AbstractPDEInterfaces.jl
A common interface for PDE solving
PDEs are messy: weird boundary conditions, moving domains, singular operators, you name it! And solvers more so with their discretization schemes, stability charectoristics, and performance tradeoffs. Not to mention the layers of complications added by the software stack, or computer architecture, or pre/postprocessing pipelines.
Numerical PDE problems drive highperformance computing. The biggest supercomputers on the planet run physics simulations on millions of MPI ranks over years of walltime. An optimized workflow is the difference between having a solution, or going home emptyhanded, and every ounce of performance has to be squeezed. As such, highly tuned software packages that specialize on a set class of problems dominate the market. With specializations, however, generalizability and interpoeratibility take a hit.
AbstractPDEInterfaces.jl
is written so that package authors won't need to write a method for Δ
(Laplacian) every time a new scheme for the gradient ∇
(gradient) comes along. We provides abstractions over components of PDE solvers that reduce the amount of boilerplate code that any new solver would need, and improve interpoeratibility between solvers. Furthermore, a requisite for the developement of Machine Learning based PDE solvers is the ability to mix state of the art discretizations with large neural network models on a ADcompatible, acceleratorfriendly testbench. Julia's multipledispatch based programming model allows for abstractlytyped, composable code, that lets packages just plugandplay. Engineers shouldn't waste their time reinventing the wheel, rather focus on what's new and interesting!
We believe switching from 'Fourierspectral collocation method' to 'discontinuous Galerkin finite elements' should be a oneline change for the user. And users should not need to deal with inconsistent syntax between solvers for specifying boundary conditions, and forming vectorcalculus operators.
Finally, AbstractPDEInterfaces.jl
is fully compatible with the SciML.ai
ecosystem, so after describing your problem, it should spit out the right BoundaryValuePDEProblem
or ODEProblem
that you can solve using the relevant DiffEq
package.
Abstract Interfaces
AbstractPDEInterfacess.jl
contains separate abstract interaces for multidimensional domains, vectorcalculus operators, and function spaces. It is general enough that anybody can plug in their discretizations (ie define an innerproduct operator, and gradient operator) and start solving boundary value problems, or timeevolution problems.
Once you plug in your discretizations, you can do a lot of cool things like apply any random deformations to the space. AbstractPDEInterfacess.jl translate all your vector calculus operators correctly. That means the same code could solve convection diffusion on a square as well as an annulus with no extra work and basically conserved accuracy.
AbstractDomain
interface
concrete types, Boundary tags
deform
 all the mapping stuff\otimes
concrete types
IntervalDomain
BoxDomain
AbstractSpace
interface
define these methods (grad, mass, common functions)
deform
\otimes
transform
AbstractDiscretization
interface
GalerkinProjection
Collocation
Operator interface  SciMLOperators.jl
BoundaryValueProblem
interface
Usually a rankdeficient systems
Associated Packages
Roadmap

AbstractDomain
interface Move concrete types to a separate package 
PDEDomains.jl
 Logically rectangular domains
 Deform domain
 Boundary tags
 Interior tags (for multiphase flows, conjugate heattransfer)
 Gordon Hall interpolation (transfinite interpolation)
 meshed domains
 signed distance geometries
 Timevarying domains
 Is it possibe to just use
DomainSets.jl
and add some metadata info?
 Move concrete types to a separate package 

AbstractField <: AbstractVector
interface  special array types Spectral polynomial (nothing special needed)
 transformbased spectral (fourier, cheby) (nothing special needed)
 Box/ full spectral elements

Operator interface  moved to
SciMLOperators.jl
 linear algebra operations
 lazy composition
 can use array reductions
 caching
 GatherScatter operator using
NNlib
 General interpolation operator on elementmeshes

Spaces

Deformed spaces

Tensor product spaces

transformed space

orthogonal polynomials 
NodalPolynomialSpaces.jl

Spectral with transforms
 Fourier 
FourierSpaces.jl
 Cosine/ Sine spaces
 Fourier 

Box, full spectral elements  create
SpectralElementSpaces.jl


Create a distinction between
Space
, andDiscretization
 Space is how to represent functions
 Discretization is how you form operators
 Rename "discretization" to "scheme" or "solve_scheme" or something. Because discretization is ambiguous. is it referring to spatial discretization? or time discretization? In this package we are using it as a "scheme" to form differential operators on a "discretized" space.
 Rename
Galerkin
>GalerkinProjection
for clarity  Flux handling in discontinuous galerkin/ finite volume
 all the shennanigans in stabalized finite elements

Boundary Condition interface (apply "this" boundary condition based on "that" domain boundary)
 Dirichlet
 Neumann
 Robin

Problems

Problem frontend with
ModelingToolkit.jl

Boundary Value Problems
 move boundary information to RHS
 dispatch to
LinearSolve.jl
 dispatch to
NonlinearSolve.jl
(afterLinearSolve.jl
,NonlinearSolve.jl
integration)

Timeevolution problems
 play nice with
OrdinaryDiffEq
 for implicit timesteppers, solve a BVP at every time step. impose boundary condition on the operator (wait for
SciMLOperators
,OrdinaryDiffEq
integration)  automatically spit out an ODEProblem
 play nice with
