Sample. This is the structure a client receives, filled in from a real, public, self-initiated investigation. No client was involved, and every number below comes from the public reproduction package at commit adaa877.
Claim Check report
PyBaMM BasicDFN: does the model conserve lithium when the transference number varies?
1. The question, as agreed
The model conserves lithium: the total in the electrolyte and particles stays constant over a cycle, up to solver tolerance.
Settled by: an independent lithium count that uses the library’s mesh and solution but none of its averaging or total-lithium diagnostics. The claim fails if the count drifts by more than solver tolerance; the cause is reported separately.
2. Verdict
Fails. With a concentration-dependent transference number, the model loses between 2.4407% and 2.4417% of its lithium in all 21 runs. The cause is a missing term in the equation, not the numerical method. Two control models hold: their largest error in any run is 1.3e-13 of the inventory.
3. What was run
I froze three revisions (1,228 files hashed before any run) and counted the lithium from the mesh, the parameters and the raw concentrations. The count uses PyBaMM’s mesh and solution, but none of its averaging or total-lithium diagnostics. A second implementation of the count, written separately with explicit loops, was compared with the first on every run. 84 jobs in total.
4. Proof the check works
Before the count was trusted, it was run on cases with known answers. Five planted defects were each caught, and two correct cases balanced:
| Case given to the counter | Largest imbalance reported |
|---|---|
| closed transfer | 1.8e-15 mol: balances, as it should |
| boundary and source conserving | 3.3e-15 mol: balances, as it should |
| altered inventory | 0.020 mol: caught |
| wrong boundary sign | 0.600 mol: caught |
| omitted source | 0.200 mol: caught |
| wrong volume factor | 0.005 mol: caught |
| synthetic imbalance | 0.010 mol: caught |
A second implementation of the count, written separately with explicit loops, is compared with the first on every run. On the synthetic test arrays above, the two agree to 3.6e-15 mol.
5. Evidence
| Mesh (cells) | Time tolerance | Case under test | Constant-transference control | Full DFN control |
|---|---|---|---|---|
| 20 × 20 | 1e-06 | 2.4417% | 1.8e-14 | 1.5e-14 |
| 20 × 20 | 1e-08 | 2.4417% | 1.9e-14 | 1.5e-14 |
| 20 × 20 | 1e-10 | 2.4417% | 1.8e-14 | 1.5e-14 |
| 20 × 80 | 1e-10 | 2.4417% | 2.9e-14 | 1.3e-13 |
| 40 × 40 | 1e-10 | 2.4409% | 2.8e-14 | 2.6e-14 |
| 80 × 20 | 1e-10 | 2.4407% | 2.0e-14 | 2.1e-14 |
| 80 × 80 | 1e-10 | 2.4407% | 2.7e-14 | 1.3e-13 |
Largest fraction of lithium unaccounted for during the run, worst of three revisions.
The loss rate matched the rate predicted by one missing transference-gradient term, instant by instant, to within 1.2e-17 mol/s in every run. The developer who opened #5700 confirmed the missing term and asked for a separate report. Separately, a half-cell diagnostic used the full-cell thickness where the electrolyte occupies 67 µm, overweighting it by a factor of 11.45.
6. What this does not show
One library, two models, one protocol, one parameter set. The full DFN model conserved, and nothing is said against it. Eleven half-cell jobs failed inside the solver at tight tolerance, so no convergence order is claimed. No physical battery was measured.
7. Next actions
- Add the missing transference-gradient term (done upstream in PR #5747, released in 26.9.0.0).
- Add the independent lithium count as a test that runs on every release, so a future change cannot reintroduce the loss.
- The finite-volume question raised in #5700 is a separate claim and would need its own check.
8. Re-run
The count, the 84-job table and the planted-defect checks are in the reproduction package. In a client report, this section gives the exact command and environment.