Next: , Previous: File List Attributes, Up: Common features


3.30 CF Conventions

Availability: ncbo, ncea, ncecat, ncflint, ncra, ncwa
Short options: None
NCO recognizes the Climate and Forecast (CF) metadata conventions, and treats such data (often called history tapes), specially. NCO handles older NCAR model datasets, such as CCM and early CCSM datasets, with its CF rules even though the earlier data may not contain an explicit Conventions attribute (e.g., ‘CF-1.0’). We refer to all such data collectively as CF data. Skip this section if you never work with CF data.

The CF netCDF conventions are described at http://www.cgd.ucar.edu/cms/eaton/cf-metadata/CF-1.0.html. Most CF netCDF conventions are transparent to NCO 1. There are no known pitfalls associated with using any NCO operator on files adhering to these conventions 2. However, to facilitate maximum user friendliness, NCO does treat certain variables in some CF files specially. The special functions are not required by the CF netCDF conventions, but experience shows they simplify data analysis.

Currently, NCO determines whether a datafile is a CF output datafile simply by checking whether value of the global attribute Conventions (if it exists) equals ‘CF-1.0’ or ‘NCAR-CSM’. Should Conventions equal either of these in the (first) input-file, NCO will attempt to treat certain variables specially, because of their meaning in CF files. NCO will not average the following variables often found in CF files: ntrm, ntrn, ntrk, ndbase, nsbase, nbdate, nbsec, mdt, mhisf. These variables contain scalar metadata such as the resolution of the host geophysical model and it makes no sense to change their values.

Furthermore, the ncbo operator does not operate on (i.e., add, subtract, etc.) the following variables: ORO, area, datesec, date, gw, hyai, hyam, hybi. hybm, lat_bnds, lon_bnds, msk_*. These variables represent the Gaussian weights, the orography field, time fields, hybrid pressure coefficients, and latititude/longitude boundaries. We call these fields non-coordinate grid properties. Coordinate grid properties are easy to identify because they are coordinate variables such as latitude and longitude.

Users usually want all grid properties to remain unaltered in the output file. To be treated as a grid property, the variable name must exactly match a name in the above list, or be a coordinate variable. The handling of msk_* is exceptional in that any variable name beginning with the string msk_ is considered to be a “mask” and is thus preserved (not operated on arithmetically).

You must spoof NCO if you would like any grid properties or other special CF fields processed normally. For example rename the variables first with ncrename, or alter the Conventions attribute.

NCO supports the CF coordinates convention described here. This convention allows variables to specify additional coordinates (including multidimensional coordinates) in a space-separated string attribute named coordinates. NCO attaches any such coordinates to the extraction list along with variable and its usual (one-dimensional) coordinates, if any. These auxiliary coordinates are subject to the user-specified overrides described in Subsetting Coordinate Variables.


Footnotes

[1] The exception is appending/altering the attributes x_op, y_op, z_op, and t_op for variables which have been averaged across space and time dimensions. This feature is scheduled for future inclusion in NCO.

[2] The CF conventions recommend time be stored in the format time since base_time, e.g., the units attribute of time might be ‘days since 1992-10-8 15:15:42.5 -6:00’. A problem with this format occurs when using ncrcat to concatenate multiple files together, each with a different base_time. That is, any time values from files following the first file to be concatenated should be corrected to the base_time offset specified in the units attribute of time from the first file. The analogous problem has been fixed in ARM files (see ARM Conventions) and could be fixed for CF files if there is sufficient lobbying.