User’s Guide for Advanced Research WRF (ARW) Modeling System Version 2

 

Chapter 5: WRF Model

Table of Contents

Introduction

The WRF model is a fully compressible, and nonhydrostatic model (with a 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 directions. 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 2.2 supports a variety of capabilities. These include

·               Real-data and idealized simulations

·               Various lateral boundary condition options for real-data and idealized simulations

·               Full physics options

·               Positive-definite advection scheme

·               Non-hydrostatic and hydrostatic (runtime option)

·               One-way, two-way nesting and moving nest

·               Three-dimensional analysis nudging

·               Observation nudging

Software requirement

·               Fortran 90 or 95 and c compiler

·               perl 5.04 or better

·               If MPI and OpenMP compilation is desired, it requires MPI or OpenMP libraries

·               WRF I/O API supports netCDF, PHD5 and GriB 1/2 formats, hence one of these libraries needs to be available on the computer where you compile and run WRF

Before you start

Before you compile WRF code on your computer, check to see if you have netCDF library installed. This is because one of the supported WRF I/O is netCDF format. If your netCDF is installed in some odd place (e.g. not in your /usr/local/), then you need to know the paths to the netCDF library, and to it’s include/ directory. You may use the environment variable NETCDF to define where the path to netCDF library is. To do so, type

setenv NETCDF/path-to-netcdf-library

If you don't have netCDF on your computer, you need to install it first. You may download netCDF source code or pre-built binary. Installation instruction can be found on the Unidata Web page athttp://www.unidata.ucar.edu/.

Hint: for Linux users:

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

Hint: NCAR IBM users:

On the other NCAR’s IBM, bluevista and blueice, the netCDF is installed in the ‘usual’ location, /usr/local, and only the 64-bit libraries are installed. No need to set anything prior to compilation.

How to compile WRF?

WRF source code tar file may be downloaded from http://www.mmm.ucar.edu/wrf/download/get_source.html. Once you obtain the tar file, gunzip, and untar the file, and this will create a WRFV2/ directory. This contains:

Makefile

Top-level makefile

README

General information about WRF code

README_test_cases

Explanation of the test cases

Registry/

Directory for WRF Registry file

arch/

Directory where compile options are gathered

clean

script to clean created files, executables

compile

script for compiling WRF code

configure

script to configure the configure.wrf file for compile

chem/

Developer code, not yet supported

dyn_em/

Directory for modules for dynamics in current WRF core (Advanced Research WRF core)

dyn_exp/

Directory for a 'toy' dynamic core

dyn_nmm/

NCEP NMM core, 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 7 test case directories, may be used to run WRF

tools/

Directory that contains tools for

Go to WRFV2 (top) directory.

Type

configure, or ./configure

and you will be given a list of choices for your computer. These choices range from compiling for a single processor job, to using OpenMP shared-memory or distributed-memory parallelization options for multiple processors. Some options support nesting, others do not. Some use RSL-LITE, others use RSL. So select the option carefully. For example, the choices for a Linux computer looks like this: 

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.




------------------------------------------------------------------------
 
Please select from among the following supported platforms.

1. PC Linux i486 i586 i686,PGI compiler (Single-threaded, no nesting)
2. PC Linux i486 i586 i686, PGI compiler (single threaded, allows nesting using RSL without MPI)
3. PC Linux i486 i586 i686, PGI compiler SM-Parallel (OpenMP, no nesting)
4. PC Linux i486 i586 i686, PGI compiler SM-Parallel (OpenMP, allows nesting using RSL without MPI)
5. PC Linux i486 i586 i686, PGI compiler DM-Parallel (RSL, MPICH, Allows nesting)
6. PC Linux i486 i586 i686, PGI compiler DM-Parallel (RSL_LITE, MPICH, Allows nesting)
7. Intel xeon i686 ia32 Xeon Linux, ifort compiler (single-threaded, no nesting)
8. Intel xeon i686 ia32 Xeon Linux, ifort compiler (single threaded, allows nesting using RSL without MPI)
9. Intel xeon i686 ia32 Xeon Linux, ifort compiler (OpenMP)
10. Intel xeon i686 ia32 Xeon Linux, ifort compiler SM-Parallel (OpenMP, allows nesting using RSL without MPI)
11. Intel xeon i686 ia32 Xeon Linux, ifort+icc compiler DM-Parallel (RSL,MPICH, allows nesting)
12. Intel xeon i686 ia32 Xeon Linux, ifort+gcc compiler DM-Parallel (RSL,MPICH, allows nesting)
13. PC Linux i486 i586 i686, PGI compiler, ESMF (Single-threaded, ESMF coupling, no nesting)

Enter selection[1-13] :

Enter a number for an option that is best for your computer and application.

You will see a configure.wrf file created. Edit compile options/paths, if necessary.

Hint: for choosing RSL_LITE versus RSL:

Choose compile options that use RSL_LITE whenever one can. The only option RSL_LITE doesn’t support is the periodic boundary condition in y. RSL_LITE is a bit faster, and will work for domains dimensioned greater than 1024x1024. The positive-definite advection scheme is implemented using RSL_LITE only.

Hint: for nesting compile:

On most platforms, this requires RSL_LITE or RSL, even if you only have one processor. Check the options carefully and select those which support nesting.

Hint: On some computers (e.g. some Intel machines), it may be necessary to set the following environment variable before one compiles:

setenv WRF_EM_CORE 1

Type 'compile', or ‘./compile’ and it will show the choices: 

  Usage:
 
compile wrf           compile wrf in run dir (Note, no real.exe, ndown.exe or ideal.exe generated)
 
test cases (see README_test_cases for details):
 
compile em_b_wave
compile em_grav2d_x
compile em_hill2d_x
compile em_quarter_ss
compile em_real
compile em_squall2d_x
compile em_squall2d_y
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. This is recommended if you make any mistake during the process, or if you have edited the Registry.EM file.

 

 

a. Idealized case

Type 'compile case_name' to compile. Suppose you would like to run the2-dimensional squall case, type

compile em_squall2d_x

or

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/ and run/directories. cd to either directory to run the model.

b. Real-data case

Compile WRF model after 'configure', type

compile em_real

or

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)

How to run WRF?

After a successful compilation, it is time to run the model. You can do so by either cd to the run/ directory, or the test/case_name directory. In either case, you should see executables, ideal.exe or real.exe, and wrf.exe, linked files(mostly for real-data cases), and one or more namelist.input files in the directory.

Idealized, real data, restart run, two-way nested, and one-way nested runs are explained on the following pages. Read on.

a. Idealized case

Suppose you choose to compile the test case em_squall2d_x, now type 'cd test/em_squall2d_x'or 'cd run' to go to a working directory.

Edit namelist.input file (see README.namelist in WRFV2/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 data files that you might need to run the case.

To run the initialization program, type

ideal.exe

This will generate wrfinput_d01 file in the same directory. All idealized cases do not require lateral boundary file because of the boundary condition choices they use, such as the periodic boundary condition option.

Note:

- ideal.exe cannot generally be run in parallel. For parallel compiles, run this on a single processor.

- The exception is the quarter_ss case, which can now be run in MPI.

To run the model, type

wrf.exe

or variations such as

wrf.exe >& wrf.out &

Note:

- Two-dimensional ideal cases cannot be run in MPI parallel. OpenMP is ok.

- The execution command may be different for MPI runs on different machines, e.g. mpirun.

After successful completion, you should see wrfout_d01_0001-01-01* and wrfrst* files, depending on how one specifies the namelist variables for output.

b. Real-data case

Type 'cd test/em_real' or 'cd run', and this is where you are going to run both the WRF initialization program, real.exe, and WRF model, wrf.exe. Start with a namelist.input file template in the directory, edit it to fit your case.

- Running real.exe using WPS output

Running a real-data case requires successfully running the WRF Preprocessing System programs(or WPS) and make sure met_em.* files from WPS are seen in the run directory. 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.d01.<date> 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 for you.

Other options for use to assist vertical interpolation are:

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.

- Running real.exe using SI output

Running a real-data case requires successfully running the WRF Standard Initialization program. Make sure wrf_real_input_em.* files from the Standard Initialization are in this directory (you may link the files to this directory).

If you use SI, you must use the SI version 2.0 and above, to prepare input for V2 WRF! Make sure you also have this line in your namelist.input file (the default input file is expected to come from WPS):

auxinput1_inname = “wrf_real_input_em.d<domain>.<date>”

For both WPS and SI output, edit namelist.input for start and end dates, and domain dimensions. Also edit time step, output, nest and physics options.

Type 'real.exe' to 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 named like wrfout_d01_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

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_d01_yyyy-mm-dd_hh:mm:ss

For DM (distributed memory) parallel systems, some form of mpirun command will be needed here. 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 the new NCAR IBMs bluevista and blueice) 

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, 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_<domain_id>_<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 (and the time a restart file is written). The other namelist variable one must set is restart, this variable should be set to .true. for a restart run.

d. One-way and Two-way Nested Forecasts

WRFV2 supports a two-way nest option in both 3-D idealized cases (quarter_ss and b_wave) and real data cases. The model can handle multiple domains at the same nest level (no overlapping nest), and multiple nest levels (telescoping).  A moving nest option has also been available since V2.0.3.1.

Note: By setting the feedback switch in the namelist.input file to 0 or 1, the domains behave as 1-way or 2-way nests, respectively.

Make sure that you compile the code with nest options.

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. The following are the key namelist variables to modify:

start_ and end_year/month/day/minute/second: these control the nest start and end times

input_from_file: whether a nest requires an input file (e.g. wrfinput_d02). This is typically an option for a real data case.

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 skintemp, soil moisture and temperature).

max_dom: setting this to a number > 1 will invoke nesting. For example, if you want to have one coarse domain and one nest, set this variable to 2.

grid_id: domain identifier will be used in the wrfout naming convention.

parent_id:use the grid_id to define the parent_id number for a nest. The most coarse grid must be grid_id  = 1.

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 in namelist.wps, if you use WPS. (If you use SI, you should find these numbers in your SI's $MOAD_DATAROOT/static/wrfsi.nl, namelist file, and look for values in the second(and third, and so on) column of DOMAIN_ORIGIN_LLI and DOMAIN_ORIGIN_LLJ).

parent_grid_ratio: integer parent-to-nest domain grid size ratio. If feedback is off, then this ratio can be even or odd. If feedback is on, then this ratio has to be odd.

parent_time_step_ratio: time ratio for the coarse and nest domains may be different from the parent_grid_ratio. For example, you may run a coarse domain at 30 km, and a nest at 10 km, the parent_grid_ratio in this case is 3. But you do not have to use 180 sec for the coarse domain and 60 for the nest domain. You may use, for example, 45 sec or90 sec for the nest domain by setting this variable to 4 or 2.

feedback: this option takes the values of prognostic variables (average of cell for mass points, and average of the cell face for horizontal momentum points) in the nest and overwrites the values in the coarse domain at the coincident points. This is the reason currently that it requires odd parent_grid_ratio with this option.

smooth_option: this a smoothing option for the parent domain if feedback is on. Three options are available: 0 = no smoothing; 1 = 1-2-1 smoothing; 2 =smoothing-desmoothing. (There was a bug for this option in pre-V2.1 code, and it has been fixed.)

3-D Idealized Cases

For3-D idealized cases, no additional 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 (namelist variable input_from_file set to F for each domain). 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 nested wrfinput file to read in (similar to MM5 nest option IOVERW = 1). The limitation of this option is that this only allows the nest to start at hour 0 of the coarse domain run.

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 current Registry setting which designates certain fields to be read in from auxiliary input stream 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 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. This option was introduced in V2.1.

To run real.exe for a nested run, one must first run WPS (or SI) and create data for all the nests. Suppose one has run WPS for a two-domain nest case, and created these files 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

Link or move all these files to the run directory, which could be run/ or em_real/.

Edit the namelist.input file and set the correct values for all relevant variables, described in the previous pages (in particular, set max_dom = 2,_ for the total number of nests one wishes to run, and num_metgrid_levels for number of incoming data levels),as well as physics options. Type the following to run:

real.exe

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

The way to create nested input files has been greatly simplified due to some improvement introduced to WRF Version 2.1.2 (released in January 2006).

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 Forecast 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 forecasts. 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 that the code is 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.

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

1) Generate a coarse-grid forecast
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 WRF 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 forecast

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, one would have run WPS (or SI) and requested one coarse and one nest domain, and for the one time period one wants to start the one-way nested run. This generates a WPS output for the nested domain (domain 2) named met_em.d02.* (or wrf_real_input_em.d02.* from SI).

- 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 and physics options.
- 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.input variable interval_seconds) is the time in seconds between the coarse-grid output times.
- Run ndown.exe, with inputs from the coarse grid wrfout files, and wrfndi_d02 file generated from Step 2 above. This will produce wrfinput_d02 and wrfbdy_d02 files.

Note that one may run program ndown with either distributed memory or serially, depending on the selected compiler options.  The ndown program must be built to support nesting, however.  For example,

mpirun -np 4 ndown.exe

or

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 following figure summarizes the data flow for a one-way nested run using program ndown.

f. Moving-Nest Run

The moving nest option is supported in the current WRF. Two types of moving tests are allowed. 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 nest runs, one first needs to compile the code with-DMOVE_NESTS flag added to ARCHFLAGS in the configure.wrf file. 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).

To make the automatic moving nest runs, two compiler flags are needed in ARCHFLAGS: -DMOVE_NESTS and -DVORTEX_CENTER. (Note that this compile would only support auto-moving nest runs, and will not support_ the specified moving nest 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).

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

This option is introduced in V2.2.

Prepare input data to WRF as usual whether you use WPS or SI. If you would like to nudge in the nest domains as well, make sure you process all time periods for all domains.

Before you run real.exe, set the following options, 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_d01 and wrfbdy_d01 files, a file named“wrffdda_d01” by default. 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 WRFV2/test/em_real/ for more information.

h. Observation Nudging Run

This option is introduced in V2.2.

In addition to the usual input data preparation from running WPS or SI, one needs to prepare an observation files to be used in the model. 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.

Once one has the observation file(s) prepared, one can activate the observation nudging options in WRF:

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

See http://www.mmm.ucar.edu/wrf/users/wrfv2/How_to_run_obs_fdda.htmland README.obs_fdda in WRFV2/test/em_real/ for more information.

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 run successfully.

-         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 you may have created. 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. 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