Skip to content

DifferentialEquations.jl v8 #1086

Open
Open
@ChrisRackauckas

Description

@ChrisRackauckas

As a bit of an extension to the discussion in #1082 (comment), specifically on the DifferentialEquations.jl changes, we need to consider what we want DiffEq to look like. We can do this separately from anything else as just a v8 so... what should it be? I'm thinking the steps are:

  • Move automated algorithm selection for DDEs to DelayDiffEq.jl
  • Move automated algorithm selection of DAEs and DiscreteProblem to OrdinaryDiffEq.jl
  • Move automated algorithm selection of SDEs and RODEs to StochasticDiffEq.jl
  • Move automated algorithm selection of SteadyStateProblems to NonlinearSolve
  • Move the default for BVPs to BoundaryValueDiffEq
  • Fully remove Sundials, which was set to not re-export a few years ago already https://github.com/SciML/DifferentialEquations.jl/blob/master/src/DifferentialEquations.jl#L13

Those ones are clear. But now I think we have some choices to make. Here's one path I see:

Specialize DifferentialEquations.jl to just be ODEs, so:

  • Make it just reexport OrdinaryDiffEq.jl
  • Update each of the docs pages like https://docs.sciml.ai/DiffEqDocs/stable/tutorials/sde_example/ to tell people to grab the relevant solver package
  • Remove the deps and importing on anything else
  • Add specialized error hinting and warnings so if you build an SDEProblem it tells you to add StochasticDiffEq.jl if it's not loaded? (Maybe add this to SciMLBase itself?

So in that way, the whole system is still documented together as a cohesive set of differential equation solvers, but people are pushed to just get OrdinaryDiffEq.jl. This would wildly improve loading times for lots of people, since the vast majority just instinctively grab DifferentialEquations.jl because "it's for ODEs". This of course has drawbacks of forcing anyone beyond the simple ODEs to have to know to grab subpackages. Is that okay with a few helpers?

This really is then a question of what we think in 2025 the identity of DifferentialEquations.jl should be. I think with the package splitting and such people "in the know" has largely started to default to just grabbing specific OrdinaryDiffEq solvers, as they should. And people "in the half know" have largely started to just use OrdinaryDiffEq.jl directly. So what's the point of DifferentialEquations.jl? Is it giving an unnecessarily difficult loading time experience to new users given that no experienced user gravitates to it anymore? So should it and OrdinaryDiffEq.jl be effectively the same repo, and the rest is a documentation problem of how to make it look and feel cohesive in a world where these things are truly separated packages? Or is there still a role for newbies with the all batteries included form? Or is it a trap with too many batteries?

I'd like to get opinions from others, but at this point I think I'd lean towards making DiffEq v8 effectively be the same as OrdinaryDiffEq. It's OrdinaryDiffEq that's a bit redundant and not needed, since you either want to choose solvers or choose the easy thing, and the easy thing "should" be using DifferentialEquations. But I'd like second opinions since this is really nothing about a technical choice but more of how it should look and feel.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions