commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: [math] resetting relative and absolute tolerances in ODE adaptive step size integrators
Date Wed, 13 Apr 2011 14:36:33 GMT
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.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.
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-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
>
>


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


Mime
View raw message