bugGNU Octave - Bugs: bug #49408, ode{23,45} option...


bug #49408: ode{23,45} option "Refine" has no effect

Submitted by:  Carlo de Falco <cdf>
Submitted on:  Fri 21 Oct 2016 08:14:31 PM UTC  
Category:  Octave Function Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Confirmed Assigned to:  None
Originator Name:  Open/Closed:  Open
Release:  dev Operating System:  Any

Add a New Comment(Rich Markup)

You are not logged in

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


Mon 24 Oct 2016 05:05:41 AM UTC, comment #5:

I pushed a cset that disables the Refine option when a sngle output is requested or when specific intermediate timesteps are given (http://hg.savannah.gnu.org/hgweb/octave/rev/04fc7e9c5f96). This is only a partial fix which will become important when the Refine option is actually implemented.

Rik <rik5>
Project Administrator
Sun 23 Oct 2016 09:48:33 PM UTC, comment #4:

According to Matlab documentation for odeset:

This merely confirms what the testing shows.

Rik <rik5>
Project Administrator
Sat 22 Oct 2016 08:56:47 PM UTC, comment #3:

Some experiments with Matlab show that 'Refine'
is ignored also in the following two cases

  • only one output is requested (this case is related to bug #49417 )
  • tspan has more than two entries

Matlab test for first case:

Matlab test for second case:

Carlo de Falco <cdf>
Project Member
Sat 22 Oct 2016 06:20:56 AM UTC, comment #2:

Clarification about the different choice of principal timesteps.
With odefun set to

the ODE could be integrated exactly in only one step,
so the timestep size is grown by the maximum factor allowed
at each step.

In Octave the maximum factor is

while from the output of this test it appears to be set to 5 in Matlab.

A large value of facmax can help with very simple problems
but can lead to many timestep rejections in practical cases.

This is more of a problem in Octave than in Matlab because of JIT so it is fair for Octave to be more conservative.

Therefore the issue here is indeed only the missing refinement steps and not the timestep selection procedure.

Carlo de Falco <cdf>
Project Member
Fri 21 Oct 2016 10:33:14 PM UTC, comment #1:

Further clarification, the integrated function myfun is

With the Refine option set to 1, only the principal timesteps are calculated. Under Matlab, the code below chooses just 4 time steps.

When Refine is an integer N greater than 1 then N-1 intermediate timesteps are calculated. So, the three gaps between the principal timesteps should each get 2 smaller timesteps. This is indeed what happens under Matlab.

Under Octave, the solver, without the Refine option, chooses 6 principal timesteps. I don't think this is an issue, just a difference from Matlab. However, when the Refine option is used, Octave does not generate any intermediate timesteps which is a problem.

Rik <rik5>
Project Administrator
Fri 21 Oct 2016 08:14:31 PM UTC, original submission:

consider the following test in Matlab 2016a:

the same code when run in Octave returns:

it seems that the intermediate steps are computed in integrate_adaptive
but not added to the output.

Carlo de Falco <cdf>
Project Member


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

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by mtmiller (Updated the item)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by cdf (Submitted the item)

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

    Only project members can vote.




    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-11-17 mtmiller Release4.2.0-rc2 => dev
    2016-10-21 rik5 StatusNone => Confirmed

    Back to the top

    Powered by Savane 3.3