Managing calibration and other software options and parameters

[gmaze]

As pointed out by @edsmall-bodc in #23 :

---

Currently the user has to define many things for the OWC toolbox to run:
For the update salinity mapping, they need to define:

• Which data set they want to use from each WMO box (argo/CTD/bottle data) [though we have discussed how the WMO boxes could be phased out!]
• The float name they want to analyse
• The maximum number of historical casts they want to use during analysis
• Whether or not they would like to use potential vorticity
• Whether or not they would like to use special constraints around the subantarctic front
• The latitude and longitude scales used for decorrelation (4 values)
• The cross isobath scales (2 values)
• The age scales (2 values)
• The exclusion depth
• The age exclusion parameter
  Many of these parameters have a default value, but I know operators change them regularly

That brings variables for salinity mapping to 15, which is somewhat tricky to manage in a usable way. Either we will need to group some of these variables together (into classes or dictionaries?), OR we can split the update salinity mapping routine up into separate routines that can be called?

---

We may want to consider a set of options (as a dictionary) used throughout the package that users can set or change within context and in their script.

Most of the time, users will only need to modify a subset of the parameters.
This is a mechanism used in matplotlib (they also use files) and xarray that I implemented in http://github.com/euroargodev/argopy as well

It is very easy to manage and I think is rather elegant and intuitive in terms of user experience:

Optional parameters can be set 3 ways:

• at the beginning of a script, notebook:

argopy.set_options(src='erddap')

• in a temporary context:

with argopy.set_options(src='erddap'):
    loader = ArgoDataFetcher().profile(6902746, 34)

I love this one, because it will make very easy for users to test different parameters in a single script

• or with options when calling methods:

loader = ArgoDataFetcher(src='erddap').profile(6902746, 34)

[gmaze]

The configuration should not come in the arguments of update_salinity_mapping.
This is inherited from the Matlab way of running the software.
Must not survive in the Python version !
The configuration is more like a context.

We should also use configuration files similar to the Matlab ow_config.txt file.
This will be a nice way for users to go from Matlab to Python, without having to create a new configuration.

I propose the following implementation:

Configuration file

Here, user provides a configuration file and py_owc uses it directly.
Internally, the dictionnary of parameters from the user file will be merged with default values.

It could be used this way:

import ow_calibration

float = "3901960"
config_file = "ow_config.txt"

with ow_calibration.configuration(config_file):
    ow_calibration.update_salinity_mapping(float)

or

import ow_calibration

float = "3901960"
config_file = "ow_config.txt"
ow_calibration.configuration(config_file)  # Will be set for the entire session

Analysis parameters

On top of a configuration file, we could allow users to modify specific parameters. In this case, only a context with could be possible.

import ow_calibration

float = "3901960"
config_file = "ow_config.txt"
ow_calibration.configuration(config_file)  # Will be set for the entire session

with ow_calibration.configuration({"MAPSCALE_LONGITUDE_LARGE": 4}):  # Temporarily try a specific parameter value
    ow_calibration.update_salinity_mapping(float)

[edsmall-bodc]

Okay, this seems like a good middle ground.

So there are default values in ow_config.txt, but they are easily editable before running the salinity mapping.

Did you say you wanted to separate the parameter options and the directory set up variables? It could make sense to do this because the parameters are only used in the salinity mapping portion, but the directory variables are used pretty much everywhere

[gmaze]

I'm afraid we gonna need to deal with this for the 1st Pypi release