help-gsl
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Help-gsl] ode version and compilers


From: Alan Fung
Subject: Re: [Help-gsl] ode version and compilers
Date: Thu, 7 Nov 2013 00:24:43 +0800

Yes.  Your interpretation is good.

In your simple example,

gsl_odeiv2_evolve_apply (e, c, s, &sys, &t, t+1, &h, y);  // First call
// modify system parameters in some fashion
gsl_odeiv2_evolve_apply (e, c, s, &sys, &t, t+1, &h, y);  // Second call

After the first call, e->dydt_out is updated by the most updated y.
However, in 4771, e->dydt_in in the second call is updated by e->dydt_out.
But e->dydt_out is based on old parameters before modifications. It may
cause problems, as dydt_in is the next k1 in stepping functions.  The
deviation may cause the step size to be very small.  I guess this is the
reason why somebody experiences a performance regression.

Alan


2013/11/6 Rhys Ulerich <address@hidden>

> > For simplicity, I would like to call the following segment an iteration.
> >
> > while (t < t1)
> >   {
> >     int status = gsl_odeiv2_evolve_apply (e, c, s, &sys, &t, t1, &h, y);
> >
> >     if (status != GSL_SUCCESS)
> >       break;
> >   }
> >
> > ...
> >
> > Honestly, I started to worry whether modifying things in params outside
> > iterations is a misuse of GSL.
>
> This may be a use case for which 4771 introduces a bug.  Hear me out...
>
> When using a plain-vanilla RK4 scheme, the system of equations and all
> of its parameters must remain fixed from substep-to-substep for
> full-order accuracy to be achieved.  However, between RK4 steps one is
> permitted to change the parameters however one likes.
>
> Along that line of reasoning, I would expect
>     gsl_odeiv2_evolve_apply (e, c, s, &sys, &t, t+1, &h, y);
>     // modify system parameters in some fashion
>     gsl_odeiv2_evolve_apply (e, c, s, &sys, &t, t+1, &h, y);
> to behave identically pre- and post-4771 as line 1 completes some
> number of full steps of the chosen scheme.  That is, the modification
> in line 2 is not done in between substeps.
>
> Alan, am I interpreting your use case correctly?
>
> Tuomo, is this use case supported and, if so, does 4771 break it in
> some fashion?
>
> - Rhys
>


reply via email to

[Prev in Thread] Current Thread [Next in Thread]