octave-bug-tracker
[Top][All Lists]
Advanced

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

[Octave-bug-tracker] [bug #53669] core ode45 takes too long adaptative s


From: Carlo de Falco
Subject: [Octave-bug-tracker] [bug #53669] core ode45 takes too long adaptative steps.
Date: Mon, 16 Apr 2018 17:06:43 -0400 (EDT)
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:59.0) Gecko/20100101 Firefox/59.0

Update of bug #53669 (project octave):

                  Status:                    None => Works For Me           

    _______________________________________________________

Follow-up Comment #2:

The selection of time steps by the adaptive algorithm is guided by the attempt
of keeping the number of time steps as low as possible while achieving a local
truncation error within the selected tolerance.

Therefore, if the algorithm is using fewer steps to achieve the same pointwise
accuracy it means the new implementation is working BETTER than the old one.

The graphical appearance of the plot is in no way taken into account when
choosing the time steps.

If you want to force the integrator to use a smaller timestep you can set the
"MaxStep" option:



>> opt = odeset ('maxstep', 1e-2);
>> [TS,YS] = ode45 (fvdp, [0, 20], [2, 0], opt);
>> [T, Y] = ode45 (fvdp, [0, 20], [2, 0]);
>> plot(Y(:,1),Y(:,2),'rx',YS(:,1), YS(:,2), 'b-') 
>> legend ('default adaptive step', '.01 maxstep')


As you can see from this example the smaller timestep does not seem to lead to
any noticeable improvement, but the computation time IS slower so the default
adaptive step seems to have worked correctly.


You can improve the plot appearance without incurring the higher computation
cost if you add a set of interpolation points in the timespan :


>> opt = odeset ('maxstep', 1e-2);
>> [TS,YS] = ode45 (fvdp, [0, 20], [2, 0], opt);
>> [T, Y] = ode45 (fvdp, [0:1e-2:20], [2, 0]);
>> plot(Y(:,1),Y(:,2),'rx',YS(:,1), YS(:,2), 'b-') 
>> legend ('default adaptive step', '.01 maxstep')


as you can see from this latter plot the two phase plots are 
almost indistinguishable even though the second one worked much faster.

Qualitatively everything seems to have worked correctly here, so unless
you can show quantitative data demonstrating that the computation was
inaccurate 
in the sense that the truncation error was not within tolerance this bug
should be closed as invalid.




    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?53669>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

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