NOAA-EMC / NCEPLIBS-grib_util

This is a collection of NCEP GRIB related utilities.
Other
22 stars 11 forks source link

grb2index produces incorrect header record for test file gdaswave.t00z.wcoast.0p16.f000.grib2 #172

Closed edwardhartnett closed 7 months ago

edwardhartnett commented 2 years ago

We have a small test file, gdaswave.t00z.wcoast.0p16.f000.grib2.

WHen I run grb2index on the test file like this:

./grb2index gdaswave.t00z.wcoast.0p16.f000.grib2 ref_gdaswave.t00z.wcoast.0p16.f000.grb2index I get an index file called ref_gdaswave.t00z.wcoast.0p16.f000.grb2index. But the second of two header records is incorrect:

!GFHDR!  1   1   162 2022-10-13 20:16:44 GB2IX1        0000            grb2index
IX1FORM:       162      3800**********  gdaswave.t00z.wcoast.0p16.f000.grib2    

Where the ** is, there is supposed to be the total number of records in the file.

THis occurs with our most recent releases.

edwardhartnett commented 2 years ago

OK, the problem is on line 105 of grb2index.F90:

NUMTOT=NUMTOT+NNUM

The problem is that NUMTOT is never initialized (and never declared). So it gets some random value which does not fit in the format at comes out as *s.

Does the intel compiler automatically initialize variables to 0? As explained here, many compilers do (or did), but it is not Fortran standard: https://gcc.gnu.org/onlinedocs/gcc-3.4.6/g77/Variables-Assumed-To-Be-Zero.html

edwardhartnett commented 2 years ago

OK, this only occurs when CMAKE_BUILD_TYPE=Debug, which is why we don't see it in our CI testing.

edwardhartnett commented 2 years ago

But even when build type is not debug, this causes a random number to appear as the number of index records. Even in our reference file, generated before any changes were made to the code, the number of index records is incorrect.