How to Compile?

How to Run?

WRF Namelist

WRF Updates

Moving Nest

Nudging

Known Problems and Fixes

Graphic Tools

Utilities

 

 

 

WRF Model Version 3: Moving Nest

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.

Running (namelist.input settings)

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.

A Number of Caveats in 3...

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



 
 
Home -- Model System -- User Support -- Doc / Pub -- Links -- Download -- WRF Real-time Forecast