Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (athena.apache.org: domain of phil.steitz@gmail.com
 designates 209.85.212.179 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references
         :in-reply-to:content-type:content-transfer-encoding;
        b=Y6lkQpKhPwzT+jJz7KuXh4C949xlC8yoaSTAE534JNvM6lBTSZPodzAV9cNASmwQPH
         p2EKUR7jQXdEYSUhts0/MIhJkAnIYbiT5vprMo7nQBGYmPG6PIIOZSLytaiDOH2XKvUq
         H86zPCJ2/UBoffdQG9LQk7S76O3O6SuscX5Xk=
Message-ID: <4DA4A7FE.5030702@gmail.com>
Date: Tue, 12 Apr 2011 12:29:02 -0700
From: Phil Steitz <phil.steitz@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US;
 rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9
MIME-Version: 1.0
To: Commons Developers List <dev@commons.apache.org>
Subject: Re: [math] resetting relative and absolute tolerances in ODE adaptive
 step size integrators
References: 
 <379411337.1755041302622016003.JavaMail.root@spooler6-g27.priv.proxad.net>
 <4DA47985.3070903@gmail.com> <4DA498C5.5010401@free.fr>
In-Reply-To: <4DA498C5.5010401@free.fr>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

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.

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