From 5dbe4fc5433b31a045d1e55285fbacb1857c40ac Mon Sep 17 00:00:00 2001 From: wolf Date: Wed, 22 May 2002 07:15:55 +0000 Subject: [PATCH] Fix wording. git-svn-id: https://svn.dealii.org/trunk@5870 0785d39b-7218-0410-832d-ea1e28bc413d --- .../step-14.data/results.html | 23 ++----------------- 1 file changed, 2 insertions(+), 21 deletions(-) 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 981b3fcd0e..12ccd786bf 100644 --- 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: -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. -

- -

-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 1/r 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.

-- 2.39.5