ChrisRackauckas/DifferentialEquations.jl

Julia package for solving differential equations

Christopher Rackauckas

@ChrisRackauckas

So what are your main development plans for the near future?

Mauro

@mauro3

Ah, nice, thanks for the tip.

Concerning work on ODEs: @pwl and I have been overhauling ODE this summer and I think it is looking promising. We're working in https://github.com/JuliaODE, which is currently just a work-space but could, if interest is there, be also used as a org.

Anyway, the current development is in the branch https://github.com/JuliaODE/ODE.jl/tree/dev . Maybe this is closer to your requirements? If not, maybe you could comment whether there is anything which is missing.

I think it should become usable in the next few weeks.

Christopher Rackauckas

@ChrisRackauckas

I see. So most of what you've been doing are the Adams-Bashford-Moulton, dense output, and solvers on iterators?

I'll be wrapping ODE very soon into DifferentialEquations, so I wanted to know other solvers you were implementing. I haven't done an ABM, so I think now that I see you have one pretty much complete there's no reason for me to do it.

Are you also working on stiff solvers?

Christopher Rackauckas

@ChrisRackauckas

Also, how exactly do you plan to be using tspan? I haven't settled on anything but am wondering where you're taking it.

I was thinking that if it's size 3, then it's beginning, end, and timestep. And then anything more is explicitly telling the timesteps. I wanted to match whatever you're going to be using though.

Mauro

@mauro3

A-B-M is @obiajulu's work: JuliaLang/ODE.jl#106

There is some work on stiff solvers: JuliaLang/ODE.jl#72 and @obiajulu is starting on RADAU, but nothing finished.

Anyway, have a look at the iterator work and see whether you like it. If so you could consider wrapping that instead of the old one. Also, wrapping outside solvers should be easy with that, and is planned.

tspan, see https://github.com/JuliaODE/ODE.jl/blob/dev/src/types.jl for our latest thoughts.

Christopher Rackauckas

@ChrisRackauckas

And is this the page that will have the most up to date API? https://github.com/JuliaODE/ODE.jl/blob/dev/doc/api.md

Mauro

@mauro3

Sorry, docs are missing (above is outdated), but the code is starting to be reasonably documented. Looking at https://github.com/JuliaODE/ODE.jl/blob/dev/src/ODE.jl tells you the order of things.

Christopher Rackauckas

@ChrisRackauckas

Okay so there's a whole new interface based off of dispatch.

I think I'm seeing it.

All of your functions are in-place?

Paweł Biernat

@pwl

hi!

they are

Mauro

@mauro3

Yes
Hi @pwl

Paweł Biernat

@pwl

the dense output is still being worked on and may change, but i think we are more or less stable with the iterator API

and there if you want to comment/ask questions we have a gitter chat room https://gitter.im/JuliaODE/ODE.jl

Christopher Rackauckas

@ChrisRackauckas

You should add the badge to the README

Paweł Biernat

@pwl

it is there

Mauro

@mauro3

Just on the fork though

Christopher Rackauckas

@ChrisRackauckas

So the solvers are exposed via odexx and ode(...)?

Paweł Biernat

@pwl

nah, this is the old matlab style interface

we keep it for backward compatibility

This is the way to call the iterators

    ode  = ODE.ExplicitODE(t0,y0,(t,y,dy)->dy[1]=y[1])
    opts = Dict(:initstep=>0.1,
                :tspan=>[0.,0.5,1.],
                :points=>:specified,
                :reltol=>1e-5,
                :abstol=>1e-5)
    stepper = ODE.RKStepperAdaptive{:rk45}

    sol = ODE.solve(ode,stepper;opts...)

    for (t,y) in sol # iterate over the solution
        println((t,y))
    end

    println(collect(sol)) # get all the solution at once

I will be back in 10 min

Christopher Rackauckas

@ChrisRackauckas

Thanks for the example.

Mauro

@mauro3

And there will be more julian high-level functions with similar signature to the matlab-style ones but passing a stepper-type to select the integrator:
t,y = ode(ODE.RKStepperAdaptive{:rk45}, f, y0, tspan, opts...)

Christopher Rackauckas

@ChrisRackauckas

But will sol = ODE.solve(ode,stepper;opts...) be the main one?

Mauro

@mauro3

You can use either, the ode in my example is just a thin wrapper, essentially containing @pwl's example code.

Christopher Rackauckas

@ChrisRackauckas

okay.

I think I will wrap the ODE.solve(ode,stepper;opts...) calls.

Just a heads up on what I'm doing.

Currently I have it set so that way you just do solve(prob,tspan,alg=:algorithm)

There's a bunch of keyword args I already have.

I am going to setup inside my solve command a way for it to use conditional dependencies (a la Plots.jl or JuMP)

and then add your ODE.jl algorithms as options to choose.

Then I'm going to be doing the same with ODEInterface.jl.

I'll make a quick little test suite from these, but since I already have plot recipes down and such, you can see that's going to be quick.

In the meantime, since I see you have a lot of the ODE algorithms down, I won't be implementing many more.

I do have planned before the end of the summer though to do the Feagin's RK methods (especially the Order 14 one).

Mauro

@mauro3

Cool.

I hope that we'll get around to wrap some outside solvers (Sundials, PETSc) into ODE.jl. That would save you the wrapping. Although, we probably will not be in time for you. So, if you end up liking our interface you could also do the wrapping there and just call into ODE.jl.

Christopher Rackauckas

@ChrisRackauckas

We probably shouldn't double-up efforts.

What benefits will your wrapper have to wrapping them directly?

Will it add dense output or something? (I think they have all of that jazz)

Mauro

@mauro3

I guess it would be a central place to use ODE solvers. Then more fancy/higher-level packages, like yours or IVPTestSuite.jl, could just use ODE.jl and get access to all solvers.

Yes, dense output is included (only 3rd order so far, but can be overloaded by solvers for higher order).

Paweł Biernat

@pwl

it would be a general interface for calling ODE solvers (implemented in ODE.jl directly or just wrapped like PETSc). This way people wouldn't have to create separate wrappers themselves. We would also take care of translating various options into their proper form effectively unifying keyword options.

Christopher Rackauckas

@ChrisRackauckas

I see. When do you plan to have that wrapped by?

Mauro

@mauro3

We don't know... Thus my statement: "if you end up liking our interface you could also do the wrapping there and just call into ODE.jl."

Where communities thrive

People

Repo info

Activity