[Bug]: ShapeError (same issue as #3630) when using nonlinear transference number

[ejfdickinson]

PyBaMM Version

24.11

Python Version

3.9.13

Describe the bug

Issue #3630 (ShapeError when using a pybamm.Interpolant of time only to specify "Ambient temperature [K]" as a thermal drive cycle), fixed in #3761, appears to still be causing a solve error due to a ShapeError in the presence of a product of temperature with a concentration variable in the "Cation transference number" parameter (possibly also in "Thermodynamic factor"?).

I'm afraid I haven't the insight to discern why the domains of definition are still mismatched here.

This only seems to happen if the thermal model is isothermal. With options={ "thermal": "lumped" }, the simulation runs.

Steps to Reproduce

The following repeat is the issue repeat from #3630 with the additional inclusion of a nonlinear expression in the transference number definition.

  import pybamm
  import numpy as np
  import matplotlib.pyplot as plt
  
  times = np.arange(0,1810,10)
  tmax = max(times)
  experiment = pybamm.Experiment([f"Discharge at 1C for {tmax} s"])
  
  temp_drive_cycle = pybamm.Interpolant(
      times,
      298.15 + 20 * (times / tmax),
      pybamm.t,
  )
  
  parameter_values = pybamm.ParameterValues("Chen2020")
  
  def transference_number(c_e, T):
      t_plus = 0.25 + (1e-10 * c_e * T)
      return t_plus
  
  parameter_values.update(
      {
          "Cation transference number": transference_number,
          "Initial temperature [K]": 298.15,
          "Ambient temperature [K]": temp_drive_cycle,
      }
  )
  
  sim = pybamm.Simulation(
      model=pybamm.lithium_ion.DFN(),
      # model=pybamm.lithium_ion.DFN(options={"thermal": "lumped"}), # uncomment in favour of above, and it will work
      parameter_values=parameter_values,
      experiment=experiment,
  )
  
  sol = sim.solve()
  sol.plot()
  
  plt.plot(sol["Time [s]"].entries, sol["Volume-averaged cell temperature [K]"].entries - 273.15)
  plt.xlabel("Time / s")
  plt.ylabel("Cell temperature / degC");

Relevant log output

[ejfdickinson]

The same workaround proposed by @rtimms is still effective (#3630 (comment)).