search

NOAA-PMEL / PyFerret

The PyFerret program and Python module from NOAA/PMEL
https://ferret.pmel.noaa.gov/Ferret/
The Unlicense
58 stars 22 forks source link

2nd netCDF file getting the wrong time stamp #141

Open ryofurue opened 12 months ago

ryofurue commented 12 months ago

In the following example, the second file acquires the wrong time value, apparently taking it from the first file:

$ pyferret
    NOAA/PMEL TMAP
    PyFerret v7.63 (optimized)
    Darwin 19.6.0 - 12/10/21
    15-Sep-23 15:14

yes? set data tmp1.nc
yes? set data tmp2.nc
yes? list/format=(G0)/d=1 t[gt=vm]
             VARIABLE : T
                        axis TIME
             FILENAME : tmp1.nc
             BAD FLAG : -1.E+34
             TIME     : 06-NOV-2014 07:00:00
735544.29166666663  !!! <- .291...
yes? list/format=(G0)/d=2 t[gt=vm]
             VARIABLE : T
                        axis TIME
             FILENAME : tmp2.nc
             BAD FLAG : -1.E+34
             TIME     : 06-NOV-2014 07:00:00  !!! WRONG time
735544.29166666663  !!! <- .291...  WRONG
yes? cancel data/all  !!!--- Swap the order ---
yes? set data tmp2.nc
yes? set data tmp1.nc
yes? list/format=(G0)/d=2 t[gt=vm]
             VARIABLE : T
                        axis TIME
             FILENAME : tmp1.nc
             BAD FLAG : -1.E+34
             TIME     : 06-NOV-2014 08:00:00  !!! WRONG time
735544.33333333337  !!! <- .333...  WRONG
yes? list/format=(G0)/d=1 t[gt=vm]
             VARIABLE : T
                        axis TIME
             FILENAME : tmp2.nc
             BAD FLAG : -1.E+34
             TIME     : 06-NOV-2014 08:00:00
735544.33333333337  !!! <- .333...
yes?

I'm attaching a ZIP archive that includes the two netCDF files. tmp-ncfiles.zip

ACManke commented 11 months ago

Coordinates are stored, and used internally, using double precision. On opening datasets, the coordinate axes are tested to see if an identical axis has already been defined. That testing included some single-precision comparisons between coordinates. In this case, double precision is in fact needed to distinguish between the two axis definitions. This is corrected, and the fix will be available in future releases.

ryofurue commented 11 months ago

Thank you for your response! Even though the underlying dataset starts from the year 2000 or so and uses "hours" , the old OPeNDAP data server we use presents its time axis as "days since 0001-01-01". When I saved time slices one timestep at a time, this problem surfaced.

ACManke commented 11 months ago

This is fixed in fmt/src/cd_clean_grids.F.

Coordinate data is always stored in double precision, and analysis computations and checking for duplicate coordinates are done using double precision. When a new dataset is initialized the code tests whether an axis is already defined by some other dataset. For some reason this duplicate-line test was done in single precision. If the incoming axis is defined in double precision, do this check using double precision.