octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Carlo De Falco
Subject: Re: Application for GSoC 2019 in ODE 15{i, s} : Matlab Compatible DAE solvers
Date: Tue, 9 Apr 2019 05:53:03 +0000

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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]