Availability: ncbo, ncea, ncecat,
ncflint, ncpdq, ncra, ncwa Short options: None |
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 here. 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 applies special rules to certain variables in CF files. The special functions are not required by the CF netCDF conventions, yet experience shows that they simplify data analysis.
Currently, NCO determines whether a datafile is a
CF output datafile simply by checking (case-insensitively)
whether the value of the global attribute Conventions
(if any)
equals ‘CF-1.0’ or ‘NCAR-CSM’
Should Conventions
equal either of these in the (first)
input-file, NCO will apply special rules to certain
variables because of their usual 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 size and rank-preserving arithmetic operators try
not to operate on certain grid properties.
These operators are ncap, ncbo, ncea,
ncflint, and ncpdq (when used for packing, not for
permutation).
These operators do not operate, by default, on (i.e., add, subtract,
pack, 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.
As of NCO version 4.0.8 (April, 2011), NCO
supports the CF bounds
convention for cell boundaries
described
here.
This convention allows coordinate variables
(including multidimensional coordinates) to describe the boundaries of
their cells.
This is done by naming the variable which contains the bounds in
in the bounds
attribute.
Note that coordinates of rank N have bounds of rank N+1.
NCO-generated subsets of CF-compliant files with bounds
attributes will include the coordinates specified by the bounds
attribute, if any.
Hence the subsets will themselves be CF-compliant.
As of NCO version 3.9.6 (January, 2009), 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.
[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.