WRF Model Version 3: Moving Nest
WRFV2.1 and later releases supports two types
of moving, 2-way interactive nested grids. The options are updated to Version 3.0
which adds a new runtime control for automatic-vortex tracking level to improve the tracking of weaker vortex.
- Specified move: User specifies nest moves
via namelist options (described below).
- Automatic move: It uses a mid-level vortex
following algorthm and hence it would work for tropical storm
simulations. Use 1:3 nest ratio for now.
In both types, the nest is initialized using
interpolated coarse grid data, including terrain, and other land
Sample output from a 48-hour 4km specified,
moving nest simulation of Hurricane Ivan (Sept 2004) is at http://www2.mmm.ucar.edu/wrf/WG2/wrf_moving_nest.gif.
to see a movie loop from a 3-day, 4 km automatic, moving nest
simulation of Hurricane Katrina (August 2005).
A capabiltiy to use high-resolution terrain and landuse data is added. Thanks to Shuyi Chen and University of Miami group for the contribution (Chen, Shuyi S., Wei Zhao, Mark A. Donelan, James F. Price, Edward J. Walsh, 2007: The CBLAST-Hurricane Program and the Next-Generation Fully Coupled Atmosphere–Wave–Ocean Models for Hurricane Research and Prediction. Bull. Amer. Meteor. Soc., 88, 311–317.
To compile the code so that it will read-in the high-res terrain and landuse data, set the environment variable TERRAIN_AND_LANDUSE before issuing 'configure' and 'compile'. Since this high-res landuse dataset is from USGS, one should use USGS to create the domain 1 input file.
To use the high-res terrain and landuse dataset in a moving nest run, first create a directory, and unzip and untar the following two files in the directory:
Then add the following parameters in the &time_control section of the namelist.input file:
rsmas_data_path = "path-to-the-high-res-data"
input_from_hires = .false., .true., .true.,
Features and Limitations
- Fully parallel (uses RSL_LITE comm
- Efficient; less than 2 percent overhead for movement
- Leading edge initialization by interpolation
from coarse domain only
- No move-checking (illegal moves outside the parent are not
Configuration and Compilation
Run the ./configure program and select an option
that uses dmpar and supports either specified ("preset moves") or automatic ("vortex following") moving nesting.
The generated configure.wrf file should have additional compile flags for moving nest compile: -DMOVE_NESTS for specified moving nest runs, and -DMOVE_NESTS
and -DVORTEX_CENTER for the automatic moving
nest runs. For now, one must recompile to do specified or automatic
moving nest runs. Also note that once the code is compiled with either moving nest options, it is only working for moving nest. Recompile with 'basic' nest option for fixed nest runs.
As distributed, the code contains a hard-limit
of 50 for the maximum number of moves (total over all domains)
allowed per run for specified moves. This can be increased by changin the setting
PARAMETER :: max_moves = 50
in the file frame/module_driver_constants.F
To compile for real data cases, type './compile em_real'.
To use high-resolution terrain and landuse dataset, set environment variable TERRAIN_AND_LANDUSE before doing 'configure' and 'compile'.
Running (namelist.input settings)
Unless you would like to change the default
settings, no namelist change is necessary. One must provide the
nest starting corner I/J indices via namelist.
often the new vortex position is computed (in minutes). Default
value is 15 min.
used to compute the search radius for the new vortex position
(in unit of m/sec). Default value is 40 m/sec.
corral_dist: the distance
in number of coarse grid cells that the moving nest is allowed
to get near the mother domain boundary. Default value is 8.
track_level: the default vortex track_level is set to 500 mb. It the vortex is weaker, but still organized, one may choose to use a lower pressure level for the tracking level
time_to_move: new in V3.1. This may help for the cases where automatic tracking may not work well when the model starts.
input_from_hires: new in V3.6. This allows high-resoultion landuse and terrain dataset to be read in as nests move in a simulation. This option overwrites option input_from_file for the nests.
rsmas_data_path: new in V3.6. Directory path to the high-resolution terrain and landuse dataset.
Run WRF with moving nests the same way you usually
run WRF on your machine. I/O and other model behavior is also
the same. The principal differences for specifying and running
moving nests are in the namelist.input file for your run. Moving
nests are specified in the namelist.input the same way as non-moving
nests (see "How to Make
a Two-way Nested Run?") but with several additional settings
to control the movement of the nests. For example:
move_id = 2, 2, 2, 2, 2
move_interval = 3, 6, 9, 12, 150
move_cd_x = 1, 1, 0, -1, 1
move_cd_y = 1, -1, 1, -1, 0
Num_moves is the total
number of moves you can make in model run. A move of any domain
counts against this total. Maximum is currently 50, which is specified
as MAX_MOVES in frame/module_driver_constants.F.
Move_id is a list
nested id's, one per move, indicating which dommain is to move
for a given move. The integer id corresponds to the number given
to the nest in the grid_id setting elsewhere in the namelist.
In example above, domain 2 is subject to 4 moves (domain 1 is
always the top-level "mother" domain and never moves). There is
currently no error checking for "bad" moves: for example, a move
that puts the nest outside the parent. Results of such an illegal
move are not predictable.
Move_interval is the
number of minutes since the beginning of the run that a move is
supposed to occur. It does not have to be whole time steps. The
move will happen on the next time step after the specified instant
of model time has passed. In the example above, the nest will
move at 3, 6, 9, and 12 minutes after the start of the domain.
move_cd_x and move_cd_y
are the distance and direction to move a domain in x and y. East
and north with positive values; west or south are negative values.
The value is an integer distance in coarse domain grid cells.
Currently in this prototype implementation, the absolute value
of the setting must not be greater than 1 (only a temporary limit).
In other words, the only allowable values for a move are -1, 0,
or 1. In the example above, the nest will move north-east, then
south-east, then north, then south-west. (The fifth move is east,
but since num_moves is set to 4 this move will not occur).
These namelist variables are treated as hidden.
By default, the registry-specified default value of num_moves
is zero, which means "no nest movement". There is no need to modify
the default namelists in the test directory if moving nesting
is not required.
It is possible to initialize the nest from a
file (input_from_file = .true.) assuming the wrfinput_d0x files
are available. However, whether or not the nest is initialized
from input files or with interpolated data from its parent, the
leading edge of the moving domain is aways initialized with data
interpolated from the parent in this prototype release of moving
A Number of Caveats in 3...
- The automatic moving nest scheme only works
well when there is a well-defined vortex from surface to the 'track_level', since the scheme tracks the vortex at the 'track_level'. The latest code appears to work reasonably well for developing or weaker storms.
- The moving nest may be controlled by time_to_move namelist to allow sit in a fixed location until the time to move. This may be helpful in studies of cyclongenesis.
- The moving nest code has been tested on limited
platforms: IBM, Linux cluster, and Opteron cluster using PGI compiler.
- Only a limited number of physics options are
tested. These include KF cumulus option, YSU PBL, Noah LSM and
5-layer soil model, microphysics options 2,3,5,6 and 8, Dudhia
short-wave and RRTM longwave radiation options. Grell-Devenyi
is not supported. MYJ PBL and BMJ cumulus scheme may not work
- When running with moving nest, nest input
is not used (or the option is not implemented). This is because
once the nest moves, the underlying surface needs to be redefined
and this can only be done with interpolated data. However there
will be an option to use a sepearte high-resolution terrain and
landuse data from a separate source in the model which would allow
the model to calculate these high-resolution data over the moving
grids during model integration. This option is still under development.