Building on OrdinaryDiffEq.jl vs DiffEqBase.jl

Specific Domains Numerics
, , ,
2

Note that StochasticDiffEq.jl and DelayDiffEq.jl do this as well. I’d write it like this:

  1. If you just want the problem type and nothing else, great just go from SciMLBase.jl. I wouldn’t recommend this one for ODEs since DiffEqBase.jl has the callback handling, which is something that you probably wouldn’t want to have to copy. Pro: very little startup time. Con: no infrastructure. Good luck.
  2. If you want all of the basic building blocks for the differential equation solver APIs (like the error handling functions, callbacks, etc.) then DiffEqBase.jl is what to build off of. Pro: enough infrastructure that you can easily guarantee that you follow the interface. Con: things that can be hard but require big dependencies (handling sparse Jacobians) are not here.
  3. If you want to extend some of the numerical details of the solvers, say use the same Jacobian handling and all of that, then extending off of OrdinaryDiffEq.jl could work. But note that if you’re doing that, you’re likely extending non-public APIs, so you should let us know about this so that there’s more of a conversation about how things internally change (i.e. letting you know when we break something that’s being used downstream). We should probably add a downstream test there as well. I try to support everyone I can here, but without a downstream test it’s hard to keep people informed. Pro: more features come for free, like sparse differentiation. Con: you’d be building off of non-public internals. Things might break.
  4. If you want your new solver to be maintained by the SciML community, add it to OrdinaryDiffEq.jl. This does require that it’s not too custom. “Too custom” is a bit hard of a line to draw: I think parareal could be done as a perform_step!, but it might be hard. Pro: you can be guaranteed that it will not break because it will all be part of the mainline OrdinaryDiffEq.jl development and tests. Con: it needs to fit the structure of OrdinaryDiffEq.jl, which is “most” solvers, but there are interesting cases that are outside of this.

As above, I think extending OrdinaryDiffEq.jl isn’t bad, but it needs to be done carefully. When we have everything in the SciML ecosystem, we have bots that tell us “this change will break DelayDiffEq”, so we make sure that PR is ready before we release an internal change to OrdinaryDiffEq.jl so that way the DDE solvers just seamlessly update. This all follows semvar: things that are not public API can break at any time, and the public API of OrdinaryDiffEq is solve, init, and the algorithms.

I don’t think that will change anytime soon just because some of these internals are pretty closely tied to how the solvers are written. These internals probably have 2-3 more years before every sparse GPU etc. case is handled well. But we as an org would be happy to take in some of these other repos and help maintain them to do more custom and weird things. It just needs real integration (downstream testing, co-development, and continued maintenance) instead of being treated as a one-and-done thing if it’s using the internals of another package.

Maybe in the future some of those bits will become a builder package or move to DiffEqBase. FiniteDiff.jl was an OrdinaryDiffEq.jl internal for many years, same with LinearSolve.jl, etc. so over time packages for tools get spawned out. But some pieces are still in too much flux to spawn out.

5 Likes