Version 31 (modified by carlos, 7 years ago) (diff)

--

# Experiment Configuration

In order to design a WRF4G experiment you need to edit a file called experiment.wrf4g. From this file, WRF4G will generate all WRF configuration files required to run the simulations planned for the experiment.

## Configuration format

The configuration experiment file consists of sections, each led by a [section] header, followed by key = value entries. Lines beginning with # are ignored. Allowing sections are [DEFAULT] and [resource_name].

## DEFAULT section

The DEFAULT section provides default values for all other sections. And its key values are:

• name: Name of the experiment it MUST be unique.
• max_dom: Number of domains.
• date_time: Describe dates for a list of realizations with the following format : start_date | end_date | simulation_interval | simulation_length | chunk_size
• start_date: Beginning of the list of realizations.
• end_date: End of the list of realizations.
• simulation_interval: Interval (in hours) between realizations.
• simulation_length: Length (in hours) of each realization.
• chunk_size: Length (in hours) of a temporal piece of a realization. That means that every chunk_size a wrf-restart will be generated.
• calendar: Either standard or leap (default value is standard). Type of calendar to create realizations.
• timestep_dxfactor: If present, the time step is computed as dx*timestep_dxfactor, in kilometers. Defaults to 6, as suggested by the WRF team for most applications. Under some circumstances (cfl problems) a lower value may be needed. In any case, the time step is adjusted to the highest value lower than timestep_dxfactor times dx fitting evenly in one hour period.
• np: Number of processors requested in a parallel job.

If you are going to use PBS/Torque or SLURM resources, it is also highly recommendable to use PPN variable in order to indicate the number of processors available per node. For example, np = 4 and environment = 'PPN = 4' which means 4 processors on one node

• requirements: Requirements for computing rerources where the experiment is going to run (for more information see advanced configuration).
• clean_after_run: Either yes or no (default value is no), indicating whether or not temporary simulation files should be removed. The maintenance of these files on running place could be desirable for debugging purposes.
• save_wps: Either yes or no (default value is no), indicating whether boundary and initial conditions (real.exe output) should be preserved or not. They will be used if the experiment is relaunched again.
• real_parallel: Either yes or no (default value is no), indicating whether the real.exe binary is compiled in serial or parallel mode.
• wrf_parallel: Either yes or no (default value is yes), indicating whether the wrf.exe binary is compiled in serial or parallel mode.
• domain_path: Path of the folder with the information about the domain of the simulations; this is, the files generated by geogrid.exe (nameslit.wps & geo_em.d[nn].nc).
• preprocessor: Name (just the ending [NAME] section in 'preprocessor.[NAME]') of the necessary pre-processor useful to make the specific input data available for WRF model. Users could not be interested in the permanent WRF-necessary modification of any source of data. With the specification and design of a pre-processor, necessary WRF modifications (e.g.: ASCII to GRIB, variables re-coding, complete input data). Pre-processors are included in WRF4G-1.0beta.tar.gz tar file in '${WRF4G_LOCATION}/repository/apps' • extdata_vtable: Vtable of the ungrib module to be used to decode provided GRIB input data. • extdata_path : Path to the input data. It must be consistent with the pre-processor design. • extdata_interval: Interval of the input data (in seconds). On multiple input data sources use the smallest one. • postprocessor: users might be interested in the transformation of the WRF output files. A first generic post-process of the output will be automatically carried out if a valid name postprocessor.[NAME] is provided. Post-processors are included in the WRF4G-1.0beta.tar.gz tar file at '${WRF4G_LOCATION}/repository/apps'
• wrfout_name_end_date: = no
• app: = wrf_all_in_one | bundle | /home/carlos/wrf4g/repository/apps/WRF/WRFbin-3.4.1_r2265_gfortran.tar.gz

# WRF-namelist parameters. Override namelist.input variables here

• namelist_version:Version of the namelist to use, available variables = 3.4.1

namelist

• multiple_parameters: Binary flag (0;No , 1: Yes) indicating whether or not the experiment is based on independent realizations with different values on the WRF-namelist.input file. When activated, it has to be accompanied by appropriated values of:
• multiparams_variables: The set of parameters that we want to change (some or all of them) between realizations. It is given as a coma-separated WRF-namelist.input files (no record specification is necessary if the parameter already appears on the provided WRF-version namelist.input template. If not, it should be [parameter]__[record])
• multiparams_combinations: Values of the changing parameters for each realization. Parameters should be separated by commas and realizations are separated by '/'.
• multiparams_nitems: number of values that should have the namelist parameter. \${max_dom}, as many values as domains; 1, a single value.
• multiparams_labels: the output of the experiment is organized with a folder for each realization. The pattern of the folder name for a given realization is [start_date]_[multiparams_combinations]('_' separated). However, users can provide a set of labels ('/' separated) for each realization, and the folder names will be '[start_date]_[multiparams_labels]'

## WRF-namelist parameters

Users provide namelist values. They will be over-written on multiple_parameters experiments (only the included parameters). Users can modify any of the parameters of the namelist. The name must be the same as the namelist.input entry, with a prefix-flag and the record to where it belongs.

• Single valued; NI_[namelist_parameter_name]_ _[record]: NI flag indicating that [namelist_parameter_name] of record [record] has a single value.
• One value per all domains; NIN_[namelist_parameter_name]_ _[record]: NIN flag indicating that [namelist_paramter_name] of record [record] has the same value for all the domains of the experiment.
• One value per domain; NIM_[namelist_name]_ _[record]: NIM flag indicating that [namelist_paramter_name] of record [record] has a different value for each experiment's domain.

Note that the namelist variables already present in the default namelist.input do not need to be provided with _ _[record].

## How to create one

You can write a experiment.wrf4g from scratch or use the templates that WRF4G provides.

## Examples

### Multipledates runs

When the multiple_dates parameter is set to 0, two additional configuration options (simulation_interval_h and simulation_length_h) are available to set up hindcast runs. Their usage is best understood through a couple of examples. Imagine you are interested in running a 7-day forecast starting every day at 12Z for the period 1-Jan-2001 to 31-Dic-2001. This can be accomplished by setting:

start_date = "2001-01-01_12:00:00"
end_date = "2002-01-01_00:00:00"
is_continuous = 0
simulation_interval_h = 24
simulation_lenght_h = 168 # this is 7 days in hours


and the wrf4g_submit will setup 365 independent runs performing the 7-day forecasts, which will be distributed in the grid or in your local cluster.

### Multipleparameters runs

Multi-physics runs are activated when the multiple_paramters parameter is set to one. Three additional parameters allow you to configure the physics combinations of your interest.

This mode allows varying parameters in general, not necessarily physics options. For instance, a user could be interested in checking WRF performance on domain MPI-decomposition, by settting:

is_multiphysics = 1
multiphysics_variables = "nproc_x,nproc_y"
multiphysics_nitems = "1,1"
multiphysics_combinations = "1,4/4,1/2,2/-1,-1"


you can vary the domain decomposition and send an experiment with four realizations, and the only difference is the way the MPI domains are partitioned.