Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Sep 24 21:04
    ChrisRackauckas commented #901
  • Sep 24 21:03
    ChrisRackauckas commented #901
  • Sep 21 19:01
    danielwe opened #901
  • Sep 20 21:49
    ChrisRackauckas commented #786
  • Sep 19 13:08

    github-actions[bot] on v7.4.0

    (compare)

  • Sep 19 13:06
    JuliaTagBot commented #709
  • Sep 19 12:48
    JuliaRegistrator commented #479
  • Sep 19 12:48
    ChrisRackauckas commented #479
  • Sep 19 12:40

    ChrisRackauckas on master

    Update Project.toml (compare)

  • Sep 19 12:40

    ChrisRackauckas on ChrisRackauckas-patch-1

    (compare)

  • Sep 19 12:40

    ChrisRackauckas on master

    Change default Rodas5 to Rodas5… Update default_ode_alg_test.jl Merge pull request #900 from Sc… (compare)

  • Sep 19 12:40
    ChrisRackauckas closed #900
  • Sep 19 12:33
    codecov[bot] commented #900
  • Sep 19 12:18
    ChrisRackauckas synchronize #900
  • Sep 19 12:17

    ChrisRackauckas on ChrisRackauckas-patch-1

    Update default_ode_alg_test.jl (compare)

  • Sep 19 11:28
    ChrisRackauckas opened #900
  • Sep 19 11:20

    ChrisRackauckas on ChrisRackauckas-patch-1

    Change default Rodas5 to Rodas5… (compare)

  • Sep 16 19:51
    rmsrosa closed #899
  • Sep 16 19:51
    rmsrosa commented #899
  • Sep 15 09:29
    rmsrosa commented #899
Christopher Rackauckas
@ChrisRackauckas
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?
Paweł Biernat
@pwl
viral for sure, I don't know about others
Christopher Rackauckas
@ChrisRackauckas
Do they know about all of the changes you're doing and will pretty much accept? Or is there a chance that when you decide to pull it will hang for awhile?
Paweł Biernat
@pwl
I talked to viral and he is pretty eager to accept almost anything that would make ODE.jl more attractive.
and we plan to be backward compatible
Christopher Rackauckas
@ChrisRackauckas
Well I think I am going to go ahead with wrapping only ODE.jl, and clean up my code to conform better with Julia standard (I realized that my camelCase isn't what's used here, so I'll fix that all up).
I will use that to set benchmarks, and when that's all together I'll contact you guys again.
Paweł Biernat
@pwl
cool, let's keep in touch!
Mauro
@mauro3
Tnx!