From: David Wells <drwells@email.unc.edu>
Date: Sat, 24 Oct 2020 22:19:11 +0000 (-0400)
Subject: Remove two more references to the long removed Boundary class.
X-Git-Tag: v9.3.0-rc1~970^2
X-Git-Url: https://gitweb.dealii.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=refs%2Fpull%2F11101%2Fhead;p=dealii.git

Remove two more references to the long removed Boundary class.
---

diff --git a/doc/doxygen/headers/glossary.h b/doc/doxygen/headers/glossary.h
index 49fc2dbf58..b2ab2452c7 100644
--- a/doc/doxygen/headers/glossary.h
+++ b/doc/doxygen/headers/glossary.h
@@ -337,23 +337,6 @@
  * on each of the selected faces. To query the boundary indicator of a particular
  * face or edge, use TriaAccessor::boundary_id.
  *
- * In older versions of the library (prior to 8.2), if you wanted also
- * to change the way the Triangulation class treated the boundary for
- * the purposes of mesh refinement, you could call
- * Triangulation::set_boundary to associate a boundary object with a
- * particular boundary indicator. This method is still supported, and
- * it allows the Triangulation object to use a different method of
- * finding new points on faces and edges to be refined; the default is
- * to use a FlatManifold object for all faces and edges. The
- * results section of step-49 has a worked example that shows all of
- * this in action.
- *
- * The suggested method from version 8.2 onwards, is to split the
- * geometrical description of the boundary from its physical meaning,
- * by using separately manifold_ids and boundary_ids. The former are
- * used to describe how the geometry changes, and the latter are used
- * to identify the boundary conditions.
- *
  * Many of the functions in namespaces DoFTools and VectorTools take
  * arguments that specify which part of the boundary to work on, and
  * they specifically refer to boundary_ids. Examples are
diff --git a/include/deal.II/grid/tria.h b/include/deal.II/grid/tria.h
index f1221cc3d7..1f97433806 100644
--- a/include/deal.II/grid/tria.h
+++ b/include/deal.II/grid/tria.h
@@ -1009,17 +1009,19 @@ namespace internal
  * following information is not stored:
  *   - signals
  *   - pointers to Manifold objects previously set using
- * Triangulation::set_manifold On the other hand, since these are objects that
+ *     Triangulation::set_manifold()
+ *
+ * On the other hand, since these are objects that
  * are usually set in user code, they can typically easily be set again in that
  * part of your code in which you re-load triangulations.
  *
  * In a sense, this approach to serialization means that re-loading a
  * triangulation is more akin to calling the
- * Triangulation::create_triangulation function and filling it with some
+ * Triangulation::create_triangulation() function and filling it with some
  * additional content, as that function also does not touch the signals and
- * boundary objects that belong to this triangulation. In keeping with this
- * analogy, the Triangulation::load function also triggers the same kinds of
- * signal as Triangulation::create_triangulation.
+ * Manifold objects that belong to this triangulation. In keeping with this
+ * analogy, the Triangulation::load() function also triggers the same kinds of
+ * signal as Triangulation::create_triangulation().
  *
  *
  * <h3>Technical details</h3>
@@ -1629,7 +1631,7 @@ public:
    * A copy of @p manifold_object is created using
    * Manifold<dim, spacedim>::clone() and stored internally.
    *
-   * It is possible to remove or replace the boundary object during the
+   * It is possible to remove or replace a Manifold object during the
    * lifetime of a non-empty triangulation. Usually, this is done before the
    * first refinement and is dangerous afterwards. Removal of a manifold
    * object is done by reset_manifold(). This operation then replaces the