long-term WRF run

[sekluzia]

Dear Colleges,

I am interested in long-term WRF simulations at 3 km spatial resolution for recent 10-year period. I am going to use ERA5 reanalysis data in my simulations.

I have two questions:

1) Can you suggest me a guide where can I find necessary information for properly configuring my long-term WRF runs? Otherwise, could you kindly mention the main points which are different and important to be considered in the long-term WRF runs relative to the short-term WRF runs (i.e. namelist options, input data, etc.).

2) Is it possible to perform long-term WRF simulations through multiple short-term runs (48 h), i.e. using multiple initializations of the model and considering 12 h spin-up time for each run? Will this method produce better (or poorer) results compared to the single initialization 10-year run?

Best regards,
Artur

 

[kwerner]

Hi Artur,

To run long runs, there are a few different things you'll need to make sure to do:
1) Most input data come with SST data, but they are coarse, so you will need to make sure to obtain some additional SST data. This presentation gives some options for climate data sources, as well as SST data:
http://www2.mmm.ucar.edu/wrf/users/tutorial/201901/werner_data_util_pp.pdf
Almost all climate data comes in netCDF format, which means that you will have to convert it to intermediate file format for metgrid to read (you will skip the ungrib process if this is the case). You can read about that conversion here: http://www2.mmm.ucar.edu/wrf/users/docs/user_guide_v4/v4.0/users_guide_chap3.html#_Writing_Meteorological_Data
I'm also attaching an example fortran script for doing that. Just keep in mind that this script was written by someone else for their specific application and then given to us, so you'll need to modify as need be for your own run.

2) When running real, you should probably run it in increments, possibly for 2 reasons: 1) if you're using a batch queueing system, there are likely limitations to the number of hours you can run, and you will reach that limit before the run is completed. 2) There is a file size limit, and the wrfinput/wrfbdy files will likely reach that limit before real.exe is complete. I would recommend running this for a couple of months at a time, and perhaps including a bit of overlap so that when you run wrf and restart the model, you can make sure to have boundary conditions for the time of your restart file.

3) You will want to run wrf in increments, as well, using the restart option (http://www2.mmm.ucar.edu/wrf/users/docs/user_guide_v4/v4.0/users_guide_chap5.html#restart), running for a period of time, and outputting restart files at certain intervals (not too often, as the model slows down when writing out files, but often enough so that if your run stops for any reason, you can restart from a file you have and won't lose too much data/time).

4) You will also need to use the bucket options, which you can read about here:
http://www2.mmm.ucar.edu/wrf/users/docs ... tml#bucket

As for your second question, I'm sure it would be possible to do it that way, but would be very tedious, and much more time-consuming. As to the results, I can't say which would be better. That would depend on the individual run, and may be something you would need to test.

 

[sekluzia]

Thank you so much for your detailed and helpful explanations! I definitely need some time to understand and analyse the information provided by you.
I have one more question regarding the spin-up time. For short-term simulations (up to 48h) the spin-up time of 12 h should be fine. Is there any approach of estimating the spin-up time for long-term runs? For example, what should be the spin-up time for one year and ten year runs, respectively?

Best regards,
Artur

 

[kwerner]

I don't believe the length of the run should make a difference. The spin-up time is simply to ensure that the model has had ample time to stabilize so that the results can become reliable, and are not just simply based on the initial and boundary conditions. Once this happens, the model can go forward to generate estimations for forecasting purposes.