sciml/differentialequations.jl

Multi-language suite for high-performance solvers of differential equations and scientific machine learning (SciML) components. Ordinary differential equations (ODEs), stochastic differential equations (SDEs), delay differential equations (DDEs), differential-algebraic equations (DAEs), and more in Julia.

differentialequations.jl's Issues

Type Instability in Solvers

Currently there are type instabilities which are causing performance issues. Before solving, the time, tableau, and initial condition types should match. Then these matching types should call the integrator and be type stable.

parameters in ODE

Hi,

The vector fields of the ODE cannot have any parameters. For example, it can be useful to modify certains parameters of the vector field, e.g. f(du,u,t,params)

Do you recommend using const variables for the parameters or is there another trick ?

Change output

Output will be changed from a matrix to a GrowableArray, a. la. timeseries[i] is the ith solution. It will be re-named as timeseries.

Nice picture for README

What would be a cool differential equation for the README? Maybe an animation?

Sensitivity Analysis and Bifurcation Plots

I would like to be able to perform a sensitivity analysis as well on a given ODEProblem. SciML/ODE.jl#22 would be interested and could be done using ForwardDiff. The ODEInterface sensitivity analysis should be parsed to be compatible.

Faster Calculations via in-place example

While running this example, the following error comes up:

LoadError: BoundsError
while loading In[3], in expression starting on line 2

in getindex at .\number.jl:21 [inlined]
in f₁(::Rational{Int64}, ::Array{Float64,1}) at .\In[1]:3
in f(::Rational{Int64}, ::Array{Float64,1}) at .\In[1]:6
in (::DifferentialEquations.##560#568{DifferentialEquations.ODEProblem{Array{Float64,1},Float64}})(::Rational{Int64}, ::Array{Float64,1}, ::Array{Float64,1}) at C:\Users\Denis.julia\v0.5\DifferentialEquations\src\ode\ode_solve.jl:79
in ode_solve(::DifferentialEquations.ODEIntegrator{:RK4,Array{Float64,1},Float64,2,Rational{Int64},Float64,Array{Float64,1},Array{Float64,1}}) at C:\Users\Denis.julia\v0.5\DifferentialEquations\src\ode\ode_integrators.jl:110
in #solve#559(::Array{Any,1}, ::Function, ::DifferentialEquations.ODEProblem{Array{Float64,1},Float64}, ::Array{Int64,1}) at C:\Users\Denis.julia\v0.5\DifferentialEquations\src\ode\ode_solve.jl:190
in (::DifferentialEquations.#kw##solve)(::Array{Any,1}, ::DifferentialEquations.#solve, ::DifferentialEquations.ODEProblem{Array{Float64,1},Float64}, ::Array{Int64,1}) at .:0

This BoundsError message appears in other examples: Solving the Giere-Meinhardt...

Thanks

NDF/BDF solvers for ODEs

DP8 dense output

These two methods have some oddities for high sigma in their dense output.

Edit

Now only DP8 has errors in the dense output

Example: Heat Equation System

At ln[3]

LoadError: UndefVarError: heatProblemExample_diffusionconstants not defined
while loading In[3], in expression starting on line 6

Add Interface for ODE.jl

Add an interface in the ODE solvers for ODE.jl

Integration with accelerator frameworks

I would like to try integrating DifferentialEquations with some of the accelerator frameworks. For example, these include things like ParallelAccelerator, Spraso, ArrayFire, CUDArt, etc.

I think the way to do these things would be write them as a separate package which:

• Imports DifferentialEquations
• Requires these extra components
• Implements a new :alg dispatch (this would be a good way to show how it's done anyways)
• Tests on its own (to not add test dependencies)
• Document as a conditional dependency

This way, these components would be entirely optional (to avoid extra build problems). The GPU ones would be necessary because, if the method was on the CPU, then items would need to be transferred back to the CPU each step. These would be employed only by the PDE methods because that's where this level of parallelization is needed (and maybe fully parallel RK methods for ODE like waveform relaxation when we get there). Xeon Phi support should be provided by ParallelAccelerator (waiting on Knights Landing to do more, but see IntelLabs/CompilerTools.jl#1)

Add get functions for DESolution

It will make sol act more like an array.

Semi-Implicit FEM Heat Solvers Diffusion Constants

Currently the FEM Semi-implicit methods for solving the heat equation cannot handle differing diffusion constants.

Add a benchmarking suite

Need a good way to benchmark between algorithms. Should be similar to the ConvergenceSimulation. Will calculate errors, elapsed time, computational efficiency, over a benchmark_axis (i.e. changing dts or dxs, or even tolerance, like in ConvergenceSimulation) and then make plots via plot recipes.

Dense Output

To get dense output, the follow steps need to be implemented:

• Propagate ks through. ks = Vector{Vector{uType}} which holds the k at each step. It should default to an empty vector.
• Store ks in the solution
• Make a basic dispatch for a dense(sol) function which will return an interpolating function which gives a Hermite interpolated dense output. Allow for choice of order, but default to the algorithm's order
• Add special dispatches for the special RKs
• Automatically make/store this function if dense=true in solver.
• Add callibility so that sol(t) is the interpolated solution at time t
• Implement a keyword saveat=tType[] which will use dense output to save a value at each time in the Vector (this is different than adding that time to tspan since that will force the solver to hit the point).

Add Feagin for ::Number

This is very simple to do. In fact, since the other isn't in place yet (#30) the current method should for for u::Number. Just needs to be copied and then tested.

Optimized RK methods

I'd like to add the following optimized RK methods:

• Order 2/3 Bogacki-Shampine (BS3)
• Tsitouras 4/5 (Tsit5) <- fsal
• Bogacki-Shampine 4/5 (BS5) <- fsal
• Verner "most efficient" 6 (Vern6) <- fsal
• Tanaka-Yamashita 7 (TanYam7)
• DP853 (DP8)
• Tsitouras-Papakostas 8 (TsitPap8)
• Verner most efficient 9 (Vern9)

One of these or DP5 will be the default.

Example: Solving Equations in with Julia-defined Types

For ArbFloats:

INFO: Precompiling module ArbFloats...
ERROR: LoadError: LoadError: BoundsError: attempt to access 3-element Array{String,1} at index [0]
in library_filepath(::String, ::Array{String,1}, ::String) at C:\Users\Denis.julia\v0.5\ArbFloats\src\support\NemoLibs.jl:15
in include_from_node1(::String) at .\loading.jl:426 (repeats 2 times)
in macro expansion; at .\none:2 [inlined]
in anonymous at .:?
in eval(::Module, ::Any) at .\boot.jl:234
in process_options(::Base.JLOptions) at .\client.jl:239
in _start() at .\client.jl:318
while loading C:\Users\Denis.julia\v0.5\ArbFloats\src\support/NemoLibs.jl, in expression starting on line 23
while loading C:\Users\Denis.julia\v0.5\ArbFloats\src\ArbFloats.jl, in expression starting on line 70
LoadError: Failed to precompile ArbFloats to C:\Users\Denis.julia\lib\v0.5\ArbFloats.ji
while loading In[11], in expression starting on line 1

in compilecache(::String) at .\loading.jl:505
in require(::Symbol) at .\loading.jl:364

For DecFP:

LoadError: LoadError: error compiling _parse: could not load library "C:\Users\Denis.julia\v0.5\DecFP\src..\deps\libbid64"
The specified module could not be found.

while loading C:\Users\Denis.julia\v0.5\DecFP\src\DecFP.jl, in expression starting on line 63
while loading In[13], in expression starting on line 1

in macro expansion; at C:\Users\Denis.julia\v0.5\DecFP\src\DecFP.jl:78 [inlined]
in anonymous at .:?
in include_from_node1(::String) at .\loading.jl:426
in eval(::Module, ::Any) at .\boot.jl:234
in require(::Symbol) at .\loading.jl:357

For Decimals:

LoadError: TypeError: ODEProblem: in uEltype, expected uEltype<:Number, got Type{Decimals.Decimal}
while loading In[15], in expression starting on line 2

in #ODEProblem#235(::Function, ::Type{T}, ::Function, ::Array{Decimals.Decimal,1}) at C:\Users\Denis.julia\v0.5\DifferentialEquations\src\general\problems.jl:408
in (::Core.#kw#Type)(::Array{Any,1}, ::Type{DifferentialEquations.ODEProblem}, ::Function, ::Array{Decimals.Decimal,1}) at .:0

For DoubleDouble:

LoadError: MethodError: Cannot convert an object of type Rational{Int64} to an object of type DoubleDouble.Double{Float64}
This may have arisen from a call to the constructor DoubleDouble.Double{Float64}(...),
since type constructors fall back to convert methods.
while loading In[16], in expression starting on line 3

in #solve#559(::Array{Any,1}, ::Function, ::DifferentialEquations.ODEProblem{DoubleDouble.Double{Float64},DoubleDouble.Double{Float64}}, ::Array{Int64,1}) at C:\Users\Denis.julia\v0.5\DifferentialEquations\src\ode\ode_solve.jl:173
in (::DifferentialEquations.#kw##solve)(::Array{Any,1}, ::DifferentialEquations.#solve, ::DifferentialEquations.ODEProblem{DoubleDouble.Double{Float64},DoubleDouble.Double{Float64}}, ::Array{Int64,1}) at .:0

issue with ODE backend

Hi

Trying https://github.com/ChrisRackauckas/DifferentialEquations.jl/blob/master/examples/Calling%20External%20Solvers%20-%20ODEjl%20and%20ODEInterface.ipynb to call ode45, I get the following error:

sol =solve(prob::ODEProblem,tspan,Δt=Δt,alg=:ode45) [DifferentialEquations.jl] Initializing backend: ODEJL ERROR: UndefVarError: ExplicitODE not defined in #solve#461(::Array{Any,1}, ::Function, ::DifferentialEquations.ODEProblem{Array{Float64,1},Float64}, ::Array{Int64,1}) at /Users/rveltz/.julia/v0.5/DifferentialEquations/src/ode/ode_solve.jl:195 in (::DifferentialEquations.#kw##solve)(::Array{Any,1}, ::DifferentialEquations.#solve, ::DifferentialEquations.ODEProblem{Array{Float64,1},Float64}, ::Array{Int64,1}) at ./<missing>:0

Do you have any idea what is wrong?

versioninfo() Julia Version 0.5.0-rc0+0 Commit 0030eec* (2016-07-26 20:22 UTC) Platform Info: System: Darwin (x86_64-apple-darwin13.4.0) CPU: Intel(R) Core(TM) i7-4980HQ CPU @ 2.80GHz WORD_SIZE: 64 BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Haswell) LAPACK: libopenblas64_ LIBM: libopenlibm LLVM: libLLVM-3.7.1 (ORCJIT, haswell)

Pkg.status("DifferentialEquations")

• DifferentialEquations 0.2.1+ master

Improving plots recipes

The plot function for animations can be improved. Right now it's a little (or a lot) hacky. The core is that it plots:

push!(ps,plotfunc(sol.femMesh.node[:,1],sol.femMesh.node[:,2],sol.timeSeries[i][j]))

at each step where this is in (x,y,z[i]) form where there are i different plots made at each step j. Plotfunc is the chosen plotting function, which is only used because this isn't a recipe implementation.

atomLoaded ? Main.Atom.progress(j/length(sol.timeSeries[1])) : nothing #Use Atom's progressbar if loaded

adds an Atom progressbar if the user is using Atom, which I find necessary convenience for long animations.

Using a recipe will likely also have a way to choose the backend? Right now it's set to PyPlot, but it should be able to switch to something like GR when it's surface plots, but should also handle trisurf plots (when those are implemented in Plots).

Stabilized Explicit Methods

ROCK2 and ROCK4. RKC. Need to give these a go.

Add Interface for Sundials.jl

Add an interface for Sundials.jl

Fix BigFloat adaptivity

Currently, BigFloat adaptivity fails because of JuliaLang/julia#17728. A conditional dependency on https://github.com/simonbyrne/GenericSVD.jl should be added when BigFloats are attempted to be used adaptively to fix this issue.

Name aliasing

See this SE question. I would like to implement this for defining the problems. The syntax there would translate for the FEM methods. It would be nice to have it for other problem types as well.

Performance Meta Issue

This issue is for tracking places where small performance updates should occur:

• Feagin's update step should become in place. #30
• Change tableaus to StaticArrays #9, waiting on v0.5 release
• Add precompile hinting
• Improve type-inference on FEM, and make quadrature in-place.
• Make FEM solvers in place, add wrapper for non-inplace inputs #18
• Change cg! and gmres! to really in place #5
• Make ParallelAccelerator versions of solvers when v0.5 compatible?
• Make multi-threaded versions of solvers
• Add Xeon Phi / GPU solvers
• Lund Stabilization
• Change ChunkedArrays to in-place random generation
• Try new RNGs from RNG.jl

Add DDE solvers

Want to wrap RETARD and RADAR5 and add Method of Steps solvers.

naming conventions

currently the packages, consistently :), uses camelCase for naming, though common and fine, almost all julia packages have instead settled on using the (extremely rough) guidelines from the julialang Contribuiting.md

General Formatting Guidelines for Julia code contributions

• 4 spaces per indentation level, no tabs
• use whitespace to make the code more readable
• no whitespace at the end of a line (trailing whitespace)
• comments are good, especially when they explain the algorithm
• try to adhere to a 92 character line length limit
• use upper camel case convention for modules, type names
• use lower case with underscores for method names
• it is generally preferred to use ASCII operators and identifiers over Unicode equivalents whenever possible

even Jump, a package that used camelCase macros before this convention was decided upon has recently switched to be more consistent.

I know this is the most boring kind of discussion (bordering on things as silly as 0, 1 indexing, emacs vs vi etc). The only reason I think it is important is that it makes the julia ecosystem feel more consistent, and I have very high hopes that this package becomes the package for solving diff.eqs. (I kind of wish they had decided on camelCase ... as it feels far less ambiguous to me ... for example all the issomething vs is_something inconsistency, but the convention is the convention)

My favorite example of what happens when people don't all agree on this is the naming convention mess in R where fundamental functions like read.table have keyword arguments that mix key.word and keyWord styles within the same function! (not to mention I increasingly notice key.word vs key_word vs keyWord ... I am sure there are reasons but it is brutal as an end user).

If this is something you are willing to consider I am happy to help with the renaming ... as it will largely be busy work and testing.

Implement Feagin's Super-High RK Methods

A sample implementation is here for these methods. I will be implementing these by the end of summer, and testing these with BigFloats, Decimals, and ArbFloats.

Symplectic ODE Methods

Magnus https://www.math.ntnu.no/num/synode/papers/pdf/iserles98oti.pdf
http://www.macs.hw.ac.uk/~simonm/magnus.pdf
http://personales.upv.es/~serblaza/2006APNUM.pdf

Moan http://ac.els-cdn.com/S0377042701004927/1-s2.0-S0377042701004927-main.pdf?_tid=180e5c88-6511-11e6-85d0-00000aacb35d&acdnat=1471503657_5677b753c09cc5ad828f97a62c36d226

Add nice displays for the types

Should add nice diaplays for the types in Juno via Media.jl. Or maybe something in relation to JuliaLang/julia#16763

Implement DAE Solvers

Implement DAE Solvers. Probably start by adding an interface for DASSL.jl

Feagin fixed timestep in-place

Feagin with fixed timestep should be able to have an in-place op (commented), but for some reason it drops the order.

SRA Tableau Choice

Right now the tableau for SRA is hardcoded to SRA1 because of the way the default_tableau is set. By using dispatch the default tableau can be used to choose SRA vs SRI to alleviate this issue.

Wrap LSODE

LSODE is known to be a good solver.. This might be achieved through ODEInterface: luchr/ODEInterface.jl#1

Options as Dictionaries

Implement options via dictionaries to better control default values. Allows for easier transition of options between packages.

Parallel ODE Solvers

This is a good SE post for explaining the difference between the major groups.

Here is another reference for the differences .

Maybe we should write a wrapper to PFASST.

Better name for solution values?

It used to have sol.uTrue, but it's not sol.analytic. For some of them you add an s to get the full series, while you have sol.u for the solution at the end but sol.timeseries for the full series. I know this is a mess. Anyone have any ideas to make it better?

Compatibility with SIUnits.jl

Compatibility with SIUnits.jl is almost complete. This is on the units branch. For example, it works with ODEs and SDEs:

using DifferentialEquations

using SIUnits
α = 0.5
f(y,t) = α*y
u₀ = 1.5Newton
prob = ODEProblem(f,u₀)

sol =solve(prob::ODEProblem,[0,1],Δt=(1/2^4)Second,save_timeseries=true,alg=:Midpoint,adaptive=true)

Plots.plotly()
plot(map((x)->x.val,sol.t),map((x)->x.val,sol[:])) #plot(sol)
#plot(sol.t,sol[:]) # Doesn't work because no unit recipe
#plot(sol) #Doesn't work because the one above doesn't work

β = 0.6
σ(y,t) = β*y
prob = SDEProblem(f,σ,u₀)

sol =solve(prob::SDEProblem,[0,1],Δt=(1/2^4)Second,save_timeseries=true,alg=:EM)

Works. What doesn't work is if you use alg=:ExplicitRK. That's the only DifferentialEquation.jl alg solver that doesn't work, but there is an open issue to fix that: Keno/SIUnits.jl#85.

The other problem is the plotting. Currently you have to do:

plot(map((x)->x.val,sol[:]),map((x)->x.val,sol.t)) #plot(sol)

To make it simpler for users, plot recipes will need to be defined. The issue is open for that: Keno/SIUnits.jl#86.

Problems exist with UnitRanges, so meshgrid doesn't work:

Δx = (1//2^(3))Meter
fem_mesh = notime_squaremesh([0 1 0 1],Δx,:dirichlet) #Fails at meshgrid because unit ranges not supported

and Heat Equation needs more work (A needs units).

Example: Unit Checked Arithmetic via SIUnits

LoadError: Dimension mismatch in convert. Attempted to convert a (SIUnits.SIUnit{1,1,-2,0,0,0,0,0,0}) to (SIUnits.SIUnit{1,1,-3,0,0,0,0,0,0})
while loading In[6], in expression starting on line 6

in convert(::Type{SIUnits.SIQuantity{Float64,1,1,-3,0,0,0,0,0,0}}, ::SIUnits.SIQuantity{Float64,1,1,-2,0,0,0,0,0,0}) at C:\Users\Denis.julia\v0.5\SIUnits\src\SIUnits.jl:148
in ode_solve(::DifferentialEquations.ODEIntegrator{:Midpoint,SIUnits.SIQuantity{Float64,1,1,-2,0,0,0,0,0,0},SIUnits.SIQuantity{Float64,1,1,-2,0,0,0,0,0,0},1,SIUnits.SIQuantity{Float64,0,0,1,0,0,0,0,0,0},Float64,SIUnits.SIQuantity{Float64,1,1,-3,0,0,0,0,0,0},SIUnits.SIQuantity{Float64,1,1,-3,0,0,0,0,0,0}}) at C:\Users\Denis.julia\v0.5\DifferentialEquations\src\ode\ode_integrators.jl:107
in #solve#559(::Array{Any,1}, ::Function, ::DifferentialEquations.ODEProblem{SIUnits.SIQuantity{Float64,1,1,-2,0,0,0,0,0,0},SIUnits.SIQuantity{Float64,1,1,-2,0,0,0,0,0,0}}, ::Array{Int64,1}) at C:\Users\Denis.julia\v0.5\DifferentialEquations\src\ode\ode_solve.jl:190
in (::DifferentialEquations.#kw##solve)(::Array{Any,1}, ::DifferentialEquations.#solve, ::DifferentialEquations.ODEProblem{SIUnits.SIQuantity{Float64,1,1,-2,0,0,0,0,0,0},SIUnits.SIQuantity{Float64,1,1,-2,0,0,0,0,0,0}}, ::Array{Int64,1}) at .:0

and at ln[10]

LoadError: MethodError: no method matching linspace(::SIUnits.SIQuantity{Float64,0,0,1,0,0,0,0,0,0}, ::SIUnits.SIQuantity{Float64,0,0,1,0,0,0,0,0,0}, ::Int64)
Closest candidates are:
linspace{T<:AbstractFloat}(!Matched::T<:AbstractFloat, !Matched::T<:AbstractFloat, ::Real) at range.jl:249
linspace(!Matched::Real, !Matched::Real, ::Real) at range.jl:253
linspace{T<:ColorTypes.Color{T,N}}(!Matched::T<:ColorTypes.Color{T,N}, !Matched::T<:ColorTypes.Color{T,N}, ::Any) at C:\Users\Denis.julia\v0.5\Colors\src\utilities.jl:63
while loading In[10], in expression starting on line 1

in macro expansion at C:\Users\Denis.julia\v0.5\DifferentialEquations\src\general\plotrecipes.jl:79 [inlined]
in apply_recipe(::Dict{Symbol,Any}, ::DifferentialEquations.ODESolution) at C:\Users\Denis.julia\v0.5\RecipesBase\src\RecipesBase.jl:238
in _process_userrecipes(::Plots.Plot{Plots.PyPlotBackend}, ::Dict{Symbol,Any}, ::Tuple{DifferentialEquations.ODESolution}) at C:\Users\Denis.julia\v0.5\Plots\src\pipeline.jl:73
in _plot!(::Plots.Plot{Plots.PyPlotBackend}, ::Dict{Symbol,Any}, ::Tuple{DifferentialEquations.ODESolution}) at C:\Users\Denis.julia\v0.5\Plots\src\plot.jl:157
in (::Plots.#kw##plot)(::Array{Any,1}, ::Plots.#plot, ::DifferentialEquations.ODESolution) at .:0

Make Solvers In-Place

Self-explanatory. Will get performance gains. Can automatically make an in-place version if not given one.

Example: Animating the solution

At ln[2]
using DifferentialEquations, Plots, ImageMagick
T = 5
Δx = 1//2^(3)
Δt = 1//2^(11)
fem_mesh = parabolic_squaremesh([0 1 0 1],Δx,Δt,T,:neumann)
prob = heatProblemExample_stochasticbirthdeath()

I receive the following error;

LoadError: UndefVarError: heatProblemExample_stochasticbirthdeath not defined
while loading In[3], in expression starting on line 6

Add Interface for ODEInterface.jl

Add the methods from ODEInterface.jl to the ODE solvers.

Change tableaus to FixedSizeArrays

This change should make sure that the arrays are stack allocated instead of heap allocated as noted by @TotalVerb . These should be changed and benchmarked.

Can't install.

No version of the package loads correctly.
Using the package after Pkg.install() returns an error with BezierCurve (https://groups.google.com/forum/#!topic/julia-users/JpznWG2isxA)
Using the package after Pkg.update() returns the error

LoadError: LoadError: ArgumentError: argument is not a generic function
 in methods at reflection.jl:180

CG and GMRES Incompatible with Systems of PDEs

CG and GMRES linear solvers only work on vectors and not matrices due to using dot. An issue has been opened at JuliaLinearAlgebra/IterativeSolvers.jl#73. I may need to implement my own CG/GMRES. Also related is a way to handle different diffusion constants (functions) with CG/GMRES

DifferentialEquations Roadmap

DifferentialEquations is dealing with the forward problem in Julia: predicting the model behaviour for all types of DEs and all types of solvers.

Are you planning to go into the direction of the Inverse Problem: inferring the models parameters from data. A hint in this direction can be found here: http://www2.warwick.ac.uk/fac/sci/statistics/staff/academic-research/girolami/podes/ . Coming from Matlab, it should translate well to Julia.

In this area, there is also the work on automatic differentiation with wrappers in python as in here: http://www.bmp.ds.mpg.de/pyodefit.html which could benefit hugely from treatment in Julia.

Thank you.

Example: Calling External Solvers

In the external solvers section,

sol =solve(prob::ODEProblem,tspan,Δt=Δt,alg=:ode45)
plot(sol,lab=["x" "y"])

LoadError: UndefVarError: ExplicitODE not defined
while loading In[4], in expression starting on line 1

in #solve#559(::Array{Any,1}, ::Function, ::DifferentialEquations.ODEProblem{Array{Float64,1},Float64}, ::Array{Int64,1}) at C:\Users\Denis.julia\v0.5\DifferentialEquations\src\ode\ode_solve.jl:256
in (::DifferentialEquations.#kw##solve)(::Array{Any,1}, ::DifferentialEquations.#solve, ::DifferentialEquations.ODEProblem{Array{Float64,1},Float64}, ::Array{Int64,1}) at .:0

then at

sol =solve(prob::ODEProblem,tspan,Δt=Δt,alg=:dopri5)
plot(sol,lab=["x" "y"])

[DifferentialEquations.jl] Initializing backend: ODEInterface
LoadError: Cannot find method(s) for dopri5! I've tried to loadODESolvers(), but it didn't work. Please check ODEInterface.help_solversupport() and call loadODESolvers and check also this output. For further information see also ODEInterface.help_install.

while loading In[5], in expression starting on line 1

in getAllMethodPtrs(::String) at C:\Users\Denis.julia\v0.5\ODEInterface\src.\DLSolvers.jl:229
in dopri5_impl(::Function, ::Float64, ::Float64, ::Array{Float64,1}, ::ODEInterface.OptionsODE, ::ODEInterface.DopriArguments{Int64}) at C:\Users\Denis.julia\v0.5\ODEInterface\src.\Dopri5.jl:128
in dopri5(::Function, ::Float64, ::Float64, ::Array{Float64,1}, ::ODEInterface.OptionsODE) at C:\Users\Denis.julia\v0.5\ODEInterface\src.\Dopri5.jl:102
in odecall(::ODEInterface.#dopri5, ::Function, ::Array{Float64,1}, ::Array{Float64,1}, ::ODEInterface.OptionsODE) at C:\Users\Denis.julia\v0.5\ODEInterface\src.\Call.jl:115
in #solve#559(::Array{Any,1}, ::Function, ::DifferentialEquations.ODEProblem{Array{Float64,1},Float64}, ::Array{Int64,1}) at C:\Users\Denis.julia\v0.5\DifferentialEquations\src\ode\ode_solve.jl:216
in (::DifferentialEquations.#kw##solve)(::Array{Any,1}, ::DifferentialEquations.#solve, ::DifferentialEquations.ODEProblem{Array{Float64,1},Float64}, ::Array{Int64,1}) at .:0

and again for the next two dopri5

Finally at

sol =solve(prob::ODEProblem,tspan,Δt=Δt,alg=:cvode_Adams)
plot(sol,lab=["x" "y"])

[DifferentialEquations.jl] Initializing backend: Sundials
LoadError: UndefVarError: cvode_fulloutput not defined
while loading In[8], in expression starting on line 1

in #solve#559(::Array{Any,1}, ::Function, ::DifferentialEquations.ODEProblem{Array{Float64,1},Float64}, ::Array{Int64,1}) at C:\Users\Denis.julia\v0.5\DifferentialEquations\src\ode\ode_solve.jl:317
in (::DifferentialEquations.#kw##solve)(::Array{Any,1}, ::DifferentialEquations.#solve, ::DifferentialEquations.ODEProblem{Array{Float64,1},Float64}, ::Array{Int64,1}) at .:0

Add a Precompile hint file

Add tableaus

This would be a really easy but nice contribution! See https://github.com/ChrisRackauckas/DifferentialEquations.jl/blob/master/src/ode/ode_tableaus.jl for the current tableaus.

Add general Adams-Bashforth-Moulton methods

A table of methods for different orders can be found here. First the these fixed orders will be implemented and tested, and then a variable order implementation would be nice.