THis does not seem to be a 2 GB problem, but happens because for some reason we have a message with 0 data points.
degrib2.F90 does not handle this well, it assumes at least 1 data points in all cases.
This has never been noticed, because the result is messed up output like this:
GRIB MESSAGE 11 starts at 52338670
SECTION 0: 0 2 1806772
SECTION 1: 7 0 2 1 1 2022 6 21 0 0 0 0 1
Contains 0 Local Sections and 1 data fields.
FIELD 1
SECTION 0: 0 2
SECTION 1: 7 0 2 1 1 2022 6 21 0 0 0 0 1
SECTION 3: 0 14452641 0 0 1
GRID TEMPLATE 3. 1 : 6 0 0 0 0 0 0 4881 2961 0 0 -37000000 299000000 48 37000000 61000000 25000 25000 64 -35000000 247000000 0
NO Optional List Defining Number of Data Points.
PRODUCT TEMPLATE 4. 0: ( PARAMETER = RIME 0 1 203 ) 1 203 2 0 134 0 0 1 0 105 0 1 255 0 0
FIELD: RIME 1 hybrid lvl valid 0 hour after 2022062100:00:00
NO Optional Vertical Coordinate List.
Num. of Data Points = 0 with BIT-MAP 0
DRS TEMPLATE 5. 0 : 0 0 0 0 0
Data Values:
Num. of Data Points = 0 Num. of Data Undefined = -1
( PARM= RIME ) : MIN= -59706.23828125 AVE= -59706.23828125 MAX= -59706.23828125
The MIN, AVE, and MAX are just whatever is in the uninitialized reals when the program runs, so they come out different each run, sometimes all asteriks because the number is too large.
THis does not seem to be a 2 GB problem, but happens because for some reason we have a message with 0 data points.
degrib2.F90 does not handle this well, it assumes at least 1 data points in all cases.
This has never been noticed, because the result is messed up output like this:
The MIN, AVE, and MAX are just whatever is in the uninitialized reals when the program runs, so they come out different each run, sometimes all asteriks because the number is too large.