commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <Luc.Maison...@free.fr>
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, luc.maisonobe@free.fr wrote:
>>>> Hi Phil,
>>>>
>>>> ----- "Phil Steitz" <phil.steitz@gmail.com> a écrit :
>>>>
>>>>> On 4/12/11 1:51 AM, luc.maisonobe@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-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message