Technical roadmap

[brosaplanella]

In our last developer meeting we agreed to hijack the next one (18th of March 4pm UK time, link will be available on the PyBaMM Slack channel) to discuss the technical roadmap for PyBaMM.

The motivation is that for the past few months we have been focusing mostly on infrastructure and smaller issues, and there are some major projects to undertake that would benefit of a more structured vision (e.g. refactoring). The goal of this upcoming meeting is to discuss what this priorities should be and choose a coordinator/lead for each one. Then, the various people/teams interested in working on each priority can discuss and work on the arising issues.

This issue is to collect any thoughts regarding the technical roadmap both before and after the meeting.

[valentinsulzer]

Model entry points

We don't have as many contributors adding models to PyBaMM as we'd like. There are a few reasons for this

• PyBaMM’s submodel structure is too complex, huge barrier to entry
• You have to add things to the PyBaMM repo, uncertain ownership

We propose "model entry points" as a solution to this. Using entry points, contributors can create models in their own repositories and make them easily available to the rest of the community, without the models having to be added to PyBaMM itself. This will enable a community for battery models that use the PyBaMM infrastructure but are not owned by the PyBaMM team.

Advantages

• Contributors get to keep models in their own repositories, retain ownership, choose license terms
• PyBaMM team doesn’t have to endorse models we don’t like
• All of GitHub’s functionality (issues, discussions, pull requests) are available for each model

How to start

• Set up a separate repository with an example of adding a model separately outside of PyBaMM
• Make required changes to PyBaMM to enable this
  • Entry points for models
  • Making basic models compatible with experiments
  • Figure out how to deal with new parameters (define parameters inside the model itself?)
• Make cookiecutter repository to help with setting up, adding entry points, publishing to pypi, tests, docs, specifying pybamm version(s), etc (as part of the GSoC coookie-cutter project)

Later changes

After this is done, we will be in a much better position to consider fully separating the model code and PDE code

[valentinsulzer]

Parameter refactor

Refactor parameter values to use the BPX format by default.
Using nested dictionaries allows cleaner definition of negative / positive and also different components of the battery.
This is a big breaking change so we should add a conversion class from legacy parameter sets to new ones, and legacy parameter sets should still work for a while.

[valentinsulzer]

3D simulations

@tlroy has been working on some 3D electrochemical models in firedrake (a python-based finite element code similar to FEniCS). This provides a pathway to allow full 3D simulations in PyBaMM. Very early stage / exploratory at this point

[TomTranter]

I'd be interested in 3d models and it aligns with what I've done on jellyrolls

[brosaplanella]

Tidy up sumbodel structure

The current submodel structure is getting a bit messy, especially with degradation models. Allowing for model entry points (#3839 (comment)) will certainly facilitate the code. We should also enable (or publicly advertise if already possible) a way to assemble models as a dictionary of submodels and reduce the number of options to the most standard models (leaving edge cases to be defined as dictionaries).

In my opinion, the new structure should be designed generic enough to allow new chemistries (e.g. solid state electrolytes, lithium-sulfur...) if we wish to include them in the future.

[brosaplanella]

Refactor backend to be model agnostic

The core of PyBaMM should be model agnostic (i.e. not assume that the models implemented are for batteries) but in some places the battery assumptions have leaked in. These assumptions are sprinkled over various part of the codes but a good place to start would with the processed variables.

[martinjrobins]

Refactor backend to be model agnostic

As well as processed variables I think the Experiment class should have a base class that is not battery specific (see #3834). Same with Simulation class probably...

[martinjrobins]

Parameter refactor

Refactor parameter values to use the BPX format by default.

Isn't the BPX format for DFN models only? I would have thought that the set of parameters that pybamm uses is much broader than what BPX defines. Then there is non-battery models as well, equivilent circuit models etc.

[martinjrobins]

Parameter Inference

I'd like to continue making pybamm easier to work with for the parameter inference libraries like PyBOP (https://github.com/pybop-team/PyBOP). At the moment I think this includes:

• GPU as well as multithreaded support for running many simulations in parallel (Add support for MLIR-based expression evaluation #3826)
• Integrate sensitivities more into Simulation (generalise simulation, include sensititivies #3834)
• Run multiple simulations from different starting points (IDAKLU solver: add option for multiple initial conditions #3713). Should be possible to reset the starting points during the middle of a solve
• This is generally "making it faster", so profiling would fit in here (see delay xarray.DataArray initialization #3862)
• others?....

[brosaplanella]

Summary of roadmap meeting 18/03/24

The main outcomes of the meeting were that we will initially work on the following areas:

• Model refactoring (aka Models): This is basically the Model entry points suggestion above, but also incorporates the Refactor backend to be model agnostic suggestion. This effort will be led by @tinosulzer.
• Parameter refactoring (aka Parameters): This is the Parameter refactor suggestion above. This effort will be led by @kratman and @BradyPlanden.
• Solver improvements (aka Solvers): This is the Parameter inference suggestion above, renamed to avoid confusion with the other project. This effort will be led by @martinjrobins.

This does not mean we are dropping the other areas above, just leaving them for a later stage.

I will now create separate issues for each area so people can continue the discussions there and organise themselves. I will keep this issue open to collect other suggestions that arise.