Mention DataPostprocessors::BoundaryIds in the glossary.

diff --git a/doc/doxygen/headers/glossary.h b/doc/doxygen/headers/glossary.h
index 54983236a5a6577f28c56f48c8ed24bd3d113912..2731d43117cfe79c77fc5fba7c851a0b9b0348a3 100644 (file)
--- 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