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

which variables are reinitialized when set false for restart

Lily_Zh

Member
Hi,

I am curious which variables are reinitialized when set to false for restart in namelist.input. I know rain, and PM2.5 (diagnose variables?) will be zero in the first 00 files. Where could I make sure those variables? I plan to use 5-day reinitialization and run several years for spin-up. I am unsure if soil moisture (which may need 1yr spin-up) and some other variables will be impacted by 5-day reinitialization.

Thank you in advance!
Lily
 
Hi,
Can you clarify a few points in your questions?
1) When you say "which variables are reinitialized when set to false for restart in namelist.input," what are you referring to that is set to false? the restart parameter?
2) Can you explain in detail what you mean by using 5-day reinitialization? Are you planning to re-run real.exe for every 5 day period? Are you planning to run restart simulations?

Thanks!
 
Hi,
Can you clarify a few points in your questions?
1) When you say "which variables are reinitialized when set to false for restart in namelist.input," what are you referring to that is set to false? the restart parameter?
2) Can you explain in detail what you mean by using 5-day reinitialization? Are you planning to re-run real.exe for every 5 day period? Are you planning to run restart simulations?

Thanks!
Hi,
1) in namelist.input:
restart = .false.,
2)Yes, for example, restart = false for Jul. 1, Jul 6, July 11...., rerun real.exe to use new wrfinput.
Thank you.
 
Thanks for clarifying. If you set restart to .false. and run a simulation, it's like an entirely new simulation. So let's say, for e.g., you wanted to run a simulation from July 1 - July 10.

If you ran a simulation from 7/1 - 7/5 as your initial simulation, and then ran real.exe and wrf.exe from 7/5 - 7/10 and had restart=.false., this simulation has nothing to do with the initial 7/1-7/5 simulation.

However, if you ran real.exe for 7/1 - 7/10, and then ran wrf.exe from 7/1 - 7/5 and set "restart_interval" to a value shorter than 4 days (e.g. = 1440 - every 23 hours), and then you ran wrf.exe again from 7/5 - 7/10, setting restart = .true., then the simulation will use the original wrinput_d0* file(s), along with the wrfrst_d0*_YYYY-07-05_00:00:00 file as the new boundary condition file (instead of using the wrfbdy_d01 file). In this way the simulation is continuous. If you wanted to do this for the entire month, you would run real.exe for the whole month, and then the initial wrf.exe simulation, and then the simultaneous restart simulations to get to the end of the month.

Does that help to answer what you're interested in?
 
Thanks for clarifying. If you set restart to .false. and run a simulation, it's like an entirely new simulation. So let's say, for e.g., you wanted to run a simulation from July 1 - July 10.

If you ran a simulation from 7/1 - 7/5 as your initial simulation, and then ran real.exe and wrf.exe from 7/5 - 7/10 and had restart=.false., this simulation has nothing to do with the initial 7/1-7/5 simulation.

However, if you ran real.exe for 7/1 - 7/10, and then ran wrf.exe from 7/1 - 7/5 and set "restart_interval" to a value shorter than 4 days (e.g. = 1440 - every 23 hours), and then you ran wrf.exe again from 7/5 - 7/10, setting restart = .true., then the simulation will use the original wrinput_d0* file(s), along with the wrfrst_d0*_YYYY-07-05_00:00:00 file as the new boundary condition file (instead of using the wrfbdy_d01 file). In this way the simulation is continuous. If you wanted to do this for the entire month, you would run real.exe for the whole month, and then the initial wrf.exe simulation, and then the simultaneous restart simulations to get to the end of the month.

Does that help to answer what you're interested in?


Hi Kelly,

I have a question regarding this. From your example, I ran real.exe and then wrf.exe for 7/1 - 7/10. Now my simulations stopped due to wallclock time of the processors on 7/5 and I have restart files created on 7/5. Now to run a restart run, I changed 2 things in the namelist:

start_* = start times for restart model integration (which is 7/5)
restart = .true.,

Now my question is, should I run real.exe again for this time change?
 
@sadya_islam20,
No, you do not need to re-run real.exe. The restart program simply looks for the wrfrst* file at your new start time, along with the wrfbdy_d01 file that you created before your initial run.
 
Thanks for clarifying. If you set restart to .false. and run a simulation, it's like an entirely new simulation. So let's say, for e.g., you wanted to run a simulation from July 1 - July 10.

If you ran a simulation from 7/1 - 7/5 as your initial simulation, and then ran real.exe and wrf.exe from 7/5 - 7/10 and had restart=.false., this simulation has nothing to do with the initial 7/1-7/5 simulation.

However, if you ran real.exe for 7/1 - 7/10, and then ran wrf.exe from 7/1 - 7/5 and set "restart_interval" to a value shorter than 4 days (e.g. = 1440 - every 23 hours), and then you ran wrf.exe again from 7/5 - 7/10, setting restart = .true., then the simulation will use the original wrinput_d0* file(s), along with the wrfrst_d0*_YYYY-07-05_00:00:00 file as the new boundary condition file (instead of using the wrfbdy_d01 file). In this way the simulation is continuous. If you wanted to do this for the entire month, you would run real.exe for the whole month, and then the initial wrf.exe simulation, and then the simultaneous restart simulations to get to the end of the month.

Does that help to answer what you're interested in?
Hi Kwerner,

Thank you for the detailed explanation.
If we do spin-up for 7days, what variable from spinup will be used for the formal simulation? After the spin-up, I set restart= false, so I think it was reinitialized, so feel confused why do the spinup?

Thank you.
 
You do a spin-up (which probably doesn't need to be more than 12-24 hours) to stabilize the model, especially near the boundaries where coarser resolution data is entering your domain. If you are running a 7 day simulation, and then starting a new run after those 7 days, that does not continue from the 7 days (i.e., not doing a restart), then you are not using anything from those 7 days for the new simulation. If you want to run a continuous simulation, you need to run it either continuously for the full length, or if you're running into issues (e.g., wallclock issues), you need to make sure you're running restart simulations, using the wrfrst* files that were output from the previous simulation.
 
You do a spin-up (which probably doesn't need to be more than 12-24 hours) to stabilize the model, especially near the boundaries where coarser resolution data is entering your domain. If you are running a 7 day simulation, and then starting a new run after those 7 days, that does not continue from the 7 days (i.e., not doing a restart), then you are not using anything from those 7 days for the new simulation. If you want to run a continuous simulation, you need to run it either continuously for the full length, or if you're running into issues (e.g., wallclock issues), you need to make sure you're running restart simulations, using the wrfrst* files that were output from the previous simulation.
Hi Kwerner,

Thank you for this detailed information. Could I know how the spin-up stabilizes the model or where I could find this information?
The chemical species concentrations should come from wrf_chem_input which is the final wrfout file from spin-up simulation. So the seven day spin-up should be useful for chemistry not for meteorology, right?

Thank you.
 
The spin-up period ensures the model components reach a physical equilibrium, due to inconsistencies between the physics in WRF and those imposed by the initial conditions from the first-guess (large-scale) data. As for the chemistry question, I'm not really sure about that. WRF-Chem is managed by a different group than ours and I don't have any experience with it. There is a WRF-Chem section in this forum where you can ask chemistry-related questions.
 
The spin-up period ensures the model components reach a physical equilibrium, due to inconsistencies between the physics in WRF and those imposed by the initial conditions from the first-guess (large-scale) data. As for the chemistry question, I'm not really sure about that. WRF-Chem is managed by a different group than ours and I don't have any experience with it. There is a WRF-Chem section in this forum where you can ask chemistry-related questions.
I see, thank you for your help and this detailed information!
 
Hi Lily_zh and kwerner,
I have a question along these lines. I am running six years of simulations and have namelist.input for each day. Every fifth day, the restart is set to false (that is the model reinitializes). For example, restart = .false. for 01/01, then 01/06, then 01/11, and so on. Basically, I run the real.exe and wrf.exe every day. When the restart is set to true, I link the wrfrst of the previous day as the wrf_input, and on days the restart is false, I use the wrf_input that the real.exe generates. What happens if I do not reinitialize the model for my entire simulation? I know the errors can accumulate, but is there any detailed documentation where I can read about that? I am asking this question because in WRF 3.9.1.1, when I set sf_urban_physics = 1, the model throws up an error about the eta_levels. The two ways I can fix that is either set sf_urban_physics = 0 (which I do not want to do) or set restart = .true. for the entire simulation.
 
@EeshanBasu,
If you are reinitializing the model every 5 days, then you are not running a continuous simulation, and each 5 day period is it's own simulation. The results will likely be quite different over time than if you were to run a simulation through the entire period. It's quite common to run very long simulations (using restarts only when necessary (for e.g., when wallclock time runs out, if using a queueing system). Unless your computing is limited by the day, it should not be necessary to restart every day. There is possibly documentation regarding accumulating errors, but I'm not aware of it.
 
@EeshanBasu,
If you are reinitializing the model every 5 days, then you are not running a continuous simulation, and each 5 day period is it's own simulation. The results will likely be quite different over time than if you were to run a simulation through the entire period. It's quite common to run very long simulations (using restarts only when necessary (for e.g., when wallclock time runs out, if using a queueing system). Unless your computing is limited by the day, it should not be necessary to restart every day. There is possibly documentation regarding accumulating errors, but I'm not aware of it.
Hi Kwerner,
What's the typical configuration of long term WRF (e.g. 5yr) running? From spin-up to the end of 5yr, do you mean never set restart=false except for the first day?
 
Hi Kwerner,
What's the typical configuration of long term WRF (e.g. 5yr) running? From spin-up to the end of 5yr, do you mean never set restart=false except for the first day?
Hi,
In my explanation, I was simply explaining the difference between doing restart simulations and consecutive back-to-back simulations. If you are doing a long-term simulation, you can try to run as long as you are able (given your environment constraints - for e.g., if you have a limited wallclock time on your cluster, you may only be able to run however long of a simulation that can fit into that wallclock time). You can make sure to output restart files at particular intervals so that you will be able to then run restarts (restart=true) using the wrfrst* files generated from the previous time frame.
 
Hi,
In my explanation, I was simply explaining the difference between doing restart simulations and consecutive back-to-back simulations. If you are doing a long-term simulation, you can try to run as long as you are able (given your environment constraints - for e.g., if you have a limited wallclock time on your cluster, you may only be able to run however long of a simulation that can fit into that wallclock time). You can make sure to output restart files at particular intervals so that you will be able to then run restarts (restart=true) using the wrfrst* files generated from the previous time frame.
Hi Kwerner,

Thank you for your reply and clarification!
Previously, I did not read any files about this but thought we conducted one month or several years of simulations using every 5-day reinitialization for WRF or WRF-Chem because it can avoid accumulated bias for meteorology, especially for cumulus precipitation. Now I doubt if my every 5-day reinitialization configuration is necessary or not, the accumulated bias may be too small and will not impact meteorology output. Do you have any idea about my concern?

Thank you.
Lily
 
Lily,
I would recommend running some comparison simulations to see what the bias is, and which method provides the most accurate results.
 
Top