From: wolf Date: Tue, 11 Jan 2000 22:27:03 +0000 (+0000) Subject: Add some things to step-6. X-Git-Url: https://gitweb.dealii.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=17481a540d6317f89c02f78939022f650df17ca5;p=dealii-svn.git Add some things to step-6. git-svn-id: https://svn.dealii.org/trunk@2206 0785d39b-7218-0410-832d-ea1e28bc413d --- diff --git a/deal.II/doc/tutorial/chapter-2.step-by-step/step-6.intro b/deal.II/doc/tutorial/chapter-2.step-by-step/step-6.intro index 89dbe461bc..214e16574c 100644 --- a/deal.II/doc/tutorial/chapter-2.step-by-step/step-6.intro +++ b/deal.II/doc/tutorial/chapter-2.step-by-step/step-6.intro @@ -35,10 +35,17 @@ refined grids.

Since the concepts used for locally refined grids are so important, -we do not show much additional new stuff in this example. There will -be large regions in the code that are unaltered from the previous -example and which we will not comment on further. The only other new -thing is a method to catch exceptions in the ``main'' function in -order to output some information in case the program crashes for some -reason. +we do not show much additional new stuff in this example. The most +important exception is that we show how to use biquadratic elements +instead of the bilinear ones which we have used in all previous +examples. In fact, The use of higher order elements is accomplished by +only replacing three lines of the program, namely the declaration of +the ``fe'' variable, and the use of an appropriate quadrature formula +in two places. The rest of the program is unchanged. +

+ +

+The only other new thing is a method to catch exceptions in the +``main'' function in order to output some information in case the +program crashes for some reason.

diff --git a/deal.II/doc/tutorial/chapter-2.step-by-step/step-6.results b/deal.II/doc/tutorial/chapter-2.step-by-step/step-6.results index 26b30c11eb..eb0fcead04 100644 --- a/deal.II/doc/tutorial/chapter-2.step-by-step/step-6.results +++ b/deal.II/doc/tutorial/chapter-2.step-by-step/step-6.results @@ -5,27 +5,46 @@ The output of the program looks as follows: 

 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

-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. +

+ +

+The final solution, as written by the program, looks as follows:

@@ -92,4 +111,70 @@ from the optimal square.

+

+For completeness, we show what happens if the destructor is omitted +from this example. +

+

+--------------------------------------------------------
+An error occurred in line <20> of file  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.
+--------------------------------------------------------
+
+

+

+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: +


+#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 (
+    file=0x8187223 "source/subscriptor.cc", line=20, 
+    function=0x8187207 "Subscriptor::~Subscriptor()", 
+    cond=0x81871fa "counter == 0", exc_name=0x81871f2 "InUse()", 
+    e={ = { = {_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
+
+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. +

+ +

+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. +