GSoC 2016 project idea - implementation of ode15s

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

GSoC 2016 project idea - implementation of ode15s

Richard Crozier
Dear List,

I have an idea for a GSoC project idea which I think would be very
beneficial for Octave now that the ode* functions are in core. A major
omission currently is ode15s which is a stiff differential solver which
is very effective. The closest equivalent solver in odepkg is probably
ode5r and, at least for the problems I solve this is much slower because
the number of steps taken to solve the problem is far smaller with ode15s.

The documentation for ode15s can be found here:

http://uk.mathworks.com/help/matlab/ref/ode15s.html

Documentation on the implementation can be found in these references:

"The MATLAB ODE Suite", L. F. Shampine and M. W. Reichelt, SIAM Journal
on Scientific Computing, 18-1, 1997

"Solving Index-1 DAEs in MATLAB and Simulink", L. F. Shampine, M. W.
Reichelt, and J. A. Kierzenka, SIAM Review, 41-3, 1999.

I have access to these papers.

What I don't have is the skills or knowledge to mentor a project
implementing the function. I would have the time and ability to help
monitor progress and give general coding advice to the student.

Would anyone else be interested in mentoring this project?

Regards,

Richard



--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.


Reply | Threaded
Open this post in threaded view
|

Re: GSoC 2016 project idea - implementation of ode15s

Nir Krakauer-2
Hi Richard,

I would be willing to be a co-mentor of this if/when we have a suitable student. Can you please add the project description to ​http://wiki.octave.org/Summer_of_Code_Project_Ideas ?

Nir
Reply | Threaded
Open this post in threaded view
|

Re: GSoC 2016 project idea - implementation of ode15s

Sebastian Schöps
Nir Krakauer-2 wrote
Hi Richard,

I would be willing to be a co-mentor of this if/when we have a suitable
student. Can you please add the project description to ​
http://wiki.octave.org/Summer_of_Code_Project_Ideas ?

Nir
It's already there.
Reply | Threaded
Open this post in threaded view
|

Re: GSoC 2016 project idea - implementation of ode15s

Sebastian Schöps
In reply to this post by Richard Crozier
Richard Crozier wrote
The closest equivalent solver in odepkg is probably
ode5r and, at least for the problems I solve this is much slower because
the number of steps taken to solve the problem is far smaller with ode15s.
Is your right-hand-side smoot enough? If yes, both ode15s and ode5r should have similar performance, both are accurate up to 5th order. however single step methods tend to use more function evaluations. if this is the bottleneck, then you might go better with odebdi (nonetheless we should get an ode15s for octave...)

Seb.
Reply | Threaded
Open this post in threaded view
|

Re: GSoC 2016 project idea - implementation of ode15s

Richard Crozier
In reply to this post by Sebastian Schöps
On 05/03/16 19:38, Sebastian Schöps wrote:

> Nir Krakauer-2 wrote
>> Hi Richard,
>>
>> I would be willing to be a co-mentor of this if/when we have a suitable
>> student. Can you please add the project description to ​
>> http://wiki.octave.org/Summer_of_Code_Project_Ideas ?
>>
>> Nir
>
> It's already there.
>
>
>

Thanks for offering to mentor Nir, this would be great. I would do my
best to help with all the 'boring' stuff like mercurial and setting up
for octave development etc.

Sebastian, there is no specific project to implement ode15s, it's
mentioned in the Matlab Compatible DAE, but I don't think ode15s is a
DAE solver? Perhaps you are thinking of ode15i? ode15s is a stiff ode
solver.

I'll add this to the project list.

Richard




--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.


Reply | Threaded
Open this post in threaded view
|

Re: GSoC 2016 project idea - implementation of ode15s

Richard Crozier
In reply to this post by Sebastian Schöps
On 05/03/16 19:52, Sebastian Schöps wrote:

> Richard Crozier wrote
>> The closest equivalent solver in odepkg is probably
>> ode5r and, at least for the problems I solve this is much slower because
>> the number of steps taken to solve the problem is far smaller with ode15s.
>
> Is your right-hand-side smoot enough? If yes, both ode15s and ode5r should
> have similar performance, both are accurate up to 5th order. however single
> step methods tend to use more function evaluations. if this is the
> bottleneck, then you might go better with odebdi (nonetheless we should get
> an ode15s for octave...)
>
> Seb.
>
>

Well, my process for choosing ode15s was this: try ode45, was really
slow, try ode15s, worked well. This should give you an idea of my
knowledge of the underlying numerical workings of the solvers. However,
this is also pretty much how ML recommend you choose one. My process for
choosing ode5r was pretty similar, although I think this might be the
only stiff solver, or possibly was when I first chose it. It gave best
performance of the odepkg solvers.

I'm solving a transient simulation of a three-phase generator attached
to a resistive load, so an inductive circuit with inductive coupling
between circuits.

As far as I can tell odebdi is an implicit solver for which you need the
initial derivatives, I don't know these.

Thanks for the help and pointing me to possibly new solvers.

I also think in general having an ode15s for octave is desirable anyway.

Richard



--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.


Reply | Threaded
Open this post in threaded view
|

Re: GSoC 2016 project idea - implementation of ode15s

Sebastian Schöps
In reply to this post by Richard Crozier

> Am 06.03.2016 um 12:17 schrieb Richard Crozier <[hidden email]>:
>
> On 05/03/16 19:38, Sebastian Schöps wrote:
>> Nir Krakauer-2 wrote
>>> Hi Richard,
>>>
>>> I would be willing to be a co-mentor of this if/when we have a suitable
>>> student. Can you please add the project description to ​
>>> http://wiki.octave.org/Summer_of_Code_Project_Ideas ?
>>>
>>> Nir
>>
>> It's already there.
>
> Thanks for offering to mentor Nir, this would be great. I would do my best to help with all the 'boring' stuff like mercurial and setting up for octave development etc.
>
> Sebastian, there is no specific project to implement ode15s, it's mentioned in the Matlab Compatible DAE, but I don't think ode15s is a DAE solver?

from the wiki: "The goal is to implement a Matlab compatible adaptive BDF solver for Differential Algebraic Equations (DAEs). The interface would need to be compatible with ode15s while for the backend the SUNDIALS library would be used, which has both a C and a MEX interface. This function should eventually be included in Octave core together with the other ODE solvers that will be released with version 4.2, but could be intially developed as an addition to the odepkg package."

> Perhaps you are thinking of ode15i? ode15s is a stiff ode solver.

Both ("s" and "i") use the same BDF method and can be used for DAEs and (stiff) ODEs. However "i" is more tailored for implicit DAEs, i.e., f(x',x,t)=0 instead of M*x'=f(x,t).

Seb.
Reply | Threaded
Open this post in threaded view
|

Re: GSoC 2016 project idea - implementation of ode15s

Richard Crozier


On 06/03/16 15:25, Sebastian wrote:

>
>> Am 06.03.2016 um 12:17 schrieb Richard Crozier <[hidden email]>:
>>
>> On 05/03/16 19:38, Sebastian Schöps wrote:
>>> Nir Krakauer-2 wrote
>>>> Hi Richard,
>>>>
>>>> I would be willing to be a co-mentor of this if/when we have a suitable
>>>> student. Can you please add the project description to ​
>>>> http://wiki.octave.org/Summer_of_Code_Project_Ideas ?
>>>>
>>>> Nir
>>>
>>> It's already there.
>>
>> Thanks for offering to mentor Nir, this would be great. I would do my best to help with all the 'boring' stuff like mercurial and setting up for octave development etc.
>>
>> Sebastian, there is no specific project to implement ode15s, it's mentioned in the Matlab Compatible DAE, but I don't think ode15s is a DAE solver?
>
> from the wiki: "The goal is to implement a Matlab compatible adaptive BDF solver for Differential Algebraic Equations (DAEs). The interface would need to be compatible with ode15s while for the backend the SUNDIALS library would be used, which has both a C and a MEX interface. This function should eventually be included in Octave core together with the other ODE solvers that will be released with version 4.2, but could be intially developed as an addition to the odepkg package."
>
>> Perhaps you are thinking of ode15i? ode15s is a stiff ode solver.
>
> Both ("s" and "i") use the same BDF method and can be used for DAEs and (stiff) ODEs. However "i" is more tailored for implicit DAEs, i.e., f(x',x,t)=0 instead of M*x'=f(x,t).
>
> Seb.
>

Thanks, it wasn't clear to me that this project aims to result in an
implementation of ode15s, even though it's mentioned in the description.
Mainly because I didn't think of it as a DAE solver (I've outlined my
level of knowledge of the solvers already though).

I do wonder if fully implementing, and thoroughly testing a good, ML
compatible version of ode15s isn't a fairly substantial project on it's
own, but you'll have a much better idea of the work involved in this.

Richard

--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.


Reply | Threaded
Open this post in threaded view
|

Re: GSoC 2016 project idea - implementation of ode15s

Carlo de Falco-2
In reply to this post by Richard Crozier

On 6 Mar 2016, at 12:17, Richard Crozier <[hidden email]> wrote:

> Sebastian, there is no specific project to implement ode15s, it's mentioned in the Matlab Compatible DAE, but I don't think ode15s is a DAE solver?

I wrote that project description.

The Matlab solver of choice for DAEs is ode15s
The task for that project is to implement ode15s.
If you think the project description is not clear enough
about this, feel free to suggest changes to that description.

Do not propose a different project as that would be just a duplicate.

c.



Reply | Threaded
Open this post in threaded view
|

Re: GSoC 2016 project idea - implementation of ode15s

Carlo de Falco-2
In reply to this post by Richard Crozier
Hi,

On 7 Mar 2016, at 09:45, Richard Crozier <[hidden email]> wrote:

> I do wonder if fully implementing, and thoroughly testing a good, ML compatible version of ode15s isn't a fairly substantial project on it's own, but you'll have a much better idea of the work involved in this.

Sorry, I got confused by too many negations ;)

Do you believe the proposed project is too hard or that it is not enough?

c.



Reply | Threaded
Open this post in threaded view
|

Re: GSoC 2016 project idea - implementation of ode15s

Nir Krakauer-2
In reply to this post by Richard Crozier
Carlo, for the proposed project, are you thinking to use daspk as already available in Octave, or use other solvers from Sundials? Nir
Reply | Threaded
Open this post in threaded view
|

Re: GSoC 2016 project idea - implementation of ode15s

Richard Crozier
In reply to this post by Carlo de Falco-2
On 07/03/16 14:25, Carlo De Falco wrote:

> Hi,
>
> On 7 Mar 2016, at 09:45, Richard Crozier <[hidden email]> wrote:
>
>> I do wonder if fully implementing, and thoroughly testing a good, ML compatible version of ode15s isn't a fairly substantial project on it's own, but you'll have a much better idea of the work involved in this.
>
> Sorry, I got confused by too many negations ;)
>
> Do you believe the proposed project is too hard or that it is not enough?
>
> c.
>
>
>

Well I was thinking it is quite hard, but that might be more of
reflection of myself than the project.

It seems quite hard to do a lot more than get a really good and well
tested implementation of ode15s, with all the features such as event
detection and documentation. However, maybe a lot of the code exists
already, I don't know the detail of the ode solver implementations and
how much can be reused.

In the project description it doesn't leap out to me that the main aim
is to create a new function ode15s for core.

The existing solvers are m-file based and self contained (I think),
would jwe be ok with adding a dependency like SUNDIALS to core?

Obviously I'd rather have one in odepkg than not at all.

Richard



--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.


Reply | Threaded
Open this post in threaded view
|

Re: GSoC 2016 project idea - implementation of ode15s

Parsiad Azimzadeh
In reply to this post by Richard Crozier
> I do wonder if fully implementing, and thoroughly testing a good, ML compatible version of ode15s isn't a fairly substantial project on it's own, but you'll have a much better idea of the work involved in this.

For reference, this is the paper describing the ODE suite, and it has some details about ode15s:


The link above might not be accessible to some; there is also the preprint version on the mathworks website:

https://www.mathworks.com/help/pdf_doc/otherdocs/ode_suite.pdf
--
Parsiad Azimzadeh [http://parsiad.ca]
PhD candidate

DC 3594 - University of Waterloo,
200 University Avenue West,
Waterloo, ON N2L 3G1
Reply | Threaded
Open this post in threaded view
|

Re: GSoC 2016 project idea - implementation of ode15s

Carlo de Falco-2
In reply to this post by Richard Crozier

On 7 Mar 2016, at 16:44, Richard Crozier <[hidden email]> wrote:
> Well I was thinking it is quite hard, but that might be more of reflection of myself than the project.

yes, you are right it is a non trivial project, but you should consider that the
library we proposed to use as a backend already implements exactly the same algorithm as
ode15s.

> It seems quite hard to do a lot more than get a really good and well tested implementation of ode15s, with all the features such as event detection and documentation. However, maybe a lot of the code exists already, I don't know the detail of the ode solver implementations and how much can be reused.

sundials has all that and even more, there is no need to reuse code just write a good interface.
that said, I admit it is definitely not a trivial task to add yet another external dependency
library to core...

there will be a lot of difficulties with stuff such as writing DLD_FUNs, using mercurial, making
autotools tests, etc.

would you like / have time to contribute to mentoring this part of the work, if we find a good student?

> In the project description it doesn't leap out to me that the main aim is to create a new function ode15s for core.

I changed the project description title to make that immediately visible, is that better?

> The existing solvers are m-file based and self contained (I think), would jwe be ok with adding a dependency like SUNDIALS to core?

well, let's ask jwe himself ;)

actually we did discuss this during OctConf and he was quite open to this,
but if there is any objection to linking sundials, we can use DASPK which
also uses the exact same algorithm and is already included in core.

There is even a preliminary wrapper for daspk to behave like ode15s in the patch
tracker that was started be jwe.

> Obviously I'd rather have one in odepkg than not at all.

I used to think that starting development in a forge package and then moving code
to core was a way to smooth out the initial learning curve, but recently the entry
barrier for Octave Forge has become more and more steep, so I'm not sure this is a
good idea anymore ...

> Richard

c.
Reply | Threaded
Open this post in threaded view
|

Re: GSoC 2016 project idea - implementation of ode15s

Carlo de Falco-2

On 7 Mar 2016, at 18:33, Carlo de Falco <[hidden email]> wrote:

> There is even a preliminary wrapper for daspk to behave like ode15s in the patch
> tracker that was started be jwe.

here it is:
https://savannah.gnu.org/patch/?8102

BTW, I am not sure I still agree with some of my own comments on that thread anymore, e.g., I'm not sure using the mex interface is a good idea ...

c.


Reply | Threaded
Open this post in threaded view
|

Re: GSoC 2016 project idea - implementation of ode15s

Richard Crozier
In reply to this post by Carlo de Falco-2
On 07/03/16 17:33, Carlo De Falco wrote:

>
> On 7 Mar 2016, at 16:44, Richard Crozier <[hidden email]> wrote:
>> Well I was thinking it is quite hard, but that might be more of reflection of myself than the project.
>
> yes, you are right it is a non trivial project, but you should consider that the
> library we proposed to use as a backend already implements exactly the same algorithm as
> ode15s.
>
>> It seems quite hard to do a lot more than get a really good and well tested implementation of ode15s, with all the features such as event detection and documentation. However, maybe a lot of the code exists already, I don't know the detail of the ode solver implementations and how much can be reused.
>
> sundials has all that and even more, there is no need to reuse code just write a good interface.
> that said, I admit it is definitely not a trivial task to add yet another external dependency
> library to core...
>
> there will be a lot of difficulties with stuff such as writing DLD_FUNs, using mercurial, making
> autotools tests, etc.
>
> would you like / have time to contribute to mentoring this part of the work, if we find a good student?
>

Yes I'm willing to help with the 'boilerplate' work, I am familiar with
autotools, mercurial, building Octave and have had a few patches
accepted to Octave core. I'm very motivated to get ode15s implemented in
Octave.

I'll be much more useful in fact if most of the actual numerical
implementation already exists and the project is mostly just making this
accessible in Octave. Sounds like you know jwe would be fine with the
dependencies. One thing I haven't done in the past is DLD_FUNs, since I
usually go with mex for Matlab compatibility, but happy to learn about
this too.

Richard

--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.


Reply | Threaded
Open this post in threaded view
|

Re: GSoC 2016 project idea - implementation of ode15s

Carlo de Falco-2

On 8 Mar 2016, at 09:46, Richard Crozier <[hidden email]> wrote:

> On 07/03/16 17:33, Carlo De Falco wrote:
>>
>> On 7 Mar 2016, at 16:44, Richard Crozier <[hidden email]> wrote:
>>> Well I was thinking it is quite hard, but that might be more of reflection of myself than the project.
>>
>> yes, you are right it is a non trivial project, but you should consider that the
>> library we proposed to use as a backend already implements exactly the same algorithm as
>> ode15s.
>>
>>> It seems quite hard to do a lot more than get a really good and well tested implementation of ode15s, with all the features such as event detection and documentation. However, maybe a lot of the code exists already, I don't know the detail of the ode solver implementations and how much can be reused.
>>
>> sundials has all that and even more, there is no need to reuse code just write a good interface.
>> that said, I admit it is definitely not a trivial task to add yet another external dependency
>> library to core...
>>
>> there will be a lot of difficulties with stuff such as writing DLD_FUNs, using mercurial, making
>> autotools tests, etc.
>>
>> would you like / have time to contribute to mentoring this part of the work, if we find a good student?
>>
>
> Yes I'm willing to help with the 'boilerplate' work, I am familiar with autotools, mercurial, building Octave and have had a few patches accepted to Octave core. I'm very motivated to get ode15s implemented in Octave.
>
> I'll be much more useful in fact if most of the actual numerical implementation already exists and the project is mostly just making this accessible in Octave. Sounds like you know jwe would be fine with the dependencies. One thing I haven't done in the past is DLD_FUNs, since I usually go with mex for Matlab compatibility, but happy to learn about this too.
>
> Richard


Great! Your help will be extremely welcome.
I'll add you as one of the mentors on the wiki page and send you an invitation from the google system.
Thanks,
c.







Reply | Threaded
Open this post in threaded view
|

Re: GSoC 2016 project idea - implementation of ode15s

Carlo de Falco-2

On 8 Mar 2016, at 11:47, Carlo De Falco <[hidden email]> wrote:

>
> On 8 Mar 2016, at 09:46, Richard Crozier <[hidden email]> wrote:
>
>> On 07/03/16 17:33, Carlo De Falco wrote:
>>>
>>> On 7 Mar 2016, at 16:44, Richard Crozier <[hidden email]> wrote:
>>>> Well I was thinking it is quite hard, but that might be more of reflection of myself than the project.
>>>
>>> yes, you are right it is a non trivial project, but you should consider that the
>>> library we proposed to use as a backend already implements exactly the same algorithm as
>>> ode15s.
>>>
>>>> It seems quite hard to do a lot more than get a really good and well tested implementation of ode15s, with all the features such as event detection and documentation. However, maybe a lot of the code exists already, I don't know the detail of the ode solver implementations and how much can be reused.
>>>
>>> sundials has all that and even more, there is no need to reuse code just write a good interface.
>>> that said, I admit it is definitely not a trivial task to add yet another external dependency
>>> library to core...
>>>
>>> there will be a lot of difficulties with stuff such as writing DLD_FUNs, using mercurial, making
>>> autotools tests, etc.
>>>
>>> would you like / have time to contribute to mentoring this part of the work, if we find a good student?
>>>
>>
>> Yes I'm willing to help with the 'boilerplate' work, I am familiar with autotools, mercurial, building Octave and have had a few patches accepted to Octave core. I'm very motivated to get ode15s implemented in Octave.
>>
>> I'll be much more useful in fact if most of the actual numerical implementation already exists and the project is mostly just making this accessible in Octave. Sounds like you know jwe would be fine with the dependencies. One thing I haven't done in the past is DLD_FUNs, since I usually go with mex for Matlab compatibility, but happy to learn about this too.
>>
>> Richard
>
>
> Great! Your help will be extremely welcome.
> I'll add you as one of the mentors on the wiki page and send you an invitation from the google system.
> Thanks,
> c.


Hi,

Can you please try to fill in the ranking of project proposals
in the sheet prepared by Nir here:

https://docs.google.com/spreadsheets/d/1Nf7yHO7-S-BJlr9ntqkZUQVIas4_WZC954RRT8yqAH0/edit?usp=sharing

the selection must be fnalized by 1PM UTC today, we we have 7 viable proposals
and 5 slots (+ probably one more in SoCiS).

c.