This behavior will be changed later on to get immutable objects.
For now, we still rely on arrays being shared between the integrator and
the interpolator.
We can just use a factory method in the integrator for building an
interpolator each time we integrate.
In the long term, we will even recreate it at each step so the
interpolator can be immutable.
This addition is for consistency with other user-implemented interfaces
as step handlers and event handlers. However, since the equations have
only the state as input and the produce derivatives as output, their
init method also only uses state, as derivatives can be computed only
after equations have been initialized, not before.
This layer implements boilerplate code, mainly step handling and events
handling. It is independent of the type of integrator used. Below this
layer will be the real implementations (Runge-Kutta, embedded
runge-Kutta, Gragg-Bulirsch-Stoer, Adams, ...).
We have merged together what was initially in an integrator interface
and in an AbstractIntegrator class. The separation was only due to
backward compatibility issues which prevented to push some functions up
in the interface. A consequence was that users needed to use the
abstract class in their declaration as soon as they needed the
additional features ... which was most of the cases. We try to fix this
here. When 4.0 will be out, the same merging will be done in the
double[] implementation of ode.
JIRA: MATH-1288
This corresponds to an improved g-stop feature. It basically allow to
manage discrete events that occur during ode integration. when the event
occurs, user can decide to log it and continue, or to change the
dynamics of a problem (for example to handle derivatives
discontinuities) or even to stop the integration before its target date
(for example when the exact final date cannot be known beforehand but is
discovered on the fly). It is the second major feature of our ode
package.
Luc Maisonobe