Around once per month we hold an informal 1-hour online meeting mainly involving developers at European forecasting centres who use ecRad, to discuss technical developments to ecRad. Regular attendees are:

  • Robin Hogan, Balthasar Reuter, Johan Ericsson, Willem Deconinck & Ahmad Nawab (ECMWF)
  • Daniel Hupp (MeteoSwiss)
  • Mareike Burba & Daniel Rieger (DWD)
  • Philippe Marguinaud & Erwan Cossevin (Meteo-France)
  • Kristian Pagh Nielsen, Ole Lindberg (DMI)
  • Jean-Francois Grailet (U. Liege)

If you are actively working on ecRad and would like to participate, please contact Robin Hogan. These meetings have been held since 2021 but minutes have only been recorded since October 2025.

Meeting 13 July 2026

Balthasar reported a symposium last year in which Jacob Poulsen (Intel) looked into CPU performance of ecRad, and found that the RRTM gas optics scheme could be optimised, especially making the IG (band) dimension innermost.  This affects a substantial number of files and interfaces, but removes the need for a transpose and improves vectorisation. Also in adding_ica, avoid temporaries for inv_denom improving memory utilisation. Reduces cost by around 21% in offline test on large number of (blocked) columns. In IFS, reduces cost by around 3.2% at Tco399, tests ongoing in Tco1279. General approval was expressed to pushing this forward to the master branch given the changes are bit identical.  

Robin outlined his plans to add precipitation (e.g. rain and graupel) to the McICA scheme. The generalised clouds feature of ecRad already permits different types of hydrometer, but they are all mixed together and fall into one "cloud fraction" which obeys one overlap rule. The new scheme would allow those hydrometeor types described as "precipitation" to be maximally overlapped and thus could decorrelate from the cloud they fell from with vertical distance. It would require an additional "precipitation fraction" to be fed into ecRad.  This variable is already available in the IFS but unused in radiation. Mareike and Daniel R expressed interest in trying this new feature in ICON when it is available. 

Willem is continuing the work on GPU-ising the ATLAS interpolation of the radiation fields to and from the radiation grid; this has been done offline and is now being adapted for being called from Fortran.

Meeting 15 June 2026

Balthasar gave an update on ecRad PRs, particularly the switch from allocatables to pointers. This works well in the IFS but may cause issues for tother compilers. If so please get in touch if any problems, but note that there is a GitHub tag for the last version before this change. There has also been quite a lot of work related to porting the IFS to GitHub. Balthasar also described how the test/ifs makefile had changed, including the default config namelist file, such as including the updated aerosols. He has also updated the "ifs" directory to represent changes to FieldAPI, part of an update of the IFS to treat model fields. Also there is a contribution from Meteo-France including a Python interface. In terms of following up with Johan's work on GPU porting, this will in the first instance be split between members of the IFS section at ECMWF.

Meeting 11 May 2026

Mareike asked whether the IFS can output net flux profiles - it can't at the moment but in principle net flux profiles can be derived from radiative heating rate tendency profiles.

Balthasar and Johan described some recent and upcoming ecRad PRs. #97 is to ensure that ECBUILD_* flags can be passed to ecRad CMake files to ensure consistent compile flags across the IFS and its components. This does not affect the simple compile method for ecRad with just "make". #95 increases the number of tests against reference calculations, so there are now six.  These can be run using a CMake build, and are like the tests in test/ifs but they automatically compare to the reference data. Another important PR is open to move from allocatables to pointers and to upgrade to version 1.8.x, which was agreed in principle.  Later this year there will be a PR to make ecRad ready for Loki transformation as part of being GPU-ready, but this should not affect ecRad usage for non-GPU compilation (the PR concerning pointers is likely to affect more people in practice).

Johan went on to talk about a field layer in the IFS to hold the memory pointed to by ecRad structures, e.g. single_layer_field_type owns the memory pointed to by single_layer_type. Also there will be some ecRad code clean-up to assist GPU/Loki compilation, including to remove recursive routines and to add explicit array bounds, which may improve CPU performance as well. The combination of ecCKD gas optics with the Tripleclouds solver now works and has been tested with Loki/GPU in an offline configuration. Ongoing work includes optimising ecRad's use of large local arrays that are quite inefficient on GPU. Balthasar is working on integrating this into the IFS, and particularly the new GPU-ised interpolation to the radiation grid.

Slides from Johan and Balthasar.

Meeting 13 April 2026

We started by welcoming Yann Meurdesoif, Patryk Kiepas and Remi Kazeroni (IPSL) who are interested in a GPU port of ecRad for the LMDZ climate model.

Robin presented his work on using ecRad to calculate photolysis rates, currently under development to improve the speed of photolysis calculations in the CAMS version of the IFS.

Our IPSL colleagues explained that the LMDZ model was now all ported to GPUs except for the radiation scheme. Currently the GPU version of LMDZ mostly uses OpenACC but their next supercomputer will not support OpenACC directives. Converting the existing OpenACC calls to OpenMP GPU calls in their dynamical core should be straightforward, and they have had success also using Loki for other parts of the model. They plan to use the ecCKD gas optics scheme and the Tripleclouds solver in ecRad. Since this is exactly the configuration currently being pursued by Johan at ECMWF, we decided that it would be the best GPU version of ecRad to use in LMDZ.  It is currently under testing and Johan will give an update at the next meeting, at which point it will hopefully be ready for other groups to test. Yann has since distributed the ecRad namelist they are using to be sure which configuration they are most interested in.

Meeting on 9 March 2026

Johan provided an update on his work on the Loki GPU version, focussing on using the ecCKD gas optics scheme with the Tripleclouds solver. Loki generates OpenACC annotated Fortran and the target architecture is ECMWF NVIDIA A100 GPUs. This involves some changes to the core ecRad code such as changing "allocatable" to "pointer", which is a current PR. Things like hoisting variables up a level are required but can be done automatically by Loki so wouldn't need a change to ecRad. There are a few more things coming down the line, such as replacing "transpose" with inline code that works on GPUs and making some array dimensions explicit. The PR for this is in progress. Johan demonstrated the new wrapper layer for the IFS to interface FIELD_API with ecRad. Since this is IFS-specific it will likely not be in the "radiation" library built by ecRad, but could be included in the ifs directory of the ecRad repository for information. The only remaining issue is lack of bit-reproducibility for parallel runs, but when this bug is found the next step will be to compare the performance and accuracy with the CPU version. Note that the MeteoSwiss/ICON GPU version of ecRad chose to do the GPU version of a different configuration of ecRad: the RRTMG gas optics together with the McICA solver, so direct comparison with the ECMWF version is not really possible.

Meeting on 9 February 2026

Willem gave an update on his work to use ATLAS to do the interpolation to and from the radiation scheme called on a coarser grid.

Meeting on 3 November 2025

We briefly discussed Johan's work to replace allocatable with pointers: this had caused some issues at DWD with the NEC compiler but they have since been resolved.

Marieke's work during her secondment at ECMWF this autumn was discussed: she has added an additional output diagnostic to ecRad containing the "true" direct beam radiation, without including forward scattering that is inherent in using delta-Eddington scaling. This leads to better agreement when comparing Direct Normal Irradiance (DNI) with BSRN pyrheliometer observations. Kristian pointed out the https://solarstations.org/ web site containing a wider range of sites for validating DNI forecasts than BSRN and a best practices handbook for using solar resource data for solar energy applications. He wondered whether the delta-Eddington DNI might be better for PV forecasting given they accept radiation from a wider range of angles than a pyrheliometer, although agreed that for concentrated solar power as used, for example, in Spain, the "true" DNI should be more relevant. He also pointed out the various instruments that can be used from Kipp & Zonen, Delta-T and Hukseflux. The suggestion was raised to also look at the impact of the two definitions of DNI on forecasted sunshine duration, although accepting that this is an imperfect diagnostic.

Sophia briefly summarised some sensitivity studies she is doing with AROME over France & Central Europe, finding that there are lots of compensating errors but that lowering "FSD", the in-cloud fractional standard deviation of water content, helps reduce RMSE.

Meeting on 2 October 2025

Balthasar summarised the ongoing work of Paul Mullowney, who working on a new ecRad branch "master-omp" (https://github.com/ecmwf-ifs/ecrad/tree/master-omp) that consists of an OpenMP port targeting AMD GPU platforms with the Nvidia compiler and the AMD offloading compiler. Part of the challenge is because of a limitation of the Fortran compiler in supporting type-bound procedures, necessitating replacing these with stand-alone procedures.  Daniel Rieger reports that this aspect of ecRad can be a showstopper on some hardware so this branch might be useful more widely. 

Robin briefly mentioned his ongoing work with Emma Turner to extend the ecCKD gas optics into the far UV (115-200 nm) rather than stopping at 200 nm, particularly to enable CAMS photolysis calculations to use ecRad rather than their own radiative transfer scheme.  

Robin also suggested that a similar approach that Balthasar had implemented in ecRad of treating it as an external library in the IFS could be applied to RTTOV. A conversation has been initiated on this with RTTOV developers at ECMWF.

Johan presented some slides summarising his work to replace allocatable arrays in ecRad with pointers, enabling memory allocation within GPU kernels to be avoided: on a GPU this memory would be externally managed, while on CPUs the change is simply to allocate memory to pointers rather than "allocatable" arrays. He reported that on CPUs this even leads to a 10-15% speed-up in normal operation on intel compiler although around neutral with gFortran.

  • No labels