Multivariate parameters #862
Open
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Introduce MultivariateParameter (subclass of pybop.Parameter) instead of MultivariateParameters (subclass of pybop.Parameters) and edit pybop.Parameters to allow for multivariate parameters.
The MultivariateParameter class is almost identical with the Parameter class but it additionally requires the name of the paramater that holds the MultivariateDistribution. This is a little bit hacky but allows the parameters to be passed without already being collected into one object.
A check_multivariate method is added to pybop.Parameters() that checks whether a MultivariateParameter is present and if so whether all parameters are of type MultivariateParameter and point to the same distribution. This method is called in the constructor, the set method and the add method. The call to the method can be disabled in the add and set method by setting the parameter check_multivariate to false. This is, for example, used in the constructor in order to only call the method once all parameters have been added.
The edits to the Parameters class are also a little bit hacky. However, this approach means the Problem and Simulator classes do not explicitly need to be aware whether they are dealing with mulitvariate parameters.
An alternative approach would be to discard the changes to pybop.Parameters, reintroduce the MultivariateParameters class and construct the MulitvariateParameters class in pybop.pybamm.Simulator if any parameters of type MultivariateParameter are provided to the constructor as part of the ParameterValues object. This means that Problem and MetaProblem need to distinguish between MultivariateParameters and Parameters as well (this would only require minor edits).
Fixes #856
Type of change
Please add a line in the relevant section of CHANGELOG.md to document the change (include PR #).
Important checks:
Please confirm the following before marking the PR as ready for review:
$ pre-commit runor$ nox -s pre-commit(see CONTRIBUTING.md for how to set this up to run automatically when committing locally, in just two lines of code)nox -s testsnox -s doctest