Chapter 5: WRF Model

Table of Contents

Introduction

The WRF model is a fully compressible, and nonhydrostatic model (with a runtime hydrostatic option). Its vertical coordinate is a terrain-following hydrostatic pressure coordinate. The grid staggering is the Arakawa C-grid. The model uses the Runge-Kutta 2nd and 3rd order time integration schemes, and 2nd to 6th order advection schemes in both horizontal and vertical. It uses a time-split small step for acoustic and gravity-wave modes. The dynamics conserves scalar variables.

The WRF model code contains several initialization programs (ideal.exe and real.exe; see Chapter 4), a numerical integration program (wrf.exe), and a program to do one-way nesting (ndown.exe). The WRF model Version 3 supports a variety of capabilities. These include

 

Other References

 

Installing WRF

Before compiling WRF code on a computer, check to see if the netCDF library is installed. This is because one of the supported WRF I/O options is netCDF, and it is the one commonly used, and supported by the post-processing programs. If the netCDF is installed in a directory other than /usr/local/, then find the path, and use the environment variable NETCDF to define where the path is. To do so, type

setenv NETCDF path-to-netcdf-library

Often the netCDF library and its include/ directory are collocated. If this is not the case, create a directory, link both netCDF lib and include directories in this directory, and use environment variable to set the path to this directory. For example,

netcdf_links/lib -> /netcdf-lib-dir/lib
netcdf_links/include -> /where-include-dir-is/include

setenv NETCDF /directory-where-netcdf_links-is/netcdf_links

If the netCDF library is not available on the computer, it needs to be installed first. NetCDF source code or pre-built binary may be downloaded from and installation instruction can be found on the Unidata Web page at http://www.unidata.ucar.edu/.

Hint: for Linux users:

If PGI, Intel or g95 compiler are used on a Linux computer, make sure netCDF is installed using the same compiler. Use NETCDF environment variable to point to the PGI/Intel compiled netCDF library.

WRF source code tar file can be downloaded from http://www.mmm.ucar.edu/wrf/download/get_source.html. Once the tar file is gunzipped (gunzip WRFV3.TAR.gz), and untared (tar –xf WRFV3.TAR), and it will create a WRFV3/ directory. This contains:

Makefile

Top-level makefile

README

General information about WRF/ARW core

README_test_cases

Explanation of the test cases

README.NMM

General information for WRF/NMM core

README.rsl_output

For NMM

Registry/

Directory for WRF Registry files

arch/

Directory where compile options are gathered

clean

script to clean created files, executables

compile

script for compiling WRF code

configure

script to create the configure.wrf file for compile

chem/

WRF chemistry, supported by NOAA/GSD

dyn_em/

Directory for ARW dynamics and numerics

dyn_exp/

Directory for a 'toy' dynamic core

dyn_nmm/

Directory for NMM dynamics and numerics, supported by DTC

external/

Directory that contains external packages, such as those for IO, time keeping and MPI

frame/

Directory that contains modules for WRF framework

inc/

Directory that contains include files

main/

Directory for main routines, such as wrf.F, and all executables after compilation

phys/

Directory for all physics modules

run/

Directory where one may run WRF

share/

Directory that contains mostly modules for WRF mediation layer and WRF I/O

test/

Directory that contains test case directories, may be used to run WRF

tools/

Directory that contains tools for developers

The steps to compile and run the model are:

1.     configure: generate a configuration file for compilation

2.     compile: compile the code

3.     run the model

Go to WRFV3 (top) directory and type

./configure

and a list of choices for your computer should appear. These choices range from compiling for a single processor job (serial), to using OpenMP shared-memory (smpar) or distributed-memory parallelization (dmpar) options for multiple processors, or combination of shared-memory and distributed memory options (dm+sm). When a selection is made, a second choice for compiling nesting will appear. For example, on a Linux computer, the above steps look like:

> setenv NETCDF /usr/local/netcdf-pgi
> ./configure

checking for perl5... no
checking for perl... found /usr/bin/perl (perl)
Will use NETCDF in dir: /usr/local/netcdf-pgi
PHDF5 not set in environment. Will configure WRF for use without.
$JASPERLIB or $JASPERINC not found in environment, configuring to build without grib2 I/O...
-----------------------------------------------------------------------
Please select from among the following supported platforms.

1.  Linux i486 i586 i686, gfortran compiler with gcc  (serial)
2.  Linux i486 i586 i686, gfortran compiler with gcc  (smpar)
3.  Linux i486 i586 i686, gfortran compiler with gcc  (dmpar)
4.  Linux i486 i586 i686, gfortran compiler with gcc  (dm+sm)
5.  Linux i486 i586 i686, g95 compiler with gcc  (serial)
6.  Linux i486 i586 i686, g95 compiler with gcc  (dmpar)
7.  Linux i486 i586 i686, PGI compiler with gcc  (serial)
8.  Linux i486 i586 i686, PGI compiler with gcc  (smpar)
9.  Linux i486 i586 i686, PGI compiler with gcc  (dmpar)
10.  Linux i486 i586 i686, PGI compiler with gcc  (dm+sm)
11.  Linux x86_64 i486 i586 i686, ifort compiler with icc (non-SGI installations)  (serial)
12.  Linux x86_64 i486 i586 i686, ifort compiler with icc (non-SGI installations)  (smpar)
13.  Linux x86_64 i486 i586 i686, ifort compiler with icc (non-SGI installations)  (dmpar)
14.  Linux x86_64 i486 i586 i686, ifort compiler with icc (non-SGI installations)  (dm+sm)
15.  Linux i486 i586 i686 x86_64, PathScale compiler with pathcc (serial)
16.  Linux i486 i586 i686 x86_64, PathScale compiler with pathcc  (dmpar)

Enter selection [1-16] : 9

Compile for nesting? (0=no nesting, 1=basic, 2=preset moves, 3=vortex following) [default 0]: 1

Enter appropriate options that are best for your computer and application.

Alternatively, one may type

> ./configure arw

When the return key is hit, a configure.wrf file will be created. Edit compile options/paths, if necessary.

Hint: It is helpful to start with something simple, such as the serial build. If it is successful, move on to build smpar or dmpar code. Remember to type ‘clean –a’ between each build.

To compile the code, type

./compile

and the following choices will appear: 

  Usage:
 
compile wrf           compile wrf in run dir (Note, no real.exe, ndown.exe or ideal.exe generated)
 
or choose a test case (see README_test_cases for details):
 
compile em_b_wave

compile em_esmf_exp (example only)
compile em_grav2d_x

compile em_heldsuarez
compile em_hill2d_x

compile em_les
compile em_quarter_ss
compile em_real

compile em_seabreeze2d_x
compile em_squall2d_x
compile em_squall2d_y

compile exp_real (example of a toy solver)

compile nmm_real (NMM solver)
 
   compile –h              help message
 

where em stands for the Advanced Research WRF dynamic solver (which currently is the 'Eulerian mass-coordinate' solver). Type one of the above to compile. When you switch from one test case to another, you must type one of the above to recompile. The recompile is necessary to create a new initialization executable  (i.e. real.exe, and ideal.exe - there is a different ideal.exe for each of the idealized test cases), while wrf.exe is the same for all test cases.

If you want to remove all object files (except those in external/directory) and executables, type 'clean'.

Type 'clean -a' to remove built files in ALL directories, including configure.wrf (the original configure.wrf will be saved to configure.wrf.backup). This is recommended if you make any mistake during the process, or if you have edited the configure.wrf  or Registry.EM file.

 a. Idealized case

For any 2D test cases (labeled in the case names), serial or OpenMP (smpar) compile options must be used. Suppose you would like to compile and run the 2-dimensional squall case, type

./compile em_squall2d_x >& compile.log

After a successful compilation, you should have two executables created in the main/ directory: ideal.exe and wrf.exe. These two executables will be linked to the corresponding test/case_name and run/ directories. cd to either directory to run the model.

It is a good practice to save the entire compile output to a file. When the executables were not present, this output is useful to help diagnose the compile errors.

b. Real-data case

For a real-data case, type

./compile em_real >& compile.log &

When the compile is successful, it will create three executables in the main/directory: ndown.exe, real.exe and wrf.exe.

real.exe: for WRF initialization of real data cases
ndown.exe : for one-way nesting
wrf.exe : WRF model integration

Like in the idealized cases, these executables will be linked to test/em_real and run/ directories. cd to one of these two directories to run the model.(back to top)

 

Running WRF

One may run the model executables in either the run/ directory, or the test/case_name directory. In either case, one should see executables, ideal.exe or real.exe (and ndown.exe), and wrf.exe, linked files (mostly for real-data cases), and one or more namelist.input files in the directory.

Hint: If you would like to run the model executables in a different directory, copy or link the files in test/em_* directory to that directory, and run from there.

a. Idealized case

Suppose the test case em_squall2d_x is compiled, to run, type

cd test/em_squall2d_x

Edit namelist.input file (see README.namelist in WRFV3/run/ directory or its Web version) to change length of integration, frequency of output, size of domain, timestep, physics options, and other parameters.

If you see a script in the test case directory, called run_me_first.csh, run this one first by typing:

./run_me_first.csh

This links some physics data files that might be needed to run the case.

To run the initialization program, type

./ideal.exe

This program will typically read an input sounding file located in that directory, and generate an initial condition file wrfinput_d01. All idealized cases do not require lateral boundary file because of the boundary condition choices they use, such as the periodic option. If the job is run successfully, the last thing it prints should be: ‘wrf: SUCCESS COMPLETE IDEAL INIT’.

To run the model and save the standard output to a file, type

./wrf.exe >& wrf.out &

or for a 3D test case compiled with MPI (dmpar) option,

mpirun –np 4 ./wrf.exe

If  successful, the wrf output file will be written to a file named
wrfout_d01_0001-01-01_00:00:00.

Pairs of rsl.out.* and rsl.error.* files will appear with any MPI runs. These are standard out and error files. Note that the execution command for MPI runs may be different on different machines and for different MPI installation. Check the user manual.

If the model run is successful, the last thing printed in ‘wrf.out’ or rsl.*.0000 file should be: ‘wrf: SUCCESS COMPLETE WRF’. Output files wrfout_d01_0001-01-01* and wrfrst* should be present in the run directory, depending on how namelist variables are specified for output. The time stamp on these files originates from the start times in the namelist file.

b. Real-data case

To make a real-data case run, cd to the working directory by typing

cd test/em_real (or cd run)

Start with a namelist.input template file in the directory, edit it to match your case.

Running a real-data case requires successfully running the WRF Preprocessing System programs (or WPS). Make sure met_em.* files from WPS are seen in the run directory (either link or copy the files):

cd test/em_real
ls –l ../../../WPS/met_em*
ln –s ../../..WPS/met_em* .

Make sure you edit the following variables in namelist.input file:

num_metgrid_levels: number of_ incoming data levels (can be found by using ncdump command on met_em.* file)
eta_levels: model eta levels from 1 to 0, if you choose to do so. If not, real will compute a nice set of eta levels. The computed eta levels have 7 half levels in the lowest 1 km or so, and stretches to constant dz.

Other options for use to assist vertical interpolation are:

use_surface: whether to use surface input data
extrap_type: vertical extrapolation of non-temperature fields
t_extrap_type: vertical extrapolation for potential temperature
use_levels_below_ground: use levels below input surface level
force_sfc_in_vinterp: force vertical interpolation to use surface data
lowest_lev_from_sfc: place surface data in the lowest model level
p_top_requested: pressure top used in the model, default is 5000 Pa
interp_type: vertical interpolation method: linear in p(default) or log(p)
lagrange_order: vertical interpolation order, linear (default) or quadratic
zap_close_levels: allow surface data to be used if it is close to a constant pressure level.

Other minimum set of namelist variables to edit are:

start_*, end_*: start and end times for data processing and model integration
interval_seconds: input data interval for boundary conditions
time_step: model time step, and can be set as large as 6*DX (in km)
e_ws, e_sn, e_vert: domain dimensions in west-east, south-north and vertical
dx, dy: model grid distance in meters

To run real-data initialization program compiled using serial or OpenMP (smpar) options, type

./real.exe >& real.out

Successful completion of the job should have ‘real_em: SUCCESS EM_REAL INIT’ printed at the end of real.out file. It should also produce wrfinput_d01 and wrfbdy_d01 files. In real data case, both files are required. 

Run WRF model by typing

./wrf.exe

A successful run should produce one or several output files with names like wrfout_d<domain>_<date> (where <domain> represents domain ID, and <date> represents a date string with the format yyyy-mm-dd_hh:mm:ss. For example, if you start the model at 1200 UTC, January 24 2000, then your first output file should have the name:

wrfout_d01_2000-01-24_12:00:00

The time stamp on the file name is always the first time the output file is written. It is always good to check the times written to the output file by typing:

ncdump -v Times wrfout_d01_2000-01-24_12:00:00

You may have other wrfout files depending on the namelist options (how often you split the output files and so on using namelist option frames_per_outfile).You may also create restart files if you have restart frequency (restart_interval in the namelist.input file) set within your total integration length. The restart file should have names like

wrfrst_d<domain>_<date>

The time stamp on a restart file is the time that restart file is valid at.

For DM (distributed memory) parallel systems, some form of mpirun command will be needed to run the executables. For example, on a Linux cluster, the command to run MPI code and using 4 processors may look like:

mpirun -np 4 ./real.exe
mpirun -np 4 ./wrf.exe

On some IBMs, the command may be:

poe ./real.exe
poe ./wrf.exe

for a batch job, and

poe ./real.exe -rmpool 1 -procs 4
poe ./wrf.exe -rmpool 1 -procs 4

for an interactive run. (Interactive MPI job is not an option on NCAR IBMs bluevista and bluefire) 

c. Restart Run

A restart run allows a user to extend a run to a longer simulation period. It is effectively a continuous run made of several shorter runs. Hence the results at the end of one or more restart runs should be identical to a single run without any restart.

 

In order to do a restart run, one must first create restart file. This is done by setting namelist variable restart_interval (unit is in minutes) to be equal to or less than the simulation length in the first 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> will be written. The date string represents the time when the restart file is valid.

 

When one starts the restart run, edit the namelist.input file, so that your start_* time will be set to the restart time (which is the time the restart file is written). The other namelist variable one must set is restart, this variable should be set to .true. for a restart run.

 

In summary, these namelists should be modified:

 

start_*, end_*:             start and end times for restart model integration
restart:                   logical to indicate whether the run is a restart or not

d. Two-way Nested Runs

A two-way nested run is a run where multiple domains at different grid resolutions are run simultaneously and communicate with each other: The coarser domain provides boundary values for the nest, and the nest feeds its calculation back to the coarser domain. The model can handle multiple domains at the same nest level (no overlapping nest), and multiple nest levels (telescoping). 

When preparing for a nested run, make sure that the code is compiled with basic nest options (option 1).

Most of options to start a nest run are handled through the namelist. All variables in the namelist.input file that have multiple columns of entries need to be edited with caution. Do start with a namelist template. The following are the key namelist variables to modify:

start_*, end_*: start and end simulation times for the nest

input_from_file: whether a nest requires an input file (e.g. wrfinput_d02). This is typically used for a real data case, since the nest input file contains nest topography and land information.

fine_input_stream: which fields from the nest input file are used in nest initialization. The fields to be used are defined in the Registry.EM. Typically they include static fields (such as terrain, landuse), and masked surface fields (such as skin temperature, soil moisture and temperature). Useful for nest starting at a later time than the coarse domain.

max_dom: the total number of domains to run. For example, if you want to have one coarse domain and one nest, set this variable to 2.

grid_id: domain identifier that is used in the wrfout naming convention. The most coarse grid must have grid_id of 1.

parent_id: used to indicate the parent domain of a nest. grid_id value is used.

i_parent_start/j_parent_start: lower-left corner starting indices of the nest domain in its parent domain. These parameters should be the same as in namelist.wps.

parent_grid_ratio: integer parent-to-nest domain grid size ratio. Typically odd number ratio is used in real-data applications.

parent_time_step_ratio: integer time-step ratio for the nest domain. It may be different from the parent_grid_ratio, though they are typically set the same.

feedback: this is the key setup to define a two-way nested (or one-way nested) run. When feedback is on, the values of the coarse domain are overwritten by the values of the variables (average of cell values for mass points, and average of the cell-face values for horizontal momentum points) in the nest at the coincident points. For masked fields, only the single point value at the collocating points is fedback. If the parent_grid_ratio is even, an arbitrary choice of  southwest corner point value is used for feedback. This is the reason it is better to use odd parent_grid_ratio with this option. When feedback is off , it is equivalent to a one-way nested run, since nest results are not reflected in the parent domain.

smooth_option: this a smoothing option for the parent domain in area of the nest if feedback is on. Three options are available: 0 = no smoothing; 1 = 1-2-1 smoothing; 2 = smoothing-desmoothing.

 

3-D Idealized Cases

For 3-D idealized cases, no nest input files are required. The key here is the specification of the namelist.input file. What the model does is to interpolate all variables required in the nest from the coarse domain fields. Set

input_from_file = F, F

 

Real Data Cases

For real-data cases, three input options are supported. The first one is similar to running the idealized cases. That is to have all fields for the nest interpolated from the coarse domain (input_from_file = T, F). The disadvantage of this option is obvious, one will not benefit from the higher resolution static fields (such as terrain, landuse, and so on).

The second option is to set input_from_file = T for each domain, which means that the nest will have a nest wrfinput file to read in. The limitation of this option is that this only allows the nest to start at the same time as the coarse domain.

The third option is in addition to setting input_from_file = T for each domain, also set fine_input_stream = 2 for each domain. Why a value of 2? This is based on the Registry setting, which designates certain fields to be read in from auxiliary input stream number 2. This option allows the nest initialization to use 3-D meteorological fields interpolated from the coarse domain, static fields and masked, time-varying surface fields from the nest wrfinput. It hence allows a nest to start at a later time than hour 0. Setting fine_input_stream = 0 is equivalent to the second option.

To run real.exe for a nested run, one must first run WPS and create data for all the nests. Suppose WPS is run for a 24 hour period, two-domain nest case starting 1200 UTC Jan 24 2000, and these files should be generated in a WPS directory:

met_em.d01.2000-01-24_12:00:00
met_em.d01.2000-01-24_18:00:00
met_em.d01.2000-01-25_00:00:00
met_em.d01.2000-01-25_06:00:00
met_em.d01.2000-01-25_12:00:00
met_em.d02.2000-01-24_12:00:00

Typically only the first time period of the nest input file is needed to create nest wrfinput file. Link or move all these files to the run directory.

Edit the namelist.input file and set the correct values for all relevant variables, described on the previous pages (in particular, set max_dom = 2, for the total number of domains to run), as well as physics options. Type the following to run:

./real.exe >& real.out
or
mpirun –np 4 ./real.exe

If successful, this will create all input files for coarse as well as nest domains. For a two-domain example, these are:

wrfinput_d01
wrfinput_d02
wrfbdy_d01

To run WRF, type

./wrf.exe
or
mpirun –np 4 ./wrf.exe

If successful, the model should create wrfout files for both domain 1 and 2:

wrfout_d01_2000-01-24_12:00:00
wrfout_d02_2000-01-24_12:00:00

e. One-way Nested Run Using ndown

WRF supports two separate one-way nested option. In this section, one-way nesting is defined as a finer-grid-resolution run made as a subsequent run after the coarser-grid-resolution run, where the ndown program is run in between the two simulations. The initial and lateral boundary conditions for this finer-grid run are obtained from the coarse grid run, together with input from higher resolution terrestrial fields (e.g. terrain, landuse, etc.), and masked surface fields (such as soil temperature and moisture). The program that performs this task is ndown.exe. Note that the use of this program requires the code to be compiled for nesting.

When one-way nesting is used, the coarse-to-fine grid ratio is only restricted to be an integer. An integer less than or equal to 5 is recommended. Frequent output (e.g. hourly) from the coarse grid run is also recommended to provide better boundary specifications.

A caveat with using ndown for one-way nesting is that the microphysics variables are not used for boundary conditions; they are only in the initial conditions. If that is important to you, use two-way nesting option instead.

To make a one-way nested run involves these steps:

1) Generate a coarse-grid model output
2) Make temporary fine-grid initial condition wrfinput_d01 file (note that only a single time period is required, valid at the desired start time of the fine-grid domain)
3) Run program ndown, with coarse-grid model output and a fine-grid initial condition to generate fine grid initial and boundary conditions, similar to the output from the real.exe program)
4) Run the fine-grid simulation

To compile, choose an option that supports nesting.

Step 1: Make a coarse grid run

This is no different than any of the single domain WRF run as described above.

Step 2: Make a temporary fine grid initial condition file

The purpose of this step is to ingest higher resolution terrestrial fields and corresponding land-water masked soil fields.

Before doing this step, WPS should be run for one coarse and one nest domains (this helps to line up the nest with the coarse domain), and for the one time period the one-way nested run is to start. This generates a WPS output file for the nested domain (domain 2): met_em.d02.<date>.

- Rename met_em.d02.* to met.d01.* for the single requested fine-grid start time.  Move the original domain 1 WPS output files before you do this.
- Edit the namelist.input file for fine-grid domain (pay attention to column 1 only) and edit in the correct start time, grid dimensions.
- Run real.exe for this domain.  This will produce a wrfinput_d01 file.
- Rename this wrfinput_d01 file to wrfndi_d02.

Step 3: Make the final fine-grid initial and boundary condition files

- Edit namelist.input again, and this time one needs to edit two columns: one for dimensions of the coarse grid, and one for the fine grid. Note that the boundary condition frequency (namelist variable interval_seconds) is the time in seconds between the coarse-grid model output times.
- Run ndown.exe, with inputs from the coarse grid wrfout file(s), and wrfndi_d02 file generated from Step 2 above. This will produce wrfinput_d02 and wrfbdy_d02 files.

Note that program ndown may be run serially or in MPI, depending on the selected compile option.  The ndown program must be built to support nesting, however.  To run the program, type,

./ndown.exe
or
mpirun –np 4 ./ndown.exe 

Step 4: Make the fine-grid WRF run

- Rename wrfinput_d02 and wrfbdy_d02 to wrfinput_d01 and wrfbdy_d01, respectively.
- Edit namelist.input one more time, and it is now for the fine-grid domain only.
- Run WRF for this grid.

The figure on the next page summarizes the data flow for a one-way nested run using program ndown.

f. Moving-Nested Run

Two types of moving tests are allowed in WRF. In the first option, a user specifies the nest movement in the namelist. The second option is to move the nest automatically based on an automatic vortex-following algorithm. This option is designed to follow the movement of a well-defined tropical cyclone.

To make the specified moving nested run, select the right nesting compile option (option ‘preset moves’). Note that code compiled with this option will not support static nested runs. To run the model, only the coarse grid input files are required. In this option, the nest initialization is defined from the coarse grid data - no nest input is used. In addition to the namelist options applied to a nested run, the following needs to be added to namelist section &domains:

num_moves: the total number of moves one can make in a model run. A move of any domain counts against this total. The maximum is currently set to 50, but it can be changed by change MAX_MOVES in frame/module_driver_constants.F.

move_id: a list of nest IDs, one per move, indicating which domain is to move for a given move.

move_interval: the number of minutes since the beginning of the run that a move is supposed to occur. The nest will move on the next time step after the specified instant of model time has passed.

move_cd_x,move_cd_y: distance in number of grid points and direction of the nest move(positive numbers indicating moving toward east and north, while negative numbers indicating moving toward west and south).

Parameter max_moves is set to be 50, but can be modified in source code file frame/module_driver_constants.F if needed.

To make the automatic moving nested runs, select the ‘vortex-following’ option when configuring. Again note that this compile would only support auto-moving nest, and will not support the specified moving nested run or static nested run at the same time. Again, no nest input is needed. If one wants to use values other than the default ones, add and edit the following namelist variables in &domains section:

vortex_interval: how often the vortex position is calculated in minutes (default is 15 minutes).

max_vortex_speed: used with vortex_interval to compute the radius of search for the new vortex center position (default is 40 m/sec).

corral_dist: the distance in number of coarse grid cells that the moving nest is allowed to come near the coarse grid boundary (default is 8). This parameter can be used to center the telescoped nests so that all nests are moved together with the storm.

track_level: the pressure level (in Pa) where the vortex is tracked.

When automatic moving nest is employed, the model dumps the vortex center location, with minimum mean sea-level pressure and maximum 10 m winds in standard out file (e.g. rsl.out.0000). Do ‘grep ATCF rsl.out.0000’ will produce a list of storm information at 15 minutes interval:

ATCF   2007-08-20_12:00:00       20.37  -81.80 929.7 133.9
ATCF   2007-08-20_12:15:00       20.29  -81.76    929.3  133.2

In both types of moving nest runs, the initial location of the nest is specified through i_parent_start and j_parent_start in the namelist.input file.

The automatic moving nest works best for well-developed vortex.

g. Three-Dimensional Analysis Nudging Run

Prepare input data to WRF as usual using WPS. If nudging is desired in the nest domains, make sure all time periods for all domains are processed in WPS.

 

Set the following options before running real.exe, in addition to others described earlier (see namelist template namelist.input.grid_fdda in test/em_real/ directory for guidance):

 

grid_fdda = 1

 

Run real.exe as before, and this will create, in addition to wrfinput_d0* and wrfbdy_d01 files, a file named ‘wrffdda_d0*’. Other grid nudging namelists are ignored at this stage. But it is a good practice to fill them all before one runs real. In particular, set

 

gfdda_inname   =  “wrffdda_d<domain>”
gfdda_interval =  time interval of input data in minutes
gfdda_end_h    =  end time of grid nudging in hours

 

See http://www.mmm.ucar.edu/wrf/users/wrfv2/How_to_run_grid_fdda.html and README.grid_fdda in WRFV3/test/em_real/ for more information.

h. Observation Nudging Run

In addition to the usual input data preparation using WPS, station observation files are required. See http://www.mmm.ucar.edu/wrf/users/wrfv2/How_to_run_obs_fdda.html for instructions. The observation file names expected by WRF are OBS_DOMAIN101 for domain 1, and OBS_DOMAIN201 for domain 2, etc.

 

Observation nudging is activated in the model by the following namelists:

 

obs_nudge_opt = 1
fdda_start    = 0 (obs nudging start time in minutes)
fdda_end      = 360 (obs nudging end time in minutes)

 

Look for example to set other obs nudging namelist variables in namelist template namelist.input.obs_fdda in test/em_real/ directory. See http://www.mmm.ucar.edu/wrf/users/wrfv2/How_to_run_obs_fdda.html and README.obs_fdda in WRFV3/test/em_real/ for more information.

i. Global Run

WRFV3 begins to support global capability. To make a global run, run WPS starting with namelist template namelist.wps.gloabl. Set map_proj = ‘lat-lon’, and grid dimensions e_we and e_sn without setting dx and dy in namelist.wps. The geogrid program will calculate grid distances and their values can be found in the global attribute section of geo_em.d01.nc file. Type
ncdump –h geo_em.d01.nc to find out the grid distances, which will be needed in filling out WRF’s namelist.input file. Grid distances in x and y directions may be different, but it is best they are set similarly or the same. WRF and WPS assume earth is a sphere, and its radius is 6370 km. There is no restrictions on what to use for grid dimensions, but for effective use of the polar filter in WRF, the east-west dimension should be set to 2P*3Q*5R+1 (where P, Q, and R are any integers, including 0).

 

Run the rest of WPS programs as usual but only for one time period. This is because the domain covers the entire global, lateral boundary conditions are no longer needed.

 

Run program real.exe as usual and for one time period only. Lateral boundary file wrfbdy_d01 is not needed.

 

Copy over namelist.input.global to namelist.input, and edit it. Run the model as usual.

Note that since this is a new option in the model, use it with caution. Not all options have been tested. For example, all filter options have not been tested, and positive-definite options are not working for lat-lon grid.

As an extension to the global lat-lon grid, regional domain can be set using lat-lon grid too. To do so, one need to set both grid dimensions, and grid distances in degrees. Again geogrid will calculate the grid distance assuming the earth is a sphere and its radius is 6370 km. Find grid distance in meters in the netcdf file, and use the value for WRF’s namelist.input file.

j. Using Digital Filter Initialization

Digital filter initialization (DFI) is a way to remove initial model imbalance as, for example, measured by the surface pressure tendency. This might be important when one is interested in the 0 – 6 hour simulation/forecast. It runs a digital filter during a short model integration, backward and forward, and then start the forecast. In WRF implementation, this can all be done in one job run. In V3.0, DFI can only be used in a single domain run.

No special requirement for data preparation.

Start with namelist template namelist.input.dfi. This namelist file contains an extra namelist record for DFI: &dfi_control. Edit it to match your case configuration. For a typical application, the following options are used:

dfi_opt = 3
dfi_nfilter = 7 (filter option: Dolph)
dfi_cutoff_seconds = 3600 (should not be longer than the filter window)

For time specification, it typically needs to integrate backward for 0.5 to 1 hour, and integrate forward for half of the time.

 

If option dfi_write_filtered_input is set to true, a filtered wrfinput file, wrfinput_initialized_d01, will be produced.

k. Using Adaptive Time Stepping

Adaptive time stepping is a way to maximize the time step that the model can use while keeping the model numerically stable. The model time step is adjusted based on the domain-wide horizontal and vertical stability criterion. The control options are described in the list of namelist options on page 5-32.

l. Output Time Series

There is an option to output time series from a model run. To active the option, a file called “tslist” must be present in the WRF run directory. The tslist file contains a list of locations defined by their latitude and longitude along with a short description and an abbreviation for each location. A sample file looks something like this:

 

#-----------------------------------------------#

# 24 characters for name | pfx |  LAT  |   LON  |

#-----------------------------------------------#

Cape Hallett              hallt -72.330  170.250

McMurdo Station           mcm   -77.851  166.713

 

The first three lines in the file are regarded as header information, and are ignored. Given a tslist file, for each location inside a model domain (either coarse or nested) a file containing time series variables at each model time step will be written with the name pfx.d<domain>.TS, where pfx is the specified prefix for the location in the tslist file. The maximum number of time series locations is controlled by the namelist variable max_ts_locs in namelist record &domains. The default value is 5. The time series output is for a selected variables at the surface, including 2 m temperature, vapor mixing ratio, 10 m wind components, u and v, rotated to the earth coordinate, etc.. More information for time series output can be found in WRFV3/run/README.tslist.

m. Using IO Quilting

This option allows a few processors to be set alone to do output only. It can be useful and performance-friendly if the domain sizes are large, and/or the time taken to write a output time is getting significant when compared to the time taken to integrate the model in between the output times. There are two variables for setting the option:

 

nio_tasks_per_group:   How many processors to use per IO group for IO quilting.

nio_groups:                        How many IO groups for IO. Default is 1.

Check Output

Once a model run is completed, it is a good practice to check a couple of things quickly.

If you have run the model on multiple processors using MPI, you should have a number of rsl.out.* and rsl.error.* files. Type ‘tail rsl.out.0000’ to see if you get ‘SUCCESS COMPLETE WRF’. This is a good indication that the model has run successfully.

The namelist options are written to a separate file: namelist.output.

Check the output times written to wrfout* file by using netCDF command:

  ncdump –v Times wrfout_d01_yyyy-mm-dd_hh:00:00

Take a look at either rsl.out.0000 file or other standard out file. This file logs the times taken to compute for one model time step, and to write one history and restart output:


Timing for main: time 2006-01-21_23:55:00 on domain  2:    4.91110 elapsed seconds.

Timing for main: time 2006-01-21_23:56:00 on domain  2:    4.73350 elapsed seconds.

Timing for main: time 2006-01-21_23:57:00 on domain  2:    4.72360 elapsed seconds.

Timing for main: time 2006-01-21_23:57:00 on domain  1:   19.55880 elapsed seconds.

and

Timing for Writing wrfout_d02_2006-01-22_00:00:00 for domain 2: 1.17970 elapsed seconds.

Timing for main: time 2006-01-22_00:00:00 on domain 1: 27.66230 elapsed seconds.

Timing for Writing wrfout_d01_2006-01-22_00:00:00 for domain 1: 0.60250 elapsed seconds.

 

If the model did not run to completion, take a look at these standard output/error files too. If the model has become numerically unstable, it may have violated the CFL criterion (for numerical stability). Check whether this is true by typing the following:

 

grep cfl rsl.error.* or grep cfl wrf.out

you might see something like these:

5 points exceeded cfl=2 in domain            1 at time   4.200000 

  MAX AT i,j,k:          123          48          3 cfl,w,d(eta)= 4.165821

21 points exceeded cfl=2 in domain            1 at time   4.200000 

  MAX AT i,j,k:          123          49          4 cfl,w,d(eta)= 10.66290
 
When this happens, consider using namelist option w_damping, and/or reducing time step.

Trouble Shooting

If  the model aborts very quickly, it is likely that either the computer memory is not large enough to run the specific configuration, or the input data have some serious problem. For the first problem, try to type ‘unlimit’ or ‘ulimit -s unlimited’ to see if more memory and/or stack size can be obtained.

To check if the input data is the problem, use ncview or other netCDF file browser.

Another frequent error seen is ‘module_configure: initial_config: error reading namelist’. This is an error message from the model complaining about errors and typos in the namelist.input file. Edit namelist.input file with caution. If unsure, always start with an available template. A namelist record where the namelist read error occurs is provided in the V3 error message, and it should help with identifying the error.

Physics and Dynamics Options

Physics Options

WRF offers multiple physics options that can be combined in any way. The options typically range from simple and efficient to sophisticated and more computationally costly, and from newly developed schemes to well tried schemes such as those in current operational models.

The choices vary with each major WRF release, but here we will outline those available in WRF Version 3.

1. Microphysics (mp_physics)

a. Kessler scheme: A warm-rain (i.e. no ice) scheme used commonly in idealized cloud modeling studies (mp_physics = 1).

b. Lin et al. scheme: A sophisticated scheme that has ice, snow and graupel processes, suitable for real-data high-resolution simulations (2).

c. WRF Single-Moment 3-class scheme: A simple efficient scheme with ice and snow processes suitable for mesoscale grid sizes (3).

d. WRF Single-Moment 5-class scheme: A slightly more sophisticated version of (c) that allows for mixed-phase processes and super-cooled water (4).

e. Eta microphysics: The operational microphysics in NCEP models. A simple efficient scheme with diagnostic mixed-phase processes (5).

f. WRF Single-Moment 6-class scheme: A scheme with ice, snow and graupel processes suitable for high-resolution simulations (6).

g. Goddard microphysics scheme. A scheme with ice, snow and graupel processes suitable for high-resolution simulations (7). New in Version 3.0.

h. Thompson et al. scheme: A new scheme with ice, snow and graupel processes suitable for high-resolution simulations (8; replacing the version in 2.1)

i. Morrison double-moment scheme (10). Double-moment ice, snow, rain and graupel for cloud-resolving simulations. New in Version 3.0.

2.1 Longwave Radiation (ra_lw_physics)

a. RRTM scheme: Rapid Radiative Transfer Model. An accurate scheme using look-up tables for efficiency. Accounts for multiple bands, trace gases, and microphysics species (ra_lw_physics = 1).

b. GFDL scheme: Eta operational radiation scheme. An older multi-band scheme with carbon dioxide, ozone and microphysics effects (99).

c. CAM scheme: from the CAM 3 climate model used in CCSM. Allows for aerosols and trace gases (3).

2.2 Shortwave Radiation (ra_sw_physics)

a. Dudhia scheme: Simple downward integration allowing efficiently for clouds and clear-sky absorption and scattering. When used in high-resolution simulations, sloping and shadowing effects may be considered (ra_sw_physics = 1).

b. Goddard shortwave: Two-stream multi-band scheme with ozone from climatology and cloud effects (2).

c. GFDL shortwave: Eta operational scheme. Two-stream multi-band scheme with ozone from climatology and cloud effects (99).

d. CAM scheme: from the CAM 3 climate model used in CCSM. Allows for aerosols and trace gases (3).

3.1 Surface Layer (sf_sfclay_physics)

a.MM5 similarity: Based on Monin-Obukhov with Carslon-Boland viscous sub-layer and standard similarity functions from look-up tables (sf_sfclay_physics = 1).

b. Eta similarity: Used in Eta model. Based on Monin-Obukhov with Zilitinkevich thermal roughness length and standard similarity functions from look-up tables(2).

c. Pleim-Xiu surface layer. (7). New in Version 3.0.

3.2 Land Surface (sf_surface_physics)

a.5-layer thermal diffusion: Soil temperature only scheme, using five layers (sf_surface_physics = 1).

b. Noah Land Surface Model: Unified NCEP/NCAR/AFWA scheme with soil temperature and moisture in four layers, fractional snow cover and frozen soil physics (2).

-Urban canopy model (ucmcall): 3-category UCM option

c. RUC Land Surface Model: RUC operational scheme with soil temperature and moisture in six layers, multi-layer snow and frozen soil physics (3).

d. Pleim-Xiu Land Surface Model. Two-layer scheme with vegetation and sub-grid tiling (7). New in Version 3.0.

4. Planetary Boundary layer (bl_pbl_physics)

a. Yonsei University scheme: Non-local-K scheme with explicit entrainment layer and parabolic K profile in unstable mixed layer (bl_pbl_physics = 1).

b. Mellor-Yamada-Janjic scheme: Eta operational scheme. One-dimensional prognostic turbulent kinetic energy scheme with local vertical mixing (2).

c. MRF scheme: Older version of (a) with implicit treatment of entrainment layer as part of non-local-K mixed layer (99).

d. ACM2 PBL: Asymmetric Convective Model with non-local upward mixing and local downward mixing (7). New in Version 3.0.

e. LES PBL: A large-eddy-simulation (LES) boundary layer is available in Version 3. For this, bl_pbl_physic = 0, isfflx = 1, and sf_sfclay_physics and sf_surface_physics are selected. This uses diffusion for vertical mixing and must use diff_opt = 2, and km_opt = 2 or 3, see below. Alternative idealized ways of running the LESPBL are chosen with isfflx = 0 or 2.

5. Cumulus Parameterization (cu_physics)

a. Kain-Fritsch scheme: Deep and shallow convection sub-grid scheme using a mass flux approach with downdrafts and CAPE removal time scale (cu_physics = 1).

b. Betts-Miller-Janjic scheme. Operational Eta scheme. Column moist adjustment scheme relaxing towards a well-mixed profile (2).

c. Grell-Devenyi ensemble scheme: Multi-closure, multi-parameter, ensemble method with typically 144 sub-grid members (3).

d. Grell 3d ensemble cumulus scheme. Scheme for higher resolution domains allowing for subsidence in neighboring columns (5). New in Version 3.0.

e. Old Kain-Fritsch scheme: Deep convection scheme using a mass flux approach with downdrafts and CAPE removal time scale (99).

Diffusion and Damping Options

Diffusion in WRF is categorized under two parameters, the diffusion option and the K option. The diffusion option selects how the derivatives used in diffusion are calculated, and the K option selects how the K coefficients are calculated. Note that when a PBL option is selected, vertical diffusion is done by the PBL scheme, and not by the diffusion scheme. In Version 3, vertical diffusion is also linked to the surface fluxes.

1.1 Diffusion Option (diff_opt)

a. Simple diffusion: Gradients are simply taken along coordinate surfaces (diff_opt = 1).

b. Full diffusion: Gradients use full metric terms to more accurately compute horizontal gradients in sloped coordinates (diff_opt = 2).

1.2 K Option (km_opt)

Note that when using a PBL scheme, only options (a) and (d) below make sense, because (b) and (c) are designed for 3d diffusion.