- Created by Glenn Carver, last modified by Marcus Koehler on Sep 05, 2022
Overview
OpenIFS 43r3v2 is based on the ECMWF operational IFS cycle 43r3 which was the operational model at ECMWF from July 2017 to June 2018. OpenIFS 43r3v2 is an upgraded version of the previous release OpenIFS 43r3v1. See below for details of changes.
Anyone wishing to use OpenIFS must have a OpenIFS license (see the list of Licensed Institutes).
OpenIFS 43r3 will not produce the same results as the previous releases based on 40r1.
Support
Please report any issues or problems with this release to either the OpenIFS User Forums or openifs-support@ecmwf.int.
Model documentation
OpenIFS 43r3v1 is scientifically identical to IFS 43r3. For a full description of the IFS 43r3 operational model, please see IFS manuals in the ECMWF eLibrary.
Summary of scientific changes compared to OpenIFS 43r3v1
OpenIFS 43r3v2 includes all the changes listed below compared to previous release OpenIFS 43r3v1.
Read the Release Notes for OpenIFS 43r3v1 for more details of the changes introduced between OpenIFS 43r3v1 and the previous release OpenIFS 40r1. For all changes related to IFS model cycles, please see: Changes in ECMWF IFS model.
Solar spectrum
A new option has been added to the ecRAD radiation scheme. It is off by default.
The Coddington et al. (BAMS 2016) solar spectrum can be enabled by setting NSOLARSPECTRUM=1 in namelist NAERAD. It is zero by default (Kurucz spectrum, default in oifs 43r3v1). The impact can be seen comparing these plots:
Temperature error with control (default Kurucz spectrum) | Temperature error with NSOLARSPECTRUM=1 |
---|---|
As shown in the plots, the upper stratosphere may be too cold with this change. Users should assess for themselves whether this change is beneficial for their purpose.
Tracer mass fixers
The tracer mass fixers in OpenIFS 43r3 were updated to a match those available in more recent IFS CY45R1.
This new mass fixer is described in more detail in the ECMWF Technical Memo. No. 819 (TM819).
The mass fixer described in TM819 (qmfixer.F90) has some improvements (described in the TM) with respect to its 43r3 predecessor:
- uses improved vertical scaling factor for the stratospheric correction computed by the limiter
- embeds limiter to the fixer to stay always positive definite and quasi-monotone
This new option is also discussed in the OpenIFS Forums here.
Technical changes in Version 2
DrHook : improved handling and reporting of floating point exception
The tracing facility 'DrHook' has been upgraded using more recent code from later IFS cycles. This now allows DrHook to return the precise floating point exception instead of returning a general 'floating point exception' report.
The code changes from the forum post introduce new DR_HOOK_* env vars which allow selective trapping of individual FPE signals (INVALID, DIVBYZERO, etc) rather than the previous default of all the FPE signals. The new env vars are:
DR_HOOK_TRAPFPE_INVALID DR_HOOK_TRAPFPE_DIVBYZERO DR_HOOK_TRAPFPE_OVERFLOW
Setting these to '1' will enable them, '0' (default) to disable them.
The extra code in signal_drhook improves the drhook signal trapping so that it now reports exactly which signal (or error) produced the SIGFPE i.e. whether it was a divide by zero etc. The output line containing this information is rather buried in the long output from drhook but it is now there:
[EC_DRHOOK:sponk:2:1:11577:11577] [20201120:222917:1605911357:6.085] [signal_drhook@/var/tmp/nagc/openifs/build_tests/oifs43r3v1/src/ifsaux/support/drhook.c:1617] Signal#8 was caused by floating-point divide by zero [memaddr=0x4fb78d], nsigs = 1 [EC_DRHOOK:sponk:2:1:11577:11577] [20201120:222917:1605911357:6.085] [signal_drhook@/var/tmp/nagc/openifs/build_tests/oifs43r3v1/src/ifsaux/support/drhook.c:1686] Starting DrHook backtrace for signal#8, nsigs = 1
For more discussion on this change, see OpenIFS Forum post.
FFTW library now fully implemented
The option to use the FFTW library did not work correctly in version 1 of OpenIFS 43r3. This has now been corrected, use of FFTW library is subject to correct licensing.
Compilers
Compilation configurations are provided for the GNU, Intel and Cray compilers.
OpenIFS 43r3v2 is tested and known to work with the following using the configurations supplied:
Compiler | Versions | |||
---|---|---|---|---|
gnu | 6.3.0 | 7.3.0 | 8.3.0 | 9.3.0 |
intel | 17.0.3 | 18.0.1 | 19.0.4 | |
cray/cdt | 8.5.6/16.12 | 8.5.8/17.03 | 8.6.2/17.09 | 8.7.7/18.12 |
Version 15 of the Intel compiler is not recommended as it has known issues with the OpenIFS code. Version 16.0.0 of the Intel compiler may generate compile errors in sufa.F90. We recommend using a more recent version if possible.
The Known Issues page has more information about potential problems with the OpenIFS code.
Technical information for version 1
ecCodes GRIB library
Users must install the ECMWF ecCodes GRIB software library to use OpenIFS 43r3. The model will fail if the older ECMWF grib-api software is used.
netCDF library
OpenIFS now depends on the netCDF library to be available in order to read and write files in both ecRad and the wave model components. Compilation of OpenIFS requires the netCDF library to be available. Please see the OpenIFS 43r3 User Guide for more details.
XIOS parallel I/O server: netCDF model output
Note that XIOS is not part of IFS, it is specific to OpenIFS only. The OpenIFS team are grateful to the team at the Barcelona Supercomputing Centre, and members of the EC-Earth community, for the implementation of XIOS in OpenIFS.
The XIOS parallel input/output library allows OpenIFS to pass all output to a separately running program (XIOS) for more efficient performance. XIOS allows for parallel output in netCDF format directly from OpenIFS instead of GRIB output via a single process. It is configured using XML input files and does not use the NAMFPC model namelist. In addition, XIOS may be configured to compute additional fields such as monthly averages 'on-the-fly' instead of a separate post-processing step after the model is run.
For instructions on how to download, build and use XIOS with OpenIFS, please see the How-to use XIOS with OpenIFS guide. By default, OpenIFS assumes that XIOS is not available. Users must have the XIOS library installed on their system and then configure the compilation to use XIOS. Note that even with XIOS linked into OpenIFS it is still possible to enable GRIB output and turn off output via XIOS. It is not possible however, to have both GRIB & netCDF output from XIOS enabled at the same time.
A t21test_xios directory configured to use with XIOS is provided with OpenIFS with some example files. The command to run OpenIFS, in bin/oifs_run, supports running OpenIFS with and without XIOS enabled.
Please note, that the XML files to configure XIOS must be developed by the user and are more complex to setup than the usual NAMFPC namelist in OpenIFS. In addition, as XIOS is not used operationally with IFS we are unable to provide anything other than support for configuring and building OpenIFS with XIOS. Users are strongly recommended to post any queries relating to XIOS to the OpenIFS Forums for help from other users.
Further reading:
Computational aspects and performance evaluation of the IFS-XIOS integration
(ECMWF Tech. Report).
Command line arguments
OpenIFS 43r3 no longer supports command line options to set the forecast length, timestep etc. These settings must now be configured in the namelist NAMARG in the namelists file fort.4.
The command to run OpenIFS, in the file bin/oifs_run, has been modified See the model code in src/ifs/module/yomarg.F90 for more details of the namelist variables to set forecast length, timestep etc.
Namelists changes
There have been a significant number of changes to the model namelists compared to OpenIFS 40r1. It's recommended that users do not attempt to use OpenIFS 40r1 namelists with OpenIFS 43r3 but contact openifs-support@ecmwf.int for new experiment files and matching namelist.
Acknowledgements
The OpenIFS team would like to acknowledge the research and support of ECMWF scientists involved in this release and the contribution of the OpenIFS users mentioned above.