Main directory clean up

[pwl]

The current state of JuliaDiffEq is now completely overtaken by various splinters of DifferentialEquations.jl package. Splitting up the huge package like that is a move in a good direction but we should figure out how to organize all the pieces. I don't really like that these new packages all include DiffEq in their names. I presume this is a reference to DifferentialEquations.jl but some people might think that DiffEqTutorials.jl contains tutorials for all the packages from JuliaDiffEq instead of the tutorials only for DifferentialEquations.jl. This is just one example but there are many other packages with the same problem. We should either change the name or update the packages to refer to other packages. Sorry if you (@ChrisRackauckas) already had this in mind when you were refactoring the code but I haven't seen it explicitly stated anywhere.

If you plan to extend these new packages to interact with other members of DiffEq then I propose to drop the DiffEq from their names and update their README.md to at least point that's a work in progress. If they are meant to be purely parts of DifferentialEquations.jl ecosystem I would move them out of JuliaDiffEq to a different organization (but I have nothing against DifferentialEquations.jl staying in JuliaDiffEq).

[mauro3]

I think the reason to have the DiffEq in the name is the "explicit" naming convention. These packages are in Metadata.jl thus having a package just named "Tutorials.jl" doesn't work.

I agree that currently it is a bit of a mess with all the packages but unless there are changes to Metadata then there is little which can be done.

[pwl]

Ah, now I see.

Then what about DifferentialEquationsTutorials.jl? I know it's long but this way it won't be confused with other stuff in JuliaDiffEq.

[mauro3]

Yes, that might be an idea.

Also note that we can pin some repos to make them prominent, I now added DASSL.jl and ODE.jl: https://github.com/JuliaDiffEq

[pwl]

Pinning is a good idea, but it is only a temporary measure, not to mention that you can only pin six repositories. I don't think that JuliaDiffEq is a good place for an ecosystem that takes up 17 packages total and is this self-centered. Maybe moving the *DiffEq*.jl packages out to a different group and then moving them back one by one, with a proper review process, would be an option? As I said, we could leave DifferentialEquations.jl where it is and just move the other packages.

Another solution would be to set up a webpage with an index of packages just like www.juliadiff.org did. This way we could live with the mess in the JuliaDiffEq group.

[mauro3]

No, they are here to stay, those were DifferentialEquations.jl packages, which itself is part of JuliaDiffEq and is its most popular package. Also @ChrisRackauckas is the only really active member of JuliaDiffEq!

The re-organisation in my mind makes sense, in particular if the long-term goal is to make part of them more widely usable. Chris and I were chatting over in #5 about a unified interface to ODE/DAE solvers. If that is done correctly other high-level parts of the DifferentialEquations.jl universe (such as DiffEqBenchmarks.jl) should become usable to any package implementing that interface, e.g. ODE.jl. That should give the JuliaDiffEq-organisation a bit a more a inclusive feel for none-DifferentialEquations.jl packages/packagers. But it will also take some time as Chris is likely the only person actually doing the work...

[ChrisRackauckas]

[Oh hey, you can pin 6 boxes? Thanks for fixing that. The tutorials should get boosted up and added there as well I think. See the part on that package]

I plan to diagram the packages like www.juliadiff.org . In fact, the only reason why I haven't made a website yet is because.... I haven't found a good looking template hahaha (not joking, check the JuliaLang Gitter). There will be a blog post too. I am waiting for the release to do the blog post it will confuse people if "the blog post isn't true yet". It is quite a bit, but here's what it looks like:

First of all, the DiffEq was appended to everything for sake of naming. You can see the naming discussions in METADATA with Tony on ParameterEstimation.jl not being appropriate because it's DiffEq related, so DiffEqParamEstim.jl was suggested by @musm, etc. A general naming scheme was developed: DiffEq* for add-on components, *DiffEq for solvers (they also just read better like that, DiffEqDevTools and OrdinaryDiffEq). This is what Tony agreed to and what we went with.

All of these do use the entire DiffEq ecosystem (they use solve on an ODEProblem, not anything specific to them). Most are not a work-in-progress, already fully functional and registered (indeed, most were parts of DifferentialEquations.jl before the modularization). This is part of why I wrapped all the other algorithms into DifferentialEquations.jl! You can use parameter estimation tools on any DifferentialEquations.jl (well, OrdinaryDiffEq.jl) algorithm, which includes the algorithms for ODE.jl's PR49, Sundials, ODEInterface, etc. Of course, there are some hiccups in there. For example, I explained earlier that PR49 and the others don't support ForwardDiff directly onto the solver, and so build_lsoptim_objective won't work for the non-native OrdinaryDiffEq.jl algorithms. You can find other hiccups in there, whereas I know that the OrdinaryDiffEq.jl algorithms are fully compatible.

• DifferentialEquations.jl is becoming a metapackage which re-exports the functionality of the whole ecosystem. Thus it does "what the docs can do" and isn't truly going to be a package after the switch occurs.
• The *DiffEq.jl packages include native algorithms and wrappers. It places everything into one interface. The discussion of ODE/DAE solver interface #5 gives a way so that way the wrapper part won't be necessary: they should "just have" this same top-level interface (even if it isn't the main one). Currently, there's no way to plug in just via dispatch, so I need to fix up how this is done and then I'll get Sundials in line (ODEInterface might need another package in the middle).
• The DiffEq* add-on packages work with all of the available algorithms to an extent because they are all wrapped together. This gives:
  • Sensitivity analysis. It builds the sensitivity ODE directly from the ParameterizedFunction, which can be used in OrdinaryDiffEq.jl. Any algorithm should work here.
  • Parameter Estimation. It builds a parameter estimation objective function from a ParameterizedFunction. Most algorithms should work on the algorithms which don't require ForwardDiff (as in, ForwardDiff on the objective function, and the objective function is the solving of an entire ODE. This is tough to support and only OrdinaryDiffEq.jl's native algorithms support this right now)
  • DiffEqBifurcate.jl. This does bifurcation plotting directly off of a ParameterizedFunction. It uses the PyDSTool.jl wrapper (also in JuliaDiffEq). It doesn't use any other solvers because PyDSTool is weird: it wants a string for what the differential equations are and not a function (because it's Python 2 and they are metaprogramming / writing C-code by writing strings... looking at their code makes you love Julia...)
  • DiffEqUncertainty.jl and DiffEqOptimalControl.jl are WIP. They will be for quite awhile, and should already say so on the README. They will, of course, do uncertainty quantification and optimal control by plugging into the rest of the ecosystem (and developing wrappers for things like PODES). If someone else wants to do this first, the other "add-on" components show exactly how to make use of DE solvers to easily implement the algorithms.
  • The *Models.jl packages are for more easily building problems. For example, FinancialModels.jl builds SDEProblems to be solved by StochasticDiffEq.jl, where these problems are specified in a more mathematical finance way (i.e. specify a HestonProblem, and DE will interpret that as an SDE and solve it). The full power will come when it can also interpret the SDE as a PDE, and apply an FDM Forward Kolmogorov solver. MultiScaleModels.jl... that's my baby. You can read up on it, but it seems hard to explain until I have an example. I was finally about a week ago able to explain what this can do to my advisor, which has turned Julia from a side project to a main project with a MultiScaleModels at the center. So this will be well-developed with examples in no time. For now, just think of it as making arrays.
• Then there are extras.
  • DiffEqDevTools.jl does convergence testing and benchmarking.
  • DiffEqDocs.jl holds the DE documentation. I was going to keep that in DifferentialEquations.jl, but with all of the stuff it ends up being 700MB, so I had to isolate that... this stays unregistered
  • DiffEqTutorials.jl holds Jupyter notebook tutorials. Also not registered. The only reason why it's DE-centric is because, well I wrote it and didn't have reason to not make that so? I do use ODE.jl, ODEInterface.jl, and Sundials.jl at least in one of the notebooks. I moved this out both for size, and because it should make it easier for others to contribute notebooks. Feel free to add a section on ODE or Sundials or whatnot.
  • DiffEqBenchmarks.jl holds a bunch of benchmarks. Also not registered. I am testing a whole lot because, as I might've mentioned before, I am doing research in methods for SDEs (specifically Runge-Kutta methods) and so I am using knowledge from ODEs as a starting point. This is the main reason why I made OrdinaryDiffEq.jl so comprehensive: I wanted to play with them! You can see a write-up on 5th order methods here. A full list of algorithms which were tested is here. (this is slightly out of date, 6-9 should all be Verner) So there's definitely no shame that the DE algorithms benchmark so well: I put quite a bit of research into them! I'll get around to benchmarking other things soon (probably next might be SDE methods, then after wrapping DASSL I'll do DAE methods).

---

Review

Maybe moving the DiffEq.jl packages out to a different group and then moving them back one by one, with a proper review process, would be an option?

If you're willing to review them, start reviewing them and leave issues. Some of these add-ons are newer, others have been there for months without anyone choosing to "review" them (well, there have been issues filed by users, and Gitter chats. That's a form of review that shouldn't be discounted). Personally, I really dislike this idea that something has to be "reviewed" by some other developer even when no other developer is around to do it or wants to take the time to do it. It's been a few days, what do you think is the solution to PyDSTool's reference counting issue? What do you think of the approach LsqFit results in DiffEqParamEstim? It's not like these things are secret: there's are issues (check PyCall, Optim, LeastSquaresOptim, etc.) and days of Gitter chats (check the JuliaLang log) devoted to them. I understand if you don't have time, most people don't/wont make the time because this isn't what they are doing or want to do.

In addition, a lot of the large changes were asked for by users, and many of the APIs were agreed on in discussions with others. These discussions have all been open and public (the only non-public discussions I will mention later), so again, you could have put in your input like many others have. And "post-publication review" is still an option: leave an issue. However, I hope it's quite clear that I am staunchly against halting development for you to review when you clearly don't want to put the time and effort into doing so (which is fine, I understand that we all have limited hours in a day!).

This is why I stay away from contributing to Base and "public packages" in the first place: people tend to be more willing to say that they will do work and "help bikeshed" than they are to review code and fix up their PRs. Instead of just pushing through that, I think we should organize to accommodate this. That transitions nicely into the main point about organizational structure...

[ChrisRackauckas]

This next part is significant enough I want it to be its own post:

Organizational Structure

I propose a distributed organizational structure, akin to what's truly worked in JuliaStats, following the example of how Amal.jl turned out in JuliaMath and others, and following the path that JuliaML is heading (if not explicitly, see their Roadmap). The structure is as follows:

Common Interface

A common distributed interface. Something like the DE solve interface, with some modifications (tspan in the problem object, etc.). See #5. We're working on it (indeed @mauro3 that last suggestion still isn't general enough, and the defaults are not quite sane, but I think it's pointing in a direction where I can get there. I'll have a prototype together soon enough). I say distributed interface as a phrase for the fact that it won't be "top-down imposed". With OrdinaryDiffEq.jl, I explicitly wrap each component package. With the distributed interface, there will be a well-documented way for you do "plug into the ecosystem"- you define a solve method and now your algorithm is available to all who use alg = ... or whatnot. I will then setup this distributed interface with Sundials.jl and ODE.jl, and have a wrapper over ODEInterface.jl (I'm not sure he's going to cooperate... but it's okay we can work around that and just wrap it). You can handle PR49 (it shouldn't be much work).

Package-Oriented Development, Distributed Maintenance

The reason why the interface matters is for this goal. Differential equations is a huge subject. What I want to do is encourage everyone to to contribute their work to the ecosystem. Traditionally this has meant contributing to a public package (ODE.jl or DifferentialEquations.jl). However, this heavily discourages non-developers, and the primary researchers are likely not software developers.

I want to encourage others to make/contribute packages, even if they do one thing. If your one thing is exponential Runge-Kutta methods, or a certain type of PDE, I encourage you to make a separate package and have it plug into the ecosystem through the interface. That way, anyone who uses the DiffEq ecosystem has a choice to use your algorithms! The deal here is that, if one transitions to JuliaDiffEq, one gets to keep full admin controls and "final say". The JuliaDiffEq members only are allowed to perform maintenance (i.e. update the tests to be the right releases, fix how things compile, fix depwarns) without review: the rest is all has to go through "whoever's in charge". For accepting this, you get first-class status in the DE universe. Many reasons for this any I think it's a good agreement for both sides:

• As noted earlier from before, for most of these things if we're waiting for review from others it's just never going to happen
• I hope we get (more) packages where it's someone's specialty: the only person who knows the algorithm well is the person who wrote it (soon see the adaptive SDE parts and new algorithms that will be made public soon after this paper is published). For that reason we should allow more executive control
• I think it's great for people to publish algorithms and add them to the ecosystem! Publish the algorithm, make a package, plug into the ecosystem, and we can help you maintain it, and everyone can use it! With a few publications actually coming up soon, I'll be putting together a page for how to cite in the documentation
• By allowing for DiffEq members to perform maintenance, this will "keep them up to date". I want to include as many algorithms as possible in DifferentialEquations.jl, but I don't want depwarns or precompilation errors. I can fix these without touching the core algorithms, which will help those who are less familiar with the full Julia package ecosystem maintain a package in JuliaDiffEq
• In exchange for joining the ecosystem and agreeing to maitanance, it will join the DifferentialEquations.jl metapackage (in most cases, there are some edge cases like ParameterizedFunctions.jl which may need to be isolated for compilation concerns) and be documented together. A good example of the metadocumentation already exists with the ODE solvers. All of the supported algorithms are listed (I should include special install procedures as necessary). Of course, it's still in a package which you control.
• The "default algorithm" algorithm is explained to help people choose the algorithm (this is being developed. This is why there's loads of tests in DiffEqBenchmarks to put this together. It will allow for a default algorithm which does things like, if the tolerance is between 1e-6 and 1e-2, use Tsit5, or lower tolerances choose Vern6 or Vern7. It will allow someone to specify "this problem is stiff, and I want an error like 1e-6 with a high order interpolation, and solve it using some Julia-specific number type" and have it choose an algorithm for you (through something like identifiers=[:stiff,:interpolate,:juliatypes]). This is because, with Julia, we have finally gotten beyond "ease of choice" which was available in MATLAB: in the summer I added over 100 algorithms at C/Fortran speeds (Julia is just too amazing!)! Instead of requiring that you "know the algorithms" (I'd assume that anyone who isn't me or Peter Stone isn't familiar with more than half of those Runge-Kutta methods), we just use input on what type of problem it is and point the solver to the right algorithm.

A good example is DASSL.jl. I am quite unfamiliar with DAEs and don't plan on touching them very much, but the AlgebraicDiffEq.jl interface is what I hope to see as the distributed DAE interface. Then you can have your DASSL.jl, and have it plug into the common interface, and people can easily choose the algorithm if they please. You can even keep your name on it, and choose how people cite it. On the other hand, now that it's been transferred, I will help maintain it: update the tests to v0.5, get rid of depwarns, and keep it up-to-date (but not touch the core algorithm except through PRs). When it's there and plugs into the common interface, I'll add it to the DifferentialEquations.jl metapackage. Then it will be ready for testing: DiffEqBenchmarks.jl will test against the other wrapped DAE solver packages (currently just Sundials.jl) to determine a way for algorithm defaults.

I hope that this organizational structure helps pull in people who "just want to do their thing", and make the sum of their things "the thing". That said, there's one last pressing question

The Status of Public-ness

• DifferentialEquations.jl will be more public. In the metapackage README and docs, I have already removed my name from the introduction line. This project has grow far beyond me and what I had originally envisioned, and this change reflects that. As a metapackage, it will document together the JuliaDiffEq ecosystem as one coherent idea, and point out who to cite for what parts. I will still be maintaining an element of control over it (and have a paper in review about it, well, about the ecosystem around it), mostly because I don't think there's anyone else with full knowledge of the ecosystem, and in general it needs the ability to have quick changes (if package A is causing precompilation errors, I will disable it immediately). That said, as mentioned earlier, there will be a well-defined interface for inclusion.
• Many of the "add-on" packages will be in a similar quasi-public state. The reason is that these tend to be an interface as well: DiffEqParamEstim is actually a very small code which links the ODE solvers to optimization and machine learning objective/cost functions. People will be able to contribute a function which links the DiffEq-universe's functionality to their package. A good example for this is DiffEqBifurcate.jl. It (will) have a function for bifurcation plotting, which takes in a ParameterizedFunction. It then can use PyDSTool.jl as a backend for doing the actual analysis by passing it the right values, and anyone could add their own backend. This will allow people who do research in parameter estimation, uncertainty qunatification, etc. to get the ODE/SDE/DAE/DDE/PDE solvers "for free", and in exchange DifferentialEquations.jl will have a more expansive ecosystem. These add-on packages are documented with DifferentialEquations.jl to act pretty much seamlessly (see DiffEqDocs.jl for how this has already started).
• My solver packages (*DiffEq) will be in the quasi-private state: all PRs go through me. This allows me to keep my rapid development going, keep adding private/unpublished algorithms as necessary (try reviewing that!), and allow me to use these as a base for citation. This is no different than the other add-on packages. I assume you'll want the same for DASSL.jl and PR49?
• Current public packages (ODE.jl, Sundials.jl) will stay that way. PRs with reviews by two DiffEq members seems to be how it's been informally working, we can write down and agree to certain rules if you like. They will be plugged into the common interface (as they already kind of are). Note that I don't plan on working on ODE/Sundials much (beyond adding the common interface to it directly), but will help with review and maintenance. In general I don't see much of a reason to rely on C/Fortran algorithms when we can beat them in terms of both performance and features with native Julia algorithms, but Sundials is good to test against, and ODE.jl is far more accessible than anything else we have (it will be a good way to show how to plug into ecosystem!)
• One important point to note is that there will be "duplicates allowed". If someone else makes a set of SDE solvers, it's perfectly fine to have that plug into the common interface and join the group. I won't "reject" people for taking a new direction with these things: sometimes it's very necessary (but there are cases where it's just silly: you can't just fork someone's project and change 2 lines). However, the defaults and recommendations will be based off of testing: just because an algorithm exists doesn't mean it's recommended or set as a default in any case. Those algorithms will still be tested and documented. And who knows, they may just be a step away from improving. I think this is a fair middleground between "top-down designated winners" and a bottom-up "anything goes" approach.

---

My Path

I think that this structure will help pull the distributed efforts together, while still letting me do my thing. One other thing I want to note is the commitment to playing nice. I know that in some sense as a developer in ODE, you saw me spring to life in the Julia-sphere and rampage through. I'm sorry I didn't start using Julia sooner. That said, I think the best thing to do is to be clear with any and all recommendations, and I should help other developers know how to satisfy these.

So I want to be clear that the "standard ODE solvers" are a bad showing of what I am planning on doing: I went through and re-built them from scratch to have the best possible performance I could benchmark, and the set of features necessary for an expansive ecosystem (for usage as the base for DDE solvers, usage in bifurcation plotting and parameter estimation, backends for PDE solvers, etc.). Thus I spent the summer perfecting these implementations because of how important these are. Because of this, I know the benchmarks and feature-differences vs PR49/Sundials/ODEInterface, and know that I can only recommend the OrdinaryDiffEq implementations for non-stiff ODEs (ODEInterface and Sundials have some advantages for stiff ODEs, see below). I know that in some ways it almost looks like it invalidates the work of PR49, but I think it was pretty clear that the only way to show people my whole vision and why each part was important was to, well, just do it!

That said, in order to not step on any toes, I think it will be helpful for me layout my "warpath". Here's what I have set out in-front of me for the next 6 months or so:

• New RK methods for SDEs
• Implicit RK methods for ODEs
• Implicit/Explicit methods for ODEs (IMEX)
• Getting the SDE suite up to speed with ODEs (event handling, adaptive stepping, etc)
• Exponential integrators for ODEs
• Exponential integrators for SDEs
• Get DiffEqBifurcate to stop segfaulting
• Stochastic Poisson and Heat equations (FDM)
• Integrating the SDE solvers with the Forward Kolmogorov PDEs
• MultiScaleModels.jl
• ParameterizedFunctions? These should be complete as of last night

(of course, message me if you want to take on one of these and don't want to double up development efforts!) and lower in my priority list:

• Building DDE solvers from the ODE solvers
• Maybe add global sensitivity analysis?
• Adams, NDF, BDF methods for ODEs
• Enhancing DiffEqParamEstim.jl to use the JuliaML suite
• GPU/Xeon Phi - compatible solvers for PDEs

What I also need to do is clearly document "how to develop algorithms fully compatible with the DiffEq ecosystem". As mentioned in the Gitter chat, this isn't necessarily easy:

• Dealing with Unitful numbers requires keeping all of the constants non-unit-ed, and the rateTypes separate from the solution types. There are a bunch of tricks required if you want to do this without adding a Unitful dependency.
• Dealing with arbitrary arrays requires more than full compatibility with OffsetArrays.jl. I should document the issues involved and clearly delineate "amounts of compatibility", with being fully MultiScaleModels.jl-compatible as a very far end.
• Performance. Pre-caching, auto-SIMD, etc. I've blogged about of bunch of this before, but it could help to have one DiffEq specific

It's perfectly fine for algorithms to be compatible with only some of this. The documentation can be Plots.jl-like. Full support is recommended to be, well, recommended. However, I want to encourage all contributions because, in the full realm of DiffEqs, who knows what'll be useful to you?

[mauro3]

@ChrisRackauckas: thanks for taking the time to write this up. A good plan. Thanks a lot for putting so much effort into this!

Just a few minor thoughts/remarks:

• I like your ideas on "The Status of Public-ness".
• It would be good to have a battery of tests which can establish which level of compatibility a solver has. This is probably on your list.
• What is the reason you split the ODE and DAE solvers into two packages? If anything, isn't the split more explicit vs implicit methods, with most implicit methods easily adaptable to handle DAEs? It doesn't really matter, except that the interface (ODE/DAE solver interface #5) should work for both.

[ChrisRackauckas]

It would be good to have a battery of tests which can establish which level of compatibility a solver has. This is probably on your list.

Yes. I need to find out how to use testsets so that way the tests will display the compatibility, so it more open than just "hidden knowledge". When I say something is supported, I always have a barrage of tests for it. So for units, I have something like this: https://github.com/JuliaDiffEq/OrdinaryDiffEq.jl/blob/master/test/units_tests.jl#L37 . Each of the features has something similar. Here you see that tests pass on any non-implicit algorithm: this is because NLsolve isn't units-compatible. Since all of the algorithms have this common interface, it's easy to just loop through and see what throws errors with rational timesteps, what throws errors with units, what isn't ForwardDiff-able, etc (though, after programming these things, it's pretty clear in advance what will be compatible and what won't be. You have to pretty far out of your way to make some of these things compatible, since even for most standard operations something like Unitful numbers will still throw errors).

What is the reason you split the ODE and DAE solvers into two packages? If anything, isn't the split more explicit vs implicit methods, with most implicit methods easily adaptable to handle DAEs?

They can be the same solver, but I think it's clear this should be developer-burden, not user-burden. To a user, a DAE is a problem defined by a function f(t,u,du,out) where out is the residual at each step (so this is written in-place), and has two initial conditions: u0 and du0. This is different from an ODE which is defined as f(t,u,du) with u0.

I think it's clear that we shouldn't make ODEs defined by f(t,u,du,out) since, while technically ODEs are a subset of DAEs, they are a very important subset which also will have a lot of users who won't be familiar with what a DAE is. So on the user side, ODEs != DAEs.

But on the developer side, there can be tons of interactions between solvers for different types of equations (in fact, this very idea is what DifferentialEquations as a suite was made for). So for example, DASSL.jl is essentially a BDF method. One can implement a BDF method for ODEs by:

• Take in an ODEProblem
• Use this ODEProblem to define a DAEProblem
• Solve that DAEProblem with DASSL
• Return the solution

Since closures are compiled in Julia now, I think you can just define f(t,u,du,out) using the function in the ODEProblem, and I think it should essentially ignore the initial condition on du? I am not as familiar with DAEs, but that sounds about right. Then you just expose this method through the common interface, and to users it's just a "good for stiff equations" method, where the true implementation as a DAE solver exists in documentation but doesn't need to be highlighted to the user.

This is already something happening in the ecosystem. I am building delay differential equation methods (DDEs) by building an ODEProblem (and using the interpolant and event handling of ODEs). I will be re-doing the PDE methods to build ODEs and use the ODE solvers. SDE solvers can make PDEs which solve using the ODE solvers. Etc. Building the problem types is super cheap since you're usually not copying anything: you're just setting another pointer to the same initial condition, building a new function. This cross-compatibility is all already built in (it was the leading design constraint), but it's developer-side, not user-side. I think that's the right way to handle it, unless you have a really good counterargument. Savvy users might just need a few examples in the ecosystem.

---

Extra stuff.

BTW, let me know if you guys plan on tackling this "native Julia BDF" thing. I'll take it off my list if you aren't. I'm not too familiar with implementing BDF methods so it would be quite a bit of work for me (and it's not clear to me how they generalize well to SDEs, which reduces my interest). It would be something I'd be interesting having multiple different implementations of too: there's so many ways to do it, it's hard to know what's good! But I really don't want to take the time to give it a shot right now: not for another year or so at least.

Instead of BDF methods, I'm doubling down on Rosenbrock methods. This is because ParameterizedFunctions can let me symbolically pre-calculate things like the Jacobian and inverse W, and because explicit methods seem to be required in order to handle some of the wackiest Julia types. I think this would be a good way to split work, and the Rosenbrock methods should come out to be a good stiff workhorse with the BDF methods taking the lead for when the function evaluations cost more. But who knows: being able to mix all of these ways of implement (using symbolic calculations on ASTs, automatic differentiation, etc.) really throws all of the old rules out the window. I think that the methods which most effectively makes use of the Julia package ecosystem will really shine and be far better than even LSODE/CVODE/Radau!

[pwl]

@ChrisRackauckas thanks for a great write up, this is basically what I meant by a review. Maybe I somehow missed it but I have never seen any discussion in JuliaDiffEq or any Roadmap issue about splitting up DifferentialEquations.jl, hence my concern. Even a simple issue announcing what you are planning to do would be enough and give people chance to react. You mention Gitter chat but it is not something you can follow and browse in an organized fashion, and the discussion in METADATA is another example of information being publicly accessible but not easy to find (I guess you meant JuliaLang/METADATA.jl#6915).

I'm only saying this from my perspective. Even if I currently don't have the time to contribute It doesn't mean I don't try to follow the discussions, and some of these decisions escaped me. Admittedly I haven't been following SciML/DifferentialEquations.jl#59, where the discussion/announcement seemed to have taken place but I still believe there should be at least a short note or a link in the Roadmap. I would love to see more transparency in the future, otherwise what is an organization good for? Don't get me wrong, I'm not suggesting stricter control over the packages or some such, but this is a huge change that would likely go under my radar if I didn't complain about the multitude of new "DiffEq" packages (which makes more sense to me after your explanations).

As for the organizational changes I mostly agree with your basic ideas but I will have to catch up with the details on the interface design. As you said, this would invalidate the work we done in PR49, which I personally hoped to become the new standard interface for implementing the basic solvers. PR49 was never about implementing newer or faster solvers but more about designing a flexible and simple interface, so if the plan is to wrap it up with another layer of interfaces anyway, then maybe there no point in having PR49 at all. But this is the topic for #5.

[ChrisRackauckas]

Admittedly I haven't been following SciML/DifferentialEquations.jl#59, where the discussion/announcement seemed to have taken place but I still believe there should be at least a short note or a link in the Roadmap. I would love to see more transparency in the future, otherwise what is an organization good for?

Yes, in retrospect I probably should've noted more "roadmap" discussions in this roadmap.

SciML/DifferentialEquations.jl#47
SciML/DifferentialEquations.jl#59

Things happen fast though: you can see that I said wasn't going to do this until Pkg3 since the Juleps just came out, and 5 days later I did it because I found the time.

PR49 was never about implementing newer or faster solvers but more about designing a flexible and simple interface, so if the plan is to wrap it up with another layer of interfaces anyway, then maybe there no point in having PR49 at all.

Let's take this over to #5 (comment).

[ChrisRackauckas]

I think this has concluded.