CDO

Hi,

I have some GRIB files which have the key stepRange not equal to 0: 3,6,... After remapping with the operator remapbil, the stepRange key is equal to 0 in the new GRIB files. Here is the grib_ls dump before remapping:

edition centre typeOfLevel level dataDate stepRange shortName packingType gridType
1 lemm heightAboveSea 0 20111001 3 pres grid_second_order rotated_ll
1 lemm heightAboveGround 2 20111001 3 2t grid_second_order rotated_ll
1 lemm heightAboveGround 10 20111001 3 10u grid_second_order rotated_ll
1 lemm heightAboveGround 10 20111001 3 10v grid_second_order rotated_ll
1 lemm heightAboveGround 2 20111001 3 r grid_second_order rotated_ll
1 lemm heightAboveGround 0 20111001 0-3 unknown grid_second_order_SPD1 rotated_ll
1 lemm heightAboveGround 0 20111001 3 tcc grid_second_order_constant_width rotated_ll
7 of 7 grib messages in /home/eolicos/aemet016/20111001000000_sfc_fc03

7 of 7 total grib messages in 1 files

And here is the grib_ls after:

edition centre typeOfLevel level dataDate stepRange shortName packingType gridType
1 lemm heightAboveSea 0 20111001 0 pres grid_simple regular_ll
1 lemm heightAboveGround 2 20111001 0 2t grid_simple regular_ll
1 lemm heightAboveGround 10 20111001 0 10u grid_simple regular_ll
1 lemm heightAboveGround 10 20111001 0 10v grid_simple regular_ll
1 lemm heightAboveGround 2 20111001 0 r grid_simple regular_ll
1 lemm heightAboveGround 0 20111001 0 unknown grid_simple regular_ll
6 of 6 grib messages in out.grid

6 of 6 total grib messages in 1 files

I'm using the ECMWF GRIB API, since I was told CDO doesn't support grid_second_order packing. It is also worth noting that there is one variable less in the output GRIB, since the packing type of the last one is grid_second_order_constant_width and apparently it is not supported by the ECMWF GRIB API. However, I guess that shouldn't mess with the other variables.

Is this a bug or it is the intended behaviour?