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
>>> problemdependent 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 toplevel 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
>>> betternamed 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
userspecific. 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.
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. 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.
Luc
>
> Phil
>> Luc
>>
>>> Phil
>>>> Luc
>>>>
>>>>
>>> 
>>>> To unsubscribe, email: devunsubscribe@commons.apache.org
>>>> For additional commands, email: devhelp@commons.apache.org
>>>>
>>>>
>>>
>>> 
>>> To unsubscribe, email: devunsubscribe@commons.apache.org
>>> For additional commands, email: devhelp@commons.apache.org
>> 
>> To unsubscribe, email: devunsubscribe@commons.apache.org
>> For additional commands, email: devhelp@commons.apache.org
>>
>>
>
>
> 
> To unsubscribe, email: devunsubscribe@commons.apache.org
> For additional commands, email: devhelp@commons.apache.org
>
>

To unsubscribe, email: devunsubscribe@commons.apache.org
For additional commands, email: devhelp@commons.apache.org
