Cycling run with 3DVAR

[beni]

Hello,

I'm trying to do a cycled run every 6 hours based on fresh GFS data with my own weather station network data assimilated, using the +6h forecast restart file from the previous run. The problem is, that in the first few hours a lot of false precipitation appears near the domains boundaries.
The process is the following:

1. I have a wrfinput_YYYY_MM_DD_HH:ii:ss warm-restart file from the previous run.
2. I download the new GFS data, run ungrib, metgrid and real.exe on it.
3. I run da_update_bc.exe with cycling=.true. and low_bdy_only=.true. (da_file and wrf_input is symlinked to the previously created wrfinput_YYYY_MM_DD_HH:ii:ss restart file).
4. I run the da_wrfvar.exe to assimilate my stations' observations (wrf_input is linked to the restart file).
5. I run da_update_bc.exe with cycling=.true. and update_lateral_bdy=.true. (da_file=wrfvar_output, wrf_input is still the wrfinput_YYYY_MM_DD_HH:ii:ss restart file).
6. Use wrfvar_output as wrfinput and start wrf.exe.

What did I misunderstood?

[toshio]

Did you solve your problem? Can you tell what you know about it?

I am experiencing a problem like yours. In my case I have a nested domain.

I made a image here https://drive.google.com/file/d/0B16l6oMrNK5ecEZrV0NxdF9EQVU/view?usp=sharing.

The red box problem is due feedback, but the blue box I don't know why.

[bociusz]

I switched back to cold-start runs because I realized that I have no upper air data to assimilate in every cycle, although it's very important to have.
I found out that if you work with cold-start runs, the new GFS initial conditions have more precise information for the upper air than the output from the previous WRF run (and that difference causes the false precipitation mentioned in my first post).
The bottom line is that if you don't have upper air data (from balloons or aircrafts) I suggest to use 3DVAR assimilation on cold-start runs.