Hi Patrick,
I can reproduce what you're describing, with this sequence,
- Define the axis in Ferret
yes? define axis/y=-90:90/npoints=72 yreg
yes? list/j=1:5/prec=7 y[gy=yreg]
VARIABLE : Y
axis YREG
SUBSET : 5 points (Y)
-90 / 1: -90.00000
-87.5 / 2: -87.46479
-84.9 / 3: -84.92958
-82.4 / 4: -82.39436
-79.9 / 5: -79.85915
which matches what you are seeing with ncdump in single precision. Now
save some variable on this axis to a netCDF file; which saves the axis
in double precision.
yes? let aa = y[gy=yreg]
yes? save/clobber/file=yreg.nc aa
And the coordinate values match what you show. Ferret saves the axis
with an attribute
YREG:point_spacing = "even" ;
which applications can use to know that the axis should be treated as
equally-spaced. When Ferret reads the file it uses this to avoid
having to check all the coordinates to see if they are equally spaced.
And it seems that the application you are testing doesn't use that
attribute.
Even if I remove this attribute from the file, Ferret still detects
this particular axis as regularly-spaced; we test for equal-spacing
using a tolerance of slightly less than full double precision 15- or
16-digits for precisely this reason. Software that is writing out
these axes may be up-converting from single precision, or may vary in
the last digit or two depending on how they were produced. In this
example the double precision coordinates have the same delta-y to 14
digits.
We could change Ferret to try to do a better job of writing
equally-spaced double precision coordinates when the axis is evenly
spaced. This cannot be perfect, as the numbers are always represented
as machine values.
We could also think of allowing users to request that the coordinates
be saved as single-precision values (or to keep the precision that the
the input axis had).
And although it wouldn't help with your other software, we have on the
table an idea to allow users to force any axis to be treated as regular
- similar to the current syntax for T axis
yes? use/regulart mydata.nc
so the new syntax might be something like
yes? use mydata.nc
yes? set axis/regular yyaxis ! OR,
yes? set axis/regular `var,return=yaxis`
I've put these ideas in our bug-tracker and we'll think about what's a
good solution.
Ansley
Brockmann Patrick wrote:
Hi all,
I have detected a problem when you have a regular spaced axis
defined as float then saved with ferret. The axis becomes irregular
spaced
because convertion to double brings numerical noice.
Note that this not detected by ferret, which still considers the saved
axis as regular
but by other software such as paraview 3.6 that I am currently testing
(netCDF reader in particular).
A simple ncdump shows the problem too.
Initial axis
#########################################
lat = 90, 87.46479, 84.92958, 82.39436, 79.85915, 77.32394, 74.78873,
72.25352, 69.71831, 67.1831, 64.64789, 62.11267, 59.57747, 57.04226,
54.50704, 51.97183, 49.43662, 46.90141, 44.3662, 41.83099, 39.29578,
36.76056, 34.22535, 31.69014, 29.15493, 26.61972, 24.08451, 21.5493,
19.01408, 16.47887, 13.94366, 11.40845, 8.87324, 6.338028, 3.802817,
1.267606, -1.267606, -3.802817, -6.338028, -8.87324, -11.40845,
-13.94366, -16.47887, -19.01408, -21.5493, -24.08451, -26.61972,
-29.15493, -31.69014, -34.22535, -36.76056, -39.29578, -41.83099,
-44.3662, -46.90141, -49.43662, -51.97183, -54.50704, -57.04226,
-59.57747, -62.11267, -64.64789, -67.1831, -69.71831, -72.25352,
-74.78873, -77.32394, -79.85915, -82.39436, -84.92958, -87.46479,
-90 ;
Saved axis:
#########################################
lat = -90, -87.4647887323944, -84.9295774647887, -82.3943661971831,
-79.8591549295775, -77.3239436619718, -74.7887323943662,
-72.2535211267606, -69.7183098591549, -67.1830985915493,
-64.6478873239437, -62.112676056338, -59.5774647887324,
-57.0422535211268, -54.5070422535211, -51.9718309859155,
-49.4366197183099, -46.9014084507042, -44.3661971830986,
-41.830985915493, -39.2957746478873, -36.7605633802817,
-34.225352112676,
-31.6901408450704, -29.1549295774648, -26.6197183098592,
-24.0845070422535, -21.5492957746479, -19.0140845070422,
-16.4788732394366, -13.943661971831, -11.4084507042253,
-8.87323943661971, -6.33802816901408, -3.80281690140844,
-1.26760563380281, 1.26760563380282, 3.80281690140846,
6.33802816901409,
8.87323943661973, 11.4084507042254, 13.943661971831,
16.4788732394366,
19.0140845070423, 21.5492957746479, 24.0845070422535,
26.6197183098592,
29.1549295774648, 31.6901408450704, 34.2253521126761,
36.7605633802817,
39.2957746478873, 41.830985915493, 44.3661971830986,
46.9014084507042,
49.4366197183099, 51.9718309859155, 54.5070422535211,
57.0422535211268,
59.5774647887324, 62.112676056338, 64.6478873239437,
67.1830985915493,
69.7183098591549, 72.2535211267606, 74.7887323943662,
77.3239436619718,
79.8591549295775, 82.3943661971831, 84.9295774647887,
87.4647887323944, 90 ;
The problem does not occur if axis is initially defined with double
precision.
Let me know if this problem can be confirmed, referenced and corrected
in a next release.
bug reference available at:
http://dods.ipsl.jussieu.fr/brocksce/ferret_bugs/err6.401_axis_float_doudle.jnl
http://dods.ipsl.jussieu.fr/brocksce/ferret_bugs/axis_lat.nc
Patrick
|