Table of Contents

7.1   Introduction
7.2   A summary of wrf_run.pl features
7.3   wrf_run.pl configuration files
7.4   Running wrf_run.pl from the command line
7.5   Running the WRF in shared and distributed memory
7.6   Configuring a workstation for distributed memory simulations
7.7   A few wrf_run.pl examples
7.8   Using the "--autopost" option

 

7.1     Introduction

The purpose of the wrf_run.pl script is to; 1) read the files output from wrf_prep.pl; 2) run the wrf real.exe program to create the initial and boundary condition files for the primary and nested domains; and 3) and execute either the NMM or ARW core of the model. The final output from wrf_run.pl are WRF forecast files in either GRIB 1 or netCDF format, which may be processed further by wrf_post.pl. More information about wrf_post.pl is provided in Chapter 8.

 

7.2      A summary of wrf_run.pl features

To summarize, the wrf_run.pl routine:

•  Is easily configured to run a local cluster on individual workstations,

•  Runs either the NMM or ARW core in shared or distributed memory,

•  Takes input from well-documented user configuration files rather than namelists,

•  Will automatically select model timesteps for both the ARW and NMM cores as a function of grid spacing,

•  Runs the NMM and ARW WRF REAL programs to create initial and boundary condition files,

•  Outputs WRF forecast files in either netCDF or GRIB 1 format (ARW only),

•  Supports 1- (ARW and NMM core) and 2-way nesting (ARW core), and

•  Has an option for synchronous post processing of forecast files.

 

7.3      wrf_run.pl configuration files

The wrf_run.pl script along with the ancillary Fortran and C programs rely on various configuration files to process the initial and boundary conditions and execute the ARW or NMM core. If you are familiar with the other WRF packages, then you should know that all model configuration is done through these configuration files and not namelist files. If you are not familiar with namelist files then don't worry about it.

The master configuration files for wrf_run.pl are located in the wrf/data/conf/config/wrf_run directory. Each time a computational domain is created with the WRF SI GUI program, local copies of these files are placed in the in the <domain>/conf/wrf_run directory, which is where all of the local configuration should take place. Note that the default configuration files are sufficient to run either ARW or NMM core out of the box, i.e, no changes are necessary if a user wants to test the model.

Eventually, the user will not want to leave well enough alone, at which time you might want to look at the available configuration files:

wrf_run.conf	Primary user options file for wrf_run.pl
run_io.conf	WRF EMS I/O Options
run_physics.conf	WRF EMS Physics Options
run_dynamics.conf	WRF EMS Dynamics Options
run_grid.conf	WRF EMS Domain Options
run_DMrun.conf	WRF EMS Distributed Memory Options

Feel free to peruse all of the configuration options available to you. If the list seems daunting, don't worry about it. Each file is reasonably well-documented with suggestions on how to set each parameter (lots of hand-holding and love; well, a little love). Files are preconfigured to run either core out of the box; however, if want to make some changes to the model it is recommended that you start with the run_physics.conf file, which contains the available physics options. If you run the NMM core your choices are limited so make sure you read the configuration suggestions provided.

 

7.4      Running wrf_run.pl from the command line

The master wrf_run.pl file resides in the wrf/strc ($WRF_STRC) directory. Users are instructed not to run the wrf_run.pl script directly from this directory, but rather, will execute "wrf_run" from one of the domain directories in wrf/runs. The wrf_run file in the domain directory is a link to the master wrf_run.pl file in the strc directory, so any changes made to the local file will be made to the master file as well.

As with all of the WRF EMS run-time scripts, wrf_run has a built in help menu and user's guide. The help menu provides a brief summary of the available options. To view the brief help menu:

% wrf_run -help

And for a much more verbose user's guide:

% wrf_run -guide

The run_info command is another utility that may be of interest to the user. Executing "run_info" from the command line provides information about the current model configuration:

% run_info

 

7.5      Running the WRF in shared and distributed memory

The WRF EMS package includes statically linked NMM and ARW binaries for both shared (SM) and distributed (DM) memory systems. Both sets of executables should run on any relatively current Linux system provided that your system is configured correctly (easy). Also included with the WRF EMS package are all of the necessary MPICH binaries and libraries for running in distributed memory. Almost all of the difficult work has been done for you (more hand holding) so that you can begin running simulations more quickly.

Which memory environment should you use? Well, as it turns out, both! Tests show that the SM binaries are up to 100x(!) faster for running the WRF REAL program to create the initial and boundary condition files, while the DM binaries improve performance by 10-20% on a multi-CPU workstation. If you are running the WRF EMS on a cluster then you must run the DM binaries, but you probably are aware of that fact already.

 

7.6      Configuring a workstation for distributed memory simulations

Setting up a multi-CPU workstation to run the WRF EMS DM binaries is relatively simple; however, it may require that you have root privilege on your system. Here are the basic steps involved:

1. Make sure you have the ssh deamon installed and enabled on each machine that you plan to use, even if you are running on just one workstation. Also make sure that you have passwordless ssh enabled on all of the machines.

2. Test to see if you are configured correctly by running:

% ssh <machine> date

If the above command returns the date without asking for a password then you are good to go; otherwise you may need to do some further configuration. If the above command fails, here are some things to check:

1. Is the ssh daemon installed and activated on your system(s)?

2. Do you have authorization to run sshd in the system(s) /etc/hosts.allow file?

3. Are you configured to do passwordless ssh on your system? If not, you may need to set it up:

% mkdir ~/.ssh If it does not exist.

% ssh-keygen -t dsa -f ~/.ssh/id_dsa -N "" Note the ""

% cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys2

% rm -f ~/.ssh/id_dsa.pub

% ssh-keyscan -t rsa <machine name>,<ip addr> > ~/.ssh/known_hosts

% ssh `hostname` date

 

7.7      Running the WRF in shared and distributed memory

There are no mandatory flags that you need to pass to wrf_run, so you can execute a simulation with just:

% wrf_run  

Executing the above command will create the initial and boundary conditions and then run the model in shared memory (default) for a length of time dictated by the input files created while running wrf_prep. If you requested 24 hours worth of initial and boundary condition files then your forecast length will be 24 hours. When the simulation is finished, all of the forecast files are placed in the "wrfprd" directory and the domain directory is cleaned of ancillary files and directories.

% wrf_run --length 12h

The above command will override the default WRF forecast length and run the model out to 12 hours, provided that you have processed at least 12 hours worth of boundary conditions. If you have only processed 6 hours worth of boundary condition files then the run will be for 6 hours.

% wrf_run --DM

The above command will run both WRF REAL and the model in distributed memory. If you are running on a cluster make sure that you have configured the <domain>/conf/wrf_run/run_DMrun.conf file. You can also set distributed memory to be the default in the wrf_run.conf file.    

% wrf_run --SMDM

The above command will run WRF REAL in shared memory and then the model in distributed memory. This is the fastest combination, so if you are setup for DM runs use this as the default in <domain>/conf/wrf_run/wrf_run.conf .   Again, if you are running on a cluster make sure that you have configured your run_DMrun.conf file. You can also set the shared/distributed memory to be the default.

% wrf_run --nowrf

Run only the WRF REAL program and then exit before running the model. This option is good for testing and troubleshooting.

 

7.8      Using the "--autopost" option

Passing the "--autopost" flag initiates synchronous or concurrent post processing of the WRF forecast files as they are being produced by the model, i.e,

% wrf_run --autopost

Sounds intoxicating, doesn't it? Now, before you attempt this option, it is strongly recommended that you follow some parental-type guidance.

First, you will need to make sure that the wrf_post.pl (chapter 8) configuration files are just the way you like them and that you read and edit the wrf_autopost.conf file located in the <domain>/conf/wrf_autorun directory.

Second, running wrf_autopost.pl concurrent with the model on the same machine will severely degrade the performance of the run. If you are thinking about using the autopost option, and I know that you are, it is strongly recommended that you locate and configure a second machine for this task. It is easy to do and the wrf_autopost.pl code will do all of the dirty work. You will need to complete the following steps:

1. Find a second 1 or 2 CPU linux machine with at least 512mb memory.

2. Make sure sshd is running on the second machine and that you have permission to run sshd.

3. Setup a user on machine #2 with the same user info as the machine running WRF.

4. NFS mount the $WRF directory on machine #1 to the same location on machine #2, i.e, /usr1/wrf on machine #1 must be the same as /usr1/wrf on machine #2.

5. Configure the machines so that the user can ssh from machine #1 to machine #2 WITHOUT a password. If the user can execute

% machine#1-> ssh date <machine #2>

without a password, then you are good to go.

6. Enter the hostname of machine #2 in the wrf_autopost.conf file.