Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Nov 27 00:16

    ChrisRackauckas on gh-pages

    build based on 8dc89e0 (compare)

  • Nov 27 00:15

    ChrisRackauckas on gh-pages

    build based on db66b39 (compare)

  • Nov 27 00:15

    ChrisRackauckas on new_version

    (compare)

  • Nov 27 00:15

    ChrisRackauckas on master

    CompatHelper: add new compat en… Merge pull request #51 from Sci… (compare)

  • Nov 27 00:15
    ChrisRackauckas closed #51
  • Nov 27 00:14
    ChrisRackauckas synchronize #51
  • Nov 27 00:14

    ChrisRackauckas on new_version

    CompatHelper: add new compat en… (compare)

  • Nov 27 00:14
    github-actions[bot] opened #51
  • Nov 27 00:14

    ChrisRackauckas on new_version

    CompatHelper: add new compat en… (compare)

  • Nov 26 18:26
    ChrisVL1 opened #915
  • Nov 26 01:42

    ChrisRackauckas on gh-pages

    build based on 326c7b0 (compare)

  • Nov 26 01:41

    ChrisRackauckas on master

    docs compat Merge pull request #50 from Arn… (compare)

  • Nov 26 01:41
    ChrisRackauckas closed #50
  • Nov 26 01:05
    codecov[bot] commented #50
  • Nov 26 01:02
    ArnoStrouwen opened #50
  • Nov 24 14:11

    ChrisRackauckas on master

    Update README.md (compare)

  • Nov 22 14:41
    ChrisRackauckas commented #914
  • Nov 22 14:30
    ChrisVL1 commented #914
  • Nov 22 14:16
    ChrisRackauckas commented #914
  • Nov 22 14:13
    ChrisVL1 commented #914
Paweł Biernat
@pwl
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."
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.