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


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

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

Add a New Comment (Rich Markup)

Comment Type & Canned Response:


( Jump to the original submission )

Tue 20 Sep 2022 03:07:02 PM UTC, comment #12: 

adding dependency and closing this report as the work is being handled with other options under bug #63063

Nicholas Jankowski <nrjank>
Project Member
Tue 20 Sep 2022 01:41:50 AM UTC, comment #11: 

I have submitted a patch on bug #63063 which both contributes to fixing it, and also implements the Refine option. To avoid duplication, I am only posting it there. The patch is posted in Comment #9 on that bug; Comment #8 there also has a prerequisite patch.

On the other bug discussion, I have posted some test files that verify my patches fix those issues. Here, I am posting a test script showing that the patches reproduce Matlab's results with Refine, including when output is as variables or struct, and when Events, OutputFcn's, or both, are used in the ode solver. See attached file <bug49408testscripts.zip>.

(file #53728)

Ken Marek <m5318>
Mon 19 Sep 2022 10:05:06 PM UTC, comment #10: 

I have posted some patches for bug #63063, a bug report that I created to fix some behavior of Events and OutputFcn handing. Those issues needed to be fixed before I could address the Refine functionality, and I thought things would be smoother if I addressed them as a separate bug. Part of that patch involved removing a problematic Refine implementation.

Further patches submitted here will probably be patched in relation to the fix for bug #63063, so hopefully that fix will be incorporated into the repository soon.

Ken Marek <m5318>
Sun 11 Sep 2022 02:25:01 AM UTC, comment #9: 

Multiple smaller patches where each patch addresses a specific issue are very much preferred.

Guidelines for submitting patches can be found on the Wiki at https://wiki.octave.org/Contribute.  The Octave volunteers can always clean up patches, but it's easier if they arrive well-formed.

Rik <rik5>
Project Administrator
Fri 09 Sep 2022 08:39:34 PM UTC, comment #8: 

I see the file attachment location now. I missed it because it is so far away from the comment text box. Thank you for the clarification.

The ODE functions relevant to this bug are included in Octave now, so maybe that means they're in the core. I called it the ODE package because they are all collected under \scripts\ode\ in the source code. I think there may be some other Octave ODE related functions elsewhere in the source as well, which would not be affected by any changes here.

I think the required changes can be submitted in a few independent patches. Would you like me to submit them that way for ease in explaining each part, or would you like everything in a single patch?

Ken Marek <m5318>
Fri 09 Sep 2022 04:49:50 AM UTC, comment #7: 

You can attach patches in the "Attached Files" section close to the bottom of this page. Please, also add a comment explaining your changes.

This bug isn't marked to apply to the ode package. I guess it is about the functions in Octave core?

Markus Mützel <mmuetzel>
Project Member
Thu 08 Sep 2022 09:16:27 PM UTC, comment #6: 

I would like to fix this bug, which appears to be current and not have anybody working on it.

I have taken a look at the relevant code in the ODE package (it touches a few files), and I think the solution will be straightforward enough. Part of the process will involve clearing out some related code that effectively does nothing, and making a couple implementation decisions which I think only have one obvious right answer.

I have a few questions as I get started:

1. Any reason I shouldn’t work on this?
2. Should I start an explicit discussion of what code I am removing and why, and/or of what relevant implementation decisions I want to make (and why)? If so, where should I post those discussions?
3. Where should I submit my changes, and in what format? At present I can't find any way to submit a fix here, but maybe I could if it were assigned to me?

I have also posted a similar message on the discord:

Ken Marek <m5318>
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:

Note:   Refine does not apply when length(tspan) > 2, or when the ODE solver returns the solution as a structure.

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:

>> sol = ode45 (@(t, x) -10 * x, [0 1], 1, odeset ('Refine', 3))
sol =
     solver: 'ode45'
    extdata: [1x1 struct]
          x: [0 0.0201 0.1023 0.1807 0.2593 0.3380 0.4166 0.4953 0.5739 0.6525 0.7312 0.8098 0.8950 1]
          y: [1 0.8180 0.3598 0.1642 0.0748 0.0341 0.0155 0.0071 0.0032 0.0015 6.6905e-04 3.0481e-04 1.3005e-04 4.5600e-05]
      stats: [1x1 struct]
      idata: [1x1 struct]

Matlab test for second case:

>> [t, x] = ode45 (@(t, x) -10 * x, [0 .5 1], 1, odeset ('Refine', 3))
t =
x =

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

myfun = @(t, y) 1;

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

facmax = 1.5;

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

myfun = @(t, y) 1;

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

myfun = @(t, y) 1;
[t, y] = ode45 (myfun, [0 1], 1, odeset ('maxstep', 1, 'initialstep', .1, 'refine', 1));
ans =
         0    0.1000    0.6000    1.0000

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.

myfun = @(t, y) 1;
[t, y] = ode45 (myfun, [0 1], 1, odeset ('maxstep', 1, 'initialstep', .1, 'refine', 3));
ans =
         0    0.0333    0.0667    0.1000    0.2667    0.4333    0.6000    0.7333    0.8667    1.0000

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:

>> [t, y] = ode45 (myfun, [0 1], 1, odeset ('maxstep', 1, 'initialstep', .1, 'refine', 3)); t.'
ans =
         0    0.0333    0.0667    0.1000    0.2667    0.4333    0.6000    0.7333    0.8667    1.0000
>> [t, y] = ode45 (myfun, [0 1], 1, odeset ('maxstep', 1, 'initialstep', .1, 'refine', 1)); t.'
ans =
         0    0.1000    0.6000    1.0000

the same code when run in Octave returns:

>> [t, y] = ode45 (myfun, [0 1], 1, odeset ('maxstep', 1, 'initialstep', .1, 'refine', 3)); t.'
ans =
   0.00000   0.10000   0.25000   0.47500   0.81250   1.00000
>> [t, y] = ode45 (myfun, [0 1], 1, odeset ('maxstep', 1, 'initialstep', .1, 'refine', 1)); t.'
ans =
   0.00000   0.10000   0.25000   0.47500   0.81250   1.00000

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:

Attached Files
file #53728:  bug49408testscripts.zip added by m5318 (3KiB - application/x-zip-compressed)


   bug dependencies.

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by nrjank (Posted a comment)
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by m5318 (Posted a comment)
  • -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)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only project members can vote.





    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-09-20 nrjank StatusConfirmed Duplicate
        Open/ClosedOpen Closed
    2022-09-20 nrjank Dependencies- Depends on bugs #63063
    2022-09-20 m5318 Attached File- Added bug49408testscripts.zip, #53728
    2016-11-17 mtmiller Release4.2.0-rc2 dev
    2016-10-21 rik5 StatusNone Confirmed

    Back to the top

    Powered by Savane 3.9