On 4/12/11 8:26 AM, luc.maison...@free.fr wrote: > Hi Phil, > > ----- "Phil Steitz" <phil.ste...@gmail.com> a écrit : > >> On 4/12/11 1:51 AM, luc.maison...@free.fr wrote: >>> Hi all, >>> >>> I have hit a limitation of the current implementation of ODE >> integrators with adaptive step size. For now, the tolerances that are >> used to adjust the step size are specified only at construction time >> and cannot be changed afterwards. However, these tolerances are highly >> problem-dependent and in fact the dimension of the problem (which is >> related to the dimension of the vectorial version of the tolerances) >> is specified only at integration time, not at construction time. >>> So I consider adding at the top-level hierarchy (abstract class >> AdaptiveStepsizeIntegrator) a few setters to allow users to change >> these tolerances after the integrator has been built. It seems the >> integrators by themselves were not documented as immutable (I first >> thought they were), so this change is probably harmless. >>> I am going to open a Jira issue for this. >>> >>> Any thoughts ? >> One natural thing to consider is to provide the tolerances at >> integration time - i.e., to either add the vectors explicitly as >> arguments to the integrate method or to create an ODEProblem or >> better-named class that encapsulates the DE, tolerances, initial >> values and time parameters. > No, it would break the interface that is shared with fixed step size > integrators. > Preserving the compatibility with both types of integrators is very > important. This > is the same reason why step size is not set at integration time for fixed > step integrator.
Got it. What about putting the specialization in the Problem class rather than in the integrators? So the fixed step integrator gets a specialized integration problem rather than exposing problem parameters itself? Would something like that be possible? Phil > Luc > >> Phil >>> Luc >>> >>> >> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
