Obs4MIPs Data Specifications version 2.6.1 (ODS2.6.1)

For the atest obs4MIPs tabes ad cotroed vocabuary, pease see the dedicated Github repository: https://githubcom/PCMDI/obs4MIPs-cmortabes/tree/master Obs4MIPs Data Specificatios ODS261 November 2025 Previous version: ODS2.5 Authors: Obs4MIPs Steering Panel (2025) Contributors to ODS2.6 and/or earlier versions: Peter Gleckler (PCMDI), Karl Taylor (PCMDI), Paul Durack (PCMDI), Denis Nadeau (LANL), Jim Biard (NOAA/NCEI), Gregory Elsaesser (NASA GISS/Columbia University), Robert Ferraro (JPL), Stephan Finkensieper (DWD), Birgit Hassler (DLR), Andrew Manaster (RSS), Carl Mears (RSS), Simon Pinnock(ESA), Paul Smith (CMIP-IPO), Scott Stevens (NOAA/NCEI), Matthias Tuma (WCRP), Briony Turner (CMIP-IPO), Allison Waterfall (CEDA), Kate Willett (MOHC), Claire Bulgin (UoR). Cotets Acknowledgements and disclaimer Introduction What is new in ODS2.6 Global attributes Data Reference Syntax (DRS) components File name template Directory structure template Sample file header Appendix 1: Coordinate bounds Appendix 2: Guidance for defining and registering source information (product description) Appendix 3: Site (in-situ) data Appendix 4: Data Preparation Appendix 5: Variable name suffixes for characterizing uncertainty Appendix 6: Anomaly data Appendix 7: Document version information Ackowedgmets The work developing and amending the obs4MIPs Data Specifications is an activity of the obs4MIPs Steering Panel, within the WCRP Earth System Modelling and Observations (ESMO) Core Project. The work on this publication has been coordinated and led by Peter Gleckler, PCMDI. This work has been performed under the auspices of the U.S. DOE Lawrence Livermore National Laboratory (LLNL) under Contract No. DE-AC52-07NA27344, including support from the Regional and Global Model Analysis (RGMA) program of the U.S. Department of Energy (DOE) Office of Science (OS), Biological and Environmental Research (BER) program. Support has also been provided by: ●NASA's Advanced Communications Capabilities for Exploration and Science Systems Project (project ACCESS-0031, 80NSSC21M0030). ●The European Space Agency’s Climate Change Initiative (CCI). ●The CMIP International Project Office, hosted by the European Space Agency, with staff provided by HE Space Operations Ltd. Discaimer: The designations employed in the WCRP Earth System Modelling and Observations Core Project, (ESMO )publications and the presentation of material in this publication do not imply the expression of any opinion whatsoever on the part of ESMO, the World Climate Research Programme (WCRP) including its Sponsor Organizations the World Meteorological Organization (WMO), the Intergovernmental Oceanographic Commission (IOC) of UNESCO and the International Science Council (ISC) –or the DKRZ in its role as host organisation of the ESMO International Project Office (ESMO IPO), concerning the legal status of any country, territory, city or area or of its authorities, or concerning the delimitation of its frontiers or boundaries. The findings, interpretations and conclusions expressed in ESMO publications with named authors are those of the authors alone and do not necessarily reflect those of ESMO, WCRP, its Sponsor Organizations, or DKRZ. This document is not an official publication of the WCRP and has been issued without formal editing. The views expressed herein do not necessarily have the endorsement of WCRP or its Members. Any potential mention of specific companies or products does not imply that they are endorsed or recommended in preference to others of a similar nature which are not mentioned or advertised. Copyright otice This report is published by ESMO International Project Office under a Creative Commons Attribution 4.0 International License (CC BY 4.0, https://creativecommons.org/licenses/by/4.0/) and thereunder made available for reuse for any purpose, subject to the license’s terms, including proper attribution. Bibiographic iformatio This report should be cited as: Obs4MIPs Steering Panel (2025). Obs4MIPs Data Specifications version 2.6 (ODS2.6). Zenodo. https://zenodo.org/records/11500474 Itroductio The purpose of obs4MIPs is to facilitate comparison of gridded and un-gridded observational data with model output from WCRP intercomparison projects, notably the Coupled Model Intercomparison Project (CMIP). To accomplish this, the organisation and description of CMIP and obs4MIPs data are closely coordinated, as described in this document. The details of this technical alignment, including the data structure and metadata requirements, facilitate coordinated delivery via the Earth System Grid Federation (ESGF) and use of the data for model evaluation, research, and development. The original obs4MIPs contributions followed CMIP5 data specification guidelines (ca. 2012, hereafter ODS1.0). This early phase was challenging because the software infrastructure (CMOR) did not readily accommodate observations. This was rectified in CMIP6, with the obs4MIPs team working closely with the Working Group on Coupled Models (WGCM) Infrastructure Panel (WIP) aligning ODS2.1 to CMIP6 data specifications. At that time, obs4MIPs coordination and governance was provided by the WCRP’s Data Advisory Council's (WDAC) Observations for Model Evaluation Task Team. Since 2022 this role has been fulfilled by the WIP and the obs4MIPs Steering Panel with technical support of the CMIP International Project Office (CMIP IPO) and oversight of WCRP’s ESMO. To avoid naming conflicts in the identification of data sources and institutions, data providers must register the name of their institution and other information about their data prior to generating obs4MIPs data sets. This process is analogous to CMIP and is done by submitting a Registered Content (RC) issue on the obs4MIPs-cmor-tables Github repository.Appendix 2 details the information required. All obs4MIPs-compliant datasets are either prepared by the official data curator, or a third-party. Either way, the institution providing a obs4MIPs-compliant dataset is identified via the <variant_label> attribute (See Table 1). Third-party contributors have to inform the original curatorsthattheyarepreparinganobs4MIPs-compliantversionoftheirdataproduct,andhonourlicensingassociatedwiththeoriginaldata. Efforts are underway to develop a “validator” or “checker”, to confirm whether or not a dataset is obs4MIPs-compliant and technically structured to be consistent with CMIP output even if it was prepared without using CMOR. To meet the strict requirements of aligning model and observational data, this includes not just adhering to the metadata conventions, but also the structure and type of the data including all coordinates and bounds. If a mechanism to confirm a dataset is “CMOR equivalent” is established, the requirement of using CMOR for obs4MIPs may be relaxed to “recommended”. Already, if a particular dataset cannot be prepared with CMOR for technical reasons, it can be prepared with other methods provided the ODS specifications are met, the data closely matches CMIP model output, and the processing scripts are included in the obs4MIPs-cmor-tables GitHub repository. Obs4MIPs metadata specifications for the following categories are described in this document: 1. Globalattributes:Explicitlydefinedmetadata included innetCDFfilesthatdescribe the contentsofthedatasetand provenance (e.g., <source_id>). 2. Data Reference Syntax (DRS): Some attributes (e.g.,<institution_id>, <source_id>, <variable_id>) comprise the data reference syntax (DRS) for obs4MIPs, which closely parallels the DRS of CMIP6. The DRS is used in file names, directory structures, and facets of some search tools such as ESGF. 3. Directory structure: This includes selected DRS information used as subdirectories. As per CMIP6, it is explicitly defined in obs4MIPs to facilitate organization of a federated database and searching for data with ESGF. 4. Filenames: Like the directory structure, filenames are constructed based on a template that uses Controlled Variables (CV) entries. This document includes a discussion of the inclusion (or not) of grid cell bounds. These bounds make it possible for users of the data to weigh the influence of each cell based on its surface area (or volume), for calculating a domain mean. A user can estimate the grid cell bounds, but those closest to the original data are generally best positioned to construct, estimate, or consider bounds for a particular dataset to be poorly defined and therefore not included. We recommend that data providers include grid bounds (Appendix 1). What is ew i ODS26? The standards describing CMIP data are quite mature, with the general structure not changing significantly from one phase to the next of CMIP. ODS2.6 includes minor changes to ODS2.5 while retaining consistency with existing (CMIP6) protocols. Minor updates to ODS2.6 may be required as the data protocols of CMIP7 are established. Making changes to ODS where necessary ensures continuity and backward compatibility. The main changes since ODS2.5 are summarised here and described later in this document. Changes to obs4MIPs Global Attributes, DRS, filenames, and directory structure ●New global attributes: <aux_uncertainty_id>, <has_aux_unc>, <DOI>, <site_id> and <site_location> (see Table 1) ●Guidelines for inclusion of (single and multi) site data, with new <product> options (Appendix 3) ●Guidelines for the inclusion of uncertainty information as separate but related files (Appendix 5) ●Guidelines for the provision of anomaly fields (Appendix 6) ●Provision for statistical/uncertainty information and anomalies via <variable_id> suffixes ●The filename template, directory template, and DRS in ODS2.6 is identical to ODS2.5 Goba attributes The global attributes facilitate organisation of the obs4MIPs datasets, in particular providing useful options (or facets) for data exploration via ESGF metagrid. DRS is more behind the scenes than the search functions - but is critical in defining how data from the CMIP and obs4MIPs databases are organised (notably the directory structure). These obs4MIPs data structures are curated by the authors of this document in coordination with the obs4MIPs Steering Panel and the WIP. CMIP data requirements are currently facilitated by using the Climate Model Output Rewriter (CMOR), recommended for producing obs4MIPs-compliant datasets, because the necessary metadata for ESGF distributed data searching is included. Following instructions, a user populates an input table with the entries of the required global attributes, and data is read in (via a python script) and output via CMOR, which automatically produces the DRS and file names. Table 1 contains the list of obs4MIPs global attributes, indicating which are required and which are optional. The values for many of the global attributes must be drawn from special obs4MIPs controlled vocabularies (CVs). A CV is a list of the permitted values that can be assigned to a given global attribute. The lists of permitted values can be found in the Github repository Tabe 1: obs4MIPs goba attribute descriptio obs4MIPs global attributes see note 1 Description Examples Introduced Form see note 2 Required Further information aux_uncertainty_id Suffix added to variable_id to indicates statistical uncertainty quantity ”sd” (Standard deviation) “stderr” (Standard error), “ucom” (Common uncertainty), uind (Independent uncertainty), “ustr” (Structured uncertainty) see also Appendix 5 table NEW IN ODS2.6 Should be considered controlled vocabulary. when has_aux_unc is TRUE Can be used to query if uncertainty data is available/ associated activity identifier only value permitted is originally CV always Renamed more generically, obs4MIPs global attributes see note 1 Description Examples Introduced Form see note 2 Required Further information activity_id see note 3 “obs4MIPs” project_id in ODS1.0 since not all activities are projects; multiple activities may now be listed separated by single spaces comment see note 9 see note 9 ODS1.0 free form optional No change from original obs4MIPs or CMIP5; CFconvention standard contact see note 9 see note 9 ODS1.0 free form always Still required with ODS-2.6 Conventions convention version "CF-1.11 ODS-2.6” ODS1.0 CVs always Updated version from ODS1.0 with a list of conventions separated by single spaces now allowed creation_date date file was created see note 5 ODS1.0 structured form always No change from original obs4MIPs specs (automatic with CMOR3) dataset_contributor Identifies the individual who obtained the original data and made it obs4MIPscompliant Initials or full name contributor ODS2.5 free form always Helps make the process of preparing obs4MIPscompliant data fully traceable data_specs_version version identifier of obs4MIPs CVs and CMOR tables e.g. 2.6 ODS2.1 CVs always This version number is associated with the version or GitHub “tag” for the obs4MIPs obs4MIPs global attributes see note 1 Description Examples Introduced Form see note 2 Required Further information CMOR tables and the CVs. See PCMDI/obs4MIPs-cmortables which originate from the CMIP6 tables doi DOI of original dataset 10.15770/EUM_SAF_O SI_0023 NEW IN ODS2.6 structured form encouraged DOI pointing to the source of dataset external_variables external cell measures “areacella”, “areacello”, “volcella”, “volcello”, as defined in CMIP6 ODS2.1 CVs rarely needed, but include when appropriate List of cell-measured variables (separated by single spaces) that are referenced but not included in the file. These variables will be stored independently in the obs4MIPs data archive. Use of this attribute is expected to be infrequent in contrast to the recommended inclusion of grid bounds (Appendix 1) frequency sampling frequency “mon” ODS1.0 CV always No change from original obs4MIPs. The current options are given in obs4MIPs_frequency.json grid grid, In the case of in situ observations this should be set to ‘site’ or ‘sitecollection’ see note 7, ODS2.1 free form always Briefly describes output grid characteristics obs4MIPs global attributes see note 1 Description Examples Introduced Form see note 2 Required Further information “temperature: unknown” See Appendix 6 variable_id variable identifier “tas”, “pr”, “ua” Note: anomalies should follow CMIP6 variable_ids with the suffix ‘anom’ e.g., ‘hussanom’, hursanom’, ‘tasanom’ etc. See Appendix 6 for examples of anomaly fields. ODS1.0 Refined in ODS2.6 CV, new variables and those with the ‘anom’ suffix will need to be added to CV. always Added to direct users and software to the primary variable of interest in the file. The complete list of CMIP6 variable_ids is here variant_info description of “3rd party” identifier and if applicable run variant “Best Estimate”, “Sphere of influence = 20km” See note 15 ODS2.1 refined in ODS2.5 free form as appropriate Provides a brief description of who has prepared the obs4MIPs-compliant data (e.g., original data curator or a 3rd party). Also, if describing an observational ensemble, variant differences can be described. variant_label “variant” label “PCMDI” Ensemble: examples: “RSS-BE” “RSS-r1” ODS2.1 refined in ODS2.5 structured form always Attribute serving two purposes: 1). a registered institution_id representing where the obs4MIPs product was prepared (either the obs4MIPs global attributes see note 1 Description Examples Introduced Form see note 2 Required Further information See note 16 institute of the data curator or a 3rd party), AND, if applicable, a concatenated (“-”) 2nd entry to identify a member of an observational ensemble. If there is a default version of an ensemble, it is identified as a ‘best estimate’ or “BE.” The ensemble entry is relevant only when there are multiple estimates of the same source_id (e.g., constructed with alternate processing choices), in which case ensemble member identification could follow CMIP6, e.g., with “BE”, “r1”, “r2”, “r3”, ... Table Notes: 1. When using CMOR, an additional global attribute will be included: cmor_version, but this is not an obs4MIPs required global attribute. 2. “CV” means content must be taken from a “controlled vocabulary” defined in coordination with the WIP. “registered content” (RC) is special controlled vocabulary defined by data contributors and monitored by the obs4MIPs Steering Panel. Data contributors can submit RC at (https://github.com/PCMDI/obs4MIPs-cmor-tables) and contact [email protected] 3. For backwards compatibility with ODS1.0 project_id will be an alias of activity_id on ESGF. 4. Since some software uses the ‘title’ for default plotting or describing the contents of a file, it can be used to provide a description that is similar or equivalent to the source. A common entry may be the same as the source but without the release_year. 5. creation_date form: YYYY-MM-DDTHH:MM:SSZ (e.g., “2025-03-23T05:56:23Z”). 7. The “grid” global attribute can be used to describe the horizontal grid and re-gridding procedure. There is no standard form used to record this information, but it is suggested that, when appropriate, the following be indicated: brief description of native grid and resolution, and if data have been re-gridded, re-gridding procedure and description of target grid. Here are some examples: grid = “data re-gridded to a CMIP6 standard 1x1 degree latxlon grid from the native T63 grid using an area-average preserving method” grid = “data re-gridded via bilinear interpolation to a 3x3 deg latxlon grid from the native atmosphere T63 gaussian grid (64x128 latxlon)” grid = “data re-gridded to a CMIP6 standard 1x1 degree latxlon grid from the native T63 grid using an area-average preserving method” grid = “data regridded via bilinear interpolation to a 3x3 deg latxlon grid from the native atmosphere T63 gaussian grid (64x128 latxlon)” 8. Data providers may choose to report their output on one or more grids or, with special care, provide an alternate projection. To distinguish between output reported on different grids, a “grid_label” attribute is defined. The original grid should be labelled with “gn.” Additional grids should be labelled using the form “gr[i]” where i is a positive integer. If the data are subsequently re-gridded to a second and third grid, “gr2” and “gr3” could be used to distinguish these grids from “gr1”. 9. A description and examples of the contact, comment, history, and references global attributes may be found in the CMIP6_output_metadata_requirements. 10. The “exploratory_product” will be used to include products that are not closely aligned with CMIP model output but have potential value for model evaluation. More information on this will follow. 13. The wording of the “license” attribute is up to the dataset creator, but it is recommended that you reference one of the “Creative Commons” licenses. For example: “Data in this file produced by <Your Centre Name> is licensed under a Creative Commons Attribution- 4.0 International (CC BY 4.0) License (https://creativecommons.org/licenses/). Use of the data must be acknowledged following guidelines found at <a URL maintained by you>. Further information about this data, including some limitations, can be found via <some URL maintained by you>.” 14. tracking_id should be of the form hdl:21.14102/<uuid> (e.g., “hdl:21.14102/02d9e6d5-9467-382e-8f9b-9300a64ac3cd”). The tracking_id should be unique for each file published in ESGF. CMOR automatically generates a tracking_id. You can review the python builtin UUID library documentation here. 15. Except when variant_label=”BE”, it is recommended that variant_info include information identifying major distinguishing features of a variant, but care should be taken to record correct information. 16. Via an obs4MIPs institution_id, the variant_label identifies where the obs4MIPs-compliant data was prepared. If an obs4MIPs product is being prepared by the original curators of the source data, the institution_id for the dataset will be the same as the institution_id identified in the source_label. If the obs4MIPs product is prepared by a “3rd party” they will typically be different. Also, if the same source_id is being used to represent multiple versions of an observational “ensemble,” the variant_label can be combined (via “-”) with labels representing subsequent versions. If there is a default or official member, “BE” can be used to identify this best-estimate, with labels representing subsequent versions (derived from different processing choices), with the CMIP nomenclature recommended: ‘BE’, ‘r1’,’r2’,’r3’...’rN’. Examples: “PCMDI”, “RSS-BE”, “RSS-r1” Data Referece Sytax (DRS) compoets: The DRS is used, for example, in file names, directory structures, and in facets of some search tools. The following components are needed for obs4MIPs: activity_id (original obs4MIPs "activity") realm (original obs4MIPs "activity") frequency (original obs4MIPs: "frequency") product (original obs4MIPs: "product") institution_id (original obs4MIPs: "institute") source_id (original obs4MIPs: "model") source_label (new in obs4MIPs ODS2.1) variable_id (original obs4MIPs: "variable name") region (new in obs4MIPs ODS2.1) grid_label (new in obs4MIPs ODS2.1) variant_label (original obs4MIPs: "ensemble member") version (original obs4MIPs: "version number") Fie ame tempate: The obs4MIPs file name must be consistent with the following template. obs4MIPs file name template = <variable_id>_<frequency>_<source_id>_<variant_label>_<grid_label>[_<time_range>].nc e.g., siconc_mon_OSI-SAF-450-a-3-0_PCMDI-BE_gr1_185001-202301.nc For time-invariant fields, the last segment (time_range) above is omitted. All strings appearing in the file name are constructed using only the following characters: a-z, A-Z, 0-9, and the hyphen ("-"), except the hyphen must not appear in variable_id. Underscores are prohibited throughout except as shown in the template. Note that the last segment of the file name indicates the time-range spanned by the data in the file, and is omitted when inappropriate. The format for this segment is the same as in CMIP6 (see Table 2 of the CMIP6 specs document: http://goo.gl/v1drZl). For comparison, here is the CMIP6 file name template: <variable_id>_<table_id>_<source_id>_<experiment_id >_<member_id>_<grid_label>[_<time_range>].nc and the legacy obs4MIPs file name template: <variable>_<instrument>_<processing_level>_<processing version>_<start_date>-<end_date>.nc Directory structure tempate: The obs4MIPs directory structure must be consistent with the following template. obs4MIPs directory structure = <activity_id>/ <institution_id>/ <source_id>/ <frequency>/ <variable_id>/ <nominal_resolution>/ <version> Any spaces in nominal_resolution are removed in directory structure. For comparison, here is the CMIP6 directory structure: <mip_era>/ <activity_id>/ <institution_id>/ <source_id>/ <experiment_id>/ <member_id>/ <table_id>/ <variable_id>/ <grid_label>/ <version> and the legacy obs4MIPs directory structure: obs4MIPs/ observations/ <realm>/ <variable_id>/ <frequency>/ <grid>/ <Institution_id> <instrument>/ <version>/ Note: <version> here refers to the CMOR-assigned version number which has the form “vYYYYMMDD” (e.g., “v20170921”), indicating a representative date for when the version was produced for obs4MIPs. For those not using CMOR, the convention must be followed. Sampe fie header The example below was produced from the following demo: https://github.com/PCMDI/obs4MIPs-cmor-tables/demo KEY: BOLD identifies required global attributes for obs4MIPs compliance. ncdump -h rlut_mon_CERES-EBAF-4-2_RSS_gn_200003-202310.nc netcdf rlut_mon_CERES-EBAF-4-2_RSS_gn_200003-202310 { dimensions: time = UNLIMITED ; // (284 currently) lat = 180 ; lon = 360 ; bnds = 2 ; variables: double time(time) ; time:bounds = "time_bnds" ; time:units = "days since 2000-03-01 00:00:00" ; time:calendar = "gregorian" ; time:axis = "T" ; time:long_name = "time" ; time:standard_name = "time" ; double time_bnds(time, bnds) ; double lat(lat) ; lat:bounds = "lat_bnds" ; lat:units = "degrees_north" ; lat:axis = "Y" ; lat:long_name = "Latitude" ; lat:standard_name = "latitude" ; double lat_bnds(lat, bnds) ; double lon(lon) ; lon:bounds = "lon_bnds" ; lon:units = "degrees_east" ; lon:axis = "X" ; lon:long_name = "Longitude" ; lon:standard_name = "longitude" ; double lon_bnds(lon, bnds) ; float rlut(time, lat, lon) ; rlut:standard_name = "toa_outgoing_longwave_flux" ; rlut:long_name = "TOA Outgoing Longwave Radiation" ; rlut:comment = "at the top of the atmosphere (to be compared with satellite measurements)" ; rlut:units = "W m-2" ; rlut:cell_methods = "area: time: mean" ; rlut:cell_measures = "area: areacella" ; rlut:history = "2024-03-28T20:04:26Z altered by CMOR: replaced missing value flag (-999) and corresponding data with standard missing value (1e+20)." ; rlut:missing_value = 1.e+20f ; rlut:_FillValue = 1.e+20f ; rlut:valid_min = "0.00000" ; rlut:valid_max = "400.000" ; // global attributes: :Conventions = "CF-1.11; ODS-2.5" ; :aux_uncertainty_id = “ustd”; :activity_id = "obs4MIPs" ; :contact = "RSS ([email protected])" ; :creation_date = "2024-03-28T20:04:26Z" ; :data_specs_version = "ODS-2.5" ; :doi = “https://doi.org/10.5194/egusphere-2025-219”; :dataset_contributor = "Andrew I. Manaster" ; :external_variables = "areacella" ; :frequency = "mon" ; :grid = "1x1 degree latitude x longitude" ; :grid_label = "gn" ; :has_aux_unc = “TRUE”; :history = "2024-03-28T20:04:26Z; CMOR rewrote data to be consistent with obs4MIPs, and CF-1.11; ODS-2.5 standards" ; :institution = "NASA-LaRC (Langley Research Center) Hampton, Va" ; :institution_id = "NASA-LaRC" ; :nominal_resolution = "100 km" ; :processing_code_location = "https://github.com/PCMDI/obs4MIPs-cmortables/tree/9876ae84146244a20fb498f2a2be7e8272a3142f//inputs/RSS/NASA-LaRC" ; :product = "observations" ; :realm = "atmos" ; :references = "doi: 10.1175/JCLI-D-17-0208.1" ; :region = "global" ; :site_id = “CA-Gro”; :site_location = “Ontario, Groundhog River, Boreal mixed wood forest”; <site_id> Acronym and locations with lon and lat scalar coordinates without bounds. <site_location> (e.g., South Western Great Plains) and <site_id> (e.g., SGP) will be curated as part of obs4MIPs CVs CF regions still honoured for <region>; site location within region selected. Demo code based on ARM with sample output Sample File Header for individual site: netcdf pr_1hr_ARMBE-atm-c1-1-8_LLNL_US-ARM-SGP_201801010030-201807280730 { dimensions: time = UNLIMITED ; // (5000 currently) lat = 1 ; lon = 1 ; bnds = 2 ; variables: double time(time) ; time:bounds = "time_bnds" ; time:units = "days since 2018-01-01" ; time:calendar = "gregorian" ; time:axis = "T" ; time:long_name = "time" ; time:standard_name = "time" ; double time_bnds(time, bnds) ; double lat(lat) ; lat:units = "degrees_north" ; lat:axis = "Y" ; lat:long_name = "Latitude" ; lat:standard_name = "latitude" ; double lon(lon) ; lon:units = "degrees_east" ; lon:axis = "X" ; lon:long_name = "Longitude" ; lon:standard_name = "longitude" ; float pr(time, lat, lon) ; pr:standard_name = "precipitation_flux" ; pr:long_name = "Precipitation" ; pr:comment = "includes both liquid and solid phases" ; pr:units = "kg m-2 s-1" ; pr:cell_methods = "area: time: mean" ; pr:cell_measures = "area: areacella" ; pr:missing_value = 1.e+20f ; pr:_FillValue = 1.e+20f ; // global attributes: :Conventions = "CF-1.7 ODS-2.1" ; :activity_id = "obs4MIPs" ; :contact = "[email protected], [email protected]" ; :creation_date = "2025-09-23T19:27:00Z" ; :data_specs_version = "2.1.0" ; :external_variables = "areacella" ; :frequency = "1hr" ; :further_info_url = "https://furtherinfo.es-doc.org/obs4MIPs.DOE-ARM.source_labelARMBE-atm-c1-1-8.pr" ; :grid = "site" ; :grid_label = "US-ARM-SGP" ; :history = "2025-09-23T19:27:00Z ; CMOR rewrote data to be consistent with CMIP6, CF-1.7 ODS-2.1 and CF standards." ; :institution = "U.S. Department of Energy, Atmospheric Radiation Measurment Program" ; :institution_id = "DOE-ARM" ; :mip_era = "CMIP6" ; :nominal_resolution = "site" ; :originData_URL = "?" ; :originData_retrieved = "Chengzhu Zhang 2023" ; :original_history = "{}" ; :product = "site-observations" ; :realm = "atmos" ; :references = "Xie, Shaocheng., and 16-coauthors, 2010: ARM climate modeling best estimate data, Bull. Amer. Meteor. Soc, 91, 13–20 , doi:10.1175/2009BAMS2891.1." ; :region = "north_america" ; :site_id = "US-ARM-SGP" ; :site_location = "Southern Great Plains" ; :source = "ARMBE atm-c1-1-8 (2023): DOE ARM Best Estimate Data Products for Atmosphere and Cloud properties" ; :source_id = "ARMBE-atm-c1-1-8" ; :source_type = "insitu" ; :source_version_number = "atm-c1-1-8" ; :table_id = "obs4MIPs_A1hrPt" ; :table_info = "Creation Date:(18 November 2020) MD5:9ce720238f2a5bdb7d5f590423223263" ; :title = "ARM Best Estimate (ARMBE) Product, atmospheric profiles: armbeatm" ; :tracking_id = "42c4bae3-f2a5-45c4-b04b-482dc0279168" ; :variable_id = "pr" ; :variant_info = "Best Estimate" ; :variant_label = "LLNL" ; :license = "Data in this file is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License (https://creativecommons.org/licenses)." ; :cmor_version = "3.9.0" ; data: Multiple sites <product>: site-collection (multiple sites with identical time coordinate) <nominal_resolution>, <grid> and <grid_label> are set to ‘site-collection’ (refined use of attributes in filename and directory templates) <site_id>: collection <site_location>:collection Site-collection provided as 2-d array (time, location), analogous to CFMIP cf-sites; see CF-compliance Although not available at time of publication of ODS2.6, a “site-collection” demo is expected here. Sample File Header for multiple sites example: a group of stations, with one variable, reported hourly, using missing data flags as appropriate rather than compressed time axes. Items in bold are required by ODS2.6. dimensions: station = 9000 ; // measurement locations time = UNLIMITED ; variables: float tas(station, time); tas:standard_name = "air temperature"; tas:coordinates = "lat lon altitude station_id station_name"; tas:_FillValue = 1.e+20f; tas:missing_value = 1.e+20f; tas:comment = "near-surface (~2m) observation from weather station with quality control applied"; tas:units = "K"; tas:cell_methods = "area: time:point"; tas:history = "2025-08-20T11:45:26Z altered by CMOR: converted degrees celsius to Kelvin, replaced missing value flag (-1.e+30f and - 2.e+30f with standard missing value (1.e+20)."; tas:valid_min = "0.00000"; tas:valid_max = "363.00"; double time(time); time:standard_name = "time"; time:long_name = "time of measurement"; time:units = "hours since 1901-01-01 00:00:00"; time:calendar = “gregorian”; time:axis = “T”; float lon(station); lon:standard_name = "longitude"; lon:long_name = "station longitude"; lon:units = "degrees_east"; lon:axis = “X”; float lat(station); lat:standard_name = "latitude"; lat:long_name = "station latitude"; lat:units = "degrees_north"; lat:axis = “Y”; float altitude(station); altitude:long_name = "vertical distance above the surface"; altitude:standard_name = "height"; altitude:units = "m"; altitude:positive = "up"; altitude:axis = "Z"; string station_id(station); station_id:long_name = "station identification code"; station_id:cf_role = "timeseries_id"; string station_name(station); station_name:long_name = "station name"; station_name:cf_role = "timeseries_id"; attributes: :featureType = "timeSeries"; // global attributes: :Conventions = "CF-1.11; ODS-2.6"; :aux_uncertainty_id = “”; [NB: Only required if :has_aux_unc = “TRUE”] :activity_id = "obs4MIPs"; :contact = "Met Office, UK ([email protected])"; :creation_date = "2025-08-20T11:45:26Z"; :data_specs_version = "ODS-2.6"; :doi = “https://doi.org/xx.xxxx/xxxxxxxx”; :dataset_contributor = "Forename Surname"; :frequency = "1hr"; :grid = "site-collection"; :grid_label = "site-collection"; :has_aux_unc = “FALSE”; :history = "2025-08-10T11:45:26Z; CMOR rewrote data to be consistent with obs4MIPs, and CF-1.11; ODS-2.6 standards"; :institution = "Met Office, UK"; :institution_id = "MOHC"; :nominal_resolution = "site-collection"; :processing_code_location = "https://github.com/PCMDI/obs4MIPs-cmor-tables/tree/xxxxx//inputs/MOHC/MOHC" ; :product = "site-collection"; :realm = "atmos"; :references = "doi: xx.xxxx/xxxxxxxxx"; :region = "global"; :site_id = “collection”; :site_location = “collection”; :source = “Met Office Hadley Centre’s Integrated Surface Dataset of hourly observations"; :source_data_retrieval_date = "20250801"; :source_data_url = "https://www.metoffice.gov.uk/hadobs/hadisd/ and https://catalogue.ceda.ac.uk/uuid/f579035b3c954475922e4b13705a7669/ " ; :source_id = "HadISD"; :source_label = "HadISD-3-4-1-2024f"; :source_type = "ungridded_insitu"; :source_version_number = "3.4.1.2024f"; :table_id = "obs4MIPs_Amon"; :table_info = "Creation Date:(18 November 2020) MD5:6eb29c0516f0c480b52815b28b3cf029"; :title = "HadISD3.4.1.2024f (ODS-v2.6.0)"; :tracking_id = "xxxxxx"; :variable_id = "tas"; :variant_info = "obs4MIPs-compliant product prepared by MOHC"; :variant_label = "MOHC"; :license = "Data in this file produced by MOHC are licensed under a Non-commercial Government License (https://www.nationalarchives.gov.uk/doc/non-commercial-government-licence/version/2//). Use of the data must be acknowledged following guidelines found at https:/www.metoffice.gov.uk/hadobs/hadisd/. Further information about this data, including some limitations, can be found via https://www.metoffice.gov.uk/hadobs/hadisd/." ; :cmor_version = "x.x.x" ; (NOTE: this will be defined at point of cmorising) Appedix 4: Data preparatio Instructional documentation and demos are available along with the codes used to prepare existing products. The institution preparing the obs4MIPs-compliant data is identified in the <variant_label> and can be the same institution where the data is curated (i.e., same as institution_id) or a third-party institution that is registered with obs4MIPs. For a dataset to be obs4MIPs-compliant it must: oHave the <source_id> registered on the obs4MIPs GitHub (GH) repo along with the other required registered content. oProvide code used to make the data obs4MIPs-compliant available on the obs4MIPs GH metadata repo. The three stages of obs4MIPs data preparation are: An obs4MIPs-compliant dataset is a netCDF file(s) that has been prepared according to all specifications described in this document and on the GH repository mentioned above. This includes submitting the required registered content to the repository and including the associated processing codes on the GH repository. Anything short of this may be obs4MIPs-like, but not obs4MIPs-compliant. An obs4MIPs product is an obs4MIPs-compliant dataset that has been published to the ESGF obs4MIPs project Areviewed obs4MIPs product is an obs4MIPs-product that has been assessed by the obs4MIPs Steering Panel and has been assigned indicators as described in Fig 2a of Waliser et al. (2020). Appedix 5: Variabe ame suffixes for characterisig ucertaity NOTE: The defiitios beow stem from ogoig commuity discussios ad may be adapted i future versios of ODS Data cotributors are ecouraged to use the defiitios beow that are suitabe for describig ucertaity i their data See the atest iformatio here: https://zeodoorg/records/17312883 Uncertainty information can be included as separate files, prepared identically to the analysis variable, differing only in the variable_id which can be modified by appending the appropriate suffix (see table below) to the variable name. For example: pr_day_GPCP-Daily-3-2_RSS_gn_20000601-20001231.nc (obs4MIPs product) prnobs_day_GPCP-Daily-3-2_RSS_gn_20000601-20001231.nc (uncertainty information associated with obs4MIPs product) Uncertainty variable_id suffixes Suffix Long name Description nobs Number of observations The number of discrete observations or measurements from which a data value has been derived. stderr Standard error Legacy term used for backward compatibility. Definition is identical to that of ustd, the standard uncertainty. sd Standard deviation The standard deviation on the mean, legacy term for backwards compatibility. ustd Standard uncertainty The per-datum standard uncertainty is a combination of independent, structured and common effects and is equal to the positive square root of the sum of the components. The standard uncertainty is provided at one standard deviation. Replacement for ‘standard error’ due to updated terminology. uind Uncertainty due to independent effects The per-datum component of uncertainty that is associated with uncorrelated effects, between observations, provided at one standard deviation. ustr Uncertainty due to structured effects The per-datum component of uncertainty that is structured and correlated over a defined space/time scale, provided at one standard deviation. This correlation length scale in space and time must be provided in the variable metadata. ucom Uncertainty due to common effects The per-datum component of uncertainty that is common to all observations of a given type (specific instrument, resolution, variable type) at one standard deviation. The definition of the type of measurement for which this uncertainty is common should be provided in the variable metadata. lbnd Lower bound of asymmetrical uncertainty information Alternative to stderr and ustd for observations with asymmetrical uncertainty distribution, lower bound of the uncertainty interval. ubnd Upper bound of asymmetrical uncertainty information Alternative to stderr and ustd for observations with asymmetrical uncertainty distribution, upper bound of the uncertainty interval.