Page History

A. The 'CY' refers to the model 'cycle'. The 'R' refers to the IFS model release. The 'v01' refers solely to OpenIFS and is the version of OpenIFS based on that IFS cycle and release.

ECMWF and Meteo-France jointly develop the IFS model. A new cycle is formed when the two centres merge their code changes, typically about once a year. A model release is specific to ECMWF (the 'R' actually represents 'Reading,UK') and there are usually at most 2 or 3 releases of the model before a new cycle is produced from the next merge with Meteo-France.

The version number refers just to OpenIFS. As OpenIFS model versions have a much longer lifetime than IFS versions, OpenIFS is periodically updated with: technical changes for new compiler versions, new hardware, bugfixes from more recent IFS releases, new functionality and so on.

Changes to the version number will not alter the model's results. Only changes to the cycle and release number will alter the scientific results from the model.

A. The 'T' refers to the spectral truncation of the model and the number following is the highest retained wavenumber. A spectral method, based on spherical harmonic expansion is used in the model, for example to compute some horizontal derivatives. The 'T' means the model uses a 'triangular' truncation in spectral space to decide the retained spherical harmonics. The number following the 'T' is the highest retained wave number. For more information on the spectral truncation and resolution of the model and the model grid, the IFS documentation is recommended reading.

T159 is approximately 125km resolution, T255 - 80km, T511 - 40km, T799 - 25km, T1279 - 16km.

A. This depends on the grid used. For medium and high resolutions, the model uses a 'reduced Gaussian grid' with reduced numbers of gridpoints along a latitude circle towards the poles. Full quadratic and linear grids are also possible. The following table shows the correspondence between spectral resolution and lat/lon resolution. 'TL' means linear grid with a triangular spectral truncation. 'T' means a quadratic grid with triangular spectral truncation. 'N' is the number of latitudes between equation and poles. The grid definitions can also be found here: reduced gaussian grid definitions.

A. The OpenIFS model is based on the IFS code though it is only capable of forecasts, no data assimilation is provided. The first OpenIFS version was based on cycle 38 release 1 (known as CY38R1). More information is found on the page comparing OpenIFS .v. IFS. OpenIFS is released less frequently than the IFS so model versions are not always consecutive.

Information on scientific and technical changes for operational cycles is available on the main ECMWF website.

A. The model writes its output in GRIB format using WMO FM-92 GRIB edition 1 and edition 2 messages. ECMWF provides the GRIB_API software for handling and manipulating grib data using either command line tools and a programming library for C, Fortran and Python.

For plotting GRIB data, ECMWF provides the Metview software, which is freely available under the Apache license.

Note that the OpenIFS model outputs a mix of GRIB edition 1 & 2 messages in a single file. Unlike Metview, not all GRIB software available on the Internet can read such files and extra steps may be necessary to separate the messages before use if you want to use 3rd party software.

A. The model can be run in 'reference' mode where it computes statistical numerical norms and compares against values calculated at ECMWF. Please see 'Testing the Installation' for more details.

A. The timestep depends on the horizontal and vertical resolution, the type of grid (full or reduced Gaussian), whether Eulerian or semi-Lagrangian (SL) transport is used and whether the 2 or 3 time-level SL scheme is used. The recommended default is the 2 time-level SL scheme. For this configuration suggested timesteps are: T21 - T159 : 60mins, T213 -T319 : 20mins, T511 and above : 10mins. If the 2 time-level scheme is not used, these timesteps should be halved. If Eulerian, not SL transport is used, these timesteps should be a quarter. For more details, see the code in the routine sudyn.F90 which has approximate values for the timestep (n.b. the NAMDYN namelist variable TSTEP is in units of secs).

Note the model will calculate the optimum timestep for its particular configuration. This value is written to the NODE_001.01 output file. Look for the line:
PTSTEP_OPT (optimal timestep computed in SUTSTEP) 0.36000000E+04
to see the recommended value in seconds.

A. The file 'MCICA' is a climatological input file that the model reads on the first time step. The model expects to read this file and all the climatological files from a sub-directory called 'ifsdata' in the same directory containing the binary executable (e.g. master.exe). See Downloading OpenIFS for more details on how to download and install the data files. It is recommended that the data files are kept separate from the directories where model runs are done and a link to the climatology data directory is made. e.g. if the ifsdata tar files have been unpacked in a directory $HOME/ecmwf/ifsdata then use the command ln -s $HOME/ecmwf/ifsdata/climatology ifsdata in the run directory to make sure the MCICA file is available. Contact OpenIFS support for further help.

A. This usually indicates an error in the GRIB file or GRIB_API configuration rather than the model. Try using the 'grib_ls' or 'grib_dump' commands on the file causing the problem to try to reproduce the error. See the GRIB FAQ on this page, or email openifs-support@ecmwf.int and include the model output file (NODE_001.01) and the job log.

<!-- the same question is also below in grib_api section. make sure answers are the same -->

A. This error means the model can't find the GRIB templates it needs to write out the model results. These are contained in a directory called 'ifs_samples' which is provided with the grib_api library. First check that the directory pointed to by OIFS_GRIB_API_DIR exists and is readable. Then check if the directory $OIFS_GRIB_API_DIR/share/grib_api/ifs_samples exists and is readable. If it does then it's possible that the library may have been moved (or a link to it changed) and because these paths are hardcoded into the grib_api library at compile time, it means the model can't find it. To overcome this, set the environment variable:

GRIB_SAMPLES_PATH - Set to the folder containing the set of samples you want grib_api to use instead of the default one.

e.g.

export GRIB_SAMPLES_PATH=$HOME/ecmwf/grib_api/share/grib_api/ifs_samples/grib1_mlgrib2

the same question is also below in grib_api section. make sure answers are the same

A. This could be for a number of reasons. However, a common one is that when compiled optimized the model requires more memory.  With the optimized settings OpenMP is enabled. This causes the model to require more what's known as 'stack memory'. To increase your stack memory to the maximum allowed on your system, use the command 'ulimit -s unlimited'. If that does not solve your problem, email openifs-support@ecmwf.int.

A. This normally means that the OpenMP stacksize is not large enough. The default per process stack size limit is too low and needs to be increased. Check the value of the OMP_STACKSIZE environment variable. It might also mean the model was not compiled correctly. RPASSF is a fortran77 routine and must be compiled with auto-double options to promote REAL*4 to REAL*8 to match the rest of the model. This is set by default in the compiler configuration files but check this is compiled correctly. Contact openifs-support@ecmwf.int for further help.

A. This means that the number of MPI processes (NPROC) specified in the job control language (PBS, SLURM, etc) in the job script and the value in the fort.4 namelist file are different. They must be the same.Contact openifs-support@ecmwf.int for further help.

A. This could be for a number of reasons.

One possibility is that the buffer space for the MPI communication is not big enough. If you get a NODE.01_001 output file (the model log), look for the line containing "MBX_SIZE" e.g.

 MP_TYPE=          2 MBX_SIZE=  128000000

If your value of MBX_SIZE is less than this then change it in the fort.4 namelist file:

&NAMPAR0
 MP_TYPE=2,
 MBX_SIZE=128000000,

Another possibility is that the model is configured as if running at ECMWF where model I/O is via a different method to a special database. Check that the NODE_001.01 output file and make sure that in namelist NAMCT0, the variable LFDBOP is .FALSE. and in namelist NAMPAR1, the variable NOUTTYPE=1.If not, change these in the fort.4  namelist file.

If this does not solve the problem, please contact openifs-support@ecmwf.int.

See HowTo on changing the model output or contact openifs-support@ecmwf.int.