text:
Узнать больше о подписке Scribd
Откройте для себя все, что может предложить Scribd, включая книги и аудиокниги от крупных издательств.
A RW Version 3 Modeling System User's Guide January 2017
Mesoscale & Microscale Meteorology Division • National Center for Atmospheric Research! ForewordThis User's Guide describes the Advanced Research WRF (ARW) Version 3.8 modelingsystem, released in April 2016. As the ARW is developed further, this document will becontinuously enhanced and updated. Please send feedback to firstname.lastname@example.com.
• WRF model: Physics: o New Kain-Fritsch cumulus potential scheme (contributed by PNNL); o A new option for aerosol-radiation interaction (aer_opt = 3) (contributed by G. Thompson and T. Eidhammer of RAL/NCAR); o Improvement to various physics options; o Updated cloud fraction scheme (icloud =3); o WRF-Hydro 4.0 (contributed by the WRF-Hydro group of RAL/NCAR) Others: o A flux-adjusting surface data nudging option; o Improved vertical refinement (contributed K. Lundquist of LLNL); o 30-seconds GMTED2010 topography dataset. • WRF-DA updates: o New observation type: AMSR-2 radiance (contributed by Xin Li, Jie Ming, Ming Xue, Yuan Wang, and Kun Zhao of Nanjing University, China) o New dynamic constraint for 3DVAR and Hybrid DA (contributed by Syed Rizvi of NCAR and Chun Yang of Nanjing University of Information Science & Technology, China) • WRF-Chemistry o Dust scheme improvement (contributed by Martina Klose of Univ. of Cologne and New Mexico State Univ.).
For the latest version of this document, please visit the ARW Users' Web site athttp://www2.mmm.ucar.edu/wrf/users/.
1. Overview − Introduction ................................................................................. 1-1 − The WRF Modeling System Program Components ..................... 1-2
2. Software Installation − Introduction .................................................................................. 2-1 − Required Compilers and Scripting Languages ............................. 2-2 − Required/Optional Libraries to Download .................................... 2-3 − Post-Processing Utilities............................................................... 2-4 − UNIX Environment Settings ......................................................... 2-4 − Building the WRF Code ................................................................ 2-5 − Building the WPS Code ................................................................ 2-6 − Building the WRFDA Code (for 3DVAR) ...................................... 2-7 − Building the WRFDA Code (for 4DVAR) …………………………...2-9
4. WRF Initialization − Introduction ................................................................................. 4-1 − Initialization for Ideal Cases ........................................................ 4-3 − Initialization for Real Data Cases ................................................ 4-6
5. WRF Model − Introduction ................................................................................ 5-1 − Installing WRF ............................................................................ 5-2 − Running WRF ............................................................................. 5-8 − Examples of namelists for various applications ........................ 5-35 − Check Output ........................................................................... 5-37 − Trouble Shooting ....................................................................... 5-38 − Physics and Dynamics Options ................................................. 5-38 − Summary of PBL Physics Options………………………………. 5-52 − Summary of Microphysics Options………………………………. 5-54 − Summary of Cumulus Parameterization Options………………. 5-56 − Summary of Radiation Physics Options.................................... 5-57 − Description of Namelist Variables ............................................. 5-60 − WRF Output Fields .................................................................. 5-115 − Special WRF Output Variables.................................................5-122
8. WRF Software − WRF Build Mechanism ................................................................ 8-1 − Registry ....................................................................................... 8-5 − I/O Applications Program Interface (I/O API) ............................ 8-14 − Timekeeping .............................................................................. 8-14 − Software Documentation ........................................................... 8-15 − Performance .............................................................................. 8-15
9. Post-Processing Programs − Introduction ................................................................................. 9-1 − NCL . ........................................................................................... 9-2 − RIP4 ......................................................................................... 9-20 − ARWpost ................................................................................... 9-29 − UPP ......................................................................................... 9-36 − VAPOR ...................................................................................... 9-38
Appendix A: WRF-Fire − Introduction ................................................................................. A-1 − WRF_Fire in idealized cases ...................................................... A-3 − Fire variables in namelist.input ................................................... A-4 − namelist.fire ................................................................................. A-5 − Running WRF_Fire on real data ................................................. A-6
Chapter 1: Overview
Table of Contents
• Introduction • The WRF ARW Modeling System Program Components
The Advanced Research WRF (ARW) modeling system has been in development for thepast few years. The current release is Version 3, available since April 2008. The ARW isdesigned to be a flexible, state-of-the-art atmospheric simulation system that is portableand efficient on available parallel computing platforms. The ARW is suitable for use in abroad range of applications across scales ranging from meters to thousands of kilometers,including:
The WRF modeling system software is in the public domain and is freely available forcommunity use.
The following figure shows the flowchart for the WRF Modeling System Version 3.
As shown in the diagram, the WRF Modeling System consists of these major programs:
This program is used primarily for real-data simulations. Its functions include 1) definingsimulation domains; 2) interpolating terrestrial data (such as terrain, landuse, and soil
types) to the simulation domain; and 3) degribbing and interpolating meteorological datafrom another model to this simulation domain. Its main features include:
• GRIB 1/2 meteorological data from various centers around the world• USGS 24 category and MODIS 20 category land datasets; USGS GTOPO30 elevation dataset; Global 5-minutes United Nation FAO, and North-America STATSGO 30 sec soil category dataset; 10-min greenness fraction data based on AVHRR and 30-sec greenness fraction data based on 10 years MODIS; MODIS- based leaf-area index; 0.15 degree monthly albedo and snow albedo data; and 1- degree deep soil temperature data; plus a few specialized datasets• Map projections for 1) polar stereographic, 2) Lambert-Conformal, 3) Mercator and 4) latitude-longitude• Nesting• User-interfaces to input other static data as well as met data
This program is optional, but can be used to ingest observations into the interpolatedanalyses created by WPS. It can also be used to update WRF model's initial conditionswhen the WRF model is run in cycling mode. Its main features are as follows:
• It is based on an incremental variational data assimilation technique, and has both 3D- Var and 4D-Var capabilities• It also includes the capability of hybrid data assimilation (Variational + Ensemble)• The conjugate gradient method is utilized to minimize the cost function in the analysis control variable space• Analysis is performed on an un-staggered Arakawa A-grid• Analysis increments are interpolated to staggered Arakawa C-grid and it gets added to the background (first guess) to get the final analysis of the WRF-model grid• Conventional observation data input may be supplied either in ASCII format via the "obsproc" utility or "PREPBUFR" format.• Multiple satellite observation data input may be supplied in BUFR format• Multiple radar data (reflectivity & radial velocity) input is supplied through ASCII format• Multiple outer loop to address the nonlinearity• Capability to compute adjoint sensitivity• Horizontal component of the background (first guess) error is represented via a recursive filter (for regional) or power spectrum (for global). The vertical component is applied through projections on climatologically generated averaged eigenvectors and its corresponding Eigen values• Horizontal and vertical background errors are non-separable. Each eigenvector has its own horizontal climatologically-determined length scale• Preconditioning of the background part of the cost function is done via the control variable transform U defined as B= UUT
ARW Solver
This is the key component of the modeling system, which is composed of severalinitialization programs for idealized, and real-data simulations, and the numericalintegration program. The key features of the WRF model include:
Several programs are supported, including RIP4 (based on NCAR Graphics), NCARGraphics Command Language (NCL), and conversion programs for other readilyavailable graphics packages like GrADS.
Program VAPOR, Visualization and Analysis Platform for Ocean, Atmosphere, andSolar Researchers (http://www.vapor.ucar.edu/), is a 3-dimensional data visualizationtool, and it is developed and supported by the VAPOR team at NCAR (firstname.lastname@example.com).
The details of these programs (with the exception of the MET program) are describedmore in the later chapters of this user's guide. See the above link for information aboutMET.
• Introduction • Required Compilers and Scripting Languages • Required/Optional Libraries to Download • Post-Processing Utilities • UNIX Environment Settings • Building the WRF Code • Building the WPS Code • Building the WRFDA Code (for 3DVAR) • Building the WRFDA Code (for 4DVAR)
The WRF modeling system software installation is fairly straightforward on the portedplatforms listed below. The model-component portion of the package is mostly self-contained. The WRF model does contain the source code to a Fortran interface to ESMFand the source to FFTPACK . Contained within the WRF system is the WRFDAcomponent, which has several external libraries that the user must install (for variousobservation types and linear algebra solvers). Similarly, the WPS package, separate fromthe WRF source code, has additional external libraries that must be built (in support ofGrib2 processing). The one external package that all of the systems require is thenetCDF library, which is one of the supported I/O API packages. The netCDF librariesand source code are available from the Unidata homepage at http://www.unidata.ucar.edu(select DOWNLOADS, registration required).
There are three tar files for the WRF code. The first is the WRF model (including thereal and ideal pre-processors). The second is the WRFDA code. The third tar file is forWRF chemistry. In order to run the WRF chemistry code, both the WRF model and thechemistry tar file must be combined.
The WRF model has been successfully ported to a number of Unix-based machines. Wedo not have access to all of them and must rely on outside users and vendors to supply therequired configuration information for the compiler and loader options. Below is a list ofthe supported combinations of hardware and software for WRF.
The majority of the WRF model, WPS, and WRFDA codes are written in Fortran (whatmany refer to as Fortran 90). The software layer, RSL, which sits between WRF andWRFDA, and the MPI interface is written in C. WPS makes direct calls to the MPIlibraries for distributed memory message passing. There are also ancillary programs thatare written in C to perform file parsing and file construction, which are required fordefault building of the WRF modeling code. Additionally, the WRF build mechanismuses several scripting languages: including perl, Cshell and Bourne shell. The traditionalUNIX text/file processing utilities are used: make, m4, sed, and awk. See Chapter 8:WRF Software (Required Software) for a more detailed listing of the necessary pieces forthe WRF build.
The only library that is always required is the netCDF package from Unidata (login >Downloads > NetCDF). Most of the WRF post-processing packages assume that the datafrom the WRF model, the WPS package, or the WRFDA program are using the netCDFlibraries. One may also need to add '/path-to-netcdf/netcdf/bin' to their path so that theymay execute netCDF utility commands, such as ncdump. Use a netCDF version that is3.6.1 or later. To utilize the compression capabilities, use netCDF 4.0 or later. Note thatcompression will require the use of HDF5.
Note 1: If one wants to compile WRF system components on a Linux or Darwin systemthat has access to multiple compilers, link the correct external libraries. For example, donot link the libraries built with PathScale when compiling the WRF components withgfortran. Even more, the same options when building the netCDF libraries must be usedwhen building the WRF code (32 vs 64 bit, assumptions about underscores in the symbolnames, etc.).
Note 2: If netCDF-4 is used, be sure that it is installed without activating parallel I/Obased on HDF5. The WRF modeling system is able to use either the classic data modelfrom netCDF-3 or the compression options supported in netCDF-4.
If you are going to be running distributed memory WRF jobs, you need a version of MPI.You can pick up a version of mpich, but you might want your system group to install thecode. A working installation of MPI is required prior to a build of WRF using distributedmemory. Either MPI-1 or MPI-2 are acceptable. Do you already have an MPI lyingaround? Try
which mpif90 which mpicc which mpirun
If these are all defined executables in your path, you are probably OK. Make sure yourpaths are set up to point to the MPI lib, include, and bin directories. As with thenetCDF libraries, you must build MPI consistently with the WRF source code.
Note that to output WRF model data in Grib1 format, Todd Hutchinson (WSI) hasprovided a complete source library that is included with the software release. However,when trying to link the WPS, the WRF model, and the WRFDA data streams together,always use the netCDF format.
Note 3: The entire step-by-step recipe for building the WRF and WPS packages isavailable at: http://www2.mmm.ucar.edu/wrf/OnLineTutorial/compilation_tutorial.phpThis page includes complete turn-key directions, from tests of your machines's utilitiesall the way up through where to download real-time data.
Post-Processing Utilities
The more widely used (and therefore supported) WRF post-processing utilities are:
There are only a few environmental settings that are WRF system related. Most of theseare not required, but when things start acting badly, test some out. In Cshell syntax:
• setenv WRF_EM_CORE 1 o explicitly defines which model core to build • setenv WRF_NMM_CORE 0 o explicitly defines which model core NOT to build • setenv WRF_DA_CORE 0 o explicitly defines no data assimilation • setenv NETCDF /usr/local/netcdf (or wherever you have it stored) o all of the WRF components want both the lib and the include directories • setenv OMP_NUM_THREADS n (where n is the number of procs to use)
o if you have OpenMP on your system, this is how to specify the number of threads • setenv MP_STACK_SIZE 64000000 o OpenMP blows through the stack size, set it large o However, if the model still crashes, it may be a problem of over- specifying stack size. Set stack size sufficiently large, but not unlimited. o On some systems, the equivalent parameter could be KMP_STACKSIZE, or OMP_STACKSIZE • unlimit o especially if you are on a small system
The WRF code has a fairly complicated build mechanism. It tries to determine thearchitecture that you are on, and then presents you with options to allow you to select thepreferred build method. For example, if you are on a Linux machine, it determineswhether this is a 32 or 64 bit machine, and then prompts you for the desired usage ofprocessors (such as serial, shared memory, or distributed memory). You select fromamong the available compiling options in the build mechanism. For example, do notchoose a PGI build if you do not have PGI compilers installed on your system.
An instructional web site describes the sequence of steps required to build the WRF andWPS codes (though the instructions are specifically given for tcsh and GNU compilers).
The WRF code supports a parallel build option, an option that compiles separate sourcecode files in the WRF directories at the same time on separate processors (though thoseprocessors need to share memory) via a parallel make. The purpose of the parallel buildoption is to be able to speed-up the time required to construct executables. In practice,users typically see approximately a 2x speed-up, a limit imposed by the variousdependencies in the code due to modules and USE association. To enable the parallelbuild option, the user sets an environment variable, J. In csh, to utilize two processors,before the ./compile command, issue the following:setenv J "-j 2"Users may wish to only use a single processor for the build. In which case:setenv J "-j 1"
Users wishing to run the WRF chemistry code must first download the WRF model tarfile, and untar it. Then the chemistry code is untar'ed in the WRFV3 directory (this is thechem directory structure). Once the source code from the tar files is combined, thenusers may proceed with the WRF chemistry build.
If you plan to use Grib2 data, additional libraries for zlib, png, and jasper arerequired. Please see details in Chapter 3.
• cd WPS • ./configure o Choose one of the options o Usually, serial builds are the best for an initial test. Most large domains work with a single processor for WPS o WPS requires that you build for the appropriate Grib decoding. Select an option that is suitable for the data you will use with the ungrib program (the Grib2 option will work for either Grib1 or Grib2 data) o If you select a Grib2 option, you must have those libraries prepared and built in advance (see the chapter on WPS for the location of these compression libraries). Add the paths to these libraries and include files using variables COMPRESSION_LIBS and COMPRESSION_INC in configure.wps. Also inside the configure.wps file is the location of the built WRFV3 directory, which needs to be modified. This is how the WPS picks up all of the required IO pieces to build the geogrid.exe and metgrid.exe files. • ./compile • ls -ls *.exe o You should see geogrid.exe, ungrib.exe, and metgrid.exe (if you are missing both geogrid.exe and metgrid.exe, you probably need to fix where the path to WRF is pointing in the configure.wps file; if you are missing ungrib.exe, try a Grib1-only build to further isolate the problem)
• ls -ls util/*.exe o You should see a number of utility executables: avg_tsfc.exe, calc_ecmwf_p.exe, g1print.exe, g2print.exe, height_ukmo.exe, mod_levs.exe, plotfmt.exe, plotgrids.exe, and rd_intermediate.exe (files requiring NCAR Graphics are plotfmt.exe and plotgrids.exe) • If geogrid.exe and metgrid.exe executables are missing, the path to the built WRFV3 directory structure is probably incorrect (found inside the configure.wps file) • If the ungrib.exe is missing, the Grib2 libraries are probably not linked or built correctly • If the plotfmt.exe or the plotgrids.exe programs is missing, the NCAR Graphics path is probably set incorrectly
WRFDA uses the same build mechanism as WRF; thus, this mechanism must beinstructed to configure and build the code for WRFDA rather than WRF. Additionally,the paths to libraries needed by WRFDA code must be set, as described in the stepsbelow.
(Note: the latest available CRTM, version 2.1.3, is included in this release version and it will be compiled automatically when the appropriate environmental variable is set. Users do not need to download and install CRTM).
• ./configure wrfda o serial means single processor o dmpar means Distributed Memory Parallel (MPI) o smpar and dm+sm are not recommended for use with WRFDA • WRFDA also supports parallel build. • ./compile all_wrfvar • ls -ls var/build/*.exe o If the compilation was successful, da_wrfvar.exe, da_update_bc.exe, and other executables should be found in the var/build directory. Their links are in the var/da directory; obsproc.exe should be found in the var/obsproc/src directory
• Please refer to above section "Building WRFDA code (for 3DVAR)" to download code and set up necessary environmental variables.
• ./configure 4dvar o serial means single processor o dmpar means Distributed Memory Parallel (MPI)
• ./compile all_wrfvar • ls -ls var/build/*.exe o If the compilation was successful, da_wrfvar.exe, da_update_bc.exe, and other executables should be found in the var/build directory. Their links are in the var/da directory; obsproc.exe should be found in the var/obsproc/src directory
• Introduction • Function of Each WPS Program • Installing the WPS • Running the WPS • Creating Nested Domains with the WPS • Selecting Between USGS and MODIS-based Land Use Data • Selecting Static Data for the Gravity Wave Drag Scheme • Using Multiple Meteorological Data Sources • Using Non-isobaric Meteorological Datasets • Alternative Initialization of Lake SSTs • Parallelism in the WPS • Checking WPS Output • WPS Utility Programs • Writing Meteorological Data to the Intermediate Format • Required Meteorological Fields for Running WRF • Creating and Editing Vtables • Writing Static Data to the Geogrid Binary Format • Creating an Urban Fraction Field from NLCD Data • Description of Namelist Variables • Description of GEOGRID.TBL Options • Description of index Options • Description of METGRID.TBL Options • Available Interpolation Options in Geogrid and Metgrid • Land Use and Soil Categories in the Static Data • WPS Output Fields
The WRF Preprocessing System (WPS) is a set of three programs whose collective role isto prepare input to the real program for real-data simulations. Each of the programsperforms one stage of the preparation: geogrid defines model domains and interpolatesstatic geographical data to the grids; ungrib extracts meteorological fields from GRIB-formatted files; and metgrid horizontally interpolates the meteorological fields extractedby ungrib to the model grids defined by geogrid. The work of vertically interpolatingmeteorological fields to WRF eta levels is performed within the real program.
The data flow between the programs of the WPS is shown in the figure above. Each ofthe 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 sharednamelist 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' operations, though theygenerally do not need to be changed by the user. The GEOGRID.TBL, METGRID.TBL,and Vtable files are explained later in this document, though for now, the user need notbe concerned with them.
The build mechanism for the WPS, which is very similar to the build mechanism used bythe WRF model, provides options for compiling the WPS on a variety of platforms.When MPI libraries and suitable compilers are available, the metgrid and geogridprograms may be compiled for distributed memory execution, which allows large modeldomains to be processed in less time. The work performed by the ungrib program is notamenable to parallelization, so ungrib may only be run on a single processor.
The WPS consists of three independent programs: geogrid, ungrib, and metgrid. Alsoincluded in the WPS are several utility programs, which are described in the section onutility programs. A brief description of each of the three main programs is given below,with further details presented in subsequent sections.
Program geogrid
The purpose of geogrid is to define the simulation domains, and interpolate variousterrestrial data sets to the model grids. The simulation domains are defined usinginformation specified by the user in the "geogrid" namelist record of the WPS namelistfile, namelist.wps. In addition to computing the latitude, longitude, and map scale factorsat every grid point, geogrid will interpolate soil categories, land use category, terrainheight, annual mean deep soil temperature, monthly vegetation fraction, monthly albedo,maximum snow albedo, and slope category to the model grids by default. Global data setsfor each of these fields are provided through the WRF download page, and, because thesedata are time-invariant, they only need to be downloaded once. Several of the data setsare 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 notdownload all available resolutions for a data set, although the interpolated fields willgenerally be more representative if a resolution of data near to that of the simulationdomain is used. However, users who expect to work with domains having grid spacingsthat cover a large range may wish to eventually download all available resolutions of thestatic terrestrial data.
Besides interpolating the default terrestrial fields, the geogrid program is general enoughto 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 useof the table file, GEOGRID.TBL. The GEOGRID.TBL file defines each of the fields thatwill 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 theNetCDF I/O format, geogrid can be made to write its output in NetCDF for easyvisualization using external software packages, including ncview, NCL, and RIP4.
Program ungrib
The ungrib program reads GRIB files, "degribs" the data, and writes the data in a simpleformat called the intermediate format (see the section on writing data to the intermediateformat for details on the format). The GRIB files contain time-varying meteorologicalfields and are typically from another regional or global model, such as NCEP's NAM orGFS models. The ungrib program can read GRIB Edition 1 and, if compiled with a"GRIB2" option, GRIB Edition 2 files.
GRIB files typically contain more fields than are needed to initialize WRF. Both versionsof the GRIB format use various codes to identify the variables and levels in the GRIBfile. Ungrib uses tables of these codes – called Vtables, for "variable tables" – to definewhich fields to extract from the GRIB file and write to the intermediate format. Detailsabout the codes can be found in the WMO GRIB documentation and in documentationfrom the originating center. Vtables for common GRIB model output files are providedwith the ungrib software.
Vtables are provided for NAM 104 and 212 grids, the NAM AWIP format, GFS, theNCEP/NCAR Reanalysis archived at NCAR, RUC (pressure level data and hybridcoordinate data), AFWA's AGRMET land surface model output, ECMWF, and other datasets. Users can create their own Vtable for other model output using any of the Vtables asa template; further details on the meaning of fields in a Vtable are provided in the sectionon 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 isincluded here so that ungrib can be used to provide GRIB2 input to the MM5 modelingsystem. Any of these formats may be used by WPS to initialize WRF, although the WPSformat is recommended.
Program metgrid
Output from metgrid is written in the WRF I/O API format, and thus, by selecting theNetCDF I/O format, metgrid can be made to write its output in NetCDF for easyvisualization using external software packages, including the new version of RIP4.
The WRF Preprocessing System uses a build mechanism similar to that used by the WRFmodel. External libraries for geogrid and metgrid are limited to those required by theWRF model, since the WPS uses the WRF model's implementations of the WRF I/OAPI; consequently, WRF must be compiled prior to installation of the WPS so that the I/OAPI 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 compiledwithout these compression libraries.
Required Libraries
The only library that is required to build the WRF model is NetCDF. The user can findthe 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/Ooption for WPS due to the easy access to utility programs that support the NetCDF dataformat, and before configuring the WPS, users should ensure that the environmentvariable 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-processormachines come preconfigured with a version of MPI, so it is unlikely that users will needto install this package by themselves.
Three libraries are required by the ungrib program for GRIB Edition 2 compressionsupport. Users are encouraged to engage their system administrators for the installation ofthese packages so that traditional library paths and include paths are maintained. Paths touser-installed compression libraries are handled in the configure.wps file by theCOMPRESSION_LIBS and COMPRESSION_INC variables. As an alternative to manuallyediting the COMPRESSION_LIBS and COMPRESSION_INC variables in the configure.wpsfile, users may set the environment variables JASPERLIB and JASPERINC to thedirectories holding the JasPer library and include files before configuring the WPS; forexample, if the JasPer libraries were installed in /usr/local/jasper-1.900.1, onemight use the following commands (in csh or tcsh):
If the zlib and PNG libraries are not in a standard path that will be checked automaticallyby the compiler, the paths to these libraries can be added on to the JasPer environmentvariables; for example, if the PNG libraries were installed in /usr/local/libpng-1.2.29 and the zlib libraries were installed in /usr/local/zlib-1.2.3, one might use
> ./configure
> make > make install
Note: The GRIB2 libraries expect to find include files in "jasper/jasper.h", so it may benecessary to manually create a "jasper" subdirectory in the "include" directory created bythe JasPer installation, and manually link header files there.
> ./configure > make check > make install
> ./configure > make > make install
To get around portability issues, the NCEP GRIB libraries, w3 and g2, have beenincluded in the WPS distribution. The original versions of these libraries are available fordownload from NCEP at http://www.nco.ncep.noaa.gov/pmb/codes/GRIB2/. The specifictar files to download are g2lib and w3lib. Because the ungrib program requires modulesfrom these files, they are not suitable for usage with a traditional library option during thelink stage of the build.
The WPS requires the same Fortran and C compilers as were used to build the WRFmodel, 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 thecurrent system architecture are presented.
• Download the WPSV3.TAR.gz file and unpack it at the same directory level as WRFV3, as shown below.
> ls -rw-r--r-- 1 563863 WPS.TAR.gz drwxr-xr-x 18 4096 WRFV3
> ls drwxr-xr-x 7 4096 WPS -rw-r--r-- 1 3491840 WPSV3.TAR drwxr-xr-x 18 4096 WRFV3
• At this point, a listing of the current working directory should at least include the directories WRFV3 and WPS. First, compile WRF (see the instructions for installing WRF in Chapter 2). Then, after the WRF executables are generated, change to the WPS directory and issue the configure command followed by the compile command as below.
> cd WPS
• After issuing the compile command, a listing of the current working directory should reveal symbolic links to executables for each of the three WPS programs: geogrid.exe, ungrib.exe, and metgrid.exe. If any of these links do not exist, check the compilation output in compile.output to see what went wrong.
> 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 necessaryto perform the first step once; thereafter, only time-varying data need to be processed foreach simulation using steps two and three. Similarly, if several model domains are beingrun for the same time period using the same meteorological data source, it is notnecessary to run ungrib separately for each simulation. Below, the details of each of thethree 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 theWPS root directory should look something like:
The model coarse domain and any nested domains are defined in the "geogrid" namelistrecord of the namelist.wps file, and, additionally, parameters in the "share" namelistrecord need to be set. An example of these two namelist records is given below, and theuser is referred to the description of namelist variables for more information on thepurpose 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, e_we = 74, 112, e_sn = 61, 97, geog_data_res = 'default','default', 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 foran ARW simulation, wrf_core should be set to 'ARW', and if running for an NMMsimulation, it should be set to 'NMM'. After selecting the dynamical core, the total numberof domains (in the case of ARW) or nesting levels (in the case of NMM) must be chosenwith max_dom. Since geogrid produces only time-independent data, the start_date,end_date, and interval_seconds variables are ignored by geogrid. Optionally, alocation (if not the default, which is the current working directory) where domain filesshould be written to may be indicated with the opt_output_from_geogrid_pathvariable, 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, asare the size and location of all model grids. The map projection to be used for the modeldomains is specified with the map_proj variable. Each of the four possible mapprojections in the ARW are shown graphically in the full-page figure below, and thenamelist variables used to set the parameters of the projection are summarized in thefollowing table.
If the earth's geographic latitude-longitude grid coincides with the computational grid, aglobal ARW domain shows the earth's surface as it is normally visualized on a regularlatitude-longitude grid. If instead the geographic grid does not coincide with the modelcomputational grid, geographical meridians and parallels appear as complex curves. Thedifference is most easily illustrated by way of example. In top half of the figure below,the earth is shown with the geographical latitude-longitude grid coinciding with thecomputational latitude-longitude grid. In the bottom half, the geographic grid (not shown)has been rotated so that the geographic poles of the earth are no longer located at thepoles of the computational grid.
When WRF is to be run for a regional domain configuration, the location of the coarsedomain is determined using the ref_lat and ref_lon variables, which specify thelatitude and longitude, respectively, of the center of the coarse domain. If nested domainsare to be processed, their locations with respect to the parent domain are specified withthe i_parent_start and j_parent_start variables; further details of setting up nesteddomains are provided in the section on nested domains. Next, the dimensions of thecoarse domain are determined by the variables dx and dy, which specify the nominal griddistance in the x-direction and y-direction, and e_we and e_sn, which give the number ofvelocity 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, andfor the 'lat-lon' projection, dx and dy are given in degrees. For nested domains, onlythe variables e_we and e_sn are used to determine the dimensions of the grid, and dx anddy should not be specified for nests, since their values are determined recursively basedon the values of the parent_grid_ratio and parent_id variables, which specify theratio of a nest's parent grid distance to the nest's grid distance and the grid number of thenest's parent, respectively.
If the regular latitude-longitude projection will be used for a regional domain, care mustbe taken to ensure that the map scale factors in the region covered by the domain do notdeviate significantly from unity. This can be accomplished by rotating the projection suchthat the area covered by the domain is located near the equator of the projection, since,for the regular latitude-longitude projection, the map scale factors in the x-direction aregiven by the cosine of the computational latitude. For example, in the figure aboveshowing the unrotated and rotated earth, it can be seen that, in the rotated aspect, NewZealand is located along the computational equator, and thus, the rotation used therewould be suitable for a domain covering New Zealand. As a general guideline forrotating the latitude-longitude projection for regional domains, the namelist parameterspole_lat, pole_lon, and stand_lon may be chosen according to the formulas in thefollowing table.
For global WRF simulations, the coverage of the coarse domain is, of course, global, soref_lat and ref_lon do not apply, and dx and dy should not be specified, since thenominal grid distance is computed automatically based on the number of grid points.Also, it should be noted that the latitude-longitude, or cylindrical equidistant, projection(map_proj = 'lat-lon') is the only projection in WRF that can support a globaldomain. Nested domains within a global domain must not cover any area north ofcomputational latitude +45 or south of computational latitude -45, since polar filters areapplied poleward of these latitudes (although the cutoff latitude can be changed in theWRF namelist).
Besides setting variables related to the projection, location, and coverage of modeldomains, the path to the static geographical data sets must be correctly specified with thegeog_data_path variable. Also, the user may select which resolution of static datageogrid will interpolate from using the geog_data_res variable, whose value shouldmatch one of the resolutions of data in the GEOGRID.TBL. If the complete set of staticdata 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-minutedata.
> ls geogrid/GEOGRID.TBL
For more details on the meaning and possible values for each variable, the user is referredto a description of the namelist variables.
Having suitably defined the simulation coarse domain and nested domains in thenamelist.wps file, the geogrid.exe executable may be run to produce domain files. In thecase of ARW domains, the domain files are named geo_em.d0N.nc, where N is thenumber of the nest defined in each file. When run for NMM domains, geogrid producesthe file geo_nmm.d01.nc for the coarse domain, and geo_nmm_nest.l0N.nc files foreach nesting level N. Also, note that the file suffix will vary depending on theio_form_geogrid that is selected. To run geogrid, issue the following command:
> ./geogrid.exe
should be printed, and a listing of the WPS root directory (or the directory specified byopt_output_from_geogrid_path, if 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 causeof failure. For more information on checking the output of geogrid, the user is referred tothe section on checking WPS output.
> ls drwxr-xr-x 2 4096 arch -rwxr-xr-x 1 1672 clean
Having already downloaded meteorological data in GRIB format, the first step inextracting 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 thesimulation domains. An example of the two namelist records is given below.
&ungrib out_format = 'WPS', prefix = 'FILE'/
In the "share" namelist record, the variables that are of relevance to ungrib are thestarting 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 ofthe intermediate data to be written by ungrib; the metgrid program can read any of theformats supported by ungrib, and thus, any of 'WPS', 'SI', and 'MM5' may be specifiedfor out_format, although 'WPS' is recommended. Also in the "ungrib" namelist, the usermay 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 ungribwould be named according to AGRMET:YYYY-MM-DD_HH, where YYYY-MM-DD_HHis the valid time of the data in the file.
After suitably modifying the namelist.wps file, a Vtable must be supplied, and the GRIBfiles must be linked (or copied) to the filenames that are expected by ungrib. The WPS issupplied with Vtable files for many sources of meteorological data, and the appropriateVtable may simply be symbolically linked to the file Vtable, which is the Vtable nameexpected by ungrib. For example, if the GRIB data are from the GFS model, this could beaccomplished with
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 GRIBfiles to these filenames, a shell script, link_grib.csh, is provided. The link_grib.csh scripttakes as a command-line argument a list of the GRIB files to be linked. For example, ifthe GRIB data were downloaded to the directory /data/gfs, the files could be linked withlink_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
After linking the GRIB files and Vtable, a listing of the WPS directory should looksomething 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
After editing the namelist.wps file and linking the appropriate Vtable and GRIB files, theungrib.exe executable may be run to produce files of meteorological data in theintermediate format. Ungrib may be run by simply typing the following:
Since the ungrib program may produce a significant volume of output, it is recommendedthat ungrib output be redirected to a file, as in the command above. If ungrib.exe runssuccessfully, the message
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ! Successful completion of ungrib. ! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
will be written to the end of the ungrib.output file, and the intermediate files shouldappear in the current working directory. The intermediate files written by ungrib willhave names of the form FILE:YYYY-MM-DD_HH (unless, of course, the prefix variablewas 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
In the final step of running the WPS, meteorological data extracted by ungrib arehorizontally interpolated to the simulation grids defined by geogrid. In order to runmetgrid, 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 areshown below.
&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. Ifthe "share" namelist was not edited while running geogrid and ungrib, however, the WRFdynamical core, number of domains, starting and ending times, interval betweenmeteorological 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 meteorologicaldata files must be given with fg_name, the full path and file names of any intermediatefiles containing constant fields may be specified with the constants_name variable, andthe output format for the horizontally interpolated files may be specified with theio_form_metgrid variable. Other variables in the "metgrid" namelist record, namely,opt_output_from_metgrid_path and opt_metgrid_tbl_path, allow the user tospecify where interpolated data files should be written by metgrid and where theMETGRID.TBL file may be found.
As with geogrid and the GEOGRID.TBL file, a METGRID.TBL file appropriate for theWRF core must be linked in the metgrid directory (or in the directory specified byopt_metgrid_tbl_path, if this variable is set).
> ls metgrid/METGRID.TBL
After suitably editing the namelist.wps file and verifying that the correct METGRID.TBLwill be used, metgrid may be run by issuing the command
> ./metgrid.exe
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ! Successful completion of metgrid. ! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
will be printed. After successfully running, metgrid output files should appear in the WPSroot directory (or in the directory specified by opt_output_from_metgrid_path, if thisvariable was set). These files will be named met_em.d0N.YYYY-MM-DD_HH:mm:ss.nc inthe case of ARW domains, where N is the number of the nest whose data reside in the file,or met_nmm.d01.YYYY-MM-DD_HH:mm:ss.nc in the case of NMM domains. Here, YYYY-MM-DD_HH:mm:ss refers to the date of the interpolated data in each file. If these files donot exist for each of the times in the range given in the "share" namelist record, themetgrid.log file may be consulted to help in determining the problem in running metgrid.
> 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 -rw-r--r-- 1 5217648 met_em.d01.2008-03-24_12:00:00.nc -rw-r--r-- 1 5217648 met_em.d01.2008-03-24_18:00:00.nc -rw-r--r-- 1 12658200 met_em.d02.2008-03-24_12:00:00.nc drwxr-xr-x 3 4096 metgrid lrwxrwxrwx 1 23 metgrid.exe -> metgrid/src/metgrid.exe -rw-r--r-- 1 65970 metgrid.log -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
To run the WPS for nested-domain simulations is essentially no more difficult thanrunning for a single-domain case; the difference with nested-domain simulations is thatthe geogrid and metgrid programs process more than one grid when they are run, ratherthan a single grid for the simulation. In order to specify the size and location of nests, anumber of variables in the namelist.wps file must be given lists of values, one value pernest.
&geogrid parent_id = 1, 1, parent_grid_ratio = 1, 3, i_parent_start = 1, 31, j_parent_start = 1, 17, e_we = 74, 112, e_sn = 61, 97, geog_data_res = 'default','default', 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/'/
The namelist variables that are affected by nests are shown in the (partial) namelistrecords above. The example shows namelist variables for a two-domain run (the coarsedomain plus a single nest), and the effect on the namelist variables generalize to multiplenests in the obvious way: rather than specifying lists of two values, lists of N values mustbe specified, where N is the total number of model grids.
In the above example, the first change to the "share" namelist record is to the max_domvariable, which must be set to the total number of nests in the simulation, including the
coarse domain. Having determined the number of nests, all of the other affected namelistvariables must be given a list of N values, one for each grid. The only other change to the"share" namelist record is to the starting and ending times. Here, a starting and endingtime must be given for each nest, with the restriction that a nest cannot begin before itsparent domain or end after its parent domain; also, it is suggested that nests be givenstarting and ending times that are identical to the desired starting times of the nest whenrunning WPS. This is because the nests get their lateral boundary conditions from theirparent domain, and thus, only the initial time for a nest needs to be processed by WPS,except when grid nudging, also called analysis nudging, is used in WRF. It is importantto note that, when running WRF, the actual starting and ending times for all nests must begiven in the WRF namelist.input file.
The remaining changes are to the "geogrid" namelist record. In this record, the parent ofeach nest must be specified with the parent_id variable. Every nest must be a child ofexactly one other nest, with the coarse domain being its own parent. Related to theidentity of a nest's parent is the nest refinement ratio with respect to its parent, which isgiven by the parent_grid_ratio variable; this ratio determines the nominal gridspacing for a nest in relation to the grid spacing of the its parent.
Next, the lower-left corner of a nest is specified as an (i, j) location in the nest's parentdomain; this is done through the i_parent_start and j_parent_start variables, andthe specified location is given with respect to the unstaggered grid. Finally, thedimensions of each nest, in grid points, are given for each nest using the s_we, e_we,s_sn, and e_sn variables. The nesting setup in our example namelist is illustrated in thefigure above, where it may be seen how each of the above-mentioned variables isdetermined. Currently, the starting grid point values in the south-north (s_sn) and west-east (s_we) directions must be specified as 1, and the ending grid point values (e_sn ande_we) determine, essentially, the full dimensions of the nest; to ensure that the upper-right corner of the nest's grid is coincident with an unstaggered grid point in the parentdomain, both e_we and e_sn must be one greater than some integer multiple of thenesting ratio. Also, for each nest, the resolution (or list or resolutions; see the description
By default, the geogrid program will interpolate land use categories from MODIS IGBP21-category data. However, the user may select an alternative set of land use categoriesbased on the USGS land-cover classification. Although the MODIS-based data contain21 categories of land use, these categories are not a subset of the 24 USGS categories;users interested in the specific categories in either data set can find a listing of the landuse classes in the section on land use and soil categories.
The 24-category USGS-based land use data may be selected instead of the MODIS dataat run-time through the geog_data_res variable in the &geogrid namelist record. This isaccomplished by prefixing each resolution of static data with the string "usgs_30s+". Forexample, in a two-domain configuration, where the geog_data_res variable wouldordinarily be specified as
The effect of this change is to instruct the geogrid program to look, in each entry of theGEOGRID.TBL file, for a resolution of static data with a resolution denoted by'usgs_30s', and if such a resolution is not available, to instead look for a resolutiondenoted by the string following the '+'. Thus, for the GEOGRID.TBL entry for theLANDUSEF field, the USGS-based land use data, which is identified with the string'usgs_30s', would be used instead of the 'default', resolutions (or source) of land-usedata in the example above; for all other fields, the 'default' resolutions would be used forthe first and second. As an aside, when none of the resolutions specified for a domain ingeog_data_res are found in a GEOGRID.TBL entry, the resolution denoted by 'default'will be used.
When changing from the default 21-class MODIS land-use data, the user must alsoensure that the num_land_cat namelist variable is set correctly in &physics namelistrecord in the WRF namelist.input file. For 24-class USGS data, num_land_cat should beset to 24.
The gravity wave drag by orography (GWDO) scheme in the ARW requires ten staticfields from the WPS. In fact, these fields will be interpolated by the geogrid programregardless of whether the GWDO scheme will be used in the model. When the GWDOscheme will not be used, the fields will simply be ignored in WRF, and the user need notbe concerned with the resolution of data from which the fields are interpolated. However,it is recommended that these fields be interpolated from a resolution of source data that isslightly lower (i.e., coarser) in resolution than the model grid; consequently, if theGWDO scheme will be used, care should be taken to select an appropriate resolution ofGWDO static data. Currently, five resolutions of GWDO static data are available: 2-degree, 1-degree, 30-minute, 20-minute, and 10-minute, denoted by the strings '2deg','1deg', '30m', '20m', and '10m', respectively. To select the resolution to interpolatefrom, the user should prefix the resolution specified for the geog_data_res variable inthe "geogrid" namelist record by the string "XXX+", where XXX is one of the fiveavailable resolutions of GWDO static data. For example, in a model configuration with a48-km grid spacing, the geog_data_res variable might typically be specified as
geog_data_res = '10m',
However, if the GWDO scheme were employed, the finest resolution of GWDO staticdata that is still lower in resolution than the model grid would be the 30-minute data, inwhich case the user should specify
geog_data_res = '30m+10m',
If none of '2deg', '1deg', '30m', or '20m' are specified in combination with otherresolutions of static data in the geog_data_res variable, the '10m' GWDO static datawill be used, since it is also designated as the 'default' resolution in the GEOGRID.TBLfile. It is worth noting that, if 10-minute resolution GWDO data are to be used, but adifferent resolution is desired for other static fields (e.g., topography height), the usershould simply omit '10m' from the value given to the geog_data_res variable, sincespecifying
geog_data_res = '10m+30s',
for example, would cause geogrid to use the 10-mintute data in preference to the 30-second data for the non-GWDO fields, such as topography height and land use category,as well as for the GWDO fields.
The metgrid program is capable of interpolating time-invariant fields, and it can alsointerpolate from multiple sources of meteorological data. The first of these capabilitiesuses the constants_name variable in the &metgrid namelist record. This variable may
&metgrid constants_name = '/data/ungribbed/constants/SST_FILE:2006-08-16_12'/
&metgrid constants_name = 'LANDSEA', 'SOILHGT'/
The second metgrid capability – that of interpolating data from multiple sources – may beuseful in situations where two or more complementary data sets need to be combined toproduce the full input data needed by real.exe. To interpolate from multiple sources oftime-varying, meteorological data, the fg_name variable in the &metgrid namelist recordshould be set to a list of prefixes of intermediate files, including path information whennecessary. When multiple path-prefixes are given, and the same meteorological field isavailable from more than one of the sources, data from the last-specified source will takepriority over all preceding sources. Thus, data sources may be prioritized by the order inwhich the sources are given.
As an example of this capability, if surface fields are given in one data source and upper-air data are given in another, the values assigned to the fg_name variable may looksomething like:
&metgrid fg_name = '/data/ungribbed/SFC', '/data/ungribbed/UPPER_AIR'/
To simplify the process of extracting fields from GRIB files, the prefix namelistvariable in the &ungrib record may be employed. This variable allows the user to controlthe names of (and paths to) the intermediate files that are created by ungrib. The utility ofthis namelist variable is most easily illustrated by way of an example. Suppose we wishto work with the North American Regional Reanalysis (NARR) data set, which is splitinto separate GRIB files for 3-dimensional atmospheric data, surface data, and fixed-fielddata. We may begin by linking all of the "3D" GRIB files using the link_grib.cshscript, and by linking the NARR Vtable to the filename Vtable. Then, we may suitablyedit the &ungrib namelist record before running ungrib.exe so that the resultingintermediate files have an appropriate prefix:
out_format = 'WPS', prefix = 'NARR_3D',/
After running ungrib.exe, the following files should exist (with a suitable substitution forthe appropriate dates):
Given intermediate files for the 3-dimensional fields, we may process the surface fieldsby linking the surface GRIB files and changing the prefix variable in the namelist:
&ungrib out_format = 'WPS', prefix = 'NARR_SFC',/
Again running ungrib.exe, the following should exist in addition to the NARR_3D files:
Finally, the fixed file is linked with the link_grib.csh script, and the prefix variable inthe namelist is again set:
&ungrib out_format = 'WPS', prefix = 'NARR_FIXED',/
Having run ungrib.exe for the third time, the fixed fields should be available in additionto the surface and "3D" fields:
For the sake of clarity, the fixed file may be renamed to remove any date information, forexample, by renaming it to simply NARR_FIXED, since the fields in the file are static. Inthis example, we note that the NARR fixed data are only available at a specific time,1979 November 08 at 0000 UTC, and thus, the user would need to set the correct startingand ending time for the data in the &share namelist record before running ungrib on theNARR fixed file; of course, the times should be re-set before metgrid is run.
Given intermediate files for all three parts of the NARR data set, metgrid.exe may be runafter the constants_name and fg_name variables in the &metgrid namelist record areset:
&metgrid constants_name = 'NARR_FIXED', fg_name = 'NARR_3D', 'NARR_SFC'/
Although less common, another situation where multiple data sources would be requiredis when a source of meteorological data from a regional model is insufficient to cover theentire simulation domain, and data from a larger regional model, or a global model, mustbe used when interpolating to the remaining points of the simulation grid.
For example, to use NAM data wherever possible, and GFS data elsewhere, the followingvalues might be assigned in the namelist:
&metgrid fg_name = '/data/ungribbed/GFS', '/data/ungribbed/NAM'/
Then the resulting model domain would use data as shown in the figure below.
If no field is found in more than one source, then no prioritization need be applied bymetgrid, and each field will simply be interpolated as usual; of course, each source shouldcover the entire simulation domain to avoid areas of missing data.
For some data sources, namely ECMWF model-level data and UK Met Office modeldata, the 3-d pressure and/or geopotential height fields can be derived from the surfacepressure and/or surface height fields using an array of coefficients, and the WPS providesutility programs for performing this derivation; see the section on WPS Utility Programsfor more information on the calc_ecmwf_p.exe and height_ukmo.exe programs.
Other meteorological datasets explicitly provide 3-d pressure and geopotential heightfields, and the user must only ensure that these fields exist in the set of intermediate filesprovided to the metgrid.exe program.
The default treatment of sea-surface temperatures – both for oceans and lakes – in themetgrid program involves simply interpolating the SST field from the intermediate filesto all water points in the WRF domain. However, if the lakes that are resolved in theWRF domain are not resolved in the GRIB data, and especially if those lakes aregeographically distant from resolved water bodies, the SST field over lakes will mostlikely be extrapolated from the nearest resolved water bodies in the GRIB data; thissituation can lead to lake SST values that are either unrealistically warm or unrealisticallycold.
Without a higher-resolution SST field for metgrid to use, one alternative to extrapolatingSST values for lakes is to manufacture a "best guess" at the SST for lakes. In the metgridand real programs, this can be done using a combination of a special land use data set thatdistinguishes between lakes and oceans, and a field to be used as a proxy for SST overlakes. A special land use data set is necessary, since WRF's real pre-processing programneeds to know where the manufactured SST field should be used instead of theinterpolated SST field from the GRIB data.
The alternative procedure for initializing lake SSTs is summarized in the following steps:
1. If they have not already been downloaded (either as a separate tar file or as part of the 'full' geographical data tar file), obtain the special land use data sets that distinguish between lakes and oceans. Two such data sets – based on USGS and MODIS land use categories – may be downloaded through the WRF download page. For simplicity, it is recommended to place the two directories in the same directory as the other static geographical data sets (e.g., topo_30s, soiltype_top_30s, etc.) used by geogrid, since doing so will eliminate the need to modify the GEOGRID.TBL file. If the landuse_30s_with_lakes and modis_landuse_21class_30s directories are placed in a location different from the other static data sets, it will be necessary to change the paths to these directories from relative paths to absolute paths in the GEOGRID.TBL file.
would tell geogrid to use the USGS-based land use data for both domains, and to use the 10-minute resolution data for other static fields in domain 1 and the 2-minute resolution data for other static fields in domain 2; for MODIS-based data, usgs_lakes should be replaced by modis_lakes.
Running geogrid should result in output files that use a separate category for inland water bodies instead of the general water category used for oceans and seas. The lake category is identified by the global attribute ISLAKE in the geogrid output files; this attribute should be set to either 28 (in the case of USGS-based data) or 21 (in the case of the MODIS-based data). See, e.g., the list of WPS output fields, where a value of -1 for ISLAKE indicates that there is no separate lake category.
3. After running the ungrib program, use the avg_tsfc.exe utility program to create an intermediate file containing a daily-average surface air temperature field, which will be substituted for the SST field only over lakes by the real program; for more information on the avg_tsfc.exe utility, see the section on WPS utility programs.
4. Before running the metgrid program, add the TAVGSFC file created in the previous step to the specification of constants_name in the &metgrid record of the namelist.wps file.
5. Run WRF's real.exe program as usual after setting the number of land categories (num_land_cat) in the &physics record of the namelist.input file so that it matches the value of the global attribute NUM_LAND_CAT in the metgrid files. If the global attribute ISLAKE in the metgrid files indicates that there is a special land use category for lakes, the real program will substitute the TAVGSFC field for the SST field only over those grid points whose category matches the lake category; additionally, the real program will change the land use category of lakes back to the general water category (the category used for oceans), since neither the LANDUSE.TBL nor the VEGPARM.TBL files contain an entry for a lake category.
If the dimensions of the domains to be processed by the WPS become too large to fit inthe memory of a single CPU, it is possible to run the geogrid and metgrid programs in adistributed memory configuration. In order to compile geogrid and metgrid for distributedmemory execution, the user must have MPI libraries installed on the target machine, andmust have compiled WPS using one of the "DM parallel" configuration options. Upon
successful compilation, the geogrid and metgrid programs may be run with the mpirun ormpiexec commands, or through a batch queuing system, depending on the machine.
As mentioned earlier, the work of the ungrib program is not amenable to parallelization,and, further, the memory requirements for ungrib's processing are independent of thememory requirements of geogrid and metgrid; thus, ungrib is always compiled for asingle processor and run on a single CPU, regardless of whether a "DM parallel"configuration option was selected during configuration.
Each of the standard WRF I/O API formats (NetCDF, GRIB1, binary) has acorresponding parallel format, whose number is given by adding 100 to the io_form value(i.e., the value of io_form_geogrid and io_form_metgrid) for the standard format. It isnot necessary to use a parallel io_form, but when one is used, each CPU will read/writeits input/output to a separate file, whose name is simply the name that would be usedduring serial execution, but with a four-digit processor ID appended to the name. Forexample, running geogrid on four processors with io_form_geogrid=102 would createoutput files named geo_em.d01.nc.0000, geo_em.d01.nc.0001, geo_em.d01.nc.0002, andgeo_em.d01.nc.0003 for the coarse domain.
When running the WPS, it may be helpful to examine the output produced by theprograms. For example, when determining the location of nests, it may be helpful to seethe interpolated static geographical data and latitude/longitude fields. As anotherexample, when importing a new source of data into WPS – either static data ormeteorological data – it can often be helpful to check the resulting interpolated fields inorder to make adjustments the interpolation methods used by geogrid or metgrid.
By using the NetCDF format for the geogrid and metgrid I/O forms, a variety ofvisualization tools that read NetCDF data may be used to check the domain filesprocessed by geogrid or the horizontally interpolated meteorological fields produced by
metgrid. In order to set the file format for geogrid and metgrid to NetCDF, the usershould specify 2 as the io_form_geogrid and io_form_metgrid in the WPS namelistfile (Note: 2 is the default setting for these options):
&share io_form_geogrid = 2,/
&metgrid io_form_metgrid = 2,/
Among the available tools, the ncdump, ncview, and new RIP4 programs may be ofinterest. The ncdump program is a compact utility distributed with the NetCDF librariesthat lists the variables and attributes in a NetCDF file. This can be useful, in particular,for checking the domain parameters (e.g., west-east dimension, south-north dimension, ordomain center point) in geogrid domain files, or for listing the fields in a file. The ncviewprogram provides an interactive way to view fields in NetCDF files. Also, for userswishing to produce plots of fields suitable for use in publications, the new release of theRIP4 program may be of interest. The new RIP4 is capable of plotting horizontalcontours, map backgrounds, and overlaying multiple fields within the same plot.
Output from the ungrib program is always written in a simple binary format (either'WPS', 'SI', or 'MM5'), so software for viewing NetCDF files will almost certainly be ofno use. However, an NCAR Graphics-based utility, plotfmt, is supplied with the WPSsource code. This utility produces contour plots of the fields found in an intermediate-format file. If the NCAR Graphics libraries are properly installed, the plotfmt program isautomatically compiled, along with other utility programs, when WPS is built.
Besides the three main WPS programs – geogrid, ungrib, and metgrid – there are anumber of utility programs that come with the WPS, and which are compiled in the utildirectory. These utilities may be used to examine data files, visualize the location ofnested domains, compute pressure fields, and compute average surface temperaturefields.
A. avg_tsfc.exe
The avg_tsfc.exe program computes a daily mean surface temperature given input files inthe intermediate format. Based on the range of dates specified in the "share" namelistsection of the namelist.wps file, and also considering the interval between intermediatefiles, avg_tsfc.exe will use as many complete days' worth of data as possible incomputing the average, beginning at the starting date specified in the namelist. If acomplete day's worth of data is not available, no output file will be written, and theprogram will halt as soon as this can be determined. Similarly, any intermediate files for
dates that cannot be used as part of a complete 24-hour period are ignored; for example,if there are five intermediate files available at a six-hour interval, the last file would beignored. The computed average field is written to a new file named TAVGSFC using thesame intermediate format version as the input files. This daily mean surface temperaturefield can then be ingested by metgrid by specifying 'TAVGSFC' for the constants_namevariable in the "metgrid" namelist section.
B. mod_levs.exe
The mod_levs.exe program is used to remove levels of data from intermediate formatfiles. The levels which are to be kept are specified in a new namelist record in thenamelist.wps file:
&mod_levs press_pa = 201300 , 200100 , 100000 , 95000 , 90000 , 85000 , 80000 , 75000 , 70000 , 65000 , 60000 , 55000 , 50000 , 45000 , 40000 , 35000 , 30000 , 25000 , 20000 , 15000 , 10000 , 5000 , 1000/
Within the &mod_levs namelist record, the variable press_pa is used to specify a list oflevels to keep; the specified levels should match values of xlvl in the intermediateformat files (see the discussion of the WPS intermediate format for more information onthe fields of the intermediate files). The mod_levs program takes two command-linearguments as its input. The first argument is the name of the intermediate file to operateon, and the second argument is the name of the output file to be written.
Removing all but a specified subset of levels from meteorological data sets is particularlyuseful, for example, when one data set is to be used for the model initial conditions and asecond data set is to be used for the lateral boundary conditions. This can be done byproviding the initial conditions data set at the first time period to be interpolated bymetgrid, and the boundary conditions data set for all other times. If the both data setshave the same number of vertical levels, then no work needs to be done; however, whenthese two data sets have a different number of levels, it will be necessary, at a minimum,to remove (m – n) levels, where m > n and m and n are the number of levels in each of thetwo data sets, from the data set with m levels. The necessity of having the same numberof vertical levels in all files is due to a limitation in real.exe, which requires a constantnumber of vertical levels to interpolate from.
levels need not match between data sets, all data sets should have a surface level of data,and, when running real.exe and wrf.exe, the value of p_top must be chosen to be belowthe lowest top among the data sets.
C. calc_ecmwf_p.exe
In the course of vertically interpolating meteorological fields, the real program requires3-d pressure and geopotential height fields on the same levels as the other atmosphericfields. The calc_ecmwf_p.exe utility may be used to create these fields for use withECMWF sigma-level data sets. Given a surface pressure field (or log of surface pressurefield) and a list of coefficients A and B, calc_ecmwf_p.exe computes the pressure at anECMWF sigma level k at grid point (i,j) as Pijk = Ak + Bk*Psfcij. The list of coefficientsused in the pressure computation can be copied from a table appropriate to the number ofsigma levels in the data set from one of the following links:
This table should be written in plain text to a file, ecmwf_coeffs, in the current workingdirectory; for example, with 16 sigma levels, the file emcwf_coeffs would containsomething like:
0 0.000000 0.000000000 1 5000.000000 0.000000000 2 9890.519531 0.001720764 3 14166.304688 0.013197623 4 17346.066406 0.042217135 5 19121.152344 0.093761623 6 19371.250000 0.169571340 7 18164.472656 0.268015683 8 15742.183594 0.384274483 9 12488.050781 0.510830879 10 8881.824219 0.638268471 11 5437.539063 0.756384850
12 2626.257813 0.855612755 13 783.296631 0.928746223 14 0.000000 0.972985268 15 0.000000 0.992281914 16 0.000000 1.000000000
Additionally, if soil height (or soil geopotential), 3-d temperature, and 3-d specifichumidity fields are available, calc_ecmwf_p.exe computes a 3-d geopotential heightfield, which is required to obtain an accurate vertical interpolation in the real program.
Given a set of intermediate files produced by ungrib and the file ecmwf_coeffs,calc_ecmwf_p loops over all time periods in namelist.wps, and produces an additionalintermediate file, PRES:YYYY-MM-DD_HH, for each time, which contains pressure andgeopotential height data for each full sigma level, as well as a 3-d relative humidity field.This intermediate file should be specified to metgrid, along with the intermediate dataproduced by ungrib, by adding 'PRES' to the list of prefixes in the fg_name namelistvariable.
D. height_ukmo.exe
The real program requires 3-d pressure and geopotential height fields to verticallyinterpolate the output of the metgrid program; however, data sets from the UKMOUnified Model contain a 3-d pressure field, but do not contain a geopotential height field.Accordingly, the height_ukmo.exe program may be used to compute a geopotentialheight field for data sets from the UKMO Unified Model. The height_ukmo.exe programrequires no command-line arguments, but reads the &metgrid namelist record to get theprefix of the intermediate files created by ungrib.exe; the intermediate files indicated bythe first prefix in the fg_name variable of the &metgrid namelist record are expected tocontain a SOILHGT field, from which the height_ukmo.exe program computes, with theaid of an auxiliary table, the 3-d geopotential height field. The computed height field iswritten to a new intermediate file with the prefix HGT, and the prefix 'HGT' should thenbe added to the fg_name namelist variable in the &metgrid namelist record beforerunning metgrid.exe. The name of the file containing the auxiliary table is currently hard-wired in the source code of the height_ukmo.exe program, and it is the responsibility ofthe user to change this file name in WPS/util/src/height_ukmo.F to the name of the tablewith the same number of levels as the GRIB data processed by ungrib.exe; tables for datawith 38, 50, and 70 levels are provided in the WPS/util directory with file namesvertical_grid_38_20m_G3.txt, vertical_grid_50_20m_63km.txt , andvertical_grid_70_20m_80km.txt, respectively.
E. plotgrids.ncl
drawn over the coarse domain, and any nested domains are drawn as rectangles outliningthe extent of each nest. This utility may be useful particularly during initial placement ofdomains, at which time the user can iteratively adjust the locations of nests by editing thenamelist.wps file, running plotgrids.ncl, and determining a set of adjustments to the nestlocations. To run this program, simply type 'ncl util/plotgrids.ncl' in the command linefrom inside the WPS/ directory. Currently, this utility does not work for ARW domainsthat use the latitude-longitude projection (i.e., when map_proj = 'lat-lon').
F. g1print.exe
The g1print.exe program takes as its only command-line argument the name of a GRIBEdition 1 file. The program prints a listing of the fields, levels, and dates of the data inthe file.
G. g2print.exe
Similar to g1print.exe, the g2print.exe program takes as its only command-line argumentthe name of a GRIB Edition 2 file. The program prints a listing of the fields, levels, anddates of the data in the file.
H. rd_intermediate.exe
Given the name of a singe intermediate format file on the command line, therd_intermediate.exe program prints information about the fields contained in the file.
The role of the ungrib program is to decode GRIB data sets into a simple intermediateformat that is understood by metgrid. If meteorological data are not available in GRIBEdition 1 or GRIB Edition 2 formats, the user is responsible for writing such data into theintermediate file format. Fortunately, the intermediate format is relatively simple,consisting of a sequence of unformatted Fortran writes. It is important to note that theseunformatted writes use big-endian byte order, which can typically be specified withcompiler flags. Below, we describe the WPS intermediate format; users interested in theSI or MM5 intermediate formats can first gain familiarity with the WPS format, which isvery similar, and later examine the Fortran subroutines that read and write all threeintermediate formats (metgrid/src/read_met_module.F andmetgrid/src/write_met_module.F, respectively).
When writing data to the WPS intermediate format, 2-dimensional fields are written as arectangular array of real values. 3-dimensional arrays must be split across the verticaldimension into 2-dimensional arrays, which are written independently. It should also be
noted that, for global data sets, either a Gaussian or cylindrical equidistant projectionmust be used, and for regional data sets, either a Mercator, Lambert conformal, polarstereographic, or cylindrical equidistant may be used. The sequence of writes used towrite a single 2-dimensional array in the WPS intermediate format is as follows (note thatnot all of the variables declared below are used for a given projection of the data).
! 2) WRITE METADATA! Cylindrical equidistantif (iproj == 0) then write(unit=ounit) hdate, xfcst, map_source, field, & units, desc, xlvl, nx, ny, iproj write(unit=ounit) startloc, startlat, startlon, & deltalat, deltalon, earth_radius
! Mercatorelse if (iproj == 1) then write(unit=ounit) hdate, xfcst, map_source, field, & units, desc, xlvl, nx, ny, iproj write(unit=ounit) startloc, startlat, startlon, dx, dy, & truelat1, earth_radius
! Lambert conformalelse if (iproj == 3) then write(unit=ounit) hdate, xfcst, map_source, field, & units, desc, xlvl, nx, ny, iproj write(unit=ounit) startloc, startlat, startlon, dx, dy, & xlonc, truelat1, truelat2, earth_radius
! Gaussianelse if (iproj == 4) then write(unit=ounit) hdate, xfcst, map_source, field, & units, desc, xlvl, nx, ny, iproj write(unit=ounit) startloc, startlat, startlon, & nlats, deltalon, earth_radius
! Polar stereographicelse if (iproj == 5) then write(unit=ounit) hdate, xfcst, map_source, field, & units, desc, xlvl, nx, ny, iproj write(unit=ounit) startloc, startlat, startlon, dx, dy, & xlonc, truelat1, earth_radius
end if
Field name inintermediate file Units Description NotesTT K 3-d air temperatureRH % 3-d relative humidity Not needed if SPECHUMD is availableSPECHUMD kg kg-1 3-d specific humidity Not needed if RH is availableUU m s-1 3-d wind u-componentVV m s-1 3-d wind v-componentGHT m 3-d geopotential height
Although Vtables are provided for many common data sets, it would be impossible forungrib to anticipate every possible source of meteorological data in GRIB format. Whena new source of data is to be processed by ungrib.exe, the user may create a new Vtableeither from scratch, or by using an existing Vtable as an example. In either case, a basicknowledge of the meaning and use of the various fields of the Vtable will be helpful.
Each Vtable contains either seven or eleven fields, depending on whether the Vtable isfor a GRIB Edition 1 data source or a GRIB Edition 2 data source, respectively. Thefields of a Vtable fall into one of three categories: fields that describe how the data areidentified within the GRIB file, fields that describe how the data are identified by theungrib and metgrid programs, and fields specific to GRIB Edition 2. Each variable to beextracted by ungrib.exe will have one or more lines in the Vtable, with multiple lines fordata that are split among different level types – for example, a surface level and upper-airlevels. The fields that must be specified for a line, or entry, in the Vtable depends on thespecifics of the field and level.
The first group of fields – those that describe how the data are identified within the GRIBfile – are given under the column headings of the Vtable shown below.
The "GRIB1 Param" field specifies the GRIB code for the meteorological field, which isa number unique to that field within the data set. However, different data sets may usedifferent GRIB codes for the same field – for example, temperature at upper-air levelshas GRIB code 11 in GFS data, but GRIB code 130 in ECMWF data. To find the GRIBcode for a field, the g1print.exe and g2print.exe utility program may be used.
Given a GRIB code, the "Level Type", "From Level1", and "From Level2" fields areused to specify which levels a field may be found at. As with the "GRIB1 Param" field,the g1print.exe and g2print.exe programs may be used to find values for the level fields.The meanings of the level fields are dependent on the "Level Type" field, and aresummarized in the following table.
When layer fields (Level Type 112) are specified, the starting and ending points for thelayer have units that are dependent on the field itself; appropriate values may be foundwith the g1print.exe and g2print.exe utility programs.
The second group of fields in a Vtable, those that describe how the data are identifiedwithin the metgrid and real programs, fall under the column headings shown below.
The most important of these three fields is the "metgrid Name" field, which determinesthe variable name that will be assigned to a meteorological field when it is written to theintermediate files by ungrib. This name should also match an entry in theMETGRID.TBL file, so that the metgrid program can determine how the field is to behorizontally interpolated. The "metgrid Units" and "metgrid Description" fields specifythe units and a short description for the field, respectively; here, it is important to note
that if no description is given for a field, then ungrib will not write that field out to theintermediate files.
The final group of fields, which provide GRIB2-specific information, are found under thecolumn headings below.
The GRIB2 fields are only needed in a Vtable that is to be used for GRIB Edition 2 datasets, although having these fields in a Vtable does not prevent that Vtable from also beingused for GRIB Edition 1 data. For example, the Vtable.GFS file contains GRIB2 Vtablefields, but is used for both 1-degree (GRIB1) GFS and 0.5-degree (GRIB2) GFS datasets. Since Vtables are provided for most known GRIB Edition 2 data sets, thecorresponding Vtable fields are not described here at present.
The static geographical data sets that are interpolated by the geogrid program are storedas regular 2-d and 3-d arrays written in a simple binary raster format. Users with a newsource for a given static field can ingest their data with WPS by writing the data set intothis binary format. The geogrid format is capable of supporting single-level and multi-level continuous fields, categorical fields represented as dominant categories, andcategorical fields given as fractional fields for each category. The most simple of thesefield types in terms of representation in the binary format is a categorical field given as adominant category at each source grid point, an example of which is the 30-second USGSland use data set.
For a categorical field given as dominant categories, the data must first be stored in aregular 2-d array of integers, with each integer giving the dominant category at the
corresponding source grid point. Given this array, the data are written to a file, row-by-row, beginning at the bottom, or southern-most, row. For example, in the figure above,the elements of the n × m array would be written in the order x11, x12, ..., x1m, x21, ..., x2m,..., xn1, ..., xnm. When written to the file, every element is stored as a 1-, 2-, 3-, or 4-byteinteger in big-endian byte order (i.e., for the 4-byte integer ABCD, byte A is stored at thelowest address and byte D at the highest), although little-endian files may be used bysetting endian=little in the "index" file for the data set. Every element in a file mustuse the same number of bytes for its storage, and, of course, it is advantageous to use thefewest number of bytes needed to represent the complete range of values in the array.
When writing the binary data to a file, no header, record marker, or additional bytesshould be written. For example, a 2-byte 1000 × 1000 array should result in a file whosesize is exactly 2,000,000 bytes. Since Fortran unformatted writes add record markers, it isnot possible to write a geogrid binary-formatted file directly from Fortran; instead, it isrecommended that the C routines in read_geogrid.c and write_geogrid.c (in thegeogrid/src directory) be called when writing data, either from C or Fortran code.
Multi-level continuous fields are handled much the same as single-level continuousfields. For an n × m × r array, conversion to a positive, integral field is first performed asdescribed above. Then, each n × m sub-array is written contiguously to the binary file asbefore, beginning with the smallest r-index. Categorical fields that are given as fractionalfields for each possible category can be thought of as multi-level continuous fields, whereeach level k, 1 ≤ k ≤ r, is the fractional field for category k.
When writing a field to a file in the geogrid binary format, the user should adhere to thenaming convention used by the geogrid program, which expects data files to have namesof the form xstart-xend.ystart-yend, where xstart, xend, ystart, and yend are five-digitpositive integers specifying, respectively, the starting x-index of the array contained in
the file, the ending x-index of the array, the starting y-index of the array, and the endingy-index of the array; here, indexing begins at 1, rather than 0. So, for example, an 800 ×1200 array (i.e., 800 rows and 1200 columns) might be named 00001-01200.00001-00800.
When a data set is given in several pieces, each of the pieces may be formed as a regularrectangular array, and each array may be written to a separate file. In this case, therelative locations of the arrays are determined by the range of x- and y-indices in the filenames for each of the arrays. It is important to note, however, that every tile in a data setmust have the same x- and y-dimensions, and that tiles of data within a data set must notoverlap; furthermore, all tiles must start and end on multiples of the index ranges. Forexample, the global 30-second USGS topography data set is divided into arrays ofdimension 1200 × 1200, with each array containing a 10-degree × 10-degree piece of thedata set; the file whose south-west corner is located at (90S, 180W) is named 00001-01200.00001-01200, and the file whose north-east corner is located at (90N, 180E) isnamed 42001-43200.20401-21600.
If a data set is to be split into multiple tiles, and the number of grid points in, say, the x-direction is not evenly divided by the number of tiles in the x-direction, then the lastcolumn of tiles must be padded with a flag value (specified in the index file using themissing_value keyword) so that all tiles have the same dimensions. For example, if adata set has 2456 points in the x-direction, and three tiles in the x-direction will be used,the range of x-coordinates of the tiles might be 1 – 820, 821 – 1640, and 1641 – 2460,with columns 2457 through 2460 being filled with a flag value.
Clearly, since the starting and ending indices must have five digits, a field cannot havemore than 99999 data points in either of the x- or y-directions. In case a field has morethan 99999 data points in either dimension, the user can simply split the data set intoseveral smaller data sets which will be identified separately to geogrid. For example, avery large global data set may be split into data sets for the Eastern and Westernhemispheres.
Besides the binary data files, geogrid requires one extra metadata file per data set. Thismetadata file is always named 'index', and thus, two data sets cannot reside in the samedirectory. Essentially, this metadata file is the first file that geogrid looks for whenprocessing a data set, and the contents of the file provide geogrid with all of theinformation necessary for constructing names of possible data files. The contents of anexample index file are given below.
type = continuous signed = yes projection = regular_ll dx = 0.00833333 dy = 0.00833333 known_x = 1.0 known_y = 1.0 known_lat = -89.99583 known_lon = -179.99583
wordsize = 2 tile_x = 1200 tile_y = 1200 tile_z = 1 tile_bdr=3 units="meters MSL" description="Topography height"
For a complete listing of keywords that may appear in an index file, along with themeaning of each keyword, the user is referred to the section on index file options.
In order to create a more inhomogeneous and detailed urban fraction field for use withNUDAPT, users may obtain high-resolution land cover information from the NationalLand Cover Database (NLCD) through the Multi-Resolution Land CharacteristicsConsortium. Generation of the urban fraction field, called FRC_URB2D in WRF,involves first downloading the NLCD data over the region covered by the WRF domain,converting the data into the binary format used by geogrid, and finally extracting only theurban categories to a new urban fraction field. The following steps can serve as a guidethrough this process.
2. After downloading the data, unpacking the archive should yield a directory with a .tif file and a .tfw file, among others. In order for the information in the GeoTIFF file to be useful, the .tif image must be converted into the binary format used by the WPS. This conversion can be accomplished using the GDAL translation tool, gdal_translate, (http://gdal.org) by running the command > gdal_translate -of ENVI foo.tif data.bil
where foo.tif is the name of the GeoTIFF image that was downloaded in Step 1. The output format "ENVI" is a simple binary raster format that matches the format used by geogrid. After converting the GeoTIFF to a binary file, the resulting data.bil file must be renamed to 00001-ncols.00001-nrows, where ncols is the number of columns (in i5.5 format) and nrows is the number of rows (also in i5.5 format) in the image; these values should have been printed to the screen when the gdal_translate program was run.
4. Create an index metadata file for the urban fraction data. In the directory created by unpacking the land use data, a .tfw file should also exist. The last two lines in this file give the location of the north-west corner of the data tile, which is used in the index file for variables known_lat and known_lon. If this location is given as (x,y) coordinates, in meters, then the coordinate converter utility available from http://www2.mmm.ucar.edu/people/duda/uf/ may be used to convert to (latitude, longitude), which is required by the index file. The basic index file should contain the following elements:
type=continuous projection=albers_nad83 dx=30.0 dy=30.0 known_x=1.0 known_y=2351.0 # <- edit known_lat = 40.096571 # <- edit known_lon = -105.405615 # <- edit truelat1=29.5 truelat2=45.5 stdlon=-96.0 wordsize=1 scale_factor=0.01 row_order=top_bottom tile_x=2407 # <- edit tile_y=2351 # <- edit tile_z=1 units="unitless" description="urban fraction"
5. Add the following entry to the GEOGRID.TBL file before re-running the geogrid.exe program:
=============================== name=FRC_URB2D priority=1 dest_type=continuous fill_missing = 0. interp_option=default: average_gcell(1.0)+four_pt abs_path=default:/path/to/dataset/ ===============================
The path to the dataset and index files created in Step 3 and Step 4, respectively, should be substituted for '/path/to/dataset/' in the entry above.
A. SHARE section
This section describes variables that are used by more than one WPS program. Forexample, the wrf_core variable specifies whether the WPS is to produce data for theARW or the NMM core – information which is needed by both the geogrid and metgridprograms.
1. WRF_CORE : A character string set to either 'ARW' or 'NMM' that tells the WPS whichdynamical core the input data are being prepared for. Default value is 'ARW'.
5. START_DAY : A list of MAX_DOM 2-digit integers specifying the starting UTC dayof the simulation for each nest. No default value.
7. END_YEAR : A list of MAX_DOM 4-digit integers specifying the ending UTC yearof the simulation for each nest. No default value.
9. END_DAY : A list of MAX_DOM 2-digit integers specifying the ending UTC day ofthe simulation for each nest. No default value.
10. END_HOUR : A list of MAX_DOM 2-digit integers specifying the ending UTC hourof the simulation for each nest. No default value.
14. ACTIVE_GRID : A list of MAX_DOM logical values specifying, for each grid,whether that grid should be processed by geogrid and metgrid. Default value is .TRUE..
15. IO_FORM_GEOGRID : The WRF I/O API format that the domain files created bythe geogrid program will be written in. Possible options are: 1 for binary; 2 for NetCDF;3 for GRIB1. When option 1 is given, domain files will have a suffix of .int; when option2 is given, domain files will have a suffix of .nc; when option 3 is given, domain fileswill have a suffix of .gr1. Default value is 2 (NetCDF).
17. DEBUG_LEVEL : An integer value indicating the extent to which different types ofmessages should be sent to standard output. When debug_level is set to 0, onlygenerally useful messages and warning messages will be written to standard output.When debug_level is greater than 100, informational messages that provide furtherruntime details are also written to standard output. Debugging messages and messagesspecifically intended for log files are never written to standard output, but are alwayswritten to the log files. Default value is 0.
B. GEOGRID section
This section specifies variables that are specific to the geogrid program. Variables in thegeogrid section primarily define the size and location of all model domains, and wherethe static geographical data are found.
1. PARENT_ID : A list of MAX_DOM integers specifying, for each nest, the domainnumber of the nest's parent; for the coarsest domain, this variable should be set to 1.Default value is 1.
5. S_WE : A list of MAX_DOM integers which should all be set to 1. Default value is 1.
6. E_WE : A list of MAX_DOM integers specifying, for each nest, the nest's full west-east dimension. For nested domains, e_we must be one greater than an integer multiple ofthe nest's parent_grid_ratio (i.e., e_we = n*parent_grid_ratio+1 for some positiveinteger n). No default value.
7. S_SN : A list of MAX_DOM integers which should all be set to 1. Default value is 1.
8. E_SN : A list of MAX_DOM integers specifying, for each nest, the nest's full south-north dimension. For nested domains, e_sn must be one greater than an integer multipleof the nest's parent_grid_ratio (i.e., e_sn = n*parent_grid_ratio+1 for somepositive integer n). No default value.
10. DX : A real value specifying the grid distance in the x-direction where the map scalefactor is 1. For ARW, the grid distance is in meters for the 'polar', 'lambert', and'mercator' projection, and in degrees longitude for the 'lat-lon' projection; forNMM, the grid distance is in degrees longitude. Grid distances for nests are determinedrecursively based on values specified for parent_grid_ratio and parent_id. Nodefault value.
11. DY : A real value specifying the nominal grid distance in the y-direction where themap scale factor is 1. For ARW, the grid distance is in meters for the 'polar','lambert', and 'mercator' projection, and in degrees latitude for the 'lat-lon'projection; for NMM, the grid distance is in degrees latitude. Grid distances for nests aredetermined recursively based on values specified for parent_grid_ratio andparent_id. No default value.
12. MAP_PROJ : A character string specifying the projection of the simulation domain.For ARW, accepted projections are 'lambert', 'polar', 'mercator', and 'lat-lon';for NMM, a projection of 'rotated_ll' must be specified. Default value is 'lambert'.
13. REF_LAT : A real value specifying the latitude part of a (latitude, longitude) locationwhose (i,j) location in the simulation domain is known. For ARW, ref_lat gives thelatitude of the center-point of the coarse domain by default (i.e., when ref_x and ref_yare not specified). For NMM, ref_lat always gives the latitude to which the origin isrotated. No default value.
14. REF_LON : A real value specifying the longitude part of a (latitude, longitude)location whose (i, j) location in the simulation domain is known. For ARW, ref_longives the longitude of the center-point of the coarse domain by default (i.e., when ref_xand ref_y are not specified). For NMM, ref_lon always gives the longitude to whichthe origin is rotated. For both ARW and NMM, west longitudes are negative, and thevalue of ref_lon should be in the range [-180, 180]. No default value.
15. REF_X : A real value specifying the i part of an (i, j) location whose (latitude,longitude) location in the simulation domain is known. The (i, j) location is always givenwith respect to the mass-staggered grid, whose dimensions are one less than thedimensions of the unstaggered grid. Default value is (((E_WE-1.)+1.)/2.) = (E_WE/2.).
16. REF_Y : A real value specifying the j part of an (i, j) location whose (latitude,longitude) location in the simulation domain is known. The (i, j) location is always givenwith respect to the mass-staggered grid, whose dimensions are one less than thedimensions of the unstaggered grid. Default value is (((E_SN-1.)+1.)/2.) = (E_SN/2.).
17. TRUELAT1 : A real value specifying, for ARW, the first true latitude for theLambert conformal projection, or the only true latitude for the Mercator and polarstereographic projections. For NMM, truelat1 is ignored. No default value.
18. TRUELAT2 : A real value specifying, for ARW, the second true latitude for theLambert conformal conic projection. For all other projections, truelat2 is ignored. Nodefault value.
19. STAND_LON : A real value specifying, for ARW, the longitude that is parallel withthe y-axis in the Lambert conformal and polar stereographic projections. For the regularlatitude-longitude projection, this value gives the rotation about the earth's geographicpoles. For NMM, stand_lon is ignored. No default value.
20. POLE_LAT : For the latitude-longitude projection for ARW, the latitude of the NorthPole with respect to the computational latitude-longitude grid in which -90.0° latitude isat the bottom of a global domain, 90.0° latitude is at the top, and 180.0° longitude is atthe center. Default value is 90.0.
21. POLE_LON : For the latitude-longitude projection for ARW, the longitude of theNorth Pole with respect to the computational lat/lon grid in which -90.0° latitude is at thebottom of a global domain, 90.0° latitude is at the top, and 180.0° longitude is at thecenter. Default value is 0.0.
22. GEOG_DATA_PATH : A character string giving the path, either relative or absolute,to the directory where the geographical data directories may be found. This path is theone to which rel_path specifications in the GEOGRID.TBL file are given in relation to.No default value.
C. UNGRIB section
Currently, this section contains only two variables, which determine the output formatwritten by ungrib and the name of the output files.
2. PREFIX : A character string that will be used as the prefix for intermediate-formatfiles created by ungrib; here, prefix refers to the string PREFIX in the filenamePREFIX:YYYY-MM-DD_HH of an intermediate file. The prefix may contain pathinformation, either relative or absolute, in which case the intermediate files will bewritten in the directory specified. This option may be useful to avoid renamingintermediate files if ungrib is to be run on multiple sources of GRIB data. Default value is'FILE'.
D. METGRID section
This section defines variables used only by the metgrid program. Typically, the user willbe interested in the fg_name variable, and may need to modify other variables of thissection less frequently.
1. FG_NAME : A list of character strings specifying the path and prefix of ungribbeddata files. The path may be relative or absolute, and the prefix should contain allcharacters of the filenames up to, but not including, the colon preceding the date. Whenmore than one fg_name is specified, and the same field is found in two or more input
sources, the data in the last encountered source will take priority over all precedingsources for that field. Default value is an empty list (i.e., no meteorological fields).
3. IO_FORM_METGRID : The WRF I/O API format that the output created by themetgrid program will be written in. Possible options are: 1 for binary; 2 for NetCDF; 3for GRIB1. When option 1 is given, output files will have a suffix of .int; when option 2is given, output files will have a suffix of .nc; when option 3 is given, output files willhave a suffix of .gr1. Default value is 2 (NetCDF).
The GEOGRID.TBL file is a text file that defines parameters of each of the data sets tobe interpolated by geogrid. Each data set is defined in a separate section, with sectionsbeing delimited by a line of equality symbols (e.g., '=============='). Within eachsection, there are specifications, each of which has the form of keyword=value. Somekeywords are required in each data set section, while others are optional; some keywordsare mutually exclusive with other keywords. Below, the possible keywords and theirexpected range of values are described.
1. NAME : A character string specifying the name that will be assigned to theinterpolated field upon output. No default value.
2. PRIORITY : An integer specifying the priority that the data source identified in thetable section takes with respect to other sources of data for the same field. If a field has nsources of data, then there must be n separate table entries for the field, each of whichmust be given a unique value for priority in the range [1, n]. No default value.
4. INTERP_OPTION : A sequence of one or more character strings, which are the namesof interpolation methods to be used when horizontally interpolating the field. Availableinterpolation methods are: average_4pt, average_16pt, wt_average_4pt,wt_average_16pt, nearest_neighbor, four_pt, sixteen_pt, search(r), andaverage_gcell(r). For the search method (search), the optional argument r specifiesthe maximum search radius in units of grid points in the grid of the source data; thedefault search radius is 1200 points. For the grid cell average method (average_gcell),the optional argument r specifies the minimum ratio of source data resolution tosimulation grid resolution at which the method will be applied; unless specified, r = 0.0,and the option is used for any ratio. When a sequence of two or more methods are given,the methods should be separated by a + sign. No default value.
7. REL_PATH : A character string specifying the path relative to the path given in thenamelist variable geog_data_path. A specification is of the general formRES_STRING:REL_PATH, where RES_STRING is a character string identifying thesource or resolution of the data in some unique way and may be specified in the namelistvariable geog_data_res, and REL_PATH is a path relative to geog_data_path wherethe index and data tiles for the data source are found. More than one rel_pathspecification may be given in a table section if there are multiple sources or resolutionsfor the data source, just as multiple resolutions may be specified (in a sequence delimitedby + symbols) for geog_data_res. See also abs_path. No default value.
8. ABS_PATH : A character string specifying the absolute path to the index and data tilesfor the data source. A specification is of the general form RES_STRING:ABS_PATH,where RES_STRING is a character string identifying the source or resolution of the datain some unique way and may be specified in the namelist variable geog_data_res, andABS_PATH is the absolute path to the data source's files. More than one abs_pathspecification may be given in a table section if there are multiple sources or resolutions
for the data source, just as multiple resolutions may be specified (in a sequence delimitedby + symbols) for geog_data_res. See also rel_path. No default value.
12. MASKED : Either land or water, indicating that the field is not valid at land orwater points, respectively. If the masked keyword is used for a field, those grid points thatare of the masked type (land or water) will be assigned the value specified byfill_missing. Default value is null (i.e., the field is not masked).
13. FILL_MISSING : A real value used to fill in any missing or masked grid points in theinterpolated field. Default value is 1.E20.
14. HALT_ON_MISSING : Either yes or no, indicating whether geogrid should halt witha fatal message when a missing value is encountered in the interpolated field. Defaultvalue is no.
geogrid output. This option can only be used for fields with dest_type=categorical.Default value is null (i.e., no dominant category will be computed from the fractionalcategorical field).
17. DF_DX : When df_dx is assigned a character string value, the effect is to causegeogrid to compute the directional derivative of the field in the x-direction using a centraldifference along the interior of the domain, or a one-sided difference at the boundary ofthe domain; the derivative field will be named according to the character string assignedto the keyword df_dx. Default value is null (i.e., no derivative field is computed).
18. DF_DY : When df_dy is assigned a character string value, the effect is to causegeogrid to compute the directional derivative of the field in the y-direction using a centraldifference along the interior of the domain, or a one-sided difference at the boundary ofthe domain; the derivative field will be named according to the character string assignedto the keyword df_dy. Default value is null (i.e., no derivative field is computed).
19. Z_DIM_NAME : For 3-dimensional output fields, a character string giving the nameof the vertical dimension, or z-dimension. A continuous field may have multiple levels,and thus be a 3-dimensional field, and a categorical field may take the form of a 3-dimensional field if it is written out as fractional fields for each category. No defaultvalue.
20. FLAG_IN_OUTPUT : A character string giving the name of a global attribute whichwill be assigned a value of 1 and written to the geogrid output. Default value is null (i.e.,no flag will be written for the field).
21. OPTIONAL : Either yes or no, indicating whether the dataset identified by theresolution specified in the geog_data_res namelist option is optional. If an entry in theGEOGRID.TBL file is optional and if the specified resolution of data cannot be read,geogrid will print an informational message indicating that the dataset was notinterpolated and continue; otherwise, if the entry is not optional and the specifiedresolution of data cannot be read, geogrid will halt with an error. It is possible fordifferent priority level entries for the same field to specify different values of theoptional keyword, e.g., the priority=2 entry for a field can be optional, while thepriority=1 entry can be non-optional (i.e., optional=no). Default value is no.
Related to the GEOGRID.TBL are the index files that are associated with each static dataset. An index file defines parameters specific to that data set, while the GEOGRID.TBLfile describes how each of the data sets should be treated by geogrid. As with theGEOGRID.TBL file, specifications in an index file are of the form keyword=value.Below are possible keywords and their possible values.
1. PROJECTION : A character string specifying the projection of the data, which may beeither lambert, polar, mercator, regular_ll, albers_nad83, or polar_wgs84. Nodefault value.
3. SIGNED : Either yes or no, indicating whether the values in the data files (which arealways represented as integers) are signed in two's complement form or not. Defaultvalue is no.
4. UNITS : A character string, enclosed in quotation marks ("), specifying the units of theinterpolated field; the string will be written to the geogrid output files as a variable time-independent attribute. No default value.
6. DX : A real value giving the grid spacing in the x-direction of the data set. Ifprojection is one of lambert, polar, mercator, albers_nad83, or polar_wgs84, dxgives the grid spacing in meters; if projection is regular_ll, dx gives the grid spacingin degrees. No default value.
7. DY : A real value giving the grid spacing in the y-direction of the data set. Ifprojection is one of lambert, polar, mercator, albers_nad83, or polar_wgs84, dygives the grid spacing in meters; if projection is regular_ll, dy gives the grid spacingin degrees. No default value.
12. STDLON : A real value specifying the longitude that is parallel with the y-axis inconic and azimuthal projections. No default value.
13. TRUELAT1 : A real value specifying the first true latitude for conic projections orthe only true latitude for azimuthal projections. No default value.
14. TRUELAT2 : A real value specifying the second true latitude for conic projections.No default value.
15. WORDSIZE : An integer giving the number of bytes used to represent the value ofeach grid point in the data files. No default value.
16. TILE_X : An integer specifying the number of grid points in the x-direction,excluding any halo points, for a single tile of source data. No default value.
17. TILE_Y : An integer specifying the number of grid points in the y-direction,excluding any halo points, for a single tile of source data. No default value.
18. TILE_Z : An integer specifying the number of grid points in the z-direction for asingle tile of source data; this keyword serves as an alternative to the pair of keywordstile_z_start and tile_z_end, and when this keyword is used, the starting z-index isassumed to be 1. No default value.
19. TILE_Z_START : An integer specifying the starting index in the z-direction of thearray in the data files. If this keyword is used, tile_z_end must also be specified. Nodefault value.
20. TILE_Z_END : An integer specifying the ending index in the z-direction of the arrayin the data files. If this keyword is used, tile_z_start must also be specified. Nodefault value
23. TILE_BDR : An integer specifying the halo width, in grid points, for each tile of data.Default value is 0.
24. MISSING_VALUE : A real value that, when encountered in the data set, should beinterpreted as missing data. No default value.
27. ENDIAN : A character string, either big or little, specifying whether the values inthe static data set arrays are in big-endian or little-endian byte order. Default value is big.
28. ISWATER : An integer specifying the land use category of water. Default value is 16.
29. ISLAKE : An integer specifying the land use category of inland water bodies. Defaultvalue is -1 (i.e., no separate inland water category).
30. ISICE : An integer specifying the land use category of ice. Default value is 24.
31. ISURBAN : An integer specifying the land use category of urban areas. Default valueis 1.
32. ISOILWATER : An integer specifying the soil category of water. Default value is 14.
33. MMINLU : A character string, enclosed in quotation marks ("), indicating whichsection of WRF's LANDUSE.TBL and VEGPARM.TBL will be used when looking upparameters for land use categories. Default value is "USGS".
34. FILENAME_DIGITS : An integer specifying the number of digits used in the namesof data tiles. Possible values are 5 or 6. Default value is 5.
The METGRID.TBL file is a text file that defines parameters of each of themeteorological fields to be interpolated by metgrid. Parameters for each field are definedin a separate section, with sections being delimited by a line of equality symbols (e.g.,'=============='). Within each section, there are specifications, each of which hasthe form of keyword=value. Some keywords are required in a section, while others areoptional; some keywords are mutually exclusive with other keywords. Below, thepossible keywords and their expected range of values are described.
1. NAME : A character string giving the name of the meteorological field to which thecontaining section of the table pertains. The name should exactly match that of the field
as given in the intermediate files (and, thus, the name given in the Vtable used ingenerating the intermediate files). This field is required. No default value.
2. OUTPUT : Either yes or no, indicating whether the field is to be written to the metgridoutput files or not. Default value is yes.
3. MANDATORY : Either yes or no, indicating whether the field is required forsuccessful completion of metgrid. Default value is no.
4. OUTPUT_NAME : A character string giving the name that the interpolated fieldshould be output as. When a value is specified for output_name, the interpolation optionsfrom the table section pertaining to the field with the specified name are used. Thus, theeffects of specifying output_name are two-fold: The interpolated field is assigned thespecified name before being written out, and the interpolation methods are taken from thesection pertaining to the field whose name matches the value assigned to theoutput_name keyword. No default value.
5. FROM_INPUT : A character string used to compare against the values in the fg_namenamelist variable; if from_input is specified, the containing table section will only beused when the time-varying input source has a filename that contains the value offrom_input as a substring. Thus, from_input may be used to specify differentinterpolation options for the same field, depending on which source of the field is beingprocessed. No default value.
7. IS_U_FIELD : Either yes or no, indicating whether the field is to be used as the windU-component field. For ARW, the wind U-component field must be interpolated to the Ustaggering (output_stagger=U); for NMM, the wind U-component field must beinterpolated to the V staggering (output_stagger=VV). Default value is no.
8. IS_V_FIELD : Either yes or no, indicating whether the field is to be used as the windV-component field. For ARW, the wind V-component field must be interpolated to the Vstaggering (output_stagger=V); for NMM, the wind V-component field must beinterpolated to the V staggering (output_stagger=VV). Default value is no.
9. INTERP_OPTION : A sequence of one or more character strings, which are the namesof interpolation methods to be used when horizontally interpolating the field. Availableinterpolation methods are: average_4pt, average_16pt, wt_average_4pt,wt_average_16pt, nearest_neighbor, four_pt, sixteen_pt, search(r), andaverage_gcell(r). For the search method (search), the optional argument r specifiesthe maximum search radius in units of grid points in the grid of the source data; thedefault search radius is 1200 points. For the grid cell average method (average_gcell),the optional argument r specifies the minimum ratio of source data resolution to
simulation grid resolution at which the method will be applied; unless specified, r = 0.0,and the option is used for any ratio. When a sequence of two or more methods are given,the methods should be separated by a + sign. Default value is nearest_neighbor.
10. INTERP_MASK : The name of the field to be used as an interpolation mask, alongwith the value within that field which signals masked points and an optional relationalsymbol, < or >. A specification takes the form field(?maskval), where field is the name ofthe field, ? is an optional relational symbol (< or >), and maskval is a real value. Sourcedata points will not be used in interpolation if the corresponding point in the field field isequal, greater than, or less than, the value of maskval for no relational symbol, a >symbol, or a < symbol, respectively. Default value is no mask.
13. FILL_MISSING : A real number specifying the value to be assigned to model gridpoints that received no interpolated value, for example, because of missing or incompletemeteorological data. Default value is 1.E20.
15. DERIVED : Either yes or no, indicating whether the field is to be derived from otherinterpolated fields, rather than interpolated from an input field. Default value is no.
16. FILL_LEV : The fill_lev keyword, which may be specified multiple times within atable section, specifies how a level of the field should be filled if that level does notalready exist. A generic value for the keyword takes the form DLEVEL:FIELD(SLEVEL),where DLEVEL specifies the level in the field to be filled, FIELD specifies the sourcefield from which to copy levels, and SLEVEL specifies the level within the source field touse. DLEVEL may either be an integer or the string all. FIELD may either be the nameof another field, the string const, or the string vertical_index. If FIELD is specified asconst, then SLEVEL is a constant value that will be used to fill with; if FIELD isspecified as vertical_index, then (SLEVEL) must not be specified, and the value of the
vertical index of the source field is used; if DLEVEL is 'all', then all levels from the fieldspecified by the level_template keyword are used to fill the corresponding levels in thefield, one at a time. No default value.
17. LEVEL_TEMPLATE : A character string giving the name of a field from which a listof vertical levels should be obtained and used as a template. This keyword is used inconjunction with a fill_lev specification that uses all in the DLEVEL part of itsspecification. No default value.
18. MASKED : Either land, water, or both. Setting MASKED to land or water indicatesthat the field should not be interpolated to WRF land or water points, respectively;however, setting MASKED to both indicates that the field should be interpolated to WRFland points using only land points in the source data and to WRF water points using onlywater points in the source data. When a field is masked, or invalid, the staticLANDMASK field will be used to determine which model grid points the field should beinterpolated to; invalid points will be assigned the value given by the FILL_MISSINGkeyword. Whether a source data point is land or water is determined by the masksspecified using the INTERP_LAND_MASK and INTERP_WATER_MASK options. Default valueis null (i.e., the field is valid for both land and water points).
19. MISSING_VALUE : A real number giving the value in the input field that is assumedto represent missing data. No default value.
21. FLAG_IN_OUTPUT : A character string giving the name of a global attribute whichwill be assigned a value of 1 and written to the metgrid output if the interpolated field isto be output (output=yes). Default value is null (i.e., no flag will be written for the field).
Through the GEOGRID.TBL and METGRID.TBL files, the user can control the methodby which source data – either static fields in the case of geogrid or meteorological fieldsin the case of metgrid – are interpolated. In fact, a list of interpolation methods may begiven, in which case, if it is not possible to employ the i-th method in the list, the (i+1)-stmethod will be employed, until either some method can be used or there are no methodsleft to try in the list. For example, to use a four-point bi-linear interpolation scheme for afield, we could specify interp_option=four_pt. However, if the field had areas ofmissing values, which could prevent the four_pt option from being used, we couldrequest that a simple four-point average be tried if the four_pt method couldn't be usedby specifying interp_option=four_pt+average_4pt instead. Below, each of theavailable interpolation options in the WPS are described conceptually; for the details of
each method, the user is referred to the source code in the fileWPS/geogrid/src/interp_options.F.
The four-point bi-linear interpolation method requires four valid source points aij,1 ≤ i, j ≤ 2 , surrounding the point (x,y), to which geogrid or metgrid must interpolate, asillustrated in the figure above. Intuitively, the method works by linearly interpolating tothe x-coordinate of the point (x,y) between a11 and a12, and between a21 and a22, and thenlinearly interpolating to the y-coordinate using these two interpolated values.
The sixteen_pt overlapping parabolic interpolation method requires sixteen valid sourcepoints surrounding the point (x,y), as illustrated in the figure above. The method works byfitting one parabola to the points ai1, ai2, and ai3, and another parabola to the points ai2,ai3, and ai4, for row i, 1 ≤ i ≤ 4 ; then, an intermediate interpolated value pi within row i atthe x-coordinate of the point is computed by taking an average of the values of the twoparabolas evaluated at x, with the average being weighted linearly by the distance of xfrom ai2 and ai3. Finally, the interpolated value at (x,y) is found by performing the sameoperations as for a row of points, but for the column of interpolated values pi to the y-coordinate of (x,y).
The four-point average interpolation method requires at least one valid source data pointfrom the four source points surrounding the point (x,y). The interpolated value is simplythe average value of all valid values among these four points.
The weighted four-point average interpolation method can handle missing or maskedsource data points, and the interpolated value is given as the weighted average of all validvalues, with the weight wij for the source point aij, 1 ≤ i, j ≤ 2 , given by
wij = max{0,1 − ( x − xi ) 2 + ( y − y j ) 2 } .
The sixteen-point average interpolation method works in an identical way to the four-point average, but considers the sixteen points surrounding the point (x,y).
The weighted sixteen-point average interpolation method works like the weighted four-point average, but considers the sixteen points surrounding (x,y); the weights in thismethod are given by
wij = max{0, 2 − ( x − xi ) 2 + ( y − y j ) 2 } ,
where xi and yj are as defined for the weighted four-point method, and 1 ≤ i, j ≤ 4 .
The nearest neighbor interpolation method simply sets the interpolated value at (x,y) tothe value of the nearest source data point, regardless of whether this nearest source pointis valid, missing, or masked.
The breadth-first search option works by treating the source data array as a 2-d gridgraph, where each source data point, whether valid or not, is represented by a vertex.Then, the value assigned to the point (x,y) is found by beginning a breadth-first search atthe vertex corresponding to the nearest neighbor of (x,y), and stopping once a vertexrepresenting a valid (i.e., not masked or missing) source data point is found. In effect, thismethod can be thought of as "nearest valid neighbor".
The grid-cell average interpolator may be used when the resolution of the source data ishigher than the resolution of the model grid. For a model grid cell Γ, the method takes asimple average of the values of all source data points that are nearer to the center of Γthan to the center of any other grid cell. The operation of the grid-cell average method isillustrated in the figure above, where the interpolated value for the model grid cell –represented as the large rectangle – is given by the simple average of the values of all ofthe shaded source grid cells.
The default land use and soil category data sets that are provided as part of the WPSstatic data tar file contain categories that are matched with the USGS categories describedin the VEGPARM.TBL and SOILPARM.TBL files in the WRF run directory.Descriptions of the 24 land use categories and 16 soil categories are provided in thetables below.
Below, a listing of the global attributes and fields that are written to the geogridprogram's output files is given. This listing is an abridged version of the output from thencdump program when run on a typical geo_em.d01.nc file.
netcdf geo_em.d01 {dimensions: Time = UNLIMITED ; // (1 currently) DateStrLen = 19 ; west_east = 73 ; south_north = 60 ; south_north_stag = 61 ; west_east_stag = 74 ; land_cat = 21 ;
soil_cat = 16 ; month = 12 ; num_urb_params = 132 ;variables: char Times(Time, DateStrLen) ; float XLAT_M(Time, south_north, west_east) ; XLAT_M:units = "degrees latitude" ; XLAT_M:description = "Latitude on mass grid" ; float XLONG_M(Time, south_north, west_east) ; XLONG_M:units = "degrees longitude" ; XLONG_M:description = "Longitude on mass grid" ; float XLAT_V(Time, south_north_stag, west_east) ; XLAT_V:units = "degrees latitude" ; XLAT_V:description = "Latitude on V grid" ; float XLONG_V(Time, south_north_stag, west_east) ; XLONG_V:units = "degrees longitude" ; XLONG_V:description = "Longitude on V grid" ; float XLAT_U(Time, south_north, west_east_stag) ; XLAT_U:units = "degrees latitude" ; XLAT_U:description = "Latitude on U grid" ; float XLONG_U(Time, south_north, west_east_stag) ; XLONG_U:units = "degrees longitude" ; XLONG_U:description = "Longitude on U grid" ; float CLAT(Time, south_north, west_east) ; CLAT:units = "degrees latitude" ; CLAT:description = "Computational latitude on mass grid" ; float CLONG(Time, south_north, west_east) ; CLONG:units = "degrees longitude" ; CLONG:description = "Computational longitude on mass grid" ; float MAPFAC_M(Time, south_north, west_east) ; MAPFAC_M:units = "none" ; MAPFAC_M:description = "Mapfactor on mass grid" ; float MAPFAC_V(Time, south_north_stag, west_east) ; MAPFAC_V:units = "none" ; MAPFAC_V:description = "Mapfactor on V grid" ; float MAPFAC_U(Time, south_north, west_east_stag) ; MAPFAC_U:units = "none" ; MAPFAC_U:description = "Mapfactor on U grid" ; float MAPFAC_MX(Time, south_north, west_east) ; MAPFAC_MX:units = "none" ; MAPFAC_MX:description = "Mapfactor (x-dir) on mass grid" ; float MAPFAC_VX(Time, south_north_stag, west_east) ; MAPFAC_VX:units = "none" ; MAPFAC_VX:description = "Mapfactor (x-dir) on V grid" ; float MAPFAC_UX(Time, south_north, west_east_stag) ; MAPFAC_UX:units = "none" ; MAPFAC_UX:description = "Mapfactor (x-dir) on U grid" ; float MAPFAC_MY(Time, south_north, west_east) ; MAPFAC_MY:units = "none" ; MAPFAC_MY:description = "Mapfactor (y-dir) on mass grid" ; float MAPFAC_VY(Time, south_north_stag, west_east) ; MAPFAC_VY:units = "none" ; MAPFAC_VY:description = "Mapfactor (y-dir) on V grid" ; float MAPFAC_UY(Time, south_north, west_east_stag) ; MAPFAC_UY:units = "none" ; MAPFAC_UY:description = "Mapfactor (y-dir) on U grid" ; float E(Time, south_north, west_east) ; E:units = "-" ; E:description = "Coriolis E parameter" ; float F(Time, south_north, west_east) ; F:units = "-" ; F:description = "Coriolis F parameter" ; float SINALPHA(Time, south_north, west_east) ;
SINALPHA:units = "none" ; SINALPHA:description = "Sine of rotation angle" ; float COSALPHA(Time, south_north, west_east) ; COSALPHA:units = "none" ; COSALPHA:description = "Cosine of rotation angle" ; float LANDMASK(Time, south_north, west_east) ; LANDMASK:units = "none" ; LANDMASK:description = "Landmask : 1=land, 0=water" ; float XLAT_C(Time, south_north_stag, west_east_stag) ; XLAT_C:units = "degrees latitude" ; XLAT_C:description = "Latitude at grid cell corners" ; float XLONG_C(Time, south_north_stag, west_east_stag) ; XLONG_C:units = "degrees longitude" ; XLONG_C:description = "Longitude at grid cell corners" ; float LANDUSEF(Time, land_cat, south_north, west_east) ; LANDUSEF:units = "category" ; LANDUSEF:description = "Noah-modified 21-category IGBP-MODIS landuse"; float LU_INDEX(Time, south_north, west_east) ; LU_INDEX:units = "category" ; LU_INDEX:description = "Dominant category" ; float HGT_M(Time, south_north, west_east) ; HGT_M:units = "meters MSL" ; HGT_M:description = "GMTED2010 30-arc-second topography height" ; float SOILTEMP(Time, south_north, west_east) ; SOILTEMP:units = "Kelvin" ; SOILTEMP:description = "Annual mean deep soil temperature" ; float SOILCTOP(Time, soil_cat, south_north, west_east) ; SOILCTOP:units = "category" ; SOILCTOP:description = "16-category top-layer soil type" ; float SCT_DOM(Time, south_north, west_east) ; SCT_DOM:units = "category" ; SCT_DOM:description = "Dominant category" ; float SOILCBOT(Time, soil_cat, south_north, west_east) ; SOILCBOT:units = "category" ; SOILCBOT:description = "16-category top-layer soil type" ; float SCB_DOM(Time, south_north, west_east) ; SCB_DOM:units = "category" ; SCB_DOM:description = "Dominant category" ; float ALBEDO12M(Time, month, south_north, west_east) ; ALBEDO12M:units = "percent" ; ALBEDO12M:description = "Monthly surface albedo" ; float GREENFRAC(Time, month, south_north, west_east) ; GREENFRAC:units = "fraction" ; GREENFRAC:description = "MODIS FPAR" ; float LAI12M(Time, month, south_north, west_east) ; LAI12M:units = "m^2/m^2" ; LAI12M:description = "MODIS LAI" ; float SNOALB(Time, south_north, west_east) ; SNOALB:units = "percent" ; SNOALB:description = "Maximum snow albedo" ; float SLOPECAT(Time, south_north, west_east) ; SLOPECAT:units = "category" ; SLOPECAT:description = "Dominant category" ; float CON(Time, south_north, west_east) ; CON:units = "" ; CON:description = "Subgrid-scale orographic convexity" ; float VAR(Time, south_north, west_east) ; VAR:units = "" ; VAR:description = "Subgrid-scale orographic variance" ; float OA1(Time, south_north, west_east) ; OA1:units = "" ; OA1:description = "Subgrid-scale orographic asymmetry" ;
// global attributes: :TITLE = "OUTPUT FROM GEOGRID V3.8" ; :SIMULATION_START_DATE = "0000-00-00_00:00:00" ; :WEST-EAST_GRID_DIMENSION = 74 ; :SOUTH-NORTH_GRID_DIMENSION = 61 ; :BOTTOM-TOP_GRID_DIMENSION = 0 ; :WEST-EAST_PATCH_START_UNSTAG = 1 ; :WEST-EAST_PATCH_END_UNSTAG = 73 ; :WEST-EAST_PATCH_START_STAG = 1 ; :WEST-EAST_PATCH_END_STAG = 74 ; :SOUTH-NORTH_PATCH_START_UNSTAG = 1 ; :SOUTH-NORTH_PATCH_END_UNSTAG = 60 ; :SOUTH-NORTH_PATCH_START_STAG = 1 ; :SOUTH-NORTH_PATCH_END_STAG = 61 ; :GRIDTYPE = "C" ; :DX = 30000.f ; :DY = 30000.f ; :DYN_OPT = 2 ; :CEN_LAT = 34.83001f ; :CEN_LON = -81.03f ; :TRUELAT1 = 30.f ; :TRUELAT2 = 60.f ; :MOAD_CEN_LAT = 34.83001f ; :STAND_LON = -98.f ; :POLE_LAT = 90.f ; :POLE_LON = 0.f ; :corner_lats = 28.17127f, 44.36657f, 39.63231f, 24.61906f, 28.17842f,44.37617f, 39.57812f, 24.57806f, 28.03771f, 44.50592f, 39.76032f, 24.49431f,28.04485f, 44.51553f, 39.70599f, 24.45341f ; :corner_lons = -93.64893f, -92.39661f, -66.00165f, -72.64047f, -93.80048f, -92.59155f, -65.83557f, -72.5033f, -93.65717f, -92.3829f, -65.9313f,-72.68539f, -93.80841f, -92.57831f, -65.76495f, -72.54843f ;
:MAP_PROJ = 1 ; :MMINLU = "MODIFIED_IGBP_MODIS_NOAH" ; :NUM_LAND_CAT = 21 ; :ISWATER = 17 ; :ISLAKE = 21 ; :ISICE = 15 ; :ISURBAN = 13 ; :ISOILWATER = 14 ; :grid_id = 1 ; :parent_id = 1 ; :i_parent_start = 1 ; :j_parent_start = 1 ; :i_parent_end = 74 ; :j_parent_end = 61 ; :parent_grid_ratio = 1 ; :FLAG_MF_XY = 1 ; :FLAG_LAI12M = 1 ; :FLAG_LAKE_DEPTH = 1 ;}
The global attributes corner_lats and corner_lons contain the lat-lon location of thecorners of the domain with respect to different grid staggerings (mass, u, v, andunstaggered). The locations referred to by each element of the corner_lats andcorner_lons arrays are summarized in the table and figure below.
In addition to the fields in a geogrid output file (e.g., geo_em.d01.nc), the followingfields and global attributes will also be present in a typical output file from the metgridprogram, run with the default METGRID.TBL file and meteorological data from NCEP'sGFS model.
netcdf met_em.d01.2016-04-07_00\:00\:00 {dimensions: Time = UNLIMITED ; // (1 currently) DateStrLen = 19 ; west_east = 73 ; south_north = 60 ; num_metgrid_levels = 27 ; num_st_layers = 4 ; num_sm_layers = 4 ; south_north_stag = 61 ; west_east_stag = 74 ; z-dimension0132 = 132 ; z-dimension0012 = 12 ; z-dimension0016 = 16 ; z-dimension0021 = 21 ;variables: char Times(Time, DateStrLen) ; float PRES(Time, num_metgrid_levels, south_north, west_east) ; PRES:units = "" ; PRES:description = "" ; float SOIL_LAYERS(Time, num_st_layers, south_north, west_east) ; SOIL_LAYERS:units = "" ; SOIL_LAYERS:description = "" ; float SM(Time, num_sm_layers, south_north, west_east) ; SM:units = "" ; SM:description = "" ; float ST(Time, num_st_layers, south_north, west_east) ; ST:units = "" ; ST:description = "" ; float GHT(Time, num_metgrid_levels, south_north, west_east) ; GHT:units = "m" ; GHT:description = "Height" ; float HGTTROP(Time, south_north, west_east) ; HGTTROP:units = "m" ; HGTTROP:description = "Height of tropopause" ; float TTROP(Time, south_north, west_east) ; TTROP:units = "K" ; TTROP:description = "Temperature at tropopause" ;
// global attributes: :TITLE = "OUTPUT FROM METGRID V3.8" ; :SIMULATION_START_DATE = "2016-04-07_00:00:00" ; :WEST-EAST_GRID_DIMENSION = 74 ; :SOUTH-NORTH_GRID_DIMENSION = 61 ; :BOTTOM-TOP_GRID_DIMENSION = 27 ; :WEST-EAST_PATCH_START_UNSTAG = 1 ; :WEST-EAST_PATCH_END_UNSTAG = 73 ; :WEST-EAST_PATCH_START_STAG = 1 ; :WEST-EAST_PATCH_END_STAG = 74 ; :SOUTH-NORTH_PATCH_START_UNSTAG = 1 ; :SOUTH-NORTH_PATCH_END_UNSTAG = 60 ; :SOUTH-NORTH_PATCH_START_STAG = 1 ; :SOUTH-NORTH_PATCH_END_STAG = 61 ; :GRIDTYPE = "C" ; :DX = 30000.f ; :DY = 30000.f ; :DYN_OPT = 2 ; :CEN_LAT = 34.83001f ; :CEN_LON = -81.03f ; :TRUELAT1 = 30.f ; :TRUELAT2 = 60.f ; :MOAD_CEN_LAT = 34.83001f ; :STAND_LON = -98.f ; :POLE_LAT = 90.f ; :POLE_LON = 0.f ; :corner_lats = 28.17127f, 44.36657f, 39.63231f, 24.61906f, 28.17842f,44.37617f, 39.57812f, 24.57806f, 28.03771f, 44.50592f, 39.76032f, 24.49431f,28.04485f, 44.51553f, 39.70599f, 24.45341f ; :corner_lons = -93.64893f, -92.39661f, -66.00165f, -72.64047f, -93.80048f, -92.59155f, -65.83557f, -72.5033f, -93.65717f, -92.3829f, -65.9313f,-72.68539f, -93.80841f, -92.57831f, -65.76495f, -72.54843f ; :MAP_PROJ = 1 ; :MMINLU = "MODIFIED_IGBP_MODIS_NOAH" ; :NUM_LAND_CAT = 21 ;
:ISWATER = 17 ; :ISLAKE = 21 ; :ISICE = 15 ; :ISURBAN = 13 ; :ISOILWATER = 14 ; :grid_id = 1 ; :parent_id = 1 ; :i_parent_start = 1 ; :j_parent_start = 1 ; :i_parent_end = 74 ; :j_parent_end = 61 ; :parent_grid_ratio = 1 ; :NUM_METGRID_SOIL_LEVELS = 4 ; :FLAG_METGRID = 1 ; :FLAG_EXCLUDED_MIDDLE = 0 ; :FLAG_SOIL_LAYERS = 1 ; :FLAG_SNOW = 1 ; :FLAG_PSFC = 1 ; :FLAG_SM000010 = 1 ; :FLAG_SM010040 = 1 ; :FLAG_SM040100 = 1 ; :FLAG_SM100200 = 1 ; :FLAG_ST000010 = 1 ; :FLAG_ST010040 = 1 ; :FLAG_ST040100 = 1 ; :FLAG_ST100200 = 1 ; :FLAG_SLP = 1 ; :FLAG_SNOWH = 1 ; :FLAG_SOILHGT = 1 ; :FLAG_UTROP = 1 ; :FLAG_VTROP = 1 ; :FLAG_TTROP = 1 ; :FLAG_PTROP = 1 ; :FLAG_PTROPNN = 1 ; :FLAG_HGTTROP = 1 ; :FLAG_UMAXW = 1 ; :FLAG_VMAXW = 1 ; :FLAG_TMAXW = 1 ; :FLAG_PMAXW = 1 ; :FLAG_PMAXWNN = 1 ; :FLAG_HGTMAXW = 1 ; :FLAG_MF_XY = 1 ; :FLAG_LAI12M = 1 ; :FLAG_LAKE_DEPTH = 1 ;}
• Introduction • Initialization for Ideal Data Cases • Initialization for Real Data Cases
The WRF model has two large classes of simulations that it is able to generate: those withan ideal initialization and those utilizing real data. The idealized simulations typicallymanufacture an initial condition file for the WRF model from an existing 1-D or 2-Dsounding and assume a simplified analytic orography. The real-data cases usually requirepre-processing from the WPS package, which provides each atmospheric and static fieldwith fidelity appropriate to the chosen grid resolution for the model. The WRF modelexecutable itself is not altered by choosing one initialization option over another(idealized vs. real), but the WRF model pre-processors (the real.exe and ideal.exeprograms) are specifically built based upon a user's selection.
The real.exe and ideal.exe programs are never used together. Both the real.exe andideal.exe are the programs that are processed just prior to the WRF model run.
o 2d • em_grav2d_x – gravity current, 100 m • em_hill2d_x – flow over a hill, 2 km • em_seabreeze2d_x – water and land, 2 km, full physics • em_squall2d_x – squall line, 250 m
o 1d • em_scm_xy – single column model, 4 km, full physics
The selection of the type of forecast is made when issuing the ./compile statement.When selecting a different case to study, the code must be re-compiled to choose thecorrect initialization for the model. For example, after configuring the setup for thearchitecture (with the ./configure command), if the user issues the command./compile em_real, then the initialization program is built usingmodule_initialize_real.F as the target module (one of the./WRFV3/dyn_em/module_initialize_*.F files). Similarly, if the userspecifies ./compile em_les, then the Fortran module for the large eddy simulation(module_initialize_les.F) is automatically inserted into the build for ideal.exe.Note that the WRF forecast model is identical for both of these initialization programs.In each of these initialization modules, the same sort of activities goes on:
• compute a base state / reference profile for geopotential and column pressure • compute the perturbations from the base state for geopotential and column pressure • initialize meteorological variables: u, v, potential temperature, vapor mixing ratio • define a vertical coordinate • interpolate data to the model's vertical coordinate • initialize static fields for the map projection and the physical surface; for many of the idealized cases, these are simplified initializations, such as map factors set to one, and topography elevation set to zero
Both the real.exe program and ideal.exe programs share a large portion of source code, tohandle the following duties:
• read meteorological and static input data from the WRF Preprocessing System (WPS) • prepare soil fields for use in the model (usually, vertical interpolation to the required levels for the specified land surface scheme)
• check to verify that soil categories, land use, land mask, soil temperature, sea surface temperature are all consistent with each other • multiple input time periods are processed to generate the lateral boundary conditions, which are required unless processing a global forecast • 3d boundary data (u, v, potential temperature, vapor mixing ratio, total geopotential) are coupled with total column pressure
The "real.exe" program may be run as either a serial or a distributed memory job. Sincethe idealized cases only require that the initialization run for a single time period (nolateral boundary file is required) and are, therefore, quick to process, all of the "ideal.exe"programs should be run on a single processor. The Makefile for the 2-D cases will notallow the user to build the code with distributed memory parallelism. For large 2-Dcases, if the user requires OpenMP, the variables nproc_x and nproc_y must be set inthe domains portion of the namelist file namelist.input (nproc_y must be setto 1, and nproc_x then set to the number of processors).
The program "ideal.exe" is the program in the WRF system that allows a user to run acontrolled scenario. Typically this program requires no input except for thenamelist.input and the input_sounding files (except for the b_wave casewhich uses a 2-D binary sounding file). The program outputs the wrfinput_d01 filethat is read by the WRF model executable ("wrf.exe"). Since no external data is requiredto run the idealized cases, even for researchers interested in real-data cases, the idealizedsimulations are an easy way to insure that the model is working correctly on a particulararchitecture and compiler.
Idealized runs can use any of the boundary conditions except "specified", and arenot, by default, set up to run with sophisticated physics (other than from microphysics).Most have no radiation, surface fluxes or frictional effects (other than the sea breeze case,LES, and the global Held-Suarez). The idealized cases are mostly useful for dynamicalstudies, reproducing converged or otherwise known solutions, and idealized cloudmodeling.
There are 1-D, 2-D and 3-D examples of idealized cases, with and without topography,and with and without an initial thermal perturbation. The namelist can control the size ofthe domain, number of vertical levels, model top height, grid size, time step, diffusionand damping properties, boundary conditions, and physics options. A large number ofexisting namelist settings are already found within each of the directories associated witha particular case.
The input_sounding file (already in appropriate case directories) can be any set oflevels that goes at least up to the model top height (ztop) in the namelist. The first lineincludes the surface pressure (hPa), potential temperature (K) and moisture mixing ratio
(g/kg). Each subsequent line has five input values: height (meters above sea-level),potential temperature (K), vapor mixing ratio (g/kg), x-direction wind component (m/s),and y-direction wind component (m/s). The "ideal.exe" program interpolates the datafrom the input_sounding file, and will extrapolate if not enough data is provided.
The base state sounding for idealized cases is the initial sounding, minus the moisture,and therefore does not have to be defined separately. Note for the baroclinic wave case: a1-D input sounding is not used because the initial 3-D arrays are read-in from the fileinput_jet. This means for the baroclinic wave case, the namelist.input filecannot be used to change the horizontal or vertical dimensions since they are specified inthe input_jet file.
Each of the ideal cases provides an excellent set of default examples to the user. Themethod to specify a thermal bubble is given in the super cell case. In the hill2d case, thetopography is accounted for properly in setting up the initial 3-D arrays, so that exampleshould be followed for any topography cases. A symmetry example in the squall linecases tests that your indexing modifications are correct. Full physics options aredemonstrated in the seabreeze2d_x case.
The real-data WRF cases are those that have the input data to the "real.exe" programprovided by the WRF Preprocessing System (WPS). This data from the WPS wasoriginally generated from a previously-run external analysis or forecast model. Theoriginal data was most-likely in GriB format and was most-likely ingested into the WPSby first ftp'ing the raw GriB data from one of the national weather agencies' anonymousftp sites.
For example, suppose a single-domain WRF forecast is desired, with the followingcriteria:
The following coarse-grid files will be generated by the WPS (starting date throughending date, at 6-h increments):
• met_em.d01.2000-01-24_12:00:00.nc • met_em.d01.2000-01-24_18:00:00.nc • met_em.d01.2000-01-25_00:00:00.nc • met_em.d01.2000-01-25_06:00:00.nc • met_em.d01.2000-01-25_12:00:00.nc
The convention is to use "met" to signify data that is output from the WPS "metgrid.exe"program and input into the "real.exe" program. The "d01" portion of the name identifiesto which domain this data refers, which permits nesting. The next set of characters is thevalidation date/time (UTC), where each WPS output file has only a single time-slice ofprocessed data. The file extension suffix ".nc" refers to the output format from WPSwhich must be in netCDF for the "real.exe" program. For regional forecasts, multipletime periods must be processed by "real.exe" so that a lateral boundary file is available tothe model. The global option for WRF requires only an initial condition.
The WPS package delivers data that is ready to be used in the WRF system by the"real.exe" program.
• The data adheres to the WRF IO API. Unless you are developing special tools, stick with the netCDF option to communicate between the WPS package and "real.exe". • The data has already been horizontally interpolated to the correct grid-point staggering for each variable, and the winds are correctly rotated to the WRF model map projection. • 3-D meteorological data required from the WPS: pressure, u, v, temperature, relative humidity, geopotential height • Optional 3-D hydrometeor data may be provided to the real program at run-time, but these fields will not be used in the coarse-grid lateral boundary file. Fields named: QR, QC, QS, QI, QG, QH, QNI (mixing ratio for rain, cloud, snow, ice, graupel, hail, and number concentration) are eligible for input from the metgrid output files. • 3D soil data from the WPS: soil temperature, soil moisture, soil liquid (optional, depending on physics choices in the WRF model) • 2D meteorological data from the WPS: sea level pressure, surface pressure, surface u and v, surface temperature, surface relative humidity, input elevation • 2-D meteorological optional data from WPS: sea surface temperature, physical snow depth, water equivalent snow depth • 2D static data for the physical surface: terrain elevation, land use categories, soil texture categories, temporally-interpolated monthly data, land sea mask, elevation of the input model's topography • 2D static data for the projection: map factors, Coriolis, projection rotation, computational latitude • constants: domain size, grid distances, date • The WPS data may either be isobaric or some more-generalized vertical coordinate, where each column is monotonic in pressure • All 3-D meteorological data (wind, temperature, height, moisture, pressure) must have the same number of levels, and variables must have the exact same levels. For example, it is not acceptable to have more levels for temperature (for example) than height. Likewise, it is not acceptable to have an extra level for the horizontal wind components, but not for moisture.
• A test data set is accessible from the WRF download page. Under the "WRF Model Test Data" list, select the January data. This is a 74x61, 30-km domain centered over the eastern US. • Make sure you have successfully built the code (fine-grid nested initial data is available in the download, so the code may be built with the basic nest option), ./WRFV3/main/real.exe and ./WRFV3/main/wrf.exe must both exist. • In the ./WRFV3/test/em_real directory, copy the namelist for the January case to the default name
o cp namelist.input.jan00 namelist.input
• Link the WPS files (the "met_em*" files from the download) into the ./WRFV3/test/em_real directory. • For a single processor, to execute the real program, type real.exe (this should take less than a minute for this small case with five time periods). • After running the "real.exe" program, the files "wrfinput_d01" and "wrfbdy_d01" should be in this directory; these files will be directly used by the WRF model. • The "wrf.exe" program is executed next (type wrf.exe), this should only take a few minutes (only a 12-h forecast is requested in the namelist file). • The output file wrfout_d01:2000-01-24_12:00:00 should contain a 12- h forecast at 3-h intervals.
• Since a new simple ocean model has been included in the WRF code, the old namelist option for activating an ocean mixed layer is no longer suitable. The variable OMLCALL has been switched to SF_OCEAN_PHYSICS. • The default behavior of the base state has been modified. Starting with release version 3.5, the isothermal temperature is no longer zero. With this change, the base state temperature no longer gets colder than 200 K (default in the Registry, though a user can override this option with a namelist setting). This fixes the problem associated with layers being too thick near the model top. A side effect of thinning-out these model layers is that users may need to increase the number of vertical levels. • The common availability of a valid seaice field in the input provided from the metgrid program has made obsolete the option to autoconvert "cold enough" water points to seaice. By default, the temperature at which water converts to seaice is now 100 K, a temperature cold enough that the option will never be triggered.
• Introduction • Installing WRF • Running WRF o Idealized Case o Real Data Case o Restart Run o Two-Way Nested Runs o One-Way Nested Run Using ndown o Moving Nested Run o Three-dimensional Analysis Nudging o Observation Nudging o Global Run o DFI Run o SST Update o Using bucket_mm and bucket_J options o Adaptive Time Stepping o Stochastic Kinetic-Energy Backscatter Option o Run-Time IO o Output Time Series o Using IO Quilting • Examples of namelists for various applications • Check Output • Trouble Shooting • Physics and Dynamics Options • Summary of PBL Physics Options • Summary of Microphysics Options • Summary of Cumulus Parameterization Options • Summary of Radiation Options • Description of Namelist Variables • WRF Output Fields • Special WRF Output Variables
The WRF model is a fully compressible and nonhydrostatic model (with a run-timehydrostatic option). Its vertical coordinate is a terrain-following hydrostatic pressurecoordinate. The grid staggering is the Arakawa C-grid. The model uses the Runge-Kutta2nd and 3rd order time integration schemes, and 2nd to 6th order advection schemes in
both the horizontal and vertical. It uses a time-split small step for acoustic and gravity-wave modes. The dynamics conserves scalar variables.
The WRF model code contains an initialization program (either for real-data, real.exe, oridealized data, ideal.exe; see Chapter 4), a numerical integration program (wrf.exe), aprogram to do one-way nesting (ndown.exe), and a program to do tropical stormbogussing (tc.exe). The WRF model, Version 3, supports a variety of capabilities. Theseinclude
Other References
Installing WRF
Before compiling the WRF code on a computer, check to see if the netCDF library isinstalled. This is because one of the supported WRF I/O options is netCDF, and it is theone commonly used and supported by the post-processing programs. If the netCDF isinstalled in a directory other than /usr/local/, then find the path, and use theenvironment variable NETCDF to define where the path is. To do so, type
Often the netCDF library and its include/ directory are collocated. If this is not the case,create a directory, link both netCDF lib and include directories in this directory, and usethe environment variable to set the path to this directory. For example,
If the netCDF library is not available on the computer, it needs to be installed first.NetCDF source code or pre-built binary may be downloaded from, and installationinstruction can be found on, the Unidata Web page at http://www.unidata.ucar.edu/.
If PGI, Intel, gfortran or g95 compilers are are used on a Linux computer, make surenetCDF is installed using the same compiler. Use the NETCDF environment variable topoint to the PGI/Intel/g95 compiled netCDF library.
Hint: If using netCDF-4, make sure that the new capabilities (such as parallel I/O basedon HDF5) are not activated at the install time, unless you intend to use the compressioncapability from netCDF-4 (supported in V3.5. More info below).
and a list of choices for your computer should appear. These choices range fromcompiling for a single processor job (serial), to using OpenMP shared-memory (smpar)or distributed-memory parallelization (dmpar) options for multiple processors, or acombination of shared-memory and distributed-memory options (dm+sm). When aselection is made, a second choice for compiling nesting will appear. For example, on aLinux computer, the above steps may look like:
-----------------------------------------------------------------------Please select from among the following Linux ARCH options:
Enter the appropriate options that are best for your computer and application.
When the return key is hit, a configure.wrf file will be created. Edit compileoptions/paths, if necessary.
Hint: It is helpful to start with something simple, such as the serial build. If it issuccessful, move on to build smpar or dmpar code. Remember to type 'clean –a' betweeneach build.
Hint: If you anticipate generating a netCDF file that is larger than 2Gb (whether it is asingle- or multi-time period data [e.g. model history]) file), you may set the followingenvironment variable to activate the large-file support option from netCDF (in c-shell):
setenv WRFIO_NCD_LARGE_FILE_SUPPORT 1
Hint: If you would like to use parallel netCDF (p-netCDF) developed by ArgonneNational Lab (http://trac.mcs.anl.gov/projects/parallel-netcdf), you will need to install p-netCDF separately, and use the environment variable PNETCDF to set the path:
Hint: Since V3.5, compilation may take a bit longer due to the addition of the CLM4module. If you do not intend to use the CLM4 land-surface model option, you canmodify your configure.wrf file by removing -DWRF_USE_CLM fromARCH_LOCAL.
compile em_b_wave compile em_convrad (new in V3.7) compile em_esmf_exp (example only) compile em_grav2d_x compile em_heldsuarez compile em_hill2d_x compile em_les compile em_quarter_ss compile em_real compile em_seabreeze2d_x compile em_squall2d_x compile em_squall2d_y compile em_tropical_cyclone compile em_tropical_cyclone compile exp_real (example of a toy solver) compile nmm_real (NMM solver)
where em stands for the Advanced Research WRF dynamic solver (which currently is the'Eulerian mass-coordinate' solver). Type one of the above to compile. When you switchfrom one test case to another, you must type one of the above to recompile. Therecompile is necessary to create a new initialization executable (i.e. real.exe, andideal.exe - there is a different ideal.exe for each of the idealized test cases),while wrf.exe is the same for all test cases.
If you want to remove all object files (except those in the external/ directory) andexecutables, type 'clean'.
Hint: If you have trouble compiling routines, like solve_em.F, you can try to run theconfigure script with the optional argument '-s', i.e.
./configure –s
This will configure to compile solve_em.F and a few other routines with reducedoptimization.
If you would like to turn off optimization for all the code, say during code developmentand debugging, you can run the configure script with option '-d':
./configure –d
Beginning with V3.5, the compression function in netCDF4 is supported. This option willtypically reduce the file size by more than 50%. It will require netCDF4 to be installedwith the option --enable-netcdf-4. Before compiling WRF, you will need to setthe environment variable NETCDF4. In a C-shell environment, type setenv NETCDF41, followed by 'configure' and 'compile'.
a. Idealized case
For any 2D test case (labeled in the case names), serial or OpenMP (smpar) compileoptions must be used. Additionally, you must only choose the '0=no nesting' optionwhen you configure. For all other cases, you may use serial or parallel (dmpar) andnesting. Suppose you would like to compile and run the 2-dimensional squall case, type
After a successful compilation, you should have two executables created in the main/directory: ideal.exe and wrf.exe. These two executables will be linked to thecorresponding test/case_name and run/ directories. cd to either directory to run themodel.
It is a good practice to save the entire compile output to a file. When the executables arenot present, this output is useful to help diagnose the compile errors.
b. Real-data case
When the compile is successful, it will create three executables in the main/directory:ndown.exe, real.exe and wrf.exe.
Like in the idealized cases, these executables will be linked to the test/em_real andrun/ directories. cd to one of these two directories to run the model.
Running WRF
One may run the model executables in either the run/ directory, or thetest/case_name directory. In either case, one should see executables ideal.exeor real.exe (and ndown.exe), and wrf.exe, linked files (mostly for real-datacases), and one or more namelist.input files in the directory.
Hint: If you would like to run the model executables in a different directory, copy or linkthe files in the test/em_* directory to that directory, and run from there.
cd test/em_squall2d_x
If you see a script in the test case directory, called run_me_first.csh, run this onefirst by typing:
This links some physics data files that might be needed to run the case.
*Note: when running em_fire, you must copy everything from the 'hill_simple' directoryinto your current working directory in order for it to run correctly.
cp hill_simple/* .
This program will typically read an input sounding file located in that directory, andgenerate an initial condition file wrfinput_d01. All idealized cases do not require alateral boundary file because of the boundary condition choices they use, such as theperiodic option. If the job is run successfully, the last thing it prints should be: 'wrf:SUCCESS COMPLETE IDEAL INIT'.
To run the model and save the standard output to a file, type
Pairs of rsl.out.* and rsl.error.* files will appear with any MPI runs. Theseare standard out and error files. Note that the execution command for MPI runs may bedifferent on different machines and for different MPI installation. Check the user manual.
If the model run is successful, the last thing printed in the 'wrf.out' or rsl.*.0000files should be: 'wrf: SUCCESS COMPLETE WRF'. Output fileswrfout_d01_0001-01-01* and wrfrst* should be present in the run directory,depending on how namelist variables are specified for output. The time stamp on thesefiles originates from the start times in the namelist file.
Start with the namelist.input template file in the directory and edit it to match yourcase.
Running a real-data case requires successfully running the WRF Preprocessing Systemprograms (or WPS). Make sure met_em.* files from WPS are seen in the run directory(either link or copy the files):
cd test/em_realls –l ../../../WPS/met_em*ln –s ../../..WPS/met_em* .
Make sure you edit the variables in the &time_control and &domains sections of thenamelist.input file (the description of the namelists can be found in the later part ofthis chapter):
&time_control run_days = 0, run_hours = 24, run_minutes = 0, run_seconds = 0, start_year = 2000, 2000, 2000, start_month = 01, 01, 01, start_day = 24, 24, 24, start_hour = 12, 12, 12, end_year = 2000, 2000, 2000, end_month = 01, 01, 01, end_day = 25, 25, 25, end_hour = 12, 12, 12, interval_seconds = 21600 input_from_file = .true.,.true.,.true., history_interval = 180, 60, 60, frames_per_outfile = 1000, 1000, 1000,/
&domains time_step = 180, max_dom = 1, e_we = 74, 112, 94, e_sn = 61, 97, 91, e_vert = 30, 30, 30, p_top_requested = 5000, num_metgrid_levels = 27, num_metgrid_soil_levels = 4, dx = 30000, 10000, 3333.33, dy = 30000, 10000, 3333.33, grid_id = 1, 2, 3, parent_id = 0, 1, 2, i_parent_start = 1, 31, 30, j_parent_start = 1, 17, 30, parent_grid_ratio = 1, 3, 3, parent_time_step_ratio = 1, 3, 3,
Make sure that the dates and dimensions of the domain match those set in WPS. If onlyone domain is used, namelists in other columns can be ignored.
interp_type = 2 extrap_type = 2 t_extrap_type = 2 lowest_lev_from_sfc = .false. use_levels_below_ground = .true. use_surface = .true. lagrange_order = 1 force_sfc_in_vinterp = 1 zap_close_levels = 500 sfcp_to_sfcp = .false. adjust_heights = .false. smooth_cg_topo = .false.
To run the real-data initialization program, compiled using serial or OpenMP (smpar)options, type
Successful completion of the job should have 'real_em: SUCCESS EM_REAL INIT'printed at the end of the real.out file. It should also produce wrfinput_d01 andwrfbdy_d01 files. In the real data case, both files are required.
A successful run should produce one or several output files with names likewrfout_d<domain>_<date> (where <domain> represents domain ID, and<date> represents a date string with the format yyyy-mm-dd_hh:mm:ss. Forexample, if you start the model at 1200 UTC, January 24 2000, then your first output fileshould have the name:
The time stamp on the file name is always the first time the output file is written. It isalways good to check the times written to the output file by typing:
You may have other wrfout files, depending on the namelist options (how often you splitthe output files is determined by the namelist option frames_per_outfile). Youmay also create restart files if you have a restart frequency (restart_interval in
the namelist.input file) set within your total integration time. The restart file(s) shouldhave the following naming convention
The time stamp on a restart file is the time at which that restart file is valid.
For DM (distributed memory) parallel systems, some form of the mpirun command willbe needed to run the executables. For example, on a Linux cluster, the command to runMPI code, using 4 processors, may look like:
poe ./real.exepoe ./wrf.exe
c. Restart Run
A restart run allows a user to extend a run to a longer simulation period. It is effectively acontinuous run made of several shorter runs. Hence the results at the end of one or morerestart runs should be identical to a single run without any restart.
In order to do a restart run, one must first create a restart file. This is done by setting thenamelist variable restart_interval (unit is in minutes) to be equal to or less thanthe simulation length in the first model run, as specified by run_* variables orstart_* and end_* times. When the model reaches the time to write a restart file, arestart file named wrfrst_d<domain>_<date> will be written. The date stringrepresents the time when the restart file is valid.
When one starts the restart run, edit the namelist.input file, so that your start_*time will be set to the restart time (which is the time the restart file is written). The othernamelist variable one must set is restart, this variable should be set to .true. for arestart run.
start_*, end_*: start and end times for restart model integrationrestart: logical to indicate whether the run is a restart or not
If the history and restart intervals are changed in a restart run, and the outcome isn't whatis expected to be, use namelist 'override_restart_timers = .true.'.
Hint: Typically the restart file is a lot bigger in size than the history file, hence one mayfind that it is even ok to write a single model history output time to a file in netCDFformat (frame_per_outfile=1), but it may fail to write a restart file. This isbecause the basic netCDF file support is only 2Gb. There are two solutions to theproblem. The first is to simply set the namelist option io_form_restart = 102(instead of 2), and this will force the restart file to be written into multiple pieces, one perprocessor. As long as one restarts the model using the same number of processors, thisoption works well (and one should restart the model with the same number of processorsin any case). The second solution is to recompile the code using the netCDF large filesupport option (see the section on "Installing WRF" in this chapter).
A two-way nested run is a run in which multiple domains at different grid resolutions arerun simultaneously and communicate with each other: The coarser domain providesboundary values for the nest, and the nest feeds its calculation back to the coarserdomain. The model can handle multiple domains at the same nest level (no overlappingnest), and multiple nest levels (telescoping).
When preparing for a nested run, make sure that the code is compiled with basic nestoptions (option 1).
Most of options to start a nest run are handled through the namelist. All variables in thenamelist.input file that have multiple columns of entries need to be edited withcaution. Start with a namelist template. The following are the key namelist variables tomodify:
start_*, end_*: start and end simulation times for the nest
fine_input_stream: which fields from the nest input file are used in nestinitialization. The fields to be used are defined in the Registry.EM. Typically they includestatic fields (such as terrain and landuse), and masked surface fields (such as skintemperature, soil moisture and temperature). Useful for a nest starting at a later time thanthe coarse domain.
max_dom: the total number of domains to run. For example, if you want to have onecoarse domain and one nest, set this variable to 2.grid_id: domain identifier that is used in the wrfout naming convention. The mostcoarse grid must have grid_id of 1.parent_id: used to indicate the parent domain of a nest. grid_id value is used.i_parent_start/j_parent_start: lower-left corner starting indices of the nestdomain in its parent domain. These parameters should be the same as innamelist.wps.parent_grid_ratio: integer parent-to-nest domain grid size ratio. Typically an oddnumber ratio is used in real-data applications.parent_time_step_ratio: integer time-step ratio for the nest domain. It may bedifferent from the parent_grid_ratio, though they are typically set the same.feedback: this is the key setup to define a two-way nested (or one-way nested) run.When feedback is on, the values of the coarse domain are overwritten by the values of thevariables (average of cell values for mass points, and average of the cell-face values forhorizontal momentum points) in the nest at the coincident points. For masked fields, onlythe single point value at the collocating points is fed back. If theparent_grid_ratio is even, an arbitrary choice of the southwest corner point valueis used for feedback. This is the reason it is better to use an odd parent_grid_ratiowith this option. When feedback is off , it is equivalent to a one-way nested run, sincenest results are not reflected in the parent domain.smooth_option: this a smoothing option for the parent domain in the area of the nestif feedback is on. Three options are available: 0 = no smoothing; 1 = 1-2-1 smoothing; 2= smoothing-desmoothing.
For 3-D idealized cases, no nest input files are required. The key here is the specificationof the namelist.input file. What the model does is to interpolate all variablesrequired in the nest from the coarse domain fields. Set
input_from_file = T, F,
For real-data cases, three input options are supported. The first one is similar to runningthe idealized cases. That is to have all fields for the nest interpolated from the coarsedomain (input_from_file = T, F). The disadvantage of this option is obvious:one will not benefit from the higher resolution static fields (such as terrain, landuse, andso on).
The second option is to set input_from_file = T for each domain, which meansthat the nest will have a nest wrfinput file to read in. The limitation of this option is thatthis only allows the nest to start at the same time as the coarse domain.
The third option is, in addition to setting input_from_file = T for each domain,also set fine_input_stream = 2 for each domain. Why a value of 2? This is basedon the Registry setting, which designates certain fields to be read in from the auxiliaryinput stream number 2. This option allows the nest initialization to use 3-Dmeteorological fields interpolated from the coarse domain, static fields and masked, andtime-varying surface fields from the nest wrfinput; hence it allows a nest to start at a latertime than hour 0. Setting fine_input_stream = 0 is equivalent to the secondoption.
To run real.exe for a nested run, one must first run WPS and create data for all thenests. Suppose WPS is run for a 24 hour period, two-domain nested case starting at 1200UTC Jan 24 2000. Then the following files should be generated in a WPS directory:
Typically only the first time period of the nest input file is needed to create a nestwrfinput file. Link or move all these files to the run directory.
Edit the namelist.input file and set the correct values for all relevant variables,described on the previous pages (in particular, set max_dom = 2, for the total numberof domains to run), as well as physics options. Type the following to run:
If successful, this will create all input files for coarse, as well as nested domains. For atwo-domain example, these are created:
./wrf.exeormpirun –np 4 ./wrf.exe
If successful, the model should create wrfout files for both domain 1 and 2:
WRF supports two separate one-way nested options. In this section, one-way nesting isdefined as a finer-grid-resolution run, made as a subsequent run after the coarser-grid-resolution run, where the ndown program is run in-between the two simulations. Theinitial and lateral boundary conditions for this finer-grid run are obtained from the coarsegrid run, with input from higher resolution terrestrial fields (e.g. terrain, landuse, etc.),and masked surface fields (such as soil temperature and moisture). The program thatperforms this task is ndown.exe.
*Note that the use of this program requires the code to be compiled for nesting.
When one-way nesting is used, the coarse-to-fine grid ratio is only restricted to be aninteger. An integer less than or equal to 5 is recommended. Frequent output (e.g. hourly)from the coarse grid run is also recommended to provide better boundary specifications.Do not change physics options when running ndown (you can change some physicsoptions when making wrf runs), and do not remove fields from Registry if you plan touse ndown.
This is no different than any of the single-domain WRF runs, as described above. Dooutput history files as often as you can, and this will provide better and more frequentboundary conditions for the next model run.
Step 2: Run geogrid.exe (gives geo_em.d01 and geo_em.d02 files) and metgrid.exe fortwo domains (as if you are making a 2-way nested run).
This will generate WPS output files for domain 1 (met_em.d01.<date>) and domain2 (met_em.d02.<date>).
The purpose of this step is to ingest higher resolution terrestrial fields and correspondingland-water masked soil fields.
- Copy the met_em* files into the directory from which you will be running real.exe. - Edit the namelist.input file, changing 'max_dom = 2', and making sure columns 1 and 2 are set-up for a 2 domain run, editting the correct start time and grid dimensions. - Run real.exe. This will produce a wrfinput_d01 file, a wrfinput_d02
Step 4: Make the final fine-grid initial and boundary condition files, by runningndown.exe
Note that the program ndown may be run serially or in MPI, depending on the selectedcompile option. The ndown program must be built to support nesting, however. To runthe program, type
./ndown.exeormpirun –np 4 ./ndown.exe
- The WRF model's physics options may be modified between runs (the WRF model before ndown and the WRF model after ndown, but do use the same physics from the first run when running ndown), except generally for the land surface scheme option
which has different number of soil depths depending on the scheme. Users may take advantage of a feature that allows both the initial and lateral boundaries to use the moist and scalar arrays (have_bcs_moist and have_bcs_scalar, respectively). This option is only to be used during the WRF model run which follows the ndown processing. With this option, a user must keep the microphysics options the same between forecasts. The advantage is that the previous WRF model provides realistic lateral boundary tendencies for all of the microphysical variables, instead of a simple "zero inflow" or "zero gradient outflow". - Run WRF for this grid. *Keep in mind that the output from this run will be in the form wrfout_d01* but it will actually be output for domain 2. It may help to rename these to avoid future confusion.
The figure on the next page summarizes the data flow for a one-way nested run using theprogram ndown.
f. Moving-Nested Run
Two types of moving tests are allowed in WRF. In the first option, a user specifies thenest movement in the namelist. The second option is to move the nest automatically,based on an automatic vortex-following algorithm. This option is designed to follow themovement of a well-defined tropical cyclone.
To make the specified moving nested run, select the right nesting compile option (option'preset moves'). Note that code compiled with this option will not support static nestedruns. To run the model, only the coarse grid input files are required. In this option, thenest initialization is defined from the coarse grid data - no nest input is used. In additionto the namelist options applied to a nested run, the following needs to be added to thenamelist section &domains:
num_moves: the total number of moves one can make in a model run. A move of anydomain counts against this total. The maximum is currently set to 50, but it can bechanged by changing MAX_MOVES in frame/module_driver_constants.F.move_id: a list of nest IDs, one per move, indicating which domain is to move for agiven move.move_interval: the number of minutes from the beginning of the run until a moveis supposed to occur. The nest will move on the next time step after the specified instantof model time has passed.move_cd_x,move_cd_y: distance in the number of grid points and direction of thenest move (positive numbers indicate moving toward east and north, while negativenumbers indicate moving toward west and south).
Parameter max_moves is set to be 50, but can be modified in the source code fileframe/module_driver_constants.F, if needed.
To make the automatic moving nested runs, select the 'vortex-following' option whenconfiguring. Again note that this compile would only support the auto-moving nest, andwill not support the specified moving nested run or static nested run at the same time.Again, no nest input is needed. If one wants to use values other than the default ones, addand edit the following namelist variables in the &domains section:
time_to_move: the time (in minutes) to move a nest. This option may help with thecase when the storm is still too weak to be tracked by the algorithm.
When the automatic moving nest is employed, the model dumps the vortex centerlocation, with minimum mean sea-level pressure and maximum 10-m winds in a standard-out file (e.g. rsl.out.0000). Typing 'grep ATCF rsl.out.0000' will produce alist of storm information at a 15-minute interval:
In both types of moving-nest runs, the initial location of the nest is specified throughi_parent_start and j_parent_start in the namelist.input file.
setenv TERRAIN_AND_LANDUSE 1
Prepare input data to WRF as usual using WPS. If nudging is desired in the nest domains,make sure all time periods for all domains are processed in WPS. For surface-analysisnudging (new in Version 3.1), OBSGRID needs to be run after METGRID, and it willoutput a wrfsfdda_d01 file that the WRF model reads for this option.
Set the following options before running real.exe, in addition to others describedearlier (see the namelists in examples.namelist in the test/em_real/directory, for guidance):
grid_fdda = 1
grid_sfdda = 1
Run real.exe as before, and this will create, in addition to wrfinput_d0* andwrfbdy_d01 files, a file named 'wrffdda_d0*'. Other grid-nudging namelists areignored at this stage, but it is good practice to fill them all in before one runs real. Inparticular, set
gfdda_inname = "wrffdda_d<domain>"gfdda_interval = time interval of input data in minutesgfdda_end_h = end time of grid-nudging in hours
sgfdda_inname = "wrfsfdda_d<domain>"sgfdda_interval = time interval of input data in minutessgfdda_end_h = end time of surface grid-nudging in hours
A different surface data nudging option is added in V3.8, and activated by setting
grid_sfdda = 2
This option nudges surface air temperature and water vapor mixing ratio similar to thatwith option 1, but uses the tendencies generated from the direct nudging approach toconstrain surface sensible and latent heat fluxes, thus ensuring thermodynamicconsistency between the atmosphere and land surface. This works with YSU PBL andNoah LSM. (Alapaty et al. JAMC, 2008)
Spectral Nudging is a new upper-air nudging option since Version 3.1. This selectivelynudges the coarser scales only, but is otherwise set up the same way as grid-nudging.This option also nudges geopotential height. The wave numbers defined here are thenumber of waves contained in the domain, and the number is the maximum one that isnudged.
grid_fdda = 2xwavenum = 3ywavenum = 3
In addition to the usual input data preparation using WPS, station observation files arerequired. See the Observation Nudging User's Guide andhttp://www2.mmm.ucar.edu/wrf/users/wrfv3.1/How_to_run_obs_fdda.html for details.The observation file names expected by WRF are OBS_DOMAIN101 for domain 1, andOBS_DOMAIN201 for domain 2, etc.
obs_nudge_opt = 1fdda_start = 0 (obs nudging start time in minutes)fdda_end = 360 (obs nudging end time in minutes)
and in &time_control
Look for an example to set other obs nudging namelist variables in the fileexamples.namelists in test/em_real/ directory. See The ObservationNudging User's Guide,http://www2.mmm.ucar.edu/wrf/users/wrfv3.1/How_to_run_obs_fdda.html, andREADME.obs_fdda in WRFV3/test/em_real/ for more information.
i. Global Run
WRFV3 supports global capability. To make a global run, run WPS, starting with thenamelist template namelist.wps.gloabl. Set map_proj = 'lat-lon', andgrid dimensions e_we and e_sn without setting dx and dy innamelist.wps. The geogrid program will calculate grid distances, and their valuescan be found in the global attribute section of geo_em.d01.nc file. Typencdump –h geo_em.d01.nc to find out the grid distances, which will be needed infilling out WRF's namelist.input file. Grid distances in x and y directions may bedifferent, but it is best that they are set similarly or the same. WRF and WPS assume theearth is a sphere, and its radius is 6370 km. There are no restrictions on what to use forgrid dimensions, but for effective use of the polar filter in WRF, the east-west dimensionshould be set to 2P*3Q*5R+1 (where P, Q, and R are any integers, including 0).
Run the rest of the WPS programs as usual but only for one time period. This is becausethe domain covers the entire globe, and lateral boundary conditions are no longer needed.
Run the program real.exe as usual and for one time period only. The lateral boundaryfile wrfbdy_d01 is not needed.
Note: since this is not a commonly-used configuration in the model, use it with caution.Not all physics and diffusion options have been tested with it, and some options may notwork well with polar filters. Also, positive-definite and monotonic advection options donot work with polar filters in a global run because polar filters can generate negative
values of scalars. This implies, too, that WRF-Chem cannot be run with positive-definiteand monotonic options in a global WRF setup.
As an extension to the global lat-lon grid, the regional domain can also be set using a lat-lon grid. To do so, one needs to set both grid dimensions, and grid distances in degrees.Again geogrid will calculate the grid distance, assuming the earth is a sphere and itsradius is 6370 km. Find the grid distance in meters in the netCDF file, and use the valuefor WRF's namelist.input file.
Digital filter initialization (DFI) is a new option in V3. It is a way to remove initial modelimbalance as, for example, measured by the surface pressure tendency. This might beimportant when one is interested in the 0 – 6 hour simulation/forecast. It runs a digitalfilter during a short model integration, backward and forward, and then starts the forecast.In WRF implementation, this is all done in a single job. With the V3.3 release, DFI canbe used for multiple domains with concurrent nesting, with feedback disabled.
Start with the namelist template namelist.input.dfi. This namelist file containsan extra namelist record for DFI: &dfi_control. Edit it to match your caseconfiguration. For a typical application, the following options are used:
In Version 3.2, a constant boundary condition option is introduced for DFI. To use it, setconstant_bc = 1 in &bdy_control
If a different time step is used for DFI, one may use time_step_dfi to set it.
The WRF model physics do not predict sea-surface temperature, vegetation fraction,albedo or sea ice. For long simulations, the model provides an alternative to read-in thetime-varying data and to update these fields. In order to use this option, one must haveaccess to time-varying SST and sea ice fields. Twelve monthly values of vegetationfraction and albedo are available from the geogrid program. Once these fields are
processed via WPS, one may activate the following options in the namelist record&time_control before running the program real.exe and wrf.exe:
io_form_auxinput4 =2auxinput4_inname = "wrflowinp_d<domain>" (created by real.exe)auxinput4_interval = 360, 360, 360,
and in &physics
sst_update = 1
These options are for long simulation rainfall accumulations and radiation budgetaccumulation terms (RAINC, RAINNC, ACSWUPT, ACLWDNBC, etc.). With 32-bitaccuracy, adding small numbers to very large numbers loses accuracy as theaccumulation term increases. For simulations of days to weeks, the accumulations areusually okay, but for months to years, this has the effect of truncating the additions, andespecially small ones may be zeroed-out.
When these options are activated, part of the term is stored in an integer that incrementsby 1 each time the bucket value is reached, so we have two terms - RAINNC andI_RAINNC, where RAINNC now only contains the remainder. The total is retrievedfrom the output with total = RAINNC+bucket_mm*I_RAINNC. A reasonable bucketvalue may be based on a monthly accumulation such as 100 mm. Total precipitationequals RAINC + RAINNC, where
The radiation accumulation terms (e.g., ACSWUPT) are in Joules/m^2, so that the meanvalue over a simulation period is the difference divided by the time between, givingW/m^2.
The bucket_J option is for these terms, and the typical value, based on a monthlyaccumulation, is 1.e9 J. Here the total is given by (ACSWUPT example - other radiativeterms would follow the same equation concept):
total = ACSWUPT+bucket_J*I_ACSWUPT
Adaptive time stepping is a way to maximize the time step that the model can use whilekeeping the model numerically stable. The model time step is adjusted based on thedomain-wide horizontal and vertical stability criterion (called the Courant-Friedrichs-Lewy (CFL) condition). The following set of values would typically work well.
use_adaptive_time_step = .true.step_to_output_time = .true. (but nested domains may still be writing output atthe desired time. Try to use adjust_output_times = .true. to make up for this.)target_cfl = 1.2, 1.2, 1.2,max_step_increase_pct = 5, 51, 51, (a large percentage value for the nest allowsthe time step for the nest to have more freedom to adjust)starting_time_step = the actual value or -1 (which means 4*DX at start time)max_time_step : use fixed values for all domains, e.g. 8*DXmin_time_step : use fixed values for all domains, e.g. 3*DXadaptation_domain: which domain is driving the adaptive time step
Also see the description of these options in the list of namelist on page 5-43.
Since Version 3.3, WRF has an option to stochastically perturb forecasts via a stochastickinetic-energy backscatter scheme (SKEBS; Shutts, 2005, QJRMS). The schemeintroduces temporally and spatially correlated perturbations to the rotational windcomponents u, v, and potential temperature θ. An application and verification of thisscheme to mesoscale ensemble forecast in the mid-latitudes is available in Berner et. al,2011, Monthly Weather Review, 139, 1972—1995(http://journals.ametsoc.org/doi/abs/10.1175/2010MWR3595.1).
Since the scheme uses Fast Fourier Transforms (FFTs) provided in the libraryFFTPACK, we recommend the number of gridpoints in each direction to be product ofsmall primes. If the number of gridpoints is a large prime in at least one of the directions,the computational cost may increase substantially. Multiple domains are supported byinterpolating the forcing from the largest domain for which the scheme is turned on(normally the parent domain) down to all nested domain.
At present, default settings for the scheme have been thoroughly tested on synoptic andmeso-scale domains over the mid-latitudes and as such offer a starting point.Relationships between backscatter amplitudes and perturbation fields for a given variableare not necessarily proportional due to the complexity of the scheme.
The namelist parameters to control the stochastic schemes are found in the namelist.inputfile currently under the &stoch section (new namelist record since V3.6):
1.lminforc Minimal forcing wavenumber in latitude for streamfunction perturbations. Default is 1.kminforct Minimal forcing wavenumber in longitude for potential temperature perturbations. Default is 1.lminforct Minimal forcing wavenumber in latitude for potential temperature perturbations. Default is 1.kmaxforc Maximal forcing wavenumber in longitude for streamfunction perturbations. Default is maximal possible wavenumbers determined by number of gridpoints in longitude.lmaxforc Maximal forcing wavenumber in latitude for streamfunction perturbations. Default is maximal possible wavenumbers determined by number of gridpoints in latitude.kmaxforct Maximal forcing wavenumber in longitude for potential temperature perturbations. Default is maximal possible wavenumbers determined by number of gridpoints in longitude.lmaxforct Maximal forcing wavenumber in latitude for potential temperature perturbations. Default is maximal possible wavenumbers determined by number of gridpoints in latitude.zsigma2_eps Noise variance in autoregressive process defining streamfunction perturbations.zsigma2_eta Noise variance in autoregressive process defining in potential temperature perturbations.skebs_vertstruc Replaces the namelist parameter stoch_vertstruc_opt which was used up to V3.6. Latter is still maintained, but obsolete. = 0, 0, 0: Constant vertical structure of random pattern generator = 1, 1, 1: Random phase vertical structure with westward tiltnens Seed for random number stream for both stochastic schemes. For ensemble forecasts this parameter needs to be different for
(From Berner)Option to generate a random perturbation fieldThis option generates a random perturbations field. The stochastic pattern is centered on0 and has a prescribed standard deviation. This pattern can be used for user-implementedperturbations of e.g., lower boundary conditions or parameters in the physicparameterizations. Currently it is only used to generate perturbations of the boundarytendencies of the WRF-CHEM. The namelist parameters to control the randomperturbation option are found in the namelist.input file under the &stoch section (newnamelist record since V3.6):
(From Berner)
This option allows for the addition of perturbations to the boundary tendencies for u andv wind components and potential temperature in WRF stand-alone runs. Users mayprovide a pattern or use the pattern generated by SKEBS.
The perturb_bdy option runs independently of SKEBS and as such may be run with orwithout the SKEB scheme, which operates solely on the interior grid. However, selectingperturb_bdy=1 will require the generation of a domain-size random array, thuscomputation time may increase.
Selecting perturb_bdy=2 will require the user to provide a pattern. Arrays are initializedand called: field_u_tend_perturb, field_v_tend_perturb, field_t_tend_perturb. Thesearrays will need to be filled with desired pattern in spec_bdytend_perturb inshare/module_bc.F or spec_bdy_dry_perturb in dyn_em/module_bc_em.F.
The namelist parameters to control the perturb boundary conditions option are found inthe namelist.input file under the &stoch section:
This option adds random perturbations to the chemistry boundary tendencies in WRF-CHEM. The random perturbation pattern is controlled by all the parameters for thenamelist option "rand_perturb", and stored as the variable named "RAND_PERT" in thewrfout file.
(From Ha)
o. Run-Time IO
With the release of WRF version 3.2, IO decisions may now be updated as a run-timeoption. Previously, any modification to the IO (such as which variable is associated withwhich stream) was handled via the Registry, and changes to the Registry alwaysnecessitate a cycle of clean –a, configure, and compile. This compile-timemechanism is still available and it is how most of the WRF IO is defined. However,should a user wish to add (or remove) variables from various streams, that capability isavailable as an option.
First, the user lets the WRF model know where the information for the run-timemodifications to the IO is located. This is a text file (my_file_d01.txt), one foreach domain, defined in the namelist.input file, located in the time_controlnamelist record.
&time_controliofields_filename = "my_file_d01.txt", "my_file_d02.txt"ignore_iofields_warning = .true.,/
The contents of the text file associates a stream ID (0 is the default history and input)with a variable, and whether the field is to be added or removed. The state variables mustalready be defined in the Registry file. Following are a few examples:-:h:0:RAINC,RAINNCwould remove the fields RAINC and RAINNC from the standard history file.
+:h:7:RAINC,RAINNCwould add the fields RAINC and RAINNC to an output stream #7.
It is not necessary to remove fields from one stream to insert them in another. It is OK tohave the same field in multiple streams.
If you are interested in outputting variables into a new stream (i.e., not the default historystream 0), then the following namelist variables will also be necessary (example forstream 7):
auxhist7_outname = "yourstreamname_d<domain>_<date>"auxhist7_interval = 360, 360,frames_per_auxhist7 = 1, 1,io_form_auxhist7 = 2
Note that any field that can be part of the optional IO (either the input or output streams)must already be declared as a state variable in the Registry. Care needs to be taken whenspecifying the names of the variables that are selected for the run-time IO. The "name"of the variable to use in the text file (defined in the namelist.input file) is the quotedstring from the Registry file. Most of the WRF variables have the same string for thename of the variable used inside the WRF source code (column 3 in the Registry file,non-quoted, and not the string to use) and the name of the variable that appears in thenetCDF file (column 9 in the Registry file, quoted, and that is the string to use).
p. Output Diagnostics
1. Time series output. To activate the option, a file called "tslist" must be present inthe WRF run directory. The tslist file contains a list of locations defined by theirlatitude and longitude along with a short description and an abbreviation for eachlocation. A sample file looks something like this:
#-----------------------------------------------## 24 characters for name | pfx | LAT | LON |#-----------------------------------------------#Cape Hallett hallt -72.330 170.250McMurdo Station mcm -77.851 166.713
The first three lines in the file are regarded as header information, and are ignored. Givena tslist file, for each location inside a model domain (either coarse or nested) a filecontaining time series variables at each model time step will be written with the namepfx.d<domain>.TS, where pfx is the specified prefix for the location in the tslist file.The maximum number of time series locations is controlled by the namelist variablemax_ts_locs in the namelist record &domains. The default value is 5. The timeseries output contains selected variables at the surface, including 2-m temperature, vapormixing ratio, 10-m wind components, u and v, rotated to the earth coordinate, etc.. Moreinformation for time series output can be found in WRFV3/run/README.tslist.
2. Pressure level output. This is activated by adding a namelist record &diag, and setp_lev_diag = 1. The option can output U, V, wind speed, T, dew point T, RH andgeopotential height at a number of pressure levels.
&diagp_lev_diag = 1num_press_level = 4,press_levels = 85000, 70000, 50000, 20000,
The output goes to auxiliary output stream 23, so the following should be set in&time_control:
auxhist3_outname = "wrfxtrm_d<domain>_<date>"auxhist3_interval = 1440, 1440,frames_per_auxhist3 = 100, 100,io_form_auxhist3 = 2
Since this option computes the daily max and min, etc., it is advisable to do a restart atthe daily interval.
http://www2.mmm.ucar.edu/wrf/users/docs/AFWA_Diagnostics_in_WRF.pdf). NOTE:These options cannot be used with OpenMP.
7. Others in &physics
prec_acc_dt = 60: Time interval for outputing precipitation variables (rain fromcumulus and microphysics schemes, and snow from microphysics scheme) (unit inminutes).
q. WRF-Hydro
This is a new capability in V3.5. It couples WRF model with hydrology processes (suchas routing and channeling). Using WRF-Hydro requires a separate compile by usingenvironment variable WRF_HYDRO. In c-shell environment, do
setenv WRF_HYDRO 1
before doing 'configure' and 'compile'. Once WRF is compiled, copy files fromhydro/Run/ directory to your working directory (e.g. test/em_real/). Aseparately prepared geogrid file is also required. Please refer the following web site fordetailed information: http://www.ral.ucar.edu/projects/wrf_hydro/. (From W. Yu)
r. Using IO Quilting
This option allows a few processors to be set aside to be responsible for output only. Itcan be useful and performance-friendly if the domain size is large, and/or the time takento write an output time is becoming significant when compared to the time taken tointegrate the model in between the output times. There are two variables for setting theoption:
*Note: This option is only used for wrf.exe. It does not work for real or ndown.
A few physics options sets (plus model top and the number of vertical levels) areprovided here for reference. They may provide a good starting point for testing the modelin your application. Also note that other factors will affect the outcome; for example, thedomain setup, the distributions of vertical model levels, and input data.
a. 1 – 4 km grid distances, convection-permitting runs for a 1- 3 day run (as used for theNCAR spring real-time convection forecast over the US in 2013):
mp_physics = 8,ra_lw_physics = 4,ra_sw_physics = 4,radt = 10,sf_sfclay_physics = 2,sf_surface_physics = 2,bl_pbl_physics = 2,bldt = 0,cu_physics = 0,
ptop_requested = 5000,e_vert = 40,
b. 10 – 20 km grid distances, 1- 3 day runs (e.g., NCAR daily real-time runs over theUS):
mp_physics = 8,ra_lw_physics = 4,ra_sw_physics = 4,radt = 15,sf_sfclay_physics = 1,sf_surface_physics = 2,bl_pbl_physics = 1,bldt = 0,cu_physics = 3,cudt = 0,
ptop_requested = 5000,e_vert = 39,
mp_physics = 4,ra_lw_physics = 4,ra_sw_physics = 2,radt = 15,sf_sfclay_physics = 2,sf_surface_physics = 2,bl_pbl_physics = 2,bldt = 0,cu_physics = 1,cudt = 5,fractional_seaice = 1,seaice_threshold = 0.0,
ptop_requested = 1000,e_vert = 44,
d. Hurricane applications (e.g. 36, 12, and 4 km nesting used by NCAR's real-timehurricane runs in 2012):
mp_physics = 6,ra_lw_physics = 4,ra_sw_physics = 4,radt = 10,sf_sfclay_physics = 1,sf_surface_physics = 2,bl_pbl_physics = 1,bldt = 0,cu_physics = 6, (only on 36/12 km grid)cudt = 0,isftcflx = 2,
ptop_requested = 2000,e_vert = 36,
e. Regional climate case at 10 – 30 km grid sizes (e.g. used in NCAR's regional climateruns):
mp_physics = 6,ra_lw_physics = 3,ra_sw_physics = 3,radt = 30,sf_sfclay_physics = 1,sf_surface_physics = 2,bl_pbl_physics = 1,bldt = 0,cu_physics = 1,cudt = 5,
sst_update = 1,tmn_update = 1,sst_skin = 1,bucket_mm = 100.0,bucket_J = 1.e9,ptop_requested = 1000,e_vert = 51,
spec_bdy_width = 10,spec_zone = 1,relax_zone = 9,spec_exp = 0.33,
Check Output
Once a model run is completed, it is good practice to check a couple of things quickly.
If you have run the model on multiple processors using MPI, you should have a numberof rsl.out.* and rsl.error.* files. Type 'tail rsl.out.0000' to see if youget 'SUCCESS COMPLETE WRF'. This is a good indication that the model has runsuccessfully.
Check the output times written to the wrfout* file by using the netCDF command:
Take a look at either the rsl.out.0000 file or other standard-out files. This file logsthe times taken to compute for one model time step, and to write one history and restartoutput file:
andTiming for Writing wrfout_d02_2006-01-22_00:00:00 for domain 2: 1.17970 elapsed seconds.Timing for main: time 2006-01-22_00:00:00 on domain 1: 27.66230 elapsed seconds.Timing for Writing wrfout_d01_2006-01-22_00:00:00 for domain 1: 0.60250 elapsed seconds.
Trouble Shooting
- If the model aborts very quickly, it is likely that either the computer memory is not large enough to run the specific configuration, or the input data have some serious problems. For the first potential issue, try to type 'unlimit' or 'ulimit -s unlimited' to see if more memory and/or stack size can be obtained.- For OpenMP (smpar-compiled code), the stack size needs to be set large, but not unlimited. Unlimited stack size may crash the computer.- To check if the input data are the problem, use ncview or another netCDF file browser to check the fields in the wrfinput files.- Another frequent error seen is 'module_configure: initial_config: error reading namelist'. This is an error message from the model complaining about errors and typos in the namelist.input file. Edit the namelist.input file with caution. If unsure, always start with an available template. A namelist record where the namelist read error occurs is provided in the V3 error message, and it should help with identifying the error.- If the model did not run to completion, one possibility is that the model may have become numerically unstatble, which means the time step used for advancing the model in time is too large for a stable solution. Even if one observes the standard rule for setting the model time step (to be ~ 6*DX in kilometers in physical space), other configurations of the model domain may affect the outcome. For example, if one has thin model layers, or if one uses a very large domain and the corners of the domain may have a very large map-scale factor that reduces the equivalent earth distance to be a lot smaller than the model grid size. One can find out whether this is the case by searching for CFL prints in the standard output/error files (e.g. the rsl files):
When this happens, consider using the namelist option w_damping, and/or reducing the time step.
Physics Options
WRF offers multiple physics options that can be combined in any way. The optionstypically range from simple and efficient, to sophisticated and more computationallycostly, and from newly developed schemes, to well-tried schemes such as those in currentoperational models.
The choices vary with each major WRF release, but here we will outline those availablein WRF Version 3.
1. Microphysics (mp_physics) a. Kessler scheme: A warm-rain (i.e. no ice) scheme used commonly in idealized cloud modeling studies (mp_physics = 1). b. Lin et al. scheme: A sophisticated scheme that has ice, snow and graupel processes, suitable for real-data high-resolution simulations (2). c. WRF Single-Moment 3-class scheme: A simple, efficient scheme with ice and snow processes suitable for mesoscale grid sizes (3). d. WRF Single-Moment 5-class scheme: A slightly more sophisticated version of (c) that allows for mixed-phase processes and super-cooled water (4). e. Eta microphysics: The operational microphysics in NCEP models. A simple efficient scheme with diagnostic mixed-phase processes. For fine resolutions (< 5km) use option (5) and for coarse resolutions use option (95). f. WRF Single-Moment 6-class scheme: A scheme with ice, snow and graupel processes suitable for high-resolution simulations (6). g. Goddard microphysics scheme. A scheme with ice, snow and graupel processes suitable for high-resolution simulations (7). New in Version 3.0. h. New Thompson et al. scheme: A new scheme with ice, snow and graupel processes suitable for high-resolution simulations (8). This adds rain number concentration and updates the scheme from the one in Version 3.0. New in Version 3.1. i. Milbrandt-Yau Double-Moment 7-class scheme (9). This scheme includes separate categories for hail and graupel with double-moment cloud, rain, ice, snow, graupel and hail. New in Version 3.2. (Note: Do not use this scheme in V3.6 and V3.6.1.) j. Morrison double-moment scheme (10). Double-moment ice, snow, rain and graupel for cloud-resolving simulations. New in Version 3.0. k. WRF Double-Moment 5-class scheme (14). This scheme has double-moment rain. Cloud and CCN for warm processes, but is otherwise like WSM5. New in Version 3.1. l. WRF Double-Moment 6-class scheme (16). This scheme has double-moment rain. Cloud and CCN for warm processes, but is otherwise like WSM6. New in Version 3.1. m. Stony Brook University (Y. Lin) scheme (13). This is a 5-class scheme with riming intensity predicted to account for mixed-phase processes. New in Version 3.3. n. NSSL 2-moment scheme (17, 18). New since Version 3.4, this is a two-moment scheme for cloud droplets, rain drops, ice crystals, snow, graupel, and hail. It also predicts average graupel particle density, which allows graupel to span the range from frozen drops to low-density graupel. There is an additional option to predict cloud condensation nuclei (CCN, option 18) concentration (intended for idealized simulations). The scheme is intended for cloud-resolving simulations (dx <= 2km) in research applications. Since V3.5, two more one-moment schemes have been added (19 and 21). Option 19 is a single-moment version of the NSSL scheme, and option 21
is similar to Gilmore et al. (2004). Option 22 (new in V3.7) is the two moment scheme (option 17) without hail. o. CAM V5.1 2-moment 5-class scheme. p. Thompson aerosol-aware (28). This scheme considers water- and ice-friendly aerosols. A climatology dataset may be used to specify initial and boundary conditions for the aerosol variables (Thompson and Eidhammer, 2014, JAS.) New in Version 3.6. q. HUJI (Hebrew University of Jerusalem, Israel) spectral bin microphysics, full (32) and 'fast' (30) versions are available since Version 3.6.
e. RRTMG shortwave. A new shortwave scheme with the MCICA method of random cloud overlap (4). New in Version 3.1. In V3.7, a fast version is introduced as option 24. f. New Goddard scheme (5). Efficient, multiple bands, ozone from climatology. New in Version 3.3. g. Fu-Liou-Gu scheme (7). multiple bands, cloud and cloud fraction effects, ozone profile from climatology, can allow for aerosols. New in Version 3.4. h. Held-Suarez relaxation. A temperature relaxation scheme designed for idealized tests only (31). Related options: - Slope and shading effects. slope_rad = 1 modifies surface solar radiation flux according to terrain slope. topo_shad = 1 allows for shadowing of neighboring grid cells. Use only with high-resolution runs with grid size less than a few kilometers. Since Version 3.2, these are available for all shortwave options. - swrad_scat: scattering turning parameter for ra_sw_physics = 1. Default value is 1, which is equivalent to 1.e-5 m2/kg. When the value is greater than 1, it increases the scattering. - swint_opt: Interpolation of short-wave radiation based on the updated solar zenith angle between SW calls. Available since V3.5.1.
d. Aerosol input for RRTMG radiation scheme from climatological water- and ice- friendly aerosols (aer_opt = 3). It works with Thompson microphysics option 28. New in V3.8. e. Effective cloud water, ice and snow radii from Thompson (since 3.5.1), WSM, WDM and NSSL microphysics schemes (new in V3.7) are used in RRTMG.
dynamic vegetation models that allocate carbon to vegetation (leaf, stem, wood and root) and soil carbon pools (fast and slow). New in Version 3.4. (Niu et al. 2011) g. (8) SSiB Land Surface Model: This is the third generation of the Simplified Simple Biosphere Model (Xue et al. 1991; Sun and Xue, 2001). SSiB is developed for land/atmosphere interaction studies in the climate model. The aerodynamic resistance values in SSiB are determined in terms of vegetation properties, ground conditions and bulk Richardson number according to the modified Monin–Obukhov similarity theory. SSiB-3 includes three snow layers to realistically simulate snow processes, including destructive metamorphism, densification process due to snow load, and snow melting, which substantially enhances the model's ability for the cold season study. To use this option, ra_lw_physics and ra_sw_physics should be set to either 1, 3, or 4. The second full model level should be set to no larger than 0.982 so that the height of that level is higher than vegetation height. New in Version 3.4. h. Fractional sea-ice (fractional_seaice = 1). Treat sea-ice as fractional field. Require fractional sea-ice as input data. Data sources may include those from GFS or the National Snow and Ice Data Center (http://nsidc.org/data/seaice/index.html). Use XICE for Vtable entry instead of SEAICE. This option works with sf_sfclay_physics = 1, 2, 5, and 7, and sf_surface_physics = 2, 3, and 7 in the present release. New in Version 3.1. i. (5) CLM4 (Community Land Model Version 4, Oleson et al. 2010; Lawrence et al. 2010): CLM4 was developed at the National Center for Atmospheric Research with many external collaborators and represents a state-of-the-science land surface process model. It contains sophisticated treatment of biogeophysics, hydrology, biogeochemistry, and dynamic vegetation. In CLM4, the land surface in each model grid cell is characterized into five primary sub-grid land cover types (glacier, lake, wetland, urban, and vegetated). The vegetated sub-grid consists of up to 4 plant functional types (PFTs) that differ in physiology and structure. The WRF input land cover types are translated into the CLM4 PFTs through a look-up table. The CLM4 vertical structure includes a single-layer vegetation canopy, a five-layer snowpack, and a ten-layer soil column. An earlier version of CLM has been quantitatively evaluated within WRF in Jin and Wen (2012; JGR-Atmosphere), Lu and Kueppers (2012; JGR-Atmosphere), and Subin et al. (2011; Earth Interactions) (from Jin). New in Version 3.5. Updated for 20/21 category MODIS landuse data in V3.6.
a. CLM 4.5 lake model (1). The lake scheme was obtained from the Community Land Model version 4.5 (Oleson et al. 2013) with some modifications by Gu et al. (2013). It is a one-dimensional mass and energy balance scheme with 20-25 model layers, including up to 5 snow layers on the lake ice, 10 water layers, and 10 soil layers on the lake bottom. The lake scheme is used with actual lake points and lake depth derived from the WPS, and it also can be used with user defined lake points and lake depth in WRF (lake_min_elev and lakedepth_default). The lake scheme is independent of a land surface scheme and therefore can be used with any land surface scheme embedded in WRF. The lake scheme developments and evaluations were included in Subin et al. (2012) and Gu et al. (2013) (Subin et al. 2012: Improved lake model for climate simulations, J. Adv. Model. Earth Syst., 4, M02001. DOI:10.1029/2011MS000072; Gu et al. 2013: Calibration and validation of lake surface temperature simulations with the coupled WRF-Lake model. Climatic Change, 1-13, 10.1007/s10584-013-0978-y).4. Planetary Boundary layer (bl_pbl_physics) a. Yonsei University scheme: Non-local-K scheme with explicit entrainment layer and parabolic K profile in unstable mixed layer (bl_pbl_physics = 1). - topo_wind: = 1: Topographic correction for surface winds to represent extra drag from sub-grid topography and enhanced flow at hill tops (Jimenez and Dudhia, JAMC 2012). Works with YSU PBL only. New in Version 3.4. = 2: a simpler terrain variance-related correction. New in Version 3.5. - ysu_topdown_pblmix: = 1: option for top-down mixing driven by radiative cooling. New in V3.7. b. Mellor-Yamada-Janjic scheme: Eta operational scheme. One-dimensional prognostic turbulent kinetic energy scheme with local vertical mixing (2). c. MRF scheme: Older version of (a) with implicit treatment of entrainment layer as part of non-local-K mixed layer (99). d. ACM2 PBL: Asymmetric Convective Model with non-local upward mixing and local downward mixing (7). New in Version 3.0. e. Quasi-Normal Scale Elimination PBL (4). A TKE-prediction option that uses a new theory for stably stratified regions (Available since 3.1). Daytime part uses eddy diffusivity mass-flux method with shallow convection (mfshconv = 1) which is added in Version 3.4. f. Mellor-Yamada Nakanishi and Niino Level 2.5 PBL (5). Predicts sub-grid TKE terms. New in Version 3.1 with significant update in V3.8. - icloud_bl: = 1, option to couple subgrid-scale clouds from MYNN to radiation - bl_mynn_cloudpdf: = 1, Kuwano et al (2010); = 2, Chaboureau and Bechtold (2002, JAS, with mods, default) - bl_mynn_cloudmix: = 1, mixing cloud water and ice (qnc and qni are mixed when scalar_pblmix = 1) The above three options are new in V3.8.
g. Mellor-Yamada Nakanishi and Niino Level 3 PBL (6). Predicts TKE and other second-moment terms. New in Version 3.1. h. BouLac PBL (8): Bougeault-Lacarrère PBL. A TKE-prediction option. New in Version 3.1. Designed for use with BEP urban model. i. UW (Bretherton and Park) scheme (9). TKE scheme from CESM climate model. New in Version 3.3. j. Total Energy - Mass Flux (TEMF) scheme (10). Sub-grid total energy prognostic variable, plus mass-flux type shallow convection. New in Version 3.3. k. LES PBL: A large-eddy-simulation (LES) boundary layer is available in Version 3. For this, bl_pbl_physic = 0, isfflx = 1, and sf_sfclay_physics and sf_surface_physics are selected. This uses diffusion for vertical mixing and must use diff_opt = 2, and km_opt = 2 or 3, see below. Alternative idealized ways of running the LESPBL are chosen with isfflx = 0 or 2. New in Version 3.0. l. Grenier-Bretherton-McCaa scheme (12): This is a TKE scheme. Tested in cloud- topped PBL cases. New in Version 3.5. m. Shin-Hong scheme (11): Include scale dependency for vertical transport in convective PBL. Vertical mixing in the stable PBL and free atmosphere follows YSU. This scheme also has diagnosed TKE and mixing length output. New in V3.7.
h. New Simplified Arakawa-Schubert (14). New mass-flux scheme with deep and shallow components and momentum transport. New in Version 3.3. i. New Simplified Arakawa-Schubert (84, HWRF version). New mass-flux scheme with deep and shallow components and momentum transport. New in Version 3.4. j. Grell-Freitas (GF) scheme (3): An improved GD scheme that tries to smooth the transition to cloud-resolving scales, as proposed by Arakawa et al. (2004). New in Version 3.5. k. Old Kain-Fritsch scheme: Deep convection scheme using a mass flux approach with downdrafts and CAPE removal time scale (99). l. Multi-scale Kain-Fritsch scheme (11): using scale-dependent dynamic adjustment timescale, LCC-based entrainment. Also uses new trigger function based on Bechtold. m. New Tiedtke scheme (16): this version is similar to the Tiedtke scheme used in REGCM4 and ECMWF cy40r1. New in V3.7, updated in V3.8. n. Kain-Fritsch-Cumulus Potential scheme (10): this option modifies the KF ad-hoc trigger function with one linked to boundary layer turbulence via probability density function (PDFs) using cumulus potential scheme. The scheme also computes the cumulus cloud fraction based on the time-scale relevant for shallow cumuli. (Berg et al. 2013.) New in V3.8.
option also includes dissipative heating term in heat flux. It is only available for sf_sfclay_physics = 1. There are two options for computing enthalpy coefficients: isftcflx = 1: constant Z0q (since V3.2) for heat and moisture; isftcflx = 2 Garratt formulation, slightly different forms for heat and moisture. b. Other options for long simulations (new in Version 3.1): - tmn_update: update deep soil temperature (1). - sst_skin: calculate skin SST based on Zeng and Beljaars (2005) (1) - bucket_mm: bucket reset value for water equivalent precipitation accumulations (value in mm, -1 = inactive). - bucket_J: bucket reset value for energy accumulations (value in Joules, -1 = inactive). Only works with CAM and RRTMG radiation (ra_lw_physics = 3 and 4 and ra_sw_physics = 3 and 4) options. - To drive WRF model with climate data that does not have leap year, there is a compile option to do that. Edit configure.wrf and add -DNO_LEAP_CALENDAR to the macro ARCH_LOCAL. c. Land model input options: - usemonalb: When set to .true., it uses monthly albedo fields from geogrid, instead of table values - rdlai2d: When set to .true., it uses monthly LAI data from geogrid (new in V3.6) and the field will also go to wrflowinp file if sst_update is 1. d. gwd_opt: Gravity wave drag option. Can be activated when grid size is greater than 10 km. May be beneficial for simulations longer than 5 days and over a large domain with mountain ranges. It is recommended that this option is used only with unrotated lat/long (e.g. global) or Mercator projections because the input orographic sub-grid asymmetry arrays assume this grid orientation. New in Version 3.1. e. windfarm_opt: Wind turbine drag parameterization scheme. It represents sub-grid effects of specified turbines on wind and TKE fields. The physical charateristics of the wind farm is read in from a file and use of the manufacturers' specification is recommeded. An example of the file is provided in run/wind-turbine-1.tbl. The location of the turbines are read in from a file, windturbines.txt. See README.windturbine in WRFV3/ directory for more detail. New in Version 3.3, and in this version it only works with 2.5 level MYNN PBL option (bl_pbl_physics=5), and updated in V3.6.
a. no_mp_heating: When set to 1, it turns off latent heating from microphysics. When using this option, cu_physics should be set to 0. b. icloud: When set to 0, it turns off cloud effect on optical depth in shortwave radiation options 1, 4 and longwave radiation option 1, 4. Note since V3.6, this namelist also controls which cloud fraction method to use for radiation. c. isfflx: When set to 0, it turns off both sensible and latent heat fluxes from the
Diffusion in WRF is categorized under two parameters: the diffusion option and the Koption. The diffusion option selects how the derivatives used in diffusion are calculated,and the K option selects how the K coefficients are calculated. Note that when a PBLoption is selected, vertical diffusion is done by the PBL scheme, and not by the diffusionscheme. In Version 3, vertical diffusion is also linked to the surface fluxes.
2. Damping Options These are independently activated choices.
Advection Options
The positive-definite and monotonic options are available for moisture, scalars, chemical scalers and TKE in the ARW solver. Both the monotonic and positive- definite transport options conserve scalar mass locally and globally and are consistent with the ARW mass conservation equation. We recommend using the positive- definite option for moisture variables on all real-data simulations. The monotonic option may be beneficial in chemistry applications and for moisture and scalars in some instances.
When using these options there are certain aspects of the ARW integration scheme that should be considered in the simulation configuration.
updated with the physics tendency, and the new updated values are used as the starting values for the transport scheme. The microphysics update occurs after the transport update using these latest values as its starting point. It is important to remember that for any scalars, the local and global conservation properties, positive definiteness and monotonicity depend upon each update possessing these properties.
(3) Most of the model physics are not monotonic nor should they be - they represent sources and sinks in the system. All should be positive definite, although we have not examined and tested all options for this property.
(4) The monotonic option adds significant smoothing to the transport in regions where it is active. You may want to consider turning off the other model filters for variables using monotonic transport (filters such as the second and sixth order horizontal filters). At present it is not possible to turn off the filters for the scalars but not for the dynamics using the namelist - one must manually comment out the calls in the solver.
a. The model can be run hydrostatically by setting the non_hydrostatic switch to .false. b. The Coriolis term can be applied to wind perturbation (pert_coriolis = .true.) only (idealized only). c. For diff_opt = 2 only, vertical diffusion may act on full fields (not just on perturbation from the 1D base profile (mix_full_fields = .true.; idealized only). d. To obtain more accurate solution with moisture, one can add use_q_diabatic: which considers moisture tendency from microphysics in small steps. This option could make time-step more restrictive. use_theta_m: which considers moisture effect on pressure in small steps. The current implementation may cost a bit more to run.
Addedmp_physics Scheme Reference
Numbermp_physics Scheme Cores Mass Variables Variables1 Kessler ARW Qc Qr
3 WSM3 ARW Qc Qr
4 WSM5 ARW/NMM Qc Qr Qi Qs
6 WSM6 ARW/NMM Qc Qr Qi Qs Qg
8 Thompson ARW/NMM Qc Qr Qi Qs Qg Ni Nr Milbrandt 2- Nc Nr Ni Ns Ng9 ARW Qc Qr Qi Qs Qg Qh mom Nh Morrison 2-10 ARW (Chem) Qc Qr Qi Qs Qg Nr Ni Ns Ng mom11 CAM 5.1 ARW Qc Qr Qi Qs Qg Nr Ni Ns Ng13 SBU-YLin ARW Qc Qr Qi Qs14 WDM5 ARW Qc Qr Qi Qs Nn** Nc Nr16 WDM6 ARW Qc Qr Qi Qs Qg Nn** Nc Nr Nc Nr Ni Ns Ng17 NSSL 2-mom ARW Qc Qr Qi Qs Qg Qh Nh NSSL 2-mom Nc Nr Ni Ns Ng18 ARW Qc Qr Qi Qs Qg Qh +CCN Nh Nn Vg19 NSSL 1-mom ARW Qc Qr Qi Qs Qg Qh Vg***21 NSSL 1-momlfo ARW Qc Qr Qi Qs Qg22 /nssl 2-mom ARW Qc Qr Qi Qs Qg Nc Nr Ni Ns Ng Thompson28 ARW/NMM Qc Qr Qi Qs Qg Ni Nr Nwf Nif aerosol-aware Nc Nr Ns Ni Ng30 HUJI fast ARW Qc Qr Qs Qg Qi Nn Qc Qr Qs Qg Qh Qip Nc Nr Ns Ng Nip32 HUJI full ARW Qic Qid Qnn Nic Nid Nn
* Advects only total condensates ** Nn = CCN number *** Vg: graupel volume
Addedcu_physics Scheme Reference
5 Grell-3 - 2008
84 New SAS (HWRF) Han and Pan (2011, Wea. Forecasting) 2012
3 GF ARW Qc Qi no yes
5 G3 ARW Qc Qi no yes
99 old KF ARW Qc Qr Qi Qs no no
overlap4 RRTMG ARW + Chem Qc Qr Qi Qs max-rand 1 profile or (τ), NMM overlap lat/month24 RRTMG5 New ARW Qc Qr Qi Qs Qg 1/0 5 profiles Goddard7 FLG ARW Qc Qr Qi Qs Qg 1/0 5 profiles99 GFDL ARW NMM Qc Qr Qi Qs max-rand lat/date overlap
Suarez99 GFDL ARW NMM Qc Qr Qi Qs max-rand lat/date constant overlap
The following is a description of the namelist variables. The variables that are a functionof nests are indicated by (max_dom) following the variable. Also see theRegistry/Registry.EM and run/README.namelist files in the WRFV3/ formore detailed information.
integration; but run_days/run_hours takes precedence over the end times. The program real.exe uses start and end times onlyinterval_seconds 10800 time interval between the incoming real data, which will be the interval between the lateral boundary condition file (for real only)input_from_file .true. (logical); whether the nested run(max_dom) will have input files for domains other than domain 1fine_input_stream selected fields from nest input(max_dom) 0 (default) all fields from nest input are used 2 only nest input specified from input stream 2 (defined in the Registry) are used. In V3.2, this requires io_form_auxinput2 to be sethistory_interval 60 history output file interval in(max_dom) minutes (integer only)history_interval_d 1 history output file interval in days(max_dom) (integer only); used as an alternative to history_intervalhistory_interval_h 1 history output file interval in hours(max_dom) (integer only); used as an alternative to history_intervalhistory_interval_m 1 history output file interval in(max_dom) minutes (integer only); used as an alternative to history_interval and is equivalent to history_intervalhistory_interval_s 1 history output file interval in(max_dom) seconds (integer only); used as an alternative to history_intervalframes_per_outfile 1 number of output times bulked into(max_dom) each history file; used to split output files into smaller piecesrestart .false. (logical); whether this run is a restart
10 GRIB2 11 parallel netCDFio_form_restart the format in which the restart output files will be 2 nedCDF 102 split netCDF files, one per processor (must restart with the same number of processors)io_form_input the format of the input files 2 netCDF 102 allows the program real.exe to read in split met_em* files, and write split wrfinput files. No split file for the wrfbdy file.io_form_boundary the format for the wrfbdy file 2 netCDF format 4 PHD5 format 5 GRIB1 format 10 GRIB2 format 11 pnetCDF formatncd_nofill .true. (default) only a single write, not the write/read/write sequence (new in V3.6)io_form_auxinput2 IO format for input stream 2 data 2 netCDF format 4 PHD5 format 5 GRIB1 format 10 GRIB2 format 11 pnetCDF formatdiag_print 0 (default) When set to 1 or 2, it allows some simple diagnostic fields to be output 1 domain-averaged 3-hourly hydrostatic surface pressure tendency (Dpsfc/Dt), and dry- hydrostatic column pressure tendency (Dmu/Dt) will appear in stdout file. 2 in addition to those listed above, domain-averaged rainfall, surface evaporation, and sensible and latent heat fluxes will be output in stdout file.debug_level 0 giving this a larger value (50, 100, 200, etc.) increases the debugging
datainputout_begin_s 0 beginning second to write 3DVAR datainputout_end_y 0 ending year to write 3DVAR datainputout_end_d 0 ending day to write 3DVAR datainputout_end_h 12 ending hour to write 3DVAR datainputout_end_m 0 ending minute to write 3DVAR datainputout_end_s 0 ending second to write 3DVAR data *NOTE: The above example shows that the input-formatted data are output starting from hour 3 to hour 12 in a 180-min interval.all_ic_times .false. when set to .true., allows you to output a wrfinput file for all time periodsadjust_output_times .false. (default); adjust output times to the nearest houroutput_ready_flag (new .true. (default = .false.); when turned on,since V3.6.1) the model will write out an empty file with the name wrfoutReady_d<domain>_< date>. This is useful in production runs so that post- processing code can check on the existence of this file to start doing processing.output_diagnostics (new 0 turned offsince V3.3.1) 1 36 surface diagnostic arrays (max/min/mean/std) in the time interval are specified. The output goes to auxiliary history output stream 3 with default file name 'wrfxtrm_d<domain>_<date>.' You must also set io_form_auxhist3 =2, auxhist3_interval = 1440, 1440, and frames_per_auxhist3 = 1000, 1000. Note: do restart only at multiple of auxhist3_intervalsnwp_diagnostics (new 0 turned off
since V3.5)For automatic moving nestsinput_from_hires .false. When set to .true., high-resolution(max_dom) (new since terrain and landuse will be used inV3.6) the nests (requires special input data, and environment variable TERRAIN_AND_LANDUSE set at compile time). This optin will overwrite input_from_file option for nest domains.rsmas_data_path "high-res-data- Directory path where the high-res directory" data is 1 output 7 history-interval maximum or mean diagnostic fields in wrfout: 10 m surface wind max, max positive and negative w, max helicity in the 2-5 km layer, mean w, max column-integrated graupeliofields_filename "my_iofields_list.txt" an option to request particular(max_dom) variables to appear in output, if they are not already, or to not appear if they do and you do not want them to. You must also create a text file (my_iofields_list.txt) in which you will declare the variables to be output. It will be a single line of text, e.g.: +:h:7:RAINC,RAINNC or -:h:0:RAINC,RAINNCignore_iofields_warning .true. tells the model to continue if an error is encountered in the user- specified files .false. tells the model to abort if an error is encountered in the user-specified files
and time_step_fract_den = 10.time_step_dfi 60 time step when setting dfi_opt = 1, may be different from the regular time step max_dom 1 the number of domains over which you are runnings_we (max_dom) 1 start index in x (west-east) direction (leave as is)e_we (max_dom) 91 end index in x (west_east) direction (staggered dimension)s_sn (max_dom) 1 start index in y (south-north) direction (leave as is)e_sn (max_dom) 82 end index in y (south-north) direction (staggered dimension)s_vert (max_dom) 1 start index in z (vertical) direction (leave as is)e_vert (max_dom) 30 end index in z (vertical) direction (staggered dimension -- this refers to full levels). Most variables are on unstaggered levels. *Note: Vertical dimensions need to be the same for all nestsdx (max_dom) 30000 grid length in x-direction (in meters)dy (max_dom) 30000 grid length in y-direction (in meters)ztop (max_dom) 19000 height in meters; used to define model top for idealized casesgrid_id (max_dom) 1 domain identifierparent_id (max_dom) 0 ID of the parent domaini_parent_start (max_dom) 1 the starting lower-left corner i- indice from the parent domainj_parent_start (max_dom) 1 the starting lower-left corner j_indice from the parent domainparent_grid_ratio 1 parent-to-nest domain grid size(max_dom) ratio. *Note: for real data cases the ratio must be odd; for ideal data cases, the ratio can be even if feedback is set to 0.parent_time_step_ratio 1 parent-to-nest time step ratio; this(max_dom) can be different from the parent_grid_ratiofeedback 0 no feedback 1 feedback from nest to its parent domain
smooth_option 0 no smoothing 1 1-2-1 smoothing option for parent domain; used only with feedback=1 2 (default) smoothing-desmoothing option for parent domain; used only with feedback=1hypsometric_opt 2 (default) computes height in program real.exe and pressure in (default changed to 2 the model (ARW only) by using an beginning V3.4) alternative method (less biased when compared against input data) 1 original methodmax_ts_locs 5 maximum number of time series locationsmax_ts_level (new since 15 highest model level for profileV3.7) outputOptions for Programreal.exenum_metgrid_levels 40 number of vertical levels in WPS output (type ncdump -h on one of the met_em* files to find out this number)num_metgrid_soil_levels 4 number of soil levels or layers in WPS output (type ncdump -h on one of the met_em* files to find out this number)eta_levels 1.0, 0.99, ...0.0 model eta levels from 1 to 0. If not given, real will provide a set of levelsideal_init_method (new method to compute albedo insince V3.8) idealized cases in start_em 1 (default) albedo from phb 2 albedo from t_initHorizontal interpolationoptions, coarse grid tofine gridinterp_method_type (new The default is to use thesince V3.7) Smolarkiewicz "SINT" method; however, this is known to break with the implementation inside of WRF for large refinement ratios (such as 15:1). For those extreme and rare occurrences, other schemes ar available. For options 1, 3, 4, and 12, the FG lateral
9 Cubic splinelowest_lev_from_sfc .false. (default) use traditional interpolation .true. use surface values for the lowest eta (u,v,t,q)sfcp_to_sfcp .true optional method to compute model's surface pressure when incoming data only has surface pressure and terrain, but not sea- level pressure (default is .false.)use_tavg_for_tsk .true. uses diurnally-averaged surface temp as skin temp. The diurnally- averaged surface temp can be computed using WPS utility avg_tsfc.exe. May use this option when SKINTEMP is not present (default is .false.)rh2qv_wrt_liquid (new .true. (default) computes qv with respectsince V3.3) to liquid water .false. computes qv with respect to icerh2qv_method (new since which method to use to computerV3.3) mixing ratio from RH: 1 (default) old MM5 method 2 uses a WMO recommended method (WMO-No. 49, corrigendum, August 2000)smooth_cg_topo .true. smooths the outer rows and columns of the domain 1 topography with respect to the input data (default is .false.)vert_refine_fact 1 vertical refinement factor for ndown (1 = same number of vertical levels as the coarse domain, 2 = double the vertical resolution, and so on); not used for current vertical grid refinementvert_refine_method 0 (default) no vertical refinement(max_dom) (new sinceV3.7) 1 integer vertical refinement 2 use specified or computed eta levels for vertical refinementOptions for PresetMoving Nestnum_moves 2 total # of moves for all domainsmove_id (max_moves) 2, 2, a list of nest domain ID's, one per
movemove_interval 60, 120, time in minutes since the start of(max_moves) this domainmove_cd_x (max_moves) 1, -1, the # of parent domain grid cells to move in the i-directionmove_cd_y (max_moves) -1, 1, the # of parent domain grid cells to move in the j-direction (positive in increasing i/j directions, and negative in decreasing i/j directions. Only 1, 0, and -1 is permitted.Options for AutomaticMoving Nestvortex_interval (max_dom) 15 how often the new vortex position is computed (in mins)max_vortex_speed 40 used to compute the search radius(max_dom) for the new vortex position (in m/s)corral_dist (max_dom) 8 how close the moving nest is allowed to get to the coarse grid boundary. This # sets the minimum limit of grid cells allowed between them.track_level 50000 pressure level value (Pa) at which the tropical storm vortex is trackedtime_to_move (max_dom) 0., time (in mins) to start moving nestOptions for AdaptiveTime Stepuse_adaptive_time_step .true. use adaptive time step (default is .false.)step_to_output_time .true. modifies the time step so that the exact history time is reachedtarget_cfl (max_dom) 1.2., 1.2., 1.2., if vertical CFL ≤ this value, then time step is increasedtarget_hcfl (max_dom) 0.84, 0.84, 0.84, if horizontal CFL ≤ this value, the(new since V3.3) time step is increasedmax_step_increase_pct 5, 51, 51, percentage of previous time step to(max_dom) increase if the max CFL is ≤ target_cflstarting_time_step -1, -1, -1, flag -1 implies 4*dx is used to start(max_dom) the model. Any positive integer specifies the time step the model will use to start (in seconds). *Note: when use_adapative_time_step = .true., the value specified for
time_step is ignored.starting_time_step_den 0 denominator for starting_time_step(max_dom) (new since (so that fractional time step can beV3.6) used)max_time_step (max_dom) -1, -1, -1, flag -1 implies the maximum time step is 8*dx. Any positive integer specifies the maximum time step (in seconds).max_time_step_den 0 denominator for max_time_step(max_dom) (new sinceV3.6)min_time_step (max_dom) -1, -1, -1, flag -1 implies the minimum time step is 3*dx. Any positive integer specifies the minimum time step (in seconds).min_time_step_den 0 denominator for min_time_step(max_dom) (new sinceV3.6)adaptation_domain 1 (default) specifies which domain to use to drive adaptive time steppingOptions to ControlParallel Computingtile_sz_x 0 number of points in tile x direction (open MP only)tile_sz_y 0 number of points in tile y direction; can be determined automatically (open MP only)numtiles 1 number of tiles per patch (alternative to above 2 items; open MP only)nproc_x -1 (default) turned off; code will do automatic decomposition (MPI only) >1 number of processors in x for decomposition (MPI only)nproc_y -1 (default) turned off; code will do automatic decomposition (MPI only) >1 number of processors in y for decomposition (MPI only)Options for 3D OceanModelocean_levels 30 (default) number of ocean levels when using sf_ocean_physics = 2ocean_z (values for # of vertical profile of layer depth (m)
&physicsmp_physics (max_dom) 0 (default) no microphysics 1 Kessler scheme 2 Lin et al. scheme 3 WSM 3-class simple ice scheme 4 WSM 5-class scheme 5 Ferrier (new Eta) microphysics, operational High-Resolution Window 6 WSM 6-class graupel scheme 7 Goddard GCE scheme (also uses gsfcgce_hail and gsfcgce_2ice) 8 Thompson graupel scheme (2- moment scheme in V3.1) 9 Milbrandt-Yau 2-moment scheme 10 Morrison 2-moment scheme(new since V3.5) 11 CAM 5.1 5-class scheme(new since V3.3) 13 SBU_YLin, 5-class scheme 14 WRF double moment, 5-class scheme 15 High-resolution Ferrier microphysics, with advection 16 WRF double moment, 6-class scheme(new since V3.4) 17 NSSL 2-moment 4-ice scheme (steady background CCN)(new since V3.4) 18 NSSL 2-moment 4-ice scheme with predicted CCN (better for idealized than real cases); to set a global CCN value, use nssl_cccn = 0.7e9 (CCN for NSSL scheme 18). Also sets same value to ccn_conc for mp_physics = 18.(new since V3.5) 19 NSSL 1-moment, 6-class scheme(new since V3.5) 21 NSSL-LFO 1-moment, 6-class;
is default)use_mp_re (new since whether to use effective radiiV3.8) computed in mp schemes in RRTMG (the mp schemes that compute effective radii are 3, 4, 6, 8, 14, 16, 17-21) 0 off; do not use 1 (default) on; use effective radiira_lw_physics (max_dom) 0 (default) no longwave radiation 1 rrtm scheme (Default values for GHG in V3.5: co2vmr=379.e-6, n2ovmr=319.e-9, ch4vmr=1774.e-9; Values used in previous versions: co2vmr=330.e- 6, n2ovmr=0., ch4vmr=0.) 3 CAM scheme *Note: restart must be at 6-hourly interval; also requires levsiz, paerlev, cam_abs_dim1(2); see below 4 rrtmg scheme (Default values for GHG in V3.5: co2vmr=379.e-6, n2ovmr=319.e-9, ch4vmr=1774.e-9)(new since V3.7) 24 fast rrtmg scheme for GPU and MIC(new since V3.3) 5 Goddard scheme(new since V3.4) 7 FLG (UCLA) scheme 31 Earth Held-Suarez forcing 99 GFDL (Eta) longwave (semi- supported); also must use co2tf = 1 for ARWra_sw_physics (max_dom) 0 (default) no shortwave radiation 1 Dudhia scheme (ptop > 50 mb) 2 (old) Goddard shortwave scheme 3 CAM scheme (restart must be at 6- hourly interval); must set levsiz, paerlev, cam_abs_dim1/2 4 rrtmg scheme(new since V3.7) 24 fast rrtmg scheme for GPU and MIC(new since V3.3) 5 Goddard scheme(new since V3.4) 7 FLG (UCLA) scheme 99 GFDL (Eta) longwave (semi-
scheme; use sf_sfclay_physics=2 3 NCEP GFS scheme (NMM only); use sf_sfclay_physics=3 4 QNSE-EDMF; use sf_sfclay_physics=4 5 MYNN 2.5 level TKE; use sf_sfclay_physics=1, 2, or 5 6 MYNN 3rd level TKE; use sf_sfclay_physics=5 7 ACM2 (Pleim) scheme (ARW only); use sf_sfclay_physics=1 or 7 8 Bougeault and Lacarrere (BouLac) TKE; use sf_sfclay_physics=1 or 2(new since V3.3) 9 Bretherton-Park/UW TKE scheme; use sf_sfclay_physics=1 or 2(new since V3.3) 10 TEMF scheme (ARW only); use sf_sfclay_physics=10(new since V3.7) 11 Shin-Hong 'scale-aware' PBL scheme(new since V3.5) 12 GBM TKE-type scheme (ARW only); use sf_sfclay_physics=1 99 MRF scheme (to be removed in the future)mfshconv (max_dom) 1 turns on day-time EDMF for QNSE (0=off)bldt (max_dom) 0 minutes between boundary-layer physics calls (0=call every time step)topo_wind (max_dom) turns on topographic surface wind(new since V3.4) correction, and requires extra input from geogrid. YSU PBL only 0 off 1 Jimenez method 2 UW methodbl_mynn_tkebudget 0 (default) off(max_dom) (new sinceV3.4.1) 1 adds MYNN tke budget terms to output
droplets 1 settling from Dyunkerke 1991 (in atmosphere at at surface) 2 Fogdes (vegetation and wind speed dependent; Katata et al. 2008) at surface, and Dyunkerke in the atmosphereysu_topdown_pblmix (new 1 turns on top-down radiation-drivensince V3.7) mixing (default is 0=no)cu_physics (max_dom) cumulus parameterization option 0 (default) no cumulus parameterization 1 Kain-Fritsch (new Eta) scheme 2 Betts-Miller-Janjic scheme(new since V3.5, replacing 3 Grell-Freitas ensemble schemeGrell-Devenyi scheme)(new to ARW since V3.3) 4 Old GFS Simplified Arakawa- Schubert (SAS) 5 New Grell scheme (G3)(new since V3.3) 6 Tiedtke scheme (ARW only)(new since V3.3) 7 Zhang-McFarlane from CESM (works with MYJ and UW PBL)(new since V3.7) 10 Modified Kain-Fritsch scheme with trigger function based on PDFs (ARW-only)(new since V3.7) 11 Multi-scale Kain-Fritsch scheme(new since V3.3) 14 New GFS SAS from YSU (ARW only)(new since V3.7) 16 A newer Tiedke scheme 84 New SAS (HWRF)(option 3 before V3.5) 93 Grell-Devenyi ensemble scheme 99 previous Kain-Fritsch schemecudt 0 minutes between cumulus physics calls; should be set to 0 when using all cu_physics except Kain-Fritsch (0 = call every time step)kfeta_trigger 1 The way to determines whether a grid point is convective; used only with cu_physics=1. = 1, default, original.(new since V3.3) 2 moisture-advection based trigger (Ma and Tan 2009; ARW only) 3 relative humidity-dependentishallow 1 shallow convection used with
cu_physics=3 or 5 (default is 0 = off)shcu_physics (max_dom) independent shallow cumulus option (not tied to deep convection) 0 no independent shallow cumulus(new since V3.3) 2 Park and Bretherton shallow cumulus from CAM5(new since V3.5) 3 GRIMS scheme*Note: The following 5 options show recommended #'s. If you would like to use anyother number, consult the code to understand what you are doing.maxiens 1 Grell-Devenyi and G3 onlymaxens 3 Grell-Devenyi onlymaxens2 3 Grell-Devenyi onlymaxens3 16 Grell-Devenyi onlyensdim 144 Grell-Devenyi onlycugd_avedx 1 (default) number of grid boxes over which subsidence is spread, for large grid distances 3 for small grid distances (DX < 5 km)nsas_dx_factor (New since 0 (default); offV3.6) 1 nsas grid distance dependent optionFor the KF-CuP Scheme:shallowcu_forced_ra .false. radiative impact of shallow Cu by(max_dom) (new since a prescribed maximum cloudV3.8) fraction [cu_physics = 10 only; default = .false. (off); if =.true., radiative impact of shallow cu with a cloud fraction value of 0.36 ]numbins (max_dom) (new 1 number of perturbations forsince V3.8) potential temperature and mixing ratio in the CuP PDF (cu_physics = 10 only ; default is 1; should be an odd number - recommended value is 21)thBinSize (max_dom) (new 1 bin size of potential temperaturesince V3.8) perturbation increment: 0.01 K ( cu_physics = 10 only; default is 1)rBinSize (max_dom) (new 1 bin size of mixing ratiosince V3.8) perturbation increment: 1.0e-4 kg/kg (cu_physics = 10 only; default is 1)minDeepFreq (max_dom) 1 minimum frequency required
0 off 1 activate a simple ocean mixed layer (oml) model(new since V3.5) 2 activate a 3D PWP ocean model
locations 0 (default) the coordinates of the turbines are defined in terms of lat- lon 1 the coordinates of the turbines are defined in terms of grid points
(max_dom) 0 (default) offobs_coef_temp (max_dom) 6.e-4 nudging coefficient for temp (s-1)obs_nudge_mois 1 nudge water vapor mixing ratio(max_dom) 0 (default) offobs_coef_mois (max_dom) 6.e-4 nudging coefficient for water vapor mixing ratio (s-1)obs_coef_pstr 0. nudging coefficient for surface pressure (s-1) (not used)obs_rinxy 200. horizontal radius of influence (km; 200 is a reasonable value, but should be adjusted, based on data density)obs_rinsig 0.1 vertical radius of influence in eta (0.1 is a reasonable value, but should be adjusted, based on data density)obs_twindo (max_dom) 0.666667 half-period time window over which an observation will be used for nudging (hrs)obs_npfi 10 frequency in coarse grid timesteps for diagnostic printsobs_ionf (max_dom) 1 frequency in coarse grid timesteps for obs input and err calcobs_idynin 1 for dynamic initialization using a ramp-down function to gradually turn off the FDDA before the pure forecast (default is 0=off)obs_dtramp 40. time period (mins) over which the nudging is ramped down from one to zeroobs_prt_max 1000 maximum allowed obs entries in diagnostic printoutobs_prt_freq (max_dom) 1000 frequency in obs index for diagnostic printoutobs_ipf_in4dob .true. print obs input diagnostics (default is .false.=off)obs_ipf_errob .true. print obs error diagnostics (default is .false.=off)obs_ipf_nudob .true. print obs nudge diagnostics (default is .false.=off)obs_ipf_init .true. (default) enable obs printed warning messagesobs_no_pbl_nudge_uv 1 no wind-nudging within the PBL(max_dom)
advection optionsrk_ord time-integration scheme option 2 Runge-Kutta 2nd order 3 (default/recommended) Runge- Kutta 3rd orderdiff_opt (max_dom) turbulence and mixing option 0 no turbulence or explicit spatial numerical filters (km_opt is ignored) 1 (default) evaluates 2nd order diffusion term on coordinate surfaces, uses kvdif for vertical diffusion unless PBL option is used, may be used with km_opt = 1 (recommended for real-data case) and 4 2 evaluates mixing terms in physical space (stress form) (x,y,z); turbulence parameterization is chosen by specifying km_optkm_opt (max_dom) eddy coefficient option 1 (default) constant (use khdif and kvdif) 2 1.5 order TKE closure (3D) ** Not recommended for DX > 2 km 3 Smagorinsky first order closure (3D) **Not recommended for DX > 2 km 4 horizontal Smagorinsky first order closure (recommended for real- data case)diff_6th_opt (max_dom) 6th-order numerical diffusion 0 (default) no 6th-order diffusion 1 6th-order numerical diffusion 2 6th-order numerical diffusion, but prohibit up-gradient diffusiondiff_6th_factor 0.12 6th-order numerical diffusion non- dimensional rate (max value 1.0 corresponds to complete removal of 2dx wave in one timestep)damp_opt upper-level damping flag 0 (default) no damping 1 with diffusive damping; maybe used for real-data cases (dampcoef nondimensional ~
0.01 to 0.1) 2 with Rayleigh damping (dampcoef inverse time scale [1/s], e.g. 0.003) 3 with Rayleigh damping (dampcoef inverse time scale [1/s], e.g. 0.2; for real-data cases)use_theta_m (new since 1 uses theta(1+1.61Qv); (defaultV3.7) 0=off)use_q_diabatic (new since 1 includes QV and QC tendencies inV3.7) advection; this helps to produce correct solution in an idealized 'moist benchmark' test case (Bryan, 2014). In real data testing, time step needs to be reduced to maintain a stable solution (default 0=off)c_s (new since V3.7) 0.25 (default) Smagorinsky coeffc_k (new since V3.7) 0.15 (default) TKE coeffzdamp (max_dom) 5000 damping depth (m) from model topdampcoef (max_dom) 0. damping coefficient (see damp_opt)w_damping vertical velocity damping flag (for operational use) 0 (default) no damping 1 with dampingbase_pres 100000 base state surface pressure (Pa); real only., not recommended to change.base_temp 290. base state temperature (K); real onlybase_lapse 50. real-data ONLY, lapse rate (K), not recommended to changeiso_temp 200. isothermal temperature in statosphere; enables model to be (default value extended to 5 mb; real only. changed to 200 in Default value changed to 200 since V3.5) V3.5base_pres_strat (New since 0. real data, em ONLY, base stateV3.6.1) (default value set to 0 pressure (Pa) at bottom of the mb in V3.7) stratosphere, US Standard atmosphere 55 hPa.base_lapse_strat (new since -11. (default) real-data; em ONLY,V3.6.1) base state lapse rate (dT/d(lnP)) in stratosphere, approx to US standard atmosphere -12K
(default is 0 = off)
&grib2background_proc_id 255 (default); background generating process identifier, typically defined by the originating center to identify the background data that was used in creating the data; this is octet 13 of Section 4 in the grib2 messageforecast_proc_id 255 (default) analysis or generating forecast process identifier, typically defined by the originating center to identify the forecast process that was used to generate the data; this is octet 14 of Section 4 in the grib2 messageproduction_status 255 (default) production status of processed data in the grib2 message; see Code Table 1.3 of the grib2 manual; this is octect 20 of Section 1 in the grib2 record.compression the compression method to encode the output grib2 message; only jpeg2000 and PNG are supported. 40 (default) for jpeg2000 41 PNG
V3.7.1) interpolate toz_levels (new since V3.7.1) 0 list of height values (m) to interpolate data to; positive numbers are for height above mean sea level (i.e., a flight level), negative numbers are for level above groundp_lev_missing -999. Missing value below ground
List of Fields
The following is an edited output list from the netCDF command 'ncdump -h'. Note thatvalid output fields will depend on the model options used. If the fields have zero values,then the fields are not computed by the model options selected.
ncdump -h wrfout_d<domain>_<date>
netcdf wrfout_d01_2000-01-24_12:00:00
dimensions: Time = UNLIMITED ; // (1 currently) DateStrLen = 19 ; west_east = 73 ; south_north = 60 ; bottom_top = 29 ; bottom_top_stag = 30 ; soil_layers_stag = 4 ; west_east_stag = 74 ; south_north_stag = 61 ;
variables: char Times(Time, DateStrLen) ; float LU_INDEX(Time, south_north, west_east) ; LU_INDEX:description = "LAND USE CATEGORY" ; LU_INDEX:units = "" ; float ZNU(Time, bottom_top) ; ZNU:description = "eta values on half (mass) levels" ; ZNU:units = "" ; float ZNW(Time, bottom_top_stag) ; ZNW:description = "eta values on full (w) levels" ; ZNW:units = "" ; float ZS(Time, soil_layers_stag) ; ZS:description = "DEPTHS OF CENTERS OF SOIL LAYERS" ; ZS:units = "m" ; float DZS(Time, soil_layers_stag) ; DZS:description = "THICKNESSES OF SOIL LAYERS" ; DZS:units = "m" ; float U(Time, bottom_top, south_north, west_east_stag) ; U:description = "x-wind component" ; U:units = "m s-1" ; float V(Time, bottom_top, south_north_stag, west_east) ; V:description = "y-wind component" ; V:units = "m s-1" ; float W(Time, bottom_top_stag, south_north, west_east) ; W:description = "z-wind component" ; W:units = "m s-1" ; float PH(Time, bottom_top_stag, south_north, west_east) ; PH:description = "perturbation geopotential" ; PH:units = "m2 s-2" ; float PHB(Time, bottom_top_stag, south_north, west_east) ; PHB:description = "base-state geopotential" ; PHB:units = "m2 s-2" ; float T(Time, bottom_top, south_north, west_east) ; T:description = "perturbation potential temperature (theta-t0)" ; T:units = "K" ; float MU(Time, south_north, west_east) ; MU:description = "perturbation dry air mass in column" ;
MU:units = "Pa" ;float MUB(Time, south_north, west_east) ; MUB:description = "base state dry air mass in column" ; MUB:units = "Pa" ;float NEST_POS(Time, south_north, west_east) ; NEST_POS:description = "-" ; NEST_POS:units = "-" ;float P(Time, bottom_top, south_north, west_east) ; P:description = "perturbation pressure" ; P:units = "Pa" ;float PB(Time, bottom_top, south_north, west_east) ; PB:description = "BASE STATE PRESSURE" ; PB:units = "Pa" ;float FNM(Time, bottom_top) ; FNM:description = "upper weight for vertical stretching" ; FNM:units = "" ;float FNP(Time, bottom_top) ; FNP:description = "lower weight for vertical stretching" ; FNP:units = "" ;float RDNW(Time, bottom_top) ; RDNW:description = "inverse d(eta) values between full (w) levels" ; RDNW:units = "" ;float RDN(Time, bottom_top) ; RDN:description = "inverse d(eta) values between half (mass) levels" ; RDN:units = "" ;float DNW(Time, bottom_top) ; DNW:description = "d(eta) values between full (w) levels" ; DNW:units = "" ;float DN(Time, bottom_top) ; DN:description = "d(eta) values between half (mass) levels" ; DN:units = "" ;float CFN(Time) ; CFN:description = "extrapolation constant" ; CFN:units = "" ;float CFN1(Time) ; CFN1:description = "extrapolation constant" ; CFN1:units = "" ;float P_HYD(Time, bottom_top, south_north, west_east) ; P_HYD:description = "hydrostatic pressure" ; P_HYD:units = "Pa" ;float Q2(Time, south_north, west_east) ; Q2:description = "QV at 2 M" ; Q2:units = "kg kg-1" ;float T2(Time, south_north, west_east) ; T2:description = "TEMP at 2 M" ; T2:units = "K" ;float TH2(Time, south_north, west_east) ; TH2:description = "POT TEMP at 2 M" ; TH2:units = "K" ;float PSFC(Time, south_north, west_east) ; PSFC:description = "SFC PRESSURE" ; PSFC:units = "Pa" ;float U10(Time, south_north, west_east) ; U10:description = "U at 10 M" ; U10:units = "m s-1" ;float V10(Time, south_north, west_east) ; V10:description = "V at 10 M" ; V10:units = "m s-1" ;float RDX(Time) ; RDX:description = "INVERSE X GRID LENGTH" ; RDX:units = "" ;float RDY(Time) ; RDY:description = "INVERSE Y GRID LENGTH" ; RDY:units = "" ;float RESM(Time) ;
HGT_SHAD:units = "m" ; float TSK(Time, south_north, west_east) ; TSK:description = "SURFACE SKIN TEMPERATURE" ; TSK:units = "K" ; float P_TOP(Time) ; P_TOP:description = "PRESSURE TOP OF THE MODEL" ; P_TOP:units = "Pa" ; float T00(Time) ; T00:description = "BASE STATE TEMPERATURE" ; T00:units = "K" ; float P00(Time) ; P00:description = "BASE STATE PRESURE" ; P00:units = "Pa" ; float TLP(Time) ; TLP:description = "BASE STATE LAPSE RATE" ; TLP:units = "" ; float TISO(Time) ; TISO:description = "TEMP AT WHICH THE BASE T TURNS CONST" ; TISO:units = "K" ; float MAX_MSTFX(Time) ; MAX_MSTFX:description = "Max map factor in domain" ; MAX_MSTFX:units = "" ; float MAX_MSTFY(Time) ; MAX_MSTFY:description = "Max map factor in domain" ; MAX_MSTFY:units = "" ; float RAINC(Time, south_north, west_east) ; RAINC:description = "ACCUMULATED TOTAL CUMULUS PRECIPITATION" ; RAINC:units = "mm" ;float RAINSH(Time, south_north, west_east) ; RAINSH:description = "ACCUMULATED SHALLOW CUMULUS PRECIPITATION" ; RAINSH:units = "mm" ; float RAINNC(Time, south_north, west_east) ; RAINNC:description = "ACCUMULATED TOTAL GRID SCALE PRECIPITATION" ; RAINNC:units = "mm" ; float PRATEC(Time, south_north, west_east) ; PRATEC:description = "PRECIP RATE FROM CUMULUS SCHEME" ; PRATEC:units = "mm s-1" ; float RAINCV(Time, south_north, west_east) ; RAINCV:description = "TIME-STEP CUMULUS PRECIPITATION" ; RAINCV:units = "mm" ; float SNOWNC(Time, south_north, west_east) ; SNOWNC:description = "ACCUMULATED TOTAL GRID SCALE SNOW AND ICE" ; SNOWNC:units = "mm" ; float GRAUPELNC(Time, south_north, west_east) ; GRAUPELNC:description = "ACCUMULATED TOTAL GRID SCALE GRAUPEL" ; GRAUPELNC:units = "mm" ; float SWDOWN(Time, south_north, west_east) ; SWDOWN:description = "DOWNWARD SHORT WAVE FLUX AT GROUND SURFACE" ; SWDOWN:units = "W m-2" ; float GLW(Time, south_north, west_east) ; GLW:description = "DOWNWARD LONG WAVE FLUX AT GROUND SURFACE" ; GLW:units = "W m-2" ;float SWNORM(Time, south_north, west_east) ; SWNORM:description = "NORMAL SHORT WAVE FLUX AT GROUND SURFACE" ; SWNORM:units = "W m-2" ; float OLR(Time, south_north, west_east) ; OLR:description = "TOA OUTGOING LONG WAVE" ; OLR:units = "W m-2" ; float XLAT(Time, south_north, west_east) ; XLAT:description = "LATITUDE, SOUTH IS NEGATIVE" ; XLAT:units = "degree_north" ; float XLONG(Time, south_north, west_east) ; XLONG:description = "LONGITUDE, WEST IS NEGATIVE" ; XLONG:units = "degree_east" ; float XLAT_U(Time, south_north, west_east_stag) ;
// global attributes:
:WEST-EAST_GRID_DIMENSION = 74 ; :SOUTH-NORTH_GRID_DIMENSION = 61 ; :BOTTOM-TOP_GRID_DIMENSION = 28 ; :DX = 30000.f ; :DY = 30000.f ; :STOCH_FORCE_OPT = 0 ; :GRIDTYPE = "C" ; :DIFF_OPT = 1 ; :KM_OPT = 4 ; :DAMP_OPT = 0 ; :DAMPCOEF = 0.2f ; :KHDIF = 0.f ; :KVDIF = 0.f ; :MP_PHYSICS = 3 ; :RA_LW_PHYSICS = 1 ; :RA_SW_PHYSICS = 1 ; :SF_SFCLAY_PHYSICS = 1 ; :SF_SURFACE_PHYSICS = 2 ; :BL_PBL_PHYSICS = 1 ; :CU_PHYSICS = 1 ; :SF_LAKE_PHYSICS = 0 ; :SURFACE_INPUT_SOURCE = 1 ; :SST_UPDATE = 0 ; :GRID_FDDA = 0 ; :GFDDA_INTERVAL_M = 0 ; :GFDDA_END_H = 0 ; :GRID_SFDDA = 0 ; :SGFDDA_INTERVAL_M = 0 ; :SGFDDA_END_H = 0 ; :HYPSOMETRIC_OPT = 2 ; :SF_URBAN_PHYSICS = 0 ; :SHCU_PHYSICS = 0 ; :MFSHCONV = 0 ; :FEEDBACK = 1 ; :SMOOTH_OPTION = 0 ; :SWRAD_SCAT = 1.f ; :W_DAMPING = 0 ; :DT = 180.f ; :RADT = 30.f ; :BLDT = 0.f ; :CUDT = 5.f ; :AER_OPT = 0 ; :SWINT_OPT = 0 ; :AER_TYPE = 1 ; :AER_AOD550_OPT = 1 ; :AER_ANGEXP_OPT = 1 ; :AER_SSA_OPT = 1 ; :AER_ASY_OPT = 1 ; :AER_AOD550_VAL = 0.12f ; :AER_ANGEXP_VAL = 1.3f ; :AER_SSA_VAL = 0.f ; :AER_ASY_VAL = 0.f ; :MOIST_ADV_OPT = 1 ; :SCALAR_ADV_OPT = 1 ; :TKE_ADV_OPT = 1 ; :DIFF_6TH_OPT = 0 ; :DIFF_6TH_FACTOR = 0.12f ; :OBS_NUDGE_OPT = 0 ; :BUCKET_MM = -1.f ; :BUCKET_J = -1.f ; :PREC_ACC_DT = 0.f ; :SF_OCEAN_PHYSICS = 0 ; :ISFTCFLX = 0 ; :ISHALLOW = 0 ; :ISFFLX = 1 ;
:ICLOUD = 1 ; :ICLOUD_CU = 0 ; :TRACER_PBLMIX = 1 ; :SCALAR_PBLMIX = 0 ; :GRAV_SETTLING = 0 ; :DFI_OPT = 0 ; :WEST-EAST_PATCH_START_UNSTAG = 1 ; :WEST-EAST_PATCH_END_UNSTAG = 73 ; :WEST-EAST_PATCH_START_STAG = 1 ; :WEST-EAST_PATCH_END_STAG = 74 ; :SOUTH-NORTH_PATCH_START_UNSTAG = 1 ; :SOUTH-NORTH_PATCH_END_UNSTAG = 60 ; :SOUTH-NORTH_PATCH_START_STAG = 1 ; :SOUTH-NORTH_PATCH_END_STAG = 61 ; :BOTTOM-TOP_PATCH_START_UNSTAG = 1 ; :BOTTOM-TOP_PATCH_END_UNSTAG = 27 ; :BOTTOM-TOP_PATCH_START_STAG = 1 ; :BOTTOM-TOP_PATCH_END_STAG = 28 ; :GRID_ID = 1 ; :PARENT_ID = 0 ; :I_PARENT_START = 1 ; :J_PARENT_START = 1 ; :PARENT_GRID_RATIO = 1 ; :DT = 180.f ; :CEN_LAT = 34.83002f ; :CEN_LON = -81.03f ; :TRUELAT1 = 30.f ; :TRUELAT2 = 60.f ; :MOAD_CEN_LAT = 34.83002f ; :STAND_LON = -98.f ; :POLE_LAT = 90.f ; :POLE_LON = 0.f ; :GMT = 12.f ; :JULYR = 2000 ; :JULDAY = 24 ; :MAP_PROJ = "Lambert Conformal" ; :MMINLU = "USGS" ; :NUM_LAND_CAT = 24 ; :ISWATER = 16 ; :ISLAKE = -1 ; :ISICE = 24 ; :ISURBAN = 1 ; :ISOILWATER = 14 ;
The WRF model outputs the state variables defined in the Registry file, and these statevariables are used in the model's prognostic equations. Some of these variables areperturbation fields; therefore the following definitions for reconstructing meteorologicalvariables are necessary:
• Introduction • Installing WRFDA for 3D-Var Run • Installing WRFPLUS and WRFDA for 4D-Var Run • Running Observation Preprocessor (OBSPROC) • Running WRFDA • Radiance Data Assimilation in WRFDA • Radar Data Assimilation in WRFDA • Precipitation Data Assimilation in WRFDA 4D-Var • Updating WRF Boundary Conditions • Background Error and running GEN_BE • Additional WRFDA Exercises • WRFDA Diagnostics • Generating ensembles with RANDOMCV • Hybrid Data Assimilation • ETKF Data Assimilation • Description of Namelist Variables
Data assimilation is the technique by which observations are combined with an NWPproduct (the first guess or background forecast) and their respective error statistics toprovide an improved estimate (the analysis) of the atmospheric (or oceanic, Jovian, etc.)state. Variational (Var) data assimilation achieves this through the iterative minimizationof a prescribed cost (or penalty) function. Differences between the analysis and observa-tions/first guess are penalized (damped) according to their perceived error. The differencebetween three-dimensional (3D-Var) and four-dimensional (4D-Var) data assimilation isthe use of a numerical forecast model in the latter.
Various components of the WRFDA system are shown in blue in the sketch below, to-gether with their relationship with the rest of the WRF system.
xb first guess, either from a previous WRF forecast or from WPS/real.exe output. xlbc lateral boundary from WPS/real.exe output. xa analysis from the WRFDA data assimilation system. xf WRF forecast output. yo observations processed by OBSPROC. (note: PREPBUFR input, radar, radi- ance, and rainfall data do not go through OBSPROC) B0 background error statistics from generic BE data (CV3) or gen_be. R observational and representative error statistics.
In this chapter, you will learn how to install and run the various components of theWRFDA system. For training purposes, you are supplied with a test case, including thefollowing input data:
• observation files, • a netCDF background file (WPS/real.exe output, the first guess of the analysis) • background error statistics (estimate of errors in the background file). • This tutorial dataset can be downloaded from the WRFDA Users Page (http://www2.mmm.ucar.edu/wrf/users/wrfda/download/testdata.html), and will be described later in more detail. In your own work, however, you will have to create all these input files yourself. See the section "Running Observation Prepro- cessor" for creating your observation files. See the section "Background Error and running GEN_BE" for generating your background error statistics file, if you want to use cv_options=5, 6, or 7.
Before using your own data, we suggest that you start by running through the WRFDA-related programs using the supplied test case. This serves two purposes: First, you canlearn how to run the programs with data we have tested ourselves, and second you cantest whether your computer is capable of running the entire data assimilation system. Af-ter you have done the tutorial, you can try running other, more computationally intensivecase studies, and experimenting with some of the many namelist variables.
Hopefully, our test cases will prepare you for the variety of ways in which you may wishto run your own WRFDA experiments. Please inform us about your experiences.
As a professional courtesy, we request that you include the following references in anypublication that uses any component of the community WRFDA system:
Barker, D.M., W. Huang, Y.R. Guo, and Q.N. Xiao., 2004: A Three-Dimensional(3DVAR) Data Assimilation System For Use With MM5: Implementation and Initial Re-sults. Mon. Wea. Rev., 132, 897-914.
Barker, D., X.-Y. Huang, Z. Liu, T. Auligné, X. Zhang, S. Rugg, R. Ajjaji, A. Bourgeois,J. Bray, Y. Chen, M. Demirtas, Y.-R. Guo, T. Henderson, W. Huang, H.-C. Lin, J.Michalakes, S. Rizvi, and X. Zhang, 2012: The Weather Research and Forecasting Mod-el's Community Variational/Ensemble Data Assimilation System: WRFDA. Bull. Amer.Meteor. Soc., 93, 831–843.
Running WRFDA requires a Fortran 90 compiler. The WRFDA system can be compiledon the following platforms: Linux (ifort, gfortran, pgf90), Macintosh (gfortran, ifort),IBM (xlf), and SGI Altix (ifort). Please let us know if this does not meet your require-ments, and we will attempt to add other machines to our list of supported architectures, asresources allow. Although we are interested in hearing about your experiences in modify-ing compiler options, we do not recommend making changes to the configure file used tocompile WRFDA.
Note: Although the WRFDA package also contains the WRF source code, they cannot be built together. WRF should be downloaded and compiled separately.
After the tar file is unzipped (gunzip WRFDAV3.8.1.TAR.gz) and untarred (tar -xfWRFDAV3.8.1.TAR), the directory WRFDA should be created. This directory contains theWRFDA source, external libraries, and fixed files. The following is a list of the systemcomponents and content for each subdirectory:
Some external libraries (e.g., LAPACK, BLAS, and NCEP BUFR) are included in theWRFDA tar file. To compile the WRFDA code, the only mandatory library is the netCDFlibrary. You should set an environment variable NETCDF to point to the directory whereyour netCDF library is installed
The source code for BUFRLIB 10.2.3 (with minor modifications) is included in theWRFDA tar file, and is compiled automatically. This library will be used for assimilatingfiles in PREPBUFR and NCEP BUFR format.
Starting with WRFDA version 3.8, AMSR2 data can be assimilated in HDF5 format,which requires the use of HDF5 libraries. If you wish to make use of this capability, youshould ensure that HDF5 libraries are installed on your system (or download and installthem yourself; the source code is available from https://www.hdfgroup.org/HDF5/). Touse HDF5 in WRFDA, you should set the environment variable "HDF5" to the parentpath of your HDF5 build:
The HDF5 path should contain the directories "include" and "lib".
For some platforms, you may have to also add the HDF5 "lib" directory to your environ-ment variable LD_LIBRARY_PATH:
If satellite radiance data are to be used, a Radiative Transfer Model (RTM) is required.The current RTM versions that WRFDA supports are CRTM V2.1.3 and RTTOV V11.1–11.3 .
The CRTM V2.1.3 source code is included in the WRFDA tar file, and is compiled au-tomatically. No action is needed from the user.
If the user wishes to use RTTOV, download and install the RTTOV v11 library beforecompiling WRFDA. This library can be downloaded fromhttp://nwpsaf.eu/deliverables/rtm/index.html. The RTTOV libraries must be compiledwith the "emis_atlas" option in order to work with WRFDA; see the RTTOV "re-adme.txt" for instructions on how to do this. After compiling RTTOV (see theRTTOV documentation for detailed instructions), set the "RTTOV" environment variableto the path where the lib directory resides. For example, if the library files can be foundin /usr/local/rttov11/gfortran/lib/librttov11.*.a, you should set RTTOV as:
Note: Make sure the required libraries were all compiled using the same compilerthat will be used to build WRFDA, since the libraries produced by one compiler maynot be compatible with code compiled with another.
Assuming all required libraries are available and the WRFDA source code is ready, youcan start to build WRFDA using the following steps:
> cd WRFDA > ./configure wrfda
A list of configuration options should appear. Each option combines an operating system,a compiler type, and a parallelism option. Since the configuration script doesn't checkwhich compilers are actually installed on your system, be sure to select only among theoptions that you have available to you. The available parallelism options are single-processor (serial), shared-memory parallel (smpar), distributed-memory parallel (dmpar),and distributed-memory with shared-memory parallel (sm+dm). However, shared-memory (smpar and sm+dm) options are not supported as of WRFDA Version3.8.1, so we do not recommend selecting any of these options.
For example, on a Linux machine such as NCAR's Yellowstone, the above steps willlook similar to the following:checking for perl5... nochecking for perl... found /usr/bin/perl (perl)Will use NETCDF in dir: /glade/apps/opt/netcdf/4.3.0/gnu/4.8.2/Will use HDF5 in dir: /glade/u/apps/opt/hdf5/1.8.12/gnu/4.8.2/PHDF5 not set in environment. Will configure WRF for use without.Will use 'time' to report timing information$JASPERLIB or $JASPERINC not found in environment, configuring to build without grib2I/O...------------------------------------------------------------------------Please select from among the following Linux x86_64 options:
Configuration successful!------------------------------------------------------------------------... ...
After entering the option that corresponds to your machine/compiler combination, theconfigure script should print the message "Configuration successful!" followed by a largeamount of configuration information. Depending on your system, you may see a warningmessage mentioning that some Fortran 2003 features have been removed: this message isnormal and can be ignored. However, if you see a message "One of compilers testingfailed! Please check your compiler", configuration has probably failed, and you shouldmake sure you have selected the correct option.
After running the configuration script and choosing a compilation option, a config-ure.wrf file will be created. Because of the variety of ways that a computer can be con-figured, if the WRFDA build ultimately fails, there is a chance that minor modificationsto the configure.wrf file may be needed.
The main executable for running WRFDA is da_wrfvar.exe. Make sure it has beencreated after the compilation: it is fairly common that all the executables will be success-fully compiled except this main executable. If this occurs, please check the compilationlog file carefully for any errors.
The basic gen_be utility for the regional model consists of gen_be_stage0_wrf.exe,gen_be_stage1.exe, gen_be_stage2.exe, gen_be_stage2a.exe,gen_be_stage3.exe, gen_be_stage4_regional.exe, and gen_be_diags.exe.
da_update_bc.exe is used for updating the WRF lower and lateral boundary conditionsbefore and after a new WRFDA analysis is generated. This is detailed in the section onUpdating WRF Boundary Conditions.
da_advance_time.exe is a very handy and useful tool for date/time manipulation. Type$WRFDA_DIR/var/build/da_advance_time.exe to see its usage instructions.
c. Clean Compilation
./clean -a
Note: if you intend to run both 3DVAR and 4DVAR experiments, it is not necessary to compile the code twice. The da_wrfvar.exe executable compiled for 4DVAR can be used for both 3DVAR and 4DVAR assimilation.
To install WRFPLUS:
• Unzip and untar the WRFPLUS file, then run the configure script
• Compile WRFPLUS
If compilation was successful, you should see the WRFPLUS executable (named wrf.exe):
• If you intend to use RTTOV to assimilate radiance data, you will need to set the appropriate environment variable at compile time. See the previous 3D-Var sec- tion for instructions.
>./configure 4dvar
You should see the same 44 executables as are listed in the above 3D-Var section, including da_wrfvar.exe
own applications, you will have to prepare your own observation files. Please seehttp://www2.mmm.ucar.edu/wrf/users/wrfda/download/free_data.html for the sources of somefreely-available observations. Because the raw observation data files have many possibleformats, such as ASCII, BUFR, PREPBUFR, MADIS (note: a converter for MADIS datato LITTLE_R is available on the WRFDA website:http://www2.mmm.ucar.edu/wrf/users/wrfda/download/madis.html), and HDF, the free data site alsocontains instructions for converting the observations to LITTLE_R format. To make theWRFDA system as general as possible, the LITTLE_R format was adopted as an inter-mediate observation data format for the WRFDA system, however, the conversion of theuser-specific source data to LITTLE_R format is the user's task. A more complete de-scription of the LITTLE_R format, as well as conventional observation data sources forWRFDA, can be found by reading the "Observation Pre-processing" tutorial found athttp://www2.mmm.ucar.edu/wrf/users/wrfda/Tutorials/2015_Aug/tutorial_presentations_summer_2015.html, or byreferencing Chapter 7 of this User's Guide.
If you haven't already, you should download the tutorial case, which contains examplefiles for all the exercises in this User's Guide. The case can be found at the WRFDAwebsite (http://www2.mmm.ucar.edu/wrf/users/wrfda/download/testdata.html).
As an example, to prepare the observation file at the analysis time, all the observations inthe range ±1h will be processed, which means that (in the example case) the observationsbetween 23h and 1h are treated as the observations at 0h. This is illustrated in the follow-ing figure:
The files obserr.txt and msfc.tbl are included in the source code undervar/obsproc. To create the required namelist file, we have provided an example file(namelist_obsproc.3dvar.wrfvar-tut) in the var/obsproc directory. Thus, proceedas follows.
> cd $WRFDA_DIR/var/obsproc > cp namelist.obsproc.3dvar.wrfvar-tut namelist.obsproc
If you are running the tutorial case, you should copy or link the sample observation file(ob/2008020512/obs.2008020512) to the obsproc directory. Alternatively, you can editthe namelist variable obs_gts_filename to point to the observation file's full path.
Once obsproc.exe has completed successfully, you will see an observation data file,with the name formatted obs_gts_YYYY-MM-DD_HH:NN:SS.3DVAR, in the obsproc direc-
Before running WRFDA, you may find it useful to learn more about various types of datathat will be processed (e.g., their geographical distribution). This file is in ASCII formatand so you can easily view it. For a graphical view of the file's content, there are NCLscripts available which can display the distribution and type of observations. In theWRFDA Tools package (can be downloaded athttp://www2.mmm.ucar.edu/wrf/users/wrfda/download/tools.html), the relevant script is located at$TOOLS_DIR/var/graphics/ncl/plot_ob_ascii_loc.ncl. You will need to haveNCL installed in your system to use this script; for more information on NCL, the NCARCommand Language, see http://www.ncl.ucar.edu/.
To prepare the observation file, for example, at the analysis time 0h for 4D-Var, all ob-servations from 0h to 6h will be processed and grouped in 7 sub-windows (slot1 throughslot7) as illustrated in the following figure:
NOTE: The "Analysis time" in the above figure is not the actual analysis time (0h). Itindicates the time_analysis setting in the namelist file, which in this example is threehours later than the actual analysis time. The actual analysis time is still 0h.
> cd $WRFDA_DIR/var/obsproc > cp namelist.obsproc.4dvar.wrfvar-tut namelist.obsproc
In the namelist file, you need to change the following variables to accommodate your ex-periments. In this tutorial case, the actual analysis time is 2008-02-05_12:00:00, butin the namelist, time_analysis should be set to 3 hours later. The different values oftime_analysis, num_slots_past, and time_slots_ahead contribute to the actualtimes analyzed. For example, if you set time_analysis = 2008-02-05_16:00:00, and setthe num_slots_past = 4 and time_slots_ahead=2, the final results will be the same asbefore.
Edit all the domain settings according to your own experiment; a full list of namelist op-tions and descriptions can be found in the section Description of Namelist Variables.You should pay special attention to the record 7 and record 8 variables: these will deter-mine the domain for which observations will be written to the output observation file.Alternatively, if you do not wish to filter the observations spatially, you can set do-main_check_h = .false. under &record4.
Once obsproc.exe has completed successfully, you will see 7 observation data files,which for the tutorial case are named
Running WRFDA
a) WRF first guess file, output from either WPS/real.exe (cold-start) or a WRF forecast (warm-start)
In the test case, you will store data in a directory defined by the environment variable$DAT_DIR. This directory can be in any location, and it should have read access. Type
Here, your_choice_of_dat_dir is the directory where the WRFDA input data is stored.
If you have not already done so, download the sample data for the tutorial case, valid at12 UTC 5th February 2008, fromhttp://www2.mmm.ucar.edu/wrf/users/wrfda/download/testdata.html
Now you should find the following four files under "$DAT_DIR"
At this point you should have three of the input files (first guess, observations from OB-SPROC, and background error statistics files in the directory $DAT_DIR) required to runWRFDA, and have successfully downloaded and compiled the WRFDA code. If this iscorrect, you are ready to run WRFDA.
The data for the tutorial case is valid at 12 UTC 5 February 2008. The first guess comesfrom the NCEP FNL (Final) Operational Global Analysis data, passed through the WRF-WPS and real.exe programs.
To run WRF 3D-Var, first create and enter into a working directory (for example,$WRFDA_DIR/workdir), and set the environment variable WORK_DIR to this directory (e.g.,setenv WORK_DIR $WRFDA_DIR/workdir). Then follow the steps below:
> cd $WORK_DIR> cp $DAT_DIR/namelist.input.3dvar namelist.input> ln -sf $WRFDA_DIR/run/LANDUSE.TBL .> ln -sf $DAT_DIR/rc/2008020512/wrfinput_d01 ./fg> ln -sf $DAT_DIR/ob/2008020512/obs_gts_2008-02-05_12:00:00.3DVAR./ob.ascii (note the different name!)> ln -sf $DAT_DIR/be/be.dat .> ln -sf $WRFDA_DIR/var/da/da_wrfvar.exe .
Now edit the file namelist.input, which is a very basic namelist for the tutorial testcase, and is shown below. &wrfvar1 var4d=false, print_detail_grad=false, / &wrfvar2 / &wrfvar3 ob_format=2, / &wrfvar4 / &wrfvar5 /
&wrfvar6 max_ext_its=1, ntmax=50, orthonorm_gradient=true, / &wrfvar7 cv_options=5, / &wrfvar8 / &wrfvar9 / &wrfvar10 test_transforms=false, test_gradient=false, / &wrfvar11 / &wrfvar12 / &wrfvar13 / &wrfvar14 / &wrfvar15 / &wrfvar16 / &wrfvar17 / &wrfvar18 analysis_date="2008-02-05_12:00:00.0000", / &wrfvar19 / &wrfvar20 / &wrfvar21 time_window_min="2008-02-05_11:00:00.0000", / &wrfvar22 time_window_max="2008-02-05_13:00:00.0000", / &time_control start_year=2008, start_month=02, start_day=05, start_hour=12, end_year=2008, end_month=02, end_day=05, end_hour=12, / &fdda / &domains e_we=90, e_sn=60, e_vert=41, dx=60000, dy=60000, / &dfi_control / &tc / &physics mp_physics=3, ra_lw_physics=1, ra_sw_physics=1, radt=60, sf_sfclay_physics=1, sf_surface_physics=1,
bl_pbl_physics=1, cu_physics=1, cudt=5, num_soil_layers=5, mp_zero_out=2, co2tf=0, / &scm / &dynamics / &bdy_control / &grib2 / &fire / &namelist_quilt / &perturbation /
No edits should be needed if you are running the tutorial case without radiance data. Ifyou plan to use the PREPBUFR-format data, change the ob_format=1 in &wrfvar3 innamelist.input and link the data as ob.bufr,
Once you have changed any other necessary namelist variables, run WRFDA 3D-Var: > da_wrfvar.exe >& wrfda.log
Observation summary ob time 1 sound 86 global, 86 local synop 750 global, 750 local pilot 85 global, 85 local satem 105 global, 105 local geoamv 2499 global, 2499 local airep 216 global, 216 local gpspw 187 global, 187 local gpsrf 3 global, 3 local metar 2408 global, 2408 local ships 135 global, 135 local qscat 2126 global, 2126 local profiler 61 global, 61 local buoy 247 global, 247 local sonde_sfc 86 global, 86 local
WRFDA dry control variables are: psi, chi_u, t_u and ps_u Humidity control variable is rh
Diagnostics Final cost function J = 21327.96
The file namelist.output.da (which contains the complete namelist settings) will begenerated after a successful run of da_wrfvar.exe. The settings appearing in namel-ist.output.da, but not specified in your namelist.input, are the default values from$WRFDA_DIR/Registry/registry.var.
After successful completion, wrfvar_output (the WRFDA analysis file, i.e. the new ini-tial condition for WRF) should appear in the working directory along with a number ofdiagnostic files. Text files containing various diagnostics will be explained in theWRFDA Diagnostics section.
To understand the role of various important WRFDA options, try re-running WRFDA bychanging different namelist options. For example, try making the WRFDA convergencecriterion more stringent. This is achieved by reducing the value of "EPS" to e.g. 0.0001by adding "EPS=0.0001" in the namelist.input record &wrfvar6. See the section Addi-tional WRFDA exercises for more namelist options.
To run WRF 4D-Var, first create and enter a working directory, such as$WRFDA_DIR/workdir. Set the WORK_DIR environment variable (e.g. setenv WORK_DIR$WRFDA_DIR/workdir)
For the tutorial case, the analysis date is 2008020512 and the test data directories are: > setenv DAT_DIR {directory where data is stored} > ls –lr $DAT_DIR ob/2008020512 ob/2008020513 ob/2008020514 ob/2008020515 ob/2008020516 ob/2008020517 ob/2008020518 rc/2008020512 be
Note: WRFDA 4D-Var is able to assimilate conventional observational data, satellite ra-diance BUFR data, and precipitation data. The input data format can be PREPBUFRformat data or ASCII observation data, processed by OBSPROC.
WRFDA 4D-Var has the capability to consider lateral boundary conditions as controlvariables as well during minimization. The namelist variable var4d_lbc=true turnson this capability. To enable this option, WRF 4D-Var needs not only the first guess atthe beginning of the time window, but also the first guess at the end of the time window. > ln -fs $DAT_DIR/rc/2008020518/wrfinput_d01 fg02
Please note: WRFDA beginners should not use this option until you have a good under-standing of the 4D-Var lateral boundary conditions control. To disable this feature, makesure var4d_lbc in namelist.input is set to false.
Edit namelist.input to match your experiment settings. The most important namelistvariables related to 4D-Var are listed below. Please refer to README.namelist under the$WRFDA_DIR/var directory. A common mistake users make is in the time informationsettings. The rules are: analysis_date, time_window_min and start_xxx in&time_control should always be equal to each other; time_window_max and end_xxx
should always be equal to each other; and run_hours is the difference betweenstart_xxx and end_xxx, which is the length of the 4D-Var time window.
&wrfvar1 var4d=true, var4d_lbc=false, var4d_bin=3600, …… / …… &wrfvar18 analysis_date="2008-02-05_12:00:00.0000", / …… &wrfvar21 time_window_min="2008-02-05_12:00:00.0000", / …… &wrfvar22 time_window_max="2008-02-05_18:00:00.0000", / …… &time_control run_hours=6, start_year=2008, start_month=02, start_day=05, start_hour=12, end_year=2008, end_month=02, end_day=05, end_hour=18, interval_seconds=21600, debug_level=0, / ……
4DVAR is much more computationally expensive than 3DVAR, so running may take awhile; you can set ntmax to a lower value so that WRFDA uses fewer minimizationsteps. You can also MPI with multiple processors to speed up the execution: > mpirun –np 4 ./da_wrfvar.exe >& wrfda.log &
The "mpirun" command may be different depending on your machine. The output logswill be found in files named rsl.out.#### and rsl.error.#### for MPI runs.
Please note: If you utilize the lateral boundary conditions option (var4d_lbc=true), inaddition to the analysis at the beginning of the time window (wrfvar_output), the analy-sis at the end of the time window will also be generated as ana02, which will be used insubsequent updating of boundary conditions before the forecast.
This section gives a brief description for various aspects related to radiance assimilationin WRFDA. Each aspect is described mainly from the viewpoint of usage, rather thanmore technical and scientific details, which will appear in a separate technical report andscientific paper. Namelist parameters controlling different aspects of radiance assimila-tion will be detailed in the following sections. It should be noted that this section does notcover general aspects of the assimilation process with WRFDA; these can be found inother sections of chapter 6 of this user's guide, or other WRFDA documentation.
In addition to the basic input files (LANDUSE.TBL, fg, ob.ascii, be.dat) mentionedin the "Running WRFDA" section, the following additional files are required for radianc-es: radiance data (typically in NCEP BUFR format), radiance_info files,VARBC.in (if you plan on using variational bias correction VARBC, as described in thesection on bias correction), and RTM (CRTM or RTTOV) coefficient files.
See the following sections for more de- Note: You can also specify the path of the "tails on each aspect of radiance assimila- crtm_coeffs" directory via the namelist; seetion. the following section for more details
Currently, the ingest interface for NCEP BUFR radiance data is implemented inWRFDA. The radiance data are available through NCEP's public ftp server(ftp://ftp.ncep.noaa.gov/pub/data/nccf/com/gfs/prod/gdas.${yyyymmddhh}) in near real-time (with a 6-hour delay) and can meet requirements for both research purposes andsome real-time applications.
As of Version 3.8.1, WRFDA can read data from NOAA ATOVS instruments (HIRS,AMSU-A, AMSU-B and MHS), EOS Aqua instruments (AIRS, AMSU-A), DMSP in-struments (SSMIS), METOP instruments (HIRS, AMSU-A, MHS, IASI), Meteosat in-
struments (SEVIRI), and JAXA GCOM-W1 instruments (AMSR2). Note that NCEP ra-diance BUFR files are separated by instrument names (i.e., one file for each type of in-strument), and each file contains global radiance (generally converted to brightness tem-perature) within a 6-hour assimilation window, from multi-platforms. For runningWRFDA, users need to rename NCEP corresponding BUFR files (table 1) tohirs3.bufr (including HIRS data from NOAA-15/16/17), hirs4.bufr (includingHIRS data from NOAA-18/19, METOP-2), amsua.bufr (including AMSU-A datafrom NOAA-15/16/18/19, METOP-1 and -2), amsub.bufr (including AMSU-B datafrom NOAA-15/16/17), mhs.bufr (including MHS data from NOAA-18/19 andMETOP-1 and -2), airs.bufr (including AIRS and AMSU-A data from EOS-AQUA)ssmis.bufr (SSMIS data from DMSP-16, AFWA provided) iasi.bufr (IASI datafrom METOP-1 and -2) and seviri.bufr (SEVIRI data from Meteosat 8-10) forWRFDA filename convention. Note that the airs.bufr file contains not only AIRSdata but also AMSU-A, which is collocated with AIRS pixels (1 AMSU-A pixel collo-cated with 9 AIRS pixels). Users must place these files in the working directory wherethe WRFDA executable is run. It should also be mentioned that WRFDA reads theseBUFR radiance files directly without the use of any separate pre-processing program. Allprocessing of radiance data, such as quality control, thinning, bias correction, etc., is car-ried out within WRFDA. This is different from conventional observation assimilation,which requires a pre-processing package (OBSPROC) to generate WRFDA readableASCII files. For reading the radiance BUFR files, WRFDA must be compiled with theNCEP BUFR library (see http://www.nco.ncep.noaa.gov/sib/decoders/BUFRLIB/).
Namelist parameters are used to control the reading of corresponding BUFR files intoWRFDA. For instance, USE_AMSUAOBS, USE_AMSUBOBS, USE_HIRS3OBS,USE_HIRS4OBS, USE_MHSOBS, USE_AIRSOBS, USE_EOS_AMSUAOBS,USE_SSMISOBS, USE_ATMSOBS, USE_IASIOBS, and USE_SEVIRIOBS controlwhether or not the respective file is read. These are logical parameters that are assigned to.FALSE. by default; therefore they must be set to .TRUE. to read the respective observa-tion file. Also note that these parameters only control whether the data is read, not wheth-er the data included in the files is to be assimilated. This is controlled by other namelistparameters explained in the next section.
Sources for downloading these and other data can be found on the WRFDA website:
HDF5 file naming conventions are different than those for BUFR files. For AMSR2 data,WRFDA will look for two data files: L1SGRTBR.h5 (brightness temperature) andL2SGCLWLD.h5 (cloud liquid water). Only the brightness temperature file is mandatory(you will also need to copy or link the "leapsec.dat" file from WRFDA/var/run). If youhave multiple data files for your assimilation window, you should name themL1SGRTBR-01.h5, L1SGRTBR-02.h5, etc. and L2SGCLWLD-01.h5, L2SGCLWLD-02.h5, etc.
The core component for direct radiance assimilation is to incorporate a radiative transfermodel (RTM) into the WRFDA system as one part of observation operators. Two widelyused RTMs in the NWP community, RTTOV (developed by ECMWF and UKMET inEurope), and CRTM (developed by the Joint Center for Satellite Data Assimilation(JCSDA) in US), are already implemented in the WRFDA system with a flexible andconsistent user interface. WRFDA is designed to be able to compile with or withoutRTTOV by the definition of the "RTTOV" environment variable at compile time (see the"Compile WRFDA and Libraries" section). At runtime the user must select which RTMthey intend to use via the namelist parameter RTM_OPTION (1 for RTTOV, the default,and 2 for CRTM).
Both RTMs can calculate radiances for almost all available instruments aboard the vari-ous satellite platforms in orbit. An important feature of the WRFDA design is that all datastructures related to radiance assimilation are dynamically allocated during running time,according to a simple namelist setup. The instruments to be assimilated are controlled atrun-time by four integer namelist parameters: RTMINIT_NSENSOR (the total number ofsensors to be assimilated), RTMINIT_PLATFORM (the platforms IDs array to be assimi-lated with dimension RTMINIT_NSENSOR, e.g., 1 for NOAA, 9 for EOS, 10 forMETOP and 2 for DMSP), RTMINIT_SATID (satellite IDs array) andRTMINIT_SENSOR (sensor IDs array, e.g., 0 for HIRS, 3 for AMSU-A, 4 for AMSU-B,etc.). The full list of instrument triplets can be found in the table below:
Here's an example of this section of the namelist for a user assimilating IASI observa-tions from METOP-A, utilizing RTTOV as their RTM:
&wrfvar14 rtminit_nsensor = 1 rtminit_platform = 10, rtminit_satid = 2, rtminit_sensor = 16, rtm_option = 1,/
Here's another example of this section of the namelist, this time for a user assimilatingAMSU-A from NOAA 18–19 and EOS-Aqua, MHS from NOAA 18–19, and AIRS fromEOS-Aqua, utilizing CRTM as their RTM:
&wrfvar14 rtminit_nsensor = 6 rtminit_platform = 1, 1, 9, 1, 1, 9 rtminit_satid = 18, 19, 2, 18, 19, 2 rtminit_sensor = 3, 3, 3, 15, 15, 11 rtm_option = 2,/
The instrument triplets (platform, satellite, and sensor ID) in the namelist can be rankedin any order. More detail about the convention of instrument triples can be found in tables2 and 3 in the RTTOV v11 User's Guide(http://nwpsaf.eu/deliverables/rtm/docs_rttov11/users_guide_11_v1.4.pdf)
When running WRFDA with radiance assimilation switched on, a set of RTM coefficientfiles need to be loaded. For the RTTOV option, RTTOV coefficient files are to be copiedor linked to a sub-directory rttov_coeffs/ under the working directory. For the CRTMoption, CRTM coefficient files are to be copied or linked to a sub-directory
crtm_coeffs/ under the working directory, or the location of this directory can be spec-ified in the namelist:
&wrfvar14 crtm_coef_path = WRFDA/var/run/crtm_coeffs (Can be a relative or absolute path)/
Only coefficients for instruments listed in the namelist are needed. Potentially WRFDAcan assimilate all sensors as long as the corresponding coefficient files are provided. Inaddition, necessary developments on the corresponding data interface, quality control,and bias correction are important to make radiance data assimilate properly; however, amodular design of radiance relevant routines already facilitates the addition of more in-struments in WRFDA.
The RTTOV package is not distributed with WRFDA, due to licensing restrictions. Usersneed to follow the instructions at http://nwpsaf.eu/site/software/rttov/ to download the RTTOVsource code and supplement coefficient files and the emissivity atlas dataset. OnlyRTTOV v11 (11.1—11.3) can be used in WRFDA version 3.8.1, so if you have an olderversion of RTTOV you must upgrade.
To use one or both of the above radiative transfer models, you will have to set the appro-priate environment variable(s) at compile time. See the section "Compile WRFDA andLibraries" for details.
d. Channel Selection
Channel selection in WRFDA is controlled by radiance 'info' files, located in the sub-directory radiance_info, under the working directory. These files are separated by sat-ellites and sensors; e.g., noaa-15-amsua.info, noaa-16-amsub.info, dmsp-16-ssmis.info and so on. An example of 5 channels from noaa-15-amsub.info is shownbelow. The fourth column is used by WRFDA to control when to use a correspondingchannel. Channels with the value "-1" in the fourth column indicate that the channel is"not assimilated," while the value "1" means "assimilated." The sixth column is used byWRFDA to set the observation error for each channel. Other columns are not used byWRFDA. It should be mentioned that these error values might not necessarily be optimalfor your applications. It is the user's responsibility to obtain the optimal error statisticsfor his/her own applications.Sensor channel IR/MW use idum varch polarization(0:vertical;1:horizontal)
e. Bias Correction
All VarBC input is passed through a single ASCII file called VARBC.in. Once WRFDAhas run with the VarBC option switched on, it will produce a VARBC.out file in a similarASCII format. This output file will then be used as the input file for the next assimilationcycle.
VarBC ColdstartColdstarting means starting the VarBC from scratch; i.e. when you do not know the val-ues of the bias parameters.
The Coldstart is a routine in WRFDA. The bias predictor statistics (mean and standarddeviation) are computed automatically and will be used to normalize the bias parameters.All coldstart bias parameters are set to zero, except the first bias parameter (= simple off-set), which is set to the mode (=peak) of the distribution of the (uncorrected) innovationsfor the given channel.
It is defined in the namelist via the option VARBC_NBGERR; the default value is 5000. Thisnumber is related to a number of observations; the bigger the number, the more inertiaconstraint. If these numbers are set to zero, the predictors can evolve without any con-straint.
Scaling factorThe VarBC uses a specific preconditioning, which can be scaled through the namelist op-tion VARBC_FACTOR (default = 1.0).
Freeze VarBCIn certain circumstances, you might want to keep the VarBC bias parameters constant intime (="frozen"). In this case, the bias correction is read and applied to the innovations,but it is not updated during the minimization. This can easily be achieved by setting thenamelist options:
Passive observationsSome observations are useful for preprocessing (e.g. Quality Control, Cloud detection)but you might not want to assimilate them. If you still need to estimate their bias correc-tion, these observations need to go through the VarBC code in the minimization. For thispurpose, the VarBC uses a separate threshold on the QC values, called "qc_varbc_bad".This threshold is currently set to the same value as "qc_bad", but can easily be changed toany ad hoc value.
RAD_MONITORING (30) Integer array of dimension RTMINIT_NSENSOR, 0 for assimilating mode, 1 for monitoring mode (only calculates innovation).
THINNING Logical, TRUE will perform thinning on radiance data.
THINNING_MESH (30) Real array with dimension RTMINIT_NSENSOR, values indicate thinning mesh (in km) for different sensors.
QC_RAD Logical, controls if quality control is performed, always set to TRUE.
WRITE_IV_RAD_ASCII Logical, controls whether to output observation-minus-background (O-B) files, which are in ASCII format, and separated by sensors and processors.
WRITE_OA_RAD_ASCII Logical, controls whether to output observation-minus-analysis (O-A) files (in- cluding also O-B information), which are in ASCII format, and separated by sen- sors and processors.
USE_ERROR_FACTOR_RAD Logical, controls use of a radiance error tuning factor file (radiance_error.factor) which is created with empirical values, or generated using a variational tuning method (Desroziers and Ivanov, 2001).
ONLY_SEA_RAD Logical, controls whether only assimilating radiance over water.
TIME_WINDOW_MIN String, e.g., "2007-08-15_03:00:00.0000", start time of assimilation time window
TIME_WINDOW_MAX String, e.g., "2007-08-15_09:00:00.0000", end time of assimilation time window
USE_ANTCORR (30) Logical array with dimension RTMINIT_NSENSOR, controls if performing An- tenna Correction in CRTM.
USE_CLDDET_MMR Logical, controls whether using the MMR scheme to conduct cloud detection for infrared radiance.
USE_CLDDET_ECMWF Logical, controls whether using the ECMWF scheme to conduct cloud detection for infrared radiance.
Logical, controls whether using the observation brightness temperature for AIRS Window channel #914 as criterion for GSI thinning.
USE_CRTM_KMATRIX Logical, controls whether using the CRTM K matrix rather than calling CRTM TL and AD routines for gradient calculation.
USE_RTTOV_KMATRIX Logical, controls whether using the RTTOV K matrix rather than calling RTTOV TL and AD routines for gradient calculation.
RTTOV_EMIS_ATLAS_IR Integer, controls the use of the IR emissivity atlas. Emissivity atlas data (should be downloaded separately from the RTTOV web site) need to be copied or linked under a sub-directory of the working directory (emis_data) if RTTOV_EMIS_ATLAS_IR is set to 1.
RTTOV_EMIS_ATLAS_MW Integer, controls the use of the MW emissivity atlas. Emissivity atlas data (should be downloaded separately from the RTTOV web site) need to be copied or linked under a sub-directory of the working directory (emis_data) if RTTOV_EMIS_ATLAS_MW is set to 1 or 2.
0 means assimilating mode. Innovations (O minus B) are calculated and data are used in minimization. 1 means monitoring mode: innovations are calculated for diagnostics and moni- toring. Data are not used in minimization.
write_iv_rad_ascii Logical. TRUE to write out (observation-background, etc.) diagnostics in- formation in plain-text files with the prefix 'inv,' followed by the instru- ment name and the processor id. For example, 01_inv_noaa-17- amsub.0000 (01 is outerloop index, 0000 is processor index)
write_oa_rad_ascii Logical. TRUE to write out (observation-background, observation- analysis, etc.) diagnostics information in plain-text files with the prefix 'oma,' followed by the instrument name and the processor id. For exam- ple, 01_oma_noaa-18-mhs.0001
Each processor writes out the information for one instrument in one file in the WRFDA working directory.
Steps (3) and (4) can be done by running a single ksh script (also in the WRFDA Tools package: $TOOLS_DIR/var/scripts/da_rad_diags.ksh) with proper set- tings. In addition to the settings of directories and what instruments to plot, there are some useful plotting options, explained below.
WRFDA has the ability to assimilate Doppler radar data, either for 3DVAR or 4DVARassimilation. Both Doppler velocity and reflectivity can be assimilated, and there are sev-eral different reflectivity operator options available.
Radar observations are read by WRFDA in a text-based format. This format is describedin the radar tutorial presentation available on the WRFDA website(http://www2.mmm.ucar.edu/wrf/users/wrfda/Tutorials/2015_Aug/docs/WRFDA_Radar.pdf). Because
radar data comes in a variety of different formats, it is the user's responsibility to converttheir data into this format. For 3DVAR, these observations should be placed in a filenamed ob.radar. For 4DVAR, they should be placed in files named ob01.radar,ob02.radar, etc., with one observation file per time slot, as described in the earlier4DVAR section.
Once your observations are prepared, you can run WRFDA the same as you would nor-mally (see the previous sections on how to run either 3DVAR or 4DVAR). For guidance,there is an example 3DVAR case available for download athttp://www2.mmm.ucar.edu/wrf/users/wrfda/download/V38/wrfda_radar_testdata.tar.gz.
Edit namelist.input and pay special attention to the radar options under &wrfvar4:&wrfvar4use_radarobs = .true. ; radar obs will be read by WRFDAuse_radar_rv = .true. ; Assimilate radar velocity observationsuse_radar_rf = .true. ; Assimilate radar reflectivity using original reflectivity operator (totalmixing ratio)use_radar_rqv = .false. ; Assimilate radar reflectivity using estimated humidity from radarreflectivityuse_radar_rhv = .false. ; Assimilate radar reflectivity using rainwater and ice mixing ratiosuse_3dvar_phy = .true. ; Partition hydrometeors via the moist explicit scheme (warm rainprocess)/…&wrfvar7cloud_cv_options = 3 ; Use hydrometeor control variables to get moisture increments for use_radar_rhv = true
Starting with Version 3.7, WRFDA has an improved radar data assimilation capability:there are now two different options for assimilating radar reflectivity data. The first(use_radar_rf) directly assimilates the observed reflectivity using a reflectivity operatorto convert the model rainwater mixing ratio into reflectivity and the total mixing ratio asthe control variable, as described in Xiao and Sun, 2007(http://journals.ametsoc.org/doi/full/10.1175/MWR3471.1); this is the only option availa-ble in previous versions of WRFDA. For this option, the hydrometeor partition using awarm rain scheme described in the above reference can be turned on (use_3dvar_phy =.true.). The second (use_radar_rhv) is a scheme described in Wang et al, 2013(http://journals.ametsoc.org/doi/full/10.1175/JAMC-D-12-0120.1), which assimilates rainwater mix-ing ratio that is estimated from radar reflectivity, described as an "indirect method" in thepaper. This second option also includes an option (use_radar_rqv) that allows the as-similation of in-cloud humidity estimated from reflectivity using a method described inWang et al, 2013. It also includes the assimilation of snow and graupel converted fromreflectivity using formulas as described in Gao and Stensrud, 2012(http://journals.ametsoc.org/doi/abs/10.1175/JAS-D-11-0162.1).
To take full advantage of the use_radar_rhv option for 4DVAR radar assimilation, youmust compile WRFDA in a specific way. Prior to running the configure script, set theenvironment variable "CLOUD_CV=1". This will enable the extra moisture control varia-bles for this option. Default values are used for the background error statistics for the ex-tra moisture control variables, so no extra BE input is necessary. We do not recommendcompiling with this option for other methods of data assimilation at this time, and itwill not work with background error option cv_options=3.
WRFDA 4D-Var can assimilate NCEP Stage IV radar and gauge precipitation data.NCEP Stage IV archived data are available on the NCAR CODIAC web page at:http://data.eol.ucar.edu/codiac/dss/id=21.093 (for more information, please see the NCEP StageIV Q&A Web page at http://www.emc.ncep.noaa.gov/mmb/ylin/pcpanl/QandA/). The original pre-cipitation data are at 4-km resolution on a polar-stereographic grid. Hourly, 6-hourly and24-hourly analyses are available. The following image shows the accumulated 6-h precip-itation for the tutorial case.
It should be mentioned that the NCEP Stage IV archived data is in GRIB1 format and it cannot beingested into the WRFDA directly. A tool "precip_converter" is provided to reformat GRIB1 ob-servations into the WRFDA-readable ASCII format. It can be downloaded from the WRFDA us-ers page at http://www2.mmm.ucar.edu/wrf/users/wrfda/download/precip_converter.tar.gz. The NCEP GRIBlibraries, w3 and g2 are required to compile the precip_converter utility. These libraries are avail-able for download from NCEP at http://www.nco.ncep.noaa.gov/pmb/codes/GRIB2/. The output file tothe precip_converter utility is named in the format ob.rain.yyyymmddhh.xxh; The 'yyyymmddhh'in the file name is the ending hour of the accumulation period, and 'xx' (=01,06 or 24) is the ac-cumulating time period.
For users wishing to use their own observations instead of NCEP Stage IV, it is the user's respon-sibility to write a Fortran main program and call subroutine writerainobs (in write_rainobs.f90) togenerate their own precipitation data. For more information please refer to the README file inthe precip_converter directory.
WRFDA 4D-Var is able to assimilate hourly, 3-hourly and 6-hourly precipitation data.According to experiments and related scientific papers, 6-hour precipitation accumula-tions are the ideal observations to be assimilated, as this leads to better results than direct-ly assimilating hourly data.
The tutorial example is for assimilating 6-hour accumulated precipitation. In your work-ing directory, link all the necessary files as follows,
Edit namelist.input (you can start with the same namelist as for the 4dvar tutorial case)and pay special attention to &wrfvar1 and &wrfvar4 for precipitation-related options.
&wrfvar1 var4d=true, var4d_lbc=true, var4d_bin=3600, var4d_bin_rain=21600, …… / …… &wrfvar4 use_rainobs=true, thin_rainobs=true, thin_mesh_conv=28*20., /
var4d_bin_rain Precipitation observation sub-window length for 4D-Var. It does not need to be consistent with var4d_bin.
thin_rainobs Logical, TRUE will perform thinning on precipitation data.
thin_mesh_conv Specify thinning mesh size (in km)
In the example above, 6-hour accumulated precipitation data is assimilated in 6-hour timewindow. In the namelist, values should be set at var4d_bin=3600 andvar4d_bin_rain=21600, and there is one observation file (i.e., i=1) in the time window,Thus the value of x is 7. The file ob.rain.2008020518.06h should be renamed asob07.rain.
Let us take another example for how to rename observation files for 3-hourly precipita-tion data in 6-hour time window. The sample namelist is as follows,
&wrfvar1 var4d=true, var4d_lbc=true, var4d_bin=3600, var4d_bin_rain=10800, …… /
When using WRFDA output to run a WRF forecast, it is essential that you update theWRF lateral boundary conditions (contained in the file wrfbdy_01, created by real.exe)to match your new analysis. Domain-1 (wrfbdy_d01) must be updated to be consistentwith the new WRFDA initial condition (analysis). This is absolutely essential. For nesteddomains, domain-2, domain-3, etc., the lateral boundary conditions are provided by theirparent domains, so no lateral boundary update is needed for these domains. The updateprocedure is performed by the WRFDA utility called da_update_bc.exe, and after com-pilation can be found in $WRFDA_DIR/var/build.
> cd $WRFDA_DIR/var/test/update_bc > cp –p $DAT_DIR/rc/2008020512/wrfbdy_d01 . (IMPORTANT: make a copy of wrfbdy_d01, as the wrf_bdy_file will be over- written by da_update_bc.exe)
> vi parame.in&control_param da_file = '../tutorial/wrfvar_output' wrf_bdy_file = './wrfbdy_d01' domain_id = 1 debug = .true. update_lateral_bdy = .true. update_low_bdy = .false. update_lsm = .false. iswater = 16 var4d_lbc = .false./
At this stage, you should have the files wrfvar_output and wrfbdy_d01 in yourWRFDA working directory. They are the WRFDA updated initial and boundary condi-tion files for any subsequent WRF model runs. To use, link a copy of wrfvar_outputand wrfbdy_d01 to wrfinput_d01 and wrfbdy_d01, respectively, in your WRF workingdirectory.
You should also see two additional output files: fort.11 and fort.12. These contain infor-mation about the changes made to wrfbdy_01.
In cycling mode (warm-start), the lower boundary in the first guess file also needs to beupdated based on the information from the wrfinput file, generated by WPS/real.exe atanalysis time. If in cycling mode (especially if you are doing radiance data assimilationand there are SEA ICE or SNOW in your domain), it is recommended that before you runWRFDA, you run da_update_bc.exe with the following namelist options: da_file = './fg' wrf_input = './wrfinput_d01' update_lateral_bdy = .false. update_low_bdy = .true. iswater = 16 Note: "iswater" (water point index) is 16 for USGS LANDUSE and 17 for MODIS LANDUSE.
If you activate the var4d_lbc option in a WRF 4D-Var run, in addition to the above-mentioned files you will also need the ana02 file from the WRFDA working directory. Inparame.in, set var4d_lbc to TRUE and use "da_file_02" to point to the location ofthe ana02 file.da_file_02 = './ana02'var4d_lbc = .true.
To run WRFDA with the generic CV3 option, simply link the provided be.dat file in thevar/run directory:
To run WRFDA with any other option, you will have to run GEN_BE first. GEN_BEtakes a series of forecasts initialized at different times, and compares the forecasts thatare valid at the same time (e.g., compare a 24-hour forecast initialized at 00Z with a 12-hour forecast initialized at 12Z) to get an estimate of the background error statistics.
You will use the wrapper script gen_be_wrapper.ksh to run GEN_BE. For instructionson how to set up your experiment to run GEN_BE, reference the test case as described inthe section "Domain-specific background error options: Running GEN_BE" below.
Users have four choices to define the background error covariance (BE). We call themCV3, CV5, CV6, and CV7. Each of these has different properties, which are outlined inthe table below:
With CV3, the control variables are in physical space while with CV5, CV6, and CV7,the control variables are in eigenvector space. The major difference between these twokinds of BE is the vertical covariance; CV3 uses the vertical recursive filter to model thevertical covariance but the others use an empirical orthogonal function (EOF) to representthe vertical covariance. The recursive filters to model the horizontal covariance are alsodifferent with these BEs. We have not conducted the systematic comparison of the anal-yses based on these BEs. However, CV3 (a BE file provided with our WRFDA system) isa global BE and can be used for any regional domain, while CV5, CV6, and CV7 BE'sare domain-dependent, and so should be generated based on forecast or ensemble datafrom the same domain.
As summarized in the above table, CV5, CV6, and CV7 differ in the control variablesthey use. CV5 utilizes streamfunction (ψ), unbalanced velocity potential (χu), unbalancedtemperature (Tu), pseudo relative humidity (RHs), and unbalanced surface pressure (Ps,u).The pseudo relative humidity is defined as Q/Qb,s, where Qb,s is the saturated specific hu-midity from the background field. For CV6 the moisture control variable is the unbal-anced portion of the pseudo relative humidity (RHs,u). Additionally, CV6 introduces sixadditional correlation coefficients in the definition of the balanced part of analysis controlvariables. See the section GEN_BE for CV6 for more details on this option. Finally, CV7uses a different set of control variables: u, v, temperature, pseudo relative humidity(RHs), and surface pressure (Ps).
CV3 is the NCEP background error covariance. It is estimated in grid space by what hasbecome known as the NMC method (Parrish and Derber 1992) . The statistics are esti-mated with the differences of 24 and 48-hour GFS forecasts with T170 resolution, validat the same time for 357 cases, distributed over a period of one year. Both the amplitudesand the scales of the background error have to be tuned to represent the forecast error inthe estimated fields. The statistics that project multivariate relations among variables arealso derived from the NMC method.
The variance of each variable, and the variance of its second derivative, are used to esti-mate its horizontal scales. For example, the horizontal scales of the stream function canbe estimated from the variance of the vorticity and stream function.
The vertical scales are estimated with the vertical correlation of each variable. A table isbuilt to cover the range of vertical scales for the variables. The table is then used to findthe scales in vertical grid units. The filter profile and the vertical correlation are fitted lo-
cally. The scale of the best fit from the table is assigned as the scale of the variable at thatvertical level for each latitude. Note that the vertical scales are locally defined so that thenegative correlation further away, in the vertical direction, is not included.
Theoretically, CV3 BE is a generic background error statistics file which can be used forany case. It is quite straightforward to use CV3 in your own case. To use the CV3 BE filein your case, set cv_options=3 in &wrfvar7 in namelist.input in your working direc-tory, and use the be.dat is located in WRFDA/var/run/be.dat.cv3.
The scaling factors for CV3 are stored as an array of values for each individual controlvariable:
These variables are all 3-element vectors. The first element is the variance scaling factor.The second is the horizontal length scale factor. The third is the vertical length scale fac-tor. So setting the default values in your namelist would look like this:
&wrfvar7 cv_options = 3, as1 = 0.25, 1.00, 1.50, as2 = 0.25, 1.00, 1.50, as3 = 0.25, 1.00, 1.50, as4 = 0.25, 1.00, 1.50, as5 = 0.25, 1.00, 1.50, /
The first column is the variance, the second is the horizontal length scale factor, and thethird is the vertical length scale factor.
For multiple outer loops, the next 3 elements of each vector must be filled in. So for 2outer loops (max_ext_its=2), to use the default values, the namelist should look like this:
&wrfvar7 cv_options = 3, as1 = 0.25, 1.00, 1.50, 0.25, 1.00, 1.50, as2 = 0.25, 1.00, 1.50, 0.25, 1.00, 1.50, as3 = 0.25, 1.00, 1.50, 0.25, 1.00, 1.50, as4 = 0.25, 1.00, 1.50, 0.25, 1.00, 1.50, as5 = 0.25, 1.00, 1.50, 0.25, 1.00, 1.50, /
Again, the first column is the variance, the second is the horizontal length scale factor,and the third is the vertical length scale factor for the first outer loop. The fourth columnis the variance, the fifth is the horizontal length scale factor, and the sixth is the verticallength scale factor for the second outer loop.
Continue in this manner for more outer loops. The values listed above are the default val-ues, but can be adjusted for each individual experiment.
To use CV5, CV6 or CV7 background error covariance, it is necessary to generate yourdomain-specific background error statistics with the gen_be utility. The default CV3background error statistics file, supplied with the WRFDA source code, can NOT be usedwith these control variable options.
The main source code for the various gen_be stages can be found in WRFDA/var/gen_be.The executables of gen_be should have been created when you compiled the WRFDAcode (as described earlier). The scripts to run these codes are inWRFDA/var/scripts/gen_be. The user can run gen_be using the wrapper scriptWRFDA/var/scripts/gen_be/gen_be_wrapper.ksh.
The input data for gen_be are WRF forecasts, which are used to generate model perturba-tions, used as a proxy for estimates of forecast error. For the NMC-method, the modelperturbations are differences between forecasts (e.g. T+24 minus T+12 is typical for re-gional applications, T+48 minus T+24 for global) valid at the same time. Climatologicalestimates of background error may then be obtained by averaging these forecast differ-ences over a period of time (e.g. one month). Given input from an ensemble predictionsystem (EPS), the inputs are the ensemble forecasts, and the model perturbations createdare the transformed ensemble perturbations. The gen_be code has been designed to workwith either forecast difference or ensemble-based perturbations. The former is illustratedin this tutorial example.
It is important to include forecast differences valid at different parts of the day (for ex-ample, forecasts valid at 00Z and 12Z through the forecast period) to remove contribu-tions from the diurnal cycle (i.e. do not run gen_be using model perturbations valid for asingle time each day).
The inputs to gen_be are netCDF WRF forecast output ("wrfout") files at specified fore-cast ranges. To avoid unnecessary large single data files, it is assumed that all forecastranges are output to separate files. For example, if we wish to calculate BE statistics us-ing the NMC-method with (T+24)-(T+12) forecast differences (default for regional) thenby setting the WRF namelist.input options history_interval=720, andframes_per_outfile=1 we get the necessary output datasets. Then the forecast outputfiles should be arranged as follows: directory name is the forecast initial time, time infoin the file name is the forecast valid time. 2008020512/wrfout_d01_2008-02-
Example dataset for a test case (90 x 60 x 41 gridpoints) can be downloaded fromhttp://www2.mmm.ucar.edu/wrf/users/wrfda/download/testdata.html. Untar thegen_be_forecasts_20080205.tar.gz file. You will have:
>ls $FC_DIR
In the above example, only 1 day (12Z 05 Feb to 12Z 06 Feb. 2008) of forecasts, every12 hours is supplied to gen_be_wrapper to estimate forecast error covariance. It is onlyfor demonstration. The minimum number of forecasts required depends on the applica-tion, number of grid points, etc. Month-long (or longer) datasets are typical for the NMC-method. Generally, at least a 1-month dataset should be used.
Note: The START_DATE and END_DATE are perturbation valid dates. As shown in theforecast list above, when you have 24-hour and 12-hour forecasts initialized at2008020512, through 2008020612, the first and final forecast difference valid dates are2008020612 and 2008020700, respectively.
> gen_be_wrapper.ksh
Once the gen_be_wrapper.ksh run is completed, the be.dat can be found under the$RUN_DIR directory.
CV6 background error statistics for WRFDA are generated by executing a top-levelscript, gen_be/wrapper_gen_mbe.ksh, residing under SCRIPTS_DIR via a suitable wrap-per script. The rest of the procedure remains the same as with normal running of thegen_be utility. A successful run will create a be.dat file in the RUN_DIR directory.
After successfully generating the CV6 background error statistics file be.dat, the proce-dure for running WRFDA is straight-forward: Include cv_options=6 in the namel-ist.input file under the &wrfvar7 list of namelist options.
Below is a list of nine tuning parameters available in WRFDA; these can be specified un-der &wrfvar7 in the namelist. Default values for these variables are set as "1.0". Settingcorresponding values > 1.0 (< 1.0) will increase (decrease) the corresponding contribu-tions:
With the single observation test, you may get some ideas of how the background and ob-servation error statistics work in the model variable space. A single observation test isdone in WRFDA by setting num_pseudo=1, along with other pre-specified values in rec-ord &wrfvar15 and &wrfvar19 of namelist.input.
With the settings shown below, WRFDA generates a single observation with a pre-specified innovation (Observation − First Guess) value at the desired location; e.g. at (interms of grid coordinate) 23x23, level 14 for "U" observation with error characteristics 1m/s, and innovation size = 1.0 m/s.
&wrfvar15 num_pseudo = 1, pseudo_x = 23.0, pseudo_y = 23.0, pseudo_z = 14.0, pseudo_err = 1.0, pseudo_val = 1.0, / &wrfvar19 pseudo_var = "u", (Note: pseudo_var can be u, v, t, p, q. If pseudo_var is q, then the reasonable values of pseudo_err and pseudo_val are 0.001) /
Note: You may wish to repeat this exercise for other observations, like temperature "t",pressure "p", specific humidity "q", and so on.
Run the single observation test with the following additional parameters in record&wrfvar7 of namelist.input.
&wrfvar7 len_scaling1 = 0.5, # reduce psi length scale by 50% len_scaling2 = 0.5, # reduce chi_u length scale by 50% len_scaling3 = 0.5, # reduce T length scale by 50% len_scaling4 = 0.5, # reduce q length scale by 50% len_scaling5 = 0.5, # reduce Ps length scale by 50% /
Note: You may wish to try the response of an individual variable by setting one parame-ter at a time. Note the spread of analysis increment.
&wrfvar7 var_scaling1 = 0.25, # reduce psi variance by 75% var_scaling2 = 0.25, # reduce chi_u variance by 75% var_scaling3 = 0.25, # reduce T variance by 75% var_scaling4 = 0.25, # reduce q variance by 75% var_scaling5 = 0.25, # reduce Ps variance by 75% /
Note: You may wish to try the response of individual variable by setting one parameter ata time. Note the magnitude of analysis increments.
&wrfvar6 eps = 0.0001, /
&wrfvar6 max_ext_its = 2, /
With this setting, the "outer loop" for the minimization procedure will be activated. Youmay wish to compare various diagnostics with an earlier run.
Note that when running multiple outer loops with the CV3 background error option, youmust specify the scaling factors which are called as1, as2, as3, as4, and as5. More detailscan be found in the section "Modifying CV3 length scales and variance".
The types of observations that WRFDA gets to use actually depend on what is includedin the observation file and the WRFDA namelist settings. For example, if you haveSYNOP data in the observation file, you can suppress its usage in WRFDA by settinguse_synopobs=false in record &wrfvar4 of namelist.input. It is OK if there are noSYNOP data in the observation file and use_synopobs=true.
Turning on and off certain types of observations is widely used for assessing the impactof observations on data assimilations.
&wrfvar2wind_sd true: all wind values which are reported as speed/direction will be assimilated as such false: (default behavior) all wind obs are converted to u/v prior to assimilationwind_stats_sd Assimilate wind in u/v format, but output speed/direction statistics
The following settings only matter if check_max_iv=true (if innovation is greater thanobservation error times the error factor listed below, the observation will be rejected):
&wrfvar2qc_rej_both true: if either u or v (spd or dir) do not pass quality control, both obs are rejected false: (default behavior) qc on wind obs is handled individually&wrfvar5max_omb_spd Max absolute value of innovation for wind speed obs in m/s; greater than this and the innovation will be set to zero (default: 100.0)max_omb_dir Max absolute value of innovation for wind direction obs in degrees; greater than this and the innovation will be set to zero (default: 1000.0)max_error_spd Speed error factor (default: 5.0)max_error_dir Direction error factor (default: 5.0)
The assimilation of wind speed/direction can also be controlled by observation type, us-ing the following variables (note: setting wind_sd = .true. as above will override the-se individual settings):
&wrfvar2wind_sd_airep Aircraft reportswind_sd_buoy Buoy reportswind_sd_geoamv Geostationary satellite atmospheric motion vectorswind_sd_metar METAR reportswind_sd_mtgirs Meteosat Third Generationwind_sd_pilot Pilot reportswind_sd_polaramv Polar satellite atmospheric motion vectorswind_sd_profiler Wind profiler reportswind_sd_qscat QuikScat reportswind_sd_ships Ship reportswind_sd_sound Sounding reportswind_sd_synop Synoptic reportswind_sd_tamdar TAMDAR reports true: wind values which are reported as speed/direction will be assimilated as such false: (default behavior) all wind obs are converted to u/v prior to assimilation
Further details about this method can be found in the following publications:
Gao, Feng, Xiang-Yu Huang, Neil A. Jacobs, and Hongli Wang, 2015: Assimila- tion of wind speed and direction observations: results from real observation ex- periments. Tellus A, 67, 27132, doi:10.3402/tellusa.v67.27132.
For Version 3.8, a new "weak penalty constraint" (WPEC) option has been added toWRFDA which aims to enforce quasi-gradient balance on a WRFDA analysis. It was de-signed with the specific aim of improving assimilation of radar data within tropical cy-clones, but may be useful for other weather phenomena of similar scales. It can be usedwith 3DVAR or hybrid 3DVAR (4DVAR is not compatible with this new capability).
Further details about this method can be found in the following publication:
Li, X., J. Ming, M. Xue, Y. Wang, and K. Zhao, 2015: Implementation of a dy- namic equation constraint based on the steady state momentum equations within the WRF hybrid ensemble-3DVar data assimilation system and test with radar T- TREC wind assimilation for tropical Cyclone Chanthu (2010). J. Geophys. Res. Atmos., 120, 4017–4039, doi: 10.1002/2014JD022706.
&wrfvar12use_wpec true: enables the constraint term false: (default behavior) disables the constraint termwpec_factor The constraint's weighting factor (1/Γ) as described in the paperbalance_type 1 = geostrophic term 2 = cyclostrophic term 3 = geostrophic + cyclostrophic terms (default; recommended)
WRFDA Diagnostics
WRFDA produces a number of diagnostic files that contain useful information on howthe data assimilation has performed. This section will introduce you to some of thesefiles, and what to look for.
After running WRFDA, it is important to check a number of output files to see if the as-similation appears sensible. The WRFDA package, which includes several useful scripts,may be downloaded from http://www2.mmm.ucar.edu/wrf/users/wrfda/download/tools.html
cost_fn and grad_fn: These files hold (in ASCII format) WRFDA cost and gradientfunction values, respectively, for the first and last iterations. If you run withPRINT_DETAIL_GRAD=true, however, these values will be listed for each iteration; this
can be helpful for visualization purposes. The NCL script in the WRFDA TOOLS pack-age located at var/graphics/ncl/plot_cost_grad_fn.ncl may be used to plot thecontent of cost_fn and grad_fn, if these files are generated withPRINT_DETAIL_GRAD=true.
Note: Make sure that you remove the first two lines (header) in cost_fn and grad_fnbefore you plot. You also need to specify the directory name for these two files.
namelist.input: This is the WRFDA input namelist file, which contains all the user-defined non-default options. Any namelist-defined options that do not appear in this fileshould have their names checked against the values in$WRFDA_DIR/Registry/registry.var.
namelist.output.da: A list of all the namelist options used. If an option was not speci-fied in namelist.input, the default listed in the registry value will be used.
rsl*: Files containing information for standard WRFDA output from individual proces-sors when multiple processors are used. It contains a host of information on a number ofobservations, minimization, timings, etc. Additional diagnostics may be printed in thesefiles by including various "print" WRFDA namelist options. To learn more about theseadditional "print" options, search for the "print_" string in$WRFDA_DIR/Registry/registry.var.
statistics: Text file containing OMB (OI) and OMA (OA) statistics (minimum, maxi-mum, mean and standard deviation) for each observation type and variable. This infor-mation is very useful in diagnosing how WRFDA has used different components of the
observing system. Also contained are the analysis minus background (A-B) statistics, i.e.statistics of the analysis increments for each model variable at each model level. This in-formation is very useful in checking the range of analysis increment values found in theanalysis, and where they are in the WRF-model grid space.
The WRFDA analysis file is wrfvar_output. It is in WRF (netCDF) format. It will be-come the input file wrfinput_d01 of any subsequent WRF run after lateral boundaryand/or lower boundary conditions are updated by another WRFDA utility (See the sectionUpdating WRF boundary conditions).
As an example, if you are aiming to display the U-component of the analysis at level 18,use the script WRF-Var_plot.ncl, and make sure the following pieces of codes are un-commented:
var = "U" fg = first_guess->U an = analysis->U plot_data = an
You may change the variable name, level, etc. in this script to display the variable of yourchoice at the desired eta level.
Take time to look through the text output files to ensure you understand how WRFDAworks. For example:
How closely has WRFDA fit individual observation types? Look at the statis- tics file to compare the O-B and O-A statistics.
How big are the analysis increments? Again, look in the statistics file to see minimum/maximum values of A-B for each variable at various levels. It will give you a feel for the impact of the input observation data you assimilated via WRFDA by modifying the input analysis first guess.
How long did WRFDA take to converge? Does it really converge? You will get the answers of all these questions by looking into the rsl.* -files, as it indicates the number of iterations taken by WRFDA to converge. If this is the same as the maximum number of iterations specified in the namelist (NTMAX), or its default value (=200) set in $WRFDA_DIR/Registry/registry.var, then it means that the analysis solution did not converge. If this is the case, you may need to increase the value of "NTMAX" and rerun your case to ensure that the convergence is achieved. On the other hand, a normal WRFDA run should usually converge within 100 iterations. If it still doesn't converge in 200 iterations, that means there may be a problem in the observations or first guess.
A good way to visualize the impact of assimilation of observations is to plot the analysisincrements (i.e. analysis minus the first guess difference). Many different graphics pack-ages (e.g. RIP4, NCL, GRADS etc) can do this.
You need to modify this script to fix the full path for first_guess and analysis files.You may also use it to modify the display level by setting kl and the name of the variableto display by setting var. Further details are given in this script.
If you are aiming to display the increment of potential temperature at level 18, after mod-ifying $WRFDA_DIR/var/graphics/ncl/WRF-Var_plot.ncl, make sure the followingpieces of code are uncommented:
var = "T" fg = first_guess->T ;Theta- 300 an = analysis->T ;Theta- 300 plot_data = an - fg
Note: Larger analysis increments indicate a larger data impact in the corresponding re-gion of the domain.
In addition to the variational methods previously mentioned, the WRFDA system sup-ports both ensemble and hybrid ensemble/variational assimilation methods. To utilizethese methods, having an ensemble of forecasts is necessary. WRFDA has a built-inmethod for generating ensemble initial conditions known as RANDOMCV. RAN-DOMCV works by adding random noise to the analysis in control variable space.
RANDOMCV is a capability of the main WRFDA executable, so you will run it by set-ting the following variables in namelist.input and then running da_wrfvar.exe as youwould with any data assimilation run:
&wrfvar5put_rand_seed true: enter your own seed numbers to generate random background perturbations. The advantage of this setting is that the same seed numbers will always produce the same perturbation false: (default behavior) perturbations will be generated "randomly" and give new perturbations each time&wrfvar11seed_array1 First integer for seeding the random function (default: 1)seed_array2 Second integer for seeding the random function (default: 1) It is not necessary to change both seeds to get different perturbations&wrfvar17analysis_type Set this to 'RANDOMCV' to use the RANDOMCV capability
When setting your own random seeds, a common good practice is to set the first seed asthe experiment date/time in integer form, and the second seed as the ensemble member
Because the perturbations are made in control variable space, the general pattern of per-turbations will depend on your background error. You should be able to use any back-ground error option with RANDOMCV (CV3, CV5, CV6, or CV7). Additionally, thismeans you can control their magnitude and lengthscales by modifying the backgrounderror variance and length scaling variables respectively:
For CV3, see the section "Modifying CV3 length scales and variance".
The WRFDA system also includes a hybrid data assimilation technique, which is basedon the existing 3D-Var. The difference between hybrid and 3D-Var schemes is that 3D-Var relies solely on a static covariance model to specify the background errors, while thehybrid system uses a combination of 3D-Var static error covariances and ensemble-estimated error covariances to incorporate a flow-dependent estimate of the backgrounderror statistics. The following section will give a brief introduction of some aspects ofusing the hybrid system. Please refer to these papers for a detailed description of themethodology used in the WRFDA hybrid system:
Xuguang Wang, Dale M. Barker, Chris Snyder, and Thomas M. Hamill, 2008: A hybrid ETKF–3DVAR data assimilation scheme for the WRF model. Part I: Ob- serving system simulation experiment. Mon. Wea. Rev., 136, 5116–5131.
Xuguang Wang, Dale M. Barker, Chris Snyder, and Thomas M. Hamill, 2008: A Hybrid ETKF–3DVAR Data Assimilation Scheme for the WRF Model. Part II: Real Observation Experiments. Mon. Wea. Rev., 136, 5132–5147.
b. Source code
Four executables are used in the hybrid system. If you have successfully compiled theWRFDA system, the following executables will exist in the WRFDA/var/build directory:
The procedure is the same as running 3D-Var/4D-Var, with the exception of some extrainput files and namelist settings. The basic input files for WRFDA are LANDUSE.TBL,ob.ascii or ob.bufr (depending on which observation format you use), and be.dat(static background errors). Additional input files required by the hybrid are a single en-semble mean file (used as the fg for the hybrid application) and a set of ensemble pertur-bation files (used to represent flow-dependent background errors).
A set of initial ensemble members must be prepared before the hybrid application can bestarted. The ensemble can be obtained from other ensemble model outputs, or you cangenerate them yourself. This can be done, for example, adding random noise to the initialconditions at a previous time and integrating each member to the desired time. A tutorialcase with a test ensemble can be found athttp://www2.mmm.ucar.edu/wrf/users/wrfda/download/V38/wrfda_hybrid_etkf_testdata.tar.gz. In thisexample, the ensemble forecasts were initialized at 2015102612 and valid 2015102712.A hybrid analysis at 2015102712 will be performed using the ensemble valid2015102712 as input. Once you have the initial ensemble, the ensemble mean and pertur-bations can be calculated following the steps below:
1) Set an environment variable for your working directory and your data directory
a) From your working directory, copy or link the ensemble forecasts to your work- ing directory. The ensemble members are identified by three-digit numbers fol- lowing the valid time.
b) Provide two template files (ensemble mean and variance files) in your working directory. These files will be overwritten with the ensemble mean and variance as discussed below.
> cp $DAT_DIR/Hybrid/fc/2015102612/wrfout_d01_2015-10- 27_12:00:00.e001 ./wrfout_d01_2015-10-27_12:00:00.mean > cp $DAT_DIR/Hybrid/fc/2015102612/wrfout_d01_2015-10- 27_12:00:00.e001 ./wrfout_d01_2015-10-27_12:00:00.vari
&gen_be_ensmean_nl directory = '.' filename = 'wrfout_d01_2015-10-27_12:00:00' num_members = 10 nv = 7 cv = 'U', 'V', 'W', 'PH', 'T', 'MU', 'QVAPOR' / where directory is the folder containing the ensemble members and template files, filename is the name of the files before their suffixes (e.g., .mean, .vari, etc), num_members is the number of ensemble members you are using, nv is the number of variables, and cv is the name of variables used in the hybrid system. Be sure nv and cv are consistent!
c) Check the output files. A list of binary files should now exist. Among them,
4) Back in the working directory, create the input file for vertical localization. This pro- gram requires one command-line argument: the number of vertical levels of the mod- el configuration (same value as e_vert in the namelist; for the tutorial example, this should be 42). > cd $WORK_DIR > ln –sf $WRFDA_DIR/var/build/gen_be_vertloc.exe . > ./gen_be_vertloc.exe 42
a) In your hybrid working directory, link all the necessary files and directories as follows:
&wrfvar7 je_factor = 2.0 / &wrfvar16 ensdim_alpha = 10 alphacv_method = 2 alpha_corr_type=3 alpha_corr_scale = 500.0 alpha_std_dev=1.000 alpha_vertloc = .true. /
Check the output files; the output file lists are the same as when you run WRF3D-Var.
ensemble covariance weighting factor. This factor controls the weighting compo- nent of ensemble and static covariances. The corresponding jb_factor = je_factor/(je_factor - 1).ensdim_alpha the number of ensemble members. Hybrid mode is activated when ensdim_alpha is larger than zeroalphacv_method 1=perturbations in control variable space ("psi","chi_u","t_u","rh","ps_u"); 2=perturbations in model space ("u","v","t","q","ps"). Option 2 is extensively tested and recommended to use.alpha_corr_type correlation function. 1=Exponential; 2=SOAR; 3=Gaussian.alpha_corr_scale hybrid covariance localization scale in km unit. Default value is 200.alpha_std_dev alpha standard deviation. Default value is 1.0alpha_vertloc for vertical localization. .true.=use vertical localization; .false.=no vertical locali- zation
The WRFDA system also includes a ETKF assimilation technique. The ETKF systemupdates the ensemble perturbations. Please refer to Bishop et al. (2001) and Wang et al.(2003) for a detailed description of the methodology. The following section will give abrief introduction of some aspects of using the ETKF system.
a. Source Code
Three executables are used in the ETKF system. If you have successfully compiled theWRFDA system, you will see the following:
The first procedure is to update the ensemble perturbations. A set of initial ensemblemembers must be prepared before the ETKF application can be started. The ensemble canbe obtained from a previous ensemble forecast. A tutorial case with a test ensemble canbe found athttp://www2.mmm.ucar.edu/wrf/users/wrfda/download/V38/wrfda_hybrid_etkf_testdata.tar.gz. In thisexample, the ensemble forecasts were initialized at 2015102612 and valid 2015102712.ETKF will be performed using the ensemble valid 2015102712 as input. Once you havethe initial ensemble, the ensemble perturbations can be updated by following the stepsbelow:
&wrfvar17 analysis_type = 'QC-OBS', /
Check the output files; you should see a 'filtered_obs_01' file which contains the filteredobservations.
a) In your ETKF working directory, make a subdirectory to prepare the omb files for
each ensemble member and link all the necessary files and directories as follows:
> cd $WORK_DIR_ETKF > mkdir -p omb/working.e001 > cd omb/working.e001 > ln -fs $DAT_DIR/Hybrid/fc/2015102612/wrfout_d01_2015-10-27_12:00:00.e001 ./fg (first guess is the ensemble member) > ln -fs $WRFDA_DIR/run/LANDUSE.TBL . > ln -fs $WORK_DIR_ETKF/obs_filter/filtered_obs_01 ./ob.ascii > ln -fs $DAT_DIR/Hybrid/be/be.dat ./be.dat > ln -fs $WRFDA_DIR/var/build/da_wrfvar.exe . > cp $DAT_DIR/ETKF/namelist.input .
&wrfvar17 analysis_type = 'VERIFY', /
Check the output files. The output files are the same as when you run WRF 3D-Var (ex-cept wrfvar_output will NOT be created), and the 'ob.etkf.0*' files are omb files.
d) Combine the ob.etkf.0* files and add the observation number in the head ofob.etkf.e0*
4) Run ETKF
a) Copy or link the ensemble mean and forecasts and ob.etkf.e0* files to your workingdirectory and make a parameter directory to save the parameter files.
> cd $WORK_DIR_ETKF > setenv PAR_DIR_ETKF $WORK_DIR_ETKF/param > mkdir $PAR_DIR_ETKF > ln -sf $DAT_DIR/Hybrid/fc/2015102612/wrfout_d01_2015-10-27_12:00:00.mean ./etkf_input > ln -sf $DAT_DIR/Hybrid/fc/2015102612/wrfout_d01_2015-10-27_12:00:00.e001 ./etkf_input.e001 ... > ln -sf $DAT_DIR/Hybrid/fc/2015102712/wrfout_d01_2015-10-27_12:00:00.e010 ./etkf_input.e010
b) Provide template files. These files will be overwritten with the ensembleperturbations.
> cp $DAT_DIR/Hybrid/fc/2015102612/wrfout_d01_2015-10-27_12:00:00.e001 ./etkf_output.e001 ... > cp $DAT_DIR/Hybrid/fc/2015102612/wrfout_d01_2015-10-27_12:00:00.e010 ./etkf_output.e010
&gen_be_etkf_nl num_members = 10, nv = 7, cv = 'U', 'V', 'W', 'PH', 'T', 'QVAPOR', 'MU', naccumt1 = 20, naccumt2 = 20, nstartaccum1 = 1, nstartaccum2 = 1, nout = 1, tainflatinput = 1, rhoinput = 1, infl_fac_file = '$PAR_DIR_ETKF/inflation_factor.dat', infl_let_file = '$PAR_DIR_ETKF/inflation_letkf.dat', eigen_val_file = '$PAR_DIR_ETKF/eigen_value.dat', inno2_val_file = '$PAR_DIR_ETKF/innovation_value.dat', proj2_val_file = '$PAR_DIR_ETKF/projection_value.dat', infl_fac_TRNK = .false., infl_fac_WG03 = .false., infl_fac_WG07 = .true., infl_fac_BOWL = .false., letkf_flg=.false., rand_filt = .false., rnd_seed = 2015102712, rnd_nobs = 5000 etkf_erro_max = 20. etkf_erro_min = .00001 etkf_inno_max = 20. etkf_inno_min = .00001 etkf_erro_flg = .true. etkf_inno_flg = .true. etkf_wrfda = .false. /
Important note: since environment variables are not parsed when reading namelists, youMUST manually change $PAR_DIR_ETKF to its actual value in the namelist
Check the output files. etkf_output.* files are updated ensemble perturbations.
5) Add updated ensemble perturbations to the ensemble mean to get new ensemblemembers
> cd $WORK_DIR_ETKF
&add_mean_nl num_members = 10 cv = 'U', 'V', 'W', 'PH', 'T', 'QVAPOR', 'MU' nv = 7 path = '$WORK_DIR_ETKF' file_mean = 'etkf_input' file_pert = 'etkf_output.e001' (for each member,etkf_output.e0*...) /
b) Run gen_be_addmean.exe.
Check the output files. etkf_output.e0* files are the new ensemble members.
num_fgat_time 1 1: 3DVar > 1: number of time slots for FGAT and 4DVAR&wrfvar4thin_conv true Turns on observation thinning for ob_format=1 (NCEP PREPBUFR) only. thin_conv can be set to .false., but this is not recommended.thin_conv_ascii false Turns on observation thinning for ob_format=2 (ASCII from OBSPROC) only.thin_mesh_conv 20. km, each observation type can set its thinning mesh (max_instrumenand the index/order follows the definition in ts) WRFDA/var/da/da_control/da_control.f90use_synopobs true use_xxxobs - .true.: assimilate xxx obs if available .false.: do not assimilate xxx obs even availableuse_shipsobs trueuse_metarobs trueuse_soundobs trueuse_pilotobs trueuse_airepobs trueuse_geoamvobs trueuse_polaramvobs trueuse_bogusobs trueuse_buoyobs trueuse_profilerobs trueuse_satemobs trueuse_gpspwobs trueuse_gpsztdobs false Note: unlike most use_*obs variables, the default for use_gpsztdobs is false. This is because PW and
&wrfvar7cv_options 5 3: NCEP Background Error model 5: NCAR Background Error model (default) 6: Use of moisture-multivariate background error statistics (CV6) 7: New NCAR Background Error model (CV7)as1(3) 0.25, 1.0, 1.5 tuning factors for variance, horizontal and vertical scales for control variable 1 = stream function. For cv_options=3 only.as2(3) 0.25, 1.0, 1.5 tuning factors for variance, horizontal and vertical scales for control variable 2 - unbalanced potential velocity. For cv_options=3 only.as3(3) 0.25, 1.0, 1.5 tuning factors for variance, horizontal and vertical scales for control variable 3 - unbalanced tempera- ture. For cv_options=3 only.as4(3) 0.25, 1.0, 1.5 tuning factors for variance, horizontal and vertical scales for control variable 4 - pseudo relative hu- midity. For cv_options=3 only.as5(3) 0.25, 1.0, 1.5 tuning factors for variance, horizontal and vertical scales for control variable 5 - unbalanced surface pressure. For cv_options=3 only.rf_passes 6 number of passes of recursive filter.var_scaling1 1.0 tuning factor of background error covariance for control variable 1 - stream function. For cv_options=5, 6, and 7 only.var_scaling2 1.0 tuning factor of background error covariance for control variable 2 - unbalanced velocity potential. For cv_options=5, 6, and 7 only.var_scaling3 1.0 tuning factor of background error covariance for control variable 3 - unbalanced temperature. For cv_options=5, 6, and 7 only.var_scaling4 1.0 tuning factor of background error covariance for control variable 4 - pseudo relative humidity. For cv_options=5, 6, and 7 only.var_scaling5 1.0 tuning factor of background error covariance for control variable 5 - unbalanced surface pressure. For cv_options=5, 6, and 7 only.len_scaling1 1.0 tuning factor of scale-length for stream function. For cv_options=5, 6, and 7 only.len_scaling2 1.0 tuning factor of scale-length for unbalanced velocity potential. For cv_options=5, 6, and 7 only.len_scaling3 1.0 tuning factor of scale-length for unbalanced temper- ature. For cv_options=5, 6, and 7 only.len_scaling4 1.0 tuning factor of scale-length for pseudo relative hu- midity. For cv_options=5, 6, and 7 only.len_scaling5 1.0 tuning factor of scale-length for unbalanced surface
&wrfvar11cv_options_hum 1 do not change
&wrfvar14the following 4 variables (rtminit_nsensor, rtminit_platform, rtminit_satid, rtminit_sensor) to-gether control what sensors to be assimilated.rtminit_nsensor 1 total number of sensors to be assimilatedrtminit_platform -1 platforms IDs array (used dimension: (max_instruments) rtminit_nsensor); e.g., 1 for NOAA, 9 for EOS, 10 for METOP and 2 for DMSPrtminit_satid -1.0 satellite IDs array (used dimension: (max_instruments) rtminit_nsensor)rtminit_sensor -1.0 sensor IDs array (used dimension: (max_instruments) rtminit_nsensor); e.g., 0 for HIRS, 3 for AMSU-