Sensor status within Argo data system: documentation

[tcarval]

The sensor status within Argo data system should be explicitely defined in §2.4.7.1.1.1" Float sensor status within Argo program"
This ticket is linked to #32

Sensor status within Argo data system
A sensor can have an “operational" or "experimental" Argo status.

If the sensor is an “operational" Argo”, it is registered in the R25 sensor table, its data are processed according to it's parameter's cookbook, its data are quality controlled as described in the parameter QC manual.

An "experimental" Argo sensor is registered in the R25 sensor table.
As "experimental", its parameters have not yet been described in a cookbook or QC manual.
Its data is distributed in the "aux" directory of the GDAC ("aux": auxiliary).
The sensor should be declared in the SPECIAL_FEATURES variable of the metadata file, it should contain the "aux" string (case insensitive).

Example of the RAMSES TRIOS hyperspectral radiometry: 7900563_meta.nc
SPECIAL_FEATURES = "THIS FLOAT HAS AUXILIARY SENSORS FOR HYPERSPECTRAL RADIOMETRIC MEASUREMENT."

[apswong]

I would suggest "operational Argo", instead of "official Argo".

Question: How do we structure R25 so that DACs are clear which sensor entry in R25 is "operational" or "pilot" or "experimental"?

Also, we need to specify the syntax in SPECIAL_FEATURES, so that it can accommodate multiple entries of the controlled vocal in R25, as well as other miscellaneous special features, in a way that each entry can be extracted for the purpose of monitoring.

[mscanderbeg]

I also like 'operational' better. I have seen an extensive list of SPECIAL_FEATURES syntax from coriolis and catherine schmectig.

[apswong]

We need to link to the Github discussion where the use of SPECIAL_FEATURES for recording experimental sensors is agreed.

[tcarval]

Yes, "operational Argo" is better than "official Argo", I change that term.
@vpaba, can we add an term "sensor_status" having two possible values : "operational" or "experimental"
In my opinion, "pilot" status is not necessary.

The SENSOR_MODEL is filled from R27, that is useful to monitor "operational" or "experimental" sensors.

In §"3.32 Reference table 32: SPECIAL_FEATURE", we can say that "A float having data in "aux" directory, should mention it with a sentence conraining "aux" (case insensitive).
Example : SPECIAL_FEATURES = "THIS FLOAT HAS AUXILIARY SENSORS FOR HYPERSPECTRAL RADIOMETRIC MEASUREMENT"

[tcarval]

We need to link to the Github discussion where the use of SPECIAL_FEATURES for recording experimental sensors is agreed.

Done (line 2 of the initial comment)

[tcarval]

ADMT-24 decision : use SPECIAL_FEATURES to provide information on "experimental" sensors.

• list the sensors with their NVS L22 entries

[vpaba]

Yes, "operational Argo" is better than "official Argo", I change that term. @vpaba, can we add an term "sensor_status" having two possible values : "operational" or "experimental" In my opinion, "pilot" status is not necessary.

@tcarval do you mean to create a new collection to host these two terms? My understanding from the ADMT-24 recordings is that the proposed solution would be to leave R25 for operational sensors only, and to use sensor models from L22 to populate the SPECIAL_FEATURES variable when AUX sensors are present.

Is a new collection on NVS for 'operational' and 'experimental' still required however? Thank you

[apswong]

@vpaba @tcarval
I don't think the classification of "operational" and "experimental" in R25 is needed anymore.
We will insert a new paragraph in the Users Manual to clarify the agreement from ADMT24, which is that "operational" sensors are recorded in R25, and "experimental" sensors are to use L22.

[vpaba]

Thanks for the confirmation @apswong

Can this issue be considered resolved?

[SBS-EREHM]

I see that for AUX files, L22 should be used as the "experimental sensor" alternative to R25 to complete SENSOR_MODEL in the wmoid_meta_aux.nc file.

What about R27 (SENSOR_MODEL)?

For example, in the case of FLUOROMETER_CHL435, ultimately BOTH SENSOR and SENSOR_MODEL would change, e.g.,

• SENSOR = "FLUOROMETER_CHL435"
• SENSOR_MODEL = "ECO_FLBBFL_AP2" or "ECO_FLBBFL" (like ECO_FLBBCD and ECO_FLBBCD_AP2 today)
• PARAMETER = "CHL435"

Can anyone clarify?

[apswong]

@SBS-EREHM : good question.

@tcarval : Does the agreement to only allow "operational sensors" in R25 need to be extended to only allow "operational sensor models" in R27?

[SBS-EREHM]

@apswong It seems that L22 is more geared to the specific SENSOR_MODEL, i.e., an experimental alternative to R27.

It doesn't seem like we have a "experimental alternative" for the more generic SENSOR (i.e., an experimental alternative to R25).

[HCBScienceProducts]

I thought the idea of the aux files was that they fulfill the IOC resolution requirements (notably making all data freely available that originate from Argo floats) for sensors that the Argo data management has not (yet or never) taken on the responsibility to deal with. As such, I had the impression that aux file content is in fact unconstrained and can be anything provided by the float operator (ranging from text files, netcdfs, or whatever they chose). There is no file checks on the aux files. While there's been some (great and to imitate) practice to mimic operational-Argo style in the aux files, this is not a per-se requirement. It (only) becomes for Argo data management a requirement to deal with experimental sensors and their meta data and data structure/storage once they move to pilot/operational status (i.e., move to the regular Argo data files). So I'd say: (1) There is no constraints or vocabulary being enforced in any aux file. (2) Sounds good that R25/R27 are only for operational (and pilot) sensors/sensor models. (3) There is no need to have duplicate/separate vocabularies that mirrors R25/R27 for experimental sensors. But put in your files whatever you find useful (and would think would fly within R25/R27 later down the road?), or is available from a (recommended) alternative (e.g., L22).

[HCBScienceProducts]

That said, how do we deal with multi-channel/multi-parameter sensors (like FLBBFL), which have both operational (*FLBB*FL) and experimental (FLBB*FL*) measurements? For the operational PARAMETERs CHLA and BBP<nnn> to be able to appear in the operational Argo files, the R25/R27-based SENSOR/SENSOR_MODEL entries need be specified for these multi-channel sensors, doesn't it? While the experimental PARAMETER CHLA435 ends up in the aux files, without R25/R27-based/'arbitrary' SENSOR entries. Opinions?

[tcarval]

Can we agree on this chapter to be added in the Argo user's manual

2.4.7.1.1 Float sensor status within Argo program
A sensor can have an “operational Argo” status, an “Argo pilot” status, or be designated as “experimental”.

If the sensor is an “operational Argo”, it must be registered in the R25 sensor table, and its data must be processed according to the cookbook and QC manual for sensor-derived parameters.

If the sensor is an Argo pilot, it must be registered in the R25 sensor table. As a pilot, its parameters have not yet been described in a cookbook or QC manual. Its data is distributed through the regular data system.

If the sensor is experimental: no R25 declaration, no cookbook, no manual. The sensor should be declared in the SPECIAL_FEATURES variable of the metadata file.

[HCBScienceProducts]

Hi Thierry, can we please wait with these updates to the Argo documents until the "Framework for adding new sensors and parameters to Argo" got approved? Particularly, without the framework approved, it is not yet fully clear what will be requirements to enter the pilot phase in terms of "data management viability". And we want to avoid to have contradicting information in Argo's documents.

[tcarval]

Yes, let's wait for the framework to be approved.