Chapter 7: NCEP WRF Postprocessor v2.2
o Controlling
which variables wrfpost outputs
o Controlling
which levels wrfpost outputs
o Overview
of the steps in scripts to run the WRF Postprocessor
o GEMPAK
o GrADS
The NCEP
WRF Postprocessor was designed to interpolate both WRF-NMM and WRF-ARW output
from their native grids to National Weather Service (NWS) standard levels
(pressure, height, etc.) and standard output grids (AWIPS, Lambert Conformal,
polar-stereographic, etc.) in NWS and World Meteorological Organization (WMO)
GRIB format. This package also provides an option to output fields on the
model’s native vertical levels.
The adaptation
of the original WRF Postprocessor package and User’s Guide (by Mike
Baldwin of NSSL/CIMMS and Hui-Ya Chuang of NCEP/EMC) was done by Lígia
Bernardet (NOAA/FSL/DTC) in collaboration with Dusan Jovic (NCEP/EMC), Robert
Rozumalski (COMET), Wesley Ebisuzaki (NWS/HQTR), and Louisa Nance (NCAR/DTC). The
upgrade to WRF Postprocessor Version 2.2 was performed by Hui-ta Chuang and
Dusan Jovic (NCEP/EMC).
The WRF Postprocessor v2.2 is compatible with WRF v2.2 and above
and can be used to post-process both WRF-ARW and WRF-NMM forecasts. The WRF Postprocessor can ingest WRF
history files (wrfout*) in two formats: netCDF and binary. The section “Setting
up the WRF model to interface with the WRF Postprocessor”
describes how to setup the WRF model to ensure compatibility with the WRF Postprocessor.
The WRF Postprocessor is divided into two parts:
1. Wrfpost
·
Interpolates the forecasts from the
model’s native vertical coordinate to NWS standard output levels
(pressure, height, etc.) and computes mean sea level pressure. If the requested
parameter is on a model’s native level, then no vertical interpolation is
performed.
·
Computes diagnostic output quantities
(e.g. convective available potential energy, helicity, radar reflectivity,
etc.). A list of fields that can be generated by wrfpost is shown in Table
1.
·
Outputs the results in NWS and WMO
standard GRIB1 format (for GRIB documentation, see http://www.nco.ncep.noaa.gov/pmb/docs/).
·
Destaggers the WRF-ARW forecasts
(description below).
·
Outputs two navigation files, copygb_nav.txt
and copygb_hwrf.txt for WRF-NMM. These files can be used as input for copygb.
Ø
copygb_nav.txt: This
file contains the GRID GDS of a Lambert Conformal Grid similar in domain and
grid spacing to the one used to run the WRF model. The Lambert Conformal map
projection works well for mid-latitudes.
Ø
copygb_hwrf.txt:
This file contains the GRID GDS of a Latitude-Longitude Grid similar in domain
and grid spacing to the one used to run the WRF model. The latitude-longitude
grid works well for tropics.
2. Copygb
·
Destaggers the WRF-NMM forecasts
(description below).
·
Interpolates the forecasts horizontally
from their native grid to a standard AWIPS or user-defined grid.
·
Outputs the results in NWS and WMO
standard GRIB1 format (for GRIB documentation, see http://www.nco.ncep.noaa.gov/pmb/docs/).
When posting (step 1 above) forecasts computed by the WRF-ARW, wrfpost
interpolates the velocity variables to the mass points of the WRF-ARW native
C-grid, which is equivalent to an A-grid representation. Since the A-grid is a regular
non-staggered grid, output from wrfpost, WRF-ARW can be displayed
directly by most display codes without going through copygb (step 2
above). On the other hand, no
de-staggering is applied when posting WRF-NMM forecasts. Therefore, the posted
WRF-NMM output is still on the staggered native E-grid and must go through copygb
to be interpolated to a regular non-staggered grid.
In addition to wrfpost and copygb, a utility called ndate
is distributed with the WRF Postprocessor tarfile. This utility is used to format the dates
of the forecasts to be posted for ingestion by the codes.
The WRF Postprocessor v2.2 has been tested on IBM and LINUX
platforms. For LINUX, the Portland Group (PG) compiler has been used. Only wrfpost
(step 1) is parallelized because it requires several 3-dimensional arrays (the
model’s history variables) for the computations. When running wrfpost on more than one
processor, the last processor will be designated as an I/O node, while the rest
of the processors are designated as computational nodes. For example, if three processors are
requested to run the wrfpost, only the first two
processors will be used for computation, while the third processor will be used
to write output to GRIB files.
One limitation of the current version of the WRF Postprocessor is
that only one forecast time can be processed per execution.
Expanding “wrfpost_v2.2.tar” creates a
main directory wrfpostprocV2 and five subdirectories:
sorc: contains source codes for wrfpost,
ndate,
and copygb.
scripts: contains sample running scripts
run_wrfpost: run wrfpost and copygb.
run_wrfpostandgempak: run wrfpost, copygb, and GEMPAK to
plot various fields.
run_wrfpostandgrads: run wrfpost, copygb, and GrADS to plot
various fields.
lib: contains source code subdirectories
for the WRF Postprocessor libraries and is the directory where the WRF Postprocessor
compiled libraries will reside.
w3lib: Library for coding and decoding data in
GRIB format
Note: The version of this library included in
this package is Endian- independent and can be used on LINUX and IBM systems.
iplib: General interpolation library (see lib/iplib/iplib.doc)
splib: Spectral transform library (see lib/splib/splib.doc)
wrfmpi_stubs:
Contains some C and FORTRAN codes to genereate libmpi.a
library. It supports MPI implementation for LINUX applications.
parm: Contains the parameter
files, which can be modified by the user to control how the post processing is
performed.
exec: Location of executables after
compilation.
The wrfpost program is currently set up to read a large number of
fields from the WRF model history files.
This configuration stems from NCEP's need to generate all of its
required operational products.
Lists of the fields that are currently read in by wrfpost for WRF-NMM and
WRF-ARW are provided in Tables 2 and 3, respectively. This program is configured such that is
will run successfully if an expected input field is missing from the WRF
history file as long as this field is not required to produce a requested
output field. If the pre-requisites
for a requested output field are missing from the WRF history file, wrfpost
will abort at run time. For
example, if isobaric state fields are requested, but the pressure fields on
model interfaces (PINT for WRF-NMM and PB and P for WRF-ARW) are not available
in the history file, wrfpost will abort at run time. The fields written to the WRF history
file are controlled by the settings in the Registry file (see the Registry.EM
and Registry.NMM
files in the Registry subdirectory of the main WRFV2 directory). Note that it is necessary to re-compile
the WRF model source code after modifying the appropriate Registry file. Also note that the wrfout files must contain
only one frame per file.
Table
2.List of all possible
fields read in by wrfpost for the
WRF-NMM:
|
T |
SFCEXC |
NRDSW |
|
U |
VEGFRC |
ARDSW |
|
V |
ACSNOW |
ALWIN |
|
Q |
ACSNOM |
ALWOUT |
|
CWM |
CMC |
NRDLW |
|
F_ICE |
SST |
ARDLW |
|
F_RAIN |
EXCH_H |
ALWTOA |
|
F_RIMEF |
EL_MYJ |
ASWTOA |
|
W |
THZ0 |
TGROUND |
|
PINT |
QZ0 |
SOILTB |
|
PT |
UZ0 |
TWBS |
|
PDTOP |
VZ0 |
SFCSHX |
|
FIS |
QS |
NSRFC |
|
SMC |
Z0 |
ASRFC |
|
SH2O |
PBLH |