<h1>Results</h1>

<h3>Point values</h3>


This program offers a lot of possibilities to play around. We can thus
only show a small part of all possible results that can be obtained
with the help of this program. However, you are encouraged to just try
it out, by changing the settings in the main program. Here, we start
by simply letting it run, unmodified:
@code
Refinement cycle: 0
   Number of degrees of freedom: 72
   Point value: 0.03243
   Estimated error: 0.000702385
Refinement cycle: 1
   Number of degrees of freedom: 67
   Point value: 0.0324827
   Estimated error: 0.000888953
Refinement cycle: 2
   Number of degrees of freedom: 130
   Point value: 0.0329619
   Estimated error: 0.000454606
Refinement cycle: 3
   Number of degrees of freedom: 307
   Point value: 0.0331934
   Estimated error: 0.000241254
Refinement cycle: 4
   Number of degrees of freedom: 718
   Point value: 0.0333675
   Estimated error: 7.4912e-05
Refinement cycle: 5
   Number of degrees of freedom: 1665
   Point value: 0.0334083
   Estimated error: 3.69111e-05
Refinement cycle: 6
   Number of degrees of freedom: 3975
   Point value: 0.033431
   Estimated error: 1.54218e-05
Refinement cycle: 7
   Number of degrees of freedom: 8934
   Point value: 0.0334406
   Estimated error: 6.28359e-06
Refinement cycle: 8
   Number of degrees of freedom: 21799
   Point value: 0.0334444
@endcode


First let's look what the program actually computed. On the seventh
grid, primal and dual numerical solutions look like this (using a
color scheme intended to evoke the snow-capped mountains of
Colorado that the original author of this program now calls
home):
<table align="center">
  <tr>
    <td width="50%">
      <img src="https://www.dealii.org/images/steps/developer/step-14.point-value.solution-7.9.2.png" alt="">
    </td>
    <td width="50%">
      <img src="https://www.dealii.org/images/steps/developer/step-14.point-value.solution-7-dual.9.2.png" alt="">
    </td>
  </tr>
</table>
Apparently, the region at the bottom left is so unimportant for the
point value evaluation at the top right that the grid is left entirely
unrefined there, even though the solution has singularities at the inner
corner of that cell! Due
to the symmetry in right hand side and domain, the solution should
actually look like at the top right in all four corners, but the mesh
refinement criterion involving the dual solution chose to refine them
differently -- because we said that we really only care about a single
function value somewhere at the top right.



Here are some of the meshes that are produced in refinement cycles 0,
2, 4 (top row), and 5, 7, and 8 (bottom row):

<table width="80%" align="center">
  <tr>
    <td><img src="https://www.dealii.org/images/steps/developer/step-14.point-value.grid-0.9.2.png" alt="" width="100%"></td>
    <td><img src="https://www.dealii.org/images/steps/developer/step-14.point-value.grid-2.9.2.png" alt="" width="100%"></td>
    <td><img src="https://www.dealii.org/images/steps/developer/step-14.point-value.grid-4.9.2.png" alt="" width="100%"></td>
  </tr>
  <tr>
    <td><img src="https://www.dealii.org/images/steps/developer/step-14.point-value.grid-5.9.2.png" alt="" width="100%"></td>
    <td><img src="https://www.dealii.org/images/steps/developer/step-14.point-value.grid-7.9.2.png" alt="" width="100%"></td>
    <td><img src="https://www.dealii.org/images/steps/developer/step-14.point-value.grid-8.9.2.png" alt="" width="100%"></td>
  </tr>
</table>

Note the subtle interplay between resolving the corner singularities,
and resolving around the point of evaluation. It will be rather
difficult to generate such a mesh by hand, as this would involve to
judge quantitatively how much which of the four corner singularities
should be resolved, and to set the weight compared to the vicinity of
the evaluation point.



The program prints the point value and the estimated error in this
quantity. From extrapolating it, we can guess that the exact value is
somewhere close to 0.0334473, plus or minus 0.0000001 (note that we get
almost 6 valid digits from only 22,000 (primal) degrees of
freedom. This number cannot be obtained from the value of the
functional alone, but I have used the assumption that the error
estimator is mostly exact, and extrapolated the computed value plus
the estimated error, to get an approximation of the true
value. Computing with more degrees of freedom shows that this
assumption is indeed valid.



From the computed results, we can generate two graphs: one that shows
the convergence of the error $J(u)-J(u_h)$ (taking the
extrapolated value as correct) in the point value, and the value that
we get by adding up computed value $J(u_h)$ and estimated
error eta (if the error estimator $eta$ were exact, then the value
$J(u_h)+\eta$ would equal the exact point value, and the error
in this quantity would always be zero; however, since the error
estimator is only a - good - approximation to the true error, we can
by this only reduce the size of the error). In this graph, we also
indicate the complexity ${\cal O}(1/N)$ to show that mesh refinement
acts optimal in this case. The second chart compares
true and estimated error, and shows that the two are actually very
close to each other, even for such a complicated quantity as the point
value:


<table width="80%" align="center">
  <tr>
    <td><img src="https://www.dealii.org/images/steps/developer/step-14.point-value.error.png" alt="" width="100%"></td>
    <td><img src="https://www.dealii.org/images/steps/developer/step-14.point-value.error-estimation.png" alt="" width="100%"></td>
  </tr>
</table>


<h3>Comparing refinement criteria</h3>


Since we have accepted quite some effort when using the mesh
refinement driven by the dual weighted error estimator (for solving
the dual problem, and for evaluating the error representation), it is
worth while asking whether that effort was successful. To this end, we
first compare the achieved error levels for different mesh refinement
criteria. To generate this data, simply change the value of the mesh
refinement criterion variable in the main program. The results are
thus (for the weight in the Kelly indicator, we have chosen the
function $1/(r^2+0.1^2)$, where $r$
is the distance to the evaluation point; it can be shown that this is
the optimal weight if we neglect the effects of boundaries):

<img src="https://www.dealii.org/images/steps/developer/step-14.point-value.error-comparison.png" alt="">



Checking these numbers, we see that for global refinement, the error
is proportional to $O(1/(sqrt(N) log(N)))$, and for the dual
estimator $O(1/N)$. Generally speaking, we see that the dual
weighted error estimator is better than the other refinement
indicators, at least when compared with those that have a similarly
regular behavior. The Kelly indicator produces smaller errors, but
jumps about the picture rather irregularly, with the error also
changing signs sometimes. Therefore, its behavior does not allow to
extrapolate the results to larger values of N. Furthermore, if we
trust the error estimates of the dual weighted error estimator, the
results can be improved by adding the estimated error to the computed
values. In terms of reliability, the weighted estimator is thus better
than the Kelly indicator, although the latter sometimes produces
smaller errors.



<h3>Evaluation of point stresses</h3>


Besides evaluating the values of the solution at a certain point, the
program also offers the possibility to evaluate the x-derivatives at a
certain point, and also to tailor mesh refinement for this. To let the
program compute these quantities, simply replace the two occurrences of
<code>PointValueEvaluation</code> in the main function by
<code>PointXDerivativeEvaluation</code>, and let the program run:
@code
Refinement cycle: 0
   Number of degrees of freedom: 72
   Point x-derivative: -0.0719397
   Estimated error: -0.0126173
Refinement cycle: 1
   Number of degrees of freedom: 61
   Point x-derivative: -0.0707956
   Estimated error: -0.00774316
Refinement cycle: 2
   Number of degrees of freedom: 131
   Point x-derivative: -0.0568671
   Estimated error: -0.00313426
Refinement cycle: 3
   Number of degrees of freedom: 247
   Point x-derivative: -0.053033
   Estimated error: -0.00136114
Refinement cycle: 4
   Number of degrees of freedom: 532
   Point x-derivative: -0.0526429
   Estimated error: -0.000558868
Refinement cycle: 5
   Number of degrees of freedom: 1267
   Point x-derivative: -0.0526955
   Estimated error: -0.000220116
Refinement cycle: 6
   Number of degrees of freedom: 2864
   Point x-derivative: -0.0527495
   Estimated error: -9.46731e-05
Refinement cycle: 7
   Number of degrees of freedom: 6409
   Point x-derivative: -0.052785
   Estimated error: -4.21543e-05
Refinement cycle: 8
   Number of degrees of freedom: 14183
   Point x-derivative: -0.0528028
   Estimated error: -2.04241e-05
Refinement cycle: 9
   Number of degrees of freedom: 29902
   Point x-derivative: -0.052814
@endcode



The solution looks roughly the same as before (the exact solution of
course <em>is</em> the same, only the grid changed a little), but the
dual solution is now different. A close-up around the point of
evaluation shows this:
<table align="center">
  <tr>
    <td width="50%">
      <img src="https://www.dealii.org/images/steps/developer/step-14.point-derivative.solution-7-dual.png" alt="">
    </td>
    <td width="50%">
      <img src="https://www.dealii.org/images/steps/developer/step-14.point-derivative.solution-7-dual-close-up.png" alt="">
    </td>
</table>
This time, the grids in refinement cycles 0, 5, 6, 7, 8, and 9 look
like this:

<table align="center" width="80%">
  <tr>
    <td><img src="https://www.dealii.org/images/steps/developer/step-14.point-derivative.grid-0.9.2.png" alt="" width="100%"></td>
    <td><img src="https://www.dealii.org/images/steps/developer/step-14.point-derivative.grid-5.9.2.png" alt="" width="100%"></td>
    <td><img src="https://www.dealii.org/images/steps/developer/step-14.point-derivative.grid-6.9.2.png" alt="" width="100%"></td>
  </tr>
  <tr>
    <td><img src="https://www.dealii.org/images/steps/developer/step-14.point-derivative.grid-7.9.2.png" alt="" width="100%"></td>
    <td><img src="https://www.dealii.org/images/steps/developer/step-14.point-derivative.grid-8.9.2.png" alt="" width="100%"></td>
    <td><img src="https://www.dealii.org/images/steps/developer/step-14.point-derivative.grid-9.9.2.png" alt="" width="100%"></td>
  </tr>
</table>

Note the asymmetry of the grids compared with those we obtained for
the point evaluation. This is due to the fact that the domain and the primal
solution may be symmetric about the diagonal, but the $x$-derivative is
not, and the latter enters the refinement criterion.



Then, it is interesting to compare actually computed values of the
quantity of interest (i.e. the x-derivative of the solution at one
point) with a reference value of -0.0528223... plus or minus
0.0000005. We get this reference value by computing on finer grid after
some more mesh refinements, with approximately 130,000 cells.
Recall that if the error is $O(1/N)$ in the optimal case, then
taking a mesh with ten times more cells gives us one additional digit
in the result.



In the left part of the following chart, you again see the convergence
of the error towards this extrapolated value, while on the right you
see a comparison of true and estimated error:

<table width="80%" align="center">
  <tr>
    <td><img src="https://www.dealii.org/images/steps/developer/step-14.point-derivative.error.png" alt="" width="100%"></td>
    <td><img src="https://www.dealii.org/images/steps/developer/step-14.point-derivative.error-estimation.png" alt="" width="100%"></td>
  </tr>
</table>

After an initial phase where the true error changes its sign, the
estimated error matches it quite well, again. Also note the dramatic
improvement in the error when using the estimated error to correct the
computed value of $J(u_h)$.



<h3>step-13 revisited</h3>


If instead of the <code>Exercise_2_3</code> data set, we choose
<code>CurvedRidges</code> in the main function, and choose $(0.5,0.5)$
as the evaluation point, then we can redo the
computations of the previous example program, to compare whether the
results obtained with the help of the dual weighted error estimator
are better than those we had previously.



First, the meshes after 9 adaptive refinement cycles obtained with
the point evaluation and derivative evaluation refinement
criteria, respectively, look like this:

<table width="80%" align="center">
  <tr>
    <td><img src="https://www.dealii.org/images/steps/developer/step-14.step-13.point-value.png" alt="" width="100%"></td>
    <td><img src="https://www.dealii.org/images/steps/developer/step-14.step-13.point-derivative.png" alt="" width="100%"></td>
  </tr>
</table>

The features of the solution can still be seen in the mesh, but since the
solution is smooth, the singularities of the dual solution entirely
dominate the mesh refinement criterion, and lead to strongly
concentrated meshes. The solution after the seventh refinement step looks
like the following:

<table width="40%" align="center">
  <tr>
    <td><img src="https://www.dealii.org/images/steps/developer/step-14.step-13.solution-7.9.2.png" alt="" width="100%"></td>
  </tr>
</table>

Obviously, the solution is worse at some places, but the mesh
refinement process should have taken care that these places are not
important for computing the point value.




The next point is to compare the new (duality based) mesh refinement
criterion with the old ones. These are the results:

<img src="https://www.dealii.org/images/steps/developer/step-14.step-13.error-comparison.png" alt="">



The results are, well, somewhat mixed. First, the Kelly indicator
disqualifies itself by its unsteady behavior, changing the sign of the
error several times, and with increasing errors under mesh
refinement. The dual weighted error estimator has a monotone decrease
in the error, and is better than the weighted Kelly and global
refinement, but the margin is not as large as expected. This is, here,
due to the fact the global refinement can exploit the regular
structure of the meshes around the point of evaluation, which leads to
a better order of convergence for the point error. However, if we had
a mesh that is not locally rectangular, for example because we had to
approximate curved boundaries, or if the coefficients were not
constant, then this advantage of globally refinement meshes would
vanish, while the good performance of the duality based estimator
would remain.




<h3>Conclusions and outlook</h3>


The results here are not too clearly indicating the superiority of the
dual weighted error estimation approach for mesh refinement over other
mesh refinement criteria, such as the Kelly indicator. This is due to
the relative simplicity of the shown applications. If you are not
convinced yet that this approach is indeed superior, you are invited
to browse through the literature indicated in the introduction, where
plenty of examples are provided where the dual weighted approach can
reduce the necessary numerical work by orders of magnitude, making
this the only way to compute certain quantities to reasonable
accuracies at all.



Besides the objections you may raise against its use as a mesh
refinement criterion, consider that accurate knowledge of the error in
the quantity one might want to compute is of great use, since we can
stop computations when we are satisfied with the accuracy. Using more
traditional approaches, it is very difficult to get accurate estimates
for arbitrary quantities, except for, maybe, the error in the energy
norm, and we will then have no guarantee that the result we computed
satisfies any requirements on its accuracy. Also, as was shown for the
evaluation of point values and derivatives, the error estimate can be
used to extrapolate the results, yielding much higher accuracy in the
quantity we want to know.



Leaving these mathematical considerations, we tried to write the
program in a modular way, such that implementing another test case, or
another evaluation and dual functional is simple. You are encouraged
to take the program as a basis for your own experiments, and to play a
little.
