Re: GSoC 2016 project idea - implementation of ode15s

[Carlo De Falco]

On 7 Mar 2016, at 16:44, Richard Crozier <address@hidden> 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.