PyBaMM icon indicating copy to clipboard operation
PyBaMM copied to clipboard

Fix interpolation bound errors in sodium-ion DFN by enabling safe extrapolation

Open aaryan-iiitu opened this issue 3 weeks ago • 2 comments

Summary

This PR fixes the interpolation bound errors occurring in the sodium-ion DFN model (Chayambuka2022 parameter set), where OCP and exchange-current interpolants would exceed their defined stoichiometry or concentration ranges during deep-discharge conditions. This caused solver failures such as:

  • "Interpolant 'k_n' lower bound"
  • "Interpolant 'U_n' lower bound"

Fix

I updated the sodium-ion parameter functions to enable extrapolate=True for:

  • Negative electrode OCP
  • Negative electrode electrolyte exchange current density
  • Positive electrode OCP
  • Positive electrode electrolyte exchange current density

This ensures that DFN simulations do not crash when stoichiometry or concentration slightly exceeds tabulated data ranges.

Tests

Added a regression test test_sodium_ion_extrapolation.py that:

  • Loads the Chayambuka2022 parameter set
  • Retrieves the modified interpolant functions
  • Asserts that they all have extrapolate=True

This test runs quickly and confirms the fix without requiring long DFN simulations.

Motivation

The sodium-ion DFN demo fails to complete cycles in recent PyBaMM versions due to strict interpolation bounds. This PR improves robustness while matching expected physical behavior.


aaryan-iiitu avatar Dec 04 '25 05:12 aaryan-iiitu

extrapolate is True by default, so I'm surprised this changes anything. Can you share a script and outputs comparing leaving the default and explicitly passing extrapolate=True? I think what is probably happening is that in your test you aren't solving for a long enough time or high enough rate to see the error.

rtimms avatar Dec 05 '25 09:12 rtimms

Thanks for the review .You are completely correct. I have re ran the tests on the current branch without my changes, and I am unable to reproduce the crash as the simulation completes successfully.It appears the default handling in the current codebase is already robust enough to prevent it.

Since I cannot reproduce the failure locally, I understand this PR might be redundant. However, I am still very keen to work on resolving the original issue for the user. Could you guide me on how to solve this issue if possible , otherwise I would be happy to close the PR.

aaryan-iiitu avatar Dec 05 '25 14:12 aaryan-iiitu