Add DiffSL export functionality

[martinjrobins]

Description

This PR adds the ability to export PyBaMM models to the DiffSL format, enabling models to be used with the DiffSL solver ecosystem.

Note this was started before the move from develop to main, in the process some commits got added, but these don't affect the diff

Changes

• New DiffSLExport class in src/pybamm/expression_tree/operations/diffsl.py:

  • Converts PyBaMM models to DiffSL format

• Unit and integration tests:

  • Added tests for ODE export (test_ode)
  • Added tests for heat equation export (test_heat_equation)
  • Integration tests for SPM, SPMe, and DFN models

Related Issues

Closes #5262

Checklist

• Tests added
• Documentation/docstrings updated (inline in code)
• CHANGELOG updated
• Code follows style guidelines

[BradyPlanden]

This is looking good @martinjrobins, a few small areas to discuss. How are you envisioning the pydiffsol dependency is maintained? At the moment it's unpinned, which could lead to failing pybamm CI. Perhaps an upper bound on a major release?

[martinjrobins]

This is looking good @martinjrobins, a few small areas to discuss. How are you envisioning the pydiffsol dependency is maintained? At the moment it's unpinned, which could lead to failing pybamm CI. Perhaps an upper bound on a major release?

don't you want a failing CI if your software ceases to be compatible with the latest version of a dependency, to let you know? I dunno, I can see arguments either way, you also want a dependable ci and only deal with breaking dependencies when you manually update them. I've also heard a security perspective that you should never pin if you can help it, so you get the latest security updates from direct and transitative dependencies.

I'm close to the fence, but my feeling would be to leave it unpined. Saying that, I'm happy to pin to a major release if you think that is better.

[Saransh-cpp]

Not having an upper-bound pin is the way to go. Good read: Should You Use Upper Bound Version Constraints?

[BradyPlanden]

Since pydiffsol is pre v1.0.0, my concern is that a breaking change can occur at any minor release, which would require a fix in pybamm before other development can continue due to the CI success rules. Since this is also a dev dependency, and not runtime, I don't think we need to worry as much about the upper-pinning convention in libraries.

My vote would be for a compatibility operator that can be bumped with pydiffsol's development. Then, at some point in the future this can be removed as pydiffsol provides more stability guarantees.

Something like:
"pydiffsol~=0.3.0; platform_system != 'Darwin' or platform_machine != 'x86_64'"

[martinjrobins]

My vote would be for a compatibility operator that can be bumped with pydiffsol's development. Then, at some point in the future this can be removed as pydiffsol provides more stability guarantees.

Is there a way for users (using a dev install of pybamm) to install a newer version of pydiffsol than the upperbound we mandate in the same virtual environment? Same with bpx I guess since it has an upper pin.

[martinjrobins]

presumably we can just make sure our CI only ever installs pydiffsol 0.3.0, that way you don't have to worry about failing tests due to pydiffsol API changes

[BradyPlanden]

Thinking on this further, how about moving the integration tests into pydiffsol while the unit tests stay in PyBaMM? Then the pydiffsol dependency is removed while still having coverage on the exported code. Similar to how PyBOP tests against main, pydiffsol could do the same and specific issues could be found and flagged to the correct developers without adding a block to PyBaMM development. Thoughts?

[martinjrobins]

Thinking on this further, how about moving the integration tests into pydiffsol while the unit tests stay in PyBaMM?

hmmm, it would be slightly awkard development though. You would have a bunch of code in pybamm that is only tested in pydiffsol. We could keep the integration tests and remove the pydiffsol validation, keep them as simple snapshot tests to verify the output doesn't change, but this will give a lot of false positives when we change any of the pybamm models. What is the downside of only testing against pydiffsol==0.3.0 in the ci but not having the upper bound pin in pyproject.toml? That way you ensure that your CI never breaks due to updates in pydiffsol, and users can install whatever version of pybamm and pydiffsol they want. We could do the same with bpx as well

[martinjrobins]

Perhaps I'll remove the integration tests for now and put some snapshot tests in the unit tests to ensure that the exporter doesn't change functionality over time. We can keep discussing this, but it would be good to get the exporter in for now.