sonar_model handling, grouping

[emiliom]

Simrad echosounders have a hierachical relationship between individual sonar model strings and the broader processing "class" (used loosely!). Specifically:

"Class"	Sonar models
EK60	EK60, ES70
EK80	EK80, ES80, EA640

Converting from the sonar model strings to the "class" is a recurring need across the code base that is implemented independently in many different places. Here are two examples:

https://github.com/OSOceanAcoustics/echopype/blob/f8082cac32bfbee2b21c62d266507491d221182d/echopype/convert/set_groups_base.py#L349

https://github.com/OSOceanAcoustics/echopype/blob/f8082cac32bfbee2b21c62d266507491d221182d/echopype/calibrate/range.py#L150-L153

This need to reimplement carries the potential of forgetting to do it; I've run into those oversights a couple of times.

The relationship is already expressed implicitly in core.SONAR_MODELS, eg:

https://github.com/OSOceanAcoustics/echopype/blob/f8082cac32bfbee2b21c62d266507491d221182d/echopype/core.py#L80-L91

We should think about options for handling this more systematically. For example, one option could involve encoding the sonar model "class" (I'm sure there's a better label for this!) in core.SONAR_MODELS, then using that consistently. And/or encoding it as a property of the echodata object, so it's always available. Doing something like that would eliminate a lot of hard-wired listings of individual sonar models in if-then statements.

[spacetimeengineer]

Upon reviewing this issue, it seems the focus is more on finding solutions for enhancing maintenance and upgrading during the development phase rather than on operational improvements (though these are still crucial). There is concern that we might overlook fixing some conditionals when we perform commits. To avoid scattering conditionals throughout the code, might it be beneficial to implement a new class or class function that provides the required answers to these conditionals from the start? Making them unneeded? This approach could streamline the solution process.

[leewujung]

Yes I think a more overarching solution like what you described above would be better. There's also a need to set up a better mechanism for deciding between the Beam_group for calibration target (depending on if user inputs to compute_Sv). It will be great if these can go into the same PR.

[jmjech]

In addition to "sonar_model", there seem to be two other mandatory parameters: "waveform" and "encode" that are required to correctly process the data. Maybe there are others as well? "sonar_model" is embedded in the netCDF4 file with the attributes, and I'm wondering if the other two could/should be embedded in the netCDF4 file as well?