Calculating in-air gain when there is DOXY variable in traj file without PPOX_DOXY

[cgrdn]

The traj files (currently BRtraj, but the B- and R- files are being updated/merged in version 3.2, will create a separate issue for handling that) contain the in-air data recorded by an oxygen optode. In some cases they have the variable PPOX_DOXY, or partial pressure of oxygen. This is great and easy to work with because it is the same unit as the calculation using NCEP reference data, so the gain calculation is straightforward.

In other cases though, there is no PPOX_DOXY variable, just a DOXY variable. I assume this is still an in-air measurement since it is in the BRtraj file, but the unit of DOXY is umol kg-1 (std. name moles_of_oxygen_per_unit_mass_in_sea_water). So, my current solution is to convert this to partial pressure, by first converting to mmol L-1, then to partial pressure using the translated SCOR WG 142 code. BUT, converting "in-air" "per seawater" oxygen doesn't really make sense? For going from umol kg-1, you have to multiply by density, and so you have to provide a temperature, T, salinity, S, and pressure, P. I can provide temperature with the variable TEMP_DOXY, and for now I am setting S=0 and P=0, but I'm not sure that really makes sense.

To properly understand this unit, I think I would need to know how the DAC went from phase (C2PHASE_DOXY) to DOXY for the in-air data in order to match their assumptions when calculating density. Plan moving forward will be to look at BRtraj files that have both, and see if I can match the conversion of DOXY to PPOX_DOXY.

@richardsc do you make anything of this? Or could you take a quick read just to see if my train of thought seems right? Thanks.

Messy block of code for the situation I am describing:

if 'PPOX_DOXY' in BRtraj_nc.variables.keys():
    floatData['PPOX_DOXY']  = BRtraj_nc.variables['PPOX_DOXY'][:].data.flatten()
elif 'DOXY' in BRtraj_nc.variables.keys():
    # unit conversion from umol kg-1 to pO2, some shaky S and P assumptions?
    floatData['PPOX_DOXY'] = unit.doxy_to_pO2(unit.umol_per_sw_to_mmol_per_L(
        BRtraj_nc.variables['DOXY'][:].data.flatten(),
        0, # salinity is 0 in air???
        BRtraj_nc.variables['TEMP_DOXY'][:].data.flatten(),
        0 # pressure is 0 in air???
    ), 0, BRtraj_nc.variables['TEMP_DOXY'][:].data.flatten())

[cgrdn]

Comment from Henry Bittig:

in air measurements are indicated by the appropriate measurement codes, not by presence or absence of PPOX_DOXY. So this is a no-issue of your QC tool, but rather the task of proper decoding by the DAC. Given that the trajectory file format will be changed soon, potentially some DACs have paused their implementation to wait for the change to one combined traj file V3.2. Details on the Measurement Codes to look out for can be found in the O2 documentation as well as the traj file documentation. From the O2 QC manual (http://dx.doi.org/10.13155/46542):
--->
Moreover, in some cases, float equipped with an oxygen sensor acquired data while at the sea surface. Those data are stored in the trajectory file using the PPOX_DOXY variable and with the base measurement codes MC and associated relative measurement codes as follows:

• X – 10 = in-water samples, part of end of profile, shallower than nominal 10 dbar
• X + 10 = in-water samples, part of surface sequence (guidance for real-time: before air-bladder inflation / before max. buoyancy)
• X + 11 = in-air samples, part of surface sequence (guidance for real-time: after air-bladder inflation / after max. buoyancy)
• X – 1 = individual surface observations
  Data to include should all be in PPOX_DOXY. Users should be warned that the distinction between X–10, X+10, X+11 is known definitively for some floats (e.g. some newer Apf9i APEX with Optode), but is only a best guess estimate for other floats (e.g. PROVORs). The X + 10 / X + 11 codes apply only for X = 600 (AET), 700 (TST) and 800 (TET), i.e., when the float is at the surface.
  When those measurements are done in the air with Aanderaa optode, they are used to correct bias and drift if necessary. Those data are usable.

<---
Note that in a soon-to-become-effective update, base measurement code "100 (DST)" will become valid as well, i.e., surface in air measurements can not only occur at the end of a cycle (AET: Ascent end time; TST: Transition start time; TET: Transition end time), but also at the beginning of a new cycle (DST: Descent start time). To match in-air data with profile data for adequate carry-over correction, note that the nearest profile data for such descending air data is most likely from the previous cycle, not the current cycle (which acquires a profile in ~10 days).

[cgrdn]

This is on hold until a major update for the ver. 3.2 trajectory files. Will update comment after ADMT.