netcdf-hdf mailing list is no longer active. The list archives are made available for historical reasons.
Hi, Before I send this note out to the netcdfgroup mailing list, I'd like to get any suggestions for changes from this smaller mailing list, since it mentions netCDF-4 plans, HDF5 work, and Greg Sjaardema's 64-bit offset changes. Please feel free to suggest changes. Thanks! To: netcdfgroup Cc: Subject: Announcement: netCDF version 3.5.1 now available Reply-to: russ@xxxxxxxxxxxxxxxx Organization: UCAR Unidata Program Fcc: +outbox Hi, A new minor release of netCDF, version 3.5.1, is now available from ftp://ftp.unidata.ucar.edu/pub/netcdf/netcdf.tar.Z Version 3.5.1 is essentially the same as version 3.5.1-beta13. It includes bug fixes, portability improvements, and performance enhancements. The netCDF language interfaces and file format are unchanged, so files written with previous versions can be read or written with version 3.5.1. For more information on the changes between 3.5.0 and 3.5.1, see the release notes: http://www.unidata.ucar.edu/packages/netcdf/release-notes-3.5.1.html Please report problems to support@xxxxxxxxxxxxxxxxx Soon we will be making available a beta-release of netCDF 3.6 that includes code contributed by Greg Sjaardema of Sandia Laboratories to supporting 64-bit file offsets for huge netCDF files in a way that is backward compatible with current programs and files. If you aren't affected by any of the issues described in the release notes referenced above, you may want to wait for the 3.6 release. At the same time, we're working with NCSA developers on netCDF-4, which will provide a netCDF interface to HDF5 data and inherit some useful new features from the HDF5 underpinnings. We recently developed a prototype implementation of the netCDF-3 API using HDF5 as a storage layer. This implementation passed all netCDF-3 tests and convinced us that - using HDF5 as a storage layer for the netCDF data model is practical, and - backward compatibility with both netCDF-3 programs and data can be achieved by just recompiling and relinking. In addition, it helped to identify a few desired enhancements to HDF5 to accommodate netCDF-4 more easily. These new features have been specified in a requirements list, and the HDF5 team is working to implement them. The prototype also demonstrates that read/write times and file sizes using the HDF5 format through a netCDF interface are reasonable. We can't support files written using this prototype, because it requires artifacts in the format that will no longer be needed when the necessary HDF5 enhancements are complete. Nevertheless, the results are encouraging and we hope to release a supportable version by June 2005, barring unanticipated problems. -- Russ Rew -- Ed Hartnett