In different contexts, “netCDF” may refer to an abstract data model, a software implementation with associated application program interfaces (APIs), or a data format. Confusion may easily arise in discussions of different versions of the data models, software, and formats, because the relationships among versions of these entities is more complex than a simple one-to-one correspondence by version. For example, compatibility commitments require that new versions of the software support all previous variants of the format and data model.
To avoid this potential confusion, we assign distinct names to versions of the formats, data models, and software releases that will be used consistently in the remainder of this appendix.
In this appendix, two format variants are specified formally, the classic format and the 64-bit offset format for netCDF data. Two additional format variants are discussed less formally, the netCDF-4 format and the netCDF-4 classic model format.
The classic format was the only format for netCDF data created between 1989 and 2004 by various versions of the reference software from Unidata. In 2004, the 64-bit offset format variant was introduced for creation of and access to much larger files. The reference software, available for C-based and Java-based programs, supported use of the same APIs for accessing either classic or 64-bit offset files, so programs reading the files would not have to depend on which format was used.
There are only two netCDF data models, the classic model and the enhanced model. The classic model is the simpler of the two, and is used for all data stored in classic format, 64-bit offset format, or netCDF-4 classic model format. The enhanced model (also referred to as the netCDF- 4 data model) was introduced in 2008 as an extension of the classic model that adds more powerful forms of data representation and data types at the expense of some additional complexity. Although data represented with the classic model can also be represented using the enhanced model, datasets that use features of the enhanced model, such as user-defined nested data types, cannot be represented with the classic model. Use of added features of the enhanced model requires that data be stored in the netCDF-4 format.
Versions 1.0 through 3.5 of the Unidata C-based reference software, released between 1989 and 2000, supported only the classic data model and classic format. Version 3.6, released in late 2004, first provided support for the 64-bit offset format, but still used the classic data model. With version 4.0, released in 2008, the enhanced data model was introduced along with the two new HDF5-based format variants, the netCDF-4 format and the netCDF-4 classic model format. Evolution of the data models, formats, and APIs will continue the commitment to support all previous netCDF data models, data format variants, and APIs in future software releases.
Use of the HDF5 storage layer in netCDF-4 software provides features for improved performance, independent of the data model used, for example compression and dynamic schema changes. Such performance improvements are available for data stored in the netCDF-4 classic model format, even when accessed by programs that only support the classic model.
Related formats not discussed in this appendix include CDL (“Common Data Language”, the original ASCII form of binary netCDF data), and NcML (NetCDF Markup Language, an XML-based representation for netCDF metadata and data).
Knowledge of format details is not required to read or write netCDF datasets. Software that reads netCDF data using the reference implementation automatically detects and uses the correct version of the format for accessing data. Understanding details may be helpful for understanding performance issues related to disk or server access.
The netCDF reference library, developed and supported by Unidata, is written in C, with Fortran77, Fortran90, and C++ interfaces. A number of community and commercially supported interfaces to other languages are also available, including IDL, Matlab, Perl, Python, and Ruby. An independent implementation, also developed and supported by Unidata, is written entirely in Java.