From 0f632b72183b05507f9185f6ac7fb13269d04241 Mon Sep 17 00:00:00 2001 From: wolf Date: Tue, 28 Mar 2006 05:20:34 +0000 Subject: [PATCH] Generate results section out of doxygen as well. git-svn-id: https://svn.dealii.org/trunk@12704 0785d39b-7218-0410-832d-ea1e28bc413d --- .../step-6.data/{results.html => results.dox} | 70 +++++++++---------- 1 file changed, 35 insertions(+), 35 deletions(-) rename deal.II/doc/tutorial/chapter-2.step-by-step/step-6.data/{results.html => results.dox} (83%) diff --git a/deal.II/doc/tutorial/chapter-2.step-by-step/step-6.data/results.html b/deal.II/doc/tutorial/chapter-2.step-by-step/step-6.data/results.dox similarity index 83% rename from deal.II/doc/tutorial/chapter-2.step-by-step/step-6.data/results.html rename to deal.II/doc/tutorial/chapter-2.step-by-step/step-6.data/results.dox index 1470588678..eae75e8707 100644 --- a/deal.II/doc/tutorial/chapter-2.step-by-step/step-6.data/results.html +++ b/deal.II/doc/tutorial/chapter-2.step-by-step/step-6.data/results.dox @@ -1,7 +1,7 @@

Results

-

+ The output of the program looks as follows:


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

-

-final-solution -

-

+ +@image html step-6.solution.png + + + In each cycle, the program furthermore writes the grid in EPS format. These are shown in the following: -

-

+ +
-grid-0 + @image html step-6.grid-0.png -grid-1 + @image html step-6.grid-1.png
-grid-2 + @image html step-6.grid-2.png -grid-3 + @image html step-6.grid-3.png
-grid-4 + @image html step-6.grid-4.png -grid-5 + @image html step-6.grid-5.png
-grid-6 + @image html step-6.grid-6.png -grid-7 + @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(). -

+ -- 2.39.5