Align the type of inputs passed from cost to problem and model

[NicolaCourtier]

Feature description

Align the evaluate and simulate functions of a problem/observer and model to accept only inputs of type Inputs. Update the Parameters functionality to return dictionaries rather than arrays.

Motivation

To continue improvements enabled by the addition of the Parameters class in #322 and work towards enabling optimisation of mulitple costs/problems/models with different or overlapping parameter sets.

Possible implementation

No response

Additional context

No response

[BradyPlanden]

Hi @NicolaCourtier, thanks for raising this. I'm keen to add the option to pass the Inputs type to the cost/problem/model, however is there a technical reason that this has to be the only type with the upcoming batch study changes?

In our current form, I very much like being able to do this: cost([0.5,0.5]) as it's a very quick way to check the constructed objects, and interact cost/problem/model. I would like to keep the type interoperability for list and np.array if possible.

[NicolaCourtier]

Hey @BradyPlanden, in the PR #352, I have kept the ability to pass values like this to the call, evaluate and evaluateS1 functions of the cost (as the optimiser does).

Further down the chain (from cost to problem to model), I think we need to keep the parameter names associated with the values in order to prevent against cases where values are passed to the incorrect parameter. Having said this, I have also kept the ability to pass values directly to quick_plot. The quick way to pass values to a problem or model would be parameters.as_dict(x). Please describe any other functionality you would like to see.

[BradyPlanden]

Excellent, thanks for clarifying. That makes sense to me.