Re: Application for GSoC 2019 in ODE 15{i, s} : Matlab Compatible DAE solvers

[CS17B031 VORA BRIJESH HARSHADBHAI]

I would try to solve the complex-valued system with sundials.

They have already written in C. We can reproduce the sundial's code in the octave's scripting language whatever algorithm they have used, we can use it, with some slight changes or, we can integrate the whole sundials into octave to call sundials whenever cvode is found.

But writing our own code would be better as we can add other functions and features latter point of time.

On Tue, Apr 9, 2019 at 9:30 PM Carlo de Falco <address@hidden> wrote:

Il mar 9 apr 2019, 17:00 Bill Greene <address@hidden> ha scritto:

> Would you like to be included as possible mentor on GSOC?

Unfortunately, my knowledge of Octave development is not good enough

to be a very effective mentor. I would  be happy to review proposals and

code though.

Actually that's exactly the job of a mentor 😉

There should never be only one mentor on each project so if you could cover the sundials part that would be already useful.

It will be interesting to hear if Brijesh has some ideas about complex

support.

Supporting JPattern and Vectorized would be useful and relatively

straightforward.

I did a little experimentation with consistent initial conditions (CIC) a year or so

ago. The current Octave implementation is certainly different from

Shampine's algorithm. But it may be more robust. Unfortunately it is

very slow for large number of unknowns. Nevertheless, I believe it

would be useful to have it as an option. Sundials has two options

for computing CIC and it would be useful to

support these as well.

I don't think the Events capability has had sufficient testing although this

is not mentioned specifically in Brijesh's proposal.

Bill

I agree that Jpattern and complex are the most useful features. 

I would not know how to deal with complex values other than split real and imaginary parts though ...

Have you ever solved a complex valued ode or dae with sundials?

Implementing CIC through sundials seems the best option to me, even though the algorithm would be different than Matlab.

c.

On Tue, Apr 9, 2019 at 1:53 AM Carlo De Falco <address@hidden> wrote:

You are right, I was quite quick in dismissing this application it does deserve some more in-depth consideration.

@Bill, as you are definitely the contributor to this list with the most knowledge of SUNDIALS,
you're definitely welcome to contribute to this evaluation and possibly mentoring projects on this topic.
Would you like to be included as possible mentor on GSOC?

> Il giorno 08 apr 2019, alle ore 23:47, Bill Greene <address@hidden> ha scritto:
>
> >  because the project has already been done:
>
> I'm not sure what you mean by that? I consider these functions in their current form to be a reasonable
> "first draft" of the necessary capability.

You are right, there is lots of possible improvements still lacking, and some of them are indeed mentioned in the application.
On the other hand the application says ode15s, unlike ode15i, is untested and allocates 2-3 weeks to writing tests for it while ode15s has about as many tests as ode15i:
http://hg.savannah.gnu.org/hgweb/octave/file/ca0230d3efbf/scripts/ode/ode15s.m#l380

I'm not saying here that ode15s is perfect and complete, but rather that there is not that much asymmetry wrt ode15i.

> I read Mr. Vora's proposal and thought he had some good ideas. Adding support for complex numbers
> would be a nice addition but is quite challenging in my opinion.

As sundials is written in C and not in C++ this seems quite hard to do.
The application states this feature would be nice to have but does not mention any idea about hout it could be done.

@Brijesh can you provide more details about how you would intend to proceed?

> Supporting the JPattern option is quite
> important for using these solvers as part of a MOL PDE solver.

Even before implementing JPattern it would be useful for this purpose to avoid allocating space for a full Jacobian when
a sparse Jacobian is provided, as noted in this FIXME comment :

http://hg.savannah.gnu.org/hgweb/octave/file/ca0230d3efbf/libinterp/dldfcn/__ode15__.cc#l394

@Brijesh could you try providing a patch to fix this issue?

Thanks,
c.