Okay, I’ll make sure to ping you when I get there. I have a few grant proposals first, but I’ll be getting to writing a bunch very soon. One of the major moves in the next month will be documenting the full SciMLInterface (as a new repo). To standardize the symbolicification of various mathematical domains, we’re greatly expanded SciML’s problem/solve interface:
https://github.com/SciML/DiffEqBase.jl/blob/master/src/problems/basic_problems.jl
There’s NonlinearProblem, OptimizationProblem, etc. And then there’s a bunch of overarching solver libraries that give a unified interface to these descriptions, such as Quadrature.jl and GalacticOptim.jl. So what was “DiffEq Problems” now includes all of the core numerical algorithms with a related symbolic system type in ModelingToolkit, which allows for going back and forth between symbolic manipulations and numerical solving. The major goal here will be to have clear documentation showing the symmetries of the design and interface. While GalacticOptim.jl’s documentation is just “hey I am all optimization packages”, showcasing how optimization, differential equation solving, nonlinear solving, etc. all have the same design and how it couples to the symbolic interfaces has been challenging to document.
The next underlying issue is how to document the PDESystem interface. PDESystem now exists and is usable. If you write:
using NeuralPDE, Flux, ModelingToolkit, GalacticOptim, Optim, DiffEqFlux
using Plots
# 3D PDE
@parameters x y t
@variables u(..)
@derivatives Dxx''~x
@derivatives Dyy''~y
@derivatives Dt'~t
# 3D PDE
eq = Dt(u(x,y,t)) ~ Dxx(u(x,y,t)) + Dyy(u(x,y,t))
# Initial and boundary conditions
bcs = [u(x,y,0) ~ exp(x+y)*cos(x+y) ,
u(0,y,t) ~ exp(y)*cos(y+4t)
u(2,y,t) ~ exp(2+y)*cos(2+y+4t) ,
u(x,0,t) ~ exp(x)*cos(x+4t),
u(x,2,t) ~ exp(x+2)*cos(x+2+4t)]
# Space and time domains
domains = [x ∈ IntervalDomain(0.0,2.0),
y ∈ IntervalDomain(0.0,2.0),
t ∈ IntervalDomain(0.0,2.0)]
You can send that off to DiffEqOperators.jl for automated finite difference discretizations and solve, or send it off to NeuralPDE.jl for a physics-informed neural network solver.
These are all expected growing pains moving from JuliaDiffEq → SciML and taking on an expanding role of course. And most of the libraries are in place, so it’s just a big documentation effort at this point.
This is all on top of the fact that ModelingToolkit couples being a CAS with its role in symbolic-numerics. Of course, it makes complete sense for a symbolic-numerics system to be a CAS because then every CAS feature for eliminating variables and simplifying equations can be done on the equations you want to numerically solve, but fully documenting a CAS is hard, and making there be a clear understanding of this relationship is a bit harder, especially since in this case there isn’t really a clear analogue in other ecosystems to this full feature. For differential equation solvers it’s like “oh it’s like odeint but better”, but ModelingToolkit’s ODESystem? Well it’s like you deconstructed Dymola’s compiler into features of a SymPy-like CAS and then coupled it to a differential equation solver like CASADI and allowed special hooks into the numerical solvers for MTK-generated functions (features like plot(sol,vars=x) where x is a symbolic variable from ModelingToolkit). I’ve learned that description helps nobody, so it’s back to square one on that front.
]