Chapter 4: WRF Initialization

Table of Contents

Introduction

The WRF model has two large classes of simulations that it is able to generate: those with an ideal initialization and those utilizing real data.  The idealized simulations typically manufacture an initial condition file for the WRF model from an existing 1-D or 2-D sounding and assume a simplified analytic orography.  The real-data cases usually require pre-processing from the WPS package, which provides each atmospheric and static field with fidelity appropriate to the chosen grid resolution for the model.  The WRF model executable 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.exe programs) are specifically built based upon a user's selection.

The real.exe and ideal.exe programs are never used together.  Both the real.exe and ideal.exe are the programs that are processed just prior to the WRF model run.

The ideal vs. real cases are divided as follows:

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 the correct initialization for the model.  For example, after configuring the setup for the architecture (with the ./configure command), if the user issues the command ./compile em_real, then the initialization program is built using module_initialize_real.F as the target module (one of the ./WRFV3/dyn_em/module_initialize_*.F files). Similarly, if the user specifies ./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:

Both the real.exe program and ideal.exe programs share a large portion of source code, to handle the following duties:

The real-data case does some additional processing:

The “real.exe” program may be run as either a serial or a distributed memory job.  Since the idealized cases only require that the initialization run for a single time period (no lateral 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 not allow the user to build the code with distributed memory parallelism.  For large 2-D cases, if the user requires OpenMP, the variables nproc_x and nproc_y must be set in the domains portion of the namelist file namelist.input  (nproc_y must be set to 1, and nproc_x then set to the number of processors).

Initialization for Ideal Cases

The program "ideal.exe" is the program in the WRF system that allows a user to run a controlled scenario.  Typically this program requires no input except for the namelist.input and the input_sounding files (except for the b_wave case which uses a 2-D binary sounding file). The program outputs the wrfinput_d01 file that is read by the WRF model executable ("wrf.exe").  Since no external data is required to run the idealized cases, even for researchers interested in real-data cases, the idealized simulations are an easy way to insure that the model is working correctly on a particular architecture and compiler.

Idealized runs can use any of the boundary conditions except "specified", and are not, 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 dynamical studies, reproducing converged or otherwise known solutions, and idealized cloud modeling.

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 of  the domain, number of vertical levels, model top height, grid size, time step, diffusion and damping properties, boundary conditions, and physics options.  A large number of existing namelist settings are already found within each of the directories associated with a particular case.

The input_sounding  file (already in appropriate case directories) can be any set of levels that goes at least up to the model top height (ztop) in the namelist. The first line includes 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 data from 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: a 1-D input sounding is not used because the initial 3-D arrays are read-in from the file input_jet. This means for the baroclinic wave case, the namelist.input file cannot be used to change the horizontal or vertical dimensions since they are specified in the input_jet file.

Making modifications, apart from namelist-controlled options or soundings, has to be done by editing the Fortran code. Such modifications would include changing the topography, the distribution of vertical levels, the properties of an initialization thermal bubble, or preparing a case to use more physics, such as a land-surface model. The Fortran code to edit is contained in ./WRFV3/dyn_em/module_initialize_[case].F, where [case] is the case chosen in compilation, e.g. module_initialize_squall2d_x.F. The subroutine to modify is init_domain_rk. To change the vertical levels, only the 1-D array znw must be defined, containing the full levels, starting from 1 at k=1, and ending with 0 at k=kde. To change the topography, only the 2-D array ht must be defined, making sure it is periodic if those boundary conditions are used. To change the thermal perturbation bubble, search for the string "bubble" to locate the code to change.

Each of the ideal cases provides an excellent set of default examples to the user.  The method to specify a thermal bubble is given in the super cell case. In the hill2d case, the topography is accounted for properly in setting up the initial 3-D arrays, so that example should be followed for any topography cases.  A symmetry example in the squall line cases tests that your indexing modifications are correct.  Full physics options are demonstrated in the seabreeze2d_x case.

Available Ideal Test Cases

The available test cases are

  1. 2-D squall2d_x (test/em_squall2d_x)
  2. 2-D squall2d_y (test/em_squall2d_y)
  3. 3-D quarter-circle shear supercell simulation (test/em_quarter_ss).
  4. 2-D flow over a bell-shaped hill (x,z) (test/em_hill2d_x)
  5. 3-D baroclinic waves (test/em_b_wave)
  6. 2-D gravity current (test/em_grav2d_x)
  7. 2-D sea breeze (test/em_seabreeze_x)
  8. 3-D large eddy simulation (test/em_les)
  9. 3-D Held-Suarez (test/em_heldsuarez)
  10. 1-D single column model (test/em_scm_xy)
  11. 3-D surface fire (test/em_fire)
  12. 3-D tropical cyclone (test/em_tropical_cyclone)

 

Initialization for Real Data Cases

The real-data WRF cases are those that have the input data to the “real.exe” program provided by the WRF Preprocessing System (WPS). This data from the WPS was originally generated from a previously-run external analysis or forecast model. The original data was most-likely in GriB format and was most-likely ingested into the WPS by first ftp'ing the raw GriB data from one of the national weather agencies’ anonymous ftp sites.

For example, suppose a single-domain WRF forecast is desired, with the following criteria:

The following coarse-grid files will be generated by the WPS (starting date through ending date, at 6-h increments):

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 identifies to which domain this data refers, which permits nesting. The next set of characters is the validation date/time (UTC), where each WPS output file has only a single time-slice of processed data. The file extension suffix “.nc” refers to the output format from WPS which must be in netCDF for the “real.exe” program.  For regional forecasts, multiple time periods must be processed by “real.exe” so that a lateral boundary file is available to the 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.

 

Real Data Test Case: 2000 January 24/12 through 25/12

 

Considerations for This Release