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

Re: Reference for NetCDF?

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: Re: Reference for NetCDF?
  • Date: Wed, 3 Jul 1996 11:09:30 -0600
On Jul 2,  3:36pm, Steve Nahm wrote:
> Subject: Reference for NetCDF?
>
> Glenn,
>
> A while back (1990) you told me:
>
> >BTW, an article on netCDF (which is layered on XDR), will appear in
> >_IEEE Computer Graphics_  this summer.
>
> I'm updating the IETF draft for XDR and someone suggested that I
> reference NetCDF.  Could you provide me with the reference info for
> your article?
>
> Thanks!
> Steve

You can find this and other references at
http://www.unidata.ucar.edu/packages/netcdf/faq.html#refs

You can find out more than you want to starting at the netcdf top level,
http://www.unidata.ucar.edu/packages/netcdf/

BTW, netcdf violates the XDR spec (and ONC implementation) in one way.
We 'pack' arrays of native type 'short' into external 2 byte integers
sequentially, padding the entire array to a 4 byte boundary
(similar to the spec for arrays of 'char').
We do not pad out each 'short' in the array to 4 bytes as
xdr_array(..., ..., ..., ..., sizeof(short), xdr_short)
does.
My personal opinion is that this was a hole in the early implementations
which found it's way into the spec.

netcdf implementation version 4 (pending) includes a complete reimplementation
of the external encode/decode functionality of XDR. This is optimised for
arrays
of type, rather than single elements of type. It separates the "encoding"
aspects of XDR from the I/O stuff in the reference implementation. Futher, it
also does no allocation. We broke this out because we needed better, more
precise, exception handling than the reference implementation provides and
because we kept getting implementations (from DEC) where xdr_float() and/or
xdr_double() didn't work.

Nice to hear from you again.

-glenn