Fri 23 Oct 2015 03:10:52 PM UTC, comment #3:
The ode45 function has been moved into core Octave in the development branch (it will be in Octave 4.2) and has undergone a lot of modifications.
With the current version I see:
so it seems this bug is not there anymore.
i am closing this ticket, please post a new bug if you see other problems with ode45.
|
Mon 11 Mar 2013 05:28:01 AM UTC, original submission:
It appears that when using a variable step size, if the estimated error 'vdelta' gets too small (e.g. if your solution is converging to a constant), the step size sometimes starts getting smaller rather than larger, until the solution fails. Here is a trivial example that demonstrates this behaviour in the ode45 function...
Example
-------
Reason
------
It seems the code that causes this is around line 440 of ode45.m:
Before this code vdelta = [0;0] and vtau = [1.0000e-06;2.6714e-04] (since u=[0;267.14]).
After replacing the zero values with max(vtau).*(0.4^(1/vpow)), vdelta = [2.7356e-06;2.7356e-06].
Now the value of 0.8*(vtau./vdelta).^vpow) is [0.65415;1.99999], since we take the min() of that we multiply vstepsize by a factor of 0.65415 - this is different from.the comment which says we should double vstepsize in this case (which makes much more sense).
Suggested solution
------------------
I would suggest the simplest solution is to amend line 440 to replace the zero values with min(vtau).(0.4^(1/vpow)) rather than max(vtau).(0.4^(1/vpow)). Then, since subsequent code also uses min() [or max() of the negative value], the code will always have the expected effect of doubling the vstepsize. I am attaching a patch to this effect for all the affected functions.
Thanks,
Matt
|