WRF Model Moving Nests

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 3-day, 4 km automatic, moving nest simulation of Hurricane Katrina (August 2005).

Update (V3.6)

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.
doi: http://dx.doi.org/10.1175/BAMS-88-3-311)

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'. Beginning with V3.9 of WPS, the default landuse option was changed to MODIS; however, this high-res landuse dataset is from USGS, and therefore in order to use this capability, your landuse data should be prepared using USGS (note: this will not work with the usgs_lakes option).

geog_data_res = 'usgs_30s+default'

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:

glcc.tar.gz
topo.tar.gz

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

Features:

- Fully parallel (uses 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)

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 of:

INTEGER, PARAMETER :: max_moves = 50

in the file frame/module_driver_constants.F and recompiling.

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)

Automatic move:

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.

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.

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.

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.

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