Fix wording.

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

diff --git a/deal.II/doc/tutorial/chapter-2.step-by-step/step-14.data/results.html b/deal.II/doc/tutorial/chapter-2.step-by-step/step-14.data/results.html
index 981b3fcd0e8a6e3322669ed5b2826e30a60f753b..12ccd786bf872be7b1582c89069dfb9a1d98cd9b 100644 (file)
--- a/deal.II/doc/tutorial/chapter-2.step-by-step/step-14.data/results.html
+++ b/deal.II/doc/tutorial/chapter-2.step-by-step/step-14.data/results.html
@@ -384,27 +384,8 @@ see a comparison of true and estimated error:
     </td>
   </tr>
 </table>
-It is obvious that here the error estimates are not as good as
-previously, under-estimation the error by about a factor of 2-4. At
-least the sign is correct, leading to a slight improvement in the
-estimated values if we sum computed value and estimated error.
-</p>
-
-<p>
-The difference between true and estimated error can be tracked down to
-the bad approximation of the dual solution. After all, in 2d, the dual
-solution has a <em>1/r</em> singularity near the evaluation point
-(while the dual solution for the point value only has a logarithmic
-singularity there), which does not allow for a good approximation of
-the dual solution by any finite element space. Indeed, computing the
-dual solution with even higher order (i.e. cubic or quartic) finite
-elements does not significantly improve the quality of error
-estimates. Intuitively, the reason is that the numerical approximation
-cannot follow accurately the simgularity of the dual solution; its
-resulting values near the point of evaluation are thus too small, and
-the error is underestimated there. Since the error is very much
-concentrated near the point of evaluation, this spoils the entire
-estimate.
+After an initial phase where the true error changes its sign, the
+estimated error matches it quite well, again.
 </p>