On 4/13/11 1:44 AM, Luc Maisonobe wrote: > Le 12/04/2011 21:29, Phil Steitz a écrit : >> On 4/12/11 11:24 AM, Luc Maisonobe wrote: >>> Le 12/04/2011 18:10, Phil Steitz a écrit : >>>> 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? >>> I'm not sure I understand well but it seems impossible to me. Both the >>> integrators and the problems should be generic. There are several >>> integrators implementations, and we provide them (I don't think any >>> users did put their own integrators, despite it is theoretically >>> possible). There are many problems implementations, as they are >>> user-specific. For each user problem, the user may choose several >>> different integrators mainly to compare the results, or choose between a >>> fast one and an accurate one, or for validation purposes with existing >>> reference solutions (the last case is the one I am more concerned with). >>> >>> Basically, a classical code architecture is to have on one side some >>> kind of factory with cases devoted to specific integrators or integrator >>> categories but without any hint about the problem, and on the other side >>> the problem definition that does know much about the integrator that has >>> been set up by the factory. Resetting the tolerance for the global >>> adaptive stepsize integrators category should lie somewhere between >>> these two pieces of code, quite close to the problem definition. >> Yes, that is what I was thinking. May not be practical or possible, >> but my intuition was that introducing an ODEProblem abstraction >> might allow for this, with specializations allowed to include >> different parameters for different types of integrators. >>> My exact use case is that the user has already built the integrator, and >>> when he feeds the problem, he has to reset the accuracy to take into >>> account some specific properties of the problem. >> Which is why it seemed natural to me to make that information part >> of the problem. >> >>> However, since the >>> integrator has already been built, he has no access to the tolerances >>> arrays anymore. An even worse problem occurs when the user wants to >>> append some additional equations to his problem, so instead of having >>> only a dimension 7 state vector, he suddenly needs a dimension 56 >>> vector, to hold both his original state vector but also a 7x7 jacobian >>> matrix. The size of the original tolerances do not match and the >>> integrator has to be completely rebuilt, which force the user to know >>> how it was built and how it was configured to repeat all these steps. >>> Adding setters for the tolerance would greatly simplify this. >> If the ODEProblem abstraction could work, then this would be a >> modification to the problem, requiring no mutation of the Integrator >> itself. > Yes, but it would be a modification of a major user interface and would > force users who don't need this feature to implement the new methods > too. I was thinking that the ODEProblem would be specialized itself, so only the methods appropriate for a given integrator would need to be implemented in posing a problem for that integrator. > On the other hand, adding the setters is a change on [math] code, > not user code, and not at interface level but at one abstract class level.
Definitely a simpler change just to add the setters. Looking carefully at what would be required to fully separate the ODEProblem from the integrators, I agree that while some new users might like the refactored API better, it would require a lot of change for no real value for existing users, so I agree with you. +1 to just add the setters. Phil > Luc > >> Phil >>> Luc >>> >>>> 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 >>>> >>>> >>> --------------------------------------------------------------------- >>> 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
