My understanding is that DiffEqOperators is being replaced by the combination of SciMLOperators and MethodOfLines. My use case is exactly what DiffEqOperators served: all I want to do is define a matrix-free derivative operator on a grid. For example, I should be able to ask for a fifth order finite-difference operator on a 100x100 grid
However, the MethodOfLines interface as shown in tutorials seems a bit too high level for me (Solving the Heat Equation · MethodOfLines.jl): the differentials are defined symbolically and then the ODE is magically solved, but I never get my hands on a concrete differential operator. Does MethodOfLines.jl expose any functionality for me to get the concrete (not symbolic) differential operators, or is there another way to get the functionality of DiffEqOperators with the new tooling?
Unfortunately not, moving to the new symbolic paradigm was what it took to make the functionality general enough for arbitrary equations/BCs, and to do it quickly with ModelingToolkit automatic system simplification and performant code generation. There is no internal operator form in MOL as the package is completely equation based. There is no functionality that was in DEO that isn’t in MOL as far as stencil generation goes, it just lacks the intermediate operator form.
May I ask what problem you are using DEO for? There is almost certainly a way to do it that leverages MOL, and if its not faster/ better we’ll make this an active area of development until it is.
It is true that MOL suffers from a pathalogical compiler case at higher point count at present, but when this is solved (in progress right now) there will be nothing that isn’t faster with MOL.
I see – that makes sense. At the moment, I mostly just wanted a lower-level approach for discoverability / debugging. I basically wanted to be able to write my own f(du, u, p, t); i.e. have the formation of the things needed to write f be automated, but then write f myself and form my own ODEProblem, even if it’s not quite as optimized.
So not quite a real need yet. Although, I imagine that perhaps this could also come up as a real need in more advanced applications, where the user really wants to write some part of f themselves?
You can feed in arbitrary julia functions as bcs/ics/source terms, and we are in the planning stage for allowing users to define custom finite difference schemes and to have them automatically apply where relevant - so I don’t think there will be a case where directly writing the f is necessary, though I could be wrong.
Of course, if there is, you could always use the unexported generate_code to get the generated f out, and apply your edits manually.
Well the issue is that as cases get more complicated, the amount of things that can be expressed as an operator decreases. WENO, upwinding, etc. are not well-expressed as standalone operators. They need more information in order to act correctly, and to be optimal they need to fuse loops in different ways. It’s the operators that cannot scale to more difficult problems, not the symbolic form. This is most of the work is on MethodOfLines.jl
But they are doing different things, so we will have to see in practice how much is truly deprecated and truly left there. We don’t just delete things, so just like how ParameterizedFunctions.jl or DiffEqParamEstim.jl aren’t our highlighted libraries anymore, we keep them alive for people to use. Just like that, DiffEqOperators.jl will still be around. We will fully remove anything that’s in SciMLOperators and make the DerivativeOperators a SciMLOperator, that will fix up some of its issues. But the core push, all of the new features, will likely be in MethodOfLines.jl simply because the operator form has too many limitations that we want to overcome.