Make Sundials.jl API compatible with ODE.jl

[ivarne]

This package has seen little updates since it was first created, long long ago, before keyword arguments was part of Julia.

The recent API discussions in ODE.jl, has resulted in an API draft, that should (probably) be followed in Sundials.jl aswell. The first PR in this direction has already been merged.

[tshort]

+1.

Sundials.jl may also be a good place to try out the iteration API being
considered over at ODE.jl. The low-level Sundials routines are a good match
for this.

On Fri, Mar 14, 2014 at 4:48 AM, Ivar Nesje notifications@github.comwrote:

This package has seen little updates since it was first created, long long
ago, before keyword arguments was part of Julia.

The recent API discussions in ODE.jl https://github.com/JuliaLang/ODE.jl,
has resulted in an API drafthttps://github.com/JuliaLang/ODE.jl/blob/master/doc/api.md,
that should (probably) be followed in Sundials.jl aswell. The first PR in
this direction has already been mergedhttps://github.com//pull/8
.

Reply to this email directly or view it on GitHubhttps://github.com//issues/10
.

[crbinz]

Is this still desirable? My guess is yes. What about the output format, specifically making yout a vector of vectors of type y0? That's a little contentious (see here), and I suspect changing Sundials output will be equally contentious, if not moreso. What are everyone's thoughts?

[acroy]

I think in an ideal world one should be able to switch between solvers from ODE.jl and the basic solvers provided by Sundials.jl without too much hassle. This implies that the output format should be the same, but as you observed there is still some debate about the best format.

The situation should become better if we switch to an iterator-like interface in ODE.jl (SciML/ODE.jl#49). This should be easy to do for Sundials.jl as well. Collecting and storing the solutions in some container (Vector{Vector{Float64}}, Matrix{Float64}, custom type or whatever) could then be done independently and coherently for all solvers using the iterator interface.

[ChrisRackauckas]

This has been achieved with the common interface in common.jl. You can read the whole thing if you want here:

SciML/Roadmap#5 (comment)

A PR just merged which implements the common interface code (which used to be in DifferentialEquations.jl, then in OrdinaryDiffEq.jl, but now in Sundials.jl) for a type-based interface:

solve(prob,alg;kwargs...)

where if alg is one of the Sundials algorithms, CVODE_BDF and CVODE_Adams it will automatically be using Sundials. The other packages that use this same interface are OrdinaryDiffEq.jl (used to be in DifferentialEquations.jl) and ODEInterface.jl (through OrdinaryDiffEq.jl). ODE.jl / ODEPR49 will join the group soon (the code already exists in OrdinaryDiffEq.jl, but it's for JuliaODE/ODE.jl, which will move and stuff soon).

With these changes DifferentialEquations.jl has become a metapackage for the common interface, with Sundials.jl being one of the constituent packages (along with OrdinaryDiffEq.jl and ODE.jl). DifferentialEquations.jl's docs have become the docs for the common interface, and you can see here the algorithms which are currently included:

https://juliadiffeq.github.io/DiffEqDocs.jl/latest/solvers/ode_solve.html

Sundials is not compatible with the full common interface yet (this is the specification of the full interface:

https://juliadiffeq.github.io/DiffEqDocs.jl/latest/basics/common_solver_opts.html

) but hopefully it will be soon.

For an example for using the common interface, see the tutorials: https://juliadiffeq.github.io/DiffEqDocs.jl/latest/tutorials/ode_example.html

[ChrisRackauckas]

Closing since now both CVode and IDA are on the common interface, matching OrdinaryDiffEq.jl, ODEInterface.jl, and ODE.jl