Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Introduction

 

Global attributes

 

During these first stages of the proof-of-concept phase of C3S seasonal forecast activity, we have been working to define a  standard for the data provision in netCDF. This standard is described below.

The proposal is constrained by the CF convention, and we also tried not to diverge from specifications coming from other well established communities: SPECS and CMIP5/6

Additionally ACDD has been also taken into account when defining the data discovery related metadata.

Hence, the following links are valuable sources of information that have informed the definition of this proposal:

CF convention

CF convention standard names tables

SPECS file content and format, data structure and metadata

CMIP5 list of variables

CMIP6 Data Request: MIP variables search

ACDD convention

Examples

Some example files have been created following the guidelines contained in this document.

 

View file
namencfiles.tgz
height150

Encoding Guide for netCDF files conforming to C3S-0.1

Global attributes

The following properties are intended to provide information about where the data came from and what has been done to it. This information is mainly for the benefit of human readers and data discovery mechanisms. The attribute values are all character strings. When an attribute appears both globally and as a variable attribute, it is the variable’s version which has precedence.


Attribute NameValueExamplesCommentConventionsCF convention string  [Other convention] :..."CF-1.6"
"CF-1.6 C3S-0.1"

Multiple conventions may be included (separated by blank spaces)

title

CF: Free text

ACDD (highly recommended)

C3S: A controlled vocabulary will be provided

"IPSL-CM5A-LR model output prepared for CMIP5 RCP4.5"referencesCF: Free text
C3S: A valid doi is recommended"doi:10.5194/gmd-8-1509-2015"

references to more information

Antonio S. Cofino Gonzalez: Published or web-based references that describe the data or methods used to produce it. This attribute is recommended in the CF conventions.

Recommend values are URIs (such as a URL or DOI) for papers or other references.
The validity of the doi values will be checked. Warnings will be raised for any other content.

sourceFree text
  • "model-generated, GloSea5-GC2"
  • "IPSL-CM5A-LR (2010) : atmos : LMDZ4 (LMDZ4_v5, 96x95x39); ocean : ORCA2 (NEMOV2_3, 2x2L31); seaIce : LIM2 (NEMOV2_3); ocnBgchem : PISCES (NEMOV2_3); land : ORCHIDEE (orchidee_1_9_4_AR5)"

Where the data is from

Antonio S. Cofino Gonzalez: The method of production of the original data. If it was model-generated, source should name the model and its version. If it is observational, source should characterize it. This attribute is defined in the CF Conventions. Examples: 'temperature from CTD #1234'; 'world model v.0.1'.

Francisco Doblas-Reyes I'm still missing information about the initialisation: what set of initial conditions was used, whether perturbations were used, etc

Eduardo Penabad: Can you (Francisco Doblas-Reyes) suggest how to do this?

institution

CF: Free text

C3S: A controlled vocabulary will be provided

"Met Office"

Francisco Doblas-Reyes I'm not convinced "Met Office" is descriptive enough. Shouldn't it be something like "C3S"?

Unknown User (brookshaw): "institution" is the origin of the data. Things like C3S will be specified elsewhere (e.g. project)

Who produced the data

Antonio S. Cofino Gonzalez: The name of the institution principally responsible for originating this data.
This attribute is recommended by the CF convention.

contact

CF: Free text

C3S: Copernicus User Support URI should be used
http://copernicus-support.ecmwf.int

 

"http://copernicus-support.ecmwf.int"

Antonio S. Cofino Gonzalez: The CMIP5/SPECS DRS define this attribute. The ACDD defines: creator_name, creator_email, creator_url, publisher_name, publisher_email, publisher_url

project

CF: Free text

C3S: "C3S Seasonal Forecast" is required, additional project info (e.g. ITT details) is optional

"C3S Seasonal Forecast"

Antonio S. Cofino Gonzalez: The name of the project(s) principally responsible for originating this data. Multiple projects can be separated by commas, as described under Attribute Content Guidelines. Examples: 'PATMOS-X', 'Extended Continental Shelf Project'.

creation_date

SPECS: YYYY-MM-DDThh:mm:ss<zone>

NOTE: This is ISO 8601:2004 extended format

"2011-06-24T02:53:46Z"

Antonio S. Cofino Gonzalez: The date on which this version of the data was created. (Modification of values implies a new version, hence this would be assigned the date of the most recent values modification.) Metadata changes are not considered when assigning the creation_date. The ISO 8601:2004 extended date format is recommended.  

The ACDD 1.3 names this attribute as date_create
SPECS conventions will be followed
 

commentFree text"This 21th century simulation has been forced by prescribed concentration following the rcp 4.5 scenario."

Antonio S. Cofino Gonzalez: Miscellaneous information about the data, not captured elsewhere. This attribute is defined in the CF Conventions.

forecast_type

C3S: Controlled Vocabulary

"forecast" or "hindcast"

"forecast"To identify the type of datahistoryFree Text
  • "Produced using CDS Toolbox on 1/6/2016"
  • "Model raw output postprocessing with modelling environment (IMDI) at DKRZ: URL: http://svn-mad.zmaw.de/svn/mad/Model/IMDI/trunk, REV: 3436 2011-07-17T15:14:45Z CMOR rewrote data to comply with CF standards and CMIP5 requirements."

To record relevant information, such as the command history which led to this file being produced

Francisco Doblas-Reyes I understand that the versioning of the software used to create the data can be included either here or in the commit attribute. Any idea how/when to make the decision?

 

commit,

iso_lineage or lineage

Free text (ISO Lineage model 19115-2)"Produced using CDS Toolbox v1.0"

trace of the tools/scripts used

Antonio S. Cofino Gonzalez: We need a more implementtios examples on this. This could achiived in EQC WP where metadata is been part of their activities (i.e. WP4@QA4SEAS). ISO 19115-2 defines a linage model where this is been considered. TBD.

summaryACDD (highly recommended): Text, defined phrase
C3S: The content will be provided A short paragraph describing the datasetkeywords

ACDD (highly recommended) : text, controlled vocabulary

C3S: The content will be provided

 A comma separated list of key words and phrases.forecast_reference_time
Attribute NameValueExamplesComment
ConventionsCF_convention_string  C3S-0.1 [Other convention] :..."CF-1.6 C3S-0.1"

Multiple conventions may be included (separated by blank spaces)

title

"<short institution name> seasonal forecast model output prepared for C3S"

CF: Free text

ACDD (highly recommended)

"ECMWF seasonal forecast model output prepared for C3S"
A short phrase or sentence describing the dataset. In many discovery systems, the title will be displayed in the results list from a search, and therefore should be human readable and reasonable to display in a list of such names
<short institution name> is the first element of the comma-separated list of values of the corresponding "institution" attribute
references

URIs (such as a URL or DOI) for papers or other references. A valid doi is recommended

CF: Free text

"doi:10.5194/gmd-8-1509-2015"
Published or web-based references that describe the data or methods used to produce it.
source

The following template should be followed in constructing this string: '<model_id> :  atmosphere: <model_name> (<technical_name>, <resolution_and_levels>); ocean: <model_name> (<technical_name>, <resolution_and_levels>); sea ice: <model_name> (<technical_name>); land: <model_name> (<technical_name>)''

Additional explanatory information may follow the required information.

NOTE that for some models, it may not make much sense to include all these components.

The first portion of the string, “model_id”, should be built using the following template:

"model_name-vYYYYMMDD" where YYYYMMDD is the release date of that version of the model (the date when it was first used)

"System4-v20111101: atmos: IFS (CY36R4, TL255L91); ocean: NEMOv3.0 (ORCA1_z42, 1x1L42); Local modifications in NEMOv3.0 (dynamic memory, flexible output, surface flux forcing, closure of frewsh water budget). FLAKE lake model "

The method of production of the original data. If it was model-generated, source should name the model and its version, as specifically as it could be useful.

It is a character string fully identifying the model and version used to generate the output. It should include information concerning the component models.

Note that information about changes in the individual components respect to the "official" releases should be included (e.g. a different bathymetry)

The "source" attribute should include as much information as possible to not just identify the model but to brief the user about it

institute_id

Controlled Vocabulary:

"ecmf" for ECMWF
"egrr" for Met Office
"lfpw" for Météo-France
"edzw" for DWD
"cmcc" for CMCC

"edzw"Standardized 4 characters identifier of the institution that produced the data;
NOTE all the values come from abbreviations of WMO/GRIB "originating centre" table, except CMCC (not available there)
institution

Controlled Vocabulary:

"ECMWF, European Centre for Medium-Range Weather Forecasts, Reading, United Kingdom"

"Met Office, Exeter, United Kingdom"

"Météo-France, Toulouse, France"

"DWD, Deutscher Wetterdienst, Offenbach, Germany"

"CMCC, Centro Euro-Mediterraneo sui Cambiamenti Climatici, Bologna, Italy"

CF: Free text


"Météo-France, Toulouse, France"

Specifies where the original data was produced. The name of the institution principally responsible for originating this data.

NOTE: The first element of the comma-separated list of values will be used as a shortened version of this attribute in some of the other global attributes ('summary', 'title')

contact

Copernicus User Support URI should be used
http://copernicus-support.ecmwf.int

CF: Free text

"http://copernicus-support.ecmwf.int"


project

"C3S Seasonal Forecast" should be used

CF: Free text


"C3S Seasonal Forecast"
creation_date

SPECS: YYYY-MM-DDThh:mm:

ssZ

ss<zone>

NOTE: This is

ISO 8601:2004 extended format

"2011-06-
01T00
24T02:
00
53:
00Z
46Z"

time of the analysis from which the forecast was made

UTC zone is required

Question: Do we need controlled vocabularies for the above ?

Spatial Coordinates

...

Pa

...

m

...

CMIP5:

2mtemp: 1.
10mu/v: 1.

...

CMIP5:

2mtemp: 10.
10mu/v: 30.

...

can be used for single level (height, soil)

e.g. 2 m (for Temperature)

...

C3S: string

 

ISSUE:

Then, it needs an auxiliary coordinate
(string len)

...

C3S: realization_dim

CF: a different name is needed for dim/variable
(see comment)

...

NOTE:

A dimension named "bounds" is also required for 'extensive' quantities.

Time Coordinates

...

SPECS: days
C3S: requested units can be relaxed to equivalent time units

...

 

...

time

...

SPECS: "days since 1850-01-01"

C3S: requested units can be relaxed to equivalent time units

...

Valid time of data

 

Coordinate Bounds

...

Values

...

dimension bounds = 2

Maybe have "bounds" in a separate table/comment, explaining that they have the same units as the variable "bounded" by them. In addition to that I would find clearer if the time variable value is always at the end of the correspondent time_bounds as this works well both for instantaneous and accumulated/aggregated variables (e.g. time=20160922 06, timebounds = [20160922 00, 20160922 06])

for 24h freqs.

2 values with the same units as "time" coordinate
[0,24]

intervals must represent 24 hours

starting at 0Z
(is this a convention? WMO?)

...

The date on which this version of the data was created. Modification of values implies a new version, hence this would be assigned the date of the most recent values modification. Metadata changes are not considered when assigning the creation_date

NOTE: The ACDD 1.3 names this attribute as "date_create". The name "creation_date" has been used following SPECS convention.

commentFree text
  • "Produced by University of Hamburg for DWD at ECMWF HPC facilities"
  • "Run by CMCC at CINECA"
Miscellaneous information about the data, not captured elsewhere.
forecast_type

Controlled Vocabulary

"forecast" or "hindcast"

"forecast"

To identify the type of data



modeling_realm

Controlled Vocabullary

"atmos", "ocean", "land", "landIce", "seaIce", "aerosol", "atmosChem", "ocnBgchem"

"seaIce"

A string that indicates the high-level modelling component that is particularly relevant to the variable encoded
Controlled vocabulary taken from SPECS


Value depends on the variable (see "global attributes" column in variables tables)

frequency

Controlled Vocabulary

"mon", "day", "12hr", "6hr", "fix"

"day"

A string indicating the interval between individual time-samples.
Controlled vocabulary taken from SPECS (extended to include "12hr" data)

Value depends on the variable (see "global attributes" column in variables tables)

level_type

Controlled Vocabulary

"surface", "pressure", "soil"

"pressure"

A string indicating the type of the level where the variable comes from

Value depends on the variable (see "global attributes" column in variables tables)

historyEmpty string""

To avoid this attribute being polluted by usual netCDF tools, it must be enforced to an empty string.


commit

timestamp + URL of a commit in a CVS repository

"2017-04-01T13:48:25Z https://software.ecmwf.int/stash/projects/C3SS/repos/ecmf/System4_v20111101"

This attribute intends to keep trace of the tools/scripts used to post-process the data output from the model.

Ideally it should contain the link to a repository containing the specific set of tools and scripts needed to reproduce the same data from the model output. It is highly desirable to have that traceability information.

As a surrogate when the previous is not feasible it should include the timestamp followed by an URL pointing to the C3S documentation repository of the correspondent model version (properly labelled with the <model_id> introduced in 'source" attribute)

summary

Controlled Vocabulary:
"Seasonal Forecast data produced by <short institution name> as its contribution to the seasonal forecast activity of the Copernicus Climate Change Service (C3S). The data has global coverage with a 1-degree horizontal resolution and spans for around 6 months since the start date"

ACDD (highly recommended)

"Seasonal Forecast data produced by DWD as its contribution to the seasonal forecast activity of the Copernicus Climate Change Service (C3S). The data has global coverage with a 1-degree horizontal resolution and spans for around 6 months since the start date"

A short paragraph describing the dataset


<short institution name> is the first element of the comma-separated list of values of the corresponding "institution" attribute

keywords

Fixed string

"Seasonal Forecasts, C3S, ECMWF, Copernicus, Climate Change, Climate Services, Earth Science Services, Environmental Advisories, Climate Advisories"

ACDD (highly recommended)


A comma separated list of key words and phrases.

NOTE: This attribute is likely to be modified in the future, once the contents of the Thesaurus for CDS faceting will be defined

forecast_reference_time

SPECS: YYYY-MM-DDThh:mm:ssZ

NOTE: This is ISO 8601:2004 extended format, but time zone is required to be UTC

"2011-06-01T00:00:00Z"

time of the analysis from which the forecast was made


Introduced as global attribute to keep compatibility with SPECS
(note that works fine for SPECS data structure, i.e. one variable per start time per file)

Spatial Coordinates

Type
(CMIP5)
Coordinate Name
(CMIP5)
Dimension Names
(CMIP5)
Axisstandard_namelong_name
(CMIP5)
units
(CF canonical units)
positivevalid_min
(CMIP5)
valid_max
(CMIP5)
boundsNotes
doublelatlatYlatitudelatitudedegrees_northN/A-90.90.lat_bnds

Values (1x1deg grid) prescribed:
center of 1-degree cells
dimension lat=180

[-89.5, -88.5 , ..., -0.5, 0.5 ... 89.5]

doublelonlonXlongitudelongitudedegrees_eastN/A0.360.lon_bndsValues (1x1deg grid) prescribed:
center of 1-degree cells
dimension lon=360

[0.5 , 1.5 , ..., 358.5, 359.5]

doubleplevplevZair_pressurepressure

Pa

downN/AN/A

This is also referred to as isobaric level by some tools
Values prescribed:
dimension plev=11

[925., 850., 700., 500., 400., 300., 200., 100., 50., 30., 10.]
(NOTE: values here written in hPa, they should be Pa)


doubledepthdepthZdepthdepth

m

downN/AN/Adepth_bndsOnly used for soil model levels
NOTE: Number and depth of levels is not prescribed by C3S
doubleheight(scalar auxiliary coordinate)Zheightheightmup or down

CMIP5:

2mtemp: 1.
10mu/v: 1.

CMIP5:

2mtemp: 10.
10mu/v: 30.


Used for single level fields (height, soil,SST)

e.g. 2 m (for Temperature)

C3S: string


 realizationstr31=31


E realizationrealization1N/AN/AN/A

members are not a physical quantity. Realization is a discrete coordinate and the members its categorical values (ordered or non-ordered ones)

SPECS approach: rXXiYYpZZ

NOTE about the horizontal coordinates: The regridding procedure to provide the data in the 1-degree grid must take into account that the full definition of the gird cells is given by the cell boundaries (lat_bnds, lon_bnds)

Time Coordinates

TypeCoordinate NameDimension NamesAxisstandard_namelong_namecalendarunitsboundsNotes
doublereftimeN/AN/Aforecast_reference_time"Start date of the forecast"gregorianUDUNITS time units
e.g.
"hours since YYYY-MM-DD hh:mm:ss TZhh:TZmm"
N/AIn SPECS it is only given as a "global_attribute"
It has been additionally introduced here as a coordinate variable to ease future netCDF management (e.g. file merging)
doubleleadtimeleadtimeN/Aforecast_period"Time elapsed since the start of the forecast"N/A

SPECS: days
C3S: requested units can be relaxed to equivalent time units

leadtime_bnds

The interval of time between the forecast reference time and the valid time

Boundaries not needed when this time coordinate is used for instantaneous values (note that "time:point" is used as cell_method in those cases)

When boundaries are required, the value of the coordinate must be in the centre of the correspondent time cell boundaries

doubletimeleadtimeN/A

time

"Verification time of the forecast"gregorian

SPECS: "days since 1850-01-01"

C3S: requested units can be relaxed to equivalent time units

time_bnds

Time for which the forecast is valid

Boundaries not needed when this time coordinate is used for instantaneous values (note that "time:point" is used as cell_method in those cases)

When boundaries are required, the value of the coordinate must be in the centre of the correspondent time cell boundaries


NOTE: Definitions for "leadtime" and "time" have been taken from SPECS. The introduction of "reftime" as a variable has been adapted from SPECS global attribute description for the forecast reference time.

NOTE: Even though there are different requested time steps among the variables (6h, 12h, 24h), just one set of time axes has been defined, as that would be enough when applying the requirement of "one variable per file"

 

Warning

"leadtime" has been selected as dimension (instead of "time") for both time and leadtime. That means "leadtime" is the coordinate and "time" is an auxiliary coordinate

  • This diverges from SPECS (where "time" was the name of the dimension and the coordinate, and "leadtime" was an auxiliary coordinate)
  • Here it has been done like that because
    1. both reftime and leadtime are the relevant (let's say "orthogonal") coordinates coming from the relationship time = reftime + leadtime
    2. doing like that has some advantages when merging netCDF files ("leadtime" can be easily shared by different variables in a merged file, while "time" cannot)


Cell boundaries

 As described in section 7.1 Cell Boundaries of CF convention.

Info

To represent cells we add the attribute bounds to the appropriate coordinate variable(s). The value of bounds is the name of the variable that contains the vertices of the cell boundaries. We refer to this type of variable as a "boundary variable." A boundary variable will have one more dimension than its associated coordinate or auxiliary coordinate variable. The additional dimension should be the most rapidly varying one, and its size is the maximum number of cell vertices. Since a boundary variable is considered to be part of a coordinate variable’s metadata, it is not necessary to provide it with attributes such as long_name and units


Bounds NameDimensionsComments
time_bndsleadtime, bnds
leadtime_bnds
lat_bndslat, bndsValues (1x1deg grid) prescribed:
[-90., -89.], [-89., -88.], ... [89., 90.]
lon_bndslon, bnds

Values (1x1deg grid) prescribed:

[0., 1.], [1., 2.], ... [359., 360.]

depth_bndsdepth, bndsShould define the full vertical extent of the soil model layers

Grid mapping

 

Info

As described in section 5.6 Grid Mappings and Projections of CF convention. (see quote below)

When the coordinate variables for a horizontal grid are longitude and latitude, a grid mapping variable with "grid_mapping_name" of "latitude_longitude" may be used to specify the ellipsoid and prime meridian.

Following that, it has been decided to include, as mandatory, in this C3S netcdf encoding guide the following variable

Code Block
char hcrs ;
    hcrs:grid_mapping_name = "latitude_longitude" ;

Variables

Common attributes

The following attributes must be included in all the variables:

attribute
name
valuecomment
grid_mappinghcrs

Conditional attributes

The following attributes may be included in the attribute list for a given variable if the conditions specified are fulfilled:

attribute namevaluecomment
_FillValueSet by netCDF libraryThose attributes must be included ONLY when the variable has missing values.
If they are NOT present in the actual data field values, they should NOT be included as variable attributes.
missing_valueSet by netCDF library

Candidate attributes

The following attributes may be included in the attribute list for a given variable at a later date as this standard evolves:

 attribute namevaluecomment
valid_maxTBD see below
valid_minTBDsee below


Info
titlevalid range attributes

Both "valid_min" and "valid_max" attributes should be included as variable attributes, but a set of sensible values for each and every variable needs to be provided.

In the meantime, it is proposed not to include them and just bear in mind that they will be required to be introduced at some point in the future.


Static Fields



attributes
name
(CMIP5)
dimensionsstandard_namelong_name
(CMIP5)
unitscoordinatesvalid_minvalid_maxglobal attributes
sftlflat,lonland_area_fraction"Land Area Fraction"1

"lat lon"



01

"frequency":"fix"
"level_type": "surface"
"modeling_realm":"atmos"

oroglat,lonsurface_altitude"Surface Altitude"m"lat lon"

"frequency":"fix"
"level_type": "surface"
"modeling_realm":"atmos"

Surface Fields (defined at a given height level)



attributes

name
(CMIP5/6&C3S)
dimensionsstandard_namelong_name
(CMIP5/6&C3S)
unitscoordinatescell_methodsvalid_minvalid_maxglobal attributesNOTES
tasleadtime,lat,lonair_temperature"Near-Surface Air Temperature"K

"reftime realization time leadtime height lat lon"



"leadtime: point"

C3S: required 
CF:
recommended




 "frequency":"6hr"
"level_type": "surface"
"modeling_realm":"atmos"

height is usually 2m

height:valid_min = 1.;
height:valid_max = 10. ;

 

 

tasmaxleadtime,lat,lonair_temperature"Daily Maximum Near-Surface Air Temperature"K

"reftime realization time leadtime height lat lon"

"leadtime: maximum (interval: <value> <unit>)"

C3S: interval is required.
CF:
interval is optional
 



"frequency":"day"
"level_type": "surface"
"modeling_realm":"atmos"

height is usually 2m

height:valid_min = 1.;
height:valid_max = 10. ;

C3S: The interval is required to have a value<=3 hours)

leadtime_bnds, time_bnds are required

tasminleadtime,lat,lonair_temperature"Daily Minimum Near-Surface Air Temperature"K

"reftime realization time leadtime height lat lon"

"leadtime: minimum (interval: <value> <unit>)"

C3S: interval is required.
CF:
interval is optional



"frequency":"day"
"level_type": "surface"
"modeling_realm":"atmos"

height is usually 2m

height:valid_min = 1.;
height:valid_max = 10. ;

C3S: The interval is required to have a value<=3 hours)

leadtime_bnds, time_bnds are required

tdpsleadtime,lat,londew_point_temperature"2m Dewpoint Temperature"K"reftime realization time leadtime height lat lon""leadtime: point"

C3S: required 
CF:
recommended



"frequency":"6hr"
"level_type": "surface"
"modeling_realm":"atmos"

height is usually 2m

height:valid_min = 1.;
height:valid_max = 10. ;

 
uasleadtime,lat,lonx_windEastward Near-Surface Windm s-1"reftime realization time leadtime height lat lon""leadtime: point"

C3S: required 
CF:
recommended



"frequency":"6hr"
"level_type": "surface"
"modeling_realm":"atmos"

height is usually 10m


height:valid_min = 1.;
height:valid_max = 30. ;

vasleadtime,lat,lony_windNorthward Near-Surface Windm s-1"reftime realization time leadtime height lat lon""leadtime: point"

C3S: required 
CF:
recommended



"frequency":"6hr"
"level_type": "surface"
"modeling_realm":"atmos"

height is usually 10m 

height:valid_min = 1.;
height:valid_max = 30. ;

 

wsgmax


N/A in CMIP

leadtime,lat,lonwind_speed_of_gust

"Maximum Wind Speed of Gust"


N/A in CMIP

m s-1"reftime realization time leadtime height lat lon" "leadtime: maximum (interval: <value> <unit>)"
C3S: interval is required.
CF:
interval is optional
 



"frequency":"day"
"level_type": "surface"
"modeling_realm":"atmos"

height is usually 10m 

height:valid_min = 1.;
height:valid_max = 30. ;

 

C3S: The interval is required to have a value<=3 hours)

leadtime_bnds, time_bnds are required


Surface Fields (not defined at a height level)



attributes

name
(CMIP5/6&C3S)
dimensionsstandard_namelong_name
(CMIP5/6&C3S)
unitscoordinatescell_methodsvalid_minvalid_maxglobal attributesComments
pslleadtime,lat,lonair_pressure_at_sea_level"Sea Level Pressure"Pa"reftime realization time leadtime lat lon""leadtime: point"

C3S: required 
CF:
recommended



"frequency":"6hr"
"level_type": "surface"
"modeling_realm":"atmos"

cltleadtime,lat,loncloud_area_fraction"Total Cloud Fraction"1"reftime realization time leadtime lat lon""leadtime: point"

C3S: required 
CF:
recommended



"frequency":"6hr"
"level_type": "surface"
"modeling_realm":"atmos"

tslleadtime,lat,lonsoil_temperature"Temperature of Soil"K"reftime realization time leadtime lat lon""leadtime: point"

C3S: required 
CF:
recommended



"frequency":"6hr"
"level_type": "surface"
"modeling_realm":"land"


tsoleadtime,lat,lonsea_surface_temperature"Sea Surface Temperature"K"reftime realization time leadtime lat lon""leadtime: point"

C3S: required 
CF:
recommended



"frequency":"6hr"
"level_type": "surface"
"modeling_realm":"ocean"

sitemptop


N/A in CMIP

leadtime,lat,lonsea_ice_temperature

"Surface Temperature of Sea Ice"

N/A in CMIP

K"reftime realization time leadtime lat lon""leadtime: point"

C3S: required 
CF:
recommended



"frequency":"6hr"
"level_type": "surface"
"modeling_realm":"seaIce"

sicleadtime,lat,lonsea_ice_area_fraction"Sea Ice Area Fraction"1"reftime realization time leadtime lat lon""leadtime: point"

C3S: required 
CF:
recommended



"frequency":"day"
"level_type": "surface"
"modeling_realm":"seaIce"

mrlsl


leadtime,depth,lat,lonmoisture_content_of_soil_layer

"Water Content per Unit Area of Soil Layers"


kg m-2"reftime realization time leadtime depth lat lon""leadtime: point"

C3S: required 
CF:
recommended



"frequency":"day"
"level_type": "soil"
"modeling_realm":"land"

lwesnw


N/A in CMIP

leadtime,lat,lonlwe_thickness_of_surface_snow_amount

"Liquid Water Equivalent Thickness of Surface Snow Amount"

N/A in CMIP

m"reftime realization time leadtime lat lon""leadtime: point"

C3S: required 
CF:
recommended



"frequency":"day"
"level_type": "surface"
"modeling_realm":"land"

rhosn


N/A in CMIP

leadtime,lat,lonsnow_density

"Snow Density"


N/A in CMIP

kg m-3"reftime realization time leadtime lat lon""leadtime: point"

C3S: required 
CF:
recommended



"frequency":"day"
"level_type": "surface"
"modeling_realm":"land"

lweprs


N/A in CMIP

leadtime,lat,lonlwe_thickness_of_stratiform_precipitation_amount"Liquid Water Equivalent Thickness of Stratiform Precipitation Amount"


N/A in CMIP

m"reftime realization time leadtime lat lon""leadtime: sum"

 


"frequency":"day"
"level_type": "surface"
"modeling_realm":"atmos"

leadtime_bnds, time_bnds are required

lweprc


N/A in CMIP

leadtime,lat,lonlwe_thickness_of_convective_precipitation_amount"Liquid Water Equivalent Thickness of Convective Precipitation Amount"


N/A in CMIP

m"reftime realization time leadtime lat lon""leadtime: sum"

 


"frequency":"day"
"level_type": "surface"
"modeling_realm":"atmos"

leadtime_bnds, time_bnds are required

lwepr


N/A in CMIP

leadtime,lat,lonlwe_thickness_of_precipitation_amount"Liquid Water Equivalent Thickness of Total Precipitation Amount"


N/A in CMIP

m"reftime realization time leadtime lat lon""leadtime: sum"

   


"frequency":"day"
"level_type": "surface"
"modeling_realm":"atmos"

leadtime_bnds, time_bnds are required

lweprsn


N/A in CMIP

leadtime,lat,lonlwe_thickness_of_snowfall_amount"Liquid Water Equivalent Thickness of Snowfall Amount"


N/A in CMIP

m"reftime realization time leadtime lat lon""leadtime: sum"

 


"frequency":"day"
"level_type": "surface"
"modeling_realm":"atmos"

leadtime_bnds, time_bnds are required

hfssleadtime,lat,lonsurface_upward_sensible_heat_flux"Surface Upward Sensible Heat Flux"W m-2"reftime realization time leadtime lat lon""leadtime: mean (interval: <value> <unit>)"
C3S: interval is required.
CF:
interval is optional


"frequency":"day"
"level_type": "surface"
"modeling_realm":"atmos"

leadtime_bnds, time_bnds are required

hflsleadtime,lat,lonsurface_upward_latent_heat_flux"Surface Upward Latent Heat Flux"W m-2"reftime realization time leadtime lat lon""leadtime: mean (interval: <value> <unit>)"
C3S: interval is required.
CF:
interval is optional


"frequency":"day"
"level_type": "surface"
"modeling_realm":"atmos"

leadtime_bnds, time_bnds are required

rsdsleadtime,lat,lonsurface_downwelling_shortwave_flux_in_air"Surface Downwelling Shortwave Radiation"W m-2"reftime realization time leadtime lat lon""leadtime: mean (interval: <value> <unit>)"
C3S: interval is required.
CF:
interval is optional


"frequency":"day"
"level_type": "surface"
"modeling_realm":"atmos"

leadtime_bnds, time_bnds are required

rldsleadtime,lat,lonsurface_downwelling_longwave_flux_in_air"Surface Downwelling Longwave Radiation"W m-2"reftime realization time leadtime lat lon""leadtime: mean (interval: <value> <unit>)"
C3S: interval is required.
CF:
interval is optional


"frequency":"day"
"level_type": "surface"
"modeling_realm":"atmos"

leadtime_bnds, time_bnds are required

rssleadtime,lat,lonsurface_net_downward_shortwave_flux"Net Shortwave Surface Radiation"W m-2"reftime realization time leadtime lat lon""leadtime: mean (interval: <value> <unit>)"
C3S: interval is required.
CF:
interval is optional


"frequency":"day"
"level_type": "surface"
"modeling_realm":"atmos"

leadtime_bnds, time_bnds are required

rlsleadtime,lat,lonsurface_net_downward_longwave_flux"Net Longwave Surface Radiation"W m-2"reftime realization time leadtime lat lon""leadtime: mean (interval: <value> <unit>)"
C3S: interval is required.
CF:
interval is optional


"frequency":"day"
"level_type": "surface"
"modeling_realm":"atmos"

leadtime_bnds, time_bnds are required

rst


N/A in CMIP

leadtime,lat,lontoa_net_downward_shortwave_flux

"TOA Net Shortwave Radiation"

N/A in CMIP

W m-2"reftime realization time leadtime lat lon""leadtime: mean (interval: <value> <unit>)"
C3S: interval is required.
CF:
interval is optional


"frequency":"day"
"level_type": "surface"
"modeling_realm":"atmos"

leadtime_bnds, time_bnds are required

rlt


N/A in CMIP

leadtime,lat,lontoa_net_downward_longwave_flux

"TOA Net Longwave Radiation"

N/A in CMIP

W m-2"reftime realization time leadtime lat lon""leadtime: mean (interval: <value> <unit>)"
C3S: interval is r equired.
CF:
interval is optional


"frequency":"day"
"level_type": "surface"
"modeling_realm":"atmos"

leadtime_bnds, time_bnds are required

rsdtleadtime,lat,lontoa_incoming_shortwave_flux"TOA Incident Shortwave Radiation"W m-2"reftime realization time leadtime lat lon""leadtime: mean (interval: <value> <unit>)"
C3S: interval is required.
CF:
interval is optional


"frequency":"day"
"level_type": "surface"
"modeling_realm":"atmos"

leadtime_bnds, time_bnds are required

tauuleadtime,lat,lonsurface_downward_eastward_stress"Surface Downward Eastward Wind Stress"Pa"reftime realization time leadtime lat lon""leadtime: mean (interval: <value> <unit>)"
C3S: interval is required.
CF:
interval is optional


"frequency":"day"
"level_type": "surface"
"modeling_realm":"atmos"

leadtime_bnds, time_bnds are required

tauvleadtime,lat,lonsurface_downward_northward_stress"Surface Downward Northward Wind Stress"Pa"reftime realization time leadtime lat lon""leadtime: mean (interval: <value> <unit>)"
C3S: interval is required.
CF:
interval is optional


"frequency":"day"
"level_type": "surface"
"modeling_realm":"atmos"

leadtime_bnds, time_bnds are required

lwee


N/A in CMIP

leadtime,lat,lonlwe_thickness_of_water_evaporation_amount

"Liquid Water Equivalent Thickness of Evaporation Amount"

N/A in CMIP

m"reftime realization time leadtime lat lon""leadtime: sum"

 


"frequency":"day"
"level_type": "surface"
"modeling_realm":"land"

leadtime_bnds, time_bnds are required

mrroa

N/A in CMIP

leadtime,lat,lonrunoff_amount

"Total Run-off Amount"

N/A in CMIP

kg m-2"reftime realization time leadtime lat lon""leadtime: sum"

 


"frequency":"day"
"level_type": "surface"
"modeling_realm":"land"

leadtime_bnds, time_bnds are required

mrroas

N/A in CMIP

leadtime,lat,lonsurface_runoff_amount

"Surface Run-off Amount"

N/A in CMIP

kg m-2"reftime realization time leadtime lat lon""leadtime: sum"

 


"frequency":"day"
"level_type": "surface"
"modeling_realm":"land"

leadtime_bnds, time_bnds are required

mrroab

N/A in CMIP

leadtime,lat,lonsubsurface_runoff_amount

"Subsurface Run-off Amount"

N/A in CMIP

kg m-2"reftime realization time leadtime lat lon""leadtime: sum"

 


"frequency":"day"
"level_type": "surface"
"modeling_realm":"land"

leadtime_bnds, time_bnds are required

Pressure Level Fields



attributes
name
(CMIP5)
dimensionsstandard_namelong_name
(CMIP5)
unitscoordinatescell_methodsvalid_minvalid_maxglobal attributes
zgleadtime,plev,lat,longeopotential_height"Geopotential Height"m"reftime realization time leadtime plev lat lon""leadtime: point"

C3S: required 
CF:
recommended



"frequency":"12hr"
"level_type": "pressure"
"modeling_realm":"atmos"
taleadtime,plev,lat,lonair_temperature"Air Temperature"K"reftime realization time leadtime plev lat lon""leadtime: point"

C3S: required 
CF:
recommended



"frequency":"12hr"
"level_type": "pressure"
"modeling_realm":"atmos"
husleadtime,plev,lat,lonspecific_humidity"Specific Humidity"1"reftime realization time leadtime plev lat lon""leadtime: point"

C3S: required 
CF:
recommended



"frequency":"12hr"
"level_type": "pressure"
"modeling_realm":"atmos"

rv

N/A in CMIP

leadtime,plev,lat,lonatmosphere_relative_vorticity

"Relative Vorticity"

N/A in CMIP

s-1"reftime realization time leadtime plev lat lon""leadtime: point"

C3S: required 
CF:
recommended



"frequency":"12hr"
"level_type": "pressure"
"modeling_realm":"atmos"

wnddiv

N/A in CMIP

leadtime,plev,lat,londivergence_of_wind

"Divergence of Wind"

N/A in CMIP

s-1"reftime realization time leadtime plev lat lon""leadtime: point"

C3S: required 
CF:
recommended



"frequency":"12hr"
"level_type": "pressure"
"modeling_realm":"atmos"
ualeadtime,plev,lat,lonx_wind"Eastward Wind"m s-1"reftime realization time leadtime plev lat lon""leadtime: point"

C3S: required 
CF:
recommended



"frequency":"12hr"
"level_type": "pressure"
"modeling_realm":"atmos"
valeadtime,plev,lat,lony_wind"Northward Wind"m s-1"reftime realization time leadtime plev lat lon""leadtime: point"

C3S: required 
CF:
recommended



"frequency":"12hr"
"level_type": "pressure"
"modeling_realm":"atmos"

Ensemble coordinate

TBD

Pressure level coordinates

These are specified as being:

925, 850, 700, 500, 400, 300, 200, 100, 50, 30 and 10 hPa

Invariant Fields

...

step

...

name

...

land_area_fraction

...

 

Surface Fields (defined at a given height level)

...

Priority

(i.e. should be defined first for MARS)

...

step

...

name

...

Coordinate

Bounds

...

"height"

 

 

...

C3S: Just 2m and 1.5m will be valid values for the height coordinate of this variable

CF: If the variable is instantaneous it shouldn't have time_bounds

...

"time: maximum (interval: value unit)"

CF: interval is optional
C3S: interval is required. (Units in UDUNITS)

...

"height"

...

C3S: Just 2m and 1.5m will be valid values for the height coordinate of this variable

C3S: The interval is required to have a value<=3 hours)

...

"time: maximum (interval: value unit)"

CF: interval is optional
C3S: interval is required. (Units in UDUNITS)

...

"height"

...

C3S: Just 2m and 1.5m will be valid values for the height coordinate of this variable

C3S: The interval is required to have a value<=3 hours)

...

scalar

value=2

unit=m

...

MetOffice's temperatures are at 1.5m

...

6 h

inst

...

scalar

value=10

unit=m

...

6 h

inst

...

scalar

value=10

unit=m

...

scalar

value=10

unit=m

...

 

Surface Fields (not defined at a  height level)

...

step

...

name

...

intervals must represent 6 hours

...

intervals must represent 6 hours

...

intervals must represent 6 hours

...

skin_temperature" doesn't exist as a CF standard_name, so maybe the required one should be "surface_temperature"

...

starting at 0Z (to be agreed)

...

starting at 0Z (to be agreed)

...

To cope with the fact that some providers send instantaneous 00UTC values and some others daily averages, it was agreed as a compromise to request 6h instantaneous SST values (so the value at 00h would be the same for everyone, and a daily average to account for the diurnal cycle could be obtained from the 6h values)

...

lwe_thickness_of_surface_snow_amount

...

starting at 0Z (to be agreed)

...

Note it is snow amount, not snowfall amount.
A check is needed whether this should be an average or an instantaneous value.

...

starting at 0Z (to be agreed)

...

A check is needed whether this should be an average or an instantaneous value

...

starting at 0Z (to be agreed)

...

don't know how the cell_methods could be coded for this variable if it is obtained from ratios of daily accumulations of shortwave radiation.

 

Soil Level Fields

...

step

...

name

...

soil model layer(level)

number

...

intervals must represent 24 hours

starting at 0Z (to be agreed)

...

scalar

value=1

 

...

the number of soil levels shouldn't be prescribed (they will likely differ from model to model) and the vertical coordinate for them should be the height -need bounds- of each layer. In addition, there was an issue with the units, Anca should have the final conclusion about that.

...

starting at 0Z (to be agreed)

...

scalar

value=2

...

starting at 0Z (to be agreed)

...

scalar

value=3

...

starting at 0Z (to be agreed)

...

scalar

value=4

...

starting at 0Z (to be agreed)

...

scalar

value=1

...

Accumulation Fields

...

step

...

name

...

intervals must represent 24 hours

starting at 0Z (to be agreed)

...

is the "interval" is needed in cell_methods with "time: sum"?

...

lwe_thickness_of_snowfall_amount

...

intervals must represent 24 hours

starting at 0Z (to be agreed)

...

surface_upward_sensible_heat_flux

 

-may request integral_of_XXXXX_wrt_time instead (diff units)
NOTE: this one is not in the CF standard names list , but the "downward" version is

...

intervals must represent 24 hours

starting at 0Z (to be agreed)

...

If we are not going to request accumulations since the beginning of the forecast, maybe it is more natural for the providers to send daily averaged values (which affects the standard name -integral_of_XXXXX_wrt_time- and hence the units)

...

surface_upward_latent_heat_flux

-may request integral_of_XXXXX_wrt_time instead (diff units)
NOTE: this one is not in the CF standard names list, but the "downward" version is

...

intervals must represent 24 hours

starting at 0Z (to be agreed)

...

surface_downwelling_shortwave_flux_in_air

-may request integral_of_XXXXX_wrt_time instead (diff units)

...

intervals must represent 24 hours

starting at 0Z (to be agreed)

...

surface_downwelling_longwave_flux

-may request integral_of_XXXXX_wrt_time instead (diff units)

 

...

intervals must represent 24 hours

starting at 0Z (to be agreed)

...

surface_net_downward_shortwave_flux

-may request integral_of_XXXXX_wrt_time instead (diff units)

 

...

intervals must represent 24 hours

starting at 0Z (to be agreed)

...

surface_net_downward_longwave_flux

...

intervals must represent 24 hours

starting at 0Z (to be agreed)

...

toa_incoming_shortwave_flux

-may request integral_of_XXXXX_wrt_time instead (diff units)
NOTE: this one is not in the CF standard names list

...

intervals must represent 24 hours

starting at 0Z (to be agreed)

...

toa_outgoing_longwave_flux

-may request integral_of_XXXXX_wrt_time instead (diff units)

...

intervals must represent 24 hours

starting at 0Z (to be agreed)

...

surface_downward_eastward_stress

-may request integral_of_XXXXX_wrt_time instead (diff units)

...

intervals must represent 24 hours

starting at 0Z (to be agreed)

...

surface_downward_northward_stress

-may request integral_of_XXXXX_wrt_time instead (diff units)

...

 

intervals must represent 24 hours

starting at 0Z (to be agreed)

...

lwe_thickness_of_water_evaporation_amount

...

starting at 0Z (to be agreed)

...

starting at 0Z (to be agreed)

...

 

...

starting at 0Z (to be agreed)

...

starting at 0Z (to be agreed)

...

 

Pressure Level Fields

 

...

step

...

name

...

intervals must represent 12 hours

...

Alternative is "geopotential_height" in m

...

intervals must represent 12 hours

...

 

Additional Questions to be addressed

...

Francisco Doblas-Reyes NetCDF4? With or without compression?
Kevin Marsh netCDF4 classic model (with deflate =6 suggested by Pierre-Antoine)

...

Kevin Marsh Pierre-Antoine Bretonniere proposed  follow SPECS convention

...

Kevin Marsh Pierre-Antoine Bretonniere suggested 4GB recommended maximum size

...

Kevin Marsh recommend 4GB Max Size for data files

...

Kevin Marsh DOI likely to be assigned at dataset level

...

Kevin Marsh DOI likely to be assigned at dataset level

...

Kevin Marsh  Antonio S. Cofino Gonzalez suggested follow cmip5 short names

...

Kevin Marsh follow cmip5 short names

...

Coordinate short names to be specified?

...

Kevin Marsh Antonio S. Cofino Gonzalez suggested  follow cmip5 coordinate short names

...

Kevin Marsh follow cmip5 coordinate short names

...

Kevin Marsh yes, but not in the initial convention release

...

Kevin Marsh Not considered in initial release

...

Kevin Marsh Antonio S. Cofino Gonzalez agreed 1 degree grid specified with valid max/min, but actual grid points not specified

...

Kevin Marsh 1 degree grid specified with valid max/min, but actual grid points not specified

...

Kevin Marsh These will be added by C3S, rather than data provider

...

Kevin Marsh These will be added by C3S

...

Kevin Marsh requested via standard name mailing list. Note that this process can take some considerable time.

...

Kevin Marsh requested via standard name mailing list

 

Discussion about time coordinates

NOTE: The SPECS approach (2 1D time coordinates) has been chosen for the "providers" convention

 

The encoding of multiple time coordinates requires particular consideration. An explicit example of the structure is given below.

Example of encoding data with multiple time axis informations

  
double forecast_reference_time(forecast_reference_time) ;
       forecast_reference_time:bounds = "forecast_reference_time_bnds" ;
       forecast_reference_time:units = "hours since 1970-01-01 00:00:00" ;
       forecast_reference_time:standard_name = "forecast_reference_time" ;
       forecast_reference_time:calendar = "gregorian" ;
double leadtime(leadtime) ;
       leadtime:bounds = "leadtime_bnds" ;
       leadtime:units = "hours" ;
       leadtime:standard_name = "forecast_period" ;
       leadtime:calendar = "gregorian" ;
double time(forecast_reference_time,leadtime) ;
       time:axis = "T" ;
       time:bounds = "time_bnds" ;
       time:units = "hours since 1970-01-01 00:00:00" ;
       time:standard_name = "time" ;
float temp(forecast_reference_time,leadtime,pressure,latitude,longitude);
      temp:units = "K";
      temp:standard_name = "air_temperature";
      temp:coordinates = "time";

Francisco Doblas-Reyes I interpret this as the time coordinates being a hypercube, where there could be missing data; this won't be consistent with the CMIP files; I still find this confusing unless a discussion about what to do with the missing data is undertaken.

Eduardo Penabad: Wouldn't that be solved by clarifying that different variables within the same file could potentially have different time coordinates/dimensions?

Francisco Doblas-Reyes Not sure. If to simplify you assume one variable only and this variable has in one file data for two start dates, one with three forecast time steps and another one with only two, the time dimensions will be forecast_reference_time=2, leadtime=3, but one of the values of temp() will have missing values, unless I haven't understood the model.

Antonio S. Cofino Gonzalez: discussion on multi-time dimension data

 

 

...