# Could my issue be tackled on the main site? If not, what parts of it could be?

Just to give you a bit regarding my background: I am a math undergraduate working on biology modelling problems. I have a strong background in Python, but it is only over the last few months that I have begun to dabble in scientific computation using scipy, numpy and most recently, Cython. This semester, I am taking my first proper course on numerical methods.

Currently, in my research work, I am writing a program that solves a large number of non-linear ODEs. I use scipy.integrate.odeint as my workhorse, although I have dabbled with using pyDSTool as well, but found that the limited capacity I had in understanding advanced methods didn't allow me to use pyDSTool so that I had better performance than vanilla scipy.integrate.odeint.

My supervisor recently pointed out a fairly major error in my previous implementation of the program: I was "breaking up" scipy.integrate.odeint's flow. So if I had to solve a problem between times 0 and 10, I would make odeint work between t in [0, 1], take the result at t=1, use it to update (non-linear) parameters for the next interval ([1, 2]) and then finally run the next interval using t=1 results as the initial conditions.

I thought it would be a good idea to do this in order to temporarily reduce the complexity of the problem by having some of the coefficients be constant over each sub-interval (something like a "quasi-equilibrium" condition?), and it also allowed me to straightforwardly implement non-DE rules to update parameters, if I needed to. However, problems with doing this include introducing errors, and causing loss of speed due to the breaking/restarting of odeint's internals.

So, I changed the implementation so that everything was done in "one-shot" (luckily the only non-DE rule I had so far was easily converted to a DE rule, although there is one coming up which I don't see any easy conversion for...that is the subject of this question).

However, I am finding that the "one-shot" method is slower than the "broken up" method! For a single cell (the number of ODEs increases linearly with increasing number of cells), solving for the interval between [0, 1] takes about 3 times longer than the "broken up method" (where I was breaking up the problem into intervals [0, 0.5] and [0.5, 1] for the same rtol and atol. Solving for the behaviour of a single cell over [0, 10] takes roughly 3 times longer than [0, 1] (hey! not bad!). Solving between [0, 1000] takes roughly 1500 times longer (weird :( ). Solving 2 cells (and solving between [0,1]) takes about 3 times longer than the single cell case, and solving 10 cells over the same time interval takes 60 times longer! So the times aren't growing linearly...whether I am increasing the length of the time interval, or increasing the number of cells. Alright, part of the problem can be explained by the fact that even though the number of ODEs grows linearly with the number of cells, the work done to calculate the Jacobian doesn't grow quite grow linearly -- still, in all cases, the "one shot" method is significantly slower than the "broken up" method (and the greater than linear effort required in calculating the Jacobian also affected the "broken up" method). Also, the Jacobian doesn't become harder to calculate when increasing the time interval...so shouldn't the time taken to solve the ODE grow linearly there at least?

Alright, that's about all the certain information I have. My guess as to the number one culprit is that in the "one shot" method, the function used to calculate the Jacobian is doing a lot more work: recall, non-linear ODEs, so some internal iteration is required, and basically every iteration, all the coefficients are calculated again, while in the "broken up" method, I could choose which ones were held constant for a small time period, before recalculation. I thought reimplementing by making significant use of Cython (I used "annotation profiling" (cython -a my_file.pyx) to make sure I am cutting down on C lines wherever possible...so I am pretty sure I have not done a horribly ugly Python to C conversion. Still, even Cythonizing doesn't help with the fact that a lot more work is being done.

I'm at a bit of a loss right now as to how to proceed, so I clearly need help. Is scicomp.stackexchange the right place for it? Would I be better off mailing the scipy-users mailing list? Would the information I have presented above be good enough to form an answerable question on the main site? If not, what parts are salvageable enough to form a decent question? One question I could ask is: "is there a ode integration library better suited for my purposes?", and I think that is definitely on-topic at scicomp.stackexchange?

• Hi Geoff. I guess I understand so little about where I am stuck right now (or perhaps I simply demoralized enough that my brain isn't working), that I am at a bit of a loss as to how I could go about seeing my issue as a bunch of discrete questions I could tackle separately. Two steps I should take come to mind immediately: 1) I need to figure out how to properly profile my Cythonized code and more importantly 2) I need to figure out which results from the full output of odeint (which gives results like the number of time steps required to converge, etc.) will be most relevant for diagnosis. – user89 Oct 6 '14 at 7:19
• I'd like to be proactive though, and tentatively suggest how I might go about breaking up what I wrote above: (1) is it possible to somehow reduce the complexity of a non-linear ODE problem by assuming that some of the coefficients change "more slowly" than others? (this was the "quasi-equilibrium" thing I was mentioning). (2) Why would scipy.integrate.odeint's time increase non-linearly with increasing length of the interval over which the ODEs are solved. (3) Which ODE solving tool is best suited for my work (i.e. is it really worth exploring alternatives to scipy.integrate.ode)? – user89 Oct 6 '14 at 7:24