@@ -8,7 +8,7 @@ It is currently being built as a component of the ModelingToolkit ecosystem,
8
8
The vision for the common PDE interface is that a user should only have to specify
9
9
their PDE once, mathematically, and have instant access to everything as simple
10
10
as a finite difference method with constant grid spacing, to something as complex
11
- as a distributed multi-GPU discrete Galerkin method.
11
+ as a distributed multi-GPU discontinuous Galerkin method.
12
12
13
13
The key to the common PDE interface is a separation of the symbolic handling from
14
14
the numerical world. All of the discretizers should not "solve" the PDE, but
@@ -20,12 +20,12 @@ the other choice.
20
20
These elementary problems, such as solving linear systems ` Ax=b ` , solving nonlinear
21
21
systems ` f(x)=0 ` , ODEs, etc. are all defined by SciMLBase.jl, which then numerical
22
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 Discontinuous Galerkin or finite element
23
+ doesn't necessarily need to be working on a discontinuous Galerkin or finite element
24
24
library, but instead "linear solvers that are good for matrices A with
25
25
properties ..." which are then accessible by every other discretization method
26
26
in the common PDE interface.
27
27
28
- Similar to the rest of the ` AbstractSystem ` types, transformation and analyses
28
+ Similar to the rest of the ` AbstractSystem ` types, transformation and analysis
29
29
functions will allow for simplifying the PDE before solving it, and constructing
30
30
block symbolic functions like Jacobians.
31
31
0 commit comments