casadi safe mode

[rtimms]

The solution time when using casadi "safe" mode depends on the number of values in t_eval. For example

model = pybamm.lithium_ion.DFN()
sim = pybamm.Simulation(model)
t_eval = np.linspace(0, 3600, 100)
sim.solve(t_eval=t_eval, solver=pybamm.CasadiSolver(mode="safe"))

takes around 1.6s but

model = pybamm.lithium_ion.DFN()
sim = pybamm.Simulation(model)
t_eval = np.linspace(0, 3600, 10)
sim.solve(t_eval=t_eval, solver=pybamm.CasadiSolver(mode="safe"))

only takes 0.2 s.

The current way safe mode is implemented is to integrate over each dt in t_eval. If there are lots of points in t_eval the result in the solver restarting a lot, which is slow.

There are some alternatives, each of which has pros and cons (here t_eval = [t0, t1, ... tf]):

1. Just integrate in fast mode until the end, and then truncate the solution at the first event after the fact. Without any extra checks this may give SolverErrors e.g. if concentration goes negative
2. Try to integrate from t0 to tf (outputting at all the points in t_eval): If success then truncate as above, if fail then try to integrate from t0 to tf/2 (again outputting at all points in t_eval that fall in this range). Then repeat, halving the window you are integrating over until the solver finishes successfully. If the event is near the start then this may lead you to unnecessarily integrate for longer than you need to.
3. Something similar to the above, but instead try to integrate in "sensible" chunks. What sensible means here is up for debate, but it could be something like try to integrate in blocks of 3600s/c_rate
4. Something else???

I think for most use cases all of those are reasonable. Does anyone have any input as to why one may be better than the other, or have other suggestions for tackling events in casadi?

[valentinsulzer]

Those all sound sensible, would lean towards 1 and 2 as hard to say what "sensible" chunks would be. For a battery model you could also get an estimate to t_eval by looking at c_n_init, c_p_init and integral(I), but that doesn't generalize ...