Managing calibration and other software options and parameters #29
Labels
priority-low
Low priority for next release
refactoring
improve the design, structure, and/or implementation
Milestone
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:
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:
I love this one, because it will make very easy for users to test different parameters in a single script
The text was updated successfully, but these errors were encountered: