From: David Wells 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=f982ad5c84a7753b0b86a2393d17f3744e244dfa;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(). * * *

Technical details

@@ -1629,7 +1631,7 @@ public: * A copy of @p manifold_object is created using * Manifold::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