Versions Compared

Old Version 13

changes.mady.by.user Eduardo Penabad

Saved on

compared with

New Version 14

changes.mady.by.user Eduardo Penabad

Saved on

Key

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

...

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

Multiple conventions may be included (separated by blank spaces)

title

A controlled vocabulary will be provided

CF: Free text

ACDD (highly recommended)

"IPSL-CM5A-LR model output prepared for CMIP5 RCP4.5"
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
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.
sourceA methodology to build this attribute will be provided
  • "world model v.0.1"
  • "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)"

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

institution

A controlled vocabulary will be provided

CF: Free text

 

"Met Office"

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

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:ss<zone>

ISO 8601:2004 extended format

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

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
SPECS conventions will be followed  

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

"forecast" or "hindcast"

"forecast"To identify the type of data
history

Each line should begin with a timestamp indicating the date and time of day when the program was executed

CF: Free 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. Provides an audit trail for modifications to the original data.
Well-behaved generic netCDF filters will automatically append their name and the parameters with which they were invoked to the global history attribute of an input netCDF file

 

commit,

iso_lineage or lineage

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

trace of the tools/scripts used.

Paco: include information about the versioning of the software used to create the data

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.

summary

The content will be provided

ACDD (highly recommended): Text, defined phrase

 A short paragraph describing the dataset
keywords

The content will be provided

ACDD (highly recommended) : text, controlled vocabulary

 A comma separated list of key words and phrases.
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: This 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.Bounds requiredlat_bounds

Values (1x1deg grid) prescribed:
dimension lat=181

[-90. , -89. , ..., 0., ... 90.]

doublelonlonXlongitudelongitudedegrees_eastN/A0.360.Bounds requiredlon_boundsValues (1x1deg grid) prescribed:
dimension lon=360

[0. , 1. , ..., 358., 359.]

doubleplevplevZair_pressurepressure

Pa

downN/AN/Abounds?

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: in hPa)

doubledepthdepthZdepthdepth

m

downN/AN/Adepth_boundsOnly used for soil model levels
NOTE: Number and depth of levels is not prescribed by C3S
doubleheightheightZheightheightmup 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

 

 realization

C3S: realization_dim

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


E realizationrealization1N/AN/AN/A members are not a physical quantity. Realization is a discrete coordinate and the mebers it categorical values (ordered or non-ordered ones)

Time Coordinates

leadtimetimeperiodTime elapsed since the start of the SPECS: days
 C3S: requested units can be relaxed to equivalent

Time for which the forecast is valid

TypeCoordinate NameDimension NamesAxisstandard_namelong_name(SPECS)calendarunitspositiveboundsNotes
doublereftimeN/ATforecast_reference_time"Start date of the forecast"N/AgregorianUDUNITS time units
e.g.
"hours since YYYY-MM-DD hh:mm:ss TZhh:TZmm"		bounds?In SPECS it was a "global_attribute"
It has been additionally introduced here as a coordinate variable to ease future netCDF management (e.g. file merging)
doubleleadtimetimeN/Aforecast_period"Time elapsed since the start of the forecast"N/AN/A

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

timetimeT

time

"Verification time of the forecast"standard

SPECS: "days since 1850-01-01"

SPECS: days

C3S: requested units can be relaxed to equivalent time units

N/A

NOTE: about forecast_reference_time as a global attribute (not generic, but SPECS use, as it will have one variable/start time per file)

Cell boundaries

 

As described in section 7.1 Cell Boundaries of CF convention.

bounds?

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

doubletimetimeT

time

"Verification time of the forecast"gregorian

SPECS: "days since 1850-01-01"

C3S: requested units can be relaxed to equivalent time units

time_bounds

Time for which the forecast is valid


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"

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

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_boundstime,bounds
  • where to put the time coordinate (beginning, middle, end of the bounds) ?

e.g.
time=20160922 06
timebounds = [20160922 00, 20160922 06]

  • for 24h time steps:

[0,24] is that convention always valid?

lat_boundslat, boundsValues (1x1deg grid) prescribed:
[-90., 89.], [-89., -88.], ... [89., 90.]
lon_boundslon, bounds

Values (1x1deg grid) prescribed:

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

depth_boundsdepth,boundsShould define the full vertical extent of the soil model layers

 

...

Grid mapping

 As described in section 5.6 Grid Mappings and Projections of CF convention.

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


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


Variables

NOTE: coordinates should list first of all the auxiliary coordinate(s) and then all the other coordinates.... SHOULD reftime and leadtime be included as well????

Static Fields

...

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

"lat lon"

 

 

 		latitude_longitude

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

Surface Fields (defined at a given height level)

...

 

  attributes 
name
(CMIP5)		dimensionsstandard_namelong_name
(CMIP5)		unitscoordinatescell_methodsgrid_mappingNOTES
tastime,lat,lonair_temperature"Near-Surface Air Temperature"K

"height time lat lon"

 

 

"time: point"

C3S: required 
CF: recommended

latitude_longitude
what value has this variable?

height is usually 2m

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

"height time lat lon"

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

C3S: required.
CF: interval is optional

 

height is usually 2m

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

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

"height time lat lon"

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

C3S: required.
CF: interval is optional
 

height is usually 2m

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

 time,lat,londew_point_temperature K"height time lat lon"
 
"time: point"

C3S: required 
CF: recommended 		 

height is usually 2m

 

uastime,lat,lonx_windEastward Near-Surface Windm s-1"height time lat lon"
  
"time: point"

C3S: required 
CF: recommended 		 

height is usually 10m

vastime,lat,lony_windNorthward Near-Surface Windm s-1"height time lat lon"
  
"time: point"

C3S: required 
CF: recommended 		 

height is usually 10m

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

height is usually 10m

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

 

Surface Fields (not defined at a  height level)

...