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. 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. 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
