ACCESS Output Data Specifications

This document provides an overview of the data specifications for data produced by ACCESS models. The initial draft of this specification targets ESM1.6 and will be expanded to other ACCESS models in time. This version of the specification is intended to be relatively lightweight, as a first step towards the standardisations of data produced by the ACCESS ecosystem. The goal of this specification is to provide a consistent and uniform experience for users across all ACCESS models by enabling the embedding of established community conventions and defined data specifications directly in the ACCESS software and release processes.

Included here are file and directory naming conventions, variable conventions, and variable and global attributes.

More information on the ACCESS models can be found here. Please direct any issues, feedback or queries on the data specification to data.access.nri@anu.edu.au.

Directory and Filename

Directory Structure

The directory structure for ACCESS-ESM1.6 output data obeys the following:

<experiment_name>/output<xxx>/<realm>/<filename.nc>

Where:

  • <experiment_name> is the name of the experiment in question
  • <xxx> is the three or four digit number for the output directory label. These numbers start from zero, increment by one for each year of data, and have at least three digits.
  • <realm> is one of atmosphere, ice, and ocean

Filenames

For ACCESS-ESM1.6 filenames follow the pattern originally designed for ACCESS-OM3 which is as follows:

<model>.<component>.<dimension>[.<field>[+<vertical_coordinate>][+d2]].<frequency>.<time_cell_method>.<datestamp>.nc

  • <model> is the model used to create the data, e.g. access-esm1p6
  • <component> is the component of the model used to create the data, e.g. cice5, mom5, or um7p3.
  • <dimension> describes the number of spatial dimensions for the file, either 2d, 3d, or scalar.
  • <field> is the name of the field/variable for data in the file. Field can be ommitted for a collection of scalar values.
  • <vertical_coordinate> is only used for non-native vertical coordinates to describe those coordinates otherwise it should be omitted.
  • <frequency> is the temporal interval between records for these data following the patterns described below.
  • <time_cell_method> is the method used to aggregate data temporally, e.g. mean, maximum, snap. <time_cell_method> should be omitted if no known method was used.
  • <datestamp> describes the date for the data in the file. Datestamp will be truncated depending on the output file temporal interval, e.g. use YYYY for yearly output files, or YYYY-MM for monthly output files. <timestamp> should be omitted for data with no temporal dimension, e.g. fixed/fx data.

All information contained in output data filenames should be present in file metadata attributes.

File content

Output files will be NetCDF4 files with data variables compressed using zlib with deflate level of at least 1 and shuffle enabled. If a compression level greater than 1 is used please consider the benefit of improved compression ratios against cost of increased compression/decompression times.

Where possible files will conform to the CF metadata conventions (version 1.11) and use the CF Convention Standard Name Table.

For ACCESS-ESM1.6 every file will contain a single data variable/field from a single simulation with the exception of scalar data which can be combined into a single output file.

Metadata Attributes

Global Attributes

Global attributes provide information on the context for the data such as the creation time, experiment it is part of, or science configurations used. All the attributes in the table below are recommended but not all are required, see the Required column, and attributes not specified are permitted. Attributes are sorted alphabetically by name.

For any given experiment run, the combination of model and model_version identify the code used to generate the data. experiment_repo and run_id identify a specific commit in the repository containing the configuration used.

Title Description Type Examples Rules Required
base_configuration Configuration modified for experiment, see configs repo: https://github.com/ACCESS-NRI/access-esm1.6-configs string release-preindustrial+concentrations-2.0 Yes
contact Email address or other contact details for who to contact regarding this data. string
  • access.nri@anu.edu.au
  • John Smith (john.smith@email.com)
 Yes
Conventions Convention(s) used with their versions, as a comma separated list string CF-1.11,ACDD-1.3 Yes
data_specification Version of this data specification used to generate the data string ACCESS Output Data Specification v2-1-1 XX.XXXX/zenodo.XXXXX Yes
date_created Date and time the file was created. Follow ISO 8601, i.e. 'YYYY-MM-DDTHH:MM:SSZ' string 2025-10-07T11:10:00Z Must match regex: ^\d{4}-(1[012]|0[1-9])-(3[01]|[12][0-9]|0[1-9])T([01][0-9]|2[0-3]):[0-5][0-9]:[0-5][0-9]Z$ Yes
date_metadata_modified Date and time the metadata for this file was last modified. Note that this applied just to the metadata, not the data. Follow ISO 8601, i.e. 'YYYY-MM-DDTHH:MM:SSZ' string 2025-10-07T11:10:00Z Must match regex: ^\d{4}-(1[012]|0[1-9])-(3[01]|[12][0-9]|0[1-9])T([01][0-9]|2[0-3]):[0-5][0-9]:[0-5][0-9]Z$ No
date_modified Date and time the data for this file was last modified. Note that this applied just to the data, not the metadata. Follow ISO 8601, i.e. 'YYYY-MM-DDTHH:MM:SSZ' string 2025-10-07T11:10:00Z Must match regex: ^\d{4}-(1[012]|0[1-9])-(3[01]|[12][0-9]|0[1-9])T([01][0-9]|2[0-3]):[0-5][0-9]:[0-5][0-9]Z$ No
experiment_repo Git repository URL that describes the experiment string https://github.com/ACCESS-Community-Hub/access-esm1.6-dev-experiments Yes
experiment_uuid The experiment UUID generated by Payu. Note: this may be the same as id. string 698E600B-BECF-4CBA-994F-A663A22FCDDF Must match regex: ^[a-fA-F\d]{8}(?:-[a-fA-F\d]{4}){3}-[a-fA-F\d]{12}$ Yes
frequency Sampling frequency of the data string
  • 12hr
  • 1day
  • 1yr
 Must match one of these regex:
  • ^fx$
  • ^subhr$
  • ^\d+min$
  • ^\d+hr$
  • ^\d+day$
  • ^\d+mon$
  • ^\d+yr$
  • ^\d+dec$
 Yes
geospatial_lat_max Specifies the northernmost latitude covered by the dataset. Units should be "degrees North". number
  • 90
  • 12.98
 Yes
geospatial_lat_min Specifies the southernmost latitude covered by the dataset. Units should be "degrees North". number
  • -90
  • -57.97
 Yes
geospatial_lat_units Units for the latitude axis described in "geospatial_lat_min" and "geospatial_lat_max" attributes. These should be "degrees_north". string degrees_north No
geospatial_lon_max Specifies the easternmost longitude covered by the dataset. Units should be "degrees East". Cases where geospatial_lon_min is greater than geospatial_lon_max indicate the bounding box extends from geospatial_lon_max, through the longitude range discontinuity meridian (e.g. the antimeridian for -180:180 values ranges) to geospatial_lon_min; for example, geospatial_lon_min=170 and geospatial_lon_max=-175 incorporates 15 degrees of longitude (ranges 170 to 180 and -180 to -175). number
  • 180
  • -152.61
 Yes
geospatial_lon_min Specifies the westernmost latitude covered by the dataset. Units should be "degrees East". See also geospatial_lon_max. number
  • -180
  • 88.48
 Yes
geospatial_lon_units Units for the longitude axis described in "geospatial_lon_min" and "geospatial_lon_max" attributes. These should be "degrees_east". string degrees_east No
grid Brief description of output grid characteristics or reference to grid specification. Should be included if the grid is not defined by the dimensions in the file. string No
license Information on the license for the data to ensure all users have access to the terms of use. Use SPDX license identifiers where possible. The default license for ACCESS-NRI is CC-BY-4.0, users should change as needed. string CC-BY-4.0 Yes
model Name of the model used to create the data string ACCESS-ESM1.6 Yes
model_version Version of the model used to create the data. Please note here if the model has been modified from an official release, ideally with links to the changes. string
  • 2025.06.001
  • 2025.06.001 (modified by John Smith, [link to repo/paper describing modifications])
 Yes
parent_experiment_branch_time The date and time this experiment branched from the parent. Follow CF variant of ISO 8601, i.e. 'YYYY-MM-DDTHH:MM:SSZ'. If this attribute is used, parent_experiment_uuid must be included too. string 2026-08-04T13:54:00Z Must match regex: ^\d{4}-(1[012]|0[1-9])-(3[01]|[12][0-9]|0[1-9])T([01][0-9]|2[0-3]):[0-5][0-9]:[0-5][0-9]Z$ No
parent_experiment_uuid The UUID of the parent experiment. If this attribute is used, parent_experiment_branch_time must be included too. string 698E600B-BECF-4CBA-994F-A663A22FCDDF Must match regex: ^[a-fA-F\d]{8}(?:-[a-fA-F\d]{4}){3}-[a-fA-F\d]{12}$ No
realm Realm where the data variable is defined string
  • atmos
  • landIce
 Must be one of the following:
  • aerosol
  • atmos
  • atmosChem
  • land
  • landIce
  • none
  • ocean
  • ocnBgchem
  • seaIce
  • unknown
 Yes
run_id Git hash for the commit associated with the experiment run string
  • 3a38fe4
  • 3a38fe435e156700ab649c4921e99f7c68a168bc
 Yes
title Name of the dataset. Typically following the Payu naming scheme detailed here - https://payu.readthedocs.io/en/stable/usage.html#experiment-names string my_expt-perturb-416af8c6 Yes
variable_id A list of short variable names, separated by commas, for the data variable/s that appear in this file (e.g. tas for surface temperature but not time/latitude/longitude). These names should match the netCDF variable names. string
  • tas
  • huss
  • uas,vas
 No

Variable Attributes

Variable attributes provide information on the data variable such as the units used, standard_name, or cell_methods used to generate the data. In netCDF files there can be multiple coordinate variables such as time, latitude, or time_bnds and the main output field variable of which there should be only one. Where possible variables and their attributes should follow CF-v1.11 conventions.

Title Description Type Examples
cell_methods A string comprising a list of space-separated pairs, "name:method", which indicate that for axis "name" the values representing the fields have been determined by "method". string
  • time: point
  • time: mean (interval: 1 hour)
  • time: maximum (interval: 1D) time: mean (interval: 1M)
long_name A long descriptive name which may, for example, be used for labelling plots. string
  • Near-Surface Air Temperature
  • latitude
  • Potential Evapotranspiration
standard_name Where possible use the CF standard_name of the variable, otherwise use a unique short phrase separated by underscores to describe the variable. string
  • air_pressure_at_sea_level
  • latitude
  • water_potential_evaporation_flux
units The units of measurement for the variable string
  • K
  • m-2 s-1

time and time_bnds

Variables describing the time dimension must be named time and have the following metadata:

Title Description Type Examples Required
axis Must have the value 'T' string T Yes
bounds Must have the value 'time_bnds' string time_bnds No
calendar Calendar defines the set of valid datetimes and their order. Follows the CF-Convention names using lower-case strings. It is recommended that "proleptic_gregorian" is used for data with leap days and "no_leap"/"365_day" for data without leap days. string Yes
long_name Must have the value 'time' string time Yes
standard_name Must have the value 'time' string time Yes
units Units for time should be given as "days since X" where X is a date (yyyy-mm-dd) or a datetime (yyyy-mm-dd HH:MM or yyyy-mm-dd HH:MM:SS) string
  • days since 0001-01-01 00:00:00
  • days since 0001-01-01 00:00
  • days since 1970-01-01
  • days since -5000-12-25
 Yes

Where possible, time variables will have their boundaries described by a time_bnds variable. The time_bnds variable itself will have no attributes.

Acknowledgements

We would like to acknowlege the specifications and conventions we have used and consulted to construct this specification and the tremendous work of their authors: