Solver speedup meta issue

[LevanBokeria]

This is a meta issue to track sub issues relating to different ways in which we can increase the speed of solving coupled ODEs in ModularCirc.

From some initial profiling I've looked at, most time is likely taken up by the solve_ivp step which is a scipy algorithm for solving the "initial value problem" of ODEs. If a better/faster solver can be found, this might speedup the whole process.

Alternatively, @MaxBalmus was mentioning there is likely a list comprehension bottleneck. I think he was referring to lines inside the advance_cycle() function in Solver.py. How the dataframe gets updated with new values after each cycle might be inefficient.

[LevanBokeria]

Meeting minutes:

1. Tests for solver
2. Profile the solver
3. Then look at swapping solvers and jaxification

[LevanBokeria]

I'm wondering about the overall structure of solver.py. Would it make sense to move some of the sub-functions outside solver.py itself, or are they too tighly connected with solver and so should stay in there?
Functions such as:

• s_u_residual()
• optimise()
• compute_permutation_matrix()
• initialize_by_function()

[MaxBalmus]

I think that is possible to move them. These functions were introduced in a rushed way to try to and address specific issues at different points. So yeah it would probably be helpful.

[LevanBokeria]

Nice! @crangelsmith I see you have a branch called 31-refactor-solver. Shall we make a dedicated issue for refactoring the solver, link it to the branch, and implement these changes there?

[crangelsmith]

Nice! @crangelsmith I see you have a branch called 31-refactor-solver. Shall we make a dedicated issue for refactoring the solver, link it to the branch, and implement these changes there?

Yes, I was playing on how to abstract the Solver to allow for different options (scipy, jax, etc). I parked it after our conversation last week, of starting with tests.