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 & Ahmad Nawab (ECMWF)
- Daniel Hupp (MeteoSwiss)
- Mareike Burba & Daniel Rieger (DWD)
- Sophia Schaefer, Philippe Marguinaud & Erwan Cossevin (Meteo-France)
- Kristian Pagh Nielsen (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 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.