|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
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.
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
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...).