Naming scheme for Flights

[d70-t]

We need a consistent naming scheme for each research flight during the campaign in order to uniquely identify each flight. These identifiers should be concise, easy to remember and easy to type, but they must be uniquely defined per flight.

In early days, we've been using an RF01, RF02, ... naming scheme, which assigns consecutive numbers to each flight. This has led to problems defining where to start the count (e.g. do we have to account for test flights or transfer flights?). This naming scheme can also be ambiguous between aircraft and campaigns and thus is not ideal for multi-aircraft campaigns.

During EUREC4A, we've adopted the <aircraft>-<month><day> naming scheme (e.g. ATR-0213), which solved some of the problems and is still relatively short, but doesn't support multiple flights on the same day. That resulted in two flights actually having the same identifier, resulting in problems and the ad-hoc creation of the <aircraft>-<month><day>-<flight_number> scheme.

This issue proposes to use a naming scheme based on aircraft and (takeoff-UTC-) date, while allowing multiple flights on one day. We deliberately don't suggest the use of e.g. takeoff or landing times, as there might be disputes or miscommunication about their exact values. Instead, we propose to use small letters (e.g. a, b, c....) as suffix to distinguish between multiple flights on a day (this approach has already been used for some instruments). We could allow to skip the a suffix for the first flight, this would in many cases shorten the identifier, but will create a corner case which may have to be accounted for in scripts.

Within the ORCESTRA campaign, we don't have a change in year, so we might skip the year part of the date (as in EUREC4A) to make the identifier more concise. On the other hand, the year would help to distinguish flights from potential other field campaigns. This leaves the following options:

• [x] HALO-20240810a, HALO-20240810b: with year and mandatory a
• [ ] HALO-20240810, HALO-20240810b: with year and without a
• [ ] HALO-0810a, HALO-0810b: without year and mandatory a
• [ ] HALO-0810, HALO-0810b: without year and without a

[lkluft]

I prefer the first scheme (i.e. HALO-20240810a). Although it is the longest option, this verbosity also serves as a clean and future-proof way to identify flights.

[yu71ng]

Hello! I've got some Feedback from the PI's as following:

Bjorn:

I’m fine with platform-date[abc] proposal. It might good to ask the data people if there is an advantage of conforming with ISO date formats (2024-08-10), but I don’t see his as an advantage on its own, as things getting messier (where to put the a, or how to connect to platform) and potentially not clearer. In the end we are in the trap where we try to put too much meta-data in the filename, but I guess we won’t get away from that completely.

Team MAESTRO:

Thank you for the proposal. A simple nomenclature such as what you propose will be fine. We support something like <aircraft>-<year><month><day><letter>

So let's use the first scheme as proposed (with year and mandatory letter) and stick to it. :)

[yu71ng]

The question came up if we then would skip the flight numbering RFxx?

For quicklook data the usual terminus QL_<aircraft>-<year><month><day><letter> _<instrument>_<Version: Vxx> shall remain.

[d70-t]

Ok, thanks for the feedback, there seems to be a clear favorite: the full version (with year and mandatory letter):

<aircraft>-<year><month><day><letter>, e.g. HALO-20240810a.

This would replace other possible identifiers for a flight (e.g. RFxx).

The hyphens (-) in the ISO date format are optional, thus a date in the form of YYYYMMDD is also a valid ISO date, thus I'd keep the current format as it's shorter and the more hyphenated format doesn't seem to be clearer.

I'd suggest to keep this issue open until we have a PR which documents this decision on our webpage.