bugGNU Octave - Bugs: bug #38499, odepkg: solvers sometimes fail...


bug #38499: odepkg: solvers sometimes fail when error term gets too small

Submitted by:  None
Submitted on:  Mon 11 Mar 2013 05:28:01 AM UTC  
Category: Octave Forge PackageSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Incorrect Result
Status: FixedAssigned to: Carlo de Falco <cdf>
Originator Name: Matthew ChapmanOriginator Email: -unavailable-
Open/Closed: ClosedRelease: 3.6.4
Operating System: Any

Add a New Comment(Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


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.

Carlo de Falco <cdf>
Project MemberIn charge of this item.
Fri 02 Oct 2015 04:14:06 PM UTC, comment #2:

Can someone comment about whether this issue still relevant with respect to the current version of ode45?

Carlo de Falco <cdf>
Project MemberIn charge of this item.
Mon 18 Mar 2013 09:52:16 PM UTC, comment #1:

Your patch looks OK, but I haven't had time to test it yet.
Would it be possible for you to add also some embedded tests
to check that the solver behavior is correct after the patch


Carlo de Falco <cdf>
Project MemberIn charge of this item.
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...



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.




(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):

Attached Files
file #27596:  odepkg-min-vtau.patch added by None (3KiB - text/x-patch)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -unavailable- added by cdf (Posted a comment)
  • -unavailable- added by cdf
  • -unavailable- added by None (Submitted the item)

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.


    Please enter the title of George Orwell's famous dystopian book (it's a date):



    Follow 6 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Fri 23 Oct 2015 03:10:52 PM UTCcdfStatusNone=>Fixed
    Mon 18 Mar 2013 09:52:16 PM UTCcdfAssigned toNone=>cdf
      Carbon-Copy-=>Added sebastian schöps
    Mon 11 Mar 2013 05:28:01 AM UTCNoneAttached File-=>Added odepkg-min-vtau.patch, #27596

    Back to the top

    Powered by Savane 3.1-cleanup1