The WRF Preprocessing System (WPS) is a set of three programs whose collective role is to prepare input to the real program for real-data simulations. Each of the programs performs one stage of the preparation: geogrid defines model domains and interpolates static geographical data to the grids; ungrib extracts meteorological fields from GRIB-formatted files; and metgrid horizontally interpolates the meteorological fields extracted by ungrib to the model grids defined by geogrid. The work of vertically interpolating meteorological fields to WRF eta levels is now performed within the real program, a task that was performed by the vinterp program in the WRF SI.

The data flow between the programs of the WPS is shown in the figure above. Each of the WPS programs reads parameters from a common namelist file, as shown in the figure. This namelist file has separate namelist records for each of the programs and a shared namelist record, which defines parameters that are used by more than one WPS program. Not shown in the figure are additional table files that are used by individual programs. These tables provide additional control over the programs’ operation, though they generally do not need to be changed by the user. The GEOGRID.TBL and METGRID.TBL files are explained later in this document, though for now, the user need not be concerned with them.
The build mechanism for the WPS, which is very similar to the build mechanism used by the WRF model, provides options for compiling the WPS on a variety of platforms. When MPICH libraries and suitable compilers are available, the metgrid and geogrid programs may be compiled for distributed memory execution, which allows large model domains to be processed in less time. The work performed by the ungrib program is not amenable to parallelization, so ungrib may only be run on a single processor.
The WPS consists of three independent programs: geogrid, ungrib, and metgrid. Also included in the WPS are several utility programs, which are described in the section on utility programs. A brief description of each of the three main programs is given below, with further details presented in subsequent sections.
The purpose of geogrid is to define the simulation domains, and interpolate various terrestrial data sets to the model grids. The simulation domains are defined using information specified by the user in the “geogrid” namelist record of the WPS namelist file, namelist.wps. By default – and in addition to computing the latitude, longitude, and map scale factors at every grid point – geogrid will interpolate soil categories, land use category, terrain height, annual mean deep soil temperature, monthly vegetation fraction, monthly albedo, maximum snow albedo, and slope category to the model grids. Global data sets for each of these fields are provided through the WRF download page, and only need to be downloaded once. Several of the data sets are available in only one resolution, but others are made available in resolutions of 30”, 2’, 5’, and 10’; here, " denotes arc seconds and ' denotes arc minutes. The user need not download all available resolutions for a data set, although the interpolated fields will generally be more representative if a resolution of data near to that of the simulation domain is used. However, users who expect to work with domains having grid spacings that cover a large range may wish to eventually download all available resolutions of the terrestrial data.
Besides interpolating the default terrestrial fields, the geogrid program is general enough to be able to interpolate most continuous and categorical fields to the simulation domains. New or additional data sets may be interpolated to the simulation domain through the use of the table file, GEOGRID.TBL. The GEOGRID.TBL file defines each of the fields that will be produced by geogrid; it describes the interpolation methods to be used for a field, as well as the location on the file system where the data set for that field is located.
Output from geogrid is written in the WRF I/O API format, and thus, by selecting the NetCDF I/O format, geogrid can be made to write its output in NetCDF for easy visualization using external software packages, including ncview and the new release of RIP4.
The ungrib program reads GRIB files, "degribs" the data, and writes the data in a simple format, called the intermediate format (see the section on writing data to the intermediate format for details of the format). The GRIB files contain time-varying meteorological fields and are typically from another regional or global model, such as NCEP's NAM or GFS models. The ungrib program can read GRIB Edition 1 and GRIB Edition 2 files.
GRIB files typically contain more fields than are needed to initialize WRF. Both versions of the GRIB format use various codes to identify the variables and levels in the GRIB file. Ungrib uses tables of these codes – called Vtables, for "variable tables" – to define which fields to extract from the GRIB file and write to the intermediate format. Details about the codes can be found in the WMO GRIB documentation and in documentation from the originating center. Vtables for common GRIB model output files are provided with the ungrib software.
Vtables are provided for NAM 104 and 212 grids, the NAM AWIP format, GFS, the NCEP/NCAR Reanalysis archived at NCAR, RUC (pressure level data and hybrid coordinate data), AFWA's AGRMET land surface model output, ECMWF, and other data sets. Users can create their own Vtable for other model output using any of the Vtables as a template; further details on the meaning of fields in a Vtable are provided in the section on creating and editing Vtables.
Ungrib can write intermediate data files in any one of three user-selectable formats: WPS – a new format containing additional information useful for the downstream programs; SI – the previous intermediate format of the WRF system; and MM5 format, which is included here so that ungrib can be used to provide GRIB2 input to the MM5 modeling system. Any of these formats may be used by WPS to initialize WRF, although the WPS format is recommended.
The metgrid program horizontally interpolates the intermediate-format meteorological data that are extracted by the ungrib program onto the simulation domains defined by the geogrid program. The interpolated metgrid output can then be ingested by the WRF real program. The range of dates that will be interpolated by metgrid are defined in the “share” namelist record of the WPS namelist file, and date ranges must be specified individually in the namelist for each simulation domain. Since the work of the metgrid program, like that of the ungrib program, is time-dependent, metgrid is run every time a new simulation is initialized.
Control over how each meteorological field is interpolated is provided by the METGRID.TBL file. The METGRID.TBL file provides one section for each field, and within a section, it is possible to specify options such as the interpolation methods to be used for the field, the field that acts as the mask for masked interpolations, and the grid staggering (e.g., U, V in ARW; H, V in NMM) to which a field is interpolated.
Output from metgrid is written in the WRF I/O API format, and thus, by selecting the NetCDF I/O format, metgrid can be made to write its output in NetCDF for easy visualization using external software packages, including the new version of RIP4.
The WRF Preprocessing System uses a build mechanism similar to that used by the WRF model. External libraries for geogrid and metgrid are limited to those required by the WRF model, since the WPS uses the WRF model's implementations of the WRF I/O API; consequently, WRF must be compiled prior to installation of the WPS so that the I/O API libraries in the WRF external directory will be available to WPS programs. Additionally, the ungrib program requires three compression libraries for GRIB Edition 2 support; however, if support for GRIB2 data is not needed, ungrib can be compiled without these compression libraries.
The only library that is required to build the WRF model is NetCDF. The user can find the source code, precompiled binaries, and documentation at the UNIDATA home page (http://www.unidata.ucar.edu/software/netcdf/). Most users will select the NetCDF I/O option for WPS due to the easy access to utility programs that support the NetCDF data format, and before configuring the WPS, users should ensure that the environment variable NETCDF is set to the path of the NetCDF installation.
Where WRF adds a software layer between the model and the communications package, the WPS programs geogrid and metgrid make MPI calls directly. Most multi-processor machines come preconfigured with a version of MPI, so it is unlikely that users will need to install this package by themselves.
Three libraries are required by
the ungrib program for GRIB Edition 2 compression support. Users are encouraged
to engage their system administrators for the installation of these packages so
that traditional library paths and include paths are maintained. Paths to
user-installed compression libraries are handled in the configure.wps file by the COMPRESSION_LIBS and COMPRESSION_INC variables.
1) JasPer (an implementation of
the JPEG2000 standard for "lossy" compression)
http://www.ece.uvic.ca/~mdadams/jasper/
Go down to “JasPer software”, one
of the "click here" parts is the source.
>
./configure
>
make
>
make install
Note: The GRIB2 libraries expect
to find include files in "jasper/jasper.h", so it may be necessary to
manually create a "jasper" subdirectory in the "include"
directory created by the JasPer installation, and manually link header files
there.
2) PNG (compression library for
"lossless" compression)
http://www.libpng.org/pub/png/libpng.html
Scroll down to "Source
code" and choose a mirror site.
>
./configure
>
make check
>
make install
3) zlib (a compression library
used by the PNG library)
Go to "The current release is
publicly available here" section and download.
>
./configure
>
make
>
make install
To get around portability issues,
the NCEP GRIB libraries, w3 and g2, have been included in the WPS distribution.
The original versions of these libraries are available for download from NCEP
at http://www.nco.ncep.noaa.gov/pmb/codes/GRIB2/.
The specific tar files to download are g2lib and w3lib. Because the ungrib
program requires modules from these files, they are not suitable for usage with
a traditional library option during the link stage of the build.
The WPS requires the same Fortran and C compilers as were used to build the WRF model, since the WPS executables link to WRF's I/O API libraries. After executing the ./configure command in the WPS directory, a list of supported compilers on the current system architecture are presented.
>
ls
-rw-r--r-- 1
563863 WPS.TAR.gz
drwxr-xr-x
18 4096 WRFV3
>
gzip -d WPSV3.TAR.gz
>
tar xf WPSV3.TAR
>
ls
drwxr-xr-x 7 4096 WPS
-rw-r--r-- 1
3491840 WPSV3.TAR
drwxr-xr-x
18 4096 WRFV3
>
cd WPS
>
./configure
o Choose one of the configure options
>
./compile >& compile.output
> ls
drwxr-xr-x 2 4096 arch
-rwxr-xr-x 1 1672 clean
-rwxr-xr-x
1 3510 compile
-rw-r--r--
1 85973 compile.output
-rwxr-xr-x
1 4257 configure
-rw-r--r--
1 2486 configure.wps
drwxr-xr-x
4 4096 geogrid
lrwxrwxrwx
1 23 geogrid.exe
-> geogrid/src/geogrid.exe
-rwxr-xr-x 1 1328 link_grib.csh
drwxr-xr-x 3 4096 metgrid
lrwxrwxrwx 1 23 metgrid.exe ->
metgrid/src/metgrid.exe
-rw-r--r--
1 1101 namelist.wps
-rw-r--r--
1 1987
namelist.wps.all_options
-rw-r--r--
1 1075 namelist.wps.global
-rw-r--r--
1 652 namelist.wps.nmm
-rw-r--r--
1 4786 README
drwxr-xr-x
4 4096 ungrib
lrwxrwxrwx
1 21 ungrib.exe
-> ungrib/src/ungrib.exe
drwxr-xr-x 3 4096 util
There are essentially three main steps to running the WRF Preprocessing System:
1. Define a model coarse domain and any nested domains with geogrid.
2. Extract meteorological fields from GRIB data sets for the simulation period with ungrib.
3. Horizontally interpolate meteorological fields to the model domains with metgrid.
When multiple simulations are to be run for the same model domains, it is only necessary to perform the first step once; thereafter, only time-varying data need to be processed for each simulation using steps two and three. Similarly, if several model domains are being run for the same time period using the same meteorological data source, it is not necessary to run ungrib separately for each simulation. Below, the details of each of the three steps are explained.
In the root of the WPS directory structure, symbolic links to the programs geogrid.exe, ungrib.exe, and metgrid.exe should exist if the WPS software was successfully installed. In addition to these three links, a namelist.wps file should exist. Thus, a listing in the WPS root directory should look something like:
> ls
drwxr-xr-x 2 4096 arch
-rwxr-xr-x 1 1672 clean
-rwxr-xr-x
1 3510 compile
-rw-r--r--
1 85973 compile.output
-rwxr-xr-x
1 4257 configure
-rw-r--r--
1 2486 configure.wps
drwxr-xr-x
4 4096 geogrid
lrwxrwxrwx
1 23 geogrid.exe
-> geogrid/src/geogrid.exe
-rwxr-xr-x 1 1328 link_grib.csh
drwxr-xr-x 3 4096 metgrid
lrwxrwxrwx 1 23 metgrid.exe ->
metgrid/src/metgrid.exe
-rw-r--r--
1 1101 namelist.wps
-rw-r--r--
1 1987
namelist.wps.all_options
-rw-r--r--
1 1075 namelist.wps.global
-rw-r--r--
1 652 namelist.wps.nmm
-rw-r--r--
1 4786 README
drwxr-xr-x
4 4096 ungrib
lrwxrwxrwx
1 21 ungrib.exe
-> ungrib/src/ungrib.exe
drwxr-xr-x 3 4096 util
The model coarse domain
and any nested domains are defined in the “geogrid” namelist record of the
namelist.wps file, and, additionally, parameters in the “share” namelist record
need to be set. An example of these two namelist records is given below, and
the user is referred to the description of
namelist variables for more information on the purpose and possible values
of each variable.
&share
wrf_core = 'ARW',
max_dom = 2,
start_date = '2008-03-24_12:00:00','2008-03-24_12:00:00',
end_date = '2008-03-24_18:00:00','2008-03-24_12:00:00',
interval_seconds = 21600,
io_form_geogrid = 2
/
&geogrid
parent_id = 1, 1,
parent_grid_ratio = 1, 3,
i_parent_start = 1, 31,
j_parent_start = 1, 17,
s_we = 1, 1,
e_we = 74, 112,
s_sn = 1, 1,
e_sn = 61, 97,
geog_data_res = '10m','2m',
dx = 30000,
dy = 30000,
map_proj = 'lambert',
ref_lat = 34.83,
ref_lon = -81.03,
truelat1 = 30.0,
truelat2 = 60.0,
stand_lon = -98.,
geog_data_path = '/mmm/users/wrfhelp/WPS_GEOG/'
/
To summarize a set of
typical changes to the “share” namelist record relevant to geogrid, the WRF
dynamical core must first be selected with wrf_core. If WPS is being run
for an ARW simulation, wrf_core should be set to 'ARW', and if running for an NMM simulation, it
should be set to 'NMM'.
After selecting the dynamical core, the total number of domains (in the case of
ARW) or nesting levels (in the case of NMM) must be chosen with max_dom. Since geogrid produces
only time-independent data, the start_date, end_date, and interval_seconds variables are ignored
by geogrid. Optionally, a location (if not the default, which is the current
working directory) where domain files should be written to may be indicated
with the opt_output_from_geogrid_path variable, and the format of these domain files
may be changed with io_form_geogrid.
In the “geogrid”
namelist record, the projection of the simulation domain is defined, as are the
size and location of all model grids. The map projection to be used for the
model domains is specified with the map_proj variable, and the namelist variables used to
set the parameters of the projection are summarized in the table below.
|
Map projection / value
of map_proj |
Projection parameters |
|
'lambert' |
truelat1 truelat2 (optional) stand_lon |
|
'mercator' |
truelat1 |
|
'polar' |
truelat1 stand_lon |
|
'lat-lon' |
pole_lat pole_lon stand_lon |
If WRF is to be run for
a regional domain configuration, the location of the coarse domain is
determined using the ref_lat and ref_lon variables, which specify the latitude and longitude,
respectively, of the center of the coarse domain. If nested domains are to be
processed, their locations with respect to the parent domain are specified with
the i_parent_start
and j_parent_start
variables; further details of setting up nested domains are provided in the
section on nested domains. Next, the dimensions
of the coarse domain are determined by the variables dx and dy, which specify the
nominal grid distance in the x-direction and y-direction, and e_we and e_sn, which give the number
of velocity points (i.e., u-staggered or v-staggered points) in the x- and
y-directions; for the 'lambert', 'mercator', and 'polar' projections, dx and dy are given in meters, and for the 'lat-lon' projection, dx and dy are given in degrees.
For nested domains, only the variables e_we and e_sn are used to determine the dimensions of the
grid, and dx
and dy
should not be specified for nests, since their values are determined
recursively based on the values of the parent_grid_ratio and parent_id variables, which
specify the ratio of a nest's parent grid distance to the nest's grid distance
and the grid number of the nest's parent, respectively.
For global WRF
simulations, the coverage of the coarse domain is, of course, global, so ref_lat and ref_lon do not apply, and dx and dy should not be
specified,
since the nominal grid distance is computed automatically based on the number
of grid points. Also, it should be noted that the latitude-longitude (map_proj
= 'lat-lon') is
the only projection in WRF that can support a global domain.
Besides setting
variables related to the projection, location, and coverage of model domains,
the path to the static geographical data sets must be correctly specified with
the geog_data_path
variable. Also, the user may select which resolution of static data geogrid
will interpolate from using the geog_data_res variable, whose value should match one
of the resolutions of data in the GEOGRID.TBL. If the full set of static data
are downloaded from the WRF download page, possible resolutions include '30s', '2m', '5m', and '10m', corresponding to
30-arc-second data, 2-, 5-, and 10-arc-second data.
Depending on the value
of the wrf_core
namelist variable, the appropriate GEOGRID.TBL file must be used with geogrid,
since the grid staggerings that WPS interpolates to differ between dynamical
cores. For the ARW, the GEOGRID.TBL.ARW file should be used, and for the NMM,
the GEOGRID.TBL.NMM file should be used. Selection of the appropriate
GEOGRID.TBL is accomplished by linking the correct file to GEOGRID.TBL in the
geogrid directory (or in the directory specified by opt_geogrid_tbl_path, if this variable is
set in the namelist).
>
ls geogrid/GEOGRID.TBL
lrwxrwxrwx 1 15 GEOGRID.TBL -> GEOGRID.TBL.ARW
For more details on the
meaning and possible values for each variable, the user is referred to a description of the namelist variables.
Having suitably defined
the simulation coarse domain and nested domains,
the geogrid.exe executable may be run to produce domain files. In the case of
ARW domains, the domain files are named geo_em.d0N.nc, where N is the number of the
nest defined in each file. When run for NMM domains, geogrid produces the file geo_nmm.d01.nc for the coarse domain,
and geo_nmm_nest.l0N.nc
files for each nesting level N. Also, note that the file suffix will vary depending on the
io_form_geogrid
that is selected. To run geogrid, issue the following command:
>
./geogrid.exe
When geogrid.exe has
finished running, the message
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
! Successful completion of
geogrid. !
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
should be printed, and a
listing of the WPS root directory (or the directory specified by opt_output_from_geogrid_path, if not this variable
was set) should show the domain files. If not, the geogrid.log file may be
consulted in an attempt to determine the possible cause of failure. For more
information on checking the output of geogrid, the user is referred to the
section on checking WPS output.
> ls
drwxr-xr-x 2 4096 arch
-rwxr-xr-x 1 1672 clean
-rwxr-xr-x
1 3510 compile
-rw-r--r--
1 85973 compile.output
-rwxr-xr-x
1 4257 configure
-rw-r--r--
1 2486
configure.wps
-rw-r--r--
1 1957004 geo_em.d01.nc
-rw-r--r--
1 4745324 geo_em.d02.nc
drwxr-xr-x
4 4096 geogrid
lrwxrwxrwx
1 23
geogrid.exe -> geogrid/src/geogrid.exe
-rw-r--r--
1 11169 geogrid.log
-rwxr-xr-x
1 1328
link_grib.csh
drwxr-xr-x
3 4096 metgrid
lrwxrwxrwx
1 23
metgrid.exe -> metgrid/src/metgrid.exe
-rw-r--r--
1 1094
namelist.wps
-rw-r--r--
1 1987
namelist.wps.all_options
-rw-r--r--
1 1075
namelist.wps.global
-rw-r--r--
1 652
namelist.wps.nmm
-rw-r--r--
1 4786 README
drwxr-xr-x
4 4096 ungrib
lrwxrwxrwx
1 21
ungrib.exe -> ungrib/src/ungrib.exe
drwxr-xr-x 3 4096 util
Having already downloaded meteorological data in GRIB format, the first step in extracting fields to the intermediate format involves editing the “share” and “ungrib” namelist records of the namelist.wps file – the same file that was edited to define the simulation domains. An example of the two namelist records is given below.
&share
wrf_core = 'ARW',
max_dom = 2,
start_date = '2008-03-24_12:00:00','2008-03-24_12:00:00',
end_date = '2008-03-24_18:00:00','2008-03-24_12:00:00',
interval_seconds = 21600,
io_form_geogrid = 2
/
&ungrib
out_format = 'WPS',
prefix = 'FILE'
/
In the “share” namelist
record, the variables that are of relevance to ungrib are the starting and
ending times of the coarse domain (start_date and end_date; alternatively,
start_year, start_month, start_day, start_hour, end_year, end_month, end_day, and end_hour) and the interval
between meteorological data files (interval_seconds). In the “ungrib”
namelist record, the variable out_format is used to select the format of the
intermediate data to be written by ungrib; the metgrid program can read any of
the formats supported by ungrib, and thus, any of 'WPS', 'SI', and 'MM5' may be specified for out_format, although 'WPS' is recommended. Also in
the "ungrib" namelist, the user may specify a path and prefix for the
intermediate files with the prefix variable. For example, if prefix were set to 'ARGRMET', then the intermediate
files created by ungrib would be named according to AGRMET:YYYY-MM-DD_HH, where YYYY-MM-DD_HH is the valid time of
the data in the file.
After suitably modifying
the namelist.wps file, a Vtable must be supplied, and the GRIB files must be
linked (or copied) to the filenames that are expected by ungrib. The WPS is
supplied with Vtable files for many sources of meteorological data, and the
appropriate Vtable may simply be symbolically linked to the file Vtable, which
is the Vtable name expected by ungrib. For example, if the GRIB data are from
the GFS model, this could be accomplished with
>
ln -s ungrib/Variable_Tables/Vtable.GFS Vtable
The ungrib program will
try to read GRIB files named GRIBFILE.AAA, GRIBFILE.AAB, …, GRIBFILE.ZZZ. In
order to simplify the work of linking the GRIB files to these filenames, a
shell script, link_grib.csh, is provided. The link_grib.csh script takes as a
command-line argument a list of the GRIB files to be linked. For example, if
the GRIB data were downloaded to the directory /data/gfs, the files could be
linked with link_grib.csh as follows:
>
ls /data/gfs
-rw-r--r--
1 42728372 gfs_080324_12_00
-rw-r--r--
1 48218303 gfs_080324_12_06
>
./link_grib.csh /data/gfs/gfs*
After linking the GRIB
files and Vtable, a listing of the WPS directory should look something like the
following:
> ls
drwxr-xr-x 2 4096 arch
-rwxr-xr-x 1 1672 clean
-rwxr-xr-x
1 3510 compile
-rw-r--r--
1 85973 compile.output
-rwxr-xr-x
1 4257 configure
-rw-r--r--
1 2486
configure.wps
-rw-r--r--
1 1957004 geo_em.d01.nc
-rw-r--r--
1 4745324 geo_em.d02.nc
drwxr-xr-x
4 4096 geogrid
lrwxrwxrwx
1 23
geogrid.exe -> geogrid/src/geogrid.exe
-rw-r--r--
1 11169 geogrid.log
lrwxrwxrwx
1 38 GRIBFILE.AAA ->
/data/gfs/gfs_080324_12_00
lrwxrwxrwx
1 38
GRIBFILE.AAB -> /data/gfs/gfs_080324_12_06
-rwxr-xr-x 1 1328 link_grib.csh
drwxr-xr-x 3 4096 metgrid
lrwxrwxrwx 1 23
metgrid.exe -> metgrid/src/metgrid.exe
-rw-r--r--
1 1094
namelist.wps
-rw-r--r--
1 1987
namelist.wps.all_options
-rw-r--r--
1 1075
namelist.wps.global
-rw-r--r--
1 652
namelist.wps.nmm
-rw-r--r--
1 4786 README
drwxr-xr-x
4 4096 ungrib
lrwxrwxrwx
1 21
ungrib.exe -> ungrib/src/ungrib.exe
drwxr-xr-x 3 4096 util
lrwxrwxrwx 1 33 Vtable
-> ungrib/Variable_Tables/Vtable.GFS
After editing the
namelist.wps file and linking the appropriate Vtable and GRIB files, the
ungrib.exe executable may be run to produce files of meteorological data in the
intermediate format. Ungrib may be run by simply typing the following:
>
./ungrib.exe >& ungrib.output
Since the ungrib program
may produce a significant volume of output, it is recommended that ungrib
output be redirected to a file, as in the command above. If ungrib.exe runs
successfully, the message
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
! Successful completion of
ungrib. !
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
will be written to the end of the ungrib.output file, and the intermediate files should appear in the current working directory. The intermediate files written by ungrib will have names of the form FILE:YYYY-MM-DD_HH (unless, of course, the prefix variable was set to a prefix other than 'FILE').
> ls
drwxr-xr-x 2 4096 arch
-rwxr-xr-x 1 1672
clean
-rwxr-xr-x
1
3510 compile
-rw-r--r--
1 85973
compile.output
-rwxr-xr-x
1
4257 configure
-rw-r--r--
1
2486 configure.wps
-rw-r--r--
1 154946888 FILE:2008-03-24_12
-rw-r--r--
1 154946888 FILE:2008-03-24_18
-rw-r--r--
1 1957004
geo_em.d01.nc
-rw-r--r--
1 4745324
geo_em.d02.nc
drwxr-xr-x
4
4096 geogrid
lrwxrwxrwx
1 23 geogrid.exe
-> geogrid/src/geogrid.exe
-rw-r--r--
1 11169
geogrid.log
lrwxrwxrwx
1 38 GRIBFILE.AAA
-> /data/gfs/gfs_080324_12_00
lrwxrwxrwx
1 38 GRIBFILE.AAB
-> /data/gfs/gfs_080324_12_06
-rwxr-xr-x 1 1328
link_grib.csh
drwxr-xr-x 3 4096
metgrid
lrwxrwxrwx 1
23 metgrid.exe -> metgrid/src/metgrid.exe
-rw-r--r--
1
1094 namelist.wps
-rw-r--r--
1
1987 namelist.wps.all_options
-rw-r--r--
1
1075 namelist.wps.global
-rw-r--r--
1
652 namelist.wps.nmm
-rw-r--r--
1
4786 README
drwxr-xr-x
4
4096 ungrib
lrwxrwxrwx
1 21 ungrib.exe
-> ungrib/src/ungrib.exe
-rw-r--r--
1
1418 ungrib.log
-rw-r--r--
1 27787
ungrib.output
drwxr-xr-x 3 4096 util
lrwxrwxrwx 1
33 Vtable -> ungrib/Variable_Tables/Vtable.GFS
In the final step of running the WPS, meteorological data extracted by ungrib are horizontally interpolated to the simulation grids defined by geogrid. In order to run metgrid, the namelist.wps file must be edited. In particular, the “share” and “metgrid” namelist records are of relevance to the metgrid program. Examples of these records are shown below.
&share
wrf_core = 'ARW',
max_dom = 2,
start_date = '2008-03-24_12:00:00','2008-03-24_12:00:00',
end_date = '2008-03-24_18:00:00','2008-03-24_12:00:00',
interval_seconds = 21600,
io_form_geogrid = 2
/
&metgrid
fg_name
= 'FILE',
io_form_metgrid
= 2,
/
By this point, there is generally no need to change any of the variables in the “share” namelist record, since those variables should have been suitably set in previous steps. If the "share" namelist was not edited while running geogrid and ungrib, however, the WRF dynamical core, number of domains, starting and ending times, interval between meteorological data, and path to the static domain files must be set in the “share” namelist record, as described in the steps to run geogrid and ungrib.
In the “metgrid” namelist record, the path and prefix of the intermediate meteorological data files must be given with fg_name, the full path and file names of any intermediate files containing constant fields may be specified with the constants_name variable, and the output format for the horizontally interpolated files may be specified with the io_form_metgrid variable. Other variables in the “metgrid” namelist record, namely, opt_output_from_metgrid_path and opt_metgrid_tbl_path, allow the user to specify where interpolated data files should be written by metgrid and where the METGRID.TBL file may be found.
As with geogrid and the
GEOGRID.TBL file, a METGRID.TBL file appropriate for the WRF core must be
linked in the metgrid directory (or in the directory specified by opt_metgrid_tbl_path, if this variable is
set).