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: NoneAssigned to: Carlo de Falco <cdf>
Originator Name: Matthew ChapmanOriginator Email: -unavailable-
Open/Closed: OpenRelease: 3.6.4
Operating System: Any

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

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

 

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
application?

Thanks,
c.

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...

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

Anonymous

 

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

Attach File(s):
   
   
Comment:
   

Attached Files
file #27596:  odepkg-min-vtau.patch added by None (3kB - 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 4 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Mon 18 Mar 2013 09:52:16 PM UTCcdfAssigned toNone=>cdf
      Releasedev=>3.6.4
      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-cleanup