commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <>
Subject Re: [math] resetting relative and absolute tolerances in ODE adaptive step size integrators
Date Wed, 13 Apr 2011 08:44:37 GMT
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, wrote:
>>>> Hi Phil,
>>>> ----- "Phil Steitz" <> a écrit :
>>>>> On 4/12/11 1:51 AM, 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.
>>>> 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.


> Phil
>> Luc
>>> Phil
>>>> Luc
>>>>> Phil
>>>>>> Luc
>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail:
>>>>>> For additional commands, e-mail:
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail:
>>>>> For additional commands, e-mail:
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail:
>>>> For additional commands, e-mail:
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message