The output of the program looks as follows:
<pre><code>
Cycle 0:
- Number of active cells: 20
+ Number of active cells: 20
+ Number of degrees of freedom: 89
Cycle 1:
- Number of active cells: 44
+ Number of active cells: 44
+ Number of degrees of freedom: 209
Cycle 2:
- Number of active cells: 86
+ Number of active cells: 92
+ Number of degrees of freedom: 449
Cycle 3:
- Number of active cells: 164
+ Number of active cells: 200
+ Number of degrees of freedom: 961
Cycle 4:
- Number of active cells: 344
+ Number of active cells: 440
+ Number of degrees of freedom: 2033
Cycle 5:
- Number of active cells: 656
+ Number of active cells: 932
+ Number of degrees of freedom: 4465
Cycle 6:
- Number of active cells: 1364
+ Number of active cells: 1916
+ Number of degrees of freedom: 9113
Cycle 7:
- Number of active cells: 2684
+ Number of active cells: 3884
+ Number of degrees of freedom: 18457
</code></pre>
</p>
<p>
-As intended, the number of cells roughly doubles in each cycle. The
-final solution, as written by the program, looks as follows:
+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
+dimensions on an infinite grid (since the spacing between the degrees
+of freedom is half the cell width: one additional degree of freedom on
+each edge and one in the middle of each cell), but it is larger than
+that factor due to the finite size and due to additional degrees of
+freedom which are introduced due to hanging nodes and local
+refinement.
+</p>
+
+<p>
+The final solution, as written by the program, looks as follows:
</p>
<p>
</p>
+<p>
+For completeness, we show what happens if the destructor is omitted
+from this example.
+</p>
+<pre><code>
+--------------------------------------------------------
+An error occurred in line <20> of file <source/subscriptor.cc> in function
+ Subscriptor::~Subscriptor()
+The violated condition was:
+ counter == 0
+The name and call sequence of the exception was:
+ InUse()
+Additional Information:
+This object is still used by 1 other objects.
+--------------------------------------------------------
+</code></pre>
+</p>
+<p>
+From the above error message, it is difficult to infer what has
+actually happened. A stack backtrace in the debugger at least tells us
+what object is presently destructed:
+<pre><code>
+#0 0x4004b0d1 in __kill () at soinit.c:27
+#1 0x4004aeff in raise (sig=6) at ../sysdeps/posix/raise.c:27
+#2 0x4004c19b in abort () at ../sysdeps/generic/abort.c:83
+#3 0x813e2b9 in void __IssueError_Assert<Subscriptor::InUse> (
+ file=0x8187223 "source/subscriptor.cc", line=20,
+ function=0x8187207 "Subscriptor::~Subscriptor()",
+ cond=0x81871fa "counter == 0", exc_name=0x81871f2 "InUse()",
+ e={<ExceptionBase> = {<exception> = {_vptr.exception = 0x8189a8c},
+ file = 0x8187223 "source/subscriptor.cc", line = 20,
+ function = 0x8187207 "Subscriptor::~Subscriptor()",
+ cond = 0x81871fa "counter == 0", exc = 0x81871f2 "InUse()"}, })
+ at /home/wolf/program/newdeal/deal.II/base/include/base/exceptions.h:382
+#4 0x80daa64 in Subscriptor::~Subscriptor (this=0xbffff534, __in_chrg=2)
+ at source/subscriptor.cc:20
+#5 0x8063d57 in FiniteElementBase<2>::~FiniteElementBase (this=0xbffff534,
+ __in_chrg=2) at source/fe/fe.cc:256
+#6 0x8063dd5 in FiniteElement<2>::~FiniteElement (this=0xbffff534,
+ __in_chrg=2)
+ at /home/wolf/program/newdeal/deal.II/deal.II/include/fe/fe.h:967
+#7 0x8074d55 in FEQ1Mapping<2>::~FEQ1Mapping (this=0xbffff534, __in_chrg=2)
+ at source/fe/q1_mapping.cc:726
+#8 0x806f625 in FEQ2<2>::~FEQ2 (this=0xbffff534, __in_chrg=2)
+ at source/fe/fe_lib.quadratic.cc:1095
+#9 0x80e9d5a in LaplaceProblem<2>::~LaplaceProblem (this=0xbffff084,
+ __in_chrg=2) at step-6.cc:306
+#10 0x804a783 in main () at step-6.cc:932
+</code></pre>
+Note that the debugger stops automatically at the point where the
+exception was thrown, you need not place a breakpoint. From frame 4 we
+see that the exception occured in the destructor of the
+``Subscriptor'' class, which is where the zeroness of the counter is
+checked. Frame 8 tells us that it is the ``fe'' object (which is of
+type ``FEQ2'') of the ``LaplaceProblem'' class, that resists its
+destruction.
+</p>
+
+<p>
+The one object that still uses the finite element is the
+``dof_handler'' object. This is usually difficult to find out since
+the ``Subscriptor'' class that stores the counter has no possibility
+to store which other object subscribed to it. However, by thinking a
+little bit about which objects use the one that is presently
+destructed, one usually quite quickly finds out where the problem is.
+</p>