NetCDF-3 Now Available

Unidata is pleased to announce the availability of netCDF-3. The netCDF-3 release supports netCDF-2 interfaces but also includes new C and Fortran interfaces that offer significant benefits. The netCDF file format is unchanged, so files written with version 3 can be read with version 2 and vice versa.

NetCDF-3 includes

The netCDF-3 release is available in source form as a compressed tar file from <URL:ftp://ftp.unidata.ucar.edu/pub/netcdf/netcdf.tar.Z>. Binary versions will soon be available for many platforms from <URL:ftp://ftp.unidata.ucar.edu/pub/binary/>.

Documentation

Documentation for the new release, including new NetCDF User's Guides for C and Fortran, is available in several forms: compressed tar files of HTML files, compressed PostScript files, and online HTML documents.

See <URL:http://www.unidata.ucar.edu/software/netcdf/docs.html> for links to these different forms of documentation as well as links to the online man pages for reference.

Soon-To-Be FAQs: Questions about the New Release

Q: Why did we change the C interface?
A: Rewriting the C library offered an opportunity to implement an improved C interface that provided some significant benefits: type safety, automatic type conversions, improved error handling, and elimination of obstacles to the future addition of support for packed data and multithreading.

Q: Why did we change the Fortran interface?
A: Creating a new Fortran interface similar to the new C interface offered some of the same benefits to users and permitted sharing documentation and testing approaches, so that the resulting code and documentation can be maintained more easily than if we had dissimilar language interfaces. We also decided to use a new approach for layering the Fortran interface on top of the C library---using Burkhard Burow's cfortran.h mechanism instead of our previous homegrown solution---so it was necessary to rewrite the Fortran interface in any case.

Q: Why are programs linked against the new library larger than before?
A: The new library does more, with type-safe interfaces, automatic type conversion, and better performance. If you can determine the requisite compiler and linker flags to build the library as shared on your platform, executables that use netCDF-3 will be smaller. We don't build the library as shared by default, because there are as many different ways of building shared libraries as there are platforms.

Q: Why is the new version named 3.3 instead of 3.0?
A: It's just a number. We made available some prereleases of netCDF-3 and needed to change some interfaces as the result of testing. 3.3 is the first version of netCDF-3 made available for general release. There will almost undoubtedly be follow-on versions (3.3.1, 3.3.2, ...) as we incorporate feedback and bug fixes into the release, but the current release has already undergone extensive testing.

Q: Why don't we provide a program to help convert automatically to the new interfaces?
A: Such a conversion program would require parsing the source language, due to the changed error handling approach in netCDF-3. Simple sed scripts that change function names are not sufficient for such a task. Furthermore, even if automatic conversion were practical, the resulting programs would not take advantage of the simplifications supported by the new automatic type-conversion features.

Q: Will we continue to support the netCDF-2 interfaces?
A: Yes, as long as there are programs that use them we will include the older interfaces in the newer libraries. However, we will encourage use of the netCDF-3 interfaces because of the benefits in type safety, program performance, readability, maintainability, and independence from some schema changes. Eventually, when a future version of netCDF supports packing (e.g., storing arrays of 11-bit integers), programs that use only netCDF-2 interfaces will not be able to write such data, and they will have at most limited capabilities for reading them.

Q: Is the C++ interface still supported?
A: Yes, but we haven't worked on it much since netCDF 2.4. The C++ interface is still a layer on top of the netCDF-2 C interface. We have some plans for incorporating C++ exceptions into a future version for error handling.

Q: Is there a Java interface to netCDF?
A: Yes, but it's not included with this distribution and not yet ready for release. We have worked with Joe Sirott's read-only netCDF Java implementation and also developed a prototype read-write netCDF package, both completely in Java. These two different interfaces and implementations need to be reconciled, and we will be working on this again now that the netCDF-3 release is finished.

Q: Why is the User's Guide no longer included with the distribution?
A: The people who build and install the netCDF library are not necessarily the same as the people who use it, so we decided not to weigh down the distribution with large copies of the User's Guides, instead making the documentation available in multiple forms from a separate Web page. We also want to be able to correct typos and errors in the documentation independently from software bug fixes. This will be the first real test of the new User's Guides, so they are likely to be more volatile than the software.

Q: Why are we no longer using Texinfo for the netCDF User's Guides?
A: We needed to derive both the C and Fortran User's Guides from a common source that captured all the differences and similarities between them. Texinfo's conditional text facilities had bugs that we reported but couldn't work around, so we switched to FrameMaker. We use WebMaker to generate the HTML.

Q: Does netCDF still work on 16-bit platforms, such as MS-DOS?
A: We think the C library should work on MSDOS, but we no longer have access to any 16-bit platforms on which to test the distribution. If someone else has access to these or other more exotic platforms and is willing to do most of the work required to port netCDF-3, we will provide what assistance we can and make the modifications generally available.

Q: Is it possible to successfully build the new version without reading the INSTALL file in the top level of the unpacked distribution?
A: Probably not, but good luck if you decide to try it anyway.