[SciPy-Dev] GSoC' 15 Ideas: define general integrators; parallelize integration; higher-order ODEs

[Max Mertens]

Hi Benny,

thanks for your reply. So I see that SciPy is a rather mature and stable
environment and should stay like that, and parallel solvers should only
be integrated if implemented as a wrapper to another solid library.

I like Maple's approach to provide nice visualization commands to easily
compare different integrators. Various of the 'classical' integrators
presented there (as well as e.g. SciPy's dopri5; but IIRC only explicit
ones) could be covered by a Butcher-tableau-based solver, which reduces
the amount of code. This solver in turn could be used to provide
Maple-like visualizations.
The method could be invoked like ode or odeint or integrated into those,
with a string option to specify the method to be used, or a
Butcher-tableau itself.
If speed and stability is an issue, I'm willing to write efficient C
code with a Python interface and analyze/profile that, and compare it to
the existing methods.

Regards,
Max


On 17.03.2015 12:09, Benny Malengier wrote:
> I mean it would be great if parallel backend is an option for the
> cases where a sparse parallel linear solver is possible.
>
>     ...
>
>
> No, what I mean is that if a parallel solver is offered, it must
> remain a simple API, and not a very detailed API geared towards a
> specific area (like molecular modelling). Scipy will not replace
> dedicated packages. The methods present should be great in general.
> I'm not a core scipy developer though, they might have other ideas on
> what is fitting.
>
> Also, for integrate, scipy mostly is a wrapper layer around academic,
> well tested, codes. I'm not sure own written solvers, or pure python
> solvers, would be accepted. So you would need to select an existing
> well tested parallel solver, and then wrap that.
>
> Personally I like the approach of maple with their student package:
> http://www.maplesoft.com/support/help/Maple/view.aspx?path=Student%2fNumericalAnalysis
> The basic integrators are present there. It paints a clear picture:
> look, you learn this stuff in numerical analysis, so here are the
> methods, but for really doing ode or dae, use dsolve numberic
> http://www.maplesoft.com/support/help/maple/view.aspx?path=dsolve%2fnumeric
> instead (though that has the classical option too with the common
> classical methods
> (http://www.maplesoft.com/support/help/maple/view.aspx?path=dsolve%2fclassical).
>
> Some sort of 'student/classical' version for integrate in scipy is
> something I always missed.
>  
>
>     ...
>
>
> I did not react to RK as I have no experience there. As I said, if
> there is a good paper that allows an implementation, then yes, it
> probably is an option.
> But mostly, a wrapper to an existing well tested codebase for RK seems
> the fastest and best approach for a student.
> Current dopri5 and dop853 in scipy seem a very specific choice for RK,
> but the fact they have step size control makes them in practise better
> than whatever standard RK you could devise based on textbooks. If the
> aim is just to have an implementation for classical methods, eg RK
> variants, available in scipy, then adding those via a clear
> student/classical package is something I would like, but perhaps not
> core scipy developers.
>
> Benny