From: David Wells <wellsd2@rpi.edu>
Date: Mon, 12 Oct 2015 22:12:05 +0000 (-0400)
Subject: Fix some erroneous names in the documentation.
X-Git-Tag: v8.4.0-rc2~320^2
X-Git-Url: https://gitweb.dealii.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=316287bc0f94c3a87b112ed24137580f386ade8e;p=dealii.git

Fix some erroneous names in the documentation.

For example: deal.II contains a 'DoFRenumbering' namespace and does not
contain a 'DoFRenumber' namespace. I removed references to the latter.
---

diff --git a/include/deal.II/base/data_out_base.h b/include/deal.II/base/data_out_base.h
index ba80e2b0d5..998fd496f0 100644
--- a/include/deal.II/base/data_out_base.h
+++ b/include/deal.II/base/data_out_base.h
@@ -94,7 +94,7 @@ class XDMFEntry;
  * example, you may have higher order elements and printing the values at the
  * vertices only is not enough. For this reason, we not only provide writing
  * the data on the vertices only, but the data is organizes as a tensor
- * product grid on each cell. The parameter <tt>n_subdivision</tt>, which is
+ * product grid on each cell. The parameter <tt>n_subdivisions</tt>, which is
  * given for each patch separately, denotes how often the cell is to be
  * divided for output; for example, <tt>n_subdivisions==1</tt> yields no
  * subdivision of the cell, <tt>n_subdivisions==2</tt> will produce a grid of
@@ -226,7 +226,7 @@ namespace DataOutBase
    *
    * See the general documentation of the DataOutBase class for more
    * information on its contents and purposes.  In the case of two dimensions,
-   * the next picture is an example of <tt>n_subdivision</tt> = 4 because the
+   * the next picture is an example of <tt>n_subdivisions</tt> = 4 because the
    * number of (sub)cells within each patch is equal to
    * <tt>2<sup>dim</sup></tt>.
    *
diff --git a/include/deal.II/base/parallel.h b/include/deal.II/base/parallel.h
index e6f752d64b..164afa8272 100644
--- a/include/deal.II/base/parallel.h
+++ b/include/deal.II/base/parallel.h
@@ -390,7 +390,7 @@ namespace parallel
    * @endcode
    *
    * Note how we use the <code>std_cxx11::bind</code> function to convert
-   * <code>mat_vec_on_subranged</code> from a function that takes 5 arguments
+   * <code>mat_vec_on_subranges</code> from a function that takes 5 arguments
    * to one taking 2 by binding the remaining arguments (the modifiers
    * <code>std_cxx11::ref</code> and <code>std_cxx11::cref</code> make sure
    * that the enclosed variables are actually passed by reference and constant
diff --git a/include/deal.II/dofs/dof_renumbering.h b/include/deal.II/dofs/dof_renumbering.h
index f44dcddd3d..2b940130d5 100644
--- a/include/deal.II/dofs/dof_renumbering.h
+++ b/include/deal.II/dofs/dof_renumbering.h
@@ -162,7 +162,7 @@ DEAL_II_NAMESPACE_OPEN
  * The component_wise() function allows not only to honor enumeration based on
  * vector components, but also allows to group together vector components into
  * "blocks" using a defaulted argument to the various
- * DoFRenumber::component_wise() functions (see
+ * DoFRenumbering::component_wise() functions (see
  * @ref GlossComponent
  * vs
  * @ref GlossBlock
@@ -182,8 +182,8 @@ DEAL_II_NAMESPACE_OPEN
  * On the other hand, if you really want to use block structure reported by
  * the finite element itself (a case that is often the case if you have finite
  * elements that have multiple vector components, e.g. the FE_RaviartThomas or
- * FE_Nedelec elements) then you can use the DoFRenumber::block_wise instead
- * of the DoFRenumbering::component_wise functions.
+ * FE_Nedelec elements) then you can use the DoFRenumbering::block_wise
+ * instead of the DoFRenumbering::component_wise functions.
  *
  *
  * <h3>Cell-wise numbering</h3>