Clarify in which unit oxygen has to be used, calculated, reported and achieved

[soerenthomsen]

I think we have to be very clear how oxygen measurements have to be reported and state it somewhere at the beginning citing the corresponding papers/SCOR reports (Bittig et al. 2016) and Bittig 2018.

And we have to ensure that this unit is used throughout the whole document too.

This also relates to @ptestor comment that 7.1. is very short. I don't want to repeat what Henry wrote down nicely in in 2018 paper https://www.frontiersin.org/articles/10.3389/fmars.2017.00429/full section 5.1 and 5.2 but maybe we can think of where to place a 3 liner section to direct the reader to this very important information.

The unit μmol O2 kg−1 is the unit of choice for oceanic applications because of its independence of temperature and pressure, both of which will change the concentration when expressed in a volumetric unit even without any production or consumption of oxygen. To allow using of O2 as a conservative tracer for ocean mixing and advection, μmol O2 kg−1 is the recommended unit for oceanic applications and used by all larger observing systems (see, e.g., documentation for GO-SHIP and Biogeochemical-Argo, Hood et al., 2010, and Thierry et al., 2016).

[patricialg]

I can add a text in setion 3. Pre-deployment operations and calibrations. We can add a section to discuss this since it will be used along the whole document (maybe a section 3.2 before Sensor confirmguration for deployment).

[soerenthomsen]

Thanks @patricialg. I think this should be clarified as early as possible maybe even in the introduction before any unit's etc are actually used or? But just very (!) short and refer to Bittig2018.

@tomhull what do you think?

[tomhull]

I agree with Henry that umol kg-1 is best for reporting final values, it also indicates at a glance that a salinity and pressure correction has been applied. However, I think users of the SOP need to be familiar with converting between umol L-1 and kg-1 as well. As most if not all of the oxygen sensors report this unit.

[soerenthomsen]

How could we organise this without repeating all the work Henry did already in the publications for the Argo community?

[soerenthomsen]

Input by John Allen, SOCIB, Spain

`It has come to my attention that the issue of how oxygen concentration should be reported has been raised yet again.

Let me be very clear and please ask for my opinion to at least be placed on record, i really want to avoid problems with archived datasets that might be very hard to overcome.

Firstly let us separate two things

1) The presentation of oxygen concentration in published manuscripts

2) The publication of archived oxygen datasets for F.A.I.R use and legacy value.

I can fully understand why it might generally be preferable to calculate and quote oxygen data in a mass/mass basis in situation 1) above, peer reviewed publication. In this case the calculation should be carried out according to best practises, firstly removing the rather inaccurate Oxygen Temperature reference and applying a properly synchronised CTD Temperature reference and secondly determining water potential density from CTD temperature (converted to potential temperature) and well calibrated Delayed Mode CTD salinity.

However, from the point of view in 2), of an archived dataset for FAIR use and legacy value, Oxygen concentration must be recorded as mass/volume and Oxygen Temperature must be recorded alongside this so that contamination by incorrectly calibrated or not yet Delayed Mode calibrated CTD data is avoided. To do otherwise would be equivalent to archiving salinity but not conductivity, and i certainly hope no one would contemplate that.

I hope this is helpful very best regards

John `

[soerenthomsen]

@gkrahmann how are you handling this at GEOMAR?

@silviepouliquen, @cgourcuf and @catsch could you also give input here from your ARGO experience maybe?

[gkrahmann]

GEOMAR's practice is to store oxygen as umol/kg in the final archived product. This final product always includes the CTD data, so that oxygen can be reverted back to umol/l , which is the output unit of the software developed by Johannes Hahn and Henry Bittig. It is also probably the unit of what an optode actually 'sees' and what its calibration coefficients are derived for. In our case the integrity of the final product and the documentation of the software used to calculate the density is essential to be able to properly revert back to umol/l.

Actually in our processing the conversion from umol/l to umol/kg is done in the last step just before writing the files. Internally in the processing all calculations are in umol/l. FWIW The world ocean database has for its latest incarnation (2018) converted all oxygen values from ml/l to umol/kg. They state that they used a constant (potential???) density of 1025 kg/m^3. So there seems to be this tendency in data centers to move towards umol/kg.

I see three solutions:

• store both umol/l and umol/kg and document the conversion
• store umol/kg and document the conversion
• store umol/l and document a (suggested) conversion

But we should always remember that the accuracy of the optode measurements is limited. In my experience that is a larger source of uncertainty than any differences in unit conversions.

[cgourcuf]

I agree with Gert and I think this is also the way Coriolis computes and stores oxygen data both for gliders & Argo. @catsch & @vracape can you confirm? I used to think the same way as John, until I realised that oxygen in umol/l depends on Salinity anyway (salinity compensation).

[catsch]

@cgourcuf, I confirm that in Argo the final product is umol/kg

[tomhull]

Just for reference, the UEA toolbox converts to umol/kg about half-way through the processing steps, after salinity compensation. So the calibration against winklers is done in umol/kg.

Internally my own tools operate the same as Gert, using mmol m-3 and converting to umol/kg when archiving. For air-sea gas exchange stuff mmol m-3 is convenient.

To comment John Allen's note (and as noted by @cgourcuf). If the idea is that data can be reprocessed easily then oxygen temperature is insufficient, you would need salinity as well. I think in practice this always happens anyway.

To properly reprocess data you would need to have the calibration coefficients, phase, whichever temperature was used and salinity. assuming we're talking about optodes only.