bugGNU Octave - Bugs: bug #52475, ode15 is not compatible with...


bug #52475: ode15 is not compatible with SUNDIALS >= 3.0.0

Submitted by:  Sebastian <sschoeps>
Submitted on:  Tue 21 Nov 2017 09:48:12 PM UTC  
Category:  Libraries Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Other
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  Closed
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.


( Jump to the original submission)

Wed 13 Mar 2019 07:42:18 AM UTC, comment #79:

OK, then I'm closing this one as fixed. If there are other issues, please open a new bug report.

John W. Eaton <jwe>
Project Administrator
Wed 13 Mar 2019 07:09:16 AM UTC, comment #78:

I pushed one more changeset to clean up the list of sundials
related includes and to remove use of deprecated functions


I have tested this on my system with sundials 3.1.0 and it
seems to work.

I do get a test failure with ode15i but that is related to
a change in str2func that I have posted about in the mailing

Carlo de Falco <cdf>
Project Member
Wed 13 Mar 2019 06:03:06 AM UTC, comment #77:

Thanks for checking it in.

Now on my Debian system, using the default library that is installed, I see the following in configure:

and then when I run make, I hit the following errors:

If I add

to my configure options so that "#include <klu.h>" will work, then I hit this error:

which is the problem I mentioned in comment #72. I pushed the following changeset to allow the build to succeed:


However, I suspect some issues with integer types remain. We should be careful to not use "int" or "long int" (I believe long int is just 32-bits wide on Windows systems) if we can avoid it. If there are cases where we need to deal with 32-bit ints, we should check that we don't have any issues with overflow. For example, using something similar to the checks that are done in the Matrix classes with "octave::to_f77_int".

John W. Eaton <jwe>
Project Administrator
Wed 13 Mar 2019 02:54:10 AM UTC, comment #76:

OK, I pushed the changes to default:


is it ok to close this ticket and continue any further
discussion in a new one or the maintainers list?

Carlo de Falco <cdf>
Project Member
Tue 12 Mar 2019 04:38:03 PM UTC, comment #75:

Yes, this change should go on default.

John W. Eaton <jwe>
Project Administrator
Tue 12 Mar 2019 04:06:33 PM UTC, comment #74:

Definitely the default branch please. Octave 5.1 works with sundials 2.7, we shouldn't suddenly break that on stable.

Mike Miller <mtmiller>
Project Administrator
Tue 12 Mar 2019 10:40:07 AM UTC, comment #73:

jwe, thanks again for your help.

the issue with including klu.h is known and was discussed before below.

with sundials 4.1.0, though, it should be solved, as now _ode15_.cc has

and sunlinsol/sunlinsol_klu.h uses an include guard
to not include klu.h if it was already included.

Anyway I agree we should apply this changes now and
then continue changes in the main repo.

Should I push to stable or default?

Carlo de Falco <cdf>
Project Member
Mon 11 Mar 2019 03:54:05 PM UTC, comment #72:

Carlo: I did have klu installed and the header sunlinsol/sunlinsol_klu.h was also present but not detected by configure. After looking more closely at the configuration problems, I found that it wasn't finding klu.h because on my system it is installed in /usr/include/suitesparse/klu.h but the sundials header is still only including <klu.h>. After adding -I/usr/include/suitesparse to CPPFLAGS it builds with your patches using my self-compiled copy of sundials 4.1.0. I configured that with

If I try to use the version installed on my system (3.1.2 on Debian), I see the following error:

Can we detect that Sundials is installed to use 32-bit integer indexing and adapt to that the same as we do for BLAS, LAPACK, and some other libraries?

In any case, I think it would be fine to apply these changes now.

John W. Eaton <jwe>
Project Administrator
Mon 11 Mar 2019 02:12:45 PM UTC, comment #71:

By looking better at the structure of headers in sundials 4.1
I think the sequence of includes in _ode15_.cc could be
simplified to

Carlo de Falco <cdf>
Project Member
Mon 11 Mar 2019 05:27:16 AM UTC, comment #70:

to clarify comment #69

should be in sunlinsol/sunlinsol_klu.h

if it isn't, including it directly would
fix the error

but it won't fix other errors related
to missing KLU related definitions.

I personally think it is not a good idea
to have two separate config variables to
detect whether sparse matrices are available
in sundials and whether sundials supports KLU.

But that choice is not new in this patch.

Carlo de Falco <cdf>
Project Member
Mon 11 Mar 2019 05:17:21 AM UTC, comment #69:

jwe, thanks for testing.

the current implementation of _ode15_
can only work with sparse jacobian if sundials
is built with KLU support.

from the errors you show I think your sundials
installations are without klu support as for comment #62.

On the other hand I think the autoconf logic
should either

1) disable the sparse jacobian feature if
klu is missing instead of trying to detect klu and
sparse matrix support separately

2) disable sundials alltogether if it does not
have all required features

Carlo de Falco <cdf>
Project Member
Sat 09 Mar 2019 10:09:50 AM UTC, comment #68:

After applying the three patches from comment #59 to the current development sources, I see the following on my Debian system.

Configuration once again finds Sundials and that seems to work for both the 3.1.x version installed from the Debian package or Sundials 4.1.0 that I built myself. But then compilation fails as follows.

With libsundials-dev 3.1.2+dfsg-3+b1 installed from Debian:

With self-compiled Sundials 4.1.0, I see these errors:

Either way, it looks the same to me. Where is the definition of SUNSparseMatrix? I don't quite follow how that is supposed to work.

John W. Eaton <jwe>
Project Administrator
Wed 06 Mar 2019 08:15:06 PM UTC, comment #67:

@cdf I haven't forgotten about this bug, and I would be happy to test your latest patch, but my distribution doesn't offer sundials 4 yet, so pulling the source and building it myself is a little more than I have time for at the moment. I'll check back in the spring.

Mike Miller <mtmiller>
Project Administrator
Tue 05 Mar 2019 12:37:50 PM UTC, comment #66:

Not until now. Using it causes general massive overlinking (as expected, I guess) but libsundials_sunlinsolklu is still not linked anywhere

Antonio Rojas <arojas>
Tue 05 Mar 2019 09:25:49 AM UTC, comment #65:

Do you have the option

enabled in your config?


Carlo de Falco <cdf>
Project Member
Mon 04 Mar 2019 09:35:25 PM UTC, comment #64:

_ode15_.oct is using a symbol which is not provided by any linked library, that's pretty much the definition of underlinking.

For now I'm working around it by using --with-sundials_ida="-lsundials_ida -lsundials_sunlinsolklu" at build time rather than polluting the user's env at runtime (not 100% techincally correct, I know, but works)

Antonio Rojas <arojas>
Mon 04 Mar 2019 09:05:02 PM UTC, comment #63:

klu is required for the sparse jacobian feature to work.
did you have sparse enabled and klu disabled in your build of sundials?

that situation is definitely not supported and probably should be detected by autotools ...

as for the other issue, I wouldn't call it "underlinking", as you say both compiling AND linking worked in your build.

what is failing is actually the loading of libsundials_sunlinsolklu.so at runtime.

you can fix that by adding the directory containing libsundials_sunlinsolklu.so to the RPATH or use LD_PRELOAD as in comment #53.

For a better fix we may wait for the sundials developers to support pkgconfig which they say is planned.

Carlo de Falco <cdf>
Project Member
Mon 04 Mar 2019 04:09:01 PM UTC, comment #62:

It seems the missing header problem was due to using a sundials version without klu - not sure if that's even supported. Anyway, I can't reproduce it once I enabled klu in sundials.

Underlinking is still an issue, though

Antonio Rojas <arojas>
Mon 04 Mar 2019 12:51:13 PM UTC, comment #61:

Hi Antonio,

Thanks for testing.

I am really surprised you need to include an extra header,
it should really not be required ...

Are you positive that you are actually using sundials 4.1.0 and you don't have other versions installed?

Would you mind trying the following test:

1) create a file named "test_sunsparsematrix.cpp" with the following contents

2) compile and link the test code.

I can do it on my system with the command

you may need to change the include and link paths according to your system configuration

If you get any error messages please post them to this thread.

Thanks again,

Carlo de Falco <cdf>
Project Member
Wed 27 Feb 2019 06:09:36 PM UTC, comment #60:

I tested this patch with sundials 4.1.0, there are two issues:

- Missing include <sunmatrix/sunmatrix_sparse.h>, which causes a compilation error

libinterp/dldfcn/__ode15__.cc:371:24: error: 'SUNSparseMatrix' was not declared in this scope

After adding the include, compilation succeeds but the compiled module is not linked to libsundials_sunlinsolklu.so, which gives a runtime error

error: ode15s: /usr/lib/octave/5.1.0/oct/x86_64-pc-linux-gnu/__ode15__.oct: failedto load: /usr/lib/octave/5.1.0/oct/x86_64-pc-linux-gnu/__ode15__.oct: undefined symbol: SUNKLU

Antonio Rojas <arojas>
Fri 15 Feb 2019 12:25:57 PM UTC, comment #59:

I updated the patch and split it into three different files
for clarity, the three files must be applied in order:

file #46271 (ode15_sundials_410_patch_0.txt)
file #46272 (ode15_sundials_410_patch_1.txt)
file #46273 (ode15_sundials_410_patch_2.txt)

@Dmitri if you install sundials 4.1.0 now the build should
work without need to specify

would you try this out when you have time?

I think NOW would be a good time to push this to the default
branch so that there is time to clean it up before the next
release (BTW, would that be 5.2.0 or 6.1.0?) and for downstream
packagers to package sundials 4.1.0

@mtmiller what do you think?

Carlo de Falco <cdf>
Project Member
Thu 14 Feb 2019 06:08:03 PM UTC, comment #58:

A new version of SUNDIALS is out : link

this should incorporate a patch I suggested to allow solving the klu include problem. I'll test soon and update the patch below.

Carlo de Falco <cdf>
Project Member
Wed 06 Feb 2019 05:20:48 PM UTC, comment #57:

I submitted a pull request to SUNDIALS which is now being considered by the SUNDIALS developers that would probably make it easier to solve the klu.h include issue.

A previous pull request was not accepted by SUNDIALS.

I am posting this update here in case someone else (mtmiller?) wants to join the discussion on the SUNDIALS tracker.

Carlo de Falco <cdf>
Project Member
Tue 05 Feb 2019 11:21:58 AM UTC, comment #56:

There is a new release of SUNDIALS, version 4.0.2
The current patch still works with the new release as well.

Carlo de Falco <cdf>
Project Member
Mon 28 Jan 2019 12:19:54 PM UTC, comment #55:

I got this reply from SUNDIALS developers.

It seems the leaking of KLU API headers is by design (?!?) but they might at least make allow to use <suitesparse/klu.h>


Carlo de Falco <cdf>
Project Member
Sun 13 Jan 2019 06:47:58 PM UTC, comment #54:

It's starting to look to me like the only realistic way to solve this is to completely overhaul how Octave looks for and includes the SuiteSparse header files to make it compatible with sundials. IMHO this is too big a change to make right before the Octave 5 release.

It's too bad these scientific libraries can't be convinced to register themselves with pkg-config.

Mike Miller <mtmiller>
Project Administrator
Sat 12 Jan 2019 08:34:22 PM UTC, comment #53:

If I preload libsundials_sunlinsolklu.so, it works:


Dmitri A. Sergatskov <dasergatskov>
Sat 12 Jan 2019 06:42:11 PM UTC, comment #52:

It would compile but would not run:


Dmitri A. Sergatskov <dasergatskov>
Sat 12 Jan 2019 10:20:09 AM UTC, comment #51:

The SUNDIALS developers seem to be "not inclined" to fix the upstream bug:


so we need to find a workaround.

@Dmitri did you manage to test whether

./configure CPPFLAGS=-I/usr/include/suitesparse ...

works any better for you?

Carlo de Falco <cdf>
Project Member
Wed 09 Jan 2019 04:37:40 AM UTC, comment #50:

I raised the question on the SUNDIALS mailing list here

Carlo de Falco <cdf>
Project Member
Tue 08 Jan 2019 10:52:53 AM UTC, comment #49:

Looking at the header sunlinsol_klu.h it has a comment saying

It seems to me that PART I should actually be a private header file while
applications should only include PART II.

If anyone wants to take care of contacting the SUNDIALS developers I think
that separating PART I and PART II into two separate files would solve the issue
for us.

Carlo de Falco <cdf>
Project Member
Tue 08 Jan 2019 01:06:16 AM UTC, comment #48:

The include of just "klu.h" does look suspicious. Is
it possible that they no longer want that to be visible?

Michael Godfrey <godfrey>
Project Member
Mon 07 Jan 2019 09:25:22 PM UTC, comment #47:

Yeah that does seem like it might be an upstream bug in sundials 3.x and 4.x.

Considering every other #include statement in the sundials software itself is of the form '<sundials/sundials_nvector.h>', and the only outlier is the single #include "klu.h", it seems like something should be fixed or at least discussed with upstream to see how this can be improved for everyone.

Until now there has never been a requirement that a user program compile against SuiteSparse with -I/usr/include/suitesparse, sundials is now effectively requiring that by leaking "klu.h" through their public API.

Mike Miller <mtmiller>
Project Administrator
Mon 07 Jan 2019 08:44:15 PM UTC, comment #46:

the reason why this used to work with sundials 2.7
is that in 2.7 sundials headers did not include klu.h
rather it was included in .c files only (I think this is a better choice) while in 4.0.1 line 46 of sunlinsol_klu.h has

Therefore I think this is an upstream issue we should report, but even if that is fixed upstream if we want to keep compatibility with sudials 3.0 through 4.0.1 we would need to find a way to deal with it in Octave

Carlo de Falco <cdf>
Project Member
Mon 07 Jan 2019 08:27:44 PM UTC, comment #45:


Thanks for testing!

Indeed the patch breaks compatibility with the 2.* release
but that is intended for two reasons:

1) I am not good enough at autotools to maintain that much
backward compatibility

2) As the current version of SUNDIALS is 4.0.1 I don't think
it is worth maintaining compatibility with more than 2 old
major releases (and quite afew minor releases)

Can you please try the following?

with the patch applied, run configure adding

to CPPFLAGS, i.e.

my understanding of the problem is that the Octave configure does detect
/usr/include/suitesparse/klu.h and sets the appropriate path in octave-config.h
so that it is included as

but /usr/include/sunlinsol/sunlinsol_klu.h has

which does not work. Unfortunately with the current test in configure this
results in

but in the final *config.h

but actually sundials/sparse and sundials/klu are unusable so the build fails.

The logic to do this detection is not affected by the patch,
so I still wonder how that could work before ...


P.S. please remember to run "make maintainer-clean" and "bootstrap" each time you apply or remove the patch.

Carlo de Falco <cdf>
Project Member
Mon 07 Jan 2019 03:57:17 PM UTC, comment #44:

I downgraded sundials to 2.7 and wit the current tip (no patch)
it worked just fine:

Updated to 3.1.1 (fedora's current version) and applied the patch.

Downgraded to 2.7 again , keep the patch applied.

So the patch broke something.


Dmitri A. Sergatskov <dasergatskov>
Mon 07 Jan 2019 03:04:32 PM UTC, comment #43:

FWIW -- some time ago I downgraded sundials to 2xx and it
compiled just fine. I guess I can try again...


Dmitri A. Sergatskov <dasergatskov>
Mon 07 Jan 2019 09:41:03 AM UTC, comment #42:


this seems the same issue as in comment #20 and comment #23, which is not new to 3.* and 4.* releases but is rather related to where sundials searches for klu.

what do you get if you type

Carlo de Falco <cdf>
Project Member
Thu 03 Jan 2019 07:10:19 AM UTC, comment #41:

On Fedora 29 (with Sundials 3.1.1) configure works, but compile
fails with:

9ec0a1e5d4d3+ (stable) tip


Dmitri A. Sergatskov <dasergatskov>
Thu 03 Jan 2019 06:45:43 AM UTC, comment #40:

I upgraded my sundials installation to the latest (4.0.1) and i can confirm that the cset in file #45848 still works

Carlo de Falco <cdf>
Project Member
Wed 02 Jan 2019 11:43:31 PM UTC, comment #39:

updating the current patch to work with Octave 5.
This is tested with SUNDIALS 3.2.1.

(file #45848)

Carlo de Falco <cdf>
Project Member
Fri 09 Nov 2018 12:16:03 PM UTC, comment #38:

Your comment #37 seems to be the best choice. Since I
use Fedora I have needed 3.0 for quite a while. But,
right now I am working on other stuff, so it is not
an urgent requirement.

In any case, thanks for all your help.

Michael Godfrey <godfrey>
Project Member
Fri 09 Nov 2018 12:08:58 PM UTC, comment #37:

I plan to keep compatibility with both and will try to extend it also to the coming Sundials 4.0 but will only have time to work on this on December.

I'm really going to use what I proposed in (4) for the reasons I explained there.

Andre da Costa Barros <andrecbarros>
Fri 09 Nov 2018 09:02:04 AM UTC, comment #36:

Question on this: do you want to preserve compatibility with both SUNDIALS 2.7 and 3.x, or just switch to 3.x?

Andrew Janke <apjanke>
Mon 05 Nov 2018 10:24:16 AM UTC, comment #35:

sorry I misspelled a sentence in the previous comment :

"With the patch modified by Orion the SUNDIALS is completely skipped so SUNDIALS becomes a mandatory dependency."

should read

"With the patch modified by Orion the variables set by configure to signal whetehr SUNDIALS is usable are completely ignored so SUNDIALS becomes a mandatory dependency."

to make things more clear I personally I think over-linking would be a minor issue (but I don't know what JWE would think about it).

The real issue is that the pre-processor fags used in conditionals inside _ode15_.cc should be set by configure by testing that a working SUNDIALS is available, not removed and ignored.

Carlo de Falco <cdf>
Project Member
Mon 05 Nov 2018 10:12:26 AM UTC, comment #34:


I'm not saying you should assign flags to make the build complete on your system.

What I say is that the configure script should be somehow able to detect whether or not a SUNDIALS installation is present on your system and whether or not it has the correct features, then decide whether or not Octave should link or not to SUNDIALS.

With the patch modified by Orion the SUNDIALS is completely skipped so SUNDIALS becomes a mandatory dependency.


Carlo de Falco <cdf>
Project Member
Mon 05 Nov 2018 09:49:56 AM UTC, comment #33:

From what I gather from configure.ac, indeed, octave does (1).

In my system, qhull doesn't have a .pc file, fftw does (what makes things easier).

The only penalty on giving assignments to *FLAGS to ./configure in step/phase, this is what I'm doing, is related to overlinking and it affects the binaries mostly if we are using static libs, with dynamic libs the unused references would be eliminated with --as-needed option on linking phase (it is not a clear cut, though, e.g., https://wiki.mageia.org/en/Overlinking_issues_in_packaging).

Have (4) implemented is doable to deal with complex cases but I would have to clear the dust from my previous knowledge about autotools. I can do it, but it will take time and I'm in a very busy period right now.

Andre da Costa Barros <andrecbarros>
Mon 05 Nov 2018 01:56:19 AM UTC, comment #32:


removing conditionals in the source code means
that building Octave will just outright fail when sundials
is not available or not the correct version.

As sundials is an optional dependency that should not be the case.

If you know some autotools scripting and would like to
propose a solution according to item 4 in your comment #30
that would be indeed welcome, but just removing all
conditionals and forcing the link is not an acceptable option.

To see how other optional dependencies are treated you may
look for example at what is done for FFTW, GLPK or QHULL.


Carlo de Falco <cdf>
Project Member
Sun 04 Nov 2018 08:53:06 PM UTC, comment #31:

"are not on cached/standard" -> "are not inside cached/standard"
"in may case" -> "in my case"

Sorry for that.

Andre da Costa Barros <andrecbarros>
Sun 04 Nov 2018 07:51:05 PM UTC, comment #30:

Hum, by parts:

1 - I don't know how octave handle it, but on many packages when you set *FLAGS it means a start point, not a whole substitution (more or less equivalent to SOMEFLAGS="$SOMEFLAGS --what-you-set-explicitly";
2 - It would be easier if every package generated a pkg-config .pc file to query where things are located and how to "link" and "include" things. Many don't, sundials doesn't;
3 - octave could get out of its way to guess where things were located using ldd and ldconfig on linux but things get really complicated when we use libraries that are not on cached/standard dirs;
4 - A possible solutions for this would be if octave had an option to, say, "some-random-lib" in the form of --with-some-random-lib-libs="-L<some_dir> -ldep1 -ldep2 .. -ldepn" in addtition to what it already use (--with-some-random-lib=, --with-some-random-lib-libdir= and --some-random-lib-includedir=);

Of course, the patch can and should be improved but, in may case, octave would, possibly, have to address (3) and (4) as I link sundials to superlu_mt and hypre and the standard setting may fail to get the extra linkage (i.e., the configure.in would have to check for extra libraries dependencies; not worth in my opinion as LDFLAGS and CFLAGS are simple and straightforward).

What I described in (4) would be a nice addition, I think (some packages use this).

Andre da Costa Barros <andrecbarros>
Sun 04 Nov 2018 04:27:23 PM UTC, comment #29:

Orion, Andre,

If I understand correctly what you are doing in file #45334
is remove all Preprocessor conditionals in order to force
using the code for sundials, is that the case?

The whole point in the patch is to detect
automatically the flags to set in order to
link with SUNDIALS so, if you need to set
the flags manually that means the patch is
not working.

As I said in comment #25 this part of the
patch was probably not correct even for SUDIALS 2.

Carlo de Falco <cdf>
Project Member
Sat 03 Nov 2018 06:34:59 AM UTC, comment #28:

Additionally, I had to add to LDFLAGS "-lsundials_ida -lsundials_idas -lsundials_sunlinsolklu -lsundials_fsunlinsolklu" but it is working now with sundials 3.2.1.

Thanks to everyone involved!

Andre da Costa Barros <andrecbarros>
Wed 31 Oct 2018 01:49:11 AM UTC, comment #27:

I've attached my updated version of the patch. I also needed to set CPPFLAGS=-I/usr/include/suitesparse in order for the sundials headers to find klu.h.

(file #45334)

Orion Poplawski <opoplawski>
Sat 27 Oct 2018 09:42:50 PM UTC, comment #26:

Any progress here?

Orion Poplawski <opoplawski>
Wed 09 May 2018 08:29:56 AM UTC, comment #25:

thanks for uploading the configuration files.
From what I see:

1) I found an error in the configure tests that I will fix ASAP
2) I am surprised this worked ever before even for sundials2

Carlo de Falco <cdf>
Project Member
Wed 09 May 2018 05:28:21 AM UTC, comment #24:

Yes, the changeset is relative to the default branch.
Yes, you need to run bootstrat to get a new configure script when configure.ac is patched.

Carlo de Falco <cdf>
Project Member
Wed 09 May 2018 04:21:50 AM UTC, comment #23:

config.h (as fc28_config.h) and config.log (as fc28_config.log)
are attached.


(file #44130, file #44131)

Dmitri A. Sergatskov <dasergatskov>
Wed 09 May 2018 04:06:21 AM UTC, comment #22:

I was messing with this stuff so I would need to recreate them.
Could you verify that
a) patach to be applied on default (dev) branch, not on stable.
b) since it patches configure.ac I need to re-run bootstrap
prior to configure.


Dmitri A. Sergatskov <dasergatskov>
Wed 09 May 2018 03:49:50 AM UTC, comment #21:


Thanks again for testing, I'm still not sure whether KLU for sparse Jacobian should be enabled or disabled for you ...

Can you please upload config.log and config.h?

Carlo de Falco <cdf>
Project Member
Tue 08 May 2018 10:54:16 PM UTC, comment #20:

configure step looked better, but compile failed:


Dmitri A. Sergatskov <dasergatskov>
Tue 08 May 2018 09:23:22 PM UTC, comment #19:

here's a new try at the changeset.

(file #44127)

Carlo de Falco <cdf>
Project Member
Tue 08 May 2018 09:17:28 PM UTC, comment #18:

sorry, I actually meant this one:

Carlo de Falco <cdf>
Project Member
Tue 08 May 2018 09:16:16 PM UTC, comment #17:

do you have the following in config.h?

Carlo de Falco <cdf>
Project Member
Tue 08 May 2018 08:59:33 PM UTC, comment #16:

it is in sunlisol sub-directory:


Dmitri A. Sergatskov <dasergatskov>
Tue 08 May 2018 08:53:51 PM UTC, comment #15:


Thanks for testing.

Indeed there seems to be something wrong, either
SUNLINSOL_KLU is installed but is not detected
or it is not installed, in which case its header
should not be included.

Which one is the case for you? Does "locate sunlinsol_klu.h"
return something for you?

Carlo de Falco <cdf>
Project Member
Tue 08 May 2018 08:48:25 PM UTC, comment #14:

comment #13 was truncated:

(which, I think, is wrong)

and during compile:

Carlo de Falco <cdf>
Project Member
Tue 08 May 2018 07:44:14 PM UTC, comment #13:

With current dev snapshot (bc5f225bc578+ tip @) on Fedora 28
(Sundials 3.1.0):

during configure:

Dmitri A. Sergatskov <dasergatskov>
Tue 08 May 2018 05:58:04 PM UTC, comment #12:

here is an updated patch, this works for me on macos 10.13 with a self built sudials 3.1.0

can someone else test the patch and/or look at it (especially the configure tests)?

(file #44125)

Carlo de Falco <cdf>
Project Member
Tue 08 May 2018 03:20:26 PM UTC, comment #11:

can you please be more specific about the compiler/linker flags you used to build _ode15_.oct from _ode15_.cc?

Carlo de Falco <cdf>
Project Member
Mon 07 May 2018 05:06:34 PM UTC, comment #10:

I built _ode15_.oct using this version of mingw:

c:\temp\Projects\ode15_ming64>where g++
c:\Program Files\mingw-w64\x86_64-7.2.0-win32-seh-rt_v5-rev1\mingw64\bin\g++.exe

Then, I ran these tests:

>> which ode15s

'ode15s' is a function from the file C:\Octave\OCTAVE~3.0\share\octave\4.4.0\m\ode\ode15s.m

>> test ode15s

PASSES 39 out of 39 tests

>> test ode15i

PASSES 48 out of 48 tests

I could do more testing, if needed.

Bill Greene <billgreene>
Mon 07 May 2018 04:20:17 PM UTC, comment #9:

The attached patch also changes configure tests.

(file #44113)

Carlo de Falco <cdf>
Project Member
Mon 07 May 2018 03:43:23 PM UTC, comment #8:


I turned your patch into a proper changeset that applies on the current development branch and made a few style fixes.

How did you build and test the code?

If I apply the changeset and run "configure" the tests for IDADENSE and IDAKLU fail and ode15{i,s} get disabled ...


(file #44112)

Carlo de Falco <cdf>
Project Member
Mon 07 May 2018 12:14:43 PM UTC, comment #7:

I think I patched revision 25054 of _ode15_.cc.

I can see that these patch files are rather problematic with
respect to the version of the file they are created for.
So, as you suggested, I just uploaded the full, modified _ode15_.cc. This version has been built and tested with octave 4.4.0.

(file #44110)

Bill Greene <billgreene>
Mon 07 May 2018 11:07:01 AM UTC, comment #6:

Bill, Thanks for your patch and sorry for the late reply.

The patch does seem to have been greated correctly
but it does not apply to the current development branch,
what exact version of Octave did you start with for creating the patch?

If you don't feel like going through the trouble of creating
a well formed mercurial changeset you can just download the latest version of ode15.cc from the hgweb interface using the following link:


and upload the full modified file.


Carlo de Falco <cdf>
Project Member
Mon 16 Apr 2018 12:13:35 PM UTC, comment #5:

I attached a patch file to this bug report to update _ode15_.cc to build with sundials 3.1.

Bill Greene <billgreene>
Tue 03 Apr 2018 12:59:03 AM UTC, comment #4:

I added more tests to configure on the stable branch as a stopgap for this bug for the Octave 4.4 release


This will automatically disable building against SUNDIALS 3.0.0 and later. Octave 4.4 will build against version 2.7.0 only. This is no longer a build failure error, so recategorizing and retitling.

Please do comment if there are still build errors that the new configure changes don't take care of automatically.

Leaving this bug open until after the release when someone has time to fix it on the development branch by rewriting the interface to the new IDA API.

Mike Miller <mtmiller>
Project Administrator
Fri 30 Mar 2018 07:05:15 PM UTC, comment #3:

I've built a copy of sundials 3.1.0 and I confirm the error and that the API has changed significantly.

I think we're probably short on time to get a true fix in for 4.4, so it might make sense to add tests to configure for the ida_dense API and conditionally compile out those parts of the code. I can take a look at doing that in the short term.

Mike Miller <mtmiller>
Project Administrator
Fri 30 Mar 2018 06:11:17 AM UTC, comment #2:

FYI -- Fedora 28 (beta is out, final is expected to be released on May 1) comes with sundials 3.1.0


Dmitri A. Sergatskov <dasergatskov>
Wed 21 Mar 2018 11:23:11 PM UTC, comment #1:

It would be really nice if someone familiar with the SUNDIALS interface could take a look at this for Octave 4.4, since distributions will probably start moving to SUNDIALS 3 very soon.

Mike Miller <mtmiller>
Project Administrator
Tue 21 Nov 2017 09:48:12 PM UTC, original submission:

As initially reported in [1]: Sundials has changed the treatment of dense matrices [1], such that "ida_dense.h" which is included by "__ode15__.cc" is gone.

From the manual:

> Added generic SUNMATRIX module with three provided implementations:
> dense, banded and sparse.
> These replicate previous SUNDIALS Dls and Sls matrix structures in a
> single object-oriented API.

[1] http://octave.1599824.n4.nabble.com/Sundials-issues-with-ode15-tt4685656.html
[2] https://computation.llnl.gov/sites/default/files/public/idas_guide.pdf

Sebastian <sschoeps>


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

Attach Files:

Attached Files
file #46516:  open_pTl0p6ie.txt added by cdf (4KiB - text/plain - remove use of deprecated functions)
file #46271:  ode15_sundials_410_patch_0.txt added by cdf (8KiB - text/plain - revised patch working with sundials 4.1.0)
file #46272:  ode15_sundials_410_patch_1.txt added by cdf (11KiB - text/plain - revised patch working with sundials 4.1.0)
file #46273:  ode15_sundials_410_patch_2.txt added by cdf (1KiB - text/plain - revised patch working with sundials 4.1.0)
file #45334:  octave-sundials3.patch added by opoplawski (19KiB - text/x-patch - octave-sundials3.patch)
file #44130:  fc28_config.log added by dasergatskov (2MiB - text/x-log)
file #44131:  fc28_config.h added by dasergatskov (114KiB - text/x-chdr)
file #44110:  __ode15__.cc added by billgreene (33KiB - text/plain - modified file to support sundials 3.1)
file #43949:  __ode15__.cc.patch added by None (11KiB - application/octet-stream - Patch file for _ode15_.cc with the required, minimal changes to build with sundials 3.)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by arojas (Posted a comment)
  • -email is unavailable- added by doronbehar
  • -email is unavailable- added by godfrey (Posted a comment)
  • -email is unavailable- added by apjanke (Posted a comment)
  • -email is unavailable- added by andrecbarros (Posted a comment)
  • -email is unavailable- added by opoplawski (Posted a comment)
  • -email is unavailable- added by cdf (Posted a comment)
  • -email is unavailable- added by billgreene (Posted a comment)
  • -email is unavailable- added by dasergatskov (Posted a comment)
  • -email is unavailable- added by siko1056 (Updated the item)
  • -email is unavailable- added by sschoeps (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 25 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-03-13 jwe StatusReady For Test => Fixed
        Open/ClosedOpen => Closed
    2019-03-13 jwe StatusIn Progress => Ready For Test
    2019-03-13 cdf Attached File- => Added open_pTl0p6ie.txt, #46516
    2019-02-15 cdf Attached File- => Added ode15_sundials_410_patch_0.txt, #46271
        Attached File- => Added ode15_sundials_410_patch_1.txt, #46272
        Attached File- => Added ode15_sundials_410_patch_2.txt, #46273
    2019-02-15 cdf Attached File#44112 => Removed
    2019-02-15 cdf Attached File#44113 => Removed
    2019-02-15 cdf Attached File#44125 => Removed
    2019-02-15 cdf Attached File#44127 => Removed
    2019-02-15 cdf Attached File#45848 => Removed
    2019-01-02 cdf Attached File- => Added open_Xku0qo65.txt, #45848
    2018-11-30 doronbehar Carbon-Copy- => Added -email is unavailable-
    2018-11-04 mtmiller Carbon-CopyRemoved 80942 => -
    2018-10-31 opoplawski Attached File- => Added octave-sundials3.patch, #45334
    2018-05-09 dasergatskov Attached File- => Added fc28_config.log, #44130
        Attached File- => Added fc28_config.h, #44131
    2018-05-08 cdf Attached File- => Added open_bXICA7Gt.txt, #44127
    2018-05-08 cdf Attached File- => Added open_TK6CSjvd.txt, #44125
    2018-05-07 cdf Attached File- => Added open_K7lryXre.txt, #44113
    2018-05-07 cdf Attached File- => Added open_tkJXJDPU.txt, #44112
        Priority1 - Later => 5 - Normal
        StatusPostponed => In Progress
    2018-05-07 billgreene Attached File- => Added _ode15_.cc, #44110

    Back to the top

    Powered by Savane 3.4