When calling optimize_control_info(model,**) (or bayesian_optimize_control_info), one would expect to retrieve the control vector corresponding to the parameter maps stored in the model object. This is not the case because the regional mapping is not always invertible (given the control vector, it's possible to derive the parameter maps, but the converse is not always true).
For instance, when using a linear mapping, what is currently retrieved by calling optimize_control_info(model,**) after model optimization is a "starting point" vector, i.e. a vector where all coefficients are set to zero except the intercept (leading to a uniform parameter map). This is confusing.
A few thoughts to improve this:
- Internally, optimize_control_info uses Fortran function
parameters_to_control (please confirm @nghi-truyen), whose name is confusing. I think function parameters_to_control should either return the inverted mapping from parameters to control if it's feasible (and by the way, it's feasible for a linear mapping!), or a flag/warning/error if the mapping is not invertible. A second function, named for instance fill_control_from_parameters, could be used to fill the parameter maps with values that "make sense" but do not necessarily correspond to the inverse mapping when the latter does not exists.
- It might be worth considering creating a new object
calibrated_model, as opposed to just model. A model object takes as input argument a parameter map to run (in addition to forcings and flow directions). By contrast, a calibrated_model would take as input a control vector, a mapping function and other options used to derive the cost function (transformation, priors etc.). Its parameter maps would not be directly modifiable, but would always be computed internally from the mapping function and the control vector, thereby ensuring that the control vector and the parameter maps are always 'in sync'.
This is probably linked with issue #301.
When calling
optimize_control_info(model,**)(orbayesian_optimize_control_info), one would expect to retrieve the control vector corresponding to the parameter maps stored in the model object. This is not the case because the regional mapping is not always invertible (given the control vector, it's possible to derive the parameter maps, but the converse is not always true).For instance, when using a linear mapping, what is currently retrieved by calling
optimize_control_info(model,**)after model optimization is a "starting point" vector, i.e. a vector where all coefficients are set to zero except the intercept (leading to a uniform parameter map). This is confusing.A few thoughts to improve this:
parameters_to_control(please confirm @nghi-truyen), whose name is confusing. I think functionparameters_to_controlshould either return the inverted mapping from parameters to control if it's feasible (and by the way, it's feasible for a linear mapping!), or a flag/warning/error if the mapping is not invertible. A second function, named for instancefill_control_from_parameters, could be used to fill the parameter maps with values that "make sense" but do not necessarily correspond to the inverse mapping when the latter does not exists.calibrated_model, as opposed to justmodel. Amodelobject takes as input argument a parameter map to run (in addition to forcings and flow directions). By contrast, acalibrated_modelwould take as input a control vector, a mapping function and other options used to derive the cost function (transformation, priors etc.). Its parameter maps would not be directly modifiable, but would always be computed internally from the mapping function and the control vector, thereby ensuring that the control vector and the parameter maps are always 'in sync'.This is probably linked with issue #301.