Table of Contents

10.1   Nesting with the ARW core
10.2   Using the SI GUI to configure a ARW core nested simulation
10.3   Running wrf_prep for an ARW core nested simulation
10.4   Running wrf_run for an ARW core nested simulation
10.5   Important discussion on nesting options and start times
10.6   WRF ARW core nesting and configuration files
10.7   WRF ARW core nesting and wrf_autorun

 

10.1      Nesting with the ARW core

The ARW core officially supports concurrent 1- and 2-way nesting, which is neatly integrated into the WRF EMS. For the uninitiated, 2-way nesting allows for information from a higher resolution child domain to be fed back to the parent domain. The parent domain provides the lateral boundary conditions to the nested domain at each time step, then the nested domain is allowed to integrate forward in time with the results are fed back onto the parent domain. In the case of 1-way nesting, this feedback mechanism is turned off so while the parent domain provides the boundary conditions to the nested domain, there is no exchange of information from the nest back to the parent. When running the ARW core, all nesting is concurrent with the parent domain, meaning that the nest runs at the same time as the outer domain. The benefit of concurrent nesting is that the boundary conditions for the nested domain can be provided at every parent domain time step. The limitation in this method is that it requires more physical memory on your workstation in order to run multiple domains at the same time.

 

The steps in running an ARW core nested simulation are described in the following sections; however, the basic sequence includes:

1. Configuring your nested domains with the SI GUI
2. Run the wrf_prep script with "--nests" option to setup the simulation
3. Edit the wrf_run configuration files for the simulation
4. Run the wrf_run script with the "--nests" option to initialize and run your simulation
5. Run the wrf_post script with the "--domain" flag to post process the forecast files.

 

10.2      Using the SI GUI to configure a ARW core nested simulation

Author's note: Some of the verbiage contained within this section was liberally adapted or used verbatim from "USERS GUIDE TO THE GRAPHICAL USER INTERFACE TO PREPARE THE STANDARD INITIALIZATION FOR WRF VERSION 2.1" by P. McCaslin, J. Smart, and B. Shaw. The full document is available in the docs/wrfsi directory of the WRF EMS package if you are interested. - Just giving them their props

The static initialization GUI (sigui) should be used to create your domains for ARW core nested runs. This process is nearly identical to creating a single computational domain except for an additional step that is described in this section. The GUI can handle multiple domains at the same nest level (no overlapping nest), or multiple nest levels (telescoping). Examples of both types of nests will be provided and the domains illustrated in those examples will be used throughout this nesting guide.

In order to create a nested domain with the SI GUI, select the "Nest Domain" tab in the Horizontal Grid configuration window. This step should be completed after you have defined your primary or "Mother of all Domains" (MOAD) area.

 

Selecting the "Nest Domain" tab will reveal a new window with menus for configuring your nests. It is important to note that all nested domains are defined as a function of the parent domain, so that the I, J corner points of a nest will be specified as values on the parent domain.

Users will be able to draw a nest domain only after they have selected values for the Domain ID , Parent ID , and Grid Space Ratio .

First select a nest Domain ID . Since the domain ID of the Mother of all Domains is always 1, the first nested domain you create will have an ID of 2. The second nest you create will have an ID of 3.

Next, specify the parent domain with the Parent ID menu. Remember that most values defining a nested domain are specified relative to the parent domain. In the above example, domain 2 (d02) is the nest and domain 1 (d01) is the parent.

Finally, select a Grid Spacing Ratio to Parent value from a list of choices. Note that the default value for the grid space ratio is 3, meaning that the nested domain will have a grid spacing 1/3 of that of the parent domain.

Important - This value (3) is the recommended grid space ratio for all ARW core nested domains. Using an even ratio, i.e, 2, 4, 6, etc. may cause your nested run to fail . Stick with a ratio of 3; you will be glad you did.

Once these values are chosen, the graphical interface will allow you to draw a nested domain using the mouse cursor. A nest must be at least 5 grid points inside the parent's grid boundary - the GUI will ensure that this limit is not exceeded. Each nest is constrained to have its corner points coincident with grid points of its parent domain, which the GUI will also ensure. The corner point values of the nest are displayed in the entry boxes for the lower left I, J, and upper right I, J. As with any domain, you can adjust the nest as necessary. The nest can be fine-tuned either by manually editing the text values, or interactively using the mouse cursor to change the nest's size and shape.

You can create as many nested domains as desired, as long as you don't get carried away.

The above example shows a second nested domain (d03) that is also a child of domain 1 (d01). This is an example of having multiple nested domains at the same level. You can also have telescoping nests similar to those shown in the next example.

The below image depicts a nested domain (d04) that is the child of domain 02 (d02), which itself is a child of domain 01 (d01). This is an example of telescoping nests. Note that the grid spacing for domain 01 (MOAD) is 30km, the spacing for d02 and d04 is 10.0 and 3.33km respectively.

A few notes: If the GUI will not create the nest that you are trying to draw, look for important information in the User Hints & Information panel. You just may be trying to create a child nest completely outside of the (selected) Parent ID domain. This is a common mistake.

Selecting "Delete Nest" will delete all of the information about the nest, its bounding box, and all of the parameters used, to describe the nest, including the Domain ID .

Selecting "Erase Box" clears the nest bounding box in order for the user to redraw it without having to redefine its Parent ID and Grid Spacing Ratio to Parent .

Selecting "Restore All Nests" button that loads all nests previously written to disk. If you change a nest value and it has been written to disk, then pressing this button reloads the nest(s) to its previous values.

The process for creating nested domains with the WRF SI GUI is the same as creating a single domain. The only difference is that following a successful localization, you will find a set of static surface files for each domain that you created in the runs/<domain>/static directory, each identified by "<data set>.d<domain>.dat". For example, in the case presented above in which four domains were created, 1 primary and 3 nests, there will be four topography files in the static directory, topography.d01.dat, topography.d02.dat, topography.d03.dat, and topography.d04.dat. If these files do not exist then there was a problem with the localization.

 

10.3      Running wrf_prep for an ARW core nested simulation

After using the SI GUI tool to configure your nests, the next step is to run wrf_prep from your domain directory. At this point you can decide which, if any, of the nested domains will be used in your simulation. Just because you created four domains doesn't mean that you need to use them all. In the case above, the four domains were created and identified as d01, d02, d03, and d04. Domain 01 (d01) is always the Mother of All Domains (MOAD) and does not require that any special options be passed to wrf_prep; however, if you want to use any of the nested domains you must pass the " --nests " flag, which is followed by the domains you want to initialize.

For example:

% wrf_prep [other arguments] --nests 2,3,4

Or

% wrf_prep [other arguments] --nests 3

Or

% wrf_prep [other arguments] --nests 2,3

Or

% wrf_prep [other arguments] --nests 2,4 (4 is a sub nest of 2)

But not

% wrf_prep [other arguments] --nests 3,4 (2 MUST be included with 4)

Or

% wrf_prep [other arguments] --nests 4 (2 MUST be included with 4)

 

Here is a real example:

% wrf_prep --dset gfsgrb2 --length 12 --ftp --sfcdset ssthr --nests 2, 4

Following the successful completion of wrf_prep you should find files for each domain that you requested in the "siprd" directory. These files will be used as input to the WRF REAL program, which is part of the next step.

 

10.4      Running wrf_run for an ARW core nested simulation

The purpose of the wrf_run script is to create the initial and boundary conditions used for the simulation, and then execute the model simulation. By default, wrf_run will only run the primary domain unless the "--nests" option is passed to wrf_prep. Passing the "--nests" flag not only tells wrf_run which domains to run but also the start hour relative to the parent domain, and the length of the forecast. Therefore, it is possible to run a nested simulation over a shorter period than that of the parent domain depending on the arguments you pass to "--nests".

The arguments to the "--nests" option are:

--nests Domain#[:Start:Length],.

Where,

Domain# Is the nested domain you wish to run

Start Is the number of hours after the start of the primary domain when you wish to begin the nested run

Length Is the length, in hours, of the nested simulation

 

Note that

1. "Domain#" is mandatory but "Start" and "Length" are optional.

2. Both the Start and Length values are preceded by a colon (:).

3. Multiple Domains with unique Start and Length values are separated by a comma.

4. In the absence of a start or length value the simulation will default to the entire length of the primary forecast

 

Here are a few examples:

A) % wrf_run --nests 2,3

Translation: Initialize nested domains 2 and 3 to run for the entire length of the primary forecast. Domain 1 does not need to be included in the list.

B) % wrf_run --nests 2:03, 3

Translation: Just like (A) except start nested domain 2, three hours after the start of the primary domain (t 0 +3). Nested domain 3 will run for the entire length of the primary domain. Note that from the discussion in section 10.2 (GUI configuration), nested domains 2 and 3 are independent of one another and are both children of the primary domain (d01).

C) % wrf_run --nests 2:03, 3:06:12

Translation: Just like in (B) except start nested domain 3 six hours after the start of the primary domain (domain 01) and run it for 12 hours. Note that if the primary domain simulation length is less than 18 hours (6+12) then the domain 3 forecast will terminate with the primary forecast.

D) % wrf_run --nests 2:03, 4:06:12

Translation: Start nested domain 2, which is the parent of domain 4, three hours after the start of the primary domain (domain 01) and run until the end of the primary simulation. Start domain 4, six hours after domain 1 (3 hours after domain 2), and run for 12 hours. Note that if the primary domain length is less than 18 hours (6+12) then the forecast for domain 4 will terminate with the primary and domain 2 forecasts.

E) % wrf_run --nests 2:03:12, 4:06:12

Translation: As in (D) except start nested domain 2, three hours after the start of the primary domain (domain 01) and run for 12 hours. Start domain 4, three hours after domain 1 (3 hours after domain 2), and run for 12 hours. Ha! - The actual length of the domain 4 run will be 9 hours since it will terminate with the end of domain 2 simulations.

F) % wrf_run --nests 2:06:12, 4:03:12

Translation: As in (D) except start nested domain 2, 6 hours after the start of the primary domain (domain 01) and run for 12 hours. Start domain 4, 3 hours after domain 1 and run for 12 hours. Ha! - The actual start of the domain 4 run will be 6 hours after the primary domain since you can not start a nested simulation before its parent.

G) % wrf_run -nests 2:02:05, 4:05:12

Translation: Start nested domain 2, the parent of domain 4, two hours after the start of the primary domain (domain 01) and run for 5 hours. Start domain 4, five hours after domain 1 (3 hours after domain 2), and run for 12 hours. Note that this will only work if you passed the "-hiresbc" option to wrf_prep.

 

10.5      Important discussion on nesting options and start times

There are a few things you should know regarding 1-and 2-way nesting and nested start times.

 

First, as explained earlier, 2-way nesting involves the feedback of information from the nested domain to the parent domain. The parent domain provides the lateral boundary conditions to the nested domain at each parent domain time step, in turn, the nested domain is allowed to integrate forward in time and the results are fed back onto the parent domain. In the case of 1-way nesting this feedback mechanism is turned off so that the parent domain provides the boundary conditions to the nested domain but there is no exchange of information from the nest back to the parent. The FEEDBACK option in the conf/wrf_run/run_grid.conf file governs whether feedback is turned ON. If FEEDBACK is ON then 2-way nesting will occur. If feedback is OFF then you will execute a 1-way nest. Note that 2-way nesting only works with odd parent-to-nest grid ratios, which is why the suggested ratio is 3. If you failed to heed the previous warning and selected a parent-to-nest ratio of 4, then FEEDBACK is automatically turned OFF. There is no command-line flag at this time to override the FEEDBACK setting in run_grid.conf.

Second, when initializing a nested run, you actually have the choice of either using the static data sets (terrain, land use, etc) at the same resolution as the nested domain or interpolating those fields from the parent domain. Should you choose the latter, interpolate from the parent, then your static surface fields in the nest will be at the same resolution as the parent even though the model dynamics will be operating at a higher resolution. In other words, your 10km nested domain will contain 30km terrain data.

Normally, you want to use the static fields at the same resolution as your nested domain. By default, the wrf_run script uses the higher resolution data for the static surface fields in your nested runs. If you decide that you want to interpolate your nest data sets from the parent domain, then you must pass the "--interp" flag to wrf_run.

Finally, you must start a nested run at an hour that coincides with one of the available WRF REAL input file located in the siprd directory. When you previously ran wrf_prep, files were created for each domain at each boundary condition time. In most cases the frequency will be 3-hourly since that is the standard frequency of the data sets used to initialize the primary parent domain. This limits the start times of you nested domains to 00, 03, 06, 09, etc. hours after the start of the primary simulation.

You can still start your nested run at an intermediate forecast hour, such as 01, 02, 04, 05, etc., provided that you pass the "--hiresbc" flag to wrf_prep before running wrf_run. By passing "--hiresbc" to wrf_prep, 1-hourly files will be created for ingestion into the WRF REAL program. If you fail to pass the "--hiresbc" flag to wrf_prep and attempt to start a nest at hour that does not coincide with a boundary condition file then WRF REAL, and consequently, wrf_run will fail.

 

10.6      WRF ARW core nesting and configuration files

The runs/<domain>/conf/wrf_run directory contains configuration files with the default settings for your primary and nested runs. If you look inside the run_physics.conf file you will find the physics options that are available for your run, which may be changed as necessary. Parameters that are designated by (NESTING) can have different settings for each nested domain. The convention by which values are specified is:

PARAMETER = d01, d02, d03, d04, ., dn

Thus, for example:

CU_PHYSICS = 1, 3, 1, 0, 4, 1

Specifies the use of cumulus scheme 1 (Kain-Fritsch) for domains 1 and 3, cumulus scheme 3 (Grell-Devenyi) for domain 2, and NO cumulus scheme (explicit) for domain 4. The final 2 schemes specified (4, 1) will be ignored.

If you do not have enough values specified, for example,

CU_PHYSICS = 1, 3

And you want to run domain 4, then the LAST value specified in the list (3) will be used.

 

10.7      WRF ARW core nesting and wrf_autorun

Executing an ARW core nest with the wrf_autorun script is simple since the script will do most of the work for you. All you need to do, besides making sure the wrf_run configuration files are to your liking, is to edit the conf/wrf_autorun/wrf_autorun.conf file and specify the values for the ACTIVE_NESTS, NEST_INITFH, and NEST_LENGTH. The same rules apply for these parameters and for the "--nests" flag described in the section above.