From e403683e0b1b82ece97811a98e9a785c8cd6f1c7 Mon Sep 17 00:00:00 2001 From: Wolfgang Bangerth Date: Tue, 3 Mar 2015 18:49:54 -0600 Subject: [PATCH] Clarify a statement in the documentation of step-8. --- examples/step-8/step-8.cc | 30 ++++++++++++++---------------- 1 file changed, 14 insertions(+), 16 deletions(-) diff --git a/examples/step-8/step-8.cc b/examples/step-8/step-8.cc index 98e3def95f..74b01ee845 100644 --- 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 Gauss 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 support 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 refine_global function is not part of the - // GridRefinement class in which - // refine_and_coarsen_fixed_number 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 - // GridRefinement 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 void ElasticProblem::run () { -- 2.39.5