Include a suggestion by Denis Davydov.

git-svn-id: https://svn.dealii.org/trunk@31853 0785d39b-7218-0410-832d-ea1e28bc413d

diff --git a/deal.II/examples/step-18/step-18.cc b/deal.II/examples/step-18/step-18.cc
index f587d740be24c21ced5e2358150636dafbfeeb5c..1d6347f8ab6bf630694946c8a37c294f91658dfe 100644 (file)
--- a/deal.II/examples/step-18/step-18.cc
+++ b/deal.II/examples/step-18/step-18.cc
@@ -1718,6 +1718,17 @@ namespace Step18
   // to the vertex we consider at present, as they may or may not be ordered
   // in the same order.
   //
+  // This inconvenience could be avoided if finite elements have support
+  // points on vertices (which the one here has; for the concept of support
+  // points, see @ref GlossSupport "support points"). For such a case, one
+  // could construct a custom quadrature rule using
+  // FiniteElement::get_unit_support_points(). The first
+  // <code>GeometryInfo@<dim@>::vertices_per_cell*fe.dofs_per_vertex</code>
+  // quadrature points will then correspond to the vertices of the cell and
+  // are ordered consistent with <code>cell-@>vertex(i)</code>, taking into
+  // account that support points for vector elements will be duplicated
+  // <code>fe.dofs_per_vertex</code> times.
+  //
   // Another point worth explaining about this short function is the way in
   // which the triangulation class exports information about its vertices:
   // through the <code>Triangulation::n_vertices</code> function, it