6 Metadata format version 3.2

The format version 3.2 of Argo metadata will replace version 3.1 gradually. During the transition period, all formats will be valid.

An Argo metadata file contains descriptive information about an Argo float.

For file naming conventions, see §4.1.

All variables are mandatory when not otherwise stated in the comment column of the tables.

6.1 Global attributes

The global attributes section is used for data discovery. It complies with NetCDF Climate and Forecast (CF) Metadata Conventions (version 1.6).

http://cfconventions.org/

The following global attributes should appear in the global section (attributes in italic are optional attributes):

// global attributes:

:title = “Argo float metadata file”;

:institution = “CSIRO”;

:source = “Argo float”;

:history = “2011-04-22T06:00:00Z creation”;

:references = “http://www.argodatamgt.org/Documentation”;

:id = “https://doi.org/10.17882/42182”

:comment = “free text”;

:user_manual_version = “3.45”;

:Conventions = “Argo-3.2 CF-1.6”;

Global attribute name	Definition
title	A succinct description of what is in the dataset.
institution	Specifies where the original data was produced.
source	The method of production of the original data. If it was model-generated, source should name the model and its version, as specifically as could be useful. If it is observational, source should characterize it (e.g., “surface observation” or “radiosonde”).
history	Provides an audit trail for modifications to the original data. Well-behaved generic NetCDF filters will automatically append their name and the parameters with which they were invoked to the global history attribute of an input NetCDF file. We recommend that each line begins with a timestamp indicating the date and time of day that the program was executed.
references	Published or web-based references that describe the data or methods used to produce it.
id	The Argo GDAC data DOI: https://doi.org/10.17882/42182 This attribute is optional but highly recommended
comment	Miscellaneous information about the data or methods used to produce it.
user_manual_version	The version number of the user manual
Conventions	The conventions supported by this file, blank separated

6.2 Dimensions and definitions

Name	Definition	Comment
DATE_TIME	DATE_TIME = 14;	This dimension is the length of an ASCII date and time value. Date_time convention is : YYYYMMDDHHMISS YYYY : year MM : month DD : day HH : hour of the day MI : minutes SS : seconds Date and time values are always in universal time coordinates (UTC). Examples : 20010105172834 : January 5th 2001 17:28:34 19971217000000 : December 17th 1997 00:00:00
STRING8192 STRING4096 STRING1024 STRING256 STRING128 STRING64 STRING32 STRING17 STRING16 STRING8 STRING4 STRING2	STRING8192 = 8192; STRING4096 = 4096; STRING1024 = 1024; STRING256 = 256; STRING128 = 128; STRING64 = 64; STRING32 = 32; STRING17 = 17; STRING16 = 16; STRING8 = 8; STRING4 = 4; STRING2 = 2;	String dimensions from 2 to 8192. STRING4096 and STRING8192 are optional (see §2.4.8)
N_PARAM	N_PARAM = <int value>;	Number of parameters measured or calculated for a pressure sample. Examples : (pressure, temperature) : N_PARAM = 2 (pressure, temperature, salinity) : N_PARAM = 3 (pressure, temperature, conductivity, salinity) : N_PARAM = 4
N_SENSOR	N_SENSOR = <int value>;	Number of sensors mounted on the float and used to measure the parameters.
N_CONFIG_PARAM	N_CONFIG_PARAM=<int value>;	Number of configuration parameters.
N_LAUNCH_CONFIG_PARAM	N_LAUNCH_CONFIG_PARAM=<int value>;	Number of pre-deployment or launch configuration parameters.
N_MISSIONS	N_MISSIONS=<unlimited>;	Number of missions.
N_POSITIONING_SYSTEM	N_POSITIONING_SYSTEM=<int value>;	Number of positioning systems.
N_TRANS_SYSTEM	N_TRANS_SYSTEM=<int value>;	Number of transmission systems.

6.3 General information on the metadata file

This section contains information about the whole file.

Name

Definition

Comment

DATA_TYPE

char DATA_TYPE(STRING16);

DATA_TYPE:long_name = “Data type”;

DATA_TYPE:conventions = “Argo reference table 1”;

DATA_TYPE:_FillValue = ” “;

This field contains the type of data contained in the file.

The list of acceptable data types is in the reference table 1 (https://vocab.nerc.ac.uk/collection/R01/).

For the metadata file, the value must be set to “Argo meta-data”

FORMAT_VERSION

char FORMAT_VERSION(STRING4);

FORMAT_VERSION:long_name = “File format version”;

FORMAT_VERSION:_FillValue = ” “;

File format version.

Example: “3.2”

~~HANDBOOK_VERSION~~

~~char HANDBOOK_VERSION(STRING4);~~

~~HANDBOOK_VERSION:long_name = “Data handbook version”;~~

~~HANDBOOK_VERSION:_FillValue = ” “;~~

REMOVED in meta FORMAT_VERSION 3.2: ~~Version number of the data handbook. This field indicates that the data contained in this file are managed according to the policy described in the Argo data management handbook.~~

~~Example: “1.0”~~

DATE_CREATION

char DATE_CREATION(DATE_TIME);

DATE_CREATION:long_name = “Date of file creation”;

DATE_CREATION:conventions = “YYYYMMDDHHMISS”;

DATE_CREATION:_FillValue = ” “;

Date and time (UTC) of creation of this file.

Example: “20011229161700” (meaning December 29th 2001 16:17:00)

DATE_UPDATE

char DATE_UPDATE(DATE_TIME);

DATE_UPDATE:long_name = “Date of update of this file”;

DATE_UPDATE:conventions = “YYYYMMDDHHMISS”;

DATE_UPDATE:_FillValue = ” “;

Date and time (UTC) of update of this file.

Example: “20011230090500” (meaning December 30th 2001 09:05:00)

6.4 Float characteristics

This section contains the main characteristics of the float.

Name

Definition

Comment

PLATFORM_NUMBER

char PLATFORM_NUMBER(STRING8);

PLATFORM_NUMBER:long_name = “Float unique identifier”;

PLATFORM_NUMBER:conventions = “WMO float identifier : A9IIIII”;

PLATFORM_NUMBER:_FillValue = ” “;

WMO float identifier. WMO is the World Meteorological Organization. This platform number is unique.

Example: 6900045

PLATFORM_WIGOS_ID

char PLATFORM_WIGOS_ID(STRING17);

PLATFORM_WIGOS_ID:long_name = “Float unique identifier”;

PLATFORM_WIGOS_ID:conventions = “WMO WIGOS float identifier: 0-22000-0-A9IIIII”;

PLATFORM_WIGOS_ID:_FillValue = ” “;

~~This is an optional variable.~~

WMO WIGOS float identifier. WMO is the World Meteorological Organization.

This platform number is unique within all observation platforms. For Argo floats, it is composed of “0-22000-0-”, the Argo float prefix, followed by the WMO ID.

For example, for float 6900045:

PLATFORM_WIGOS_ID = “0-22000-0-6900045”

PTT

char PTT(STRING256);

PTT:long_name = “Transmission identifier (ARGOS, ORBCOMM, etc.)”;

PTT:_FillValue = ” “;

Transmission identifier of the float. Comma separated list for multi-beacon transmission.

Examples:

“22507” (example when the float is equipped with one ARGOS beacon)

“22598, 22768” (example when the float is equipped with 2 ARGOS beacons)

TRANS_SYSTEM

char TRANS_SYSTEM(N_TRANS_SYSTEM, STRING16);

TRANS_SYSTEM:long_name = “Telecommunication system used”;

TRANS_SYSTEM:_FillValue = ” “;

Name of the telecommunication system from reference table 10 (https://vocab.nerc.ac.uk/collection/R10/).

Example: “ARGOS”

TRANS_SYSTEM_ID

char TRANS_SYSTEM_ID(N_TRANS_SYSTEM, STRING32);

TRANS_SYSTEM_ID:long_name = “Program identifier used by the transmission system”;

TRANS_SYSTEM_ID:_FillValue = ” “;

Program identifier of the telecommunication subscription. DACs can use N/A or alternative of their choice when not applicable (e.g. : Iridium or Orbcomm)

Example: 38511 is a program number for all the beacons of an ARGOS customer.

TRANS_FREQUENCY

char TRANS_FREQUENCY(N_TRANS_SYSTEM, STRING16);

TRANS_FREQUENCY:long_name = “Frequency of transmission from the float”;

TRANS_FREQUENCY:units = “hertz”;

TRANS_FREQUENCY:_FillValue = ” “;

Frequency of transmission from the float.

Example: “1/44”

POSITIONING_SYSTEM

char POSITIONING_SYSTEM(N_POSITIONING_SYSTEM, STRING8);

POSITIONING_SYSTEM:long_name = “Positioning system”;

POSITIONING_SYSTEM:_FillValue = ” “;

Position system from reference table 9 (https://vocab.nerc.ac.uk/collection/R09/). ARGOS or GPS are 2 positioning systems.

Example: “ARGOS”

PLATFORM_FAMILY

char PLATFORM_FAMILY(STRING256);

PLATFORM_FAMILY:long_name = “Category of instrument”;

PLATFORM_FAMILY:conventions = “Argo reference table 22”;

PLATFORM_FAMILY:_FillValue = ” “;

Category of instrument.

See Argo reference table 22 (https://vocab.nerc.ac.uk/collection/R22/).

Example: “FLOAT”

PLATFORM_TYPE

char PLATFORM_TYPE(STRING32);

PLATFORM_TYPE:long_name = “Type of float”;

PLATFORM_TYPE:conventions = “Argo reference table 23”;

PLATFORM_TYPE:_FillValue = ” “;

Type of float.

See Argo reference table 23 (https://vocab.nerc.ac.uk/collection/R23/).

Example: “APEX”

PLATFORM_MAKER

char PLATFORM_MAKER(STRING256);

PLATFORM_MAKER:long_name = “Name of the manufacturer”;

PLATFORM_MAKER:conventions = “Argo reference table 24”;

PLATFORM_MAKER:_FillValue = ” “;

Name of the manufacturer.

See Argo reference table 24 (https://vocab.nerc.ac.uk/collection/R24/).

Example: “TWR”

FLOAT_FIRMWARE_VERSION

char FLOAT_FIRMWARE_VERSION(STRING64);

FLOAT_FIRMWARE_VERSION:long_name = “Firmware version for the float”;

FLOAT_FIRMWARE_VERSION:_FillValue = ” “;

The float firmware version. This is specified as per the format on the manufacturer’s manual.

char FLOAT_FIRMWARE_VERSION(STRING32) is also accepted.

Example: “072804”

FLOAT_MANUAL_VERSION

char FLOAT_MANUAL_VERSION(STRING16);

FLOAT_MANUAL_VERSION:long_name = “Manual version for the float”;

FLOAT_MANUAL_VERSION:_FillValue = ” “;

The version date or number for the manual for each float.

char FLOAT_MANUAL_VERSION(STRING128) is also accepted.

Example: “110610”, “004”

FLOAT_SERIAL_NO

char FLOAT_SERIAL_NO(STRING32);

FLOAT_SERIAL_NO:long_name = “Serial number of the float”;

FLOAT_SERIAL_NO:_FillValue = ” “;

This field should contain only the serial number of the float.

Example: “1679”

STANDARD_FORMAT_ID

char STANDARD_FORMAT_ID(STRING16);

STANDARD_FORMAT_ID:long_name = “Standard format number to describe the data format type for each float”;

STANDARD_FORMAT_ID:_FillValue = ” “;

Standardized format number as described in the online reference table: https://docs.google.com/spreadsheets/d/16iTji2i9tLh2PfiiMItfhaQybQB1NLAhj4s0mDML5yY/edit#gid=9

This table cross references to individual DAC format numbers.

Example: “1010151”

DAC_FORMAT_ID

char DAC_FORMAT_ID(STRING16);

DAC_FORMAT_ID:long_name = “Format number used by the DAC to describe the data format type for each float”;

DAC_FORMAT_ID:_FillValue = ” “;

Format numbers used by individual DACs to describe each float type.

This is cross-referenced to a standard format id as outlined in the online reference table: https://docs.google.com/spreadsheets/d/16iTji2i9tLh2PfiiMItfhaQybQB1NLAhj4s0mDML5yY/edit#gid=9

Example: “A9”

WMO_INST_TYPE

char WMO_INST_TYPE(STRING4);

WMO_INST_TYPE:long_name = “Coded instrument type”;

WMO_INST_TYPE:conventions = “Argo reference table 8”;

WMO_INST_TYPE:_FillValue = ” “;

Instrument type from WMO code table 1770. A subset of WMO table 1770 is documented in the reference table 8 (https://vocab.nerc.ac.uk/collection/R08/).

Example: “846” (corresponding to Webb Research float, Seabird sensor)

PROJECT_NAME

char PROJECT_NAME(STRING64);

PROJECT_NAME:long_name = “Name of the project”;

PROJECT_NAME:_FillValue = ” “;

Name of the project that operates the float. Multiple projects are separated by commas.
Example: “GYROSCOPE, GMMC”

PROGRAM_NAME

char PROGRAM_NAME(STRING64);

PROGRAM_NAME:long_name = “Name of the program”;

PROGRAM_NAME:_FillValue = ” “;

This variable becomes mandatory in meta version 3.2.

The overarching program(s) of which the float is a part. A program consists of a set of related and possibly interdependent projects (PROJECT_NAME) that meet an overarching objective. A program defines a group of floats managed by the same lead agency. It materializes the implementing, operating, and responsible team.

The PROGRAM_NAME list is managed by OceanOPS. Detailed definition of PROGRAM_NAME is available here: https://www.ocean-ops.org/metadata/#concept-definitions.

See Argo reference table 41 (https://vocab.nerc.ac.uk/collection/R41/).

Examples: “Argo INDIA” or “Argo UK Bio” or “Argo UW”

DATA_CENTRE

char DATA_CENTRE(STRING2);

DATA_CENTRE:long_name = “Data centre in charge of float real-time processing”;

DATA_CENTRE:conventions = “Argo reference table 4”;

DATA_CENTRE:_FillValue = ” “;

Code of the data centre in charge of the float data management. The data centre codes are described in the reference table 4 (https://vocab.nerc.ac.uk/collection/R04/).

Example: “ME” (for MEDS)

PI_NAME

char PI_NAME (STRING64);

PI_NAME:long_name = “Name of the principal investigator”;

PI_NAME:_FillValue = ” “;

Name of the principal investigator responsible for the profiling float. Valid PI names are listed in reference table 40 (https://vocab.nerc.ac.uk/collection/R40/). The generic convention to follow is “Firstname1 [Firstname2] LASTNAME”. Multiple names can be concatenated, separated by commas.

Example: “Julia UITZ, Birgit KLEIN”

ANOMALY

char ANOMALY(STRING256);

ANOMALY:long_name = “Describe any anomalies or problems the float may have had”;

ANOMALY:_FillValue = ” “;

This field describes any anomaly or problem the float may have had.

This field is also used to record ending causes (see §3.29).

Example: “the immersion drift is not stable.”

BATTERY_TYPE

char BATTERY_TYPE(STRING64);

BATTERY_TYPE:long_name = “Type of battery packs in the float”;

BATTERY_TYPE:_FillValue = ” “;

Describes the type of battery packs in the float.

BATTERY_TYPE syntax uses both reference table 33 altLabel (https://vocab.nerc.ac.uk/collection/R33/) and reference table 34 altLabel (https://vocab.nerc.ac.uk/collection/R34/) with the following convention: <R33-battery_maker> <R34-battery_type> <voltage> V [+<R33-battery_maker> <R34-battery_type> <voltage> V].

<voltage> stands for the initial battery voltage.

Examples:

“ELECTROCHEM Lithium 15.0 V”

“TADIRAN Lithium 15 V + TADIRAN Lithium 12.1 V”

BATTERY_PACKS

char BATTERY_PACKS(STRING64);

BATTERY_PACKS:long_name = “Configuration of battery packs in the float”;

BATTERY_PACKS:_FillValue = ” “;

Describes the configuration of battery packs in the float, number and type.

BATTERY_PACKS uses both reference table 35 altLabel (https://vocab.nerc.ac.uk/collection/R35) and reference table 34 prefLabel (https://vocab.nerc.ac.uk/collection/R34/) with the following convention: <x><R35-battery_size> <R34-battery_type> [+<x><R35-battery_size> <R34-battery_type>].

<x> indicates the number of packs (not the number of batteries in a pack).

“U” standing for “unknown” is also accepted.

Example: “4DD Li + 1C Alk”

CONTROLLER_BOARD_TYPE_PRIMARY

char CONTROLLER_BOARD_TYPE_PRIMARY(STRING32);

CONTROLLER_BOARD_TYPE_PRIMARY:long_name = “Type of primary controller board”;

CONTROLLER_BOARD_TYPE_PRIMARY:_FillValue = ” “;

Describes the type of controller board. See reference table 28 (https://vocab.nerc.ac.uk/collection/R28/) for the left part of the variable. An optional free text within square brackets can be appended to detail the firmware version of the controller board.

Example: “APF9 [iridium version xyz]”

CONTROLLER_BOARD_TYPE_SECONDARY

char CONTROLLER_BOARD_TYPE_SECONDARY(STRING32);

CONTROLLER_BOARD_TYPE_SECONDARY:long_name = “Type of secondary controller board”;

CONTROLLER_BOARD_TYPE_SECONDARY:_FillValue = ” “;

This is an optional variable.

Only applicable if there is more than one controller board in the float. Describes the second type of controller board. See reference table 28 (https://vocab.nerc.ac.uk/collection/R28/) for the left part of the variable. An optional free text within square brackets can be appended to detail the firmware version of the controller board.

Example: “APF9 [iridium version xyz]”

CONTROLLER_BOARD_SERIAL_NO_PRIMARY

char CONTROLLER_BOARD_SERIAL_NO_PRIMARY(STRING32);

CONTROLLER_BOARD_SERIAL_NO_PRIMARY:long_name = “Serial number of the primary controller board”;

CONTROLLER_BOARD_SERIAL_NO_PRIMARY:_FillValue = ” “;

The serial number for the primary controller board.

Example: “4567”

CONTROLLER_BOARD_SERIAL_NO_SECONDARY

char CONTROLLER_BOARD_SERIAL_NO_SECONDARY(STRING32);

CONTROLLER_BOARD_SERIAL_NO_SECONDARY:long_name = “Serial number of the secondary controller board”;

CONTROLLER_BOARD_SERIAL_NO_SECONDARY:_FillValue = ” “;

This is an optional variable.

Only applicable if there is more than one controller board in the float. The serial number for the secondary controller board.

Example: “4571”

SPECIAL_FEATURES

char SPECIAL_FEATURES(STRING1024);

SPECIAL_FEATURES:long_name = “Extra features of the float (algorithms, compressee etc.)”;

SPECIAL_FEATURES:_FillValue = ” “;

Additional float features can be specified within this variable. These features can be (e.g.):

specific algorithms (such as ISA)
Specific materials
Specific sensor/parameter, for which data is in the auxiliary repository.

N.B.: when there are AUX data files, the SPECIAL_FEATURE variable must be filled by the DAC. In this case, the string must include the substring ‘AUX’ for machine parsing (more details in https://argo.ucsd.edu/data/auxiliary-directory).

Examples:

Algorithms: “Ice Sensing Algorithm”, “Interim Storage Algorithm”, “grounding avoidance”

Materials: “compressee” (buoyancy compensator), “ARVOR DEEP 2 HEAD WITH ADDITIONAL RBR SN 205111 CTD PROBE”.

Specific sensor/parameters: ” THIS FLOAT HAS AUXILIARY SENSORS FOR HYPERSPECTRAL RADIOMETRIC MEASUREMENT”, “AUXILIARY_SENSOR_FLOATRIDER”

FLOAT_OWNER

char FLOAT_OWNER (STRING64);

FLOAT_OWNER:long_name = “Float owner”;

FLOAT_OWNER:_FillValue = ” “;

The owner of the float (may be different from the data centre and operating institution).

Example: “Joe Blogg”

OPERATING_INSTITUTION

char OPERATING_INSTITUTION(STRING64);

OPERATING_INSTITUTION:long_name = “Operating institution of the float”;

OPERATING_INSTITUTION:_FillValue = ” “;

The operating institution of the float (may be different from the float owner and data centre).

Example: “ACE CRC”

CUSTOMISATION

char CUSTOMISATION(STRING1024);

CUSTOMISATION:long_name = “Float customisation, i.e. (institution and modifications)”;

CUSTOMISATION:_FillValue = ” “;

Free form field to record changes made to the float after manufacture and before deployment, i.e. this could be the customisation institution plus a list of modifications.

Example: “Float stability collar removed for deployment in ice.”

6.5 Float deployment and mission information

Name

Definition

Comment

LAUNCH_DATE

char LAUNCH_DATE(DATE_TIME);

LAUNCH_DATE:long_name = “Date (UTC) of the deployment”;

LAUNCH_DATE:conventions = “YYYYMMDDHHMISS”;

LAUNCH_DATE:_FillValue = ” “;

Date and time (UTC) of launch of the float.

Format : YYYYMMDDHHMISS

Example: “20011230090500” (meaning December 30^th 2001 03:05:00)

LAUNCH_LATITUDE

double LAUNCH_LATITUDE;

LAUNCH_LATITUDE:long_name = “Latitude of the float when deployed”;

LAUNCH_LATITUDE:units = “degree_north”;

LAUNCH_LATITUDE:_FillValue = 99999.;

LAUNCH_LATITUDE:valid_min = -90.;

LAUNCH_LATITUDE:valid_max = 90.;

Latitude of the launch as a real number between -90 and 90.

Unit : degree north

Example: 44.4991 (corresponding to 44° 29’ 56.76’’ N)

LAUNCH_LONGITUDE

double LAUNCH_LONGITUDE;

LAUNCH_LONGITUDE:long_name = “Longitude of the float when deployed”;

LAUNCH_LONGITUDE:units = “degree_east”; LAUNCH_LONGITUDE:_FillValue = 99999.;

LAUNCH_LONGITUDE:valid_min = -180.;

LAUNCH_LONGITUDE:valid_max = 180.;

Longitude of the launch as a real number between -180 and 180.

Unit : degree east.

Example: 16.7222 (corresponding to 16° 43’ 19.92’’ E)

LAUNCH_QC

char LAUNCH_QC;

LAUNCH_QC:long_name = “Quality on launch date, time and location”;

LAUNCH_QC:conventions = “Argo reference table 2”;

LAUNCH_QC:_FillValue = ” “;

Quality flag on launch date, time and location.

The flag scale is described in the reference tables 2 (https://vocab.nerc.ac.uk/collection/RR2/ for real time and https://vocab.nerc.ac.uk/collection/RD2/ for delayed mode).

Example: “1” (meaning launch location seems correct)

START_DATE

char START_DATE(DATE_TIME);

START_DATE:long_name = “Date (UTC) of the first

descent of the float”;

START_DATE:conventions = “YYYYMMDDHHMISS”; START_DATE:_FillValue = ” “;

Date and time (UTC) of the first descent of the float.

Format : YYYYMMDDHHMISS

Example: “20011230090500” (meaning December 30^th 2001 06:05:00)

START_DATE_QC

char START_DATE_QC;

START_DATE_QC:long_name = “Quality on start date”;

START_DATE_QC:conventions = “Argo reference table 2”;

START_DATE_QC:_FillValue = ” “;

Quality flag on start date. The flag scale is described in the reference tables 2 (https://vocab.nerc.ac.uk/collection/RR2/ for real time and https://vocab.nerc.ac.uk/collection/RD2/ for delayed mode).

Example: “1” (meaning start date seems correct)

STARTUP_DATE

char STARTUP_DATE(DATE_TIME);

STARTUP_DATE:long_name = “Date (UTC) of the activation of the float”;

STARTUP_DATE:conventions = “YYYYMMDDHHMISS”; STARTUP_DATE:_FillValue = ” “;

Date and time (UTC) of the activation of the float before or just after deployment. This may include automatic startup during pressure activation.

Format : YYYYMMDDHHMISS

Example: “20011230090500” (meaning December 30^th 2001 06:05:00)

STARTUP_DATE_QC

char STARTUP_DATE_QC;

STARTUP_DATE_QC:long_name = “Quality on startup date”;

STARTUP_DATE_QC:conventions = “Argo reference table 2”;

STARTUP_DATE_QC:_FillValue = ” “;

Quality flag on startup date. The flag scale is described in the reference tables 2 (https://vocab.nerc.ac.uk/collection/RR2/ for real time and https://vocab.nerc.ac.uk/collection/RD2/ for delayed mode).

Example: “1” (meaning startup date seems correct)

DEPLOYMENT_PLATFORM

char DEPLOYMENT_PLATFORM(STRING128);

DEPLOYMENT_PLATFORM:long_name = “Identifier of the deployment platform”;

DEPLOYMENT_PLATFORM:_FillValue = ” “;

Identifier of the deployment platform, i.e. vessel or ship name, followed by the associated C17 url when it exists (in that case, the platform name must follow the C17 prefLabel spelling - in particular, do not use R/V, RV, etc. prefixes).

char DEPLOYMENT_PLATFORM(STRING32) is also accepted.

Example: “Ronald H. Brown uri:http://vocab.nerc.ac.uk/collection/C17/current/33RO/”

DEPLOYMENT_CRUISE_ID

char DEPLOYMENT_CRUISE_ID(STRING32);

DEPLOYMENT_CRUISE_ID:long_name = “Identification number or reference number of the cruise used to deploy the float”;

DEPLOYMENT_CRUISE_ID:_FillValue = ” “;

Identification number or reference number of the cruise used to deploy the platform.

Whenever this is possible, indicate an url allowing direct access to the cruise information.

Example: “POMME2”

DEPLOYMENT_REFERENCE_STATION_ID

char DEPLOYMENT_REFERENCE_STATION_ID(STRING256);

DEPLOYMENT_REFERENCE_STATION_ID:long_name = “Identifier or reference number of co-located stations used to verify the first profile”;

DEPLOYMENT_REFERENCE_STATION_ID:_FillValue = ” “;

Identifier or reference number of co-located CTD or XBT stations used to verify the first profile.

Whenever this is possible, indicate an url allowing direct access to the reference data.

Examples : “58776”, “58777”, “https://data-selection.odatis-ocean.fr/coriolis/uri/p87075054”

DEPLOYMENT_COMMENT

char DEPLOYMENT_COMMENT(STRING4096);

DEPLOYMENT_COMMENT:long_name = “Float deployment comment”;

DEPLOYMENT_COMMENT:_FillValue = ” “;

This is an optional variable.

It is used to record information (usually received from deployment team/crew) such as weather conditions, deployment delays or issues, etc.

Example: “One of the side CTD red plugs was off the tube when box was opened”,

“Icebergs floating by overcast”

END_MISSION_DATE

char END_MISSION_DATE(DATE_TIME);

END_MISSION_DATE:long_name = “Date (UTC) of the

end of mission of the float”;

END_MISSION_DATE:conventions = “YYYYMMDDHHMISS”;

END_MISSION_DATE:_FillValue = ” “;

Date (UTC) of the end mission of the float.

Format : YYYYMMDDHHMISS

Example: “20011230090500” (meaning December 30^th 2001 03:05:00)

END_MISSION_STATUS

char END_MISSION_STATUS;

END_MISSION_STATUS:long_name = “Status of the end of mission of the float”;

END_MISSION_STATUS:conventions = “T:No more transmission received, R:Retrieved”;

END_MISSION_STATUS:_FillValue = ” “;

Status of the end of the float’s deployment.

Example: “T”

6.6 Configuration parameters

This section describes the configuration parameters for a float. It is important to note that configuration parameters are float settings selected by the PI, not measurements reported by the float.

Configuration parameters may or may not be reported by a float.

Configuration parameter names are identified by the “CONFIG” prefix.

For each configuration parameter, the name and the value of the parameter are recorded.

Name

Definition

Comment

LAUNCH_CONFIG_PARAMETER_NAME

char LAUNCH_CONFIG_PARAMETER_NAME(N_LAUNCH_CONFIG_PARAM, STRING128)

LAUNCH_CONFIG_PARAMETER_NAME:long_name = “Name of configuration parameter at launch”;

LAUNCH_CONFIG_PARAMETER_NAME:_FillValue = ” “;

Name of the configuration parameter; pre-deployment or launch settings.

See reference table 18 (https://vocab.nerc.ac.uk/collection/R18/) for standard configuration parameter names.

Example: “CONFIG_ParkPressure_dbar”

LAUNCH_CONFIG_PARAMETER_VALUE

float (for standard Argo floats) or can use double if applicable (e.g. BGC-Argo float) LAUNCH_CONFIG_PARAMETER_VALUE(N_LAUNCH_CONFIG_PARAM)

LAUNCH_CONFIG_ PARAMETER_VALUE:long_name = “Value of configuration parameter at launch”;

LAUNCH_CONFIG_ PARAMETER_VALUE:_FillValue = 99999.f;

Value of the configuration parameter; either pre-deployment or launch settings.

Example: 1500

CONFIG_PARAMETER_NAME

char CONFIG_PARAMETER_NAME(N_CONFIG_PARAM, STRING128)

CONFIG_PARAMETER_NAME:long_name = “Name of configuration parameter”;

CONFIG_PARAMETER_NAME:_FillValue = ” “;

Name of the configuration parameter; mission settings.

See reference tables 18 (https://vocab.nerc.ac.uk/collection/R18/) for standard configuration parameter names.

Example:

“CONFIG_ParkPressure_dbar”

CONFIG_PARAMETER_VALUE

float (for standard Argo floats) or can use double if applicable (e.g. BGC-Argo float) CONFIG_PARAMETER_VALUE(N_MISSIONS, N_CONFIG_PARAM)

CONFIG_ PARAMETER_VALUE:long_name = “Value of configuration parameter”;

CONFIG_ PARAMETER_VALUE:_FillValue = 99999.f;

Value of the configuration parameter; mission settings.

Example: 1500

CONFIG_MISSION_NUMBER

int CONFIG_MISSION_NUMBER(N_MISSIONS);

CONFIG_MISSION_NUMBER:long_name = “Unique number denoting the missions performed by the float”;

CONFIG_MISSION_NUMBER:conventions = “1…N, 1 : first complete mission”;

CONFIG_MISSION_NUMBER:_FillValue = 99999;

Unique number of the mission to which this profile belongs.

See note on floats with multiple configurations §2.4.6.1.

The number 0 (zero) can be used to denote the float’s mission prelude, if it exists.

CONFIG_MISSION_COMMENT

char CONFIG_MISSION_COMMENT(N_MISSIONS, STRING256)

CONFIG_MISSION_COMMENT:long_name = “Comment on configuration”;

CONFIG_MISSION_COMMENT:_FillValue = ” “;

Comment on this configuration mission.

Example: “This mission follows a 1000 dbar meddy during parking”

All parameter names are standardized and are available in the online reference table 18 (https://vocab.nerc.ac.uk/collection/R18/).

The configuration table 18 contains both Core Argo configuration parameters (Identifier starting with CC*, or AltLabel starting with “Core Config”) and BGC-Argo sensor configuration parameters (Identifier starting with CB*, or AltLabel starting with “BGC Config”). If you are a new user or have only standard Argo floats you should first check the Core Argo configuration parameters list which has the basic set of configuration parameters that caters for most of the standard float types. If your float carries additional BGC-Argo sensors you will also need to refer to the BGC-Argo sensor configuration parameters list. To request for new configuration parameter names, please either send an e-mail to the table responsible(s), who are mentioned in the readme of ArgoVocab Github, or open a new AVFTT ticket (https://github.com/OneArgo/ArgoVocabs/issues).

The mission settings or parameter values are recorded as numbers (the NetCDF field type is float). In this scheme, strings will need to be converted to numbers and will require numeric codes for the relevant parameters. How to translate back these numeric codes to a string value is detailed in the definition field of https://vocab.nerc.ac.uk/collection/R18/. Only a few existing parameters are concerned. If new floats with new configuration parameters (as strings) are introduced, then equivalent numeric codes must also be added to the table by the proposer of the new configuration parameter.

The mission is used to record information that changes from cycle to cycle, for instance when a float changes its mission from 3 shallow profiles to 1 deep profile. The shallow and deep profiles will have different mission numbers. The value of the mission number is recorded in CONFIG_MISSION_NUMBER.

Configuration parameters are separated into two types.

1) Pre-deployment or launch configuration parameters that are the ‘configured’ start settings of the float and the initial mission configuration parameters for the first cycle. These parameters with the dimension N_LAUNCH_CONFIG_PARAM, are stored in LAUNCH_CONFIG_PARAMETER_NAME and LAUNCH_CONFIG_PARAMETER_VALUE.

2) After deployment,configuration parameters define float behavior for each mission, including all applicable mandatory and highly-desirable parameters and any other parameters that change during the life of the float are reported as mission settings. These parameters with the dimension N_CONFIG_PARAM, need to be reported in the CONFIG_PARAMETER_NAME and CONFIG_PARAMETER_VALUE variables. The mission parameters for the first cycle must also be reported in the launch section.

The parameter CONFIG_MISSION_COMMENT can be used to store information about the mission or whether the mission was set pre-deployment or transmitted by the float (free form field).

6.6.1 Note on floats with multiple missions

Typically, an Argo float configuration is valid for the whole life of the float. Each cycle is repeated with the same behavior (one configuration).

However, some floats may be configured to change their behavior from cycle to cycle (multiple configurations).

When there is only one configuration, CONFIG_MISSION_NUMBER is set to 1: all the cycles are programmed to be the same. Note that in this case; floats will still have a set of pre-deployment/launch configuration information that contains all the start settings for the float. So for a float with one basic mission, it will have launch configuration parameters and mission 1 configuration parameters (typically just the mission critical subset).

When there are multiple configurations, the configuration from the first cycle has CONFIG_MISSION_NUMBER set to 1. Each subsequent configuration change will be recorded as additional entries in CONFIG_MISSION_NUMBER, with the value increased sequentially by the integer one. All variables from mission 1 must be repeated in subsequent missions. Floats with multiple configurations still record pre-deployment or launch information in: LAUNCH_CONFIG_PARAMETER_NAME and LAUNCH_CONFIG_PARAMETER_VALUE.

Argo best practice, and our recommendation to users, is a minimum of configuration missions. If there is a change to one or more of the configuration parameters that does not repeat a previous configuration then a new mission number must be used. If the configuration parameters change, but mirror a previous mission then that mission number should be re-used. In extremely complex cases where mission changes are unclear, then a new mission number can be used for each cycle. Users should be aware that the metafile will need to be rewritten each time a new mission number is added.

Some floats conduct a pressure-activated test mission after deployment (i.e. some SOLO floats) where they essentially ‘wake-up’ at depth and return to the surface. This is not a normal mission in any way, and the floats do not use their configuration parameters in this first ‘test’ cycle. In this case you would assign a fill value to CONFIG_MISSION_NUMBER.

6.6.2 Determining which mission applies to a particular float cycle

Users are able to determine which mission applies to each cycle by looking at the CONFIG_MISSION_NUMBER(N_CYCLE) variable in the trajectory files, and the CONFIG_MISSION_NUMBER(N_PROF) variable in the profile files.
See section “§2.2.4 General information for each profile” and “§2.3.6 N_CYCLE dimension variable group”).

Example

In the above example, there are 3 different float behaviors to record, (with park depth varying between 1500, 2000 and 1700 db). Each of these new behaviors requires a new mission number. This is in addition to the pre-deployment or launch information:

CONFIG_PARAMETER_NAME = “CONFIG_ParkPressure_dbar”
CONFIG_PARAMETER_VALUE = “1500”
CONFIG_MISSION_NUMBER = 1

CONFIG_PARAMETER_NAME = “CONFIG_ParkPressure_dbar”
CONFIG_PARAMETER_VALUE = “2000”
CONFIG_MISSION_NUMBER = 2

CONFIG_PARAMETER_NAME = “CONFIG _ParkPressure_dbar”
CONFIG_PARAMETER_VALUE = “1700”
CONFIG_MISSION_NUMBER = 3

A further example for a float with multiple missions and changes to multiple configuration parameters is shown below.

In this example there are 11 pre-deployment/launch configuration parameters for this float which are set before launch. Of this set, the last four are mission critical parameters that change and control float behavior; these are reported in subsequent missions (missions 1 to n). For this float, the depth, at which the float parks, changes in missions 2 and 3 (with changes in two configuration parameters). For mission 4, the park depth stays the same as for mission 3 but now the park sampling period has changed. For mission 5, the park sampling period changes again. All configuration parameters from mission 1 must still be reported for each subsequent mission, even those that do not change.

Configuration parameter names from reference table 18 LAUNCH_CONFIG_PARAMETER_NAME(N_LAUNCH_CONFIG_PARAM,STRING128) * N_LAUNCH_CONFIG_PARAM = int value	Pre-deployment or launch configuration settings LAUNCH_CONFIG_PARAMETER_VALUE(N_LAUNCH_CONFIG_PARAM) * float or double depending on data type
CONFIG_PistonPositionPressureActivation_COUNT	100
CONFIG_Direction_NUMBER	1*
CONFIG_AscentToSurfaceTimeout_hours	3
CONFIG_MissionPreludeTime_hours	3
CONFIG_MeasureBattery_LOGICAL	0**
CONFIG_IceDetection_DegC	-1.78
CONFIG_CycleTime_hours	240
CONFIG_ParkPressure_dbar	1000
CONFIG_ProfilePressure_dbar	2000
CONFIG_ParkSamplingPeriod_hours	10
CONFIG_PistonPark_COUNT	111
…	…

(*): 1 = Ascending, 2 = Descending

(**): 0 = No, 1 = Yes

Configuration parameter names (from reference table 18a or 18b) CONFIG_PARAMETER_NAME(N_CONFIG_PARAM,STRING128)	Mission configuration settings at sea CONFIG_PARAMETER_VALUE(N_MISSIONS,N_CONFIG_PARAM)
CONFIG_MISSION_NUMBER	1	2	3	4	5	…
CONFIG_ParkPressure_dbar	1000	1500	1700	1700	1000	…
CONFIG_ProfilePressure_dbar	2000	2000	2000	2000	2000	…
CONFIG_ParkSamplingPeriod_hours	10	10	10	15	17	…
CONFIG_PistonPark_COUNT	111	75	53	53	45	…
…	…	…	…	…	…	…

6.6.3 Highly desirable configuration parameters

Highly desirable configuration parameters should be correctly filled according to the following table.

Highly desirable configuration parameter	Format	Example
CONFIG_CycleTime_hours CONFIG_CycleTime_days	Duration of a cycle	240
CONFIG_ParkPressure_dbar	Park pressure	1900
CONFIG_ProfilePressure_dbar	Profile pressure	2000

6.7 Float sensor and parameter information

A sensor is a device used to measure a physical parameter. Sensor outputs are provided in parameter counts and need to be converted into parameter physical units using a calibration equation. This conversion can be done onboard the float or during the decoding process.

A parameter is a measurement of a physical phenomenon; it can be provided by a sensor (in sensor counts or in physical units) or computed (derived) from other parameters.

A sensor can measure 1 to N parameter(s). A parameter can be measured by 1 or N sensor(s).

6.7.1 Float sensor information

This section contains information about the sensors of the profiler.

A list of standardized Argo sensor names is given in reference table 25 (https://vocab.nerc.ac.uk/collection/R25/).

Each ocean state parameter recorded in an Argo profile or trajectory file must be considered its own sensor in this context. This is necessary to record the sensor serial numbers, etc. Thus a CTD which records PRES, TEMP, and PSAL should be considered 3 separate sensors (CTD_PRES, CTD_TEMP, CTD_CNDC respectively), as all 3 parameters are reported in the Argo profile and trajectory files. In comparison, an OPTODE only has DOXY reported in Argo NetCDF files, thus it should be considered a single sensor (OXYGEN_OPTODE or OXYGEN_ELECTROCHEMICAL) even though the sensor also reports TEMP_DOXY. All intermediate variables that do not appear in the core Argo files, even though they may appear in the ‘raw’ form (i.e. in the BGC-Argo B-file), do not have to be listed as a separate sensor. This is especially true if there is not a unique serial number for the sensor.

Name

Definition

Comment

SENSOR

char SENSOR(N_SENSOR, STRING32);

SENSOR:long_name = “Name of the sensor mounted on the float”;

SENSOR:conventions = “Argo reference table 25”;

SENSOR:_FillValue = ” “;

Name of the sensor mounted on the float See reference table 25 (https://vocab.nerc.ac.uk/collection/R25/).

For multiple sensors, follow §3.25.1 rule.

Examples: “CTD_PRES”, “CTD_TEMP”, “CTD_CNDC”, “OPTODE_DOXY”.

SENSOR_MAKER

char SENSOR_MAKER(N_SENSOR, STRING256);

SENSOR_MAKER:long_name = “Name of the sensor manufacturer”;

SENSOR_MAKER:conventions = “Argo reference table 26”;

SENSOR_MAKER:_FillValue = ” “;

Name of the manufacturer of the sensor. See reference table 26 (https://vocab.nerc.ac.uk/collection/R26/).

Example: “SBE”

SENSOR_MODEL

char SENSOR_MODEL(N_SENSOR, STRING256);

SENSOR_MODEL:long_name = “Type of sensor”;

SENSOR_MODEL:conventions = “Argo reference table 27”;

SENSOR_MODEL:_FillValue = ” “;

Name of the model of the sensor, as defined by the sensor manufacturer. See reference table 27 (https://vocab.nerc.ac.uk/collection/R27/)

Example: “SBE41CP”

SENSOR_SERIAL_NO

char SENSOR_SERIAL_NO(N_SENSOR, STRING16);

SENSOR_SERIAL_NO:long_name = “Serial number of the sensor”;

SENSOR_SERIAL_NO:_FillValue = ” “;

Serial number of the sensor.

Example: “2646 036 073”

SENSOR_VERTICAL_PRES_OFFSET

float SENSOR_VERTICAL_PRES_OFFSET(N_SENSOR);

SENSOR_VERTICAL_PRES_OFFSET:long_name = “vertical pressure offset due to the fact that the sensor is not at same vertical position as the CTD sensor”;

SENSOR_VERTICAL_PRES_OFFSET:units = “dbar”

SENSOR_VERTICAL_PRES_OFFSET:convention = “The value is negative when above the CTD and positive when below the CTD”

SENSOR_VERTICAL_PRES_OFFSET:_FillValue = 99999;

Distance (in equivalent dbar) from the sensor to the main CTD sensor. The conversion approximation will be 1m = 1dbar. The approximation error remains below the pressure sensor accuracy.

The sign convention is negative when the sensor is above the main CTD and positive otherwise. Thus, an addition between PRES and SENSOR_VERTICAL_PRES_OFFSET yields the pressure at which the sensor performs its measurement.

For the main CTD sensor, the value would be 0.

Example: 0.2

SENSOR_FIRMWARE_VERSION

char SENSOR_FIRMWARE_VERSION (N_SENSOR, STRING32)

SENSOR_FIRMWARE_VERSION :long_name = “Firmware version of the sensor”;

SENSOR_FIRMWARE_VERSION :_FillValue = ” “;

This variable becomes mandatory in meta version 3.2.

Firmware version of the sensor.

If the firmware version is unknown or not applicable, use the variable fillvalue ” “.

Example: “1.141”

6.7.2 Float parameter information

This section contains information about the parameters measured by the profiler or derived from profiler measurements.

Name

Definition

Comment

PARAMETER

char PARAMETER(N_PARAM, STRING64);

PARAMETER:long_name = “Name of parameter computed from float measurements”;

PARAMETER:conventions = “Argo reference table 3”;

PARAMETER:_FillValue = ” “;

Names of the parameters measured by float sensors or derived from float measurements.

The parameter names are listed in reference table 3 (https://vocab.nerc.ac.uk/collection/R03/).

For multiple sensors and parameters, follow §3.3.1 rule.

Examples :

TEMP, PSAL, PRES

TEMP : temperature in Celsius

PSAL : practical salinity in psu

PRES: pressure in dbar

PARAMETER_SENSOR

char PARAMETER_SENSOR(N_PARAM, STRING128);

PARAMETER_SENSOR:long_name = “Name of the sensor that measures this parameter”;

PARAMETER_SENSOR:conventions = “Argo reference table 25”;

PARAMETER_SENSOR:_FillValue = ” “;

Names of the sensors that measured the float parameters.

See Argo reference table 25 (https://vocab.nerc.ac.uk/collection/R25/).

Example: CTD_PRES, CTD_TEMP, CTD_CNDC, OXYGEN_OPTODE.

This field is used to match up fields with dimension N_PARAMETER to fields with dimension N_SENSOR. For this to work, SENSOR and PARAMETER fields must have unique entries. See §3.3.1 and §3.25.1 for rules applicable to handle multiple sensors and parameters.

PARAMETER_UNITS

char PARAMETER_UNITS(N_PARAM, STRING32);

PARAMETER_UNITS:long_name = “Units of accuracy and resolution of the parameter”;

PARAMETER_UNITS:_FillValue = ” “;

Units of accuracy and resolution associated with the values in PARAMETER_ACCURACY and PARAMETER_RESOLUTION fields.

PARAMETER_UNITS are provided by the manufacturers, and can be different from the units used in R03.

Example: “psu”

PARAMETER_ACCURACY

char PARAMETER_ACCURACY(N_PARAM, STRING32);

PARAMETER_ACCURACY:long_name = “Accuracy of the parameter”;

PARAMETER_ACCURACY:_FillValue = ” “;

Accuracy of the parameter.

Example: “8 micromole/l” or “5%”

PARAMETER_RESOLUTION

char PARAMETER_RESOLUTION(N_PARAM, STRING32);

PARAMETER_RESOLUTION:long_name = “Resolution of the parameter”;

PARAMETER_RESOLUTION:_FillValue =” “;

Resolution of the parameter returned by the sensor (note that this is not necessarily equivalent to the resolution of the parameter returned by the float through telemetry).

Example: “0.001 micromole/l”

6.8 Float predeployment calibration information

This section contains information about the calibration of the profiler. The calibration described in this section is an instrumental calibration, performed mainly by the sensor manufacturer. The delayed mode calibration, performed by a data analysis, is described in the profile file (see Section §2.2.6).

The PREDEPLOYMENT_CALIB_* parameters in the table below link to the PARAMETER variable listed in §2.4.7.2. It is critical that these are ordered in the same way so that calibration information is assigned to the correct parameter.

Name

Definition

Comment

PREDEPLOYMENT_CALIB _EQUATION

char PREDEPLOYMENT_CALIB_EQUATION(N_PARAM, STRING1024);

PREDEPLOYMENT_CALIB_EQUATION:long_name = “Calibration equation for this parameter”;

PREDEPLOYMENT_CALIB_EQUATION:_FillValue = ” “;

Calibration equation for this parameter.

The syntax should follow §2.4.8.1 guidelines.

The exact syntax and equation(s) are mentioned in the cookbooks related to the parameter (the profile/meta/tech cookbook https://dx.doi.org/10.13155/41151 for core parameters, and the BGC cookbook suite as indicated in https://www.argodatamgt.org/Documentation.html for BGC parameters). The cookbook information must be followed.

char PREDEPLOYMENT_CALIB_EQUATION(N_PARAM, STRING4096) is also accepted.

Example: “Tc = a1 * T + a0”

PREDEPLOYMENT_CALIB_COEFFICIENT

char PREDEPLOYMENT_CALIB_COEFFICIENT(N_PARAM, STRING1024);

PREDEPLOYMENT_CALIB_COEFFICIENT:long_name = “Calibration coefficients for this equation”;

PREDEPLOYMENT_CALIB_COEFFICIENT:_FillValue = ” “;

Calibration coefficients for this equation.

The syntax should follow §2.4.8.2 guidelines.

The exact syntax and coefficient list(s) are mentioned in the cookbooks related to the parameter (same list as for PREDEPLOYMENT_CALIB _EQUATION). The cookbook information must be followed.

char PREDEPLOYMENT_CALIB_COEFFICIENT(STRING8192) and char PREDEPLOYMENT_CALIB_COEFFICIENT(STRING4096) are also accepted.

Example: “a1=0.99997 , a0=0.0021”

PREDEPLOYMENT_CALIB_DATE

char

PREDEPLOYMENT_CALIB_DATE(N_PARAM, DATE_TIME);

PREDEPLOYMENT_CALIB_DATE:long_name = “Date and time (UTC) of calibration”;

PREDEPLOYMENT_CALIB_DATE:conventions = “YYYYMMDDHHMISS”;

PREDEPLOYMENT_CALIB_DATE:_Fill Value = ” “;

Calibration date for the sensor that measures this parameter. If date only is known, pad with zeros for HHMISS.

Example: “20010203000000” (meaning Feb 3rd 2001)

PREDEPLOYMENT_CALIB_COMMENT

char PREDEPLOYMENT_CALIB_COMMENT(N_PARAM, STRING1024);

PREDEPLOYMENT_CALIB_COMMENT:long_name = “Comment applying to this parameter calibration”;

PREDEPLOYMENT_CALIB_COMMENT:_FillValue = ” “;

Comments applying to this parameter calibration.

char PREDEPLOYMENT_CALIB_COMMENT(STRING4096) is also accepted.

6.8.1 PREDEPLOYMENT_CALIB _EQUATION SYNTAX GUIDELINES

Calculation symbols used in PREDEPLOYMENT_CALIB_EQUATION

Symbol	Meaning
=	Equal
- , + , / , *	Minus, plus, divide, multiply
log , log10, exp	Natural logarithm, Base-10 logarithm, exponential (power of e)
^	Power function
SUM	Sum
( )	Indicators of grouping or enclosing or delimiters of index
.	Decimal separator
>= , <= , > , <	Greater than or equal to, less than or equal to, greater than, less than

Punctuation used in PREDEPLOYMENT_CALIB_EQUATION

Symbol	Meaning
,	Separates out extra information in a sentence
;	Separates different sets of equation
:	Before an equation that follows an explanation sentence
.	Marks the end of the sentence

Order of presentation

The equation is presented in the following order:

Elementary pieces of calculation are first presented
Then intermediary equations
Then the final equation

The final equation can be completed by comments to give some guidance.

Example from the “Processing BGC-Argo nitrate

concentration at the DAC Level” document (https://dx.doi.org/10.13155/46121) :

“NITRATE= MOLAR_NITRATE/rho*1000, where rho is the potential density [kg/m^3] calculated from the CTD data.”

6.8.2 PREDEPLOYMENT_CALIB _COEFFICIENT SYNTAX GUIDELINES

Symbols used in PREDEPLOYMENT_CALIB_COEFFICIENT

Symbol	Meaning
=	Separates the name and the value for a key-value pair
,	Separates different key-value pairs (name/value) of coefficients for the same equation
;	Separates different sets of key-value pairs (name/value) of coefficients for different equations
.	Decimal separator
[ ]	To indicate an array of coefficients (e.g., to record spectrum coefficients)

Notes on reporting PREDEPLOYMENT_CALIB_COEFFICIENT

For reporting PREDEPLOYMENT_CALIB_COEFFICIENT

The exact name used in PREDEPLOYMENT_CALIB_EQUATION (including spelling and lower or upper case) should be reported in the key-value pairs
If possible, the key-value pairs should be presented in the same order as they appear in PREDEPLOYMENT_CALIB_EQUATION (n.b.: a possible exception to this recommendation could relate to, e.g., grouping the spectrum values to ease readability)

Parsing order:

1. ”;”

2. “,”

3. “=”