WRFSI README

NOTE:  THIS README, WHILE MORE DETAILED THAN SOME OF THE OTHER
DOCUMENTATION PROVIDED, IS SOMEWHAT OUT OF DATE.  WE RECOMMEND
REFERRING TO THE "INSTALL" AND "HOW_TO_RUN" FILES TO GET
STARTED WHILE THIS DOCUMENTATION IS BEING UPDATED.  ADDITIONALLY,
ALL OF THE SCRIPTS IN THIS VERSION PROVIDE HELP IF RUN WITH
THE "-h" OPTION.  IN THE CASE OF "install_wrfsi.pl", USE "--help".
BLS 25 OCT 2002


README CONTENTS:
---------------------------------------------------------------------
1.0 INTRO

2.0 INSTALLING WRFSI
2.1 Installation Requirements
2.1.1 NetCDF Library
2.1.2 Perl
2.1.3 Fortran 90
2.1.4 C
2.1.5 make
2.2 WRFSI Directory Overview
2.3 Building WRFSI

3.0 WRF STANDARD INITIALIZATION OVERVIEW
3.1 gridgen_model Program
3.1.1 Automatic Domain Localization
3.2 grib_prep Program
3.2.1 Using Other Data Sources
3.3 hinterp Program
3.4 vinterp Program

4.0 WRFSI NAMELIST ENTRIES



1.0 INTRO
---------------------------------------------------------------------

The "standard initialization" (SI) package performs two major
functions required for running the WRF model:

  1.  Domain definition and setup.  This is the step where the user
specifies the domain (projection parameters, dimensions, location, etc.).
From this definition, the SI program "gridgen_model.exe" will create a
"static" file in netCDF format that contains the grid specification
as well various static fields such as topography, land use, soil types,
monthly greenness fraction, latitudes, longitudes, etc.  This static
file is used by the second major function of the SI.

  2.  Interpolation of data to the WRF grid (horizontal and vertical) for
use as initial and lateral boundary conditions.  The SI programs "hinterp.exe"
and "vinterp.exe" perform this function.  Additionally, the program
"gribprep.exe" processes standard GRIB-format data files into a format
suitable for ingest by hinterp.  Gribprep has been tested with NCEP AVN
and Eta files (pressure level data only).  However, it is also possible
to use other data sets, provided the user puts their data into the correct
file format used by hinterp and follows the file naming convention as
described in section 3.2.1.

In addition to the tar file containing the SI package and this README
file, you must also obtain and extract the tiled surface data sets:

  FILES CONTAINING GLOBAL DATA:

These files are available at:
ftp://aftp.fsl.noaa.gov/divisions/frd-laps/WRFSI/Geog_Data

 greenfrac.tar.tgz
 soiltemp_1deg.tar.tgz
 topo_10m.tar.tgz
 albedo_ncep.tar.tgz




  GLOBAL SETS THAT HAVE BEEN SUBDIVIDED INTO "QUARTERSPHERES" FOR 
  EASIER DOWNLOAD (ONLY GET THE ONES YOU NEED):


These files are available at:
ftp://aftp.fsl.noaa.gov/divisions/frd-laps/WRFSI/Geog_Data

 landuse_30s/landuse_30s.NE.tar.tgz
 landuse_30s/landuse_30s.NW.tar.tgz
 landuse_30s/landuse_30s.SE.tar.tgz
 landuse_30s/landuse_30s.SW.tar.tgz

 soiltype_bot_30s/soiltype_bot_30s.NE.tar.tgz
 soiltype_bot_30s/soiltype_bot_30s.NW.tar.tgz
 soiltype_bot_30s/soiltype_bot_30s.SE.tar.tgz
 soiltype_bot_30s/soiltype_bot_30s.SW.tar.tgz

 soiltype_top_30s/soiltype_top_30s.NE.tar.tgz
 soiltype_top_30s/soiltype_top_30s.NW.tar.tgz
 soiltype_top_30s/soiltype_top_30s.SE.tar.tgz
 soiltype_top_30s/soiltype_top_30s.SW.tar.tgz

 topo_30s/topo_30s.NE.tar.tgz
 topo_30s/topo_30s.NW.tar.tgz
 topo_30s/topo_30s.SE.tar.tgz
 topo_30s/topo_30s.SW.tar.tgz


SI actions are controlled by command-line entries to the
three perl scripts wrfsi.pl, grib_prep.pl, and wrfprep.pl,
and by two namelists: wrfsi.nl and grib_prep.nl.

The SI code consists of Fortran 90 and
C routines.  Some of the SI I/O is performed using netCDF libraries.  Thus
to install and use the WRFSI, you will need a Fortran 90 compiler, a
C compiler (gcc is preferred), the netCDF libaries, and Perl.  Specific
requirements are described in Section 2.1.


2.0 INSTALLING WRFSI:
---------------------------------------------------------------------

2.1 Installation Requirements
---------------------------------------------------------------------

The following packages are required:

2.1.1 NetCDF Library
---------------------------------------------------------------------

The NetCDF package is required for laps, it is available via
internet at  http://www.unidata.ucar.edu/packages/netcdf/
netcdf 3.3.1 or higher is required.  You should check and
determine if netCDF is properly installed;  check that the
'ncdump' and 'ncgen' programs are in your path (e.g. 'which ncdump')

NetCDF is a general format structure. The detailed format of
static.wrfsi data file is self-describing (via 'ncdump'), and
is mirrored in a separate static file called data/cdl/wrfsi.cdl.

2.1.2 Perl
---------------------------------------------------------------------

The perl package is also required for wrfsi; it is available
via internet at any gnu site such as:
http://www.perl.com/pub/a/language/info/software.html


Perl 5.003 or higher is required. Check that 'perl' is in your path.

2.1.3 Fortran 90
---------------------------------------------------------------------

A Fortran compiler for your operating system capable of compiling
both Fortran 90 and Fortran 77 style code is required.  Note that
g77 will not work.  We have built the WRFSI code with the following
compilers:


     IBM xlf90 (IBM with AIX OS)
     Portland Group pgf90 (Intel PC with Linux OS)
     Compaq fort (Compaq Alpha with Linux)


Additionally, NCAR has compiled the code on a Compaq Alpha system running
Compaq unix.  

2.1.4 C
---------------------------------------------------------------------

There are a few C routines in the library.  gcc is the recommended
compiler:
http://gcc.gnu.org

2.1.5 make
---------------------------------------------------------------------
The Makefiles (top level, src/lib and src/grid) work with either
Unix or GNU make utilities (version 3.75 or higher).  GNU make
is available at any gnu site such as:
http://www.gnu.org/software/make/make.html


You can check the version of gnu make by typing 'make -v'.

2.2 WRFSI Directory Overview
---------------------------------------------------------------------
Before building and running the WRFSI system, it is useful to understand
the directory structure we use and the rationale.  There are four distinct
"top-level" directories we refer to:

  SOURCE_ROOT:  This is the top level directory containing the source code, i.e.
  the directory created when you untar the original tar file (note that you
  can rename this directory after untarring if you wish.  Currently, the
  directory is named wrfsi_YYYYMMDD, where YYYYMMDD are the year, month, and
  day of the build from our revision control system). It has various 
  subdirectories, including src, data, and etc. The default setting for
  SRCROOT if not specified by the user will be the directory containing
  the "install_wrfsi.pl" script used during installation.  When installing
  wrfsi, you will generally be in the SRCROOT directory when you run
  the install_wrfsi.pl script.  You should allow approximately 10 MB for
  the SRCROOT.

  INSTALLROOT:  This is the directory where you want the executable system
  (including binaries and Perl scripts) to reside.  This can be the same
  directory as SRCROOT, in which case the "bin" directory will be created
  within the SRCROOT during the installation.  When running any binary or Perl
  script of the WRFSI system, whether manually or via cron, you should use
  the executables found in INSTALLROOT/bin and the scripts in 
  INSTALLROOT/etc.  The rationale for allowing SRCROOT and INSTALLROOT to
  be different is to allow users to have more than one version installed (for
  example, to allow parallel testing of a new version while the original 
  version is still present).  The default INSTALLROOT root if not 
  specified by the user during installation will be in the SRCROOT.  You 
  should allow approximately 5 MB for the INSTALLROOT.

  MOAD_DATAROOT:  This is the top-level directory containing data specific
  to a particular domain (and its nests once that is supported).  For the
  curious, MOAD stands for "Mother Of All Domains", or the coarsest grid
  when using nesting (not yet supported).  It contains a "static" directory, 
  where the namelist (wrfsi.nl) that controls that domain, along with 
  the static.wrfsi netCDF file and the Vtable files that are used by gribprep.
  Having MOAD_DATAROOT separate from the INSTALLROOT and SRCROOT allows a 
  user to have mutiple domains supported by one installation of the WRFSI. 
  Additionally, it is generally good practice to keep source code and 
  executables on separate disk volumes than the data, and this strucuture 
  supports this concept. 
  The default data root if not set is the directory INSTALLROOT/data.

  MOAD_TEMPLATE:  This directory contains "template" files used when
  creating/changing (i.e., "localizing") a domain.  A template file is 
  a file containing one or more entries of the wrfsi.nl that pertain to the 
  domain you are creating.  When running the localization script, the entries
  found in the template wrfsi.nl will be merged with the wrsfi.nl in the
  SRCROOT/data/static area to create a modified MOAD_DATAROOT/static/wrfsi.nl.

  EXT_DATAROOT:  This is the top level directory containing "external" data,
  i.e., the pre-processed GRIB data (in hinterp intermediate format) that
  is going to be read by the hinterp program.  This directory is specified
  in wrfsi.nl (extdataroot) contained in the MOAD_DATAROOT/static directory.
  EXT_DATAROOT is separate from the MOAD_DATAROOT because one set of 
  processed GRIB data (e.g., global AVN data) can support many domains
  (MOAD_DATAROOTs).


2.3 Building WRFSI
---------------------------------------------------------------------
There are five fortran executables (gridgen_model.exe,
grib_prep.exe, hinterp.exe, vinterp.exe, and siscan) that are built
during the install procedure, and a directory tree is built
if it does not already exist. 

After untarring the WRFSI.tar file, cd into the newly created
directory (where install_wrfsi.pl is located).  Ensure the NETCDF
environment variable is set.  This should be set to the directory
which contains the lib and include directories.  For example, at FSL,
our netCDF library is installed in /usr/local/netcdf-3.4, so we would:

setenv NETCDF /usr/local/netcdf-3.4

Alternatively, you can specify this directory on the command line of
when running install_wrfsi.pl.  Also ensure perl is in your path, then
execute the installation:

perl install_wrfsi.pl

Typing the above will do a default installation, where
INSTALLROOT=SRCROOT.  The script will attempt to determine your
hardware platform and operating system.  You can override some of the
automated settings using the following options:
command to install WRFSI:

   --srcroot=/your/source/root
     Set if you want to use a different set of source code than
             the one contained in the directory with the install script
   --installroot=/your/installroot/
     Set this to install in a directory other than SRCROOT
   --path_to_netcdf=/your/path/to/installed/netCDF
     Use this to supply the path to netCDF instead of NETCDF env variable
   --path_to_perl=/your/complete/path/to/perl
     (e.g., --path_to_perl='/usr/bin/perl'
   --machine="machine type: 'alpha, 'alphalinux', 'ibm', or 'pc'    
   --extdataroot=/your/extdataroot
   --dataroot=/your/dataroot

(We have all these command line entries because we are not
yet using "auto-configure" to insert those things automatically
given a platform and software environment.)

NOTE: The install script uses files in src/include called
makefile_"machine".inc.in and to create the file makefile.inc.
File makefile.inc is included in the src/lib and src/grid
Makefile before compiling.  If errors occur when compiling, the
user should examine this file to be sure it conforms to their
environment.  The tar file has these already
included for IBM AIX, Linux PCs, Compaq with Linux, and standard Compaq.  If
your machine is not supported, simply copy one of these to a new name
(makefile_yourmachine.inc.in), and edit the settings appropriately.  If you
get it to work, please consider sending us this file so we can include it
in future distributions.                 

By installing, you get:

$INSTALLROOT/bin
     "      /etc
     "      /templates
     "           "    /default
     "      /extdata
     "         "    /static
     "         '    /extprd
     "         '    /log
     "      /data
              "  /static
              "  /cdl
              "  /log
              "  /siprd
              "  /wrfprd



bin:  contains the five required binaries;
etc:  contains the perl scripts and other utilities to run WRFSI;

Many of the directories above have README files describing
their contents.

(NOTE:  We developed this directory structure based mainly on
the needs of operational (or "real time") modeling groups.  To
make things easier for research users, the installation script
will default to SOURCE_ROOT=current directory from which
install_wrfsi.pl is run, INSTALLROOT=SOURCE_ROOT, MOAD_DATAROOT=
INSTALLROOT/data, EXT_DATAROOT=INSTALLROOT/extdata, TEMPLATES=
INSTALLROOT/templates.


3.0 WRF STANDARD INITIALIZATION OVERVIEW
---------------------------------------------------------------------
Standard Initialization consists of three main functions:  

  1.  Domain definition, controlled by the use of the
      window_domain_rt.pl script, which runs the 
      Fortran gridgen_model.exe program to produce the
      static.wrfsi file.  The static.wrfsi file contains
      information on the grid projection, dimensions, and
      a wide variety of 2d arrays interpolated to the 
      specified grid (terrain height, landuse, etc.)

  2.  Preparation of GRIB data for input, controlled
      by the script grib_prep.pl, which runs the 
      FORTRAN program grib_prep.exe.  Grib_prep
      reformats GRIB data sets into binary files
      suitable for intput into hinterp.  Grib_prep
      can be run independently out of cron or manually,
      as it performs no interpolation to a grid.  Thus,
      the output from grib_prep may be used to support
      multipled domains.  However, if one uses the 
      wrfsi.pl script to run the main SI, it will run
      grib_prep by default unless the -g option is set.
      Grib_prep CAN perform temporal interpolation.


      When grib_prep runs, it needs to know the location
      where you set up its data tree during installation.
      This is known in WRFSI-ese as the external 
      data root, or EXT_DATAROOT.   


  3.  Horizontal/vertical interpolation of grib_prep
      output (or other data placed into the same
      format using another program) to the WRF
      3D grid for input into the WRF "real" program.  This
      process is performed by wrfprep.pl, which calls
      the hinterp.exe and vinterp.exe FORTRAN programs.


      For each domain processed, the WRFSI scripts
      and executables need to know where to look for
      the domains configuration and work area.  This
      is known as the MOAD_DATAROOT, for "mother of
      all domain" data root. 


In addition to EXT_DATAROOT and MOAD_DATAROOT, the WRFSI
system allows the user to have multiple versions of
source code supporting multiple "installation" areas.

With this version of the SI, explicit use of these two
items via environment variables or command line options
is optional. If not specified, it assumes INSTALLROOT
is based on which directory contains the script you are running.


Alternatively, each of the SI scripts wrfsi.pl, grib_prep.pl,
and wrfsi.pl allows you to specify $MOAD_DATAROOT and
$INSTALLROOT on their command lines.  Note that command line
entries supersede the environment variables (if those
variables have already been defined with shell commands).

All of these scripts can be entered with the -h argument, and
they will respond by telling you what they need.  Try it!

The top-level script to run grib_prep is grib_prep.pl.  Here
is the generic command line:

grib_prep.pl [options]SOURCE

where source is one of the sources that has a Vtable.SOURCE
in $EXT_DATAROOT/static and is also entered in
$EXT_DATAROOT/static/grib_prep.pl.  The script has
various options that allow you to specify cycle time,
run length, output interval, etc.  Use the -h option to
see the list.

The main script to perform the horizontal/vertical interpolation is
wrfprep.pl.  Here is the generic command line:

wrfprep.pl [options]

If run without any options, there must be a MOAD_DATAROOT
environment variable set so it knows where to find the domain
data and configuration items (this is created when you run
the window_domain_rt.pl for localization).  Use the -h
option to see what options there are.

Finally, there is a main driver script called "wrfsi.pl" that
will run grib_prep and wrfprep in sequence.  This is to
maintain compatiblity with previous versions, and is used by
entering:

wrfsi.pl [options] YYYYMMDDHH FF SOURCE

An example would be:

wrfsi.pl 2000112812 6 Eta

The last three arguments are required.  They are:

  yyyymmddhh -- The start time of the WRF model run.  For
                example, 12 UTC on November 28, 2000 would
                be specified as 2000112812

  fcstlen ----- The length of the WRF forecast in hours, set
                to 6 in the above example.

  src_model --- The model providing input initialization and
                lateral boundaries; currently only AVN and
                ETA are valid (case insensitive).


To see other options, execute:

wrfsi.pl -h


3.1 gridgen_model PROGRAM
---------------------------------------------------------------------
The gridgen_model.exe executable generates the WRF static
data (e.g., terrain heights, latitudes, longitudes,
map factor, coriolis parameter, land use categories, etc.)
based on user specifications in the hgridspec section of
the wrfsi.nl file. 

Three projection types are supported: Lambert, polar
stereographic, and mercator.  The install script described
above produces a WRFSI setup in the user specified "installroot"
for the default setup given in wrfsi.nl. See section 4.3 below
for additional descriptions of the hgridspec section of wrfsi.nl.

New WRFSI configurations can be obtained by appropriately
setting the "hgridspec" section variables in wrfsi.nl as desired.
One set of executables in the "installroot" will support numerous
WRFSI configurations (these are represented as $DATAROOT's).

NOTE: the horizontal dimensions must be set in "$DATAROOT/data
/cdl/wrfsi.cdl" (nx and ny) to match those in wrfsi.nl (xdim
and ydim). This modification is automatic when using the
automatic domain localization utilities described in section 3.1.1
below.

It is recommended that a new "DATAROOT" be used for each unique
WRFSI configuration. If manually setting up a domain, copy the
"data" subdirectory in the $INSTALLROOT to the new $DATAROOT.
Gridgen_model can then be run manually as follows:
    > gridgen_model.exe $DATAROOT.

For Example:
   gridgen_model.exe /projects/wrfsi/operational/data



3.1.1 AUTOMATIC DOMAIN LOCALIZATION
---------------------------------------------------------------------
Perl scripts exist that allow users to automatically
localize WRFSI domains.  There are two primary scripts:

- window_domain_rt.pl:  This is the script that the user
will run.  The methodology is to use templates with specific
namelist settings that define a domain (these are a selected
few within the hgridspec section of wrfsi.nl).

- localize_domain.pl: This script is activated by
window_domain_rt.pl when once the directories are configured.
This script merges the template specifics with the source
root version of wrfsi.nl.

Usage:

window_domain_rt.pl allows user command line input for
MOAD_DATAROOT (-d), INSTALLROOT (-i), and SOURCE_ROOT (-s)
but these are overrides and it is recommended to set these
environment variables since "window" is designed to use them.

There are three critical (required) command line inputs
to script window_domain_rt.pl. These are:

1. -t: the path to the template(s)
2. -w: which type of localization (use -w wrfsi)
3. -c: whether or not the user wishes to reconfigure the domain.
        (use -c to destroy and rebuild the domain. Without -c
         only static and cdl are destroyed).

Example:

Suppose a user wants to only modify the grid spacing of the
source root wrfsi.nl, then they should setup a template
like this:

     > /your/template/WRFSI_1KM/wrfsi.nl
     > cat /your/template/WRFSI_1KM/wrfsi.nl
       &hgridspec
        moad_delta_x = 1000.,
        moad_delta_y = 1000.,
       /
     >

The domain name is "WRFSI_1KM" which will be generated
automatically if it doesn't already exist (whether or not
-c is used). That is, if $MOAD_DATAROOT is
/scratch/user/WRFSI_1KM/data but /scratch/user/WRFSI_1KM
does not exist, then window_domain_rt.pl will create it
and all necessary subdirectories under that for you.

Assuming the environment variables are properly set, and
all other variables in the namelist are correct, then run
window like this:

     > perl window_domain_rt.pl -t /your/template/WRFSI_1KM -w wrfsi

The window script will evaluate the results of localize_domain.pl
and print output concerning success or failure.  Note that a logfile
will be available ($MOAD_DATAROOT/silog/localize_domain.log) that
the user can examine further if necessary.


3.2 grib_prep PROGRAM
---------------------------------------------------------------------
The executable "grib_prep.exe" is used to extract the
required variables and any user specified variables from the
NCEP grib files and reformats them into files suitable for
input into hitnerp.  It gets its configuration (i.e., what variables
to read and for what times) from two files:

  wrfsi.nl
  Vtable

When using the wrfsi.pl and/or interp.pl scripts, these
files are edited/linked automatically based on the command
line arguments.  In this case, the file that will most
likely be changed by the user is one or all of the various
Vtables contained in the data/static subdirectory.  There
are four Vtables that are currently provided (one for AVN,
one for ETA, one for SST data, and one for SNOW data).  The
wrfsi.pl script copies or links the appropriate Vtable at
run time into the work directory using the name "Vtable"
(i.e., if the background model selected on the command line
is AVN, the script puts a copies Vtable.AVN into the work
directory as Vtable).  These Vtable files control which
variables will be extracted from the GRIB files, which
levels of those variables are desired, and what name the
variable will be labeled as along with a description and units
field for the grib_prep.exe output file.  The templates    
as currently provided contain the basic variables needed for
WRF initialization, and their names should not be edited! 
However, if there are additional variables in the AVN or
ETA grib files the user wants interpolated and passed along
to the hinterp/vinterp program, they only need to add
them to the Vtables.

NOTE: For the current version of WRF (zeta coordinate), the
following variables must be present in the Vtables and
available in the data set for hinterp/vinterp to work
properly.  These variables must be on pressure surfaces and/or
at the surface.

Description :: Units :: Output Name
---------------------------------------------------------------------
Temperature :: K :: T
U-wind comp :: m s{-1} :: U
V-wind comp :: m s{-1} :: V
Rel. Humidity :: % :: RH
Geo. Height :: m :: HGT
Surface Press :: Pa :: PSFC
Terrain Hgt :: m :: SOILHGT
Skin temp :: K :: SKINTEMP
SST :: K :: SST

In addition to the Vtables, grib_prep.exe reads the
filetimespec section of the namelist to determine the start
and end time for the desired output as well as the
time frequency output is desired (if the user wants more
frequent output than that provided by the NCEP files,
grib_prep will do simple linear time interpolation).

When run using wrfsi.pl, the script reads a few other
sections of wrfsi.nl to set things up, including
si_paths and si_controls. 

Detailed descriptions of the wrfsi.nl entries are included
below.

3.2.1 USING OTHER DATA SOURCES
---------------------------------------------------------------------
Because grib_prep essentially reformats GRIB data into an intermediate
format that can be read by hinterp, one can use other non-GRIB data
sources by converting their custom format to the intermediate format.  This
section describes that format, which is nearly identical to the version 3
format of the MM5 "Pregrid" program.

The files are written as Fortran sequential access, unformatted data.  The
data are written as two-dimensional "slabs" and each slab of data has
3 records of metadata preceding the actual array.  The slab is always
written as a REAL array with dimensions (nx,ny).  The first two metadata records
always contain the same variables regardless of map projection, whereas the
third record will be different depending on projection.

Record 1: version
Record 2: hdate, xfcst, source*, field, units, description, level,
           nx, ny, proj_flag
IF (proj_flag == 0)
   Record 3: startloc*, startlat, startlon, deltalat, deltalon
IF (proj_flag == 1)
   Record 3: startloc*, startlat, startlon, dx, dy, truelat1
IF (proj_flag == 3)
   Record 3: startloc*, startlat, startlon, dx, dy, orient, truelat1, truelat2
IF (proj_flag == 5)
    Record 3: startloc*, startlat, startlon, dx, dy, orient, truelat1

Variable Descriptions:


! RECORD 1:
INTEGER*4  :: version 
        ! For now, this should be set to 4

! RECORD 2:
CHARACTER (LEN=24)      :: hdate
        ! Valid date/time in the form YYYY-MM-DD_HH:mm:ss.ssss
        REAL                    :: xfcst
        ! Forecast time (in hours) of slab
        CHARACTER (LEN=32)      :: source
        ! Description of the source of data
        CHARACTER (LEN=9)       :: field
        ! Field name (corresponds to names in Vtable where mandatory
        ! variables must use recognized names)
        CHARACTER (LEN=25)      :: units
        ! Units of data in slab.  This is for documentation purposes only,
        ! as the code will NOT do conversions based on this field.
        CHARACTER (LEN=46)      :: description
        ! Detail description of the data in the slab
        REAL                    :: level
        ! Pressure level in Pa.  If slab is a surface value, the
        ! level must = 200100.0 Pa.  If it is a sea-level variable,
        ! then set level = 201300.0
        INTEGER                 :: nx
        ! Dimension of slab in x direction
        INTEGER                 :: ny
        ! Dimension of slab in y direction
        INTEGER                 :: proj_flag
        ! Flag indicating map projection.
        ! 0: Cylindrical Equidistant (lat/lon grid)
        ! 1: Mercator
        ! 3: Lambert Conformal
        ! 5: Polar Stereographic


! RECORD 3:
       CHARACTER (LEN=8)        :: startloc
       ! Describes the location in the slab of where startlat/startlon
       ! are located.  Valid entries are:
       !    'SWCORNER':  startlat/startlon represent the lower-left corner
       !    'CENTER  ':     "        "     represent the projection center
       REAL                     :: startlat
       ! Latitude at startloc
       REAL                     :: startlon
       ! Longitude of startlon
       REAL                     :: deltalat
       ! Latitude increment for lat/lon grids
       REAL                     :: deltalon
       ! Longitude increment for lat/lon grids
       REAL                     :: dx
       ! Grid spacing in x direction (km), valid at true latitudes
       REAL                     :: dy
       ! Grid spacing in y direction (km), valid at true latitudes
       REAL                     :: orient
       ! Longitude on earth that is parallel to grid's y-axis
       REAL                     :: truelat1
       ! Latitude at which dx/dy are true
       REAL                     :: truelat2
       ! Latitude at which dx/dy are true (Lambert conformal only)



3.3 HINTERP PROGRAM
---------------------------------------------------------------------
The executable "hinterp.exe" is used to horizontally interpolate
fields to the WRF horizontal grid.  It reads the output files from
grib_prep and outputs files in the WRF-native format to be
read by the vinterp program.  It gets the WRF domain information
from the data/static/static.wrfsi NetCDF file built by
the gridgen_model program.

It requires the following files be present:

data/static/wrfsi.nl
data/static/static.wrfsi

It reads the filetimespec section of the wrfsi.nl file to
determine what output times are desired, and reads the
required fields from the static.wrfsi file to perform
the actual interpolation and provide static fields needed
by WRF (e.g., terrain height, latitudes, longitudes, etc.).

Hinterp is very flexible in that it will attempt to handle any
variable found in the grib_prep output (which in turn is controlled
by the Vtables).  So, if a WRF user has special variables that
are required in the WRF input files, they need only be present
in the grib_prep output (or a user-built file that conforms to the
same data format, described later).  It also allows for mutiple
input files that cover the same time period as well as files that
contain pseudo-static data (e.g., SST) covering the whole time period
of the run.  This allows the user to use multiple data sources
to obtain all of the required fields. 

Note that hinterp is the first in the series of WRF SI programs
to output its data in the WRF native format. 

The interp_control namelist options are described later.  Because
hinterp.exe has a strong heritage from MM5V3 "REGRID", users of that
program should find it relatively straightforward to set up. 

3.4 VINTERP PROGRAM
---------------------------------------------------------------------
The final program in the WRF SI suite is vinterp.exe.  Its role is to
vertically interpolate the output from hinterp onto the WRF vertical
coordinate.  As of this release, the only vertical interpolation supported
is from pressure coordinates to the zeta (height-based)
coordinate, but the flexibility has been built into the program
to make it easier to add additional transformations in the future. 

In addition to the vertical interpolation, it derives the variables
required by the WRF initialization routine.  Since the current
WRF prototype is based on the Runge-Kutta dynamic scheme, these
variable include potential temperature, density, surface pressure, and
u and v wind components.  There are a host of "static" variables that are
derived as well.  Like hintep, vinterp is very flexible in that
it will attempt to vertically interpolate any 3D variable it finds
in the hinterp output and it passes through any 0, 1, or 2D variables found
in the output. 

Vinterp requires the following files to run:

hinterp output files in data/siprd
data/static/wrfsi.nl

It uses the vinterp_control and filetimespec sections in
wrfsi.pl to control its behavior.  These items are
discussed in detail in a later section.

4.0 WRFSI NAMELIST ENTRIES
---------------------------------------------------------------------
See README.wrfsi_nl file:  http://wrfsi.noaa.gov/README.wrfsi_nl