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

Re: Another netCDF problem on IEEE T90

> From: address@hidden (John Sheldon)
> Subject: Re: Another netCDF problem on IEEE T90
> To: address@hidden (Ramesh Rao), address@hidden (Koushik Ghosh),
        address@hidden (Lou Umscheid), address@hidden,
        address@hidden
> Date: Fri, 9 Aug 1996 01:22:40 -0400 (EDT)
> Cc: address@hidden (Bruce Ross)
>
> Hi all-
>
> I just wanted to update you all on the problem I mentioned to you a
> couple of days ago regarding the "_FillValue" attribute for a double
> precision variable.  In particular, on our C90, the intended value of
> "9.9692099683868690e+36" was correctly stored, while on the IEEE T90,
> the value which gets stored is "414.".  The source of this problem was
> traced to the fact that, in the code writing the file, the variable
> holding the value was declared to be "DOUBLE PRECISION". This is
> explained further below...
>
> When you tell netCDF that you want to store a "double precision"
> quantity, it grabs an input 64-bit sequence and stores it to disk as
> 64-bits.  To its credit, it should be noted that netCDF *is* smart
> enough to realize that when you want to store "floats" from a Cray, it
> has to grab 64-bits and write 32-bits to disk. But, apparently, the
> netCDF library does not know about REAL*16 quantities, which is what
> Cray "DOUBLE PRECISION" amounts to.  It seems that it just ignores the
> least significant bits of any REAL*16.  This was not detectable (for
> non-array quantities) on the C90 because the bit representation of
> REAL*8 and REAL*16 numbers differs only in the number of mantissa bits,
> with the first 64 bits being the same.  On the IEEE T90, however, the
> number of exponent bits is different between REAL*8 and REAL*16, and
> the first 8-bytes of the 16-byte number are misinterpreted.
>
> Now, it's not clear (to me, at least) whether this is a netCDF problem,
> or if it is a problem in the Cray XDR library.  I'm not even sure how I
> could determine which it is.  For now, I can get get by with simply
> making sure I don't declare anything "DOUBLE PRECISION".  But I am
> curious if anyone knows what netCDF and the XDR layer are doing here.
>
> The other problem I mentioned in the same mail just seems to be a
> matter of arithmetic round-off.  It does seem odd, though, that the
> roundoff of large quantities (like "1.E35" in that example or others
> I've used elsewhere) is downward...
>
> Lastly, I am still doing some tests with netCDF on voyager, and not
> everything is working quite right yet, but at least we are making good
> progress.  I will keep you informed...
>
> John

Hi John:

I just wanted to add $.02 to this disscussion, and perhaps clarify some
things.

The version of netcdf you are working with (2.x) and previous versions,
are built on top of the ONC XDR interface. This C language interface,
oddly enough, takes a subset of C language types and maps them to
external representations. It sounds like the "DOUBLE PRECISION" FORTRAN
type (aka REAL *16) on your machine is not the same as the "double" C
type. It is probably a "long double". Unfortunately, there is no
xdr_long_double() function in the XDR interface, and, even more unfortunate,
no way in netcdf 2.x for you to be warned that you are trying to do something
that won't work.

The good news is that we are fixing this. In netcdf-3, we no longer
are building on top of the ONC XDR interface. (The external representations,
are, however, are staying the same, and so is the "file format".)
Our replacement interface does not make an implict connection between the
external data representation being used, and the internal (machine)
representation being converted from or to. The full matrix of conversions is
supported, eg, "write double as external float", "read external short into
int",
rather than just the "diagonal" (sortof) as the ONC XDR interface does.
The other good news is that the public netcdf interfaces will be "strongly
typed". That is to say, there are separate functions for putting and getting
each of the standard types in a language.

The bad news is that "standard types in a language" phrase.
Initially, we aren't supporting "long long" and "long double"
internal types.

Thank you for using netcdf.

-glenn