## Where communities thrive

• Join over 1.5M+ people
• Join over 100K+ communities
• Free without limits
• Create your own community
##### Activity
• Dec 04 12:32

ChrisRackauckas on master

• Dec 04 12:31

ChrisRackauckas on master

• Dec 03 18:41
ChrisRackauckas closed #916
• Dec 03 15:03
asprionj edited #916
• Dec 03 15:00
asprionj commented #893
• Dec 03 14:59
asprionj opened #916
• Dec 03 10:18
ChrisRackauckas closed #915
• Dec 03 10:18
ChrisRackauckas commented #915
• Dec 03 10:17
ChrisRackauckas commented #914
• Dec 03 10:01
ChrisRackauckas commented #893
• Dec 03 07:59
asprionj commented #893
• Dec 03 01:43
ChrisRackauckas commented #893
• Dec 03 01:38

ChrisRackauckas on master

• Dec 02 21:24
asprionj commented #893
• Dec 02 21:18
ChrisRackauckas commented #893
• Dec 02 21:16
asprionj commented #893
• Dec 02 20:52
ChrisRackauckas commented #893
• Dec 02 20:18
asprionj commented #893
• Dec 02 15:39
ChrisRackauckas transferred #912
• Dec 02 15:38
ChrisRackauckas commented #912
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)

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."
But if that is not an option, you can also use it at some later stage.
Christopher Rackauckas
@ChrisRackauckas
What's you're development like? I see you're making great strides because of the GSoC, but will it slow down after summer? I thought I saw it almost slow to a crawl for awhile.
I think I remember you're faculty in Germany, so you probably get super busy during the year?
If that's the case, I'll hold up on wrapping the other packages until nearing the end of summer to take stock on how far along you are with it.
Paweł Biernat
@pwl
development of the iterators is independent of the development of new solvers, only the latter is done by GSoC student (and @mauro3)
Mauro
@mauro3
I think, we're all just doing it "by-night"...
Christopher Rackauckas
@ChrisRackauckas
Oh okay.
Mauro
@mauro3
Yes, check back in a wee while and we can tell you more.
Christopher Rackauckas
@ChrisRackauckas
so the development of new solvers is the summer thing?
The wrapping will be more of an ongoing project, not being pushed right now?
Paweł Biernat
@pwl
the wrapping is not a difficult task by itself, the difficulty lies in deciding what goes into the backend API and how do we design it
that's why it takes so long, it's a theoretical discussion for the most part
and there are only two people working on it (me and @mauro3)
Christopher Rackauckas
@ChrisRackauckas
I see. You wrote DASSL? I suppose you plan to wrap that BDF solver too?
Paweł Biernat
@pwl
that's on our list
Christopher Rackauckas
@ChrisRackauckas
How do you guys plan on handling the dependencies?
Mauro
@mauro3
Not sure yet whether we'll go the Plots.jl-eval or the MathProgBase route.
Christopher Rackauckas
@ChrisRackauckas
I think I'm going to be doing the Plots.jl approach. I think it makes more sense given how I already set things up.
So are there any more things I should know about? Any other solvers (or "integrators") you're implementing? (Waveform relaxation???)
Oh and do all of your methods work for arbitrary number types?
Paweł Biernat
@pwl
they do
the only limitation now is that the state vector has to be indexible
Also, you should know that the new solvers in ODE.jl are not conforming to the iterator interface yet. They will be ported at some point (perhaps once we merge back into the original repo).