|
1 | 1 | # PDESystem
|
2 | 2 |
|
3 |
| -`PDESystem` is still a work in progress. |
| 3 | +`PDESystem` is the common symbolic PDE specification for the SciML ecosystem. |
| 4 | +It is currently being built as a component of the ModelingToolkit ecosystem, |
| 5 | + |
| 6 | +## Vision |
| 7 | + |
| 8 | +The vision for the common PDE interface is that a user should only have to specify |
| 9 | +their PDE once, mathematically, and have instant access to everything as simple |
| 10 | +as a finite difference method with constant grid spacing, to something as complex |
| 11 | +as a distributed multi-GPU discrete Galerkin method. |
| 12 | + |
| 13 | +The key to the common PDE interface is a separation of the symbolic handling from |
| 14 | +the numerical world. All of the discretizers should not "solve" the PDE, but |
| 15 | +instead be a conversion of the mathematical specification to a numerical problem. |
| 16 | +Preferably, the transformation should be to another ModelingToolkit.jl `AbstractSystem`, |
| 17 | +but in some cases this cannot be done or will not be performant, so a `SciMLProblem` is |
| 18 | +the other choice. |
| 19 | + |
| 20 | +These elementary problems, such as solving linear systems `Ax=b`, solving nonlinear |
| 21 | +systems `f(x)=0`, ODEs, etc. are all defined by SciMLBase.jl, which then numerical |
| 22 | +solvers can all target these common forms. Thus someone who works on linear solvers |
| 23 | +doesn't necessarily need to be working on a DG or finite element library, but |
| 24 | +instead "linear solvers that are good for matrices A with properties ..." which |
| 25 | +are then accessible by every other discretization method in the common PDE interface. |
| 26 | + |
| 27 | +Similar to the rest of the `AbstractSystem` types, transformation and analyses |
| 28 | +functions will allow for simplifying the PDE before solving it, and constructing |
| 29 | +block symbolic functions like Jacobians. |
| 30 | + |
| 31 | +## Constructors |
| 32 | + |
| 33 | +```@docs |
| 34 | +PDESystem |
| 35 | +``` |
| 36 | + |
| 37 | +### Domains (WIP) |
| 38 | + |
| 39 | +Domains are specifying by saying `indepvar in domain`, where `indepvar` is a |
| 40 | +single or a collection of independent variables, and `domain` is the chosen |
| 41 | +domain type. Thus forms for the `indepvar` can be like: |
| 42 | + |
| 43 | +```julia |
| 44 | +t ∈ IntervalDomain(0.0,1.0) |
| 45 | +(t,x) ∈ UnitDisk() |
| 46 | +[v,w,x,y,z] ∈ VectorUnitBall(5) |
| 47 | +``` |
| 48 | + |
| 49 | +#### Domain Types (WIP) |
| 50 | + |
| 51 | +- `IntervalDomain(a,b)`: Defines the domain of an interval from `a` to `b` |
| 52 | + |
| 53 | +## `discretize` and `symbolic_discretize` |
| 54 | + |
| 55 | +The only functions which act on a PDESystem are the following: |
| 56 | + |
| 57 | +- `discretize(sys,discretizer)`: produces the outputted `AbstractSystem` or |
| 58 | + `SciMLProblem`. |
| 59 | +- `symbolic_discretize(sys,discretizer)`: produces a debugging symbolic description |
| 60 | + of the discretized problem. |
| 61 | + |
| 62 | +## Boundary Conditions (WIP) |
| 63 | + |
| 64 | +## Transformations |
| 65 | + |
| 66 | +## Analyses |
| 67 | + |
| 68 | +## Discretizer Ecosystem |
| 69 | + |
| 70 | +### NeuralPDE.jl: PhysicsInformedNN |
| 71 | + |
| 72 | +[NeuralPDE.jl](https://github.com/SciML/NeuralPDE.jl) defines the `PhysicsInformedNN` |
| 73 | +discretizer which uses a [DiffEqFlux.jl](https://github.com/SciML/DiffEqFlux.jl) |
| 74 | +neural network to solve the differential equation. |
| 75 | + |
| 76 | +### DiffEqOperators.jl: MOLFiniteDifference (WIP) |
| 77 | + |
| 78 | +[DiffEqOperators.jl](https://github.com/SciML/DiffEqOperators.jl) defines the |
| 79 | +`MOLFiniteDifference` discretizer which performs a finite difference discretization |
| 80 | +using the DiffEqOperators.jl stencils. These stencils make use of NNLib.jl for |
| 81 | +fast operations on semi-linear domains. |
0 commit comments