Generic CoSimulation block

[DavidMStraub]

Hi,

when initially designing pathsim-batt, I tried to override DynamicalSystem's step method to step PyBaMM's internal solver. As correctly pointed out by @milanofthe in pathsim/pathsim-batt#2 (comment), this doesn't work as it is based on a misunderstanding of step: it's not a macro time step, but an ODE solver step.

pathsim-batt is now implemented by extracting the ODE RHS and using pathsim's internal solver, which is way more elegant and integrated.

However, there is a fundamental limitation: the most accurate electrochemical model, the Doyle-Fuller-Newman (DFN) model, is not pure ODE but also contains algebraic equations (DAEs). As far as I know, this is not currently supported by pathsim.

Since PyBaMM already includes powerful solvers tuned for this use case, I tried to wrap my head around how to make this work. This was also triggered by this article: Running PyBaMM from MATLAB: Expanding Battery Simulation Capabilities, which discusses putting PyBaMM into a Simulink Python code block.

I think the answer is: this would not be a full integration, but a cosimulation.

PathSim already supports cosimulation via FMUs, but creating an FMU would be overkill here: we already have the PyBaMM Python objects.

So, here is my suggestion: let's introduce a new block CoSimulation, which uses event hooks like the FMU cosimulation block and provides an abstract method macro_step (or whatever is a good name) that can be overridden by child classes.

This would allow us to add DFN models to pathsimm-batt, choose between full integration and cosimulation for SPM models, and also allow integrating other Python-based simulation tools in PathSim via cosimulation.

[milanofthe]

@DavidMStraub exactly right. We already have a block in pathsim exactly for that purpose. Its the Wrapper block. See the API Reference.

It has an internal scheduled event that periodically triggers the user defined function. Maybe naming is a bit ambiguous here..

[DavidMStraub]

Beautiful! I should have RTFM 🤣 I will investigate implementing this for DFN.

[milanofthe]

And yes, DAE blocks are currently not supported. But they might be in the future. Do you know what kind of DAE we would need for pybamm? Semi-explicit? Fully implicit? Mass matrix?

[DavidMStraub]

I'll investigate.

[DavidMStraub]

Not an expert, but I think it's semi-explicit. In CellBase's constructor, the objects I extract are the ones needed for the explicit ODE (the one I currently pass to the PathSim integrator) and the ones for the implicit algebraic part (the one where I currently raise NotImplementedError if it's non-empty). Does that make sense?

[milanofthe]

Yes makes sense, typically semi-explicit dae looks like this:

$$ \dot{x} = f(x, u, z, t) $$

$$ 0 = g(x, u, z, t) $$

Where $f$ is the ODE part and $g$ is an additional algebraic constraint that has to be sattisfied. And $z$ are some additional agebraic variables. If thats what we are dealing with, its good news. Implementing this as a pathsim block just needs an additiona newton solve for $g$ during the ODE stepping and we can still use explicit ODE solvers then.

[DavidMStraub]

Yes, I think that's what it is.