DifferentialEquations.jl 3.0 release post and a roadmap for 4.0

We at JuliaDiffEq are excited to release DifferentialEquations.jl 3.0. It was a systematic dismantling of a list of “what tasks should we really accomplish well?”. See this blog post for details:

The purpose of 3.0 was to take a step back and see what other DiffEq suites had, and build the best pieces of each of them. This resulted in the following comparison:

But post-3.0 this means we’ll have some new focuses. Our ODE/SDE/DDE solvers are quite complete, so there will be a minor focus in developing native versions of some pieces (BDF, radau, IMEX, exponential integrators), many of which we already have wrapped or would make great Google Summer of Code projects. My focus will likely (no guarantees) be based around development of modeling tools which utilize DifferentialEquations.jl and unique new algorithms for SDEs, along with fixing odds and ends of course.

But one major goal for 4.0 is finding out how to unify specification and interfaces for PDEs in Julia. I know that other people (such as @John_Gibson) are focused on solving PDEs. Each of the methods we create will do better/worse on different problems, and so what I want to have down during the next time frame is a method for specifying new PDEs and ways for authors to plugin new solvers for these PDE types (along with extra information required to make the solving efficient). Under this interface I hope we can build a more cohesive and comprehensive set of PDE solvers than what has been seen before, with the ability to “plug and play” different solver methods not only easing the entry for users, but also allowing methods researchers easily compare and benchmark methods. Please let me know if you have PDE solvers which should be taken into account. Thanks.

22 Likes

Great work and great post!

Sorry to play the pessimist here but I don’t see your angle on PDEs. The specification of a PDE is significantly more complex than an ODE, and I don’t see how you can easily share significant code between, say, a steady state CFD finite volume code in a complex geometry and a time-dependent Schrödinger solver with a spectral method. So do you want to do a JuMP for PDEs (specification only, and leave it to plugins to see if they can be applicable), or do you want a generic PDE solver that tries to solve anything you throw at it (and is necessarily less efficient than a specialized implementation)?

I want to make the interface for the first and write the tools for the second (well, I will be writing things “specialized to semilinear (S)PDEs”, which for anything nonlinear will not be specialized enough of course). The second its clear how to do it. The first, yes I agree it’s not clear how to do it yet. But I want it. I want to have a PDE specified, and then you can choose between FDM method-of-lines method, or so-and-so’s spectral solver, etc… I’m not saying I have an answer, but I want a big focus to be coming up with something.

1 Like

I’m a specialized PDE solver kind of guy, and I have plans to write in Julia a spectral Navier-Stokes solver for a fixed geometry, but I agree with @ChrisRackauckas that there’s real potential for Julia to do something more general, flexible, and powerful for PDEs. Dedalus is a good example, but Julia has potential to do something better, I think. It’s definitely worth exploring.

If you end up implementing this, please do make it as modular as possible. Other methodologies for solving functional equations in general also use spectral methods, and it would be really nice to have a library that just

  1. evaluates a set of basis functions with the given coefficients,
  2. solves for the coefficients given values and a set of basis functions.

with 1. working smoothly with AD libraries. Having an optimized library for this for various bases (eg complete Chebyshev polynomials, splines, etc) would avoid duplicating effort.

2 Likes