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

960102: netcdf with 64 bit integer & real for Digital UNIX ?

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: 960102: netcdf with 64 bit integer & real for Digital UNIX ?
  • Date: Wed, 03 Jan 96 08:16:05 -0700
Eng,

> From: Eng Sin Teoh <address@hidden>
> Organization: Digital Corporation
> Subject: netcdf with 64 bit integer & real for Digital UNIX ? 
> Keywords: 199601030057.AA13250 netCDF DEC 64-bit

In the above message you wrote:

> I am currently porting Cray (Fortran) to Digital Unix and ran into an 
> odd problem.  Because the Cray code uses 64 int and 64 bit real, I have
> decided to compile on Digital UNIX using 64 bit int/real as the default.
> 
> Unfortunately, the above breaks when it accesses the netcdf (v2.4 beta5) on 
> Digital Unix. (netcdf on D Unix uses 32 bit int and 32 bit real by default.)
> 
> What are the "gotchas" to compile a 64 bit integer and 64 bit real 
> version of netcdf for Digital Unix ?

I don't think that one can create a Digital UNIX netCDF library that uses 
64-bit floats.  I wouldn't even attempt it because I don't believe such
a thing is necessary.  In a netCDF dataset, the following variable types
can exist:

    netCDF Type # Bits
    ----------- ------
    NCSHORT     16
    NCLONG      32
    NCFLOAT     32
    NCDOUBLE    64

The netCDF library is designed to use the following mapping:

    netCDF Type C Type
    ----------- ------
    NCSHORT     short
    NCLONG      nclong
    NCFLOAT     float
    NCDOUBLE    double

There is no reason that I can see for attempting to bypass this mapping.
Since an NCFLOAT has only 32 bits, nothing is gained by mapping it to a
`double' rather than a `float'.  Similar reasoning applies to NCDOUBLE.

To be portable, the code you're porting should have been written using
the above mapping -- in which case it will work, unmodified, on Cray's,
Alpha's, Sun's, and PC's.

Please let me know if this helps or if you wish to discuss the matter
further.

--------
Steve Emmerson   <address@hidden>