netCDF

netCDF (Network Common Data Form) stores multidimensional arrays together with the metadata describing them, in one file, in a form that does not depend on the machine that wrote it. It is the default container for gridded climate and atmospheric data, and it is the reason a model output file from an unfamiliar group can be opened and largely understood without correspondence.

The property that earns it that role is being self-describing. A netCDF file carries its own dimensions, variable names, units, coordinate values, and arbitrary attributes. Opening one tells you what the array axes mean, what units the values are in, and where the grid points sit. A raw binary file plus a README tells you what the README’s author remembered to write down, which after five years is generally less than needed.

The data model, briefly

Dimensions define array shapes. Variables carry data over those dimensions. Attributes attach metadata to variables or to the file. Coordinate variables — a variable whose name matches a dimension — supply the actual axis values, so latitude is not just an index but a set of degrees.

That last piece is what makes the format usable rather than merely structured, and it is also where the format stops. netCDF specifies how to attach metadata, not what to attach. Nothing in the format requires a variable to have units, or requires those units to be interpretable. That is left to conventions layered on top — CF conventions most importantly, and community profiles like ATMODAT and the UC2 data standard on top of that.

The practical consequence is worth stating clearly: “it is netCDF” is a statement about the container, not about interoperability. A CF-compliant file and a file with variables named var1 through var9 are both valid netCDF. Most real interoperability problems live in this gap.

Versions, and the one thing that bites

netCDF-3 (classic) is simple, widely supported, and limited — no compression, no groups, restricted types, and awkward beyond certain file sizes. netCDF-4 is built on HDF5 and adds compression, chunking, groups, and unlimited dimensions.

The trap is that netCDF-4 files are not readable by netCDF-3-only software, and some older tooling still is. PALM-4U writes netCDF-3, which is a real constraint on downstream handling rather than a detail. It is worth knowing which version a workflow produces before discovering it at the point of exchange.

Compression and chunking in netCDF-4 deserve more attention than they usually get. Chunk layout determines read performance dramatically — a file chunked for time-series access is slow for map access and vice versa — and the default is frequently wrong for the access pattern that matters. This is one of the more common reasons analysis feels inexplicably slow, and it motivates alternatives like Zarr for cloud-based access.

See also: CF conventions for the semantic layer, CDL for the text representation, climate data generally, and metadata.