Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
|
Panel | ||||
---|---|---|---|---|
| ||||
IBM / AIX |
Panel | ||||
---|---|---|---|---|
| ||||
IBM (xlf) issues with grib-apiWhen compiling grib-api on IBM architectures with the XLF compiler, we recommend disabling the creation of "shared libraries" and use static libraries only. This can cause runtime errors. For more information, please see Installing grib-api. |
Panel | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||
Compilation of bindproc.c fails with XLF V12 compilerThis is caused by missing lines in the bindproc.c file for OpenIFS version 38r1. Please add the following code lines to bindproc.c:
Please contact openifs-support@ecmwf.int for further assistance. JIRA Issue:
|
Panel | ||||
---|---|---|---|---|
| ||||
Intel compiler |
Panel | ||
---|---|---|
| ||
Use of MKL library can cause irreproducible resultsOpenIFS includes a compilation configuration for the Intel compiler with the Intel MKL library (for optimized LAPACK/BLAS). However, please be aware use of this library can cause the model to be irreproducible, even on the same core count in successive runs. We recommend not using it if reproducibility is a concern. OpenIFS also only provides a compilation configuration for the MKL and the Intel library. Linking MKL with other compilers is possible, though complicated and is not tried or tested with OpenIFS. For help with linking the MKL library with other compilers, please see: https://software.intel.com/en-us/articles/intel-mkl-link-line-advisor |
Panel | |||||||||
---|---|---|---|---|---|---|---|---|---|
| |||||||||
OpenIFS can fail with Intel compiler at -O2There is an issue with OpenIFS when compiling with the Intel compiler at optimization level -O2 or above on chipsets that support SSE4.1 & AVX instructions. Intel compilers are generally more aggressive at optimisations for -O2 than other compilers. Users will see failure with the T21 test job similar to the following:
It arises because this compiler makes use of 2-way vectorization when compiling both branches of IF statements which can generate floating point exceptions if a zero divide is possible in the unexecuted branch and the IFS internal signal handler (DRHOOK) is enabled. There are several possible workarounds:
OpenIFS uses a default of -O1 in the configuration files. If you increase the optimisation level, please be aware of this issue. For more help with this issue, please contact openifs-support@ecmwf.int. |
Panel | ||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||
OpenIFS fails writing GRIB if grib_api compiled with Intel and -O2We are aware of a problem in grib_api when using the Intel compiler that seems to affect different versions of grib_api and causes the model to fail with a floating point exception (SIGFPE). This is known to happen in the routine PRESET_GRIB_TEMPLATE or in the GRIB_F_SET_REAL8_ARRAY in the grib_api library. The advice is to reduce the optimization level when compiling grib_api to -O1 rather than -O2 or try a more recent version of the Intel compiler. The error message that typifies this problem is:
or a traceback like this:
Note that the grib packing can also fail if the model has produced fields with a very large range of values, such that the grib library can't pack the values into a smaller bit range. For further help, please contact openifs-support@ecmwf.int. |
Panel | ||||
---|---|---|---|---|
| ||||
GNU compilers |
Panel | ||
---|---|---|
| ||
OpenIFS 38r1 fails with gfortran version 5 compilerOpenIFS 38r1 is known to fail when using the gfortran/gcc version 5.2 compiler. The error is:
If this occurs we recommend using version 4.8.1 of the gnu compilers. There is currently no fix for this issue with OpenIFS based on the 38r1 release. Later versions of OpenIFS (40r1+) do not fail. |
Panel | ||||
---|---|---|---|---|
| ||||
Cray |
Panel | ||||
---|---|---|---|---|
| ||||
Cray ATP does not workThis is caused by the way IFS creates its own signal handler. To enable Cray ATP set:
in the job script to completely disable any signal trapping by the IFS signal handler code 'DrHook'. Contact openifs-support@ecmwf.int for assistance. |
Panel | ||||
---|---|---|---|---|
| ||||
CrayPAT does not workThis is a result of the way in which the OpenIFS is compiled. More information on this and the resolution is described here. |
Panel | ||||
---|---|---|---|---|
| ||||
MacOS X |
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
Gfortran compiler fails with missing reference |
Code Block |
---|
cd cfg
cp gnu-opt.cfg mac-opt.cfg |
Edit mac_gnu-opt.cfg
and find the line which defines the pre-processor symbols for the C compiler (gcc):
Code Block |
---|
$OIFS_CCDEFS{?} = BLAS LITTLE LINUX INTEGER_IS_INT _ABI64 |
add 'DARWIN'
to this line:
Code Block |
---|
$OIFS_CCDEFS{?} = BLAS LITTLE LINUX INTEGER_IS_INT _ABI64 DARWIN |
and save the file.
To compile OpenIFS with this new configuration file set:
Code Block |
---|
export OIFS_COMP=mac
export OIFS_BUILD=opt |
which tells the build system to use the file: mac-opt.cfg. The same change can be made to the un-optimized compilation configuration:
gnu-noopt.cfg.
Panel | ||
---|---|---|
Using FCM with 2 or more threads hangsThere is a known issue where more than one thread causes the fcm command to hang. Until this is fixed only use 1 thread for compilation e.g.
This will unfortunately result in longer compile times. |
...
...
...
...