Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 15:39
    ChrisRackauckas transferred #912
  • 15:38
    ChrisRackauckas commented #912
  • 10:55

    ChrisRackauckas on master

    Update README.md (compare)

  • 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
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).
Christopher Rackauckas
@ChrisRackauckas
Okay.
Is ODE.jl going to still be part of JuliaLang?
Mauro
@mauro3
I guess that is something to be discussed.
Paweł Biernat
@pwl
That's not up to us to decide, we are only developing a rogue fork and we have no write access to the main package.
Christopher Rackauckas
@ChrisRackauckas
Oh I see.
I would've thought you guys had write access.
Mauro
@mauro3
One day ...
Christopher Rackauckas
@ChrisRackauckas
Who actually has write access to that REPO?