From: Wolfgang Bangerth <bangerth@colostate.edu>
Date: Wed, 27 Apr 2022 19:26:44 +0000 (-0600)
Subject: Mention DataPostprocessors::BoundaryIds in the glossary.
X-Git-Tag: v9.4.0-rc1~277^2~6
X-Git-Url: https://gitweb.dealii.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=59e5ad0d04874f43256a0e2d8b84368fe72a33cf;p=dealii.git

Mention DataPostprocessors::BoundaryIds in the glossary.
---

diff --git a/doc/doxygen/headers/glossary.h b/doc/doxygen/headers/glossary.h
index 54983236a5..2731d43117 100644
--- a/doc/doxygen/headers/glossary.h
+++ b/doc/doxygen/headers/glossary.h
@@ -346,6 +346,43 @@
  * VectorTools::interpolate_boundary_values,
  * VectorTools::compute_no_normal_flux_constraints.
  *
+ * It is often useful to visualize the boundary indicators used on different
+ * parts of the boundary of a domain. For example, when reading in a complex
+ * mesh generated by an external program, one typically wants to verify
+ * that what is *believed* to be the assignment of boundary indicators is
+ * indeed what is in the mesh file, or maybe equally importantly, what deal.II
+ * has read in from the mesh file. This can be done by using the
+ * DataPostprocessors::BoundaryIds class and the following small piece of code:
+ * @code
+ *    DataPostprocessors::BoundaryIds<dim> boundary_ids;
+ *    DataOutFaces<dim> data_out_faces;
+ *    FE_Q<dim>         dummy_fe(1);
+ *
+ *    DoFHandler<dim>   dummy_dof_handler(triangulation);
+ *    dummy_dof_handler.distribute_dofs(dummy_fe);
+ *
+ *    Vector<double> dummy_solution (dummy_dof_handler.n_dofs());
+ *
+ *    data_out_faces.attach_dof_handler(dummy_dof_handler);
+ *    data_out_faces.add_data_vector(dummy_solution, boundary_ids);
+ *    data_out_faces.build_patches();
+ *
+ *    std::ofstream out("boundary_ids.vtu");
+ *    data_out_faces.write_vtu(out);
+ * @endcode
+ * The code requires setting up a dummy finite element, DoFHandler, and
+ * solution vector because that's what DataOutFaces works on. However,
+ * while the content of the dummy solution, evaluated on each face of the
+ * domain, is passed to the DataPostprocessors::BoundaryIds member functions,
+ * they simply ignore this information and only output information obtained
+ * from the mesh (namely, the boundary indicators).
+ *
+ * The example code above uses FE_Q as the finite element. This is appropriate
+ * when the mesh consists of quadrilateral or hexahedral meshes. When using
+ * simplex meshes (triangular, tetrahedral), FE_SimplexP is the right choice.
+ * Mixed meshes will require a bit more work, but the general idea should be
+ * clear.
+ *
  * @note Boundary indicators are inherited from mother faces and edges to
  * their children upon mesh refinement. Some more information about boundary
  * indicators is also presented in a section of the documentation of the