Merge pull request #2363 from ArnoStrouwen/ci_typo

typos CI

Author: YingboMa

.github/workflows/SpellCheck.yml

@@ -0,0 +1,13 @@
+name: Spell Check
+
+on: [pull_request]
+
+jobs:
+  typos-check:
+    name: Spell Check with Typos
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout Actions Repository
+        uses: actions/checkout@v3
+      - name: Check spelling
+        uses: crate-ci/typos@v1.16.23 

.typos.toml

@@ -0,0 +1,6 @@
+[default.extend-words]
+nin = "nin"
+nd = "nd"
+Strat = "Strat"
+eles = "eles"
+ser = "ser"

docs/src/basics/AbstractSystem.md

@@ -121,7 +121,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 proceding
+methods. The first argument is always the `AbstractSystem`, and the next
 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/Linearization.md

@@ -51,7 +51,7 @@ If linearization is to be performed around multiple operating points, the simpli
 
 ## Symbolic linearization
 
-The function [`ModelingToolkit.linearize_symbolic`](@ref) works simiar to [`ModelingToolkit.linearize`](@ref) but returns symbolic rather than numeric Jacobians. Symbolic linearization have several limitations and no all systems that can be linearized numerically can be linearized symbolically.
+The function [`ModelingToolkit.linearize_symbolic`](@ref) works similar to [`ModelingToolkit.linearize`](@ref) but returns symbolic rather than numeric Jacobians. Symbolic linearization have several limitations and no all systems that can be linearized numerically can be linearized symbolically.
 
 ## Input derivatives
 

docs/src/basics/MTKModel_Connector.md

@@ -29,7 +29,7 @@ equations.
   - `@icon` : for embedding the model icon
   - `@parameters`: for specifying the symbolic parameters
   - `@structural_parameters`: for specifying non-symbolic parameters
-  - `@variables`: for specifing the states
+  - `@variables`: for specifying the states
 
 Let's explore these in more detail with the following example:
 
@@ -104,7 +104,7 @@ end
 
 #### `@structural_parameters` begin block
 
-  - This block is for non symbolic input arguements. These are for inputs that usually are not meant to be part of components; but influence how they are defined. One can list inputs like boolean flags, functions etc... here.
+  - This block is for non symbolic input arguments. These are for inputs that usually are not meant to be part of components; but influence how they are defined. One can list inputs like boolean flags, functions etc... here.
   - Whenever default values are specified, unlike parameters/variables, they are reflected in the keyword argument list.
 
 #### `@parameters` and `@variables` begin block

docs/src/tutorials/bifurcation_diagram_computation.md

@@ -1,6 +1,6 @@
 # [Bifurcation Diagrams](@id bifurcation_diagrams)
 
-Bifurcation diagrams describes how, for a dynamic system, the quantity and quality of its steady states changes with a parameter's value. These can be computed through the [BifurcationKit.jl](https://github.com/bifurcationkit/BifurcationKit.jl) package. ModelingToolkit provides a simple interface for creating BifurcationKit compatible `BifurcationProblem`s from `NonlinearSystem`s and `ODESystem`s. All teh features provided by BifurcationKit can then be applied to these systems. This tutorial provides a brief introduction for these features, with BifurcationKit.jl providing [a more extensive documentation](https://bifurcationkit.github.io/BifurcationKitDocs.jl/stable/).
+Bifurcation diagrams describes how, for a dynamic system, the quantity and quality of its steady states changes with a parameter's value. These can be computed through the [BifurcationKit.jl](https://github.com/bifurcationkit/BifurcationKit.jl) package. ModelingToolkit provides a simple interface for creating BifurcationKit compatible `BifurcationProblem`s from `NonlinearSystem`s and `ODESystem`s. All the features provided by BifurcationKit can then be applied to these systems. This tutorial provides a brief introduction for these features, with BifurcationKit.jl providing [a more extensive documentation](https://bifurcationkit.github.io/BifurcationKitDocs.jl/stable/).
 
 ### Creating a `BifurcationProblem`
 

docs/src/tutorials/domain_connections.md

@@ -205,7 +205,7 @@ nothing #hide
 
 ![actsys2](https://github.com/SciML/ModelingToolkit.jl/assets/40798837/8ed50035-f6ac-48cb-a585-1ef415154a02)
 
-After running `structural_simplify()` on `actsys2`, the defaults will show that `act.port_a.ρ` points to `fluid_a₊ρ` and `act.port_b.ρ` points to `fluid_b₊ρ`.  This is a special case, in most cases a hydraulic system will have only 1 fluid, however this simple system has 2 separate domain networks.  Therefore, we can connect a single fluid to both networks.  This does not interfer with the mathmatical equations of the system, since no states are connected.
+After running `structural_simplify()` on `actsys2`, the defaults will show that `act.port_a.ρ` points to `fluid_a₊ρ` and `act.port_b.ρ` points to `fluid_b₊ρ`.  This is a special case, in most cases a hydraulic system will have only 1 fluid, however this simple system has 2 separate domain networks.  Therefore, we can connect a single fluid to both networks.  This does not interfere with the mathematical equations of the system, since no states are connected.
 
 ```@example domain
 @component function ActuatorSystem1(; name)
@@ -239,7 +239,7 @@ nothing #hide
 
 ## Special Connection Cases (`domain_connect()`)
 
-In some cases a component will be defined with 2 connectors of the same domain, but they are not connected.  For example the `Restrictor` defined here gives equations to define the behavior of how the 2 connectors `port_a` and `port_b` are physcially connected.
+In some cases a component will be defined with 2 connectors of the same domain, but they are not connected.  For example the `Restrictor` defined here gives equations to define the behavior of how the 2 connectors `port_a` and `port_b` are physically connected.
 
 ```@example domain
 @component function Restrictor(; name, p_int)

docs/src/tutorials/ode_modeling.md

@@ -327,7 +327,7 @@ plot(solve(prob))
 
 More on this topic may be found in [Composing Models and Building Reusable Components](@ref acausal).
 
-## Inital Guess
+## Initial Guess
 
 It is often a good idea to specify reasonable values for the initial state and the
 parameters of a model component. Then, these do not have to be explicitly specified when constructing the `ODEProblem`.
@@ -347,7 +347,7 @@ end
 ```
 
 While defining the model `UnitstepFOLFactory`, an initial guess of 0.0 is assigned to `x(t)` and 1.0 to `τ`.
-Additionaly, these initial guesses can be modified while creating instances of `UnitstepFOLFactory` by passing arguements.
+Additionally, these initial guesses can be modified while creating instances of `UnitstepFOLFactory` by passing arguments.
 
 ```@example ode2
 @named fol = UnitstepFOLFactory(; x = 0.1)

ext/MTKBifurcationKitExt.jl

@@ -20,7 +20,7 @@ struct ObservableRecordFromSolution{S, T}
     param_end_idxs::Int64
     # The index (in subs_vals) that contain the bifurcation parameter.
     bif_par_idx::Int64
-    # A Vector of pairs (Symbolic => value) with teh default values of all system variables and parameters.
+    # A Vector of pairs (Symbolic => value) with the default values of all system variables and parameters.
     subs_vals::T
 
     function ObservableRecordFromSolution(nsys::NonlinearSystem,
@@ -41,10 +41,10 @@ struct ObservableRecordFromSolution{S, T}
         # Gets the (base) substitution values for observables. 
         subs_vals_obs = [obs.lhs => substitute(obs.rhs,
             [subs_vals_states; subs_vals_params]) for obs in observed(nsys)]
-        # Sometimes observables depend on other observables, hence we make a second upate to this vector.
+        # Sometimes observables depend on other observables, hence we make a second update to this vector.
         subs_vals_obs = [obs.lhs => substitute(obs.rhs,
             [subs_vals_states; subs_vals_params; subs_vals_obs]) for obs in observed(nsys)]
-        # During the bifurcation process, teh value of some states, parameters, and observables may vary (and are calculated in each step). Those that are not are stored in this vector
+        # During the bifurcation process, the value of some states, parameters, and observables may vary (and are calculated in each step). Those that are not are stored in this vector
         subs_vals = [subs_vals_states; subs_vals_params; subs_vals_obs]
 
         param_end_idxs = state_end_idxs + length(parameters(nsys))

ext/MTKDeepDiffsExt.jl

@@ -72,9 +72,9 @@ function Base.show(io::IO, l::BipartiteAdjacencyListDiff)
     new_nonempty = isnothing(l.new.u) ? nothing : !isempty(l.new.u)
     old_nonempty = isnothing(l.old.u) ? nothing : !isempty(l.old.u)
     if new_nonempty === true && old_nonempty === true
-        if (!isempty(setdiff(l.new.highligh_u, l.new.u)) ||
-            !isempty(setdiff(l.old.highligh_u, l.old.u)))
-            throw(ArgumentError("The provided `highligh_u` must be a sub-graph of `u`."))
+        if (!isempty(setdiff(l.new.highlight_u, l.new.u)) ||
+            !isempty(setdiff(l.old.highlight_u, l.old.u)))
+            throw(ArgumentError("The provided `highlight_u` must be a sub-graph of `u`."))
         end
 
         new_items = Dict(i => HighlightInt(i, :nothing, i === l.new.match) for i in l.new.u)