Guidelines for Argo floats
As profiling floats become more prevalent, scientists outside of estalished Argo National Programs are
considering adding their profiling floats to Argo. To address this, the Argo Steering Team (AST) and Argo Data
Management Team (ADMT) have developed a framework for entry into the Argo data stream based on Stages I - III. This page describes the guidelines for the Stages in more detail.
Stage III: Global Implementation and full acceptance into Argo data stream
The performance and accuracy of an approved sensor are fully characterized. There is a well-defined data quality control path for the data. Approved Argo sensors appear in the Argo Reference Tables (Ref Table #27) with sensor descriptions and measure accepted Argo parameters as identified in Reference Table 3 of the Argo User’s Manual and in an excel spreadsheet(http://www.argodatamgt.org/content/download/30910/209488/file/argo-parameters-list-core-and-b_CS_20180129.xlsx).
The AIC must be notified, including a full list of sensors, before any Argo float is deployed. At a minimum, Argo floats should measure temperature, salinity and pressure using accepted sensors that can meet Argo accuracy requirements. Target cycle time, maximum profile depth and park depth are 10 days, 2000 dbar, and 1000 dbar, respectively. The approved Argo parameters must meet general requirements related to data quality and management. At present, the only approved CTD is the SBE41 operating to 2000 dbar. The SBE61, SBE41 deployed deeper than 2000 dbar, and RBR CTDs are pilot sensors. The approved Core Argo variables are temperature, salinity, pressure and conductivity. The approved Biogeochemical (BGC) Argo variables are oxygen, chlorophyl, BBP, nitrate, pH and irradiance.
All general, data quality and management requirements listed in the tables below must also be met. For BGC Argo floats, the additional DAC requirements for data beyond core must also be met.
Stage II: Global Pilot and qualified distribution on Argo data stream
A sensor has been developed, for either an existing parameter, or to measure a new parameter, and has been shown to have the potential to meet Argo requirements for accuracy and quality control procedures. This sensor is also likely to be mounted on a significant fraction of the Argo fleet. A Pilot Study using these sensors should be proposed to the AST. This study should be large enough to qualify the new sensor over different oceanographic conditions. The necessary description of the sensor and the measured parameters, meta and technical data should be proposed to the ADMT. If the Pilot Study is approved, the data from these sensors will be stored in the main Argo NetCDF formatted files, but they will be grey listed, with a quality flag of 2 or 3. The QC flag can be improved in delayed-mode, if the Argo data system agrees that the data are good.
All general requirements listed in the tables below must be met. Data quality and management requirements listed in table below should be in progress. For BGC Argo floats, the additional DAC requirements for data beyond core must also be met.
Stage I: Experimental deployments and distribution in the Auxiliary directory
An experimental sensor has been mounted on an Argo float with an accepted CTD sensor, but its performance and accuracy have not been determined. If mounted on an Argo float, the data from the accepted sensors are included at the GDACs in Argo NetCDF format. Experimental data are placed in the 'aux' directory at the GDAC. Experimental sensors can also be tested outside of Argo.
To satisfy the Argo requirement that all measurements are transparent and available to the public and to minimize the burden on the ADMT, Argo has formed an Auxiliary directory at the Argo GDACs that will distribute, but not curate this data. Documentation describing the contents and means to access the data in these directories is mandatory and the responsibility of the float provider. The float provider also needs to provide contact information where users can direct questions regarding the data. If over time the experimental sensors are shown to meet Argo's requirements or form part of a new global mission, a case for approval needs to be made to the AST and IOC to include these into the Argo data stream.
For accepted sensors on experimental floats, all general, data quality and management requirements listed in the tables below must also be met. For BGC Argo floats, the additional DAC requirements for data beyond core must also be met.
Data from experimental sensors must meet Auxiliary directory requirements.
Argo general and data quality and management requirements
||Who oversees this requirement?
The float and its data are consistent with Argo governance (IOC XX-6; IOC-EC_XLI.4)
It is the PI's responsibility to ensure that floats are managed according to Argo governance.
This includes using national points of contact for notifying float deployments and drifting into EEZs.
||AIC will monitor consistency with Argo governance.
If the float does not conform, AIC will notify national points of contact, who will take whatever
action is necessary.|
The float has a contact point for its entire lifetime, and for the data processing after the float is dead
The AIC requires a contact point for all floats identified as Argo floats by their WMO number. Where individuals'
responsibilities change within national programs and research groups, contact points must be maintained.
PIs must consider the long-term ownership of and responsibility for their floats. It is possible that 'ownership' of
a float could be passed to a contact in a national program, but this should be planned before the float becomes part of Argo.
||Points of contact in the national program of the PI deploying the float.
Where AIC is uncertain of a contact point, AIC will refer to points of contact in the relevant national program.|
The float PI will recover the float safely if beached
Once a float is part of Argo, the PI must remain responsible for the float or identify delegated responsibility,
throughout the float lifetime. The float cannot stop being an Argo float because it has drifted out of a PI's area of interest, or
fulfilled the PI's initial purpose. It may or may not be possible to delegate this responsibility to points of contact in national programs.
||AIC, supported by national points of contact.|
||Who oversees this requirement?
The data have established end-to-end pathway
Before a Principal Investigator proposes to their national program that a float will become an Argo float, there must be an agreed pathway
This should be in place when a float is notified to Argo Information Centre (AIC) and added to the
Argo data system, which is the moment at which a float becomes an Argo float.
- data telemetry to a real time DAC
- preparation of real time files for the GTS and submission to GDAC through an existing DAC that include all telemetered parameters
- Real Time Quality Control (RTQC) procedures for all parameters
- a pathway to agreed Delayed-Mode Quality Control (DMQC) procedures for all parameters
- a DMQC group identified and funded for all approved parameters
- a commitment by a DMQC group for long-term curation of the data, with the ability to respond to evolving
requirements from ADMT.
|The person making the notification to AIC.
If this is an established Argo point of contact,
it is the notifying person's responsibility to be sure everything is in place.
If a float is notified to AIC from a
new source, the AIC should check that the PI is ready to fulfill these obligations.
The data meet Argo targets for accuracy and vertical sampling characteristics
New sensors that measure parameters already established in the Argo system must have been demonstrated to meet Argo
targets for accuracy. This can be established through peer-reviewed papers. Vertical sampling
must be appropriate. Where no published statements of requirement exist, the AST or ADMT will evaluate proposals or
develop statements of requirement.
||AST advised by ADMT|
The PI has agreed data management arrangements with a recognized Argo DAC and delayed-mode group,
including the supply of all technical and metadata
The PI is advised to negotiate the pathway for real time and delayed mode activities with one of the recognized Argo DACs
before stating in funding applications that floats will be a contribution to Argo. This includes timely delivery of
appropriate technical and metadata. Argo DACs may require funding for extra staff time to handle extra floats, sensors and parameters.
||Real Time DACs will ensure the necessary arrangements are in place before starting to accept data from new floats.
This should be agreed between RT DACs and float PIs before the float is deployed or notified.|
Addition of new sensors and parameters on floats in the Argo data system requires endorsement from the AST & ADMT
Argo requires all data from all sensors on an Argo float to be made available at the Argo GDACs. The list of
Argo PARAM names (Reference Table 3 in the Argo User's Manual)
cannot be allowed to grow indiscriminately without undermining the Argo data system.
The AST and ADMT should only endorse the addition of new sensors and new parameters when there is a reasonable future
prospect of those sensors being deployed in sufficient numbers and with appropriate global distribution.
The PI must supply the variables names for data sent by additional sensors and not included in
Reference Table 3 of the Argo User's Manual.
||AST advised by ADMT|
Argo DAC requirements for data beyond core data
In order to accept data for distribution on the Argo GDACs that originate beyond the core
temperature, salinity, pressure and BGC (oxygen, chlorophyl, BBP, nitrate, pH and irradiance) data from standard and BGC mission Argo floats deployed by national programs,
a DAC must ascertain that:
||Who oversees this requirement?
There are sufficient resources to manage and archive these data in perpetuity according to evolving ADMT requirements
As Argo has evolved, the ADMT has agreed to a number of changes to the Argo data system. The most recent major
change was the introduction of v3 format NetCDF files, with substantial impact on the contents and storage of
profile, trajectory, technical and metadata. DACs have had to bear the burden of updating or converting legacy
files in the Argo archive. Lesser examples include reprocessing data to review
TNPD floats and requests for
more complete metadata on sensors. The burden is disproportionately large for floats that lie outside the
core T/S/P capability. DACs and PIs need to consider the long-term responsibility for float data before a
float can be accepted into the Argo system.
DACs will ensure the necessary arrangements are in place before starting to accept data from new floats.
This should be agreed between DACs and float PIs before the float is deployed or notified.|
A delayed-mode group has agreed to perform calibration and quality control in perpetuity
From time to time, the ADMT has asked DACs to revisit DMQC for the approved variables in the light of new insight into sensor
behaviour. Floats must have a plan for long-term responsibility, so that floats do not become 'orphans'.
DACs should ensure they know who is responsible for short- and long-term DMQC for all floats that fall in
their directory at the GDAC. This should be agreed between DACs and float PIs before the float is deployed
Sufficient meta data are provided by the PI.
PIs must undertake to provide to the DAC whatever metadata are defined from time to time as mandatory by the ADMT.
DACs should notify national points of contact of any floats that do not conform to the ADMT's metadata requirements.|