From 0f632b72183b05507f9185f6ac7fb13269d04241 Mon Sep 17 00:00:00 2001
From: wolf
+
The output of the program looks as follows:
Results
-
-
Cycle 0:
@@ -29,9 +29,9 @@ Cycle 7:
Number of active cells: 3884
Number of degrees of freedom: 18401
+ + As intended, the number of cells roughly doubles in each cycle. The number of degrees is slightly more than four times the number of cells; one would expect a factor of exactly four in two spatial @@ -41,63 +41,63 @@ each edge and one in the middle of each cell), but it is larger than that factor due to the finite size of the mesh and due to additional degrees of freedom which are introduced by hanging nodes and local refinement. -
-
+
+
The final solution, as written by the program at the end of the
run()
function, looks as follows:
-
- -
-+ +@image html step-6.solution.png + + + In each cycle, the program furthermore writes the grid in EPS format. These are shown in the following: -
-+ +
- + @image html step-6.grid-0.png | - + @image html step-6.grid-1.png |
- + @image html step-6.grid-2.png | - + @image html step-6.grid-3.png |
- + @image html step-6.grid-4.png | - + @image html step-6.grid-5.png |
- + @image html step-6.grid-6.png | - + @image html step-6.grid-7.png |
+ + It is clearly visible that the region where the solution has a kink, i.e. the circle at radial distance 0.5 from the center, is refined most. Furthermore, the central region where the solution is @@ -107,15 +107,15 @@ coefficient is large there. The region outside is refined rather randomly, since the second derivative is constant there and refinement is therefore mostly based on the size of the cells and their deviation from the optimal square. -
-
+
+
For completeness, we show what happens if the code we commented about
in the destructor of the LaplaceProblem
class is omitted
from this example.
-
+
+@code
--------------------------------------------------------
An error occurred in line <79> of file <source/subscriptor.cc> in function
virtual Subscriptor::~Subscriptor()
@@ -137,13 +137,13 @@ Stacktrace:
#5 ./step-6: main
--------------------------------------------------------
make: *** [run] Aborted
-
-
+@endcode
+
+
-
From the above error message, we conclude that an object of type
-``10DoFHandlerILi2EE'' is still using the object of type
-``4FE_QILi2EE''. These are of course "mangled" names for
+10DoFHandlerILi2EE
is still using the object of type
+4FE_QILi2EE
. These are of course "mangled" names for
DoFHandler
and FE_Q
. The mangling works as
follows: the first number indicates the number of characters of the
template class, i.e. 10 for DoFHandler
and 4
@@ -151,14 +151,14 @@ forFE_Q
; the rest of the text is then template
arguments. From this we can already glean a little bit who's the
culprit here, and who the victim.:
The one object that still uses the finite element is the
-``dof_handler'' object.
-
dof_handler
object.
+
+
-
The stacktrace gives an indication of where the problem happened. We
see that the exception was triggered in the
destructor of the FiniteElement
class that was called
through a few more functions from the destructor of the
LaplaceProblem
class, exactly where we have commented out
the call to DoFHandler::clear()
.
-