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

Re: netcdf install problems

> From address@hidden Mon Mar 28 17:32:02 1994
> Date: Mon, 28 Mar 94 17:31:58 MST
> From: address@hidden (Dave Resch)
> To: address@hidden
> Subject: Re:  netcdf install problems
> 
> Thanks Glenn,
> 
> Yes that certainly helps.  It looks as if the ncdump of test.cdf and
> test_cdf.sav are the same.  I will look into our xdr encoding for a 
> double float of 0.0 and verify that it is correct.

It would be important to generate the netcdf file "test.cdf" on the system
under test (cray 3?) and run the ncdump on an IEEE machine. Otherwise,
a problem of the form X -> F(X) might be masked by X == Finverse(F(X))
on the machine under test.
 
> It looks like I spent considerably more time than I needed to looking
> into this problem, most of which was because I was totally unfamiliar 
> with netcdf...  

Sorry about this.
 
> Since this software is meant to be installed on varying machine 
> architectures (IEEE floating point and other), and likely by people 
> that are not all that familiar with the internals, I would suggest 
> that the test suite the install kit recommends running be made
> "machine independent".  In this case, if the binary files don't need
> to be absolutely "identical", then compare the ncdump outputs of the 
> binaries instead of the binaries themselves... 

Actually, upon looking at the cdftest code, I see that the "put" values
there have been set to values which have exact floating point representations
on known floating point architectures. (It used to be that there were values
like PI in there.) So, my earlier statement that it is okay for
test.cdf to be fuzzy with respect to test_cdf.sav is false.
(For arbitrary netcdf files containing float or double values, it is true
that there may be fuzz. The values in cdftest.c were specially chosen
so that byte for byte comparison should work on all platforms.)
Sorry about the confusion.

It should be clear that your system has some (albiet small) problem doing
xdr_double() encoding of zero. It probably needs a special case for
zero.

-glenn