Support for inference of functional ECM parameters
Opened this issue · 2 comments
Feature description
Currently PyBOP supports inference of some equivalent circuit model parameters, where those parameters remain constant across the depth of discharge. Cell kinetics and resistance vary with both temperature and state-of-charge, so it would be useful for PyBOP to infer these functional relationships from data.
Motivation
Functional parameters for equivalent circuit model components provide more accurate cell models, compared to using constant parameters across the whole depth of discharge. State-of-charge and temperature-dependent functional parameters are the method of choice within both academia and industry, however there are not currently any standardised software packages for parameterising these relationships.
Possible implementation
A simple discretisation scheme could be chosen, to convert functional parameter inference into a numerically tractable problem. For example, the function R0(T, SOC) could be represented in a spline basis, or through a regular grid interpolator. PyBOP would then infer the spline coefficients or gridded interpolating points, such that the resulting functional parameters generate an optimal model fit to data. Identifiability issues could be avoided by restricting the sets of parameters that can be identified, eg. only R0, R1, C1 for a Thevenin ECM, and by placing requirements on the input data, eg. instructing the user that data must contain both (dis)charge and relaxation periods.
Additional context
No response
Hi @MarkBlyth,
Excellent, thanks for submitting this issue. As per our discussion yesterday, I'm looking forward to take a look at a MWE. Do shout if you have questions in regards to the contributing guide, or find things that are brittle for new users/contributors!
In terms of utilising a Pyro GP for functional parameter representations in PyBaMM, @martinjrobins might be able to weigh in on the challenges from the Casadi side. Perhaps you can post a MWE that shows the current issue and we can take a look at sorting it.
Any functional form you use (spline, GP, NN, etc.) would ultimately have to be convertable to either casadi (can either use the casadi or idaklu solver) or JAX (can only use the JAX solver). At the moment, this translates into: you can only use pure python or numpy functions, but you could probably do something more fancy with JAX and cover a lot of the ML ecosystem with some minor updates to pybamm (https://github.com/JaxGaussianProcesses/GPJax). But if you wanted to do something straight away, just write your spline/GP/NN using numpy functions and it should work fine.
Really this is a pybamm issue, once you have your pybamm model with the spline/GP/NN embedded it believe it should "just work" in pybop.
An issue you will probably run into with pybamm, is that your spline/GP/NN will probably take a vector or parameter rather than a scalar. pybamm is rather inconsistent with supporting vector input parameters, so this will probably break something...