A battery model ran to completion on every revision tested and lost 2.4% of its lithium. Independent inventory accounting localised the loss to one equation, and a project contributor confirmed the missing term.

The system said: Solved, on every revision. The then-under-review pull request #5524 changed nothing.
The evidence showed: 2.44% of the lithium inventory drifted on every revision and at every refinement. The missing term was named, and a project contributor confirmed it.

§ 1

The record

FINDING · pybamm-basicdfn-variable-transference-driftverify · faithfulness

A battery model ran to completion on every revision tested and lost 2.4% of its lithium. Independent inventory accounting localised the loss to one equation, and a project contributor confirmed the missing term.

Claim: In PyBaMM's BasicDFN with a concentration-dependent transference number, an independently assembled lithium inventory drifted by 2.44% of the initial inventory over the reporter's 4,800-second protocol on v26.4.1, main at 258fdc8 and the head of pull request #5524, byte-identical between main and the pull request; the drift persisted under temporal tightening to 1e-10 and spatial refinement to 80 cells, and matched, instant by instant, the rate predicted from the missing transference-gradient term. The constant-transference control conserved to 7.7e-15 mol.

Status: OBSERVED Witnessed in one instance. No claim about how often.

Question: Passed is not correct

Subject: PyBaMM, an open-source battery modelling library (third-party system); the inventory code and the referee are Omega's. third-party subject

Frame: The two one-dimensional cases from issue #5700; three pinned revisions; seven mesh and tolerance settings; 84 frozen jobs.

Method: Lithium inventory assembled from the mesh, the parameters and the raw concentrations, never from the library's own totals; a second explicit-loop implementation checked against the vectorised one on every run; a refinement sweep; the instantaneous rate of loss compared with the rate the equation predicts.

Oracle: Conservation of lithium: the physical inventory computed independently of the library's diagnostics, checked against its own initial value.

Negative control: Present The constant-transference BasicDFN and the full modular DFN, run under the same harness, conserved to 7.7e-15 and 3.5e-14 mol; analytic referee mutations (an altered inventory, a reversed boundary sign, an omitted source, a wrong volume factor) were each detected before and after the runs.

Denominator: 2.44e-2 relative drift at 20 cells, 20 shells, 1e-8; 73 of 84 frozen jobs completed; main and the pull request byte-identical on all 24 completed pairs.

Limitation: One model in one library under one protocol and one parameter set. Nothing against PyBaMM's full DFN, whose control conserved to 3.5e-14 mol, and nothing about the finite-volume discretisation of nonlinear source terms, which a contributor raised and which was not investigated. Eleven of 84 half-cell jobs failed inside the solver at tight tolerance, so no half-cell spatial convergence order is claimed. No physical battery was measured. The #5745 fix is on the default branch but not in a tagged release; #5746 remains open.

Source: repowazdogz-droid/pybamm-5700-lithium-inventory @ adaa877

Reproduce: PYBAMM_DISABLE_TELEMETRY=true python minimal_reproducer.py --output reviewer-output

Independent reproduction: None known.

Upstream: REPORTED UPSTREAM Issue #5745 was closed after Warren's pull request #5747 was approved and merged on 18 September 2026. The fix is on the default branch and in no tagged release as of 20 September 2026. Link

§ 2

Where this sits

This finding answers Passed is not correct and supports the VERIFY stage of the operating method. It is an instance of the faithfulness mechanism.

Evidence ledger Bring us a problem