CDO

Hi,

I'm trying to remap ICON's prediction with help of CDO according to "Guideline for the transformation of GRIB2 datasets from the original triangular to the regular lat/lon grid. Version 1.3. February 14, 2018". My command line is:

cdo -O -f grb2 remap,ICON_GLOBAL2WORLD_0125_EASY/target_grid_world_0125.txt,ICON_GLOBAL2WORLD_0125_EASY/weights_icogl2world_0125.nc icon_global_icosahedral_single-level_2023062300_000_CLCT.grib2 /tmp/clct.grib2

The files could be obtailed at https://opendata.dwd.de/weather/lib/cdo/ and https://opendata.dwd.de/weather/nwp/icon/grib/00/clct/

At first I tried it with cdo installed on Kubuntu machine from its official repositories. And it was CDO 2.1.1. It outputs:

ECCODES ERROR   :  pack_bytes: Wrong size (20) for section2Padding. It is 0 bytes long
cdo    remap: Processed 2949120 values from 1 variable over 1 timestep [0.87s 437MB]

I googled for this error and decided that it might be ignored while I'm getting a valid output file. So I'm fine this this.

Then I tried to do the same on system that has no CDO in repos (Astra Linux).
I downloaded the latest CDO 2.2.0 sources. Build them with eccodes-2.30.2 and a few other deps that I was able to get from repos (libeac, openjpeg, netcdf..). My configure is:
./configure --with-eccodes=/usr --with-netcdf=/usr --with-sz=/usr

The cdo was build successfully, but the output is:

cdo    remap (Abort): NetCDF: Invalid dimension ID or name

with no output file.

I spent a few hours debugging it. I tried to build it with newest netCDF (4.9.x) sources - and couldn't workaround this problem.

Then I tried to do the same with CDO 2.1.1 sources (the same version I had in Kubuntu repos). And it works!:

$ cdo-2.1.1/src/cdo  -O  remap,ICON_GLOBAL2WORLD_0125_EASY/target_grid_world_0125.txt,ICON_GLOBAL2WORLD_0125_EASY/weights_icogl2world_0125.nc    icon_global_icosahedral_single-level_2023062300_000_CLCT.grib2 /tmp/clct.grib2
ECCODES ERROR   :  pack_bytes: Wrong size (20) for section2Padding. It is 0 bytes long
cdo    remap: Processed 2949120 values from 1 variable over 1 timestep [1.13s 414MB]

Is this a bug? Regression? Or some warning in 2.1.1 become treated as error in 2.2.0?