Observe 0D custom variables after solving

[MarcBerliner]

Description

Adds preliminary ability to lazily evaluate custom pybamm expressions after solving the simulation. E.g.,

import pybamm

sim = pybamm.Simulation(pybamm.lithium_ion.SPM())

sol = sim.solve([0, 1000])

soc = pybamm.Variable("Discharge capacity [A.h]") / pybamm.Parameter("Nominal cell capacity [A.h]")

sol.observe(soc)
# <pybamm.solvers.processed_variable.ProcessedVariable0D at 0x104606c90>

This currently only supports 0D variables. It's not straightforward to support variables with meshes because only their discretized version is available at solution time. To support lazy observation of general variables (including the non-state variables), we would need to ensure that the original, non-discretized model.variables is not replaced with a discretized version.

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:

• No style issues: nox -s pre-commit
• All tests pass: nox -s tests
• The documentation builds: nox -s doctests
• Code is commented for hard-to-understand areas
• Tests added that prove fix is effective or that feature works

[MarcBerliner]

SymbolReplacer and its test are copied from https://github.com/pybamm-team/pybamm-eis/blob/c88e134b28c50070dbf7b904c020c16b4b73e1d9/pybammeis/utils.py

[codecov]

Codecov Report

❌ Patch coverage is 93.23308% with 18 lines in your changes missing coverage. Please review.
✅ Project coverage is 98.69%. Comparing base (df53205) to head (9844e0e).

Files with missing lines	Patch %	Lines
src/pybamm/expression_tree/operations/serialise.py	68.75%	10 Missing ⚠️
...bamm/expression_tree/operations/replace_symbols.py	95.04%	5 Missing ⚠️
src/pybamm/expression_tree/symbol.py	50.00%	1 Missing ⚠️
src/pybamm/models/base_model.py	92.30%	1 Missing ⚠️
src/pybamm/solvers/solution.py	98.87%	1 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff             @@
##           develop    #5308      +/-   ##
===========================================
- Coverage    98.77%   98.69%   -0.09%     
===========================================
  Files          321      322       +1     
  Lines        27746    27947     +201     
===========================================
+ Hits         27406    27582     +176     
- Misses         340      365      +25     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[valentinsulzer]

I don't like the idea of adding the parameter values as an argument to the model, could we find a different way of doing this, e.g.

1. pass parameter values to solution
2. create a "parameterized model" type which is model + parameter values (as created by the simulation) and pass that to the solution in the all_models argument

2 is my preferred solution but it is a bigger change

[valentinsulzer]

I don't think adding parameter values as an attribute to the model is the right pattern, I could see this causing some bugs. It would be better to have a "parameterized model" object which is model + parameter values.

[valentinsulzer]

Is this just here so we can access parameter values when processing a variable in observe? In that case could the parameter values be an optional argument of Solution instead (and throw an error in observe if not provided)?

[valentinsulzer]

why not use ParameterValues.to_json() ?

[MarcBerliner]

I don't like the idea of adding the parameter values as an argument to the model, could we find a different way of doing this, e.g.

1. pass parameter values to solution

2. create a "parameterized model" type which is model + parameter values (as created by the simulation) and pass that to the solution in the all_models argument

2 is my preferred solution but it is a bigger change

@valentinsulzer the reason I attached parameter_values to the model is because I believe this is the only way to make it work with the solver.solve(built_model, t_eval, ...) interface, since the parameter values are inaccessible after the model is built. We could streamline this if we chose to only make it available via the Simulation solve interface