Types of model output

OpenIFS produces 3 basic types of output:

Prognostic variables: these are output at controllable write times. There is no provision in the model to accumulate averages.

Diagnostics variables: these are also output at specified write times, though there are some exceptions like wind gust or maximum and minimum 2m temperature which represent a max/min value over a period of time.

Cumulative variables or fluxes: these are typically fields such as precipitation which are accumulated from the start of the model run.

The sections below describe how to change and control the model output in more detail. Please contact openifs-support@ecmwf.int in case of difficulty or any questions.

Diagnostics & postprocessing software: Full-Pos

Full-Pos is the name of the code inside OpenIFS that produces the model output and 'in-model' diagnostics. We gratefully acknowledge permission from MeteoFrance to include it in OpenIFS.

More documentation about Full-Pos is available through the links below, though note that not all of the options discussed apply to OpenIFS which does not support any stretched grids or Arpege format output.

ECMWF use additional namelist variables to control output as described in the sections below.

• Full-Pos Home Page
• Full-Pos User Guide (PDF) - somewhat old but still useful reference of the namelists and variables
• Full-Pos Technical Guide (PDF) - detailed technical description of the Full-Pos code and includes more up to date description of some namelists & variables for cycle 38.

GRIB output files

OpenIFS only produces GRIB format files as output and they are named similarly to the input files. e.g.

% ls ICM*+*
ICMGGepc8+000000  ICMGGepc8+000100  ICMSHepc8+000000  ICMSHepc8+000100

The output files all begin with 'ICM' and end in '+'00xxxx'. The number on the end refers to the timestep.

ICMGG files contain gridpoint fields, ICMSH files contain spectral fields.

The model can output at regular or irregular intervals according to the namelist settings.

How to control output frequency

The namelist variables that control the output from the model as it runs are:

Namelist : NAMCT0

LFPOS - (38r1 only) this should be set TRUE in order to turn on model output and diagnostics.

NFPOS - (40r1+). Set NFPOS=2 to turn on model output and diagnostics.

NFRHIS   - this is the output frequency of the 'history' files, that is, the model's variables on the model levels.
NFRPOS  - this is the output frequency of the model variables.

NFRHIS and NFRPOS are usually set to the same value. If they are positive, the units are in model timesteps, if negative the units are in hours.

NPOSTS & NHISTS - these are integer arrays that control the write times of the history files.  They can be used for non-regular output intervals. If they are positive, the units are in model timesteps, if negative the units are in hours.

Examples

Regular output at fixed timesteps

NFRHIS=4,
NFRPOS=4,
NPOSTS=0,
NHISTS=0,

This simple example will cause the model to produce history file output every 4 timesteps.

Make sure that NPOSTS and NHISTS is set to zero for regular output because irregular output (NPOSTS /= 0) takes precedence.

Non-regular output

NFRHIS=1,
NFRPOS=1,
NHISTS(0)=-3,
NHISTS(1:3)=0,-3,-9,
NPOSTS(0)=-3,
NPOSTS(1:3)=0,-3,-9,

In this example, the model will write 3 separate output files at the first timestep (0hrs), 3hrs and 9hrs and then no more regardless of how long the model runs for.

The minus sign indicates the units are in hours rather than timesteps. The 0th element of NHISTS & NPOSTS determines how many outputs are produced in total by the model, the first to nth elements determine the actual output times (hours in this case because of the negative values used).

NFRHIS or NFRPOS act as a multiplier to the values in the NHISTS and NPOSTS arrays. For example, if NFRPOS is set to two, this has the effect in the above example of producing output at 0, 6 and 18hrs rather than 0, 3 and 9 hrs.

Controlling output on different level types

Output levels: Model output can be produced on different vertical coordinates: model levels, pressure, height, potential temperature and PV levels. Output on each vertical coordinate is controlled by 3 namelist variables for each type: the number of fields, the grib codes of the fields and the levels to output on.

GRIB codes: for a complete list of available GRIB output, please see the tables below.

Namelist NAMFPC: This is the main namelist for the post-processing. Variables in this list can be sensitive to changes as many combinations are possible but not all work.

If you find the model output does not provide what you need, please contact openifs-support@ecmwf.int who can advise on the namelist settings to use.

The *FP3D and *FP2D namelist variables are reserved for the prognostic (or derived) variables from the dynamics/numerics.

The "PHY" group of variables is for variables from the physics routines.

NAMCT0: LFPOS. To enable post-processing make sure LFPOS=true in the NAMCT0 namelist.

Model level output

To control model level output the following namelist variables (in NAMFPC) are used:

NRFP3S - list of the model levels on which post-processed output is required.
                e.g. for a 60 level model run where output on all levels was required set:
                NRFP3S=1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,
                For a 91 level model, this would give output on the first 60 levels (top level first).

Note: if output on all model levels is desired then this can be specified by setting NRFP3S=-99 (instead of writing out the full comma-separated sequence of model levels)

NFP3DFS - number of 3D fields to be output on model levels. Must equal number of entries in MFP3DFS.
MFP3DFS - list of grib codes of 3D variables to be output on model levels. See table for valid codes.

               e.g
               NFP3DFS = 4,
               MFP3DFS = 130, 135, 138, 155,
               would output the temperature (130), vertical velocity (135), relative vorticity (138), divergence (155) on model levels.

Pressure level output

RFP3P - list of pressure levels (units Pascals) on which post-processed output is required.
e.g.
       RFP3P=100000.,85000.,70000.,50000.,
       would produce output on 1000hPa, 850hPa, 700hPa and 500hPa.

NFP3DFP - number of 3D fields to be output on pressure levels. Must equal number of entries in MFP3DFP.
MFP3DFP - list of grib codes of 3D variables to be output on pressure levels. See table for valid codes.

Theta level output

RFP3TH - real array in units of Kelvin, of the theta levels on which post-processed output is required.
e.g.
               RFP3TH=330,375,400,450,
               would produce output on 330K, 375K, 400K and 450K levels.

NFP3DFT - number of 3D fields to output to theta levels. Must equal number of GRIB codes listed in MFP3DFT.
MFP3DFT - list of GRIB codes of 3D variables to be output on theta levels. See table for valid codes.

PV level output

RFP3PV - real array in PV units of the potential vorticity levels on which post-processed output is required.
e.g.
                RFP3PV=2E-6,3E-6,
                would give output on the +/- 2 and +/- 3 PVU surfaces.

NFP3DFV - number of 3D fields to output to PV levels. Must equal number of GRIB codes listed in MFP3DFV.
MFP3DFV - list of GRIB codes of 3D variables to be output on PV levels. See table for valid codes.

Height level output

RFP3H - real array in units of metres of height levels above orography for which post-processed output is required.
e.g.
           RFP3H=200,1000,5000,
           would give output on 200m, 1km and 5km height surfaces

NFP3DFH - number of 3D fields to output to height levels. Must equal number of GRIB codes listed in MFP3DFH.
MFP3DFH - list of GRIB codes of 3D variables to be output on height levels. See table for valid codes.

Example annotated namelist

An annotated example NAMFPC namelist can be downloaded.

GRIB parameters

Model output variables are specified in the namelists by using GRIB field codes. GRIB is a WMO standard concise data format.

There are two versions of the GRIB format, known as GRIB edition 1 (released in 1994) and GRIB edition 2 (released in 2003).

The multilevel fields in OpenIFS (sometimes called 'upper air' fields) are written as GRIB edition 2 messages, whilst other fields are written as GRIB edition 1. GRIB parameter IDs are the same in GRIB1 and GRIB2 (this is why the environment variable GRIB_SAMPLES_PATH in the example job script points to a file '.../ifs_samples/grib1_mlgrib2; the 'mlgrib2' means multilevel fields are GRIB2).

OpenIFS mostly uses grib codes from table 128 and will be 3 digits. If you see 6 digit codes specified in a model namelist, the first 3 digits refer to the GRIB table and the last 3 digits are the field code.

A complete list of GRIB parameter IDs is available at: http://apps.ecmwf.int/codes/grib/param-db. NOTE!  Not all grib codes listed here can be output by the model. Please see tables below.

A list of the GRIB fields in the operational datasets from ECMWF can be found here in the description of the HRES forecast output.

Controlling output with namelist NAMFPC

This is the namelist for controlling the post-processing. The model will not output any fields unless requested in the appropriate namelist variable.

If you find the model output does not provide what you need, please contact openifs-support@ecmwf.int who can advise on the namelist settings to use.

Model variables may be output as 3D or 2D, either gridpoint or spherical harmonic forms and on model, pressure, theta, PV or height levels.

Gridpoints fields are output to the ICMGG files, spectral fields are output to the ICMSH files.

The following tables shows what variables are output on which levels and in what form:

3D output fields available

Three-dimensional output fields can be in both spectral and gridpoint form. This is indicated in the table below. Spectral and gridpoint fields are written to separate output fields.

These grib codes can be used in the namelist NAMFPC for the following variables (see below for more details of these variables):

MFP3DFS - fields on model levels,            MFP3DFP - fields on pressure levels,
MFP3DFT - fields on theta levels,              MFP3DFV - fields on PV levels,
MPF3DFH - fields on height levels

For more information, the reader is referred to the IFS Documentation manuals.

All tables are sortable by column, click in the header column.

2D dynamical output fields available

These fields are computed by the model's dynamical core. It is strongly recommended these fields are always enabled in the output in order for the post-processing to work correctly. Note these fields can also be output as gridpoint fields in MFPPHYS. 

These GRIB codes are for use with the NAMFPC variable: MFP2DF. Remember to set the number of gribcodes used with NFP2DF.

2D physical output fields available

These variables are for the MFPPHY variable in namelist NAMFPC and are largely computed by the model's physical parametrizations.

Reset of accumulated fields

The default behaviour is for accumulated fields (in the tables above), to be accumulated from the start of the model forecast. It is possible to have these fields reset whenever they are output. To do this:

&NAMPPC
       LRSACC=true,             ! reset accumulated fields to zero at model output frequency

So if output frequency (controlled by NFRPOS) is set to 6hrs, the accumulated variables are reset to zero every 6hr; if output frequency is 12hrs, the reset to zero happens 12rly and so on.

Note all accumulated variables are reset apart from the physical tendencies and fluxes in the PEXTRA output described below.

Physical tendencies and fluxes (budget) output (PEXTRA)

The physics code in IFS supports the output of 3D tendencies and fluxes for budget calculations. This works differently to the standard diagnostics above as additional namelist variables need to be set. It's typically known as the PEXTRA or LBUD23 model output.

This output is primarily a research tool and is not archived by ECMWF operational forecasts.  For that reason, some details of output fields may change between model releases. If in doubt, please check the appropriate code or contact openifs-support@ecmwf.int for assistance.

To enable this output, follow these steps.

Code

See src/ifs/phys_ec/callpar.F90 for more details on how the PEXTRA diagnostics are computed and stored.

Enable tendency fields output

The computation and storage of the tendencies in the physics model code first needs to be enabled by setting:

&NAEPHY
  LBUD23=true,        ! enable computation of physics tendencies and budget diagnostics

The tendency output is often referred to as 'lbud23' output.

Enable array sizes

All of the diagnostics fields need to be explicitly allocated array storage in the model code, unlike the standard diagnostics above where storage is already allocated in the model.

Do this by setting these namelist variables:

&NAMDPHY
   NVEXTR=25,                              ! set number of tendency output fields (see table)
   NCEXTR=<number of full model levels>,   ! edit to correctly set number of full model levels e.g. 60, 91, 137 etc       

Define GRIB codes for tendency fields

The tendency fields are not standard model output. They therefore need to explicitly have GRIB codes defined for them.

ECMWF use the GRIB codes 91 to 115 inclusive (see table below) for the code provided in OpenIFS. These GRIB codes are empty in GRIB table 128.  Other GRIB codes can be used but only if they are not already assigned. The list of GRIB parameters can be found here.

To set GRIB codes for these tendency fields:

&NAMPHYDS
    NVEXTRAGB(1:25)=91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,  ! define GRIB codes for the tendency fields

If the tendency code (in ifs/phys_ec/callpar.F90) is modified to introduce extra fields, they must also have GRIB codes defined.

Note that defining the GRIB codes does not enable their output from the model. This must be done using the NAMFPC namelist (see below).

Available tendency and flux fields

The following table provides the list of configured fields in OpenIFS. Note that these are subject to possible change between model versions.

Download this table: Tendency_3D.pdf

Request tendency output using NAMFPC

Finally request the output of these fields, via their GRIB codes, in the normal way by using the variables in the NAMFPC namelist. You do not need to output all of the variables, but you must define all the grib codes as the model code will write to all the internal arrays.

For example, to output the u, v & T tendency from convection on model levels, add their GRIB codes to:

&NAMFPC
    MFP3DFS=....,103,104,105,....,            ! Add u,v & T convective tendency output. Remember to add 3 to NFP3DFS

Notes

1. It is advisable to output the tendency & flux fields on model levels only. If other output on other levels are selected, interpolations will be performed which may incorrectly represent the information.
2. All parameters are accumulated from the beginning of the forecast.
3. The precipitation fluxes are appropriate to the half level below the actual output full level. It is therefore advisable not to request these fields on any other type of level other than model level as the FULLPOS post-processing software is not aware they are shifted.
4. The tendencies from dynamics are composed of the explicit right-hand-side (RHS) of the equations and advection terms. The RHS is further stabilized by off-centred non-linear residual in order to comply with the time step discretization scheme used in the IFS (SETTLS). To a first approximation however, this can be neglected. Therefore, unfortunately, there is no tendency for the advection only.
5. The q-tendency (position 9) (similarly to fields in position 6-8) contains the tendency obtained by joint vertical diffusion orographic GWD processes and surface scheme solver.
6. The fields 10 and 11 for momentum variables contains exclusively the part of GWD scheme from the previously mentioned joint solver (so there is some duplication here with the tendencies 6 and 7) plus the contribution from non-orographic GWD scheme.

Spectral fitting of dynamic fields

By default the model will post-process surface or upper-air dynamically fields on pressure, theta or PV levels to perform a spectral fit between the vertical interpolation and the horizontal interpolation. Although this adds to the cost of the model, the spectral fit will remove numerical noise generated by the vertical interpolation beyond the model truncation and is normally recommended.

Although spectral fitting is the model default, the namelist variables do not normally need changing. The NAMFPC namelist variables are:

If NFIT* = 0 (LFIT*=false for CY38), then no spectral fitting is done. See the code in ifs/fullpos/sufpc.F90 and ifs/module/yomfpc.F90 to check defaults for each model release.

It is not possible to spectral fit upper air dynamic fields on height levels or hybrid model levels because the horizontal interpolations are performed before the vertical interpolation in order to respect the displacement of the planetary boundary layer.

Dynamic fields not represented by spectral coefficients in the model will not be spectrally fitted even if the corresponding namelist variable above is set.

Several fields can be smoothed via tunable spectral filters. For further information on this advanced usage, please see section 3.1.2 in the Full-Pos Users Guide.

How to change output at every output instance

(to be done: use of postins/dirlist)

Other NAMFPC namelist variables

CFPFMT - this character string controls the format of the output files. For OpenIFS this should always be set to 'MODEL'.

LFPSPEC - (cycle 38 only) if TRUE post-processed dynamical fields are written out as spectral coefficients. If FALSE, they are written as grid-point fields.

NFPCLI - this integer variable is used to control the use of climatology data in improving the accuracy of the upper air fields and several surface fields when interpolated on surface-dependent levels.
               For OpenIFS, the default is 0 (i.e. off). For more information on this option and the use of climatology data, see section 3.1.3 in the Full-Pos Users Guide.
               You may see other NAMFPC variables like: RFPCORR, LFPMOIS which are related to the use of climatology data. Again, for more details see the Users Guide.

LFPQ - this logical variable controls the interpolation of relative or specific humidity on height or model levels. The recommended value is .FALSE.
           Relative humidity has better conservative properties than mixing ratio when interpolating even if it's not a conservative quantity.
           If set FALSE (recommended) the relative humidity is interpolated then specific humidity is subtracted. If TRUE, specific humidity is first interpolated.