From: David Wells <drwells@email.unc.edu>
Date: Tue, 18 May 2021 15:02:43 +0000 (-0400)
Subject: Run codespell
X-Git-Tag: v9.3.0-rc1~41^2
X-Git-Url: https://gitweb.dealii.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=refs%2Fpull%2F12238%2Fhead;p=dealii.git

Run codespell
---

diff --git a/examples/step-19/doc/intro.dox b/examples/step-19/doc/intro.dox
index faed96ac74..a0067bd1af 100644
--- a/examples/step-19/doc/intro.dox
+++ b/examples/step-19/doc/intro.dox
@@ -243,7 +243,7 @@ zero velocity will roughly pick up equal velocity increments in each successive
 time step if the electric field it encounters along the way were roughly
 constant. So the maximal difference between $\|\mathbf v_i^{(n-1)}\|$ and
 $\|\mathbf v_i^{(n)}\|$ would be a factor of two. As a consequence,
-we will choose $c_\text{saftey}=0.5$.
+we will choose $c_\text{safety}=0.5$.
 
 There is only one other case we ought to consider: What happens in
 the very first time step? There, any particles to be moved along have just
@@ -331,7 +331,7 @@ and call `insert_particle`. The only thing that may be surprising is
 the reference location: In order to evaluate things such as
 $\nabla V(\mathbf x_i)$, it is necessary to evaluate finite element
 fields at locations $\mathbf x_i$. But this requires evaluating the
-finite element shape functions at points on the refence cell
+finite element shape functions at points on the reference cell
 $\hat{\mathbf x}_i$. To make this efficient, every particle doesn't
 just store its location and the cell it is on, but also what location
 that point corresponds to in the cell's reference coordinate system.
@@ -418,7 +418,7 @@ field lines are also shown). The green part of the boundary is the anode,
 held at $V=+V_0$. The rest of the boundary satisfies a Neumann boundary
 condition.
 
-This setup mimicks real devices. The re-entrant corner results in an
+This setup mimics real devices. The re-entrant corner results in an
 electric potential $V$ whose derivative (the electric field $\mathbf E$)
 has a singularity -- in other words, it becomes very large in the vicinity
 of the corner, allowing it to rip electrons away from the metal. These
@@ -447,7 +447,7 @@ Of practical interest is to figure out which fraction of the
 electrons emitted from the cathode actually make it through the
 hole in the anode -- electrons that just bounce into the anode
 itself are not actually doing anything useful other than converting
-eletricity into heat. As a consequence, in the `track_lost_particle()`
+electricity into heat. As a consequence, in the `track_lost_particle()`
 function (which is called for each particle that leaves the domain,
 see above), we will estimate where it might have left the domain
 and report this in the output.
diff --git a/examples/step-26/step-26.cc b/examples/step-26/step-26.cc
index ff5e54ce72..6a672fc0e3 100644
--- a/examples/step-26/step-26.cc
+++ b/examples/step-26/step-26.cc
@@ -396,7 +396,7 @@ namespace Step26
     // solution vector, i.e., to make sure that the values of degrees of
     // freedom located on hanging nodes are so that the solution is
     // continuous. This is necessary since SolutionTransfer only operates on
-    // cells locally, without regard to the neighborhoof.
+    // cells locally, without regard to the neighborhood.
     triangulation.execute_coarsening_and_refinement();
     setup_system();
 
diff --git a/examples/step-27/step-27.cc b/examples/step-27/step-27.cc
index 34297f1c2f..b253c4850f 100644
--- a/examples/step-27/step-27.cc
+++ b/examples/step-27/step-27.cc
@@ -470,7 +470,7 @@ namespace Step27
   // The following function is used when creating the initial grid. The grid we
   // would like to create is actually similar to the one from step-14, i.e., the
   // square domain with the square hole in the middle. It can be generated by
-  // excatly the same function. However, since its implementation is only a
+  // exactly the same function. However, since its implementation is only a
   // specialization of the 2d case, we will present a different way of creating
   // this domain which is dimension independent.
   //
diff --git a/examples/step-33/step-33.cc b/examples/step-33/step-33.cc
index aae7684239..aa64b0721a 100644
--- a/examples/step-33/step-33.cc
+++ b/examples/step-33/step-33.cc
@@ -1113,7 +1113,7 @@ namespace Step33
       prm.declare_entry("mesh",
                         "grid.inp",
                         Patterns::Anything(),
-                        "intput file name");
+                        "input file name");
 
       prm.declare_entry("diffusion power",
                         "2.0",
diff --git a/examples/step-50/step-50.cc b/examples/step-50/step-50.cc
index d3c50e34c7..0ed27598bb 100644
--- a/examples/step-50/step-50.cc
+++ b/examples/step-50/step-50.cc
@@ -374,7 +374,7 @@ bool Settings::try_parse(const std::string &prm_filename)
 // MatrixFreeOperators::LaplaceOperator class which defines `local_apply()`,
 // `compute_diagonal()`, and `set_coefficient()` functions internally. Note that
 // the polynomial degree is a template parameter of this class. This is
-// necesary for the matrix-free code.
+// necessary for the matrix-free code.
 template <int dim, int degree>
 class LaplaceProblem
 {
@@ -919,7 +919,7 @@ void LaplaceProblem<dim, degree>::assemble_multigrid()
 // Finally, the system_rhs vector is of type LA::MPI::Vector, but the
 // MatrixFree class only work for
 // dealii::LinearAlgebra::distributed::Vector.  Therefore we must
-// compute the right-hand side using MatrixFree funtionality and then
+// compute the right-hand side using MatrixFree functionality and then
 // use the functions in the `ChangeVectorType` namespace to copy it to
 // the correct type.
 template <int dim, int degree>
diff --git a/examples/step-67/doc/intro.dox b/examples/step-67/doc/intro.dox
index 183784f17e..7c258b8c16 100644
--- a/examples/step-67/doc/intro.dox
+++ b/examples/step-67/doc/intro.dox
@@ -170,7 +170,7 @@ Riemann solvers. For the Euler equations, there exist so-called exact Riemann
 solvers -- meaning that the states from both sides are combined in a way that
 is consistent with the Euler equations along a discontinuity -- and
 approximate Riemann solvers, which violate some physical properties and rely
-on other mechanisms to render the scheme accurate overall. Approxiate Riemann
+on other mechanisms to render the scheme accurate overall. Approximate Riemann
 solvers have the advantage of beging cheaper to compute. Most flux functions
 have their origin in the finite volume community, which are similar to DG
 methods with polynomial degree 0 within the cells (called volumes). As the
diff --git a/examples/step-71/doc/results.dox b/examples/step-71/doc/results.dox
index c6f5ed3157..f3a375edfa 100644
--- a/examples/step-71/doc/results.dox
+++ b/examples/step-71/doc/results.dox
@@ -309,7 +309,7 @@ There are a few logical ways in which this program could be extended:
   magnetic hysteretic effects or damage models for the composite polymer that these material
   seek to model.
 - Of course, the implemented models could be modified or completely replaced with models that are
-  focussed on other aspects of physics, such as electro-active polymers, biomechanical materials,
+  focused on other aspects of physics, such as electro-active polymers, biomechanical materials,
   elastoplastic media, etc.
 - Implement a different time-discretization scheme for the viscoelastic evolution law.
 - Instead of deriving everything directly from an energy density function, use the
diff --git a/examples/step-71/step-71.cc b/examples/step-71/step-71.cc
index ba33757af0..5389f9e113 100644
--- a/examples/step-71/step-71.cc
+++ b/examples/step-71/step-71.cc
@@ -1673,7 +1673,7 @@ namespace Step71
       // Next is the symbolic representation of the saturation function for
       // the elastic part of the free energy density function, followed by the
       // magnetoelastic contribution to the free energy density function.
-      // This all has the same stucture as we'd seen previously.
+      // This all has the same structure as we'd seen previously.
       const Differentiation::SD::Expression f_mu_e_sd =
         1.0 +
         (mu_e_inf_sd / mu_e_sd - 1.0) *
@@ -3893,7 +3893,7 @@ namespace Step71
             material_assisted_computation.update_end_of_timestep();
           }
 
-          // ... and test for discrepencies between the two.
+          // ... and test for discrepancies between the two.
           check_material_class_results(material_hand_calculated,
                                        material_assisted_computation);
 
diff --git a/examples/step-74/step-74.cc b/examples/step-74/step-74.cc
index 8ff6389825..e82c462596 100644
--- a/examples/step-74/step-74.cc
+++ b/examples/step-74/step-74.cc
@@ -531,7 +531,7 @@ namespace Step74
     // The following lambda function will then copy data into the
     // global matrix and right-hand side.  Though there are no hanging
     // node constraints in DG discretization, we define an empty
-    // AffineConstraints oject that allows us to use the
+    // AffineConstraints object that allows us to use the
     // AffineConstraints::distribute_local_to_global() functionality.
     AffineConstraints<double> constraints;
     constraints.close();
diff --git a/include/deal.II/arborx/access_traits.h b/include/deal.II/arborx/access_traits.h
index 8625e959f2..0f3509ba85 100644
--- a/include/deal.II/arborx/access_traits.h
+++ b/include/deal.II/arborx/access_traits.h
@@ -30,7 +30,7 @@ namespace ArborXWrappers
 {
   /**
    * Base class for Point-based predicates providing basic functionality for
-   * dericed classes, not supposed to be used on its own.
+   * derived classes, not supposed to be used on its own.
    */
   class PointPredicate
   {
@@ -119,7 +119,7 @@ namespace ArborXWrappers
 
   /**
    * Base class for BoundingBox predicates providing basic functionality for
-   * dericed classes, not supposed to be used on its own.
+   * derived classes, not supposed to be used on its own.
    */
   class BoundingBoxPredicate
   {
diff --git a/include/deal.II/base/function_restriction.h b/include/deal.II/base/function_restriction.h
index e8db27f8e4..0714c83a1e 100644
--- a/include/deal.II/base/function_restriction.h
+++ b/include/deal.II/base/function_restriction.h
@@ -80,7 +80,7 @@ namespace Functions
     // The (`dim + 1`)-coordinate direction that has been restricted.
     const unsigned int restricted_direction;
 
-    // Value of the restriced coordinate.
+    // Value of the restricted coordinate.
     const double coordinate_value;
   };
 
diff --git a/include/deal.II/base/ndarray.h b/include/deal.II/base/ndarray.h
index 74b558e844..5d0250c6aa 100644
--- a/include/deal.II/base/ndarray.h
+++ b/include/deal.II/base/ndarray.h
@@ -90,7 +90,7 @@ namespace internal
  * @endcode
  * The repetitions of `std::array` look awkward and, worse, the index
  * ranges have reversed: the leftmost index has range [0,2), the middle
- * index has rnage [0,3) and the rightmost index has range [0,4).
+ * index has range [0,3) and the rightmost index has range [0,4).
  * We address this issue by providing a class ndarray that allows to you
  * declare the above stacked `std::array` type by simply writing:
  * @code
diff --git a/include/deal.II/base/vectorization.h b/include/deal.II/base/vectorization.h
index b780aa5517..a58a4aaf04 100644
--- a/include/deal.II/base/vectorization.h
+++ b/include/deal.II/base/vectorization.h
@@ -176,7 +176,7 @@ public:
   }
 
   /**
-   * This operator advances the iterator by @p offet lanes and returns a
+   * This operator advances the iterator by @p offset lanes and returns a
    * reference to <tt>*this</tt>.
    */
   VectorizedArrayIterator<T> &
@@ -5011,7 +5011,7 @@ enum class SIMDComparison : int
  * whenever the control flow itself would depend on (computed) data. For
  * example, in case of a scalar data type the statement
  * <code>(left < right) ? true_value : false_value</code>
- * could have been also implementd using an <code>if</code>-statement:
+ * could have been also implemented using an <code>if</code>-statement:
  * @code
  * if (left < right)
  *     result = true_value;
diff --git a/include/deal.II/distributed/shared_tria.h b/include/deal.II/distributed/shared_tria.h
index 358ce8ebdc..d967fe7661 100644
--- a/include/deal.II/distributed/shared_tria.h
+++ b/include/deal.II/distributed/shared_tria.h
@@ -232,7 +232,7 @@ namespace parallel
       /**
        * Constructor.
        *
-       * The flag @p allow_artificial_cells can be used to enable artifical
+       * The flag @p allow_artificial_cells can be used to enable artificial
        * cells. If enabled, this class will behave similarly
        * to parallel::distributed::Triangulation and
        * parallel::fullydistributed::Triangulation in the sense that there will
@@ -248,9 +248,9 @@ namespace parallel
        * updates lead to communication only with the direct process neighbors in
        * a point-to-point fashion, these degenerate to an operation in which
        * every process communicates with every other process (an "all-to-all"
-       * communication) if no artifical cells are available. If such ghost-value
-       * updates are the bottleneck in your code, you may want to consider
-       * enabling artificial cells.
+       * communication) if no artificial cells are available. If such
+       * ghost-value updates are the bottleneck in your code, you may want to
+       * consider enabling artificial cells.
        */
       Triangulation(
         const MPI_Comm &mpi_communicator,
diff --git a/include/deal.II/distributed/tria.h b/include/deal.II/distributed/tria.h
index 44a7b37202..5883275c2b 100644
--- a/include/deal.II/distributed/tria.h
+++ b/include/deal.II/distributed/tria.h
@@ -1030,9 +1030,9 @@ namespace parallel
      *
      * The TemporarilyMatchRefineFlags class should only be used in
      * combination with the Triangulation::Signals::post_p4est_refinement
-     * signal. At this stage, the p4est orcale already has been refined, but
+     * signal. At this stage, the p4est oracle already has been refined, but
      * the triangulation is still unchanged. After the modification, all
-     * refine and coarsen flags describe how the traingulation will acutally
+     * refine and coarsen flags describe how the traingulation will actually
      * be refined.
      *
      * The use of this class is demonstrated in step-75.
diff --git a/include/deal.II/dofs/dof_handler.h b/include/deal.II/dofs/dof_handler.h
index e747df95c8..551f109fb9 100644
--- a/include/deal.II/dofs/dof_handler.h
+++ b/include/deal.II/dofs/dof_handler.h
@@ -1598,7 +1598,7 @@ private:
    * Pointer to the first cached degree of freedom of a geometric object for all
    * relevant active finite elements.
    *
-   * @note In normal mode it is possible to access this data strucutre directly.
+   * @note In normal mode it is possible to access this data structure directly.
    *   In hp-mode, an indirection via hp_object_fe_indices/hp_object_fe_ptr is
    * necessary.
    */
@@ -1665,7 +1665,7 @@ private:
 
   /**
    * A list of connections with which this object connects to the
-   * triangulation. They get triggered specifially when data needs to be
+   * triangulation. They get triggered specifically when data needs to be
    * transferred due to refinement or repartitioning. Only active in hp-mode.
    */
   std::vector<boost::signals2::connection> tria_listeners_for_transfer;
diff --git a/include/deal.II/fe/fe_update_flags.h b/include/deal.II/fe/fe_update_flags.h
index 93e7002a21..a94474d320 100644
--- a/include/deal.II/fe/fe_update_flags.h
+++ b/include/deal.II/fe/fe_update_flags.h
@@ -581,7 +581,7 @@ namespace internal
       HessianVector shape_hessians;
 
       /**
-       * Store the 3nd derivatives of the shape functions at the quadrature
+       * Store the 3rd derivatives of the shape functions at the quadrature
        * points.  See the description of the data type for the layout of the
        * data in this field.
        */
diff --git a/include/deal.II/grid/connectivity.h b/include/deal.II/grid/connectivity.h
index 70fb2e2e03..0f845c8d54 100644
--- a/include/deal.II/grid/connectivity.h
+++ b/include/deal.II/grid/connectivity.h
@@ -977,7 +977,7 @@ namespace internal
                 {
                   // face is visited the second time -> now we know the cells
                   // on both sides of the face and we can determine for both
-                  // cells the neigbor
+                  // cells the neighbor
                   col_cc[j_0] = neighbors[col_cf[j_0]].first;
                   col_cc[neighbors[col_cf[j_0]].second] = i_0;
                 }
diff --git a/include/deal.II/grid/grid_tools_cache_update_flags.h b/include/deal.II/grid/grid_tools_cache_update_flags.h
index 4e164ffd37..d8d861dc60 100644
--- a/include/deal.II/grid/grid_tools_cache_update_flags.h
+++ b/include/deal.II/grid/grid_tools_cache_update_flags.h
@@ -80,7 +80,7 @@ namespace GridTools
     update_locally_owned_cell_bounding_boxes_rtree = 0x080,
 
     /**
-     * Update vertex to neighbhor subdomain
+     * Update vertex to neighbor subdomain
      */
     update_vertex_to_neighbor_subdomain = 0x100,
 
diff --git a/include/deal.II/lac/petsc_vector_base.h b/include/deal.II/lac/petsc_vector_base.h
index ed2d67096b..f40f44f276 100644
--- a/include/deal.II/lac/petsc_vector_base.h
+++ b/include/deal.II/lac/petsc_vector_base.h
@@ -94,7 +94,7 @@ namespace PETScWrappers
 
     public:
       /*
-       * Copy constrcutor.
+       * Copy constructor.
        */
       VectorReference(const VectorReference &vector) = default;
 
diff --git a/include/deal.II/matrix_free/fe_evaluation.h b/include/deal.II/matrix_free/fe_evaluation.h
index 512a63439f..2e8fbbcc2a 100644
--- a/include/deal.II/matrix_free/fe_evaluation.h
+++ b/include/deal.II/matrix_free/fe_evaluation.h
@@ -8828,7 +8828,7 @@ FEFaceEvaluation<dim,
       const auto face_orientations = this->compute_face_orientations();
 
 #  ifdef DEBUG
-      // currently on structured meshes are supported -> face numers and
+      // currently on structured meshes are supported -> face numbers and
       // orientations have to be the same for all filled lanes
       for (unsigned int v = 1; v < VectorizedArrayType::size(); ++v)
         {
diff --git a/include/deal.II/numerics/data_out_dof_data.templates.h b/include/deal.II/numerics/data_out_dof_data.templates.h
index c4ed973eef..cae34457c3 100644
--- a/include/deal.II/numerics/data_out_dof_data.templates.h
+++ b/include/deal.II/numerics/data_out_dof_data.templates.h
@@ -85,7 +85,7 @@ namespace internal
 
 
     /**
-     * Generate evalution points on a simplex with arbitrary number of
+     * Generate evaluation points on a simplex with arbitrary number of
      * subdivisions.
      */
     template <int dim>
diff --git a/include/deal.II/numerics/data_out_stack.h b/include/deal.II/numerics/data_out_stack.h
index d7423a001d..dbc01d1b37 100644
--- a/include/deal.II/numerics/data_out_stack.h
+++ b/include/deal.II/numerics/data_out_stack.h
@@ -58,7 +58,7 @@ public:
 
 /**
  * This class is used to stack the output from several computations into one
- * output file by stacking the data sets in another co-ordinate direction
+ * output file by stacking the data sets in another coordinate direction
  * orthogonal to the space directions. The most common use is to stack the
  * results of several time steps into one space-time output file, or for
  * example to connect the results of solutions of a parameter dependent
diff --git a/include/deal.II/numerics/rtree.h b/include/deal.II/numerics/rtree.h
index a1ea58a8cc..1b9d04dacd 100644
--- a/include/deal.II/numerics/rtree.h
+++ b/include/deal.II/numerics/rtree.h
@@ -388,7 +388,7 @@ struct ExtractLevelVisitor
  * processes. The finest level of information is given by the leaves, which in
  * this context would be the collection of all the bounding boxes associated
  * to the locally owned cells of the triangulation. Exchanging this information
- * with all participating processess would defeat the purpuse of parallel
+ * with all participating processes would defeat the purpuse of parallel
  * computations. If however one constructs an RTree containing these bounding
  * boxes (for example, by calling
  * GridTools::Cache::get_cell_bounding_boxes_rtree()), and then extracts one of
diff --git a/include/deal.II/numerics/smoothness_estimator.h b/include/deal.II/numerics/smoothness_estimator.h
index 366bbea101..1ef89230cf 100644
--- a/include/deal.II/numerics/smoothness_estimator.h
+++ b/include/deal.II/numerics/smoothness_estimator.h
@@ -267,7 +267,7 @@ namespace SmoothnessEstimator
    * @f}
    * with $u_j$ the degrees of freedom and $\varphi_j$ the corresponding shape
    * functions. $\{\phi_{\bf k}({\bf x}) = \exp(i \, 2 \pi \, {\bf k} \cdot
-   * {\bf x}) \}$ are expoential functions on cell $K$. $a_{\bf k}$ and ${\cal
+   * {\bf x}) \}$ are exponential functions on cell $K$. $a_{\bf k}$ and ${\cal
    * F}_{{\bf k},j}$ are coefficients and transformation matrices from the
    * Fourier expansion of each shape function. For practical reasons, we will
    * perform the calculation of these matrices and coefficients only on the
diff --git a/include/deal.II/numerics/vector_tools_evaluate.h b/include/deal.II/numerics/vector_tools_evaluate.h
index 6864b832c8..21a6e03b27 100644
--- a/include/deal.II/numerics/vector_tools_evaluate.h
+++ b/include/deal.II/numerics/vector_tools_evaluate.h
@@ -189,16 +189,17 @@ namespace VectorTools
 
     Assert(cache.is_ready(),
            ExcMessage(
-             "Utilties::MPI::RemotePointEvaluation is not ready yet! "
-             "Please call Utilties::MPI::RemotePointEvaluation::reinit() "
+             "Utilities::MPI::RemotePointEvaluation is not ready yet! "
+             "Please call Utilities::MPI::RemotePointEvaluation::reinit() "
              "yourself or the other evaluate_at_points(), which does this for"
              "you."));
 
-    Assert(&dof_handler.get_triangulation() == &cache.get_triangulation(),
-           ExcMessage(
-             "The provided Utilties::MPI::RemotePointEvaluation and DoFHandler "
-             "object have been set up with different Triangulation objects, "
-             "a scenario not supported!"));
+    Assert(
+      &dof_handler.get_triangulation() == &cache.get_triangulation(),
+      ExcMessage(
+        "The provided Utilities::MPI::RemotePointEvaluation and DoFHandler "
+        "object have been set up with different Triangulation objects, "
+        "a scenario not supported!"));
 
     // evaluate values at points if possible
     const auto evaluation_point_results = [&]() {
diff --git a/include/deal.II/opencascade/utilities.h b/include/deal.II/opencascade/utilities.h
index f7172f5abd..3b2f216dd2 100644
--- a/include/deal.II/opencascade/utilities.h
+++ b/include/deal.II/opencascade/utilities.h
@@ -144,7 +144,7 @@ namespace OpenCASCADE
    * shape and the mesh, to control the shape and regularity of the triangles
    * you should use other meshing softwares. The two arguments `deflection` and
    * `angular_deflection` select the accuracy of the created triangulation with
-   * respect to the orginal topological shape. The argument
+   * respect to the original topological shape. The argument
    * `sew_different_faces` gives the possibility to use a Sewer from OpenCASCADE
    * to create a watertight closed STL using the argument `sewer_tolerance`. The
    * argument `is_relative` specifies if distance are relative and `in_parallel`
diff --git a/include/deal.II/particles/particle.h b/include/deal.II/particles/particle.h
index 797bd7c7f2..a2e9c43845 100644
--- a/include/deal.II/particles/particle.h
+++ b/include/deal.II/particles/particle.h
@@ -105,7 +105,7 @@ namespace Particles
      * specified ID at the specified location. Note that there is no check for
      * duplicate particle IDs so the user must make sure the IDs are unique over
      * all processes. Data is stored in a global PropertyPool object
-     * (corresponding to the global "heap") but can later be transfered to
+     * (corresponding to the global "heap") but can later be transferred to
      * another property pool by calling set_property_pool().
      *
      * @param[in] location Initial location of particle.
@@ -121,7 +121,7 @@ namespace Particles
      * Copy-constructor for Particle. This function creates a particle with
      * exactly the state of the input argument. The copied data is stored in a
      * global PropertyPool object (corresponding to the global "heap") but can
-     * later be transfered to another property pool by calling
+     * later be transferred to another property pool by calling
      * set_property_pool().
      */
     Particle(const Particle<dim, spacedim> &particle);
@@ -129,7 +129,7 @@ namespace Particles
     /**
      * Constructor for Particle. This function creates a particle from a data
      * vector. Data is stored in a global PropertyPool object (corresponding to
-     * the global "heap") but can later be transfered to another property pool
+     * the global "heap") but can later be transferred to another property pool
      * by calling set_property_pool(). This constructor is usually called after
      * serializing a particle by calling the write_data() function.
      *
@@ -274,7 +274,7 @@ namespace Particles
     /**
      * Return the ID number of this particle. The ID of a particle is intended
      * to be a property that is globally unique even in parallel computations
-     * and is transfered along with other properties of a particle if it
+     * and is transferred along with other properties of a particle if it
      * moves from a cell owned by the current processor to a cell owned by
      * a different processor, or if ownership of the cell it is on is
      * transferred to a different processor.
@@ -285,7 +285,7 @@ namespace Particles
     /**
      * Set the ID number of this particle. The ID of a particle is intended
      * to be a property that is globally unique even in parallel computations
-     * and is transfered along with other properties of a particle if it
+     * and is transferred along with other properties of a particle if it
      * moves from a cell owned by the current processor to a cell owned by
      * a different processor, or if ownership of the cell it is on is
      * transferred to a different processor. As a consequence, when setting
@@ -625,7 +625,7 @@ namespace Particles
   inline bool
   Particle<dim, spacedim>::has_properties() const
   {
-    // Particles always have a property pool asssociated with them,
+    // Particles always have a property pool associated with them,
     // but we can access properties only if there is a valid handle.
     // The only way a particle can have no valid handle if it has
     // been moved-from -- but that leaves an object in an invalid
diff --git a/include/deal.II/particles/particle_handler.h b/include/deal.II/particles/particle_handler.h
index 4edfb8525f..e1954f5134 100644
--- a/include/deal.II/particles/particle_handler.h
+++ b/include/deal.II/particles/particle_handler.h
@@ -335,7 +335,7 @@ namespace Particles
      * Create and insert a number of particles into the collection of particles.
      * This function takes a list of positions and creates a set of particles
      * at these positions, which are then distributed and added to the local
-     * particle collection of a procesor. Note that this function uses
+     * particle collection of a processor. Note that this function uses
      * GridTools::distributed_compute_point_locations(). Consequently, it can
      * require intense communications between the processors. This function
      * is used in step-70.
@@ -374,7 +374,7 @@ namespace Particles
      *
      * @param[in] properties (Optional) A vector of vector of properties
      * associated with each local point. The size of the vector should be either
-     * zero (no properties will be transfered nor attached to the generated
+     * zero (no properties will be transferred nor attached to the generated
      * particles) or it should be a vector of `positions.size()` vectors of size
      * `n_properties_per_particle()`. Notice that this function call will
      * transfer the properties from the local mpi process to the final mpi
@@ -403,7 +403,7 @@ namespace Particles
      * Insert a number of particles into the collection of particles. This
      * function takes a list of particles for which we don't know the associated
      * cell iterator, and distributes them to the correct local particle
-     * collection of a procesor, by unpacking the locations, figuring out where
+     * collection of a processor, by unpacking the locations, figuring out where
      * to send the particles by calling
      * GridTools::distributed_compute_point_locations(), and sending the
      * particles to the corresponding process.
@@ -513,7 +513,7 @@ namespace Particles
     /**
      * Set the position of the particles within the particle handler using a
      * function with spacedim components. The new set of point defined by the
-     * fuction has to be sufficiently close to the original one to ensure that
+     * function has to be sufficiently close to the original one to ensure that
      * the sort_particles_into_subdomains_and_cells algorithm manages to find
      * the new cells in which the particles belong.
      *
@@ -995,7 +995,7 @@ namespace Particles
 
     /**
      * Cache structure used to store the elements which are required to
-     * exchange the particle information (location and properties) accross
+     * exchange the particle information (location and properties) across
      * processors in order to update the ghost particles. This structure
      * is only used to update the ghost particles.
      */
diff --git a/include/deal.II/particles/partitioner.h b/include/deal.II/particles/partitioner.h
index b9fc11d837..2a7ef41c5b 100644
--- a/include/deal.II/particles/partitioner.h
+++ b/include/deal.II/particles/partitioner.h
@@ -28,7 +28,7 @@ namespace Particles
   {
     /**
      * Cache structure used to store the elements which are required to
-     * exchange the particle information (location and properties) accross
+     * exchange the particle information (location and properties) across
      * processors in order to update the ghost particles.
      *
      * This structure should only be used when one wishes to carry out work
diff --git a/include/deal.II/sundials/arkode.h b/include/deal.II/sundials/arkode.h
index 559f76562d..16ea245344 100644
--- a/include/deal.II/sundials/arkode.h
+++ b/include/deal.II/sundials/arkode.h
@@ -931,7 +931,7 @@ namespace SUNDIALS
      *
      * Arguments to the function are
      *
-     * @param[in] v  The vector to be mulitplied by the Jacobian
+     * @param[in] v  The vector to be multiplied by the Jacobian
      * @param[out] Jv The vector to be filled with the product J*v
      * @param[in] t  The current time
      * @param[in] y  The current $y$ vector for the current ARKode internal
@@ -993,7 +993,7 @@ namespace SUNDIALS
     /**
      * A LinearSolveFunction object that users may supply and that is intended
      * to solve the linearized system $Ax=b$, where $A = M-\gamma J$ is the
-     * Jacobian of the nonlinear residual. The application fo the mass matrix
+     * Jacobian of the nonlinear residual. The application of the mass matrix
      * $M$ and Jacobian $J$ are known through the functions mass_times_vector()
      * and jacobian_times_vector() and $\gamma$ is a factor provided by
      * SUNDIALS. The matrix-vector product $Ax$ is encoded in the supplied
diff --git a/include/deal.II/sundials/ida.h b/include/deal.II/sundials/ida.h
index 80aaa6984a..5c549b7956 100644
--- a/include/deal.II/sundials/ida.h
+++ b/include/deal.II/sundials/ida.h
@@ -841,7 +841,7 @@ namespace SUNDIALS
      * components of your system.
      *
      * When running in parallel, every process will call this function
-     * independently, and syncronization will happen at the end of the
+     * independently, and synchronization will happen at the end of the
      * initialization setup to communicate what components are local. Make sure
      * you only return the locally owned (or locally relevant) components, in
      * order to minimize communication between processes.
diff --git a/include/deal.II/sundials/n_vector.h b/include/deal.II/sundials/n_vector.h
index cbe58f426a..1b0353fa07 100644
--- a/include/deal.II/sundials/n_vector.h
+++ b/include/deal.II/sundials/n_vector.h
@@ -98,7 +98,7 @@ namespace SUNDIALS
     /**
      * A view to a vector which can be used whenever a N_Vector is required.
      *
-     * Objects of this class should preferrably be created by
+     * Objects of this class should preferably be created by
      * make_nvector_view() as
      *
      * @code
diff --git a/include/deal.II/sundials/n_vector.templates.h b/include/deal.II/sundials/n_vector.templates.h
index 4c1b8bc2ce..ee6294cd6d 100644
--- a/include/deal.II/sundials/n_vector.templates.h
+++ b/include/deal.II/sundials/n_vector.templates.h
@@ -60,14 +60,14 @@ namespace SUNDIALS
     public:
       /**
        * Create a non-owning content with an existing @p vector.
-       * @param vector The underlying vector to wrap in thi object.
+       * @param vector The underlying vector to wrap in this object.
        */
       NVectorContent(VectorType *vector);
 
       /**
        * Create a non-owning content with an existing const @p vector. If this
        * constructor is used, access is only allowed via the get() const method.
-       * @param vector The underlying vector to wrap in thi object.
+       * @param vector The underlying vector to wrap in this object.
        */
       NVectorContent(const VectorType *vector);
 
diff --git a/source/base/tensor_product_polynomials.cc b/source/base/tensor_product_polynomials.cc
index 8bb03217cf..280f51b806 100644
--- a/source/base/tensor_product_polynomials.cc
+++ b/source/base/tensor_product_polynomials.cc
@@ -210,7 +210,7 @@ TensorProductPolynomials<dim, PolynomialType>::compute_grad(
   // compute values and
   // uni-directional derivatives at
   // the given point in each
-  // co-ordinate direction
+  // coordinate direction
   ndarray<double, dim, 2> v;
   {
     std::vector<double> tmp(2);
@@ -617,7 +617,7 @@ AnisotropicPolynomials<dim>::compute_grad(const unsigned int i,
   // compute values and
   // uni-directional derivatives at
   // the given point in each
-  // co-ordinate direction
+  // coordinate direction
   ndarray<double, dim, 2> v;
   for (unsigned int d = 0; d < dim; ++d)
     polynomials[d][indices[d]].value(p(d), 1, v[d].data());
diff --git a/source/fe/fe.cc b/source/fe/fe.cc
index 8792bec013..f6ff33e1c0 100644
--- a/source/fe/fe.cc
+++ b/source/fe/fe.cc
@@ -1332,7 +1332,7 @@ FiniteElement<dim, spacedim>::fill_fe_face_values(
                                                                      spacedim>
     &output_data) const
 {
-  // base class version, implement overriden function in derived classes
+  // base class version, implement overridden function in derived classes
   AssertDimension(quadrature.size(), 1);
   fill_fe_face_values(cell,
                       face_no,
diff --git a/source/fe/fe_abf.cc b/source/fe/fe_abf.cc
index 463292c324..4c6b68a133 100644
--- a/source/fe/fe_abf.cc
+++ b/source/fe/fe_abf.cc
@@ -112,7 +112,7 @@ FE_ABF<dim>::FE_ABF(const unsigned int deg)
         ++target_row;
       }
 
-  // We need to initialize the dof permuation table and the one for the sign
+  // We need to initialize the dof permutation table and the one for the sign
   // change.
   initialize_quad_dof_index_permutation_and_sign_change();
 }
diff --git a/source/fe/fe_bdm.cc b/source/fe/fe_bdm.cc
index a8ea21bbbd..5173e03254 100644
--- a/source/fe/fe_bdm.cc
+++ b/source/fe/fe_bdm.cc
@@ -104,7 +104,7 @@ FE_BDM<dim>::FE_BDM(const unsigned int deg)
         ++target_row;
       }
 
-  // We need to initialize the dof permuation table and the one for the sign
+  // We need to initialize the dof permutation table and the one for the sign
   // change.
   initialize_quad_dof_index_permutation_and_sign_change();
 }
diff --git a/source/fe/fe_bernardi_raugel.cc b/source/fe/fe_bernardi_raugel.cc
index 92339842a9..6d3da61195 100644
--- a/source/fe/fe_bernardi_raugel.cc
+++ b/source/fe/fe_bernardi_raugel.cc
@@ -67,7 +67,7 @@ FE_BernardiRaugel<dim>::FE_BernardiRaugel(const unsigned int p)
   // points
   initialize_support_points();
 
-  // We need to initialize the dof permuation table and the one for the sign
+  // We need to initialize the dof permutation table and the one for the sign
   // change.
   initialize_quad_dof_index_permutation_and_sign_change();
 }
diff --git a/source/fe/fe_nedelec.cc b/source/fe/fe_nedelec.cc
index d09993dc41..687aa2139a 100644
--- a/source/fe/fe_nedelec.cc
+++ b/source/fe/fe_nedelec.cc
@@ -207,7 +207,7 @@ FE_Nedelec<dim>::FE_Nedelec(const unsigned int order)
         Assert(false, ExcNotImplemented());
     }
 
-  // We need to initialize the dof permuation table and the one for the sign
+  // We need to initialize the dof permutation table and the one for the sign
   // change.
   initialize_quad_dof_index_permutation_and_sign_change();
 }
diff --git a/source/fe/fe_nedelec_sz.cc b/source/fe/fe_nedelec_sz.cc
index 7952b3d169..96d8751457 100644
--- a/source/fe/fe_nedelec_sz.cc
+++ b/source/fe/fe_nedelec_sz.cc
@@ -148,7 +148,7 @@ FE_NedelecSZ<dim, spacedim>::get_data(
 
   const unsigned int n_line_dofs = this->n_dofs_per_line() * lines_per_cell;
 
-  // we assume that all quads have the same numer of dofs
+  // we assume that all quads have the same number of dofs
   const unsigned int n_face_dofs = this->n_dofs_per_quad(0) * faces_per_cell;
 
   const UpdateFlags  flags(data.update_each);
@@ -420,7 +420,7 @@ FE_NedelecSZ<dim, spacedim>::get_data(
                   // point (x,y): polyx = L_{i+2}(2x-1), polyy = L_{j+2}(2y-1),
                   //
                   // for each polyc[d], c=x,y, contains the d-th derivative with
-                  // respect to the co-ordinate c.
+                  // respect to the coordinate c.
 
                   // We only need poly values and 1st derivative for
                   // update_values, but need the 2nd derivative too for
@@ -864,7 +864,7 @@ FE_NedelecSZ<dim, spacedim>::get_data(
                       // L_{j+2}(2y-1), polyz = L_{k+2}(2z-1).
                       //
                       // for each polyc[d], c=x,y,z, contains the d-th
-                      // derivative with respect to the co-ordinate c.
+                      // derivative with respect to the coordinate c.
                       std::vector<std::vector<double>> polyx(
                         degree, std::vector<double>(poly_length));
                       std::vector<std::vector<double>> polyy(
@@ -1697,7 +1697,7 @@ FE_NedelecSZ<dim, spacedim>::fill_face_values(
           // Loop through quad points:
           for (unsigned int m = 0; m < faces_per_cell; ++m)
             {
-              // we assume that all quads have the same numer of dofs
+              // we assume that all quads have the same number of dofs
               const unsigned int shift_m(m * this->n_dofs_per_quad(0));
               // Calculate the offsets for each face-based shape function:
               //
diff --git a/source/fe/fe_raviart_thomas.cc b/source/fe/fe_raviart_thomas.cc
index 3a50b6f64c..bcf3513c5f 100644
--- a/source/fe/fe_raviart_thomas.cc
+++ b/source/fe/fe_raviart_thomas.cc
@@ -110,7 +110,7 @@ FE_RaviartThomas<dim>::FE_RaviartThomas(const unsigned int deg)
         ++target_row;
       }
 
-  // We need to initialize the dof permuation table and the one for the sign
+  // We need to initialize the dof permutation table and the one for the sign
   // change.
   initialize_quad_dof_index_permutation_and_sign_change();
 }
diff --git a/source/fe/fe_raviart_thomas_nodal.cc b/source/fe/fe_raviart_thomas_nodal.cc
index 75c72f1299..086679cb46 100644
--- a/source/fe/fe_raviart_thomas_nodal.cc
+++ b/source/fe/fe_raviart_thomas_nodal.cc
@@ -115,7 +115,7 @@ FE_RaviartThomasNodal<dim>::FE_RaviartThomasNodal(const unsigned int deg)
         ++target_row;
       }
 
-  // We need to initialize the dof permuation table and the one for the sign
+  // We need to initialize the dof permutation table and the one for the sign
   // change.
   initialize_quad_dof_index_permutation_and_sign_change();
 }
diff --git a/source/fe/fe_rt_bubbles.cc b/source/fe/fe_rt_bubbles.cc
index a5064d363e..bd3b3ce960 100644
--- a/source/fe/fe_rt_bubbles.cc
+++ b/source/fe/fe_rt_bubbles.cc
@@ -107,7 +107,7 @@ FE_RT_Bubbles<dim>::FE_RT_Bubbles(const unsigned int deg)
         ++target_row;
       }
 
-  // We need to initialize the dof permuation table and the one for the sign
+  // We need to initialize the dof permutation table and the one for the sign
   // change.
   initialize_quad_dof_index_permutation_and_sign_change();
 }
diff --git a/source/fe/mapping.cc b/source/fe/mapping.cc
index 18e0fa6e48..b075dd6b65 100644
--- a/source/fe/mapping.cc
+++ b/source/fe/mapping.cc
@@ -158,7 +158,7 @@ Mapping<dim, spacedim>::fill_fe_face_values(
   dealii::internal::FEValuesImplementation::MappingRelatedData<dim, spacedim>
     &output_data) const
 {
-  // base class version, implement overriden function in derived classes
+  // base class version, implement overridden function in derived classes
   AssertDimension(quadrature.size(), 1);
   fill_fe_face_values(cell, face_no, quadrature[0], internal_data, output_data);
 }
@@ -193,7 +193,7 @@ Mapping<dim, spacedim>::get_face_data(
   const UpdateFlags               update_flags,
   const hp::QCollection<dim - 1> &quadrature) const
 {
-  // base class version, implement overriden function in derived classes
+  // base class version, implement overridden function in derived classes
   return get_face_data(update_flags, quadrature[0]);
 }
 
diff --git a/source/fe/mapping_q_cache.cc b/source/fe/mapping_q_cache.cc
index 563dbc0289..4cfba57b6d 100644
--- a/source/fe/mapping_q_cache.cc
+++ b/source/fe/mapping_q_cache.cc
@@ -406,7 +406,7 @@ MappingQCache<dim, spacedim>::initialize(
       std::vector<Point<spacedim>> result;
 
       // Step 2b) read of quadrature points in the relative displacement case
-      // note: we also take this path for non-active or artifical cells so that
+      // note: we also take this path for non-active or artificial cells so that
       // these cells are filled with some useful data
       if (vector_describes_relative_displacement ||
           is_active_non_artificial_cell == false)
@@ -612,7 +612,7 @@ MappingQCache<dim, spacedim>::initialize(
       std::vector<Point<spacedim>> result;
 
       // Step 2b) read of quadrature points in the relative displacement case
-      // note: we also take this path for non-active or artifical cells so that
+      // note: we also take this path for non-active or artificial cells so that
       // these cells are filled with some useful data
       if (vector_describes_relative_displacement ||
           (is_non_artificial_cell == false))
diff --git a/source/grid/grid_out.cc b/source/grid/grid_out.cc
index d2a99be179..2f7cd9009f 100644
--- a/source/grid/grid_out.cc
+++ b/source/grid/grid_out.cc
@@ -1555,7 +1555,7 @@ GridOut::write_msh(const Triangulation<dim, spacedim> &tria,
   std::vector<std::vector<std::vector<std::size_t>>> element_nodes(
     n_entity_tags, std::vector<std::vector<std::size_t>>(8));
 
-  // One elment id counter for all dimensions.
+  // One element id counter for all dimensions.
   std::size_t element_id = 1;
 
   const auto add_element = [&](const auto &element, const int &entity_tag) {
diff --git a/source/numerics/derivative_approximation.cc b/source/numerics/derivative_approximation.cc
index 5871717ade..38a424f5ce 100644
--- a/source/numerics/derivative_approximation.cc
+++ b/source/numerics/derivative_approximation.cc
@@ -676,7 +676,7 @@ namespace DerivativeApproximation
     public:
       /**
        * alias to select the DerivativeDescription corresponding to the
-       * <tt>order</tt>th derivative. In this general template we set an unvalid
+       * <tt>order</tt>th derivative. In this general template we set an invalid
        * alias to void, the real alias have to be specialized.
        */
       using DerivDescr = void;