Magics 2.24.7 has just been released as User Version on all our platforms.
This version is now used to generate all the operational plots for the new cycle.
We started working on the next version where new features will be added.
In the wish list, we have:
- Introduction of the Streamlines.
- Improved observation plotting and use of meteorological symbols
- Improved zoom mechanisms for cell/grid shading for Metview and ecCharts
We will keep you informed when the new developments will become available to test.
With gfortran 4.6 onwards, you run a real risk of invoking software-emulated 128-bit precision floating point operations when you thought you were asking for hardware-supported 64-bit operations. A symptom is that the linker requires -lquadmath to be added.
See this interesting article for more details:
libquadmath was introduced in GFortran 4.6 which fundamentally changed what the -fdefault-real-8 switch does. Rather than promoting all floating point arithmetic to double precision, it doubles the width of all floating point types, so explicitly typed double precision is converted to quad precision. This quad precision is orders of magnitude slower since it must be done in software, causing binaries built with -fdefault-real-8 to grind to a halt when built with GFortran 4.6 and newer.
The solution is to add -fdefault-double-8 to undo this implicit doubling of explicit real*8.
Guidance
When building ECMWF software which contains Fortran code, if you add -fdefault-real-8 then you should also add -fdefault-double-8 to the compiler flags. If the linker complains about missing quadmath symbols then you may need to rebuild the complete software stack - for example, you may encounter the problem when linking Metview, but the problem might have been generated when building emoslib. For CMake, this command-line option should work:
cmake ...... -DCMAKE_Fortran_FLAGS="-fdefault-real-8 -fdefault-double-8"
Addendum
The behaviour can be demonstrated with the following trivial Fortran programme:
program gfortran_test double precision :: a, b, c c = a + b end program
Compile this programme in 3 variants:
# Default precision gfortran test.F90 -o test_default # Double precision for real and double gfortran test.F90 -fdefault-real-8 -fdefault-double-8 -o test_double8 # Double precision for real, quad precision for double gfortran test.F90 -fdefault-real-8 -o test_double16
Verify that the last programme actually uses emulated quad precision and the remaining ones do not:
$ nm -a test_default | fgrep __addtf3
$ nm -a test_double8 | fgrep __addtf3
$ nm -a test_double16 | fgrep __addtf3
U __addtf3@@GCC_4.3.0
Note that gfortran >= 4.6 will always link libquadmath, regardless of whether quad precision emulation is actually required or not. In other words: if a library / binary links libquadmath, this is not yet a sufficient indication that quad precision double arithmetic is used.
Dear Emoslib users,
Version 000402 of Emoslib has been released, including a good number of new features and bug fixes. This is the first export version since 000392 (with exception of a CMake test release of version 000400). We would like to thank the users of the CMake test release who provided us with very useful feedback.
The highlight changes since version 000392 are:
- The installation is now using CMake to be in line with other ECMWF software packages
- Various bug fixes including for the bilinear interpolation with reduced Gaussian grids
- Support for new wave parameters introduced in CY41R1
- Add environment variable EMOSLIB_FILENAME_APPEND_LSM_GG to trigger non-default land sea marks (LSM) for rotated grids.
A full list of all changes for each Emoslib version can be found at
The new version can be downloaded in the following page
https://confluence.ecmwf.int/display/EMOS/Releases
Please report any problems to software.support@ecmwf.int