From 59e5ad0d04874f43256a0e2d8b84368fe72a33cf Mon Sep 17 00:00:00 2001 From: Wolfgang Bangerth Date: Wed, 27 Apr 2022 13:26:44 -0600 Subject: [PATCH] Mention DataPostprocessors::BoundaryIds in the glossary. --- doc/doxygen/headers/glossary.h | 37 ++++++++++++++++++++++++++++++++++ 1 file changed, 37 insertions(+) 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 boundary_ids; + * DataOutFaces data_out_faces; + * FE_Q dummy_fe(1); + * + * DoFHandler dummy_dof_handler(triangulation); + * dummy_dof_handler.distribute_dofs(dummy_fe); + * + * Vector 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 -- 2.39.5