From 11af2c56e7143582dee1f1c80d9d51945c38e82f Mon Sep 17 00:00:00 2001
From: bangerth <bangerth@0785d39b-7218-0410-832d-ea1e28bc413d>
Date: Mon, 11 Jun 2012 10:14:03 +0000
Subject: [PATCH] Comment on the refinement criterion.

git-svn-id: https://svn.dealii.org/trunk@25621 0785d39b-7218-0410-832d-ea1e28bc413d
---
 deal.II/examples/step-43/doc/intro.dox   |  5 ++++-
 deal.II/examples/step-43/doc/results.dox | 10 ++++++++++
 2 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/deal.II/examples/step-43/doc/intro.dox b/deal.II/examples/step-43/doc/intro.dox
index 998e3f35a4..f0532e4bd1 100644
--- a/deal.II/examples/step-43/doc/intro.dox
+++ b/deal.II/examples/step-43/doc/intro.dox
@@ -308,7 +308,10 @@ computed by
 where $\nabla S_h(\mathbf x_K)$ is the gradient of the discrete saturation
 variable evaluated at the center $\mathbf x_K$ of cell $K$. This approach is
 analogous to ones frequently used in compressible flow problems, where density
-gradients are used to indicate refinement.
+gradients are used to indicate refinement. That said, as we will
+discuss at the end of the <a href="#Results">results section</a>, this turns
+out to not be a very useful criterion since it leads to refinement basically
+everywhere. We only show it here for illustrative purposes.
 
 
 <h3>Linear system and its preconditioning.</h3>
diff --git a/deal.II/examples/step-43/doc/results.dox b/deal.II/examples/step-43/doc/results.dox
index cbc8d7dac4..f07f8e2fc5 100644
--- a/deal.II/examples/step-43/doc/results.dox
+++ b/deal.II/examples/step-43/doc/results.dox
@@ -99,3 +99,13 @@ recomputed is appropriate; one may, for example, suggest that it is
 also important to decide whether (and by how much) a wrong velocity
 field in fact affects the solution of the saturation equation. This
 would then naturally lead to a sensitivity analysis.
+
+From an algorithmic viewpoint, we have here used a criterion for refinement
+that is often used in engineering, namely by looking at the gradient of
+the solution. However, if you inspect the solution, you will find that
+it quickly leads to refinement almost everywhere, even in regions where it
+is clearly not necessary: frequently used therefore does not need to imply
+that it is a useful criterion to begin with. On the other hand, replacing
+this criterion by a different and better one should not be very difficult.
+For example, the KellyErrorEstimator class used in many other programs
+should certainly be applicable to the current problem as well.
-- 
2.39.5