Hi Ansley,
Thank you for the detailed, helpful explanation!
On Wed, Jul 8, 2020 at 5:54 AM Ansley C. Manke <ansley.b.manke@xxxxxxxx> wrote:
When a coordinates are read in on initializing a dataset, they're checked for regular spacing using the data type of the coordinates in the file, so a floating-point axis is checked using single-precision testing.[ . . . ]But, on writing a netCDF dataset, Ferret/PyFerret always writes coordinates in double precision.
Has that changed recently? Initially I suspected that that was the reason, but the new netCDF file from the SAVE command has single-precision axes:float LON(LON) ;
LON:units = "degrees_east" ;
LON:modulo = 360.f ;
LON:point_spacing = "even" ;
LON:axis = "X" ;
LON:standard_name = "longitude" ;
. . .
(from ncdump -h tmp.nc ) This causes an "irregular axis" warning for LON in this case on PyFerret v7.6 on macOS . In the original netCDF file
float lon(lon) ;
lon:units = "degree east" ;
(It was produced by a colleague and I don't have much control over it). I've found that some of the values of longitude (ncdump -p9 -c . . . ) are different between the two datasets.
As you say below, you are in the middle of moving toward preserving original data and names, and I guess this particular transition to recovering axis data types has been implemented.
But, I still don't understand exactly what's causing the problem, because all the bits of a single-precision number are preserved by the single -> double conversion and the re-conversion double -> single should always recover the original single precision value, bit-by-bit. Perhaps something beyond straightforward conversions is happening?
Anyway, this is a harmelss issue. I just wanted to document it.
Ryo
It looks as though we changed the testing for regular-spacing somewhere at about version 7.4, and I'll have a look at that. Also, we've been working along in general on changes so that any netCDF files that Ferret writes as subsets or otherwise based on netcdf files, match what is in the input files. Things like upcasing variable names and ignoring attributes should at least be controllable. In recent versions we write data using the same data type as the input file, and it should be easy to do the same for axes, so for this example the y-axis would be written as single precision coordinate variable. So we'll have a look at that too.
Ansley
On 7/3/2020 6:51 AM, Ryo Furue wrote:
Ferret Team,
I searched our mailing archive but didn't find it there.
My original netCDF file has an x axis like
float lat = 9.95, 10.05, 10.15, . . .
without the "point_spacing=even" attribute.
I open the file in PyFerret and save just one timestep (L) into a new file:
save/file=tmp.nc/l=10 var
I then open this new file and PyFerret says,
*** NOTE: Axis "LAT" is irregular. Ignoring erroneous point_spacing=even attribute.
Indeed the new file has gotten the "point_spacing=even" attribute.
I come across this problem from time to time. (Today I reproduced this on PyFerret v7.5 on Linux.)
The axis is a single-precision real and the gridpoints may not be precisely represented. So, I'm not surprised that this axis isn't regarded as "even". That is, PyFerret is doing the right thing when it reads the new netCDF file. So, it's probably a mistake that it added the "even" attribute when it saved the data.
Strangely, the longitude axis -0.05, 0.05, 0.15, . . . , which originally didn't have a point_spacing attribute either, got a point_spacing = "uneven" attribute in the new file!
Cheers,Ryo
-- Ansley Manke Science Data Integration Group NOAA Pacific Marine Environmental Laboratory 7600 Sand Point Way NE Seattle WA 98115 I am currently teleworking and am available Tue-Wed-Thu.
-- Ansley Manke Science Data Integration Group NOAA Pacific Marine Environmental Laboratory 7600 Sand Point Way NE Seattle WA 98115 I am currently teleworking and am available Tue-Wed-Thu.