Skip to content

Commit 56e5844

Browse files
Merge pull request #1600 from stillyslalom/patch-1
Fix minor typos
2 parents 28b36c8 + f238262 commit 56e5844

File tree

1 file changed

+3
-3
lines changed

1 file changed

+3
-3
lines changed

docs/src/systems/PDESystem.md

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -8,7 +8,7 @@ It is currently being built as a component of the ModelingToolkit ecosystem,
88
The vision for the common PDE interface is that a user should only have to specify
99
their PDE once, mathematically, and have instant access to everything as simple
1010
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.
1212

1313
The key to the common PDE interface is a separation of the symbolic handling from
1414
the numerical world. All of the discretizers should not "solve" the PDE, but
@@ -20,12 +20,12 @@ the other choice.
2020
These elementary problems, such as solving linear systems `Ax=b`, solving nonlinear
2121
systems `f(x)=0`, ODEs, etc. are all defined by SciMLBase.jl, which then numerical
2222
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
2424
library, but instead "linear solvers that are good for matrices A with
2525
properties ..." which are then accessible by every other discretization method
2626
in the common PDE interface.
2727

28-
Similar to the rest of the `AbstractSystem` types, transformation and analyses
28+
Similar to the rest of the `AbstractSystem` types, transformation and analysis
2929
functions will allow for simplifying the PDE before solving it, and constructing
3030
block symbolic functions like Jacobians.
3131

0 commit comments

Comments
 (0)