add NONSTD to sondeless circle in HALO-0215

[Geet-George]

Added the NONSTD tag to HALO-0215_c4. The circle had no dropsonde launches.

[Geet-George]

This irregularity tag is currently defined as "segment is not at its usual location or size (only added if there is a usual location or size for this segment kind on that platform)". So, the tag doesn't fit to HALO-0215_c4 presently. But I think we can extend the "standard" for circles to ones that have dropsonde launches. If you agree with this, then the tag can be added. :)

[d70-t]

I am unsure if I agree, but if I would, the definition in the README-File must be updated as well.

In principle, I think one should argue that the presence of any irregularity turns the segment into something which is not the "standard" (I'd say that standard and regular could be used interchangeably in this case). Thus if I want to obtain a list of only regular segments, I could run a code like:

regular_segments = [segment
                    for segment in all_segments
                    if not segment["irregularities"]]

An irregularity tag should be a (more) machine readable way to be a bit more precise about the kind of the irregularity, such that a more specific selection would be possible. I.e. if I only want regular segments, but dont't care about TTFS irregularities, I could go for:

regular_segments = [segment
                    for segment in all_segments
                    if all("TTFS" in irregularity
                           for irregularity in segment["irregularities"])]

(i.e. if any irregularity is present, it must contain TTFS to be accepted)

But in that reasoning, a "catch all" irregularity tag would not help.

That said, NONSTD is probably a misnomer, but as it stands now, we are having it and it means that the segment is of untypical proportions or location. If the definition of NONSTD can be converted to incorporate the no sondes without becoming too unspecific, we should go for it. If we need another tag, that's also fine and if we need no tag at all, thats also an option.

---

The code examples above assume the following has been executed before:

import eurec4a
segments = eurec4a.get_flight_segments()
all_segments = [s for flights in segments.values() for flight in flights for s in flight["segments"]]

[d70-t]

@Geet-George I am wondering if more updates in this PR are to be expected, or if we should close it?

[Geet-George]

Yes, this can be merged.

[d70-t]

No, it can't. Currently this would leave the repository in an inconsistent state (the meaning of NONSTD would change, but this is not reflected in the readme). Apart from that, there are doubts if this change would be an improvement (as outlined above).

[Geet-George]

Okay, I agree with the arguement made here. I'll edit the text in the manuscript accordingly. I saw that someone had included this circle in the NONSTD definition in the manuscript and that's why I had revisited this PR the last time.

In this case, shall we then close this issue without merging? And then, maybe issue a DOI for this version? I forgot the bird you were suggesting. I remember the story though partially.. 😅

[d70-t]

Yes, I'd also opt for close without merge.

Heike also asked if we could reorder the entries in the compiled yaml file. I've got an idea on how to do this, but that's for sure something for another issue.

[d70-t]

I've opened #27 and #28 for the remaining issues.