Run a WRF Restart¶

A restart runs allows a user to extend a run to a longer simulation period when there are reasons the entire simulation cannot be done at one time (e.g., not enough wall-clock time). It is effectively a continuous run made of two or more shorter runs; hence the results at the end of one or more restart runs should be identical to a single run without any restart. It is good practice to produce restart files when running longer simulations. If the model should stop for any reason, having restart files allows starting the model again from that restart time, instead of having to run from the beginning.

To restart the model, a restart file must have been created during a previous simulation. This is done by setting the namelist variable restart_interval (in minutes) to a value equal to, or less than, the simulation length in the original model run, as specified by run_* variables, or start_* and end_* times. When the model reaches the time to write a restart file, a restart file named wrfrst_d<domain>_<date> is written. The date string represents the time when the restart file is valid.

During the Single Domain Case, the above namelist parameters should have been set properly to create a restart file, which is what will be used for this case. This exercise uses the same severe storm outbreak over the midwest and southest United States case from the Single Domain exercise, along with the same setup. The difference is that this exercise teaches to steps to restart the model at a particular time. If you have not gone through the Single Domain exercise, please go back and run that case before advancing in this exercise.

Steps to Restart the Model¶

When restarting the model, there is no need to re-run any of the WPS programs, or the real.exe program, as the wrfrst file contains all of the initial condition information (and will serve to replace the wrfinput_d01 file), and will be used, along with the wrfbdy_d01 file to run wrf.exe.

Simply follow the steps below to run wrf.exe for a restart simulation.

Move into the test/em_real directory.
Edit the namelist.input file. Note that the only namelist settings that need to be changed are in the &time_control record.
```
&time_control
run_hours  = 12,
start_day  = 31,
start_hour = 12,
restart    = .true.,
```
Run wrf.exe using the method for which the model was compiled.

For parallel-processing (dmpar
```
mpiexec -np X ./wrf.exe
```
where X indicates the number of processors to use. An appropriate number of processors for this particular simulation would be somewhere between ~1-50. See Choosing an Appropriate Number of Processors.

For serial processing (using a single processor)
```
./wrf.exe >& wrf.log
```
The error and output will go to the wrf.log file for serial computation, and for parallel computation, there will be an rsl.out and rsl.error file available for each processor. Check the end of those files for the “SUCCESS” message to ensure wrf.exe ran correctly. If successful, the following new history files will be available in the em_real directory.
```
wrfout_d01_2023-03-31_15:00:00
wrfout_d01_2023-03-31_18:00:00
wrfout_d01_2023-03-31_21:00:00
wrfout_d01_2023-04-01_00:00:00
```

Note

Notice a wrfout file is not created for the start time of 12 UTC. This is a default safety feature to prevent overwriting the previously-created file. To have a new file output for the restart initial time, add the line write_hist_at_0h_rst = .true. anywhere within the &time_control namelist.input record, prior to running wrf.exe.

To look at the contents in the wrfout files, use either the netCDF ncdump utility, or the ncview tool.

Tip

Occasionally when running restarts, wrfout files will not print out at the expected times. To overcome this issue, add override_restart_timers = .true. anywhere in the &time_control namelist.input record, prior to running wrf.exe.
Restart runs can also be useful for troubleshooting. For e.g., if a simulation crashes at a certain time, it can be helpful to add print statements to the code to determine what went wrong. After doing this, the model can use the restart files to start from a time right before the model crashes, instead of having to start from scratch each time.

Try Another Exercise ->