Summary
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
state data.
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.
Click here
to see a movie loop from a 5-day, 4 km automatic, moving nest
simulation of Hurricane Iavn (Sept 2004).
Features and Limitations
Features:
- Fully parallel (uses RSL and RSL_LITE comm
library)
- Telescoping
- Efficient; less than 2 percent overhead for movement
Limitations:
- Leading edge initialization by interpolation
from coarse domain only
- No move-checking (illegal moves outside the parent are not
prevented yet)
- EM-core only
Configuration and Compilation
Run the ./configure program and select an option
that uses dmpar and supports either specified or atommatic 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.
As distributed, the code contains a hard-limit
of 50 for the maximum number of moves (total over all domains)
allowed per run. This can be increased by changin the setting
of:
INTEGER,
PARAMETER :: max_moves = 50
in the file frame/module_driver_constants.F
and recompiling. Compile the code using './compile em_real' for
real data cases. Other EM cases such as em_b_wave and em_quarter_ss
should also work.
Specified move:
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:
num_moves
= 4
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
nest.
Automatic move:
Unless you would like to change the default
settings, not namelist change is necessary. One must provide the
nest starting corner I/J indices via namelist.
vortex_interval: how
often the new vortex position is computed (in minutes). Default
value is 15 min.
max_vortex_speed:
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.
- The automatic moving nest scheme only works
well when there is a well-defined vortex from surface to 500 mb
level, since the scheme tracks the 500 mb vortex. Improvement
will be required to be able to track developing or weaker storms. Use time_to_move namelist control to see if it will help.
- 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
either.
- 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.
