Confusing variable names in icon forcing data (iefff)

Tools
1

Hi all,

I’m running into an inconsistency in GRIB2 parameter naming when remapping ICON forcing data, and I’d like to understand why.

Setup 1: ICONTOOLS-2.7.3 on HoreKa

Modules loaded:
module load compiler/intel/2025.1_llvm lib/hdf5/1.14-serial lib/netcdf/4.9-serial cdo-2.5.4

which resolves to:
1) compiler/intel/2025.1_llvm 2) lib/netcdf/4.9-serial 3) eccodes-2.41.0 4) lib/hdf5/1.14-serial 5) libaec-1.1.3 6) cdo-2.5.4

Running cdo -sinfov iefff... on the forcing data gives parameter names like:
C_T_LK, FR_ICE, H_ML_LK, T_BOT_LK, T_MNW_LK, T_WML_LK, W_SO_ICE, FR_LAND, H_SNOW, SNOAG, HSNOW_MAX, Z0, SMI, EVAP_PL, ALB_SEAICE, QV_S, T_G, W_I, FRESHSNW, RHO_SNOW, T_SNOW, W_SNOW, H_ICE, T_ICE, T_SO, W_SO, P, HHL, QC, QI, QR, QS, QV, T, U, V, W

Setup 2: ICONTOOLS-2.8.3 on HoreKa2

Modules loaded (EasyBuild)
module add gompi/2025b HDF5/1.14.6-gompi-2025b netCDF/4.9.3-gompi-2025b netCDF-Fortran/4.6.2-gompi-2025b ecCodes/2.43.0-gompi-2025b CDO/2.5.3-gompi-2025b CMake/3.31.8-GCCcore-14.3.0 UDUNITS/2.2.28-GCCcore-14.3.0

which resolves to:
1) GCCcore/14.3.0 2) netCDF/4.9.3-gompi-2025b 3) ecCodes/2.43.0-gompi-2025b 4) HDF5/1.14.6-gompi-2025b 5) libaec/1.1.4-GCCcore-14.3.0 6) CDO/2.5.3-gompi-2025b, etc ...

Running the same cdo -sinfov iefff... on the same forcing data gives different names for the same fields
C_T_LK, ci, H_ML_LK, lblt, T_MNW_LK, T_WML_LK, W_SO_ICE, lsm, sde, snoag, HSNOW_MAX, fsr, SMI, EVAP_PL, ALB_SEAICE, QV_S, T_G, cnwat, FRESHSNW, rsn, T_SNOW, sd, sithick, sit, T_SO, W_SO, pres, HHL, clwmr, QI, rwmr, snmr, q, t, u, v, wz**

My remapping build configuration on HoreKa2**

In do_configure:
module load intel-compilers/2025.2.0 impi/2021.16.1-intel-compilers-2025.2.0 HDF5/1.14.6-iimpi-2025b netCDF/4.9.3-iimpi-2025b netCDF-Fortran/4.6.2-iimpi-2025b ecCodes/2.43.0-iimpi-2025b iimkl/2025b CMake/3.31.8-GCCcore-14.3.0 libunwind/1.8.2-GCCcore-14.3.0 CUDA/13.2.0

In the remapping script itself:
module add intel-compilers/2025.2.0 impi/2021.16.1-intel-compilers-2025.2.0 HDF5/1.14.6-iimpi-2025b netCDF/4.9.3-iimpi-2025b ecCodes/2.43.0-iimpi-2025b

When I keep the old (all-caps) parameter names in my remapping script, I get:
mo_remap_io::get_varID: Variable W not found!

Questions

  1. Should I simply rename the GRIB variable names in my remapping script to match the new (lowercase/short) names shown on HoreKa2?

  2. Is this a genuine inconsistency between the module/library versions used for remapping vs. the ones used by cdo to read the GRIB2 metadata (e.g. different ecCodes versions using different internal GRIB2 parameter tables)? If so, is there a recommended ecCodes/module combination on HoreKa2 that preserves the old naming convention, or is switching to the new names the expected path forward?

Thanks in advance for any help!

2

Hi Julian,

shortnames are only an interpretation of grib2 metadata. There are tables that translate these grib table numbers into actual short names. By default, eccodes uses the shortnames of ECMWF (the lower case names). DWD has own shortname tables (the upper case names) which need to be specified (also to CDO). In your example, Setup 1 knows about DWD short names, Setup 2 doesn’t.

There are multiple ways to solve this, for example you could use CDO to derive netcdf data from the grib data and rename the variables, if needed. The more consistent way is to defined your ECCODES_DEFINITION_PATH in such a way, that DWD short names are used (as in your setup 1). The ICON Tutorial describes this in detail in section 1.2.4:

I hope this helps!
Daniel

3

Hi Daniel, thanks for your reply. It helped a bit, but I still have some questions:

How do I decide which dwd definiton file ( Index of /weather/lib/grib/ ) I use? Is this ecCode version dependend or do I just use the latest version?

If I use the latest dwd definitons and set the path as in the icon manual to
export ECCODES_DEFINITION_PATH=/yourpath/definitions.edzw:/yourpath/definitions
then using cdo -sinfov gives me the same ICON-names (all in caps) - so that worked :slight_smile:

Can it be using different icontool version that the remapping variable values differ:
775 of 867 fields differ
59 of 867 fields differ more than 0.001
cdo diffn: Processed 780466464 values from 66 variables over 2 timesteps [1.90s 291MB]

Best, Julian

4

Hi Julian,

the DWD definition files have a version which has to correspond to the eccodes version you are using. Unfortunately, eccodes does not provide any method to check this. In some cases, it might also work fine if the version is close, but there is no way to guarantee.

Regarding your second question: Difficult to say without further information, do you know the versions you were using? Anyways, I would like to point out that CDO is the recommended tool for remapping (outside operational NWP centers).

5

I am using icontools-2.7.0 and icontools-2.8.3.

Ok, so I am using ecCodes 2.43. This specific version is not listed, should I then just use the newer or the older definition? And what is the difference between 0-1 and 0-2 in e.g.

eccodes_definitions.edzw-2.44.0-1.tar.bz2 22-Jul-2026 15:43:32 557756

eccodes_definitions.edzw-2.44.0-2.tar.bz2 22-Jul-2026 16:03:37 559433

6

Hi Julian,

it depends on the method. For RBF and barycentric, there might be changes which should not have a significant impact.

Regarding eccodes: I forwarded this to a colleague and we will get back to you.

7

Hi Julian,

ecCodes software version 2.43.0 was not implemented at DWD, so there are no corresponding eccodes_definitions.edzw-2.43.0. As Daniel mentioned, the version of the DWD ecCodes definitions should match the software version. It is therefore advisable to use another version than 2.43.0.

The numbering:

  • eccodes_definitions.edzw-2.44.0-1.tar.bz2
  • eccodes_definitions.edzw-2.44.0-2.tar.bz2

is used to label updates of the DWD definitions that take place between two software version releases at DWD (e.g., when new shortname definitions are implemented). So you may use the latest update.

Best, Sebastian

8

Coming back to your “CDO is the recommended tool for remapping outside operational NWP centers”:

  • why is this the recommend tool outside DWD?
  • is there a rule on how to decide which interpolation method should be used for DWD ICON TOOLS (intp_method) and CDO (remapnn, remapcon, etc.)?
9

why is this the recommend tool outside DWD?

iconremap is neither supported nor distributed publicly. The future of this tool is not clear, thus we do not want to encourage usage. With CDO, you might encounter issues with grib2 metadata, but this is no problem outside operational NWP centers.

is there a rule on how to decide which interpolation method should be used

No, this might depend on variable and resolution difference. In my experience, cdo remapcon usually works fine. For production setups, I would recommend to always have a closer look at the interpolated fields if there are any artifacts.