The WRF model has two large classes of forecasts that it is able to generate: those with an ideal initialization and those utilizing real data. The WRF model itself is not altered by choosing one initialization over another, but the WRF pre-processors are specifically built based upon a user's selection.
The ideal vs real cases are divided as follows:
The selection of the type of forecast is made when issuing the ./compile statement. If the user chooses ./compile em_real, then the initialization program is built using the target module (one of the ./WRFV2/dyn_em/module_initialize_*.F files). In each of these modules, the same sort of activities go on:
The real-data case does some additional work:
Both the real.exe and the 3d ideal.exe programs may be run as a distributed memory jobs.
The program "ideal" is an alternative in the WRF system to running with real-data inputs (which uses program "real".) Typically this program requires no inputs except for the namelist.input and the input_sounding files (except for the b_wave case which uses a 2d binary sounding file). The program outputs the wrfinput_d01 file that is read by the WRF model executable ("wrf.exe".)
Idealized runs can use any of the boundary conditions except "specified", and are not, by default, set up to run with sophisticated physics apart from microphysics. There are no radiation, surface fluxes or frictional effects in these cases, so they are mostly useful for dynamical studies and idealized cloud modeling.
There are 2d and 3d examples of idealized cases, with and without topography, and with and without an initial thermal perturbation. The namelist can control the size of domain, number of vertical levels, model top height, grid size, time step, diffusion and damping properties, and microphysics options.
The input_sounding can be any set of levels that goes at least up to the model top height (ztop) in the namelist. The first line is the surface pressure (hPa), potential temperature (K) and moisture mixing ratio (g/kg). The following lines are five digits: height (meters above sea-level), potential temperature (K), mixing ratio (g/kg), x wind component, y wind component (m/s). In the hill2d case, the topography is accounted for properly in setting up the initial 3d arrays, so that example should be followed for any topography cases. The base state sounding for idealized cases is the initial sounding minus the moisture, and so does not have to be defined separately. [b_wave Note: For the b_wave case the input_sounding is not used because the initial 3d arrays are read in from file input_jet. This means for b_wave the namelist.input file cannot be used to change the dimensions either.]
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 bubble, or preparing a case to use more physics, such as a land-surface model. The Fortran code to edit is contained in module_initialize_[case].F, where [case] is the case chosen in compilation, e.g. module_initialize_squall2d_x.F. The subroutine is init_domain_rk. To change the vertical levels, only the 1d 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 2d array ht(i,j) must be defined, making sure it is periodic if those boundary conditions are used. To change the bubble, search for the string "bubble" to locate the code to change.
Available Ideal Test Cases
The available test cases are
The real-data WRF cases are those that have the input data to the real.exe program provided by the Standard Initialization (SI) system. The data from the SI originally came from a previously run, external analysis or forecast model. The original data was probably in GriB format and was probably ingested into the SI by first ftp'ing the raw GriB data from one of the national weather agencies’ anonymous ftp sites.
For example, suppose a WRF forecast is desired with the following criteria:
The following files will be generated by the SI:
The convention is to use "wrf_real_input" to signify data that is output from the SI and input into the real.exe program. The "d01" part of the name is used to identify to which domain this data refers. The trailing characters are the date, where each SI output file has only a single time-slice of processed data.
The SI package delivers data that is ready to be used in the WRF system.
Real Data Test Case: 2000 January 24/12 through 25/12