Merge pull request #633 from ArnoStrouwen/LT

[skip ci] LanguageTool2

Author: ChrisRackauckas

docs/src/solvers/benchmarks.md

@@ -4,5 +4,7 @@ Benchmarks for the solvers can be found at
 [benchmarks.sciml.ai](https://docs.sciml.ai/SciMLBenchmarksOutput/stable/).
 The source code can be found at
 [SciMLBenchmarks.jl](https://github.com/SciML/SciMLBenchmarks.jl).
-Many different problems are tested. However, if you would like additional problems to be benchmarked, 
-please open an issue or PR at the SciMLBenchmarks.jl repository with the code that defines the DEProblem.
+A variety of different problems are already tested.
+However, if you would like additional problems to be benchmarked, 
+please open an issue or PR at the SciMLBenchmarks.jl repository
+with the code that defines the DEProblem.

docs/src/solvers/bvp_solve.md

@@ -1,12 +1,12 @@
 # BVP Solvers
 
-## Recomended Methods
+## Recommended Methods
 
-`GeneralMIRK4` is a good well-rounded method when the problem is not too large.
+`GeneralMIRK4` is a well-rounded method when the problem is not too large.
 It uses highly stable trust region methods to solve a 4th order fully
 implicit Runge-Kutta scheme. As an alternative on general `BVProblem`s, the
 `Shooting` method paired with an appropriate integrator for the IVP, such as
-`Shooting(Tsit5())`, is a flexible and efficient option. This will allow one
+`Shooting(Tsit5())`, is a flexible and efficient option. This allows one
 to combine callbacks/event handling with the BVP solver, and the high order
 interpolations can be used to define complex boundary conditions. However,
 `Shooting` methods can in some cases be prone to sensitivity of the boundary
@@ -22,6 +22,6 @@ improve the efficiency.
 
 - `Shooting` - A wrapper over initial value problem solvers.
 - `GeneralMIRK4` - A 4th order collocation method using an implicit Runge-Kutta
-  tableau solved using a trust region dogleg method from NLsolve.jl.
+  tableau, solved using a trust region dogleg method from NLsolve.jl.
 - `MIRK4` - A 4th order collocation method using an implicit Runge-Kutta tableau
   with a sparse Jacobian. Compatible only with two-point boundary value problems.

docs/src/solvers/dae_solve.md

@@ -2,7 +2,7 @@
 
 ## Recommended Methods
 
-For medium to low accuracy small numbers of DAEs in constant mass matrices form,
+For medium to low accuracy small numbers of DAEs in constant mass matrix form,
 the  `Rosenbrock23` and `Rodas4` methods are good choices which will get good
 efficiency if the mass matrix is constant. `Rosenbrock23` is better for low
 accuracy (error tolerance `<1e-4`) and `Rodas4` is better for high accuracy.
@@ -24,10 +24,10 @@ but still needs more optimizations.
 For all OrdinaryDiffEq.jl methods, an initialization scheme can be set with a
 common keyword argument `initializealg`. The choices are:
 
-- `BrownFullBasicInit`: For Index-1 DAEs implicit DAEs and and semi-explicit
+- `BrownFullBasicInit`: For Index-1 DAEs implicit DAEs and semi-explicit
   DAEs in mass matrix form. Keeps the differential variables constant. Requires
   `du0` when used on a `DAEProblem`.
-- `ShampineCollocationInit`: For Index-1 DAEs implicit DAEs and and semi-explicit
+- `ShampineCollocationInit`: For Index-1 DAEs implicit DAEs and semi-explicit
   DAEs in mass matrix form. Changes both the differential and algebraic variables.
 - `NoInit`: Explicitly opts-out of DAE initialization.
 
@@ -48,8 +48,8 @@ extra options for the solvers, see the ODE solver page.
 !!! note
 
     The standard Hermite interpolation used for ODE methods in OrdinaryDiffEq.jl
-    is not applicable to the algebraic variables. Thus for the following mass-matrix
-    methods, use the interplation (thus `saveat`) with caution if the default
+    is not applicable to the algebraic variables. Thus, for the following mass-matrix
+    methods, use the interpolation (thus `saveat`) with caution if the default
     Hermite interpolation is used. All methods which mention a specialized interpolation
     (and implicit ODE methods) are safe.
 
@@ -85,7 +85,7 @@ extra options for the solvers, see the ODE solver page.
 #### Rosenbrock-W Methods
 
 - `Rosenbrock23` - An Order 2/3 L-Stable Rosenbrock-W method which is good for very stiff equations with oscillations at low tolerances. 2nd order stiff-aware interpolation.
-- `Rosenbrock32` - An Order 3/2 A-Stable Rosenbrock-W method which is good for mildy stiff equations without oscillations at low tolerances. Note that this method is prone to instability in the presence of oscillations, so use with caution. 2nd order stiff-aware interpolation.
+- `Rosenbrock32` - An Order 3/2 A-Stable Rosenbrock-W method which is good for mildly stiff equations without oscillations at low tolerances. Note that this method is prone to instability in the presence of oscillations, so use with caution. 2nd order stiff-aware interpolation.
 - `RosenbrockW6S4OS` - A 4th order L-stable Rosenbrock-W method (fixed step only).
 - `ROS34PW1a` - A 4th order L-stable Rosenbrock-W method.
 - `ROS34PW1b` - A 4th order L-stable Rosenbrock-W method.

docs/src/solvers/dde_solve.md

@@ -28,7 +28,7 @@ that one uses `MethodOfSteps(Vern6())`. Benchmarks show that going to higher ord
 
 ### Stiff DDEs and Differential-Algebraic Delay Equations (DADEs)
 
-For stiff DDEs, the SDIRK and Rosenbrock methods are very efficient as they will
+For stiff DDEs, the SDIRK and Rosenbrock methods are very efficient, as they will
 reuse the Jacobian in the unconstrained stepping iterations. One should choose
 from the methods which have stiff-aware interpolants for better stability.
 `MethodOfSteps(Rosenbrock23())` is a good low order method choice. Additionally,
@@ -75,6 +75,6 @@ keyword arguments `abstol` and `reltol` when solving the DDE problem, and increa
 the maximal number of iterations by specifying the keyword argument `max_iter` in
 the `MethodOfSteps` algorithm, can help ensure that the steps are correct. If the problem
 still is not correctly converging, one should lower `dtmax`. For problems with only
-constant delays, in the worst case scenario, one may need to set `constrained = true` which
+constant delays, in the worst-case scenario, one may need to set `constrained = true` which
 will constrain timesteps to at most the size of the minimal lag and hence forces more
 stability at the cost of smaller timesteps.

docs/src/solvers/discrete_solve.md

@@ -15,7 +15,7 @@ to solve function maps, along with everything else like plot recipes, while
 completely ignoring the ODE functionality related to continuous equations (except
 for a tiny bit of initialization). However, the `SimpleFunctionMap` from SimpleDiffEq.jl
 can be more efficient if the mapping function is sufficiently cheap, but it doesn't have
-all of the extras like callbacks and saving support (but does have an integrator interface).
+all the extras like callbacks and saving support (but does have an integrator interface).
 
 ## Full List of Methods
 
@@ -24,7 +24,7 @@ all of the extras like callbacks and saving support (but does have an integrator
 - `FunctionMap`: A basic function map which implements the full common interface.
 
 OrdinaryDiffEq.jl also contains the `FunctionMap` algorithm which lets you 
-It has a piecewise constant interpolation and allows for all of the 
+It has a piecewise constant interpolation and allows for all the 
 callback/event handling capabilities (of course, with `rootfind=false`. If a 
 `ContinuousCallback` is given, it's always assumed `rootfind=false`).
 
@@ -49,10 +49,10 @@ u_{n+1} = u_n + dtf(t_{n+1},u_n).
 ```
 
 Notice that this is the same as updates from the Euler method, except in this
-case we assume that its a discrete change and thus the interpolation is
+case we assume that it's a discrete change and thus the interpolation is
 piecewise constant.
 
 ### SimpleDiffEq.jl
 
-- `SimpleFunctionMap`: A barebones implementation of a function map. Is optimally-efficient
+- `SimpleFunctionMap`: A bare-bones implementation of a function map. Is optimally-efficient
   and has an integrator interface version, but does not support callbacks or saving controls.

docs/src/solvers/dynamical_solve.md

@@ -22,7 +22,7 @@ The functions should be specified as `f1(dv,v,u,p,t)` and `f2(du,v,u,p,t)`
 specified by the solver), and `f2` is independent of `t` and `u`. This includes
 discretizations arising from `SecondOrderODEProblem`s where the velocity is not
 used in the acceleration function, and Hamiltonians where the potential is
-(or can be) time-dependent but the kinetic energy is only dependent on `v`.
+(or can be) time-dependent, but the kinetic energy is only dependent on `v`.
 
 Note that some methods assume that the integral of `f2` is a quadratic form. That
 means that `f2=v'*M*v`, i.e. ``\int f_2 = \frac{1}{2} m v^2``, giving `du = v`. This is
@@ -33,10 +33,10 @@ kinetic energy".
 
 ## Recommendations
 
-When energy conservation is required, use a symplectic method. Otherwise the
+When energy conservation is required, use a symplectic method. Otherwise, the
 Runge-Kutta-Nyström methods will be more efficient. Energy is mostly conserved
-by Runge-Kutta-Nyström methods, but is not conserved for long time integrations.
-Thus it is suggested that for shorter integrations you use Runge-Kutta-Nyström
+by Runge-Kutta-Nyström methods, but is not conserved for long-time integrations.
+Thus, it is suggested that for shorter integrations you use Runge-Kutta-Nyström
 methods as well.
 
 As a go-to method for efficiency, `DPRKN6` is a good choice. `DPRKN12` is a good
@@ -50,9 +50,9 @@ can be a good choice as it minimizes the number of evaluations.
 For symplectic methods, higher order algorithms are the most efficient when higher
 accuracy is needed, and when less accuracy is needed lower order methods do better.
 Optimized efficiency methods take more steps and thus have more force calculations
-for the same order, but have smaller error. Thus the "optimized efficiency"
+for the same order, but have smaller error. Thus, the “optimized efficiency”
 algorithms are recommended if your force calculation is not too sufficiency large,
-while the other methods are recommend when force calculations are really large
+while the other methods are recommended when force calculations are really large
 (for example, like in MD simulations `VelocityVerlet` is very popular since it only
 requires one force calculation per timestep). A good go-to method would be `McAte5`,
 and a good high order choice is `KahanLi8`.
@@ -67,7 +67,7 @@ page for more details.
 
 Unless otherwise specified, the OrdinaryDiffEq algorithms all come with a
 3rd order Hermite polynomial interpolation. The algorithms denoted as having a
-"free" interpolation means that no extra steps are required for the
+“free” interpolation means that no extra steps are required for the
 interpolation. For the non-free higher order interpolating functions, the extra
 steps are computed lazily (i.e. not during the solve).
 
@@ -79,10 +79,10 @@ steps are computed lazily (i.e. not during the solve).
   timestep only.
 - `IRKN4`: 4th order explicit two-step Runge-Kutta-Nyström method. Can be more
   efficient for smooth problems. Fixed timestep only.
-- `ERKN4`: 4th order Runge-Kutta-Nyström method which is integrates the periodic
+- `ERKN4`: 4th order Runge-Kutta-Nyström method which integrates the periodic
   properties of the harmonic oscillator exactly. Gets extra efficiency on periodic
   problems.
-- `ERKN5`: 5th order Runge-Kutta-Nyström method which is integrates the periodic
+- `ERKN5`: 5th order Runge-Kutta-Nyström method which integrates the periodic
   properties of the harmonic oscillator exactly. Gets extra efficiency on periodic
   problems.
 - `Nystrom4VelocityIndependent`: 4th order explicit Runge-Kutta-Nyström method.
@@ -112,7 +112,7 @@ Note that all symplectic integrators are fixed timestep only.
 - `CalvoSanz4`: Optimized efficiency 4th order explicit symplectic integrator.
 - `McAte42`: 4th order explicit symplectic integrator. (Broken)
 - `McAte5`: Optimized efficiency 5th order explicit symplectic integrator.
-  Requires quadratic kinetic energy
+  Requires quadratic kinetic energy.
 - `Yoshida6`: 6th order explicit symplectic integrator.
 - `KahanLi6`: Optimized efficiency 6th order explicit symplectic integrator.
 - `McAte8`: 8th order explicit symplectic integrator.

docs/src/solvers/nonautonomous_linear_ode.md

@@ -14,7 +14,7 @@ is for solvers to require state-independent operators, which implies the form:
 u^\prime = A(t)u
 ```
 
-Another type of solvers are needed when the operators are state-dependent, i.e.
+Another type of solver is needed when the operators are state-dependent, i.e.
 
 ```math
 u^\prime = A(u)u
@@ -42,7 +42,7 @@ page for more details.
 
 Unless otherwise specified, the OrdinaryDiffEq algorithms all come with a
 3rd order Hermite polynomial interpolation. The algorithms denoted as having a
-"free" interpolation means that no extra steps are required for the
+“free” interpolation means that no extra steps are required for the
 interpolation. For the non-free higher order interpolating functions, the extra
 steps are computed lazily (i.e. not during the solve).
 
@@ -61,10 +61,10 @@ Options:
     defined for the operator `A`.
   - :simple - uses simple Krylov approximations with fixed subspace size `m`.
   - :adaptive - uses adaptive Krylov approximations with internal timestepping.
-- `m` - integer, default: `30`. Controls the size of Krylov subsapce if
+- `m` - integer, default: `30`. Controls the size of Krylov subspace if
   `krylov=:simple`, and the initial subspace size if `krylov=:adaptive`.
 - `iop` - integer, default: `0`. If not zero, determines the length of the incomplete
-  orthogonalization procedure (IOP) [^1]. Note that if the linear operator/jacobian is hermitian,
+  orthogonalization procedure (IOP) [^1]. Note that if the linear operator/Jacobian is hermitian,
   then the Lanczos algorithm will always be used and the IOP setting is ignored.
 
 ```@example linear_ode
@@ -78,10 +78,10 @@ sol = solve(prob, LinearExponential())
 !!! note
 
     LinearExponential is exact, and thus it uses `dt=tspan[2]-tspan[1]` by default. The interpolation
-    used is inexact (3rd order Hermite). Thus values generated by the interpolation (via `sol(t)` or
+    used is inexact (3rd order Hermite). Thus, values generated by the interpolation (via `sol(t)` or
     `saveat`) will be inexact with increasing error as the size of the time span grows. To counteract
-    this, directly set `dt` or use `tstops` instead of of `saveat`. For more information, see
-    [this issue](https://github.com/SciML/OrdinaryDiffEq.jl/issues/1491)
+    this, directly set `dt` or use `tstops` instead of `saveat`. For more information, see
+    [this issue](https://github.com/SciML/OrdinaryDiffEq.jl/issues/1491).
 
 ### State-Independent Solvers
 
@@ -110,7 +110,7 @@ prob = ODEProblem(A, ones(2), (1.0, 6.0))
 sol = solve(prob,MagnusGL6(),dt=1/10)
 ```
 
-The initial values for ``A`` are irrelevant in this and similar cases as the `update_func` immediately overwrites them.
+The initial values for ``A`` are irrelevant in this and similar cases, as the `update_func` immediately overwrites them.
 Starting with `ones(2,2)` is just a convenient way to get a mutable 2x2 matrix.