Introduction
Global attributes
...
Files must pass the supplied checker
Multiple conventions may be included (separated by blank spaces)
...
CF: Free text
ACDD (highly recommended)
C3S: A controlled vocabulary will be provided
...
Antonio S. Cofino Gonzalez: 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.
This attribute is recommended by the NetCDF Users Guide and the CF conventions
...
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.
...
- "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?
...
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.
...
CF: Free text
C3S: Copernicus User Support URI should be used
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
...
CF: Free text
C3S: "C3S Seasonal Forecast" is required, additional project info (e.g. ITT details) is optional
...
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'.
...
SPECS: YYYY-MM-DDThh:mm:ss<zone>
NOTE: This is ISO 8601:2004 extended format
...
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
...
Antonio S. Cofino Gonzalez: Miscellaneous information about the data, not captured elsewhere. This attribute is defined in the CF Conventions.
...
C3S: Controlled Vocabulary
"forecast" or "hindcast"
...
- "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
...
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.
...
ACDD (highly recommended) : text, controlled vocabulary
C3S: The content will be provided
...
SPECS: YYYY-MM-DDThh:mm:ssZ
NOTE: This is ISO 8601:2004 extended format
...
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?)
...
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)"
...
"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)"
...
"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
...
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
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 standard names tables
SPECS file content and format, data structure and metadata
CMIP6 Data Request: MIP variables search
Examples
Some example files have been created following the guidelines contained in this document.
| View file | ||||
|---|---|---|---|---|
|
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 Name | Value | Examples | Comment |
|---|---|---|---|
| Conventions | CF_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 | "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 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". The name "creation_date" has been used following SPECS convention. |
| comment | Free text |
| 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
|
| frequency | Controlled Vocabulary "mon", "day", "12hr", "6hr", "fix" | "day" | A string indicating the interval between individual time-samples. 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) |
| history | Empty 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://git.ecmwf.int/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: 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
|
Spatial Coordinates
| Type (CMIP5) | Coordinate Name (CMIP5) | Dimension Names (CMIP5) | Axis | standard_name | long_name (CMIP5) | units (CF canonical units) | positive | valid_min (CMIP5) | valid_max (CMIP5) | bounds | Notes |
|---|---|---|---|---|---|---|---|---|---|---|---|
| double | lat | lat | Y | latitude | latitude | degrees_north | N/A | -90. | 90. | lat_bnds | Values (1x1deg grid) prescribed: [-89.5, -88.5 , ..., -0.5, 0.5 ... 89.5] |
| double | lon | lon | X | longitude | longitude | degrees_east | N/A | 0. | 360. | lon_bnds | Values (1x1deg grid) prescribed: center of 1-degree cells dimension lon=360 [0.5 , 1.5 , ..., 358.5, 359.5] |
| double | plev | plev | Z | air_pressure | pressure | Pa | down | N/A | N/A | This is also referred to as isobaric level by some tools [925., 850., 700., 500., 400., 300., 200., 100., 50., 30., 10.] | |
| double | depth | depth | Z | depth | depth | m | down | N/A | N/A | depth_bnds | Only used for soil model levels NOTE: Number and depth of levels is not prescribed by C3S |
| double | height | (scalar auxiliary coordinate) | Z | height | height | m | up or down | CMIP5: 2mtemp: 1. | CMIP5: 2mtemp: 10. | Used for single level fields (height, soil,SST) e.g. 2 m (for Temperature) | |
C3S: string
| realization | str31=31 | E | realization | realization | 1 | N/A | N/A | N/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
| Type | Coordinate Name | Dimension Names | Axis | standard_name | long_name | calendar | units | bounds | Notes |
|---|---|---|---|---|---|---|---|---|---|
| double | reftime | N/A | N/A | forecast_reference_time | "Start date of the forecast" | gregorian | UDUNITS time units e.g. "hours since YYYY-MM-DD hh:mm:ss TZhh:TZmm" | N/A | In 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) |
| double | leadtime | leadtime | N/A | forecast_period | "Time elapsed since the start of the forecast" | N/A | SPECS: days | 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 |
| double | time | leadtime | N/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
|
Cell boundaries
As described in section 7.1 Cell Boundaries of CF convention.
| Info |
|---|
To represent cells we add the attribute |
| Bounds Name | Dimensions | Comments |
|---|---|---|
| time_bnds | leadtime, bnds | |
| leadtime_bnds | ||
| lat_bnds | lat, bnds | Values (1x1deg grid) prescribed: [-90., -89.], [-89., -88.], ... [89., 90.] |
| lon_bnds | lon, bnds | Values (1x1deg grid) prescribed: [0., 1.], [1., 2.], ... [359., 360.] |
| depth_bnds | depth, bnds | Should 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 | value | comment |
|---|---|---|
| grid_mapping | hcrs |
Conditional attributes
The following attributes may be included in the attribute list for a given variable if the conditions specified are fulfilled:
| attribute name | value | comment |
|---|---|---|
| _FillValue | Set by netCDF library | Those 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_value | Set 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 name | value | comment |
|---|---|---|
| valid_max | TBD | see below |
| valid_min | TBD | see below |
| Info | ||
|---|---|---|
| ||
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) | dimensions | standard_name | long_name (CMIP5) | units | coordinates | valid_min | valid_max | global attributes |
|---|---|---|---|---|---|---|---|---|
| sftlf | lat,lon | land_area_fraction | "Land Area Fraction" | 1 | "lat lon"
| 0 | 1 | "frequency":"fix" |
| orog | lat,lon | surface_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) | dimensions | standard_name | long_name (CMIP5/6&C3S) | units | coordinates | cell_methods | valid_min | valid_max | global attributes | NOTES |
|---|---|---|---|---|---|---|---|---|---|---|
| tas | leadtime,lat,lon | air_temperature | "Near-Surface Air Temperature" | K | "reftime realization time leadtime height lat lon"
| "leadtime: point" | "frequency":"6hr" | height is usually 2m height:valid_min = 1.;
| ||
| tasmax | leadtime,lat,lon | air_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" | height is usually 2m height:valid_min = 1.; C3S: The interval is required to have a value<=3 hours) leadtime_bnds, time_bnds are required | ||
| tasmin | leadtime,lat,lon | air_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" | height is usually 2m height:valid_min = 1.; C3S: The interval is required to have a value<=3 hours) leadtime_bnds, time_bnds are required | ||
| tdps | leadtime,lat,lon | dew_point_temperature | "2m Dewpoint Temperature" | K | "reftime realization time leadtime height lat lon" | "leadtime: point" C3S: required CF: recommended | "frequency":"6hr" | height is usually 2m height:valid_min = 1.; | ||
| uas | leadtime,lat,lon | x_wind | Eastward Near-Surface Wind | m s-1 | "reftime realization time leadtime height lat lon" | "leadtime: point" C3S: required CF: recommended |
"frequency":"6hr" | height is usually 10m
| ||
| vas | leadtime,lat,lon | y_wind | Northward Near-Surface Wind | m s-1 | "reftime realization time leadtime height lat lon" | "leadtime: point" C3S: required CF: recommended |
"frequency":"6hr" | height is usually 10m height:valid_min = 1.;
| ||
wsgmax
N/A in CMIP | leadtime,lat,lon | wind_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" | height is usually 10m height:valid_min = 1.;
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) | dimensions | standard_name | long_name (CMIP5/6&C3S) | units | coordinates | cell_methods | valid_min | valid_max | global attributes | Comments |
|---|---|---|---|---|---|---|---|---|---|---|
| psl | leadtime,lat,lon | air_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" | |||
| clt | leadtime,lat,lon | cloud_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" | |||
| tsl | leadtime,lat,lon | soil_temperature | "Temperature of Soil" | K | "reftime realization time leadtime lat lon" | "leadtime: point" C3S: required CF: recommended | "frequency":"6hr" | |||
| tso | leadtime,lat,lon | sea_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,lon | sea_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" | |||
| sic | leadtime,lat,lon | sea_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,lon | moisture_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,lon | lwe_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,lon | snow_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,lon | lwe_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" | leadtime_bnds, time_bnds are required | ||
lweprc
N/A in CMIP | leadtime,lat,lon | lwe_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" | leadtime_bnds, time_bnds are required | ||
lwepr
N/A in CMIP | leadtime,lat,lon | lwe_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" | leadtime_bnds, time_bnds are required | ||
| lweprsn
N/A in CMIP | leadtime,lat,lon | lwe_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" | leadtime_bnds, time_bnds are required | ||
| hfss | leadtime,lat,lon | surface_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" | leadtime_bnds, time_bnds are required | ||
| hfls | leadtime,lat,lon | surface_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" | leadtime_bnds, time_bnds are required | ||
| rsds | leadtime,lat,lon | surface_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" | leadtime_bnds, time_bnds are required | ||
| rlds | leadtime,lat,lon | surface_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" | leadtime_bnds, time_bnds are required | ||
| rss | leadtime,lat,lon | surface_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" | leadtime_bnds, time_bnds are required | ||
| rls | leadtime,lat,lon | surface_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,lon | toa_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,lon | toa_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 | ||
| rsdt | leadtime,lat,lon | toa_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 | ||
| tauu | leadtime,lat,lon | surface_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 | ||
| tauv | leadtime,lat,lon | surface_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,lon | lwe_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,lon | runoff_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,lon | surface_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,lon | subsurface_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) | dimensions | standard_name | long_name (CMIP5) | units | coordinates | cell_methods | valid_min | valid_max | global attributes |
|---|---|---|---|---|---|---|---|---|---|
| zg | leadtime,plev,lat,lon | geopotential_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" | ||
| ta | leadtime,plev,lat,lon | air_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" | ||
| hus | leadtime,plev,lat,lon | specific_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,lon | atmosphere_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,lon | divergence_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" | ||
| ua | leadtime,plev,lat,lon | x_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" | ||
| va | leadtime,plev,lat,lon | y_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" | ||
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
...