maximum steps exception with odeint
22 views
Skip to first unread message
Sebastian Weber
Oct 12, 2015, 3:49:20 PM10/12/15
to stan development mailing list
Hi Bob!
You are right in that it´s probably better to continue here. The new max_step_exception branch in the odeint-v2 repository does throw an exception - so it is exactly the same as if the ode system functor were to throw an exception. I think you should decide for whatever is easier to get in quickly. From that perspective you are probably right in that throwing an exception is easiest as it is quickest to deploy to stan and the interfaces. The only upside I see of going with the odeint patches is that the counter is reset between time-points automatically which is a bit cumbersome to achieve using the current design (the observer would have to reset elements of the coupled_ode_system object).
Sebastian
Bob wrote:
I think we can sneak some headers in by hand in the interfaces,
put them first on the build path, and then the header guards will block
the official ones. It's what Ben did to hack around the official Boost
headers in R's BH package. It makes everything much more brittle, of course,
to user library substitutions, paths, etc., so I want to save this as a last-ditch
effort as we had to do for the older Intel compiler.
Can we just use the exception throwing approach for now?
- Bob
You are right in that it´s probably better to continue here. The new max_step_exception branch in the odeint-v2 repository does throw an exception - so it is exactly the same as if the ode system functor were to throw an exception. I think you should decide for whatever is easier to get in quickly. From that perspective you are probably right in that throwing an exception is easiest as it is quickest to deploy to stan and the interfaces. The only upside I see of going with the odeint patches is that the counter is reset between time-points automatically which is a bit cumbersome to achieve using the current design (the observer would have to reset elements of the coupled_ode_system object).
Sebastian
Bob wrote:
I think we can sneak some headers in by hand in the interfaces,
put them first on the build path, and then the header guards will block
the official ones. It's what Ben did to hack around the official Boost
headers in R's BH package. It makes everything much more brittle, of course,
to user library substitutions, paths, etc., so I want to save this as a last-ditch
effort as we had to do for the older Intel compiler.
Can we just use the exception throwing approach for now?
- Bob
Bob Carpenter
Oct 12, 2015, 4:54:03 PM10/12/15
to stan...@googlegroups.com
Is this in an issue somewhere? My head's spinning from
all the options on the table for ODE solvers.
- Bob
> --
> You received this message because you are subscribed to the Google Groups "stan development mailing list" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to stan-dev+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
all the options on the table for ODE solvers.
- Bob
> You received this message because you are subscribed to the Google Groups "stan development mailing list" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to stan-dev+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
Sebastian Weber
Oct 13, 2015, 5:03:30 PM10/13/15
to stan development mailing list
Hi Bob!
My last comment in
https://github.com/stan-dev/math/issues/179
Describes what needs to be done to make the current odeint rk45 integrator robust.
Sebastian
Bob Carpenter
Oct 13, 2015, 8:21:57 PM10/13/15
to stan...@googlegroups.com
Great. We have that targeted for 2.8.0++ and assigned
to Daniel, so it's top priority.
- Bob
to Daniel, so it's top priority.
- Bob
Reply all
Reply to author
Forward
0 new messages