TOO_MUCH_WORK exception

[wds15]

In order to use non-stiff solvers in parameter estimation algorithms a too much work type of exception would be very useful (since some parameter values can render a system very stiff causing odeint to essentially freeze the program).

Many thanks.

[mariomulansky]

see #173 for some discussion leading to this request

[mariomulansky]

addressed in 23ffb209fa14d26a2217ea837c5f49081fa209ac

[wds15]

Looks very promising. How about defining a maximal number of steps in terms of maximal density of steps? Hence, the exception would be thrown if more than XX steps are needed per dt?

For example no more than 1E3 steps within a time-interval of 0.1?

Just a thought.

[mariomulansky]

this is exactly what is happening - at least what should be happening. the exception is thrown if the number of steps between observer calls exceeds the given threshold.

[wds15]

but the observer calls are not necessarily equi-distant. In integrate_times I can make huge and small jumps and the observer gets called after very different time-spans. I don´t know the details, but this is the right thing to do, I think.

[mariomulansky]

Yes I see. However, I'm (roughly) following the CVODE implementation here.

And to me this makes sense. The idea is that I throw an exception if I spend to much time without any "visible progress". And visible progress simply means observer calls - anything else would mean to make assumptions on typical step size and won't be universal.

[wds15]

That´s fine. And in a sense this sets a lower density limit of steps, i.e. the largest timespan/threshold value is then the density step limit.

BTW, have you considered ODEs with sensitivities like CVODES implements? Is that of interest for odeint?

... I know this is off-topic, but before I start an issue for this really big topic, I have put it here (even though it does not belong here).

[mariomulansky]

I've finished the updates, the branch max_step_exception now contains possible exception checks in the integrate functions. Note that for backwards compatibility the standard choice is no checks, you will have to provide max_step_checker explicitly in the integrate functions to switch on the overflow checks.

It would be great if you could try whether this implementation works for your use case. I've build some test cases to ensure basic functionality, but a "production" use case would be better.

[wds15]

Ok, I can try that one. Just one question: odeint v2 is not part of boost, right? Are there plans to eventually update odeint in boost at some time?

[mariomulansky]

odeint-v2 is the one that is also in boost. Development mainly happens here, but we synchronize the boost version regularly.

[wds15]

I tested this patch in Stan - and it works nicely! Great work. Very easy to apply and straightforward.

[mariomulansky]

Nice to hear it works! I'll keep it open until the branch is actually merged.

[mariomulansky]

Merged in #176 Furthermore about to be released in Boost 1.60