library I/O

[apatlpo]

This issue is intended to decide what type of I/O would be adequate and build a roadmap for implementation.

Here are a couple of first thoughts to start the discussion:

Different levels of I/O can be considered in general and we'll stick for now to low level code enabling to read input data directly into library and store raw outputs.

Inputs

1/ Environmental model

The environmental model is made of an UnderwaterEnvironment container that is further decomposed into lower level containers: Altimetry, Bathymetry, SoundSpeedProfile, Number, ReflectionModel, ReflectionModel.

Lowest level loading functions should take a filename as input and load each one of the low level containers.
Let's consider Bathymetry for example.
Because, there are several kinds of Bathymetry (ConstantDepth, SampledDepth), a variable must first hold kind of bathymetry is stored.
Other variables must be then be found depending on the value of the bathymetry kind (depth for ConstantDepth for example)

Provided filename(s), a wrapper around these could load the full Environment.
I would find it useful to be able to store a full environment in one file as well as only having part of the environment (e.g. altimetry, bathymetry, ...).

2/ Propagation models (RaySolver for example):

There are several propagation models and a variable must first hold what kind of model the file contains.

Each propagation model seems to be defined by a range of parameters and an environment.
Loading a propagation model thus requires thus either providing an environment or loading an environment (in the same file or in another file)

outputs

My time is up for this today, I'll come back to this in a later post.

file format

Netcdf is the standard in my field and it is quite a widely distributed, versatile and performant format.
A self describing approach would be useful (as hinted above).
Keeping track of library (UnderwaterAcoustics) version used to produce output files would be useful for internal checks.

[apatlpo]

I'm running out of time prior to summer break, so I put very quickly some elements to be further discussed later ... apologizes

1. I just realized I forgot to add AcousticSource and AcousticReceivers in the list of inputs.
2. Standard putputs, here is a quick list of object that one may want to store:
   • rays
   • arrivals (core object plus potentially impulse response)
   • transfercoef / transmissionloss (scalar, grid)
   • acoustic simulations
3. Probalistic modeling inputs / outputs
4. Differential modeling inputs / outputs

[apatlpo]

Ok, I guess I have green light to give this a try.

My agenda this month won't help unfortunately ... I'll have to do this on my spare time

[mchitre]

No worries, take your time.

The green light is on the need for library I/O for various model inputs/outputs. We'd probably want to discuss the formats and API before you start implementing, to avoid wasted work later. We could do that as part of the issue discussion.

[apatlpo]

I initiated a draft PR about I/O based on netcdf.
I think you could take a look at it @mchitre to push this discussion further.

Or I can change the PR into a real one and we can discuss there.
Let me know what your preference is @mchitre

[mchitre]

We can discuss it on the draft PR. I'll take a look and comment there. You should convert the draft PR to a PR only at a time you feel that you're ready for it to be reviewed in detail and merged.