Rename DifferentialEquations.jl to DiffEq.jl?

[musm]

As the title says, DiffEq.jl fits in with the rest of the orgs organizational and name structure. It would also make it easier for others to identify its centrality with respect to the solvers and the other helper packages.

[ChrisRackauckas]

I've always been pretty publicly for this since my first METADATA PR. I still think DifferentialEquations is too long. Maybe Pkg3 could alias names, so DiffEq and DifferentialEquations point to the same thing? That way it would have a clear name and a short (and clear) name!

Any name change has to go by @tkelman. Name changes don't work very well with METADATA, so it might be smart to, if we agree on it, slate the name change as a Pkg3 change.

[musm]

sounds good. Since 0.6 is end of year, I suppose we don't have to wait long for Pkg3

[ChrisRackauckas]

What about having a DiffEq.jl which just reexports DifferentialEquations.jl? That would be a simple alias package which would be nice to have (also, who else could sensibly use the name at this point?)

[mauro3]

-1 from me. First DifferentialEquations.jl is a nice name. Second, that package is not the sole purpose of the JuliaDiffEq organization, which the DiffEq.jl name would suggest.

[ChrisRackauckas]

Second, that package is not the sole purpose of the JuliaDiffEq organization, which the DiffEq.jl name would suggest.

As of yesterday, DifferentialEquations.jl is now pretty much a common slate for the JuliaDiffEq since all of the functionality moved out to separate packages. I mean, the full code is this:

module DifferentialEquations

  using Reexport

  @reexport using DiffEqBase
  @reexport using StochasticDiffEq
  @reexport using FiniteElementDiffEq
  @reexport using DiffEqDevTools
  @reexport using OrdinaryDiffEq
  @reexport using AlgebraicDiffEq
  @reexport using StokesDiffEq
  @reexport using DiffEqParamEstim
  @reexport using DiffEqSensitivity

end

It's a little misleading because actually, OrdinaryDiffEq is also using Sundials, ODEInterface, and PR49 together in the "pre" version of the unified interface, and it documents all of it together. Once the common interface is in the distributed form and things like DASSL plug in, the code will be

module DifferentialEquations

  using Reexport

  @reexport using DiffEqBase
  @reexport using StochasticDiffEq
  @reexport using FiniteElementDiffEq
  @reexport using DiffEqDevTools
  @reexport using OrdinaryDiffEq
  @reexport using ODE
  @reexport using Sundials
  @reexport using ODEIterators
  @reexport using DASSL
  @reexport using AlgebraicDiffEq
  @reexport using StokesDiffEq
  @reexport using DiffEqParamEstim
  @reexport using DiffEqSensitivity

end

and it will document using the common interface and the add-on components. The only thing that's left out is ODEInterface, which is both not DiffEq and it has build issues on many setups. (ParameterizedFunctions will be here as well after SymEngine makes build issues more safe). So since all of the algorithms / functionality moved out to metapackages, it really just will be the set of functionality which is available via the common interface. You can then use any component directly, but this will be the package which will solve any differential equation with any method defined in JuliaDiffEq.

What I was saying about an alias is that we could just have a DiffEq package which does

module DiffEq

  using Reexport

  @reexport using DifferentialEquations

end

and so it's a nice shorthand for whoever wants it. I don't know if registering this would every fly though.

[musm]

-1 from me. First DifferentialEquations.jl is a nice name. Second, that package is not the sole purpose of the JuliaDiffEq organization, which the DiffEq.jl name would suggest.

Well, it kinda already is. And I think Chris's intention is to have it be the Plots.jl of the DiffEq world.
But that's unrelated to the original intention which is for ease of discoverability of the packages centrality to the ecosystem.

As the title says, DiffEq.jl fits in with the rest of the orgs organizational and name structure. It would also make it easier for others to identify its centrality with respect to the solvers and the other helper packages.

I'm not sure if creating another package which just reeexports things is a good solution. IMO it's best to either rename it completely or to not. Clearly this should be done asap so it doesn't get too ingrained (the original name DifferentialEquations.jl) or wait until Pkg3 until a better solution arrives (although who knows when that will arrive and by then it might be more annoying since the package will likely become more popular). Ultimately, however, it's Chris's decision.

[mauro3]

Well, either way. Still, I think DifferentialEquations.jl is a nice name and it stands out fine in the jungle of packages of JuliaDiffEq. Also, unlike with Plots.jl there will be different entry points and one could well just use DiffEqBase when wanting to solve an ODE.

[ChrisRackauckas]

Also, unlike with Plots.jl there will be different entry points and one could well just use DiffEqBase when wanting to solve an ODE.

Indeed, this is one way how our design improves upon Plots.jl: by distributing the common interface not only can you have different entry points, but these different entry points can still have a common API.

I do want to note that it would probably be a good idea for DiffEq members to follow the "new" DifferentialEquations.jl repository. Since all of the algorithmic issues have moved to separate repositories, what the issue now contains is just:

1. Solver addition discussions (adding DDE solvers) which, by adding this functionality to the common interface, effectively extends the available functionality to most JuliaDiffEq components (and it's important to know what "most" means, like what's come up in parameter estimation discussions).
2. Component addition discussions (adding Morris global sensitivity, different forms of parameter estimation, etc.) which, by adding this functionality to the component packages via the common interface, effectively extends the available functionality to most JuliaDiffEq solvers (same caveat to "most").
3. User bugs/errors. This is the entry-point to users for the full ecosystem, so I would expect (and am encouraging) users to continue to file issues here.

A lot of these discussions are started by or carried on by users, like this one for example: SciML/DifferentialEquations.jl#47 , and so since they are very user-facing they belong there. This Roadmap repo is just for dev roadmap discussions (like we've been having), mostly because I don't think most users would ever find this repo.

[pwl]

This Roadmap repo is just for dev roadmap discussions (like we've been having), mostly because I don't think most users would ever find this repo.

That's why I pinned it instead of DASSL. I think the discussions here are more important at this point.

[ChrisRackauckas]

I think the ship has sailed on this one.