[skip ci] docstring spelling

Author: ArnoStrouwen

docs/src/basics/AbstractSystem.md

@@ -10,14 +10,14 @@ model manipulation and compilation.
 ### Subtypes
 
 There are three immediate subtypes of `AbstractSystem`, classified by how many independent variables each type has:
-* `AbstractTimeIndependentSystem`: has no independent variable (eg: `NonlinearSystem`)
-* `AbstractTimeDependentSystem`: has a single independent variable (eg: `ODESystem`)
-* `AbstractMultivariateSystem`: may have multiple independent variables (eg: `PDESystem`)
+* `AbstractTimeIndependentSystem`: has no independent variable (e.g.: `NonlinearSystem`)
+* `AbstractTimeDependentSystem`: has a single independent variable (e.g.: `ODESystem`)
+* `AbstractMultivariateSystem`: may have multiple independent variables (e.g.: `PDESystem`)
 
 ## Constructors and Naming
 
 The `AbstractSystem` interface has a consistent method for constructing systems.
-Generally it follows the order of:
+Generally, it follows the order of:
 
 1. Equations
 2. Independent Variables
@@ -28,15 +28,15 @@ All other pieces are handled via keyword arguments. `AbstractSystem`s share the
 same keyword arguments, which are:
 
 - `system`: This is used for specifying subsystems for hierarchical modeling with
-  reusable components. For more information, see the [components page](@ref components)
+  reusable components. For more information, see the [components page](@ref components).
 - Defaults: Keyword arguments like `defaults` are used for specifying default
   values which are used. If a value is not given at the `SciMLProblem` construction
   time, its numerical value will be the default.
 
 ## Composition and Accessor Functions
 
 Each `AbstractSystem` has lists of variables in context, such as distinguishing
-parameters vs states. In addition, an `AbstractSystem` also can hold other
+parameters vs states. In addition, an `AbstractSystem` can also hold other
 `AbstractSystem` types. Direct accessing of the values, such as `sys.states`,
 gives the immediate list, while the accessor functions `states(sys)` gives the
 total set, which includes that of all systems held inside.
@@ -118,7 +118,7 @@ patterns via an abstract interpretation without requiring differentiation.
 
 At the end, the system types have `DEProblem` constructors, like `ODEProblem`,
 which allow for directly generating the problem types required for numerical
-methods. The first argument is always the `AbstractSystem`, and the proceeding
+methods. The first argument is always the `AbstractSystem`, and the proceding
 arguments match the argument order of their original constructors. Whenever an
 array would normally be provided, such as `u0` the initial condition of an
 `ODEProblem`, it is instead replaced with a variable map, i.e., an array of

docs/src/basics/Composition.md

@@ -109,7 +109,7 @@ u0 = [
 
 Note that any default values within the given subcomponent will be
 used if no override is provided at construction time. If any values for
-initial conditions or parameters are unspecified an error will be thrown.
+initial conditions or parameters are unspecified, an error will be thrown.
 
 When the model is numerically solved, the solution can be accessed via
 its symbolic values. For example, if `sol` is the `ODESolution`, one
@@ -281,7 +281,7 @@ When modeling, e.g., impacts, saturations or Coulomb friction, the dynamic
 equations are discontinuous in either the state or one of its derivatives. This
 causes the solver to take very small steps around the discontinuity, and
 sometimes leads to early stopping due to `dt <= dt_min`. The correct way to
-handle such dynamics is to tell the solver about the discontinuity by means of a
+handle such dynamics is to tell the solver about the discontinuity by a
 root-finding equation, which can be modeling using [`ODESystem`](@ref)'s event
 support. Please see the tutorial on [Callbacks and Events](@ref events) for
 details and examples.

docs/src/basics/ContextualVariables.md

@@ -10,8 +10,8 @@ the `@variable` which is defined by
 @variables x y(x)
 ```
 
-This is used for the "normal" variable of a given system, like the states of a
-differential equation or objective function. All of the macros below support
+This is used for the “normal” variable of a given system, like the states of a
+differential equation or objective function. All the macros below support
 the same syntax as `@variables`.
 
 ## Parameters
@@ -28,11 +28,11 @@ Constants are like parameters that:
 - do not show up in the list of parameters of a system.
 
 The intended use-cases for constants are:
-- representing literals (eg, π) symbolically, which results in cleaner
+- representing literals (e.g., π) symbolically, which results in cleaner
     Latexification of equations (avoids turning `d ~ 2π*r` into `d = 6.283185307179586 r`)
 - allowing auto-generated unit conversion factors to live outside the list of
     parameters
-- representing fundamental constants (eg, speed of light `c`) that should never
+- representing fundamental constants (e.g., speed of light `c`) that should never
      be adjusted inadvertently.
 
 ## Wildcard Variable Arguments
@@ -48,7 +48,7 @@ need to be able to write `u(t, 0.0)` to define a boundary condition at `x = 0`.
 
 ## Variable metadata [Experimental/TODO]
 
-In many engineering systems some variables act like "flows" while others do not.
+In many engineering systems, some variables act like “flows” while others do not.
 For example, in circuit models you have current which flows, and the related
 voltage which does not. Or in thermal models you have heat flows. In these cases,
 the `connect` statement enforces conservation of flow between all of the connected

docs/src/basics/Events.md

@@ -21,7 +21,7 @@ for more detail.
 Events involve both a *condition* function (for the zero crossing or truth
 test), and an *affect* function (for determining how to update the system when
 the event occurs). These can both be specified symbolically, but a more [general
-functional affect](@ref func_affects) representation is also allowed as described
+functional affect](@ref func_affects) representation is also allowed, as described
 below.
 
 ## Continuous Events
@@ -35,7 +35,7 @@ In the former, equations that evaluate to 0 will represent conditions that shoul
 be detected by the integrator, for example to force stepping to times of
 discontinuities. The latter allow modeling of events that have an effect on the
 state, where the first entry in the `Pair` is a vector of equations describing
-event conditions, and the second vector of equations describe the effect on the
+event conditions, and the second vector of equations describes the effect on the
 state. Each affect equation must be of the form
 ```julia
 single_state_variable ~ expression_involving_any_variables_or_parameters
@@ -155,7 +155,7 @@ that are provided in the `u` and `p` arguments (implemented as `NamedTuple`s).
 The integrator can also be manipulated more generally to control solution
 behavior, see the [integrator
 interface](https://docs.sciml.ai/DiffEqDocs/stable/basics/integrator/)
-documentation. In affect functions we have that
+documentation. In affect functions, we have that
 ```julia
 function affect!(integ, u, p, ctx)
     # integ.t is the current time
@@ -208,7 +208,7 @@ individual affect should be executed. Here `affect1` and `affect2` are each
 either a vector of one or more symbolic equations, or a functional affect, just
 as for continuous events. As before, for any *one* event the symbolic affect
 equations can either all change states (i.e. variables) or all change
-parameters, but one can not currently mix state and parameter changes within one
+parameters, but one cannot currently mix state and parameter changes within one
 individual event.
 
 ### Example: Injecting cells into a population
@@ -234,7 +234,7 @@ plot(sol)
 
 Notice, with generic discrete events that we want to occur at one or more fixed
 times, we need to also set the `tstops` keyword argument to `solve` to ensure
-the integrator stops at that time. In the next section we show how one can
+the integrator stops at that time. In the next section, we show how one can
 avoid this by using a preset-time callback.
 
 Note that more general logical expressions can be built, for example, suppose we
@@ -252,7 +252,7 @@ plot(sol)
 Since the solution is *not* smaller than half its steady-state value at the
 event time, the event condition now returns false. Here we used logical and,
 `&`, instead of the short-circuiting logical and, `&&`, as currently the latter
-can not be used within symbolic expressions.
+cannot be used within symbolic expressions.
 
 Let's now also add a drug at time `tkill` that turns off production of new
 cells, modeled by setting `α = 0.0`
@@ -275,7 +275,7 @@ plot(sol)
 ```
 
 ### Periodic and preset-time events
-Two important sub-classes of discrete events are periodic and preset-time
+Two important subclasses of discrete events are periodic and preset-time
 events.
 
 A preset-time event is triggered at specific set times, which can be

docs/src/basics/FAQ.md

@@ -27,7 +27,7 @@ pnew = varmap_to_vars([β=>3.0, c=>10.0, γ=>2.0],parameters(sys))
 For statements that are in the `if then else` form, use `IfElse.ifelse` from the
 [IfElse.jl](https://github.com/SciML/IfElse.jl) package to represent the code in a
 functional form. For handling direct `if` statements, you can use equivalent boolean
-mathematical expressions. For example `if x > 0 ...` can be implemented as just
+mathematical expressions. For example, `if x > 0 ...` can be implemented as just
 `(x > 0) * `, where if `x <= 0` then the boolean will evaluate to `0` and thus the
 term will be excluded from the model.
 
@@ -47,7 +47,7 @@ such as `@register_symbolic`, are described in detail
 ## Using ModelingToolkit with Optimization / Automatic Differentiation
 
 If you are using ModelingToolkit inside a loss function and are having issues with
-mixing MTK with automatic differentiation, getting performance, etc... don't! Instead, use
+mixing MTK with automatic differentiation, getting performance, etc… don't! Instead, use
 MTK outside the loss function to generate the code, and then use the generated code
 inside the loss function.
 
@@ -64,7 +64,7 @@ end
 Since `ODEProblem` on a MTK `sys` will have to generate code, this will be slower than
 caching the generated code, and will require automatic differentiation to go through the
 code generation process itself. All of this is unnecessary. Instead, generate the problem
-once outside the loss function, and remake the prob inside of the loss function:
+once outside the loss function, and remake the prob inside the loss function:
 
 ```julia
 prob = ODEProblem(sys, [], [p1 => p[1], p2 => p[2]])

docs/src/basics/Linearization.md

@@ -28,7 +28,7 @@ eqs = [u ~ kp * (r - y) # P controller
 matrices, simplified_sys = linearize(sys, [r], [y]) # Linearize from r to y
 matrices
 ```
-The named tuple `matrices` contains the matrices of the linear statespace representation, while `simplified_sys` is an `ODESystem` that, amongst other things, indicates the state order in the linear system through
+The named tuple `matrices` contains the matrices of the linear statespace representation, while `simplified_sys` is an `ODESystem` that, among other things, indicates the state order in the linear system through
 ```@example LINEARIZE
 using ModelingToolkit: inputs, outputs
 [states(simplified_sys); inputs(simplified_sys); outputs(simplified_sys)]

docs/src/basics/Validation.md

@@ -4,7 +4,7 @@ ModelingToolkit.jl provides extensive functionality for model validation and uni
 
 ## Assigning Units 
 
-Units may assigned with the following syntax. 
+Units may be assigned with the following syntax. 
 
 ```@example validation
 using ModelingToolkit, Unitful
@@ -30,7 +30,7 @@ Do not use `quantities` such as  `1u"s"`, `1/u"s"` or `u"1/s"` as these will res
 
 ## Unit Validation & Inspection
 
-Unit validation of equations happens automatically when creating a system. However, for debugging purposes one may wish to validate the equations directly using `validate`.
+Unit validation of equations happens automatically when creating a system. However, for debugging purposes, one may wish to validate the equations directly using `validate`.
 
 ```@docs
 ModelingToolkit.validate
@@ -61,7 +61,7 @@ ModelingToolkit.validate(eqs[1])
 ModelingToolkit.get_unit(eqs[1].rhs)
 ```
 
-An example of an inconsistent system: at present, `ModelingToolkit` requires that the units of all terms in an equation or sum to be equal-valued (`ModelingToolkit.equivalent(u1,u2)`), rather that simply dimensionally consistent. In the future, the validation stage may be upgraded to support the insertion of conversion factors into the equations. 
+An example of an inconsistent system: at present, `ModelingToolkit` requires that the units of all terms in an equation or sum to be equal-valued (`ModelingToolkit.equivalent(u1,u2)`), rather than simply dimensionally consistent. In the future, the validation stage may be upgraded to support the insertion of conversion factors into the equations. 
 
 ```@example validation
 using ModelingToolkit, Unitful

docs/src/basics/Variable_metadata.md

@@ -75,7 +75,7 @@ istunable(Kp)
 
 ## Probability distributions
 A probability distribution may be associated with a parameter to indicate either
-uncertainty about it's value, or as a prior distribution for Bayesian optimization.
+uncertainty about its value, or as a prior distribution for Bayesian optimization.
 
 ```julia
 using Distributions
@@ -88,7 +88,7 @@ getdist(m)
 ```
 
 ## Additional functions
-For systems that contain parameters with metadata like described above have some additional functions defined for convenience.
+For systems that contain parameters with metadata like described above, have some additional functions defined for convenience.
 In the example below, we define a system with tunable parameters and extract bounds vectors
 
 ```@example metadata

docs/src/systems/PDESystem.md

@@ -11,21 +11,21 @@ as a finite difference method with constant grid spacing, to something as comple
 as a distributed multi-GPU discontinuous Galerkin method.
 
 The key to the common PDE interface is a separation of the symbolic handling from
-the numerical world. All of the discretizers should not "solve" the PDE, but
+the numerical world. All the discretizers should not “solve” the PDE, but
 instead be a conversion of the mathematical specification to a numerical problem.
 Preferably, the transformation should be to another ModelingToolkit.jl `AbstractSystem`,
 but in some cases this cannot be done or will not be performant, so a `SciMLProblem` is
 the other choice.
 
 These elementary problems, such as solving linear systems `Ax=b`, solving nonlinear
 systems `f(x)=0`, ODEs, etc. are all defined by SciMLBase.jl, which then numerical
-solvers can all target these common forms. Thus someone who works on linear solvers
+solvers can all target these common forms. Thus, someone who works on linear solvers
 doesn't necessarily need to be working on a discontinuous Galerkin or finite element
 library, but instead "linear solvers that are good for matrices A with
 properties ..." which are then accessible by every other discretization method
 in the common PDE interface.
 
-Similar to the rest of the `AbstractSystem` types, transformation and analysis
+Similar to the rest of the `AbstractSystem` types, transformation, and analysis
 functions will allow for simplifying the PDE before solving it, and constructing
 block symbolic functions like Jacobians.
 

src/inputoutput.jl

@@ -58,7 +58,7 @@ unbound_outputs(sys) = filter(x -> !is_bound(sys, x), outputs(sys))
 """
     is_bound(sys, u)
 
-Determine whether or not input/output variable `u` is "bound" within the system, i.e., if it's to be considered internal to `sys`.
+Determine whether input/output variable `u` is "bound" within the system, i.e., if it's to be considered internal to `sys`.
 A variable/signal is considered bound if it appears in an equation together with variables from other subsystems.
 The typical usecase for this function is to determine whether the input to an IO component is connected to another component,
 or if it remains an external input that the user has to supply before simulating the system.
@@ -111,7 +111,7 @@ end
 """
     same_or_inner_namespace(u, var)
 
-Determine whether or not `var` is in the same namespace as `u`, or a namespace internal to the namespace of `u`.
+Determine whether `var` is in the same namespace as `u`, or a namespace internal to the namespace of `u`.
 Example: `sys.u ~ sys.inner.u` will bind `sys.inner.u`, but `sys.u` remains an unbound, external signal. The namepsaced signal `sys.inner.u` lives in a namspace internal to `sys`.
 """
 function same_or_inner_namespace(u, var)
@@ -149,7 +149,7 @@ end
 """
     has_var(eq, x)
 
-Determine whether or not an equation or expression contains variable `x`.
+Determine whether an equation or expression contains variable `x`.
 """
 function has_var(eq::Equation, x)
     has_var(eq.rhs, x) || has_var(eq.lhs, x)