[Bug]: Composite ElectrodeSOH input parameters (Q_n_1 etc.) collide with the legacy MSMR name pattern

[rtimms]

PyBaMM Version

26.8.0.0 (also present in 26.7.1.0, and on main)

Python Version

3.13.5

Describe the bug

electrode_soh_composite names its internal phase-capacity InputParameters Q_n_1, Q_p_1, Q_n_2, Q_p_2 (electrode_soh_composite.py#L171-L182, and again as the Qs dict at L589 / L824).

Those names match the legacy-MSMR pattern in msmr.py:

^(?P<base>X|Q|w|U0|a|j0_ref)_(?P<elec>n|p)(?:_(?P<qual>[ld]))?_(?P<idx>[0-9]+)$

so when those inputs reach ParameterValues.check_parameter_values (via BaseSolver._set_up_model_inputs), is_deprecated_msmr_name returns True and the deprecation branch at L745-L752 fires. Two effects:

1. A user-facing DeprecationWarning nobody can act on. It names PyBaMM's own internal input parameters and tells the user to rename them; there is no user-side name to change. It fires on any composite / multi-phase initial-state solve.

2. A bogus key is injected into the solver inputs. values[new_param] = values.get(param) adds e.g. Negative electrode host site occupancy capacity (1) [A.h] alongside Q_n_1:

   >>> pybamm.ParameterValues.check_parameter_values({"Q_n_1": 5.0})
   {'Q_n_1': 5.0, 'Negative electrode host site occupancy capacity (1) [A.h]': 5.0}

   So every composite ESOH solve carries three or four phantom MSMR host-site inputs that no model variable reads. Harmless today, but it means Q_n_1 and a real MSMR host-site capacity are indistinguishable to anything downstream that inspects the inputs dict.

The collision is accidental — the composite Q_n_1 is a phase capacity (primary/secondary particle), whereas the MSMR Q_n_1 is a host site capacity. They are unrelated quantities that happen to share a spelling.

Steps to Reproduce

No MSMR model or MSMR parameter anywhere in the stack:

import warnings
import pybamm

model = pybamm.lithium_ion.SPMe({"particle phases": ("2", "1")})
params = pybamm.ParameterValues("Chen2020_composite")
sim = pybamm.Simulation(model, parameter_values=params)

with warnings.catch_warnings(record=True) as caught:
    warnings.simplefilter("always")
    sim.solve([0, 10], initial_soc="2.8 V")

for w in caught:
    if issubclass(w.category, DeprecationWarning):
        print(f"{w.filename.split('site-packages/')[-1]}:{w.lineno}: {w.message}")

Relevant log output

pybamm/solvers/base_solver.py:1766: The parameter 'Q_n_1' has been renamed to 'Negative electrode host site occupancy capacity (1) [A.h]'
pybamm/solvers/base_solver.py:1766: The parameter 'Q_p_1' has been renamed to 'Positive electrode host site occupancy capacity (1) [A.h]'
pybamm/solvers/base_solver.py:1766: The parameter 'Q_n_2' has been renamed to 'Negative electrode host site occupancy capacity (2) [A.h]'

Suggested fix

Rename the composite-ESOH input parameters to something outside the MSMR pattern — e.g. Q_n_prim / Q_n_sec / Q_p_prim / Q_p_sec, which also reads better than the numeric suffix. They look internal to electrode_soh_composite.py (constructed and consumed in the same module, then passed to solve as the Qs dict), so this should not be a public-API change.

Narrowing _VALID_NAME_RE instead would not help: Q_n_1 genuinely is a legacy MSMR name, so the check is doing the right thing on the name it is given. The problem is that the composite path chose that name for something else.

Happy to open a PR if that fix direction looks right.

[rtimms]

Correction to point 2 above: the phantom Negative electrode host site occupancy capacity (1) [A.h] key is added to the dict check_parameter_values returns, but it does not reach the solver on this path — BaseSolver._set_up_model_inputs keeps only the names the model declares, so it is discarded:

_set_up_model_inputs(model_declaring_Q_n_prim, {"Q_n_1": 1.0, "Q_n_prim": 2.0})
# -> {'Q_n_prim': 2.0}

So the user-visible symptom is the DeprecationWarning alone (3 per get_initial_stoichiometries_composite call on a negative-composite parameter set). The injection still persists for the other caller of check_parameter_values, ParameterValues.update, which composite ESOH does not go through.

The fix in #5738 is unaffected — the collision and the warning are real either way.