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

Re: NetCDF development

Bert,

> Thank you for the clarifications.  We've looked at HDF5 as a possible
> solution for our issues, but there is understandable reluctance to convert
> to an incompatible data format.  Have you and the HDF5 team discussed
> possible ways of getting HDF5 to read/write NetCDF 3.5 format files?

No, the proposal for netCDF 4 involves a different format for netCDF 4
files, the first netCDF format change since 1989.  It's impractical to
support some of the advanced features we have proposed, such as large
files that require 64-bit offsets, new packed data types, and multiple
unlimited dimensions using the current netCDF format.  Our plan is to
support a new format in a backwards-compatible way, so that the new
library would be able to read and update files in the old format as
well as read and write files in the new format.  Since the format
version is explicitly represented in netCDF files, it should be
possible to do this transparently to applications.

> Is there any thought of how to represent some of the unique features of
> NetCDF (named dimensions, for example) in HDF5?

Yes, we've thought about this and have a preliminary design.  A
prototype for representing netCDF data using the HDF5 format has been
developed by NCSA.  We have also discussed extensions to HDF5 that
would make such representations more efficient and practical.  That's
why part of the development funds for the NASA proposal are for
supporting any NCSA extensions to HDF5 that are needed to facilitate
its use as a format for the netCDF 4 interfaces.

We've also considered developing our own new format for netCDF 4
independent from HDF5.  Another group of researchers have recently
written a parallel interface and library for accessing netCDF data
that is independent of HDF5, although it also uses MPI-IO.

--Russ