Clarify a statement in the documentation of step-8.

diff --git a/examples/step-8/step-8.cc b/examples/step-8/step-8.cc
index 98e3def95f211e0c7bc1c85794463ed93e1a4ed0..74b01ee845eb1e2b3851488eff60f5b0d71b45a7 100644 (file)
--- a/examples/step-8/step-8.cc
+++ b/examples/step-8/step-8.cc
@@ -704,17 +704,22 @@ namespace Step8
   // example. This time, we use the square [-1,1]^d as domain, and we refine
   // it twice globally before starting the first iteration.
   //
-  // The reason is the following: we use the <code>Gauss</code> quadrature
+  // The reason for refining twice is a bit accidental: we use the QGauss quadrature
   // formula with two points in each direction for integration of the right
   // hand side; that means that there are four quadrature points on each cell
   // (in 2D). If we only refine the initial grid once globally, then there
   // will be only four quadrature points in each direction on the
   // domain. However, the right hand side function was chosen to be rather
-  // localized and in that case all quadrature points lie outside the support
-  // of the right hand side function. The right hand side vector will then
-  // contain only zeroes and the solution of the system of equations is the
-  // zero vector, i.e. a finite element function that it zero everywhere. We
-  // should not be surprised about such things happening, since we have chosen
+  // localized and in that case, by pure chance, it happens that all quadrature
+  // points lie at points where the the right hand side function is zero (in
+  // mathematical terms, the quadrature points happen to be at points outside
+  // the <i>support</i> of the right hand side function). The right hand side
+  // vector computed with quadrature will then contain only zeroes (even though
+  // it would of course be nonzero if we had computed the right hand side vector
+  // exactly using the integral) and the solution of the system of
+  // equations is the zero vector, i.e., a finite element function that is zero
+  // everywhere. In a sense, we
+  // should not be surprised that this is happening since we have chosen
   // an initial grid that is totally unsuitable for the problem at hand.
   //
   // The unfortunate thing is that if the discrete solution is constant, then
@@ -729,16 +734,9 @@ namespace Step8
   // The conclusion needs to be: while of course we will not choose the
   // initial grid to be well-suited for the accurate solution of the problem,
   // we must at least choose it such that it has the chance to capture the
-  // most striking features of the solution. In this case, it needs to be able
-  // to see the right hand side. Thus, we refine twice globally. (Note that
-  // the <code>refine_global</code> function is not part of the
-  // <code>GridRefinement</code> class in which
-  // <code>refine_and_coarsen_fixed_number</code> is declared, for
-  // example. The reason is first that it is not an algorithm that computed
-  // refinement flags from indicators, but more importantly that it actually
-  // performs the refinement, in contrast to the functions in
-  // <code>GridRefinement</code> that only flag cells without actually
-  // refining the grid.)
+  // important features of the solution. In this case, it needs to be able
+  // to see the right hand side. Thus, we refine twice globally. (Any larger
+  // number of global refinement steps would of course also work.)
   template <int dim>
   void ElasticProblem<dim>::run ()
   {