Merge pull request #2363 from ArnoStrouwen/ci_typo

typos CI

.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/[email protected] 

.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)

src/bipartite_graph.jl

@@ -203,7 +203,7 @@ end
 # Matrix whose only purpose is to pretty-print the bipartite graph
 struct BipartiteAdjacencyList
     u::Union{Vector{Int}, Nothing}
-    highligh_u::Union{Set{Int}, Nothing}
+    highlight_u::Union{Set{Int}, Nothing}
     match::Union{Int, Bool, Unassigned}
 end
 function BipartiteAdjacencyList(u::Union{Vector{Int}, Nothing})
@@ -236,13 +236,13 @@ function Base.show(io::IO, l::BipartiteAdjacencyList)
         printstyled(io, '⋅', color = :light_black)
     elseif isempty(l.u)
         printstyled(io, '∅', color = :light_black)
-    elseif l.highligh_u === nothing
+    elseif l.highlight_u === nothing
         print(io, l.u)
     else
         match = l.match
         isa(match, Bool) && (match = unassigned)
         function choose_color(i)
-            solvable = i in l.highligh_u
+            solvable = i in l.highlight_u
             matched = i == match
             if !matched && solvable
                 :default
@@ -254,10 +254,10 @@ function Base.show(io::IO, l::BipartiteAdjacencyList)
                 :magenta
             end
         end
-        if !isempty(setdiff(l.highligh_u, l.u))
+        if !isempty(setdiff(l.highlight_u, l.u))
             # Only for debugging, shouldn't happen in practice
             print(io,
-                map(union(l.u, l.highligh_u)) do i
+                map(union(l.u, l.highlight_u)) do i
                     HighlightInt(i, !(i in l.u) ? :light_red : choose_color(i),
                         i == match)
                 end)

src/systems/connectors.jl

@@ -184,7 +184,7 @@ function isframe(sys)
     get(md, :frame, false)
 end
 
-"Return orienation object of a multibody frame."
+"Return orientation object of a multibody frame."
 function ori(sys)
     @assert has_metadata(sys)
     md = get_metadata(sys)

src/systems/discrete_system/discrete_system.jl

@@ -163,7 +163,7 @@ end
 
 function DiscreteSystem(eqs, iv = nothing; kwargs...)
     eqs = scalarize(eqs)
-    # NOTE: this assumes that the order of algebric equations doesn't matter
+    # NOTE: this assumes that the order of algebraic equations doesn't matter
     diffvars = OrderedSet()
     allstates = OrderedSet()
     ps = OrderedSet()

src/systems/model_parsing.jl

@@ -10,7 +10,7 @@ struct Model{F, S}
     """The constructor that returns ODESystem."""
     f::F
     """
-    The dictionary with metadata like keyword arguements (:kwargs), base
+    The dictionary with metadata like keyword arguments (:kwargs), base
     system this Model extends (:extend), sub-components of the Model (:components),
     variables (:variables), parameters (:parameters), structural parameters
     (:structural_parameters) and equations (:equations).
@@ -327,7 +327,7 @@ end
 
 function extend_args!(a, b, dict, expr, kwargs, varexpr, has_param = false)
     # Whenever `b` is a function call, skip the first arg aka the function name.
-    # Whenver it is a kwargs list, include it.
+    # Whenever it is a kwargs list, include it.
     start = b.head == :call ? 2 : 1
     for i in start:lastindex(b.args)
         arg = b.args[i]

src/systems/sparsematrixclil.jl

@@ -155,7 +155,7 @@ function bareiss_update_virtual_colswap_mtk!(zero!, M::SparseMatrixCLIL, k, swap
     #    algorithm.
     #
     # For point 1, remember that we're working on a system of linear equations,
-    # so it is always legal for us to multiply any row by a sclar without changing
+    # so it is always legal for us to multiply any row by a scalar without changing
     # the underlying system of equations.
     #
     # For point 2, note that the factorization we're now computing is the same

src/utils.jl

@@ -293,7 +293,7 @@ function check_operator_variables(eqs, op::T) where {T}
         if length(tmp) == 1
             x = only(tmp)
             if op === Differential
-                # Having a differece is fine for ODEs
+                # Having a difference is fine for ODEs
                 is_tmp_fine = isdifferential(x) || isdifference(x)
             else
                 is_tmp_fine = istree(x) && !(operation(x) isa op)

test/bigsystem.jl

@@ -57,7 +57,7 @@ multithreadedf = eval(ModelingToolkit.build_function(du, u, fillzeros = true,
 MyA = zeros(N, N);
 AMx = zeros(N, N);
 DA = zeros(N, N);
-# Loop to catch syncronization issues
+# Loop to catch synchronization issues
 for i in 1:100
     _du = rand(N, N, 3)
     _u = rand(N, N, 3)

test/odesystem.jl

@@ -555,7 +555,7 @@ function submodel(; name)
     ODESystem(D(y) ~ sum(A) * y; name = name)
 end
 
-# Buid system
+# Build system
 @named sys1 = submodel()
 @named sys2 = submodel()