Merge pull request #26058 from farscape-project/typos

Fix typos in the docs

framework/doc/content/automatic_differentiation/index.md

@@ -205,7 +205,7 @@ the $\phi_i's$ are shape functions associated with the dofs. For a
 Lagrange basis, shape functions and dofs are tied to mesh nodes. To
 illustrate initiation of the AD process, we will consider construction of
 a local finite element solution on a `QUAD4` element, that is to say a
-quadrilaterial with a number of nodes equal to the number of vertices. This
+quadrilateral with a number of nodes equal to the number of vertices. This
 element type when combined with a Lagrange basis has four dofs which
 contribute to the local solution, one for each element node. In MOOSE we
 assign these local degree of freedom solution values (the local $u_i's$) to a

framework/doc/content/automatic_differentiation/templated_objects.md

@@ -53,7 +53,7 @@ The corresponding source file is
 
 !listing framework/src/kernels/BodyForce.C
 
-One important observation in this case is that this class (`BodyForcdeTempl`) derives
+One important observation in this case is that this class (`BodyForceTempl`) derives
 from a templated base class (`GenericKernel<is_ad`). This is slightly more complicated
 than the material example above. Members of the base class are not available in this
 derived class without including them with the `using` declaration in the header file

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

@@ -27,7 +27,7 @@ required to solve a constrained PDE defined by
 [this input file](/upper-and-lower-bound.i) with the various constraint
 algorithms is summarized below:
 
-- `viewntonrsls` and `ConstantBoundsAux`:                      22
+- `vinewtonrsls` and `ConstantBoundsAux`:                      22
 - `vinewtonssls` and `ConstantBoundsAux`:                      53
 - `UpperBoundNodalKernel` and `LowerBoundNodalKernel`: 25
 

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

@@ -8,7 +8,7 @@ One of the main purposes of this object is to aid in the diagnostic of mesh part
 
 This is particularly interesting in the case of the [PetscExternalPartitioner](PetscExternalPartitioner.md) which has the capability to do "hierarchical" partitioning.  Hierarchical partitioning makes it possible to partition over compute-nodes first... then within compute nodes, in order to better respect the physical topology of the compute cluster.
 
-One important aspect of that is that how you launch your parallel job can matter quite a bit to partitioning.  In-general, it's better for partitioners if all of the ranks of your job are contiguously assigned to each compute node.  Here are four different ways, and the outcome using `HardwareIDAux`, to launch a job using a 100x100 generated mesh on 16 processes and 4 ndoes with two different partitioner...
+One important aspect of that is that how you launch your parallel job can matter quite a bit to partitioning.  In-general, it's better for partitioners if all of the ranks of your job are contiguously assigned to each compute node.  Here are four different ways, and the outcome using `HardwareIDAux`, to launch a job using a 100x100 generated mesh on 16 processes and 4 nodes with two different partitioner...
 
 Top left (METIS):
 

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

@@ -103,7 +103,7 @@ directly opposite along the unit normal direction.
 As mentioned above, the $\lambda$ discretization needs to be continuous along patches
 of element faces (`LAGRANGE`, not `MONOMIAL`) in order to be stable, but must be discontinuous along
 corners of the mesh where the outward unit normal $\hat{n}$ is discontinuous since it is
-a flux variable (see the thrid condition [strong-form]). An easy way to do this is to make a
+a flux variable (see the third condition [strong-form]). An easy way to do this is to make a
 separate `LAGRANGE` variable for each 'face' of the model with different $\hat{n}$, which
 usually corresponds with different named side-sets or boundaries used for creating
 lower-dimensional mesh surfaces. This approach is demonstrated in many of the test input files.

framework/doc/content/source/dirackernels/ReporterPointSource.md

@@ -3,7 +3,7 @@
 A `ReporterPointSource` reads in multiple point sources from a `Reporter`.  The point source values and coordinates are updated as the `Reporter` values are changed.  
 
 An example of a `ReporterPointSource` using a [ConstantReporter](/ConstantReporter.md)
-and a `VectorPostrocessor` of type [CSVReader](/CSVReader.md) is given by:
+and a `VectorPostprocessor` of type [CSVReader](/CSVReader.md) is given by:
 
 !listing test/tests/dirackernels/reporter_point_source/2d_vpp.i block=reporter_point_source
 
@@ -12,15 +12,15 @@ The two ConstantReporters are given as:
 
 !listing test/tests/dirackernels/reporter_point_source/2d_vpp.i block=Reporters
 
-The `CSVReader` VectorPostrocessor is given by:
+The `CSVReader` VectorPostprocessor is given by:
 
 !listing test/tests/dirackernels/reporter_point_source/2d_vpp.i block=VectorPostprocessors
 
 reading from the following csv file:
 
 !listing test/tests/dirackernels/reporter_point_source/point_value_file.csv
 
-The `Reporter` and `VectorPostrocessor` for the above example produce the same `ReporterPointSource` (e.g. same magnitude and location).   
+The `Reporter` and `VectorPostprocessor` for the above example produce the same `ReporterPointSource` (e.g. same magnitude and location).   
 
 The next example applies a `ReporterPointSource` in a transient simulation given by:
 

framework/doc/content/source/fvbcs/FVDirichletBC.md

@@ -8,7 +8,7 @@ Dirichlet boundary conditions impose the boundary condition $u=g$, where $g$ is
 flux.
 
 Note that an upwinding scheme that may be used by flux kernels will affect how the Dirichlet value is applied to the interface. Upwinding schemes can result in the boundary solution being different than the specified Dirichlet value. In order to
-obtain the desired boundary value, it is necessary to use a FVNeummannBC to specify
+obtain the desired boundary value, it is necessary to use a FVNeumannBC to specify
 the flux.
 
 !syntax parameters /FVBCs/FVDirichletBC

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

@@ -26,7 +26,7 @@ ALWAYS | Union of all the above flags.
 The "execute_on" parameter can be set to a single flag or multiple flags. For example, it may be
 desirable to only execute an object initially because the state of the auxiliary computation does not
 vary. In the input file snippet below, the [ElementLengthAux](/ElementLengthAux.md) computation only
-needs to be computed initially, thus the "exeucte_on" parameter is set as such.
+needs to be computed initially, thus the "execute_on" parameter is set as such.
 
 !listing test/tests/auxkernels/element_length/element_length.i block=AuxKernels
 

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

@@ -31,7 +31,7 @@ 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 anisotropic diffusion problem can be found below:
+`AnisotropicDiffusion` syntax in a steady-state anisotropic diffusion problem can be found below:
 
 !listing test/tests/kernels/anisotropic_diffusion/aniso_diffusion.i block=Kernels
 

framework/doc/content/source/meshgenerators/MeshDiagnosticsGenerator.md

@@ -104,7 +104,7 @@ The coarse element, if it were refined with MOOSE h-adaptivity, would be refined
 originally present in the mesh.
 
 This check will only detect mesh refinement for triangle and quadrilateral 2D elements and, tetrahedral and hexahedral 3D
-elements. For tetrahedrals, because the refinement pattern depends on the selection of a diagonal inside the coarse element,
+elements. For tetrahedra, because the refinement pattern depends on the selection of a diagonal inside the coarse element,
 the check only considers the `tip` fine elements on the four vertex of the coarse element.
 
 !alert note

framework/doc/content/source/postprocessors/AreaPostprocessor.md

@@ -1,6 +1,6 @@
 # AreaPostprocessor
 
-The AreaPostprocesor is a SidePostprocessor that computes the area or dimension - 1 "volume" of a given side of the mesh. This
+The AreaPostprocessor is a SidePostprocessor that computes the area or dimension - 1 "volume" of a given side of the mesh. This
 postprocessor may be applied to one or more boundaries simultaneously, the latter case produces a total area is output.
 
 # Description and Syntax

framework/doc/content/source/variables/MooseVariableFV.md

@@ -63,7 +63,7 @@ For background on the functor system see [Functors/index.md].
   `FaceArg` `limiter_type`. On external faces this will generally return a two
   term expansion using the cell center value and gradient unless
   `two_term_boundary_expansion` has been set to `false`. On Dirichlet faces this
-  will return the Diriclet value
+  will return the Dirichlet value
 - `ElemQpArg`: this forwards to `ElemPointArg` where the `point` is simply the
   quadrature point location
 - `ElemSideQpArg`: same as `ElemQpArg`

framework/doc/content/syntax/Adaptivity/index.md

@@ -24,8 +24,8 @@ higher than their parents.
 ## P-Refinement
 
 P-refinement level mismatches are not supported for continuous, non-hierarchic
-finite element families. Additionally, p-refinement of NEDELEC_ONE is not
-supported. Consequently, by default we disable p-refinement of the bollowing
+finite element families. Additionally, p-refinement of `NEDELEC_ONE` is not
+supported. Consequently, by default we disable p-refinement of the following
 bases: `LAGRANGE`, `NEDELEC_ONE`, `LAGRANGE_VEC`, `CLOUGH`, `BERNSTEIN`, and
 `RATIONAL_BERNSTEIN`. Users can control what families are disabled for
 p-refinement by setting the `disable_p_refinement_for_families` parameter.

framework/doc/content/syntax/ICs/index.md

@@ -37,9 +37,9 @@ these DOFs, the initial condition system has an optional override for supplying
 ## Inspecting Current Node or Element Pointers
 
 The initial condition system uses a generic projection algorithm for setting the initial condition
-for each supported discritization scheme. In the general case, the projection system may choose
+for each supported discretization scheme. In the general case, the projection system may choose
 to sample anywhere within the domain and not necessarily right on a mesh node or at an element center
-position. However, for common FE discritizations suchs as Lagrange, all of the initial condition
+position. However, for common FE discretizations such as Lagrange, all of the initial condition
 samples are taken at nodes. To support these common cases, InitialCondition derived objects have
 access to pointers to both current nodes and current elements. These will be non-null when
 samples are taken at the corresponding mesh entity and null otherwise.

framework/doc/content/syntax/Limiters/index.md

@@ -23,7 +23,7 @@ TV(u^{n+1}) \leq TV(u^n)
 ## Limiting Process
 
 Borrowing notation from [!citep](greenshields2010implementation), we will now
-discuss computation of limited quanties, represented by $\bm{\Psi}_{f\pm}$ where
+discuss computation of limited quantities, represented by $\bm{\Psi}_{f\pm}$ where
 $+$ represents one side of a face, and $-$ represents the other side. To be
 clear about notation: the equations that follow will have a lot of $\pm$ and
 $\mp$. When computing the top quantity (e.g. $+$ for $\pm$) we select the top

framework/doc/content/syntax/Mesh/Partitioner/index.md

@@ -5,7 +5,7 @@ to split up a mesh among two or more processors. There are several partitioners
 available in both PETSc and libMesh which can be directly dialed up through the
 MOOSE input file via the [/LibmeshPartitioner.md] and [/PetscExternalPartitioner.md]
 objects. Custom Partitioners may be built by inheriting from MoosePartitioner.md
-and overriding the special `_do_parition()` method (from libMesh's partitioner).
+and overriding the special `_do_partition()` method (from libMesh's partitioner).
 
 !syntax list /Mesh/Partitioner objects=True actions=False subsystems=False