PMIP 2 Variables


 

Variables' lists and definitions

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

How to read the tables

 Name(s)

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 

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 

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

Axes 

The axes or dimensions over which the variable is defined.

Example: XYT

Frequency 

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.

Symbols used in the Frequency columns

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:

DB 

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.

Project AMIP GLASS IPCC PMIP PRISM
Initial(s) An G Table # P PR

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

Estimated storage space

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


Home Top Site Map @ Last updated \2008/05/09 12:40:56