Merge pull request #25705 from farscape-project/typo_grinder

Fix spelling mistakes throughout the docs

framework/doc/content/automatic_differentiation/index.md

@@ -280,7 +280,7 @@ we see exactly what we would expect: values 0--3 corresponding to the $u$
 indices are equivalent to that shown in the previous lldb output whereas the
 values in 4--7, corresponding to the $v$ indices, are equal to the negative of
 that shown in the previous lldb output. In general, the quality of automatic
-differention results are verified with unit testing in MetaPhysicL and using a
+differentiation results are verified with unit testing in MetaPhysicL and using a
 `PetscJacobianTester` in MOOSE which compares the Jacobian produced
 by automatic differentiation against that generated using finite differencing of
 the residuals. The latter test relies on using well-scaled problems; for

framework/doc/content/finite_volumes/fv_design.md

@@ -9,7 +9,7 @@ within each mesh element/cell. Because of this, much of MOOSE's use of libMesh
 for FE is not relevant for FV.  This document gives an overview of how FV is
 similar and different from FE with respect to implementation in MOOSE and
 explains why FV is designed and implemented in its current form.  In order to
-fully enable taking advantage of perfomance opportunities and to simplify the
+fully enable taking advantage of performance opportunities and to simplify the
 FV method implementation in MOOSE, a new set of FV-specific systems was built
 along-side the MOOSE FE infrastructure.  As a new set of systems being created
 after MOOSE has received powerful automatic differentiation (AD) support, the
@@ -35,7 +35,7 @@ have shared their entire interface/API with FE variables - which would be a
 poor choice because of so many non-overlapping API needs between the two (e.g.
 no shape and test function related functions are needed for FV variables).  So
 a new field-variable intermediate class was introduced to the variable class
-heirarchy to facilitate appropriately separate APIs while allowing common
+hierarchy to facilitate appropriately separate APIs while allowing common
 operations to be performed on all field variables.
 
 ## FV Kernels
@@ -108,7 +108,7 @@ Similar reasoning to decisions about the FV kernel system motivated the
 creation of a separate FV boundary condition system as well.  While FV
 flux/integrated boundary conditions are somewhat similar to FE integrated BCs,
 they still lack test/weight functions.  FV Dirichlet BCs, however must be
-implemented completedly differently than in FE and strongly motivate the
+implemented completely differently than in FE and strongly motivate the
 creation of a separate FV BC system.
 
 Dirichlet boundary conditions (BCs) in an FV method cannot be created by
@@ -120,7 +120,7 @@ implemented as a weak BC.  To do this, the normal flux kernel terms are
 applied at the mesh boundary faces.  Since flux kernels are calculated using
 information from cells on both sides of the face, we use the desired Dirichlet
 BC value to extrapolate a "ghost" cell value for the side of the face that has
-no actuall mesh cell.  Other necessary cell properties are also
+no actual mesh cell.  Other necessary cell properties are also
 reflected/mirrored from the existing cell.  A design was chosen that allows
 handling ghost-element creation and use by existing flux kernels automatically
 for enforcement of Dirichlet BCs.  This procedure results in the Dirichlet BC
@@ -180,7 +180,7 @@ down the assembly process due to the fact that additional face gradients need to
 
 On regular, orthogonal grids, the face gradient $\nabla \phi_f$ can be computed
 using a simple linear interpolation between neighboring cell gradients,
-e.g. between $\nabla \phi_C$ and $\nabla \phi_F$. However, on non-orthgonal
+e.g. between $\nabla \phi_C$ and $\nabla \phi_F$. However, on non-orthogonal
 grids, some correction has to be made. The correction implemented is that shown
 in section 9.4 of [!cite](moukalled2016finite):
 
@@ -206,4 +206,4 @@ gradient.
 * FV functionality does NOT work with mesh displacements yet. See
   [idaholab/moose#15064](https://github.com/idaholab/moose/issues/15064)
 
-* Have not tested vector-FV varaibles - they almost certainly don't work (yet).
+* Have not tested vector-FV variables - they almost certainly don't work (yet).

framework/doc/content/hit.md

@@ -1,6 +1,6 @@
 # The `hit` command
 
-*Hierarchial Input Text* (HIT) is the file format that MOOSE input files (and
+*Hierarchical Input Text* (HIT) is the file format that MOOSE input files (and
 `tests` specs) are built upon. HIT is a key-value pair syntax with multilevel
 block hierarchies. To deal with HIT files we provide the `hit` executable, which
 is automatically built under `framework/contrib/hit`. This command line tool
@@ -107,7 +107,7 @@ list of files to search follow.
 hit format [-i] [-style file] input
 ```
 
-The format subcommand will reformat a valid HIT file into a cannonical form with
+The format subcommand will reformat a valid HIT file into a canonical form with
 a consistent indentation and potentially sorted sections and parameters. The
 name of the file to be formatted is given as the `input` parameter. When
 specifying `-` as the filename the input is taken from stdin.

framework/doc/content/source/auxkernels/ArrayParsedAux.md

@@ -5,7 +5,7 @@
 ## Overview
 
 This auxiliary kernel is meant to emulate the behavior and syntax of [ParsedAux.md] for array variables.
-Using [!param](/AuxKernels/ArrayParsedAux/expression), one can define a general parsed function dependent on array variabls, scalar field variables, mesh coordinates, and time:
+Using [!param](/AuxKernels/ArrayParsedAux/expression), one can define a general parsed function dependent on array variables, scalar field variables, mesh coordinates, and time:
 
 !equation
 u_i = f(v_{1,i}, v_{2,i},..., w_1, w_2,..., x, y, z, t), \quad i=1,...,n,

framework/doc/content/source/auxkernels/GhostingAux.md

@@ -4,7 +4,7 @@
 
 # Description
 
-`GhostingAux` allows you to visualize what the current algebraic and geomtric ghosting functors (and RelationshipManagers) are going to do.  This is useful in tracking down both under and over-ghosting.
+`GhostingAux` allows you to visualize what the current algebraic and geometric ghosting functors (and RelationshipManagers) are going to do.  This is useful in tracking down both under and over-ghosting.
 
 At any one time it will only show you the ghosted elements for one processor ID.
 

framework/doc/content/source/auxkernels/PenetrationAux.md

@@ -1,6 +1,6 @@
 # PenetrationAux
 
-Auxililary Kernel for computing several geometry related quantities between two different bodies in or near contact.
+Auxiliary Kernel for computing several geometry related quantities between two different bodies in or near contact.
 
 ## Gap offset parameters
 

framework/doc/content/source/auxkernels/VectorPostprocessorVisualizationAux.md

@@ -6,11 +6,11 @@
 
 ## Description
 
-This object is intended to let you view VectorPostprocessor vectors that are of lenght `num_procs` (meaning there is one value per MPI process).  This object will take those values and fill up an Auxiliary field with them so the values can be visualized.
+This object is intended to let you view VectorPostprocessor vectors that are of length `num_procs` (meaning there is one value per MPI process).  This object will take those values and fill up an Auxiliary field with them so the values can be visualized.
 
 ## Important Notes
 
-Note: the VectorPostprocessor must be syncing the vectors it's computing to all processors.  By default many just compute to processor 0 (because that's where output occurrs).
+Note: the VectorPostprocessor must be syncing the vectors it's computing to all processors.  By default many just compute to processor 0 (because that's where output occurs).
 
 For instance: this is the case for [WorkBalance](WorkBalance.md).  By default it only syncs to processor 0, but it has a parameter (`sync_to_all_procs`) to tell it to create copies of the vectors on all processors.
 

framework/doc/content/source/constraints/MortarScalarBase.md

@@ -36,10 +36,10 @@ input parameter names):
 
 The three focus spatial variables `_var`, `_secondary_var`, and `_primary_var` are each indicated by the
 name `var` below, and are differentiated by the `mortar_type` flag as one of "Primary". "Secondary", or
-"Lower". In a coupled (multi-phyics) weak form, all interface integral terms containing the test function
+"Lower". In a coupled (multi-physics) weak form, all interface integral terms containing the test function
 of one of these three variables are potential candidates for `MortarConstraint` contributions.
 
-The philosphy of the scalar augmentation class `MortarScalarBase` is to add a single focus scalar variable
+The philosophy of the scalar augmentation class `MortarScalarBase` is to add a single focus scalar variable
 referred to as `_kappa` to the `MortarConstraint` object so that all terms in the coupled weak form that
 involve the spatial variables, scalar variable, and/or their test functions can be assembled in one
 or multiple class instances.

framework/doc/content/source/constraints/PenaltyPeriodicSegmentalConstraint.md

@@ -56,7 +56,7 @@ Two of these objects are shown in the input file below:
 
 !listing test/tests/mortar/periodic_segmental_constraint/penalty_periodic_simple2d.i block=Constraints
 
-The applied macroscale diffusive flux $\sigma$ is applied as the `sigma` vector via an auxillary
+The applied macroscale diffusive flux $\sigma$ is applied as the `sigma` vector via an auxiliary
 scalar. The computed macroscale diffusive gradient $\epsilon$ is assigned in a scalar variable `epsilon`.
 Both of these scalars should have the same number of components as the spatial dimension of $\Omega$.
 The volume integral of the gradient of the primary field will be constrained to $\epsilon$

framework/doc/content/source/constraints/PeriodicSegmentalConstraint.md

@@ -71,7 +71,7 @@ Two of these objects are shown in the input file below:
 
 !listing test/tests/mortar/periodic_segmental_constraint/periodic_simple2d.i block=Constraints
 
-The applied macroscale diffusive flux $\sigma$ is applied as the `sigma` vector via an auxillary
+The applied macroscale diffusive flux $\sigma$ is applied as the `sigma` vector via an auxiliary
 scalar. The computed macroscale diffusive gradient $\epsilon$ is assigned in a scalar variable `epsilon`.
 Both of these scalars should have the same number of components as the spatial dimension of $\Omega$.
 The volume integral of the gradient of the primary field will be constrained to $\epsilon$

framework/doc/content/source/dgkernels/ADDGAdvection.md

@@ -11,7 +11,7 @@ couple distinctions:
   and/or changing spatially. Additionally, the use of a material property as
   opposed to a coupled variable allows more straightforward
   propagation of derivatives for automatic differentiation.
-- A [!param](/DGKernels/ADDGAdvection/advected_quantity) paramter is
+- A [!param](/DGKernels/ADDGAdvection/advected_quantity) parameter is
   available which allows for advecting different quantities than the `variable`
   this object is acting upon
 

framework/doc/content/source/dgkernels/ArrayDGDiffusion.md

@@ -13,7 +13,7 @@ where $\vec{u}^\ast$ is the test function, $\vec{u}$ is the finite element solut
 $[\![ \cdot ]\!]$ and $\{\!\!\{ \cdot \}\!\!\}$ are the jump and average of the enclosed quantity on the internal sides.
 
 $\vec{n}(x)$ is a unit norm defined on internal sides denoted by $\Gamma_\text{int}$.
-$\epsilon$ can be 1, -1, and 0, corresponding symmetric, asymetric and incomplete interior penalty methods respectively.
+$\epsilon$ can be 1, -1, and 0, corresponding symmetric, asymmetric and incomplete interior penalty methods respectively.
 The penalty coefficients $\kappa$ are evaluated with the following formulation:
 \begin{equation}
 \vec{\kappa} = \sigma \{\!\!\{ p^2\frac{\vec{D}}{h_\bot} \}\!\!\}, \quad  x\in\Gamma_\text{int},

framework/doc/content/source/executioners/Steady.md

@@ -55,7 +55,7 @@ The preconditioning matrix $\mathbf{M}$ can be viewed with the PETSc option `-ks
 
 ## Solve Type
 
-The general method in which the nonlinear system is solved is controled by the [!param](/Executioner/Steady/solve_type) parameter. Below is a description of each of the options:
+The general method in which the nonlinear system is solved is controlled by the [!param](/Executioner/Steady/solve_type) parameter. Below is a description of each of the options:
 
 - `PJFNK` is the default solve type. It makes the executioner perform Jacobian-free linear solves at each Newton iteration with the preconditioner built from the preconditioning matrix $\mathbf{M}$. By default, the preconditioning matrix is block-diagonal with each block corresponding to a single MOOSE variable without custom preconditioning, refer to [Preconditioning](/Preconditioning/index.md). Off-diagonal Jacobian terms are ignored. It essentially activates the matrix-free Jacobian-vector products, and the preconditioning matrix.
 - `JFNK` means there is no preconditioning during the Krylov solve. No Jacobian will be assembled. It essentially activates the matrix-free Jacobian-vector products and no preconditioning matrix.

framework/doc/content/source/executors/Executor.md

@@ -146,7 +146,7 @@ FooExecutor::run()
   Result & r = newResult();
   ...
   // When we record an inner/sub executor's result, we give it a label - which
-  // helps identify its placement/role within the executor heirarchy.
+  // helps identify its placement/role within the executor hierarchy.
   r.record("solve1", _inner_solve1->exec());
   r.record("solve2", _inner_solve2->exec());
   ...
@@ -167,7 +167,7 @@ FooExecutor::run()
   Result & r = newResult();
   ...
   // When we record an inner/sub executor's result, we give it a label - which
-  // helps identify its placement/role within the executor heirarchy.
+  // helps identify its placement/role within the executor hierarchy.
   r.record("solve1", _inner_solve1->exec());
   r.record("solve2", _inner_solve2->exec());
 

framework/doc/content/source/functions/PiecewiseLinear.md

@@ -6,7 +6,7 @@
 
 The `PiecewiseLinear` function performs linear interpolations between user-provided
 pairs of x-y data.  The x-y data can be provided in three ways. The first way is through
-a combination of the `x` and `y` paramaters, which are lists of the x and y coordinates
+a combination of the `x` and `y` parameters, which are lists of the x and y coordinates
 of the data points that make up the function.  The second way is in the `xy_data`
 parameter, which is a list of pairs of x-y data that make up the points of the
 function.  This allows for the function data to be specified in columns by inserting line

framework/doc/content/source/geomsearch/GeometricSearchData.md

@@ -20,6 +20,6 @@
     - [`IntegratedBCs`](syntax/BCs/index.md) e.g. the `HeatConduction` module's `GapHeatTransfer` object
     - [Elemental `AuxKernels`](AuxKernels/index.md) e.g. the elemental versions of [`GapValueAux`](/GapValueAux.md), [`NearestNodeDistanceAux`](/NearestNodeDistanceAux.md), and [`PenetrationAux`](/PenetrationAux.md)
 - The non-quadrature based methods should be used for nodal objects such as:
-    - [`NodeFaceConstraints`](Constraints/index.md) e.g. the `Contact` module's `MechanicalContactConstrant` object
+    - [`NodeFaceConstraints`](Constraints/index.md) e.g. the `Contact` module's `MechanicalContactConstraint` object
     - [Nodal `AuxKernels`](AuxKernels/index.md) e.g. the nodal versions of [`GapValueAux`](/GapValueAux.md), [`NearestNodeDistanceAux`](/NearestNodeDistanceAux.md), and [`PenetrationAux`](/PenetrationAux.md)
-- geometric search objects like [`NearestNodeLocator`](/NearestNodeLocator.md) and [`PenetrationLocator`](/PenetrationLocator.md) should hold to their geometric purpose and **not** call algebraic APIs like `FEProblemBase::prepare` which will query `libMesh::DofObject` information. This information may or may not have been initialized at the time that geometric search objects are being updated, so any query attempt may result in failed assertions or segmentaton faults.
+- geometric search objects like [`NearestNodeLocator`](/NearestNodeLocator.md) and [`PenetrationLocator`](/PenetrationLocator.md) should hold to their geometric purpose and **not** call algebraic APIs like `FEProblemBase::prepare` which will query `libMesh::DofObject` information. This information may or may not have been initialized at the time that geometric search objects are being updated, so any query attempt may result in failed assertions or segmentation faults.

framework/doc/content/source/indicators/LaplacianJumpIndicator.md

@@ -8,7 +8,7 @@ The LaplacianJumpIndicator object computes the error as computed by the change i
 Laplacian of a variable across element interfaces.
 
 !alert warning title=LaplacianJumpIndicator requires second derivatives
-The Laplacian ($\nabla^2 u$ or $\nabla\cdot\nabla u$) operator requires second derivaties with
+The Laplacian ($\nabla^2 u$ or $\nabla\cdot\nabla u$) operator requires second derivatives with
 respect to the spacial dimensions. As such, the selected finite elements must be at least
 second order for the calculation to be valid.
 

framework/doc/content/source/interfaces/SolutionInvalidInterface.md

@@ -2,6 +2,6 @@
 
 The SolutionInvalidInterface defines the method used to mark a solution as "invalid".  An invalid solution means that the solution somehow does not satisfy requirements such as a value being out of bounds of a correlation.  Solutions are allowed to be invalid _during_ the nonlinear solve - but are not allowed to invalid once it converges.  A "converged" solution that is marked as invalid will cause MOOSE to behave as if the solution did NOT converge - including cutting back timesteps, etc.
 
-This can be overriden by setting `Problem/allow_invalid_solution=true`.
+This can be overridden by setting `Problem/allow_invalid_solution=true`.
 
 !listing /SolutionInvalidInterface.h start=doco-normal-methods-begin end=doco-normal-methods-end include-start=false

framework/doc/content/source/kernels/AnisotropicDiffusion.md

@@ -2,13 +2,13 @@
 
 ## Description
 
-The `AnisotropicDiffusion` kernel implements anistropic diffusion term on a domain ($\Omega$) given in its strong form as
+The `AnisotropicDiffusion` kernel implements anisotropic diffusion term on a domain ($\Omega$) given in its strong form as
 
 \begin{equation}
 \nabla\cdot -\widetilde{k} \nabla u = 0 \in \Omega,
 \end{equation}
 where $\widetilde{k}$ is the anisotropic
-diffusion coefficient. Diffusion is anistropic if the diffusion rate varies with
+diffusion coefficient. Diffusion is anisotropic if the diffusion rate varies with
 direction. The corresponding weak form, using inner-product notation, is given by
 
 \begin{equation}
@@ -31,12 +31,12 @@ For a constant diffusion coefficient, the Jacobian is given by
 
 The `AnisotropicDiffusion` kernel may be used in a variety of physical models, including steady-state
 and time-dependent diffusion, advection-diffusion-reaction, etc. A kernel block demonstrating the
-`AnistropicDiffusion` syntax in a steady-state anistropic diffusion problem can be found below:
+`AnistropicDiffusion` syntax in a steady-state anisotropic diffusion problem can be found below:
 
 !listing test/tests/kernels/anisotropic_diffusion/aniso_diffusion.i block=Kernels
 
 !alert note
-The anistropic diffusion coefficient $\widetilde{k}$ is a three-dimensional tensor supplied through a
+The anisotropic diffusion coefficient $\widetilde{k}$ is a three-dimensional tensor supplied through a
 string with nine space separated real values. The entries correspond to $xx$, $xy$, $xz$, $yx$, $yy$,
 $yz$, $zx$, $zy$, and $zz$, respectively. Also, this problem is 2-dimensional so the corresponding
 $zx$, $zy$, and $zz$ terms are zero.

framework/doc/content/source/kernels/ArrayDiffusion.md

@@ -15,7 +15,7 @@ where $\vec{u}^\ast$ is the test function, $\vec{u}$ is the finite element solut
 $\vec{u}$ is an array variable that has $N$ number of components.
 $w_p, p=1,\cdots,N$ is the scalings of all components of the array variable.
 The size of the vector test function $\vec{u}^\ast$ is the same as the size of $\vec{u}$.
-The kernel can be furthur spelled out as
+The kernel can be further spelled out as
 \begin{equation}
 \sum_{p=1}^N w_p \sum_{q=1}^N (\nabla u_p^\ast, D_{p,q} \nabla u_q) = \sum_{p=1}^N w_p \sum_{q=1}^N \sum_{e} \int_e D_{p,q}(x) \nabla u_p^\ast (x) \cdot \nabla u_q(x)\,dx = \sum_{p=1}^N w_p \sum_{q=1}^N \sum_{e} \sum_{i=1}^{N_{\text{dof}}} \sum_{j=1}^{N_{\text{dof}}} u_{p,i}^\ast u_{q,j} \sum_{\text{qp}=1}^{N_{qp}} (|J|w)_{\text{qp}} D_{p,q,\text{qp}} \nabla b_{i,\text{qp}} \cdot \nabla b_{j,\text{qp}}, \label{eq:weak-array-diffusion}
 \end{equation}
@@ -36,7 +36,7 @@ When it is a diagonal matrix, it can be represented by an array.
 In such a case, the components are not coupled with this array diffusion kernel.
 If all elements of the diffusion coefficient vector are the same, we can use a scalar diffusion coefficient.
 Thus this kernel gives users an option to set the type of diffusion coefficient with a parameter named as *diffusion_coefficient_type*.
-Users can set it to *scalar*, *array* or *full* cooresponding to scalar, diagonal matrix and full matrix respectively.
+Users can set it to *scalar*, *array* or *full* corresponding to scalar, diagonal matrix and full matrix respectively.
 Its default value is *array*.
 
 With some further transformation, the kernel becomes