[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 961002: problem with ncdump



>To: address@hidden
>From: Patrick Guio <address@hidden>
>Subject: problem with ncdump
>Organization: The Auroral Observatory, University of Troms, Norway 
>Keywords: 199610020838.AA13526

Hi Patrick,

> I have a problem to report using the last version of ncdump (v2.4.3). I
> have now been using netcdf for a while and I am very satisfied with this
> package (I am using mexcdf on top of it).
> I have now installed version 2.4.3 and the behaviour of ncdump is
> not the same as before. I generate my cdf files using mexcdf. When I was
> running version 2.3, I could browse the data by mean of ncdump, but with
> the last version a lot of the variables are just full of underscores
> (_).
> If I use my old ncdump2.3 on the newly generated cdf files they look
> ok and I know they are ok when I plot them from matlab. Inversely if I
> use my new ncdump2.43 on old cdf files again I get these _'s.

Although it's probably not as prominent as it should be, this behavior
of ncdump is documented in the Release Notes:

    The ncdump program now uses the underscore character (_) to display
    fill-values (data that hasn't been written yet or missing
    values). The ncgen utility recognizes these, as well as the old
    FloatInf and DoubleInf symbols for backward compatibility.
    
and in the User's Guide:

    A special notation for fill values is supported: the `_' character
    designates a fill value for variables.

There are several reasons for using the new "_" notation for fill-values
instead of the old behavior of using "FloatInf" for floating-point,
"DoubleInf" for double precision, and just the value for other types:

  - it is much more compact, making CDL files smaller and faster to
    parse when there are many fill values;

  - it conveys the meaning of the data more clearly, since the "_" is
    only used for values that are equal to the _FillValue attribute, (or
    within relative floating-point epsilon in the case of floating-point
    values), and not also for very large values, as "FloatInf" and
    "DoubleInf" were;

  - it is not type-specific, so is consistent with the display of other
    values in ncdump output, just as for example the constant "1" can be
    used as a value for any numeric type; and

  - it can be done in a backward compatible way, since there was
    previously no valid meaning for "_" as a data constant.

There is currently no way to turn off this behavior of ncdump (and ncgen
parsing "_" as fill values).  I asked the netcdfgroup mailing list
whether anyone needed the old behavior and wanted a flag to ncdump to
support it, but no one responded.  If this causes a problem for you,
please let me know and we can reconsider adding an option to support the
old behavior.

Incidentally, ncdump does not output a "_" for NC_BYTE data unless the
variable has an explicit _FillValue attribute defined, because some
users want to use the whole range for bytes and don't need any fill
value to test for unwritten data.  This is also documented in the User's
Guide:

    ncdump uses `_' to represent data values that are equal to the
    _FillValue attribute for a variable, intended to represent data that
    has not yet been written. If a variable has no _FillValue attribute,
    the default fill value for the variable type is used unless the
    variable is of byte type.

--Russ

_____________________________________________________________________

Russ Rew                                         UCAR Unidata Program
address@hidden                     http://www.unidata.ucar.edu