Add dive/yo/profile number definition

[callumrollo]

moderator: @OceanGlidersCommunity/format-maintainers

Is your feature request related to a problem? Please describe.

Gliders a profiling platforms which spend most of their operational time going up and down the water column in a series of dives/profiles/yos. We have defined phase, we should also define these variables

Is this related to a specific platform models

Glider agnostic

Describe the solution you'd like

1. Vocabulary terms for dive/profile/yo to be added
2. Guidance added to the document on how the term(s) should be used

[MOchiara]

I am not sure we need to have 'yo' too. I see 'yo' as the same as dive so a full navigation cycle, i.e the glider goes through all the phases. We need to agree on where the split of profiles occur. Does the surface data during comms for example belong to climb or dive and same for apogee. Where do we want the split of dives to happen? Do we discard apogee and surface from the profile data?

The split of dives, I guess, is just dictated by the different files. If this is the case, then do all the 3 (4 with Spray) do the split of files at the same point?

SeaExplorer splits the files right after the GPS fix, for example

[callumrollo]

All good questions! I just stuck profile, dive and yo in the description as these are terms I've seen used in the community.

We should define some standard that makes sense for all glider platforms that the format supports. We don't need to define how the dive/profile numbers are calculated (e.g. how seaexplorer splits after GPS). But, we do need to define standardised names and nomencalture for this.

consider e.g. a glider going surface >> apogee >> surface >> apogee >> surface (completing two full dive cyclesI) is this:

dive_number: 1,1,2,2
profile_number:1,2,3,4

Or

dive_number: 1,1.5,2,2.5
profile_number:1,2,3,4

Or some other method? Is the dive number ever NaN? Must it increase monotonically throughout the dataset? (e.g. a glider on nrt sending back data from every 10th dive cycle, are these dives 1,2,3 or 1, 11, 21 etc.)

Lots to consider!

[callumrollo]

Should we consult the published literature? Ask big users? follow existing formats like EGO/IOOS glider format?

[MOchiara]

Yeah all all very fair points!
I will have a think and read a bit around and see what I can come up with!
I personally prefer both profile and dive number to be integers. I feel like dive number should be a unique ID for both dive and climb and if we use the '.5' the we are sort of repeating the use of profile number. Plus, the user has to round the number in case they want to identify the exact dive number or grid by dive

In terms of the nomenclature for nrt and delayed mode data, this is also worth having a think. I found it confusing at the beginning when I was calling dive 2 in delayed was not the same as dive 2 in nrt but it also makes sense to count them differently

[emmerbodc]

I'm wondering if we keep a profile or perhaps segment to describe surface to surface of the platform and then it is consistent for all platforms. Then we can use phase already defined to help distinguish the behaviour of the platform.

So you would have something like
profile/segment number - 1,1,1,1,2,2,2
phase - 2,5,1,3,2,5,1

phase 3 definition is
3 | surfacing | the platform is at the surface for communication, recovery or safety purpose

so each phase 3 should be an increment in the profile/segment number

software then can be built to use the profile and phase to extract whatever a user wants to look at?

[vturpin]

I like the suggestion of Emma.
Segment is used to refer to surface to surface.
A segment can have multiple phase (behaviors of the gliders).
And from the diferent phase you can derive profiles.

[MOchiara]

I like Emma's suggestion but I am not sure I am fully understanding. Do we then remove profile as a predefined variable and keep only dive/segment?
Do we want to leave it to the user to define profile as they prefer and choose if apogee belongs to the dive or to the climb. I think it may make it confusing for other tools to then provide consistent outputs

[kimmotikka]

I'd prefer defining segment - yo - profile hierarchy. So a segment is a dive (surface to surface), yo a downcast and the next upcast and a profile either downcast or upcast. I've found yo useful in qc when calculating the timelags of sensors. Also I'd like to see consensus on where profiles are cut (lowest/highest point of a yo by pressure). So, unlike Victor's suggest, I find it easier to handle data with profiles and not with phases.