Usage¶
Syntax¶
The cdo cmor operator requires at least one parameter and one argument. The parameter corresponds to
the MIP-table which contains the requested variables and the argument is the input file infile. Both files
can be specified as relative or absolute path. In contrast to many other operators, the outfile name can
not be specified because it is always generated by CMOR according to the project standard. The general
syntax of the operator is:
cdo cmor,MIP-table[,keyvaluelist] infile
The MIP-table always has to be the first parameter of cdo cmor. A second parameter can be specified
and corresponds to a comma separated keyvaluelist. This list consists of keyword=values pairs with the
format: word=string where the values can be specified as a comma-separated list:
key=value[,value,...][,key=value[,value,...]]
The position of configurable keywords in the list does not matter. Note that for some keywords only one
value is allowed. Every keyword is assigned to a short name which is composed of the first character of
the keyword and, if available, the first character after ’_’. For example, the corresponding shortname
for keyword cmor_name is cn.
MIP-table¶
The data request of CMIP-like projects is formulated in MIP-tables. These tables contain the MIP Data
standard in a CMOR-readable format including variable names, variable attributes and required dimen-
sions. In CMIP phases up to CMIP6, these MIP-tables are subdivided by the frequency of the variables.
E.g., if monthly aggregated data should be processed, the name of a corresponding MIP-table contains
’mon’ for monthly. CMOR uses these MIP-tables to check the infile data and rewrites it.
A CMOR variable is the unique combination of a MIP-table and a cmor name. Thus, the same cmor name
can occur in different MIP-tables because it can have different requirements for a different frequency. It is
essential to know for the use which one one likes to process.
Why no outfile specification?¶
The output file as well as its name and its path are created by CMOR. Name and path are constructed
using a subset of meta data which well-defines the data. This subset is called Data Reference Syntax
(DRS).
For both, name and path, DRS elements are arranged according to a template defined for each project. Two
keywords are available to control and modify the output generation: drs determines whether a directory
structure according to the Data Reference Syntax (DRS) is built and drs root defines in which path.
Note that the build-rules of the CMIP6 standard for constructing outfile name and path are different from
those of CMIP5. CMIP5 uses the CMOR2 template, CMIP6 changed some attribute names and added
some attributes to the CMIP5 templates. All templates are given in the next passage.
CMOR version 2 sets the file names and paths according to the CMIP5 build-rules. These can not be
changed by the user and, therefore, if CMOR version 2 is used to rewrite data according to a standard
different from that of CMIP5, a renaming of the ouput paths and files is necessary.
The output file template:
<variable_id><table_id><model_id><experiment_id><member>
and the output path template:
<activity_id><product><institude_id><model_id><experiment_id> <frequency><realm><variable_id><member>.
CMOR version 3 allows the user to specify the build rules for output file names. The defaults are those of
The output file template:
<variable_id><table_id><source_id><experiment_id><variant_label><grid_label>
The output path template:
<mip_era><activity_id><institution_id><source_id><experiment_id> <variant_label><table_id><variable_id><grid_label><version>.