Table of Contents

11.1   Nesting with the NMM core
11.2   General guidance for nesting with the NMM core
11.3   Using the SI GUI to configure a NMM core nested simulation
11.4   Running the wrf_autonest.pl routine

 

11.1      Nesting with the NMM core

As of WRF release 2.1.2, the official NMM core does not support nesting. This limitation is likely to change in the near future, but until then, the WRF EMS does include a method by which simple 1-way asynchronous nesting may be accomplished. This method is similar to that of the WS Eta in which the parent domain provides the initial and boundary conditions for the nested domain.

The steps for running an NMM core nested simulation are described in the following sections; however, the basic steps include:

1. Configure your nested domains with the SI GUI.
2. Run the wrf_prep script to setup a simulation.
3. Edit the wrf_run configuration files for a simulation.
4. Run the wrf_run script option to initialize and run your simulation.
5. Run the wrf_post script to post process the forecast files.
6. Use the post processed grib 1 and wrf_prep file to initialize an inner domain.
7. Repeat steps 2-6 until you run out of domains or patience.

Executing the above steps for a NMM nested run will quickly help you become familiar with running the WRF EMS package; however, it does become tedious and does not lend itself to real-time forecasting. Consequently, the wrf_autopost.pl routine is provided to assist you in running an NMM nested simulation. Additional information on using the wrf_autopost.pl routine is provided in Chapter 7.

From the description above, it should be apparent to the user that setting up and running an NMM nested simulation is similar to setting up and running a series of separate runs. The difference is that the initial and boundary condition data used for a nested domain come from the forecast files of a parent domain, and that each of the nested domains must reside completely within a parent domain.

 

11.2      General guidance for nesting with the NMM core

a. This nesting method requires the user to setup multiple (2+) domains using the SI GUI. DO NOT use the nesting configuration capability in the GUI, but rather, the user must configure multiple individual domains, just as if you were creating multiple non-nested runs.

b. Note that a child domain must fit entirely with the parent domain. Seems obvious but problems and questions do arise.

c. You can have an infinite number of domains. Go ahead and try it.

e. You can use this routine to make nested runs with the ARW core although it is not the officially sanctioned method. Heck, you can even do a NMM -> ARW -> NMM -> ARW nest.

f. When making a run that will provide the initial and boundary conditions for a nested domain, it is recommended that output forecast files are at a high temporal frequency. I recommend at least every hour. The STRC EMS package has been modified to handle 1-minute BCs. This task took some effort!

g. After creating an infinite number of domains, you will have to configure each domain separately to meet your needs. This task can take a while so start with less than an infinite number of domains until you gain some experience.

h. You can post process and ship forecast files from intermediate runs to wherever you want for display.

i. A limitation of this method is the amount of time required to process the forecast files from a parent run in preparation for a nest. If your output frequency is high, and it should be, it takes a while to convert the netCDF files to GRIB and then process the GRIB files for the nest.

 

j. While not necessary, it is recommended that you use the autopost option on another workstation to process and prepare the forecast files from a parent domain while it is running. This step will speed up the transition from one domain to the next.

 

11.3      Using the SI GUI to configure a NMM core nested simulation

As stated above, the NMM nested run is merely a series of quasi-independent 1-way simulations. Thus, when setting up your NMM nested simulation you will simply create multiple NMM core domains with the SI GUI. The steps in using the SI GUI to create a NMM domain is provided in Chapter 5. Note that the user must create more than one domain wherein any nested domains reside completely within the area defined by the parent. You can not use the method of creating nested domains as described in Chapter 10.

 

11.4      Running wrf_run for an ARW core nested simulation

The wrf_autonest.pl routine is developed to facilitate the running of nested simulations with the NMM core. During installation of the WRF EMS, a crontab entry is made (deactivated) that can be used for real-time nested runs.

The wrf_autonest.pl routine can also be run from the command line, although unlike most other simulations, there is no domain directory from which to run the simulation. You can execute wrf_autonest.pl anywhere from the command line with:

% wrf_autonest.pl --verbose --config /path/wrf_autonest.conf

The "--config" option flag is mandatory and specifies the name and location of the configuration file, which should be created and edited prior to running a simulation. A sample configuration file resides in the wrf/data/conf/config/wrf_autonest directory and may be used to define your nested run. If you want to create multiple nested runs, simply copy this file and configure accordingly. This file can have any name and be located anywhere provided that it is accessible to the wrf_autonest.pl script when passing the "--conf </path/thisfile>" flag.

There is only one parameter to specify in the configuration file, but it is important since it defines the names of the directories containing the names of the parent and nested domains.

DOMAINS = dom1,dom2[:INITFH][:LENGTH],dom3[:INITFH][:LENGTH],...,domn[:INITFH][:LENGTH ]

Where INITFH is the forecast hour for the parent simulation to use as the 00-hour forecast in the nest, and LENGTH is the forecast length in hours.

DOMAINS is an ordered list of domains that make up the nested simulation. Each domain must be created and localized with the WRF SI GUI; however, they do not need to be of the same WRF core. All domains must reside within the $WRF_RUN directory.

The first domain in the list is the parent of all domains. The wrf_autonest.pl routine will run each domain in the list in succession. Should one domain fail the nested run will terminate.

The domains are separated by a comma (,) while user options for the initial forecast hour and length are separated by a colon (:). Note that the values for the initialization hour of a nested run refer to the data from the parent domain.

Here are a few examples:

DOMAINS = nmm,nmm01,nmm02

In the above example, wrf_autonest.pl will execute wrf_autorun.pl on the $WRF_RUN/nmm domain and then use the forecast files to initialize a run over nmm01, and then nmm02 .

The length of both the nmm01 and nmm02 runs will be the same as nmm, which is defined in $WRF_RUN/nmm/conf/wrf_autorun/wrf_autorun.conf.

The boundary condition frequency will be the same as the output frequency from the parent domain, which is defined in $WRF_RUN/<parent domain>/conf/wrf_run/run_io.conf. This information will be calculated by the wrf_autonest.pl script.

DOMAINS = nmm,nmm01:03:12,nmm02:00:12

The above example is similar to the first, except that the initial nest (nmm01) will be initialized from the nmm run 3-hour forecast, thus, if nmm's 00-hour forecast is at 12 UTC, NMM's 00-hour forecast will be 15 UTC. The nmm01 domain will be a 12 hour forecast or to the end of the available NMM forecast files, whichever is shorter. The nmm02 run will be initialized from the nmm01 00-hour forecast and also be run over the same period as nmm01 .

DOMAINS = arw,nmm01:03:12,arw_small:00:12

Just like example (2) except run "arw" domain followed by "nmm01", and then "arw_small".