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

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

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

CS17B031 VORA BRIJESH HARSHADBHAI
Respected sir,
My Name is Brijesh Vora. I am studying in IIT Tirupati in 2nd year CS.
I have prepared my GSoC proposal and it will be very useful to me if you reviewed it.
 
I am very much excited about ode15 solvers and implementing them. I would like to extend the work done by Francesco Faccio.
please let me know if it needs to be edited or if some part is missing.

Thanking you,
Brijesh Vora

Project proposal(2).pdf (141K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Carlo de Falco-2


> Il giorno 06 apr 2019, alle ore 01:27, CS17B031 VORA BRIJESH HARSHADBHAI <[hidden email]> ha scritto:
>
> Respected sir,
> My Name is Brijesh Vora. I am studying in IIT Tirupati in 2nd year CS.
> I have prepared my GSoC proposal and it will be very useful to me if you reviewed it.

> I am very much excited about ode15 solvers and implementing them. I would like to extend the work done by Francesco Faccio.
> please let me know if it needs to be edited or if some part is missing.
>
> Thanking you,
> Brijesh Vora


Dear Brijesh Vora,

The project proposal for this project is striked through on the wiki page because the project has already been done:
http://gsoc2016ode15s.blogspot.com/

c.

>


Project proposal(2).pdf (141K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Bill Greene-3
>  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.

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. Supporting the JPattern option is quite 
important for using these solvers as part of a MOL PDE solver.

On Mon, Apr 8, 2019 at 7:14 AM Carlo De Falco <[hidden email]> wrote:


> Il giorno 06 apr 2019, alle ore 01:27, CS17B031 VORA BRIJESH HARSHADBHAI <[hidden email]> ha scritto:
>
> Respected sir,
> My Name is Brijesh Vora. I am studying in IIT Tirupati in 2nd year CS.
> I have prepared my GSoC proposal and it will be very useful to me if you reviewed it.

> I am very much excited about ode15 solvers and implementing them. I would like to extend the work done by Francesco Faccio.
> please let me know if it needs to be edited or if some part is missing.
>
> Thanking you,
> Brijesh Vora


Dear Brijesh Vora,

The project proposal for this project is striked through on the wiki page because the project has already been done:
http://gsoc2016ode15s.blogspot.com/

c.

>

Reply | Threaded
Open this post in threaded view
|

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

nrjank
In reply to this post by Carlo de Falco-2

The project proposal for this project is striked through on the wiki page because the project has already been done:
http://gsoc2016ode15s.blogspot.com/


where do you see it striked through?  On the wiki I'm looking at it has it listed as the first project idea and comments that there are improvements to be made beyond the 2016 work:
Reply | Threaded
Open this post in threaded view
|

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

Carlo de Falco-2


> Il giorno 09 apr 2019, alle ore 05:11, Nicholas Jankowski <[hidden email]> ha scritto:
>
> The project proposal for this project is striked through on the wiki page because the project has already been done:
> http://gsoc2016ode15s.blogspot.com/
>
>
> where do you see it striked through?  On the wiki I'm looking at it has it listed as the first project idea and comments that there are improvements to be made beyond the 2016 work:
> https://wiki.octave.org/Summer_of_Code_Project_Ideas#ode15.7Bi.2Cs.7D_:_Matlab_Compatible_DAE_solvers

I was actually looking here :
https://wiki.octave.org/Projects
not at the SoC project ideas page.

you are right that the project is not striked through there.

c.


Reply | Threaded
Open this post in threaded view
|

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

Carlo de Falco-2
In reply to this post by Bill Greene-3
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 <[hidden email]> 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 | Threaded
Open this post in threaded view
|

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

nrjank
On Tue, Apr 9, 2019, 1:53 AM Carlo De Falco <[hidden email]> wrote:

You are right, there is lots of possible improvements still lacking, and some of them are indeed mentioned in the application.


Has the current state of MATLAB compatibility since the 2016 work been summarized anywhere? 
Reply | Threaded
Open this post in threaded view
|

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

CS17B031 VORA BRIJESH HARSHADBHAI
I will solve the above patch as soon as possible.
As the GSoC proposal submission timeline is over, I won't be able to include the patch in my proposal as I started late. But please consider it for my proposal.
Thank you,

On Tue, Apr 9, 2019 at 3:47 PM Nicholas Jankowski <[hidden email]> wrote:
On Tue, Apr 9, 2019, 1:53 AM Carlo De Falco <[hidden email]> wrote:

You are right, there is lots of possible improvements still lacking, and some of them are indeed mentioned in the application.


Has the current state of MATLAB compatibility since the 2016 work been summarized anywhere? 
Reply | Threaded
Open this post in threaded view
|

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

Bill Greene-3
In reply to this post by Carlo de Falco-2
> 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.

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

On Tue, Apr 9, 2019 at 1:53 AM Carlo De Falco <[hidden email]> 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 <[hidden email]> 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 | Threaded
Open this post in threaded view
|

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

Carlo de Falco-2


Il mar 9 apr 2019, 17:00 Bill Greene <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 | Threaded
Open this post in threaded view
|

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 <[hidden email]> wrote:


Il mar 9 apr 2019, 17:00 Bill Greene <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 | Threaded
Open this post in threaded view
|

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

Carlo de Falco-2
So you would suggest  reimplementing and maintaining the whole sundials library in m-files? Seriously?
c.

Il mar 9 apr 2019, 19:15 CS17B031 VORA BRIJESH HARSHADBHAI <[hidden email]> ha scritto:
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 <[hidden email]> wrote:


Il mar 9 apr 2019, 17:00 Bill Greene <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 | Threaded
Open this post in threaded view
|

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

CS17B031 VORA BRIJESH HARSHADBHAI
I am sorry,
I now realized how stupid that idea was. So, do you have any other idea about how I should approach this problem? I would want to implement at least complex-valued system and J pattern in this project.

On Tue, Apr 9, 2019 at 10:50 PM Carlo de Falco <[hidden email]> wrote:
So you would suggest  reimplementing and maintaining the whole sundials library in m-files? Seriously?
c.

Il mar 9 apr 2019, 19:15 CS17B031 VORA BRIJESH HARSHADBHAI <[hidden email]> ha scritto:
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 <[hidden email]> wrote:


Il mar 9 apr 2019, 17:00 Bill Greene <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 | Threaded
Open this post in threaded view
|

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

Nir Krakauer-3

It could be worth looking at Julia's interface to Sundials [1]; the implication I get from [2] is that it can handle complex-valued functions.

> I will solve the above patch as soon as possible.

Please do. It will be beneficial for your GSoC application.

--Nir