Model | Coordinator(s) | Updated |
---|---|---|
Atmosphere | Paul Valdes / BRIDGE | 03/10/2005 |
Ocean | Olivier Marti / LSCE | 03/14/2005 |
Land-surface and Vegetation | Nathalie de Noblet / LSCE | 03/10/2005 |
Ice | Thierry Fichefet / UCL-ASTR | 03/10/2005 |
There are two lines, for the tables that have been updated (if you have doubts or questions, get in touch with the webmaster and the coordinator of the current group of variables):
Example: tos (output name) and
sea_surface_temperature (standard name)
Note that when the name or the standard name of a PMIP 2 variable are not already defined in the IPCC and/or
the CF tables, they are surrounded by braces
([new_var] or
[new_standard_name]).
Example: [sos] in the case of ocean surface
salinity
The variable names have been chosen to be the same as the IPCC
variable names, or as close as possible. They were chosen in a
consistent way (following the AMIP
naming convention), so that related variables are grouped together
when sorted alphabetically.
Units of the variable.
Units should be written as a product of IS units, where each
sub-unit is immediately followed by its exponent (when different from
1). Individual terms (unit followed by its exponent) should be
separated by spaces (no '.', '*', 'x' or 'X' multiply
sign!). Dimensionless variables should be specified as having unit 1
(integer number one) or the multiplying factor that has been applied
to the variable before storing it.
Example: use K s-1, not C/s or
°C.s-1.
Note: sign conventions are specified in the Description
field below.
Description of the variable, including the sign convention, when
required.
Example: Vertical current velocity (+ up)
Note: we will probably provide somewhere a list of accepted values'
range for testing purpose (basic units and sign testing).
The axes or dimensions over which the variable is defined.
Example: XYT
Frequency chosen to save the variable. The frequencies are listed
in expected decreasing storage space required in the database (though
this also depends on the actual number of years saved).
A circle (O) or some other more appropriate symbol (for 3D variables and zonal
means) in a frequency column means that a given variable is required
at this frequency.
Note: for obvious storing space problems reasons, most variables will only be stored at the SE frequency! You can read the note about estimated storage space below for more details.
A blank space in a given frequency column means that the current
variable will not be stored in the PMIP 2 database.
If a variable has to be stored in the database, we use a symbol that
depends on the axes (longitude, latitude and level) on which
the variable is defined:
International project (or database) where this variable has already been defined and studied. When possible, we will try to use the names and conventions that have already been defined in the projects listed below.
In the case of IPCC, we give the name of the table where the
variable can be found (and the number of the variable in the table),
in the IPCC
Standard Output from Coupled Ocean-Atmosphere GCMs
document.
Example: O1e2 is thetao, the 2nd variable
of table 01e
The tables in the variables' lists give a rough estimation of the
storage space that will be required per model and per
run. The estimation is based on a T42 (128*64) horizontal grid
for the atmosphere (with the 17 WMO pressure levels, or a subset of
WMO), vegetation and land-surface variables (with 20 vegetation
levels and 5 soil depth levels) and a 240*120
horizontal grid for the ocean variables (with 25 depth levels) and the
ice variables. Each data point is stored in a 4-byte real, and we
don't count the extra space required by the metadata (names, units,
axes, ...) in the netCDF files.
Requirements for the daily variables are based on 360-day years.
The expected size of the database, for 15 models and 6 runs per model,
and 100-200 years of run (50-100 for daily values) is 1.5 Tb (yes,
that is indeed Tb, and 1 Terabyte = 1024 Gigabytes...).