| WRF EMS User's Guide Chapter 8: Using wrf_post.pl |
Table of Contents
8.1 Introduction
8.2 A summary of wrf_post.pl features
8.3 wrf_post.pl configuration files
8.4 Running wrf_post.pl from the command line
8.5 Commentary and a wrf_post.pl example
8.6 Post processing ARW core nested domains
8.7 Processing WRF forecast files into GRIB 1 format
8.8 Controlling the output of fields to the GRIB file
The wrf_post.pl script is used to post-process WRF model forecasts from either the NMM or ARW cores. By default, the WRF EMS forecast files are in netCDF format on native model levels. The wrf_post.pl script will allow users to create GRIB 1 formatted files containing additional fields and interpolated to isobaric coordinates, which can be processed further and the resultant files shipped to other systems.
8.2 A summary of wrf_post.pl features
To summarize, the wrf_post.pl routine:
• Post-processes WRF model forecasts from either the NMM or ARW cores in netCDF or GRIB 1 format on model native coordinate levels,
• Can be run in both shared and distributed memory environments,
• Can output fields on 47 pressure levels including 2, 3, 5, 10, 20, 30, 50, 70, 75, 100 to 1000 every 25, and 1013 mb,
• Handles forecast files with up to 1-minute temporal frequency,
• Can handle the processing of multiple domains from ARW and NMM core nested simulations independently,
• Is capable of producing model output fields in a variety of formats including GRIB 1, BUFR, GEMPAK grid files, GEMPAK sounding files, BUFKIT, and GRADS,
• Can send processed forecast files to remote systems via FTP, COPY, SCP, or RCP depending on the user's needs.
• Provides special configuration options for sending data to AWIPS systems, and
• Will allow users to fine-tune the frequency of the files being processed into each format.
8.3 wrf_post.pl configuration files
The wrf_post.pl script along with the ancillary Fortran and C programs rely on various configuration files and tables to complete the task of processing your WRF forecast data. These files provide the default wrf_post.pl options and may be edited to meet the needs of the user. Also, note that some of these options can be overridden by command line arguments to wrf_post.
• The wrf_prep.conf and prep_wrfsi.conf files
Master configuration files for wrf_post.pl are located in the wrf/data/conf/config/wrf_post directory. Each time a domain is created with the WRF SI GUI, local copies of these files are placed in the <domain>/conf/wrf_post directory, where users should make any desired changes.
• The wrf_post.conf file
In the absence of any command-line options, wrf_post will use the conf/wrf_post/wrf_post.conf file in determining how to process your WRF forecast files. Current options include processing forecast files into GRIB, GEMPAK, GRADS, BUFR, and BUKIT formats. There are also options for sending files to an AWIPS system or archiving the data. Note that most of the parameters contained in the wrf_post.conf file may be overridden by command line options. Please see "wrf_post --help" or "wrf_post --guide" for more information on the command line options.
• The other configuration files
In addition to the wrf_post.conf file, there are other configuration files in the conf/wrf_post directory used to further your post-processing experience. These files should be reviewed and edited as necessary depending on your post-processing needs. The files are:
post_archive.conf Forecast Archive Options post_awips.conf For shipping your GRIB files to AWIPS post_bufr.conf Convert your WRF forecast files to BUFR format post_grads.conf Options for processing GrADS files post_gempak.conf Options for processing GEMPAK files post_grib.conf Options for processing GRIB 1 files 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).
8.4 Running wrf_post.pl from the command line
The master wrf_post.pl file resides in the wrf/strc ($WRF_STRC) directory. Users are instructed not to run the wrf_post.pl script directly from this directory, but rather, will execute "wrf_post" from one of the domain directories in wrf/runs. The wrf_post file in the domain directory is a link to the master wrf_post.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_post 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_post -help
And for a much more verbose user's guide:
% wrf_post -guide
8.5 Commentary and a wrf_post.pl example
There are no mandatory arguments to wrf_post. So, if you are a minimalist type of person, you might run:
% wrf_post
Next, wrf_post will attempt to read the conf/wrf_post/wrf_post.conf file and proceed with the processing of your WRF forecast files. Fortunately, there are many command-line options available to wrf_post used to override the default settings. So, if the minimalist approach is not for you or you don't enjoy editing a file each time you want to make changes then here is another option:
% wrf_post --grib --nogempak --grads --awips --nobufkit --noarchive
The above command tells wrf_post to override the settings in the wrf_post.conf file and turns on GRIB 1, GrADS, and AWIPS processing, turn off GEMPAK and BUFKIT processing, and turns off file archiving.
8.6 Post processing ARW core nested domains
Following a successful nested simulation with the ARW core, forecast files for each domain will be located in the wrfprd directory with each nest identified by a "_d0#" in the filename. You can process each nest individually by passing the "--domain #" option. For example:
% wrf_post --domain 2 [ other options ]
Passing "--domain 2" as in the above example will process only those files for nested domain #2. In the absence of the "--domain" option wrf_post will default to domain #1. If you have multiple nested domains to process you must run wrf_post multiple times.
You can also turn ON/OFF the post proceeding options for individual domains in the wrf_post.conf file for nested ARW core runs. Those fields designated by "Nested ARW Core" may contain multiple entries separated by a comma. The multiple entries are for use with the domain forecast files output by the ARW core when running synchronous 1- and 2-way nested simulations, where each entry is tied to a specific domain. For example:
GEMPAK = MOAD, Nest1, Nest2, Nest3, ..., NestN
or
GEMPAK = Yes, No, Yes, No
The above example specifies that you want to convert forecast files from Mother of all Domains (MOAD) and nested domain #2 to GEMPAK format, but not nested domains #1 and #3. Remember that you need to tell wrf_post which domain to process by passing the --domain # flag. Not passing this flag defaults to the MOAD when processing. Passing the corresponding command line flag to wrf_post overrides the settings in this file. So, passing "--domain 2 --gempak" will turn ON the gempak processing for nested domain #2.
8.7 Post processing ARW core nested domains
The WRF EMS includes a utility to read the WRF netCDF forecast files and create GRIB 1 formatted files for use with other display software packages. Part of the processing to GRIB 1 format includes the interpolation from model native (either Eta or hybrid sigma) to isobaric coordinates. This interpolation takes place whenever you request GRIB processing of the forecast files.
The WRF post currently can output fields on 47 pressure levels including 2, 3, 5, 10, 20, 30, 50, 70, 75, 100 to 1000 every 25, and 1013 mb. Note that the DEFAULT pressure levels in the WRF EMS package are 5, 20, 50, 75, 100 to 1000 every 25, and 1013 mb (42 total) . More information on controlling the wrf post can be found in section 8.8.
In addition to the interpolation of fields to isobaric coordinates, the GRIB 1 processing includes the generation of many, many diagnostic fields that are not part of the standard WRF forecast file. A list of all the available fields in provided in Appendix C, but for those of you who can't wait here is a subset:
• Accumulated snowfall
• Accumulated rain
• Convective precipitation
• Gridscale precipitation
• Instantaneous dominant precipitation type (Rain, Snow, Ice Pellets, Sleet)
• Cloud top brightness temperature
• Clear air turbulence
• In-flight icing
• Flight restriction
• Ceiling height
• Surface wind gust
• 0-2000ft low level wind sheer
• PBL height
• Composite radar reflectivity
• Lowest level reflectivity
• Surface visibility
FAQ:
Why are the number of grid points and grid spacing in the WRF-NMM GRIB files different from that specified in the SIGUI when creating my NMM computational domain?
ANSWER:
During the writing of the WRF NMM forecast files to GRIB 1 format, the rotated Lat-Lon (Arakawa-E) grid is interpolated to a Lambert Conic Conformal (LCC) projection. The rationale for doing this step is that more display software packages can handle the LCC projection than the Rotated Lat-Lon. In order to accurately capture the native resolution of the NMM domain, additional points must be added on the LCC grid to fill in the mass and momentum points of the staggard Arakawa-E grid. The effect of this interpolation is that the final GRIB 1 files have 2*NX-1 grid points in the E-W direction, where NX is the number of points on the native WRF-NMM domain.
In addition, the grid spacing of the points in the GRIB file will be smaller than that specified by the user with the SIGUI and used in the model simulation; a consequence of adding the additional grid points as described above; however, the "effective resolution" of the GRIB files is the same as that used for the WRF-NMM run. Simply interpolating a forecast to a higher resolution grid does not increase the native resolution of the data. Note that the native grid spacing (DX) of the model simulation can be determined from the information wgrib information by using,
DX native = sqrt (2* DX grib **2).
8.8 Controlling the output of fields to the GRIB files
Users can to tailor the wrf post processor to meet their needs. Currently, the wrfpost has the ability to write data on model native and isobaric coordinates.
The wrf/data/conf/tables/wrf_cntrl.parm.template file controls the fields and levels that are written to the initial GRIB file, which is copied to wrf_cntrl.parm during post processing. Each field written to the initial grib file is controlled by two lines in the file. For example:
(U WIND ON PRESS SFCS) SCAL=(-3.0)
L=(11111 11111 11111 11111 11111 11111 11111 11111 11111 11111 00000 00000)
The first line describes the field and defines the precision of the data written to the grib file.
SCAL defines the precision of the data written out to the GRIB data. Positive values denote decimal scaling (maintain that number of significant digits), while negative values describe binary scaling (precise to 2^{SCAL}; SCAL=-3.0 gives output precise to the nearest 1/8). Higher resolution runs should output the data with more precision when performing complex diagnostics on data involving higher order derivatives (e.g., Q vectors, vorticity advection).
The second line controls the output levels (and whether a field will be created at all) by providing on/off switches for the output.
For multi-level data, the switches (1 = generate, 0 = do not generate) control the output levels, with the lowest pressure level (furthest from ground) controlled by the leftmost element of the string. This ordering can be reversed by using 2's in place of 1's; 2's apply the switches from the ground up. For isobaric data the levels being switched on and off correspond to the pressure values. For single level data, the leftmost number is used as the switch (1 = generate, 0 = do not generate).
The WRF post currently can output fields on 47 pressure levels including 2, 3, 5, 10, 20, 30, 50, 70, 75, 100 to 1000 every 25, and 1013 mb. The DEFAULT pressure levels in the WRF EMS are 5, 20, 50, 75, 100 to 1000 every 25, and 1013 mb (42 total).
EXAMPLES (assuming LSM=47, with pressure level values as defined above):
(MESINGER MEAN SLP ) SCAL=(-0.1)
L=(10000 00000 00000 00000 00000 00000 00000 00000 00000 0000)
(TEMP ON PRESS SFCS ) SCAL=(-3.0)
L=(00101 01011 11111 11111 11111 11111 11111 11111 11111 11000 00000 00000)
(TEMP ON PRESS SFCS) SCAL=(-3.0)
L=(00000 00000 11111 11111 11111 11111 11111 11111 11111 00000 00000)
(TEMP ON PRESS SFCS) SCAL=(-3.0)
L=(22222 22222 22222 22222 22222 22222 22222 00000 00000 00000)
(SPEC HUM ON MDL SFCS) SCAL= (2.7)
L=(22220 00000 00000 00000 00000 00000 00000 00000 00000)
Translations:
The first output field is a special sea level pressure reduction designed for use with the NAM model. SCAL=-0.1 specifies that the value is stored to a precision of 2^ {-0.1}, or pretty close to the nearest Pa
The second example is isobaric temperature. The leading 0's turn off output of this field on the 2, 3, 10, 30, and 70mb levels. This is the WRF EMS default setting.
The third example removes the temperature fields on the 2, 3, 5, 10, 20, 30, 50, 70, 75, and 100mb levels. The subsequent 1's turn on output between 125 mb and 1013 mb. SCAL=-3.0 writes out the data to the nearest 0.125.
The forth output field is identical to the second, but by using 2's instead of 1's it is clearer that output is being generated for the 14 output pressure levels closest to the ground.
The fifth output field is for specific humidity on model surfaces. The 2's indicate that the output switches are working from the ground up. Thus, data will be written for the four lowest model surfaces above ground. SCAL=2.7 will retain 2-3 significant digits (higher levels of precision create larger GRIB files, fractional values approach the precision of the next higher integer value but store fewer bits).