Scheduled Downtime
On Friday 21 April 2023 @ 5pm MT, this website will be down for maintenance and expected to return online the morning of 24 April 2023 at the latest

How to migrate from 3dvar to 4dvar

KiyoTom

Member
Hello all!

I have a question about creating a model to forecast the weather using 4dvar products.

The tutorial I referred to does a cycle run using 3dvar. I would like to run this with 4dvar.
WRFDA Practice

In the tutorial there are
1) Run wrf.exe from 00:00 to 06:00 using wrfinput and wrfbdy, which do not take in observation data.
2) Run 3dvar using the 06:00 forecast from 1), wrfinput and wrfbdy created by real.exe for the forecast from 06:00, and the observed data. (Includes running da_update_bc.exe)
3) Execute wrf.exe using the results of 2).
The process is repeated.

I want to run 2) with 4dvar and would like to know how to rewrite namelist.input.

Aside from the flags that tell 4dvar to execute, I would like to know how to rewrite the part that specifies the time below.

&wrfvar18
analysis_date="2013-12-23_06:00:00",
/
&wrfvar19
/
&wrfvar20
/
&wrfvar21
time_window_min="2013-12-23_04:30:00.0000",
/
&wrfvar22
time_window_max="2013-12-23_07:30:00.0000",
/
&wrfvar23
/
&time_control
start_year = 2013,
start_month = 12,
start_day = 23,
start_hour = 06,
start_minute = 00,
start_second = 00,
end_year = 2013,
end_month = 12,
end_day = 23,
end_hour = 06,
end_minute = 00,
end_second = 00,
/

Best regards.
 
Last edited:
Hello KiyoTom,

If you want to run the 4DVAR, first you will need to re-compile WRFDA. Please visit this link for instructions on how to do that: WRFDA Tutorial or this link You will likely need more software as well (such as WRFPLUS and rttov/CRTM) to compile it. Once that's complete (or if you already have that done), then you will need to use any .4DVAR files that may or may not be provided (I'm not familiar with that tutorial so I'm not sure if it supplies 4DVAR files), or create your own, or use ncep bufr files for the test. The bufr files are pretty straightforward and will require some modification of the namelist options, but those are all covered in depth in the first link I sent. I hope that helps and if you have anymore questions, feel free to ask.

Cheers,
JeremyB
 
Hello Jeremy B.

Thanks for your advice.

I am building the executable with 4dvar options.

My goal is to create a wrfinput for the forecast starting at 09:00.
First I want to replace the example for 3dvar with 4dvar and assimilate the observation data from 07:30 to 10:30.

In this link, there is a note in "6. Edit necessary namelist variables." Leave "time_window_min", "time_window_max" and "analysis_date" as they are for 3dvar and set "var4d=true" and "run_hours=6" settings and ran 4dvar, which completed successfully.
I would like to know if the wrfvat_out file generated matches my intended 4dvar results. If wrong, I would like to know how to set up the correct namelist.

Best regards.
 
Hello KiyoTom,

I'm glad you for it working. I believe if you want your forecast to start at 09:00, then you should change your assimilation to 09:00-10:30 instead of 07:30-10:30. If you initialize it to 07:30, then I believe the wrfvar_output will start at 07:30 and you may get an error when you run wrf (assuming it doesn't crash when you update the boundary conditions or run da_wrfvar.exe). If you could please post your namelist.input files as well as one of your rsl files that would ensure the file you generated would match your intended results. However if you changed the time_window_min, analysis_date, and start_time in &time_control to 09:00, then your time_window_max and end_time to 10:30 in the namelist then you should be good and you'll have the right file. Be sure to run da_update_bc.exe to update the lateral boundary conditions before you use that wrfvar_output as your wrfinput file. I hope that helped. Please post your namelist and rsl.out.0000 and rsl.error.0000 as those would help as well.

Thanks,
JeremyB
 
Hello JeremyB!

Thanks for your advice.

I uploaded namelist.input and rsl.out.0000.
The one I modified with your advice is stored in the "after" folder.

I did not check all of them, but ncdiff seems to be the same as the initial value when time_window_min is aligned with start as 09:00 and it is not assimilated.

I am not sure if the assimilation is correct, because the initial value of assimilating the forecast data at 09:00 with the observed data and the forecast initial value at 09:00 start looks the same as the initial value of the forecast at 09:00 start.

I think it is assimilated because the forecast result is different from the one without assimilation.

Best regards.
 

Attachments

  • 4dvar.tar.gz
    1.6 MB · Views: 1
Hello KiyoTom,

Thank you for providing your files. That provides a lot of information. I do see a problem. I'm assuming you are trying to run this case with 4DVAR files, you need to link them to a new file. For your first timestep 2023-07-03_09:00:00.0000, you should have a 4DVAR file for that time, and you should link it to a file called ob01.ascii. (ln -s obs_gts_2023-07-03_09:00:00.4DVAR ob01.ascii). Then repeat that process with the other observations files. so for the 10:00 file, it should be ob02.ascii and so on. That will then read in the observations into the wrfvar_output file. Once da_wrfvar.exe is complete, then you should run da_update_bc.exe and make sure the options in the parame.in file are correct. I hope that helps. Please reach out with any further questions. As for why the forecast result is different from the one without assimilation, that's odd and I'm not sure why it's doing that. If you ever find out please let us know.

Thanks,
JeremyB
 
Hello JeremyB.

Thanks for your advice.

First of all, sorry for the omission in the communication. We are entering our observations in radar format.
I have a basic question: if we set "var4d_bin=3600" in this case, the observation data that should be recorded in "obs.radar_2023070090000" is correct for the period 2023/07/03 09:00:00 - 2023/07/03 10:00:00 Is it correct?

The current status is: "var4d_bin" in namelist.input is changed to "3600", "ob01.radar" with observation data from "2023/07/03 09:00:00 - 2023/07/03 10:00:00" and "ob01.radar" with observation data from 2023/07/03 10:00:00 - 2023 /07/03 11:00:00", the following error occurs when "ob02.radar" is prepared and executed, and the first observation data cannot be read.

---------------------------- FATAL ERROR -----------------------
Fatal error in file: da_scan_obs_radar.inc LINE: 156
Error reading next level for
RADAR AOPR 135.411 34.638 23.0 2023-07-03_09:00:04 42195 7637
Observation number 1 out of 42195
----------------------------------------------------------------

Best regards.
 
Hello KiyoTom,

With regards to your first question that is correct. As for your second question, unfortunately I'm not too familiar with radar data with WRFDA. I usually use SYNOP stations for my purpose. However if I had to guess, I would say your little r file was not prepared properly. Please refer to this link which shows what a little r file should look like. I just wrote my own little r files using python, but I know SYNOP is much easier to work with than radar data. Unfortunately the best advice I could give for that error is to refer to this link which does contain information for radar data. If you have the raw little r file (not 4DVAR file), I would run obsproc.exe on that (after modifying the namelist.obsproc). That should tell you if your data is in the correct format. If all you have are the 4DVAR files, then something is wrong with those files. I would also ask one of the mods if this didn't help since this is out of my expertise. However, if you did get it working, please post your solution in depth as others will likely have the same issue in the future.

Thanks,
JeremyB
 
Hello JeremyB.

Thanks for your advice.

I will close on how to rewrite namelist.input from for 3dvar to for 4dvar.

As for the radar observation data, it has been working so far and I will look into the parameters again.

Best regards.
 
Hello JeremyB.

It seems that when radar observation data is extracted as input data, too much data per target hour results in the recent "FATAL ERROR".

Best regards.
 
Top