From: wolf Date: Tue, 28 Mar 2006 05:45:56 +0000 (+0000) Subject: Various fixes. Doxygenize step-7 X-Git-Url: https://gitweb.dealii.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=755dd2143ccc4cda37129051b5b71707197fd112;p=dealii-svn.git Various fixes. Doxygenize step-7 git-svn-id: https://svn.dealii.org/trunk@12705 0785d39b-7218-0410-832d-ea1e28bc413d --- diff --git a/deal.II/doc/tutorial/chapter-2.step-by-step/step-1.data/results.dox b/deal.II/doc/tutorial/chapter-2.step-by-step/step-1.data/results.dox index 754418b3c2..60cb962c79 100644 --- a/deal.II/doc/tutorial/chapter-2.step-by-step/step-1.data/results.dox +++ b/deal.II/doc/tutorial/chapter-2.step-by-step/step-1.data/results.dox @@ -7,11 +7,11 @@ like this:
- @image html step-1.grid-1.jpg + @image html step-1.grid-1.png - @image html step-1.grid-2.jpg + @image html step-1.grid-2.png
diff --git a/deal.II/doc/tutorial/chapter-2.step-by-step/step-4.data/intro.html b/deal.II/doc/tutorial/chapter-2.step-by-step/step-4.data/intro.dox similarity index 74% rename from deal.II/doc/tutorial/chapter-2.step-by-step/step-4.data/intro.html rename to deal.II/doc/tutorial/chapter-2.step-by-step/step-4.data/intro.dox index a7e72aaac7..e282d9e2b6 100644 --- a/deal.II/doc/tutorial/chapter-2.step-by-step/step-4.data/intro.html +++ b/deal.II/doc/tutorial/chapter-2.step-by-step/step-4.data/intro.dox @@ -1,16 +1,16 @@

Introduction

-

-deal.II has a unique feature which we call + +deal.II has a unique feature which we call ``dimension independent programming''. You may have noticed in the previous examples that many classes had a number in angle brackets suffixed to them. This is to indicate that for example the triangulation in two and three space dimensions are different, but related data types. We could as well have called them Triangulation2d and Triangulation3d instead -of Triangulation<2> and -Triangulation<3> to name the two classes, but this +of Triangulation@<2@> and +Triangulation@<3@> to name the two classes, but this has an important drawback: assume you have a function which does exactly the same functionality, but on 2d or 3d triangulations, depending on which dimension we would like to solve the equation in @@ -22,11 +22,11 @@ working on Triangulation2d and once working with a Triangulation3d. This is an unnecessary obstacle in programming and leads to a nuisance to keep the two function in synch (at best) or difficult to find errors if the two versions get out of -synch (at worst; this would probably the more common case). -

+sync (at worst; this would probably the more common case). + + -

Such obstacles can be circumvented by using some template magic as provided by the C++ language: templatized classes and functions are not really classes or functions but only a pattern depending on an @@ -37,97 +37,97 @@ it with the information that is needed for that. Of course, parts of the template can depend on the template parameters, and they will be resolved at the time of compilation for a specific template parameter. For example, consider the following piece of code: -


-  template <int dim>
-  void make_grid (Triangulation<dim> &triangulation)
+@code
+  template 
+  void make_grid (Triangulation &triangulation)
   {
     GridGenerator::hyper_cube (triangulation, -1, 1);
   };
-
-

+@endcode + + -

At the point where the compiler sees this function, it does not know -anything about the actual value of ``dim''. The only thing the compiler has is +anything about the actual value of dim. The only thing the compiler has is a template, i.e. a blueprint, to generate functions make_grid if given a particular value of -``dim''. Since ``dim'' has an unknown value, there is no +dim. Since dim has an unknown value, there is no code the compiler can generate for the moment. -

-

+ + However, if later down the compiler would encounter code that looks, for example, like this, -


-  Triangulation<2> triangulation;
+@code
+  Triangulation<2> triangulation;
   make_grid (triangulation);
-
+@endcode then the compiler will deduce that the function make_grid for dim==2 was requested and will compile the template above into a function with dim replaced by 2 everywhere, i.e. it will compile the function as if it were defined as -

-  void make_grid (Triangulation<2> &triangulation)
+@code
+  void make_grid (Triangulation<2> &triangulation)
   {
     GridGenerator::hyper_cube (triangulation, -1, 1);
   };
-
-

+@endcode + + -

However, it is worth to note that the function GridGenerator::hyper_cube depends on the dimension as well, so in this case, the compiler will call the function -GridGenerator::hyper_cube<2> while if dim were 3, -it would call GridGenerator::hyper_cube<3> which +GridGenerator::hyper_cube@<2@> while if dim were 3, +it would call GridGenerator::hyper_cube@<3@> which might be (and actually is) a totally unrelated function. -

-

+ + The same can be done with member variables. Consider the following function, which might in turn call the above one: -


-  template <int dim>
-  void make_grid_and_dofs (Triangulation<dim> &triangulation)
+@code
+  template 
+  void make_grid_and_dofs (Triangulation &triangulation)
   {
     make_grid (triangulation);
 
-    DoFHandler<dim> dof_handler(triangulation);
+    DoFHandler dof_handler(triangulation);
     ...
   };
-
+@endcode This function has a member variable of type -DoFHandler<dim>. Again, the compiler can't +DoFHandler@. Again, the compiler can't compile this function until it knows for which dimension. If you call this function for a specific dimension as above, the compiler will take the template, replace all occurences of dim by the dimension for which it was called, and compile it. If you call the function several times for different dimensions, it will compile it several times, each -time calling the right ``make_grid'' function and reserving the right +time calling the right make_grid function and reserving the right amount of memory for the member variable; note that the size of a DoFHandler might, and indeed does, depend on the space dimension. -

-

-The deal.II library is build around this concept + + +The deal.II library is build around this concept of dimension-independent programming, and therefore allows you to program in a way that will not need to distinguish between the space dimensions. It should be noted that in only a very few places is it necessary to actually compare the -dimension using ``if''s or ``switch''es. However, since the compiler +dimension using ifs or switches. However, since the compiler has to compile each function for each dimension separately, even there -it knows the value of ``dim'' at the time of compilation and will -therefore be able to optimize away the ``if'' statement along with the +it knows the value of dim at the time of compilation and will +therefore be able to optimize away the if statement along with the unused branch. -

-

+ + In this example program, we will show how to program dimension independently (which in fact is even simpler than if you had to take care about the dimension) and we will extend the Laplace problem of the last example to a program that runs in two and three space dimensions at the same time. Other extensions are the use of a non-constant right hand side function and of non-zero boundary values. -

+ diff --git a/deal.II/doc/tutorial/chapter-2.step-by-step/step-5.data/intro.html b/deal.II/doc/tutorial/chapter-2.step-by-step/step-5.data/intro.dox similarity index 99% rename from deal.II/doc/tutorial/chapter-2.step-by-step/step-5.data/intro.html rename to deal.II/doc/tutorial/chapter-2.step-by-step/step-5.data/intro.dox index 2de8f398a9..43e24bfd97 100644 --- a/deal.II/doc/tutorial/chapter-2.step-by-step/step-5.data/intro.html +++ b/deal.II/doc/tutorial/chapter-2.step-by-step/step-5.data/intro.dox @@ -1,7 +1,7 @@

Introduction

-

+ This example does not show revolutionary new things, but it shows many small improvements over the previous examples, and also many small things that can usually be found in finite element programs. Among @@ -35,4 +35,3 @@ them are: preconditioned iterative solvers for the linear systems of equations. -

diff --git a/deal.II/doc/tutorial/chapter-2.step-by-step/step-5.data/results.dox b/deal.II/doc/tutorial/chapter-2.step-by-step/step-5.data/results.dox index 44c133c8ba..3cd03c5bb0 100644 --- a/deal.II/doc/tutorial/chapter-2.step-by-step/step-5.data/results.dox +++ b/deal.II/doc/tutorial/chapter-2.step-by-step/step-5.data/results.dox @@ -36,8 +36,8 @@ Cycle 5: Number of degrees of freedom: 20609 182 CG iterations needed to obtain convergence. -------------------------------------------------------- -An error occurred in line <273> of file <step-5.cc> in function - void Coefficient<dim>::value_list(const std::vector<Point<dim>, std::allocator<Point<dim> > >&, std::vector<double, std::allocator<double> >&, unsigned int) +An error occurred in line <273> of file in function + void Coefficient::value_list(const std::vector, std::allocator > >&, std::vector >&, unsigned int) const [with int dim = 2] The violated condition was: values.size() == points.size() @@ -48,7 +48,7 @@ Dimension 1 not equal to 2 Stacktrace: ----------- -#0 ./step-5: Coefficient<2>::value_list(std::vector<Point<2>, std::allocator<Point<2> > > const&, std::vector<double, std::allocator<double> >&, unsigned) const +#0 ./step-5: Coefficient<2>::value_list(std::vector, std::allocator > > const&, std::vector >&, unsigned) const #1 ./step-5: main -------------------------------------------------------- make: *** [run] Aborted @@ -108,8 +108,8 @@ example. As for the error — let's look at it again: @code -------------------------------------------------------- -An error occurred in line <273> of file <step-5.cc> in function - void Coefficient<dim>::value_list(const std::vector<Point<dim>, std::allocator<Point<dim> > >&, std::vector<double, std::allocator<double> >&, unsigned int) +An error occurred in line <273> of file in function + void Coefficient::value_list(const std::vector, std::allocator > >&, std::vector >&, unsigned int) const [with int dim = 2] The violated condition was: values.size() == points.size() @@ -120,7 +120,7 @@ Dimension 1 not equal to 2 Stacktrace: ----------- -#0 ./step-5: Coefficient<2>::value_list(std::vector<Point<2>, std::allocator<Point<2> > > const&, std::vector<double, std::allocator<double> >&, unsigned) const +#0 ./step-5: Coefficient<2>::value_list(std::vector, std::allocator > > const&, std::vector >&, unsigned) const #1 ./step-5: main -------------------------------------------------------- make: *** [run] Aborted diff --git a/deal.II/doc/tutorial/chapter-2.step-by-step/step-6.data/intro.html b/deal.II/doc/tutorial/chapter-2.step-by-step/step-6.data/intro.dox similarity index 83% rename from deal.II/doc/tutorial/chapter-2.step-by-step/step-6.data/intro.html rename to deal.II/doc/tutorial/chapter-2.step-by-step/step-6.data/intro.dox index c3288d7b89..990220acd0 100644 --- a/deal.II/doc/tutorial/chapter-2.step-by-step/step-6.data/intro.html +++ b/deal.II/doc/tutorial/chapter-2.step-by-step/step-6.data/intro.dox @@ -1,24 +1,24 @@

Introduction

-

+ The main emphasis in this example is the handling of locally refined grids. The approach to adaptivity chosen in deal.II us to use grids in which neighboring cells may be refined a different number of times. This then results in nodes on the interfaces of cells which belong to one side, but are unbalanced on the other. The common term for these is -“hanging nodes”. -

+“hanging nodes”. + + -

To guarantee that the global solution is continuous at these nodes as well, we have to state some additional constraints on the values of the solution at these nodes. In the program below, we will show how we can get these constraints from the library, and how to use them in the solution of the linear system of equations. -

-

+ + The locally refined grids are produced using an error estimator class which estimates the energy error with respect to the Laplace operator. This error estimator, although developed for Laplace's @@ -28,30 +28,30 @@ problems. Although it will create non-optimal meshes for other equations, it is often a good way to quickly produce meshes that are well adapted to the features of solutions, such as regions of great variation or discontinuities. Since it was developed by Kelly and -co-workers, we often refer to it as the “Kelly refinement -indicator” in the library, documentation, and mailing list. The +co-workers, we often refer to it as the “Kelly refinement +indicator” in the library, documentation, and mailing list. The class that implements it is called -“KellyErrorEstimator”. Although the error estimator (and +KellyErrorEstimator. Although the error estimator (and its implementation in the deal.II library) is capable of handling variable coefficients in the equation, we will not use this feature since we are only interested in a quick and simple way to generate locally refined grids. -

-

+ + Since the concepts used for locally refined grids are so important, 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 +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 +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.data/results.dox b/deal.II/doc/tutorial/chapter-2.step-by-step/step-6.data/results.dox index eae75e8707..95700f9299 100644 --- a/deal.II/doc/tutorial/chapter-2.step-by-step/step-6.data/results.dox +++ b/deal.II/doc/tutorial/chapter-2.step-by-step/step-6.data/results.dox @@ -117,12 +117,12 @@ from this example. @code -------------------------------------------------------- -An error occurred in line <79> of file <source/subscriptor.cc> in function +An error occurred in line <79> of file in function virtual Subscriptor::~Subscriptor() The violated condition was: counter == 0 The name and call sequence of the exception was: - ExcInUse(counter, object_info->name(), infostring) + ExcInUse(counter, object_info->name(), infostring) Additional Information: Object of class 4FE_QILi2EE is still used by 1 other objects. from Subscriber 10DoFHandlerILi2EE @@ -130,10 +130,10 @@ Object of class 4FE_QILi2EE is still used by 1 other objects. Stacktrace: ----------- #0 /u/bangerth/p/deal.II/1/deal.II/lib/libbase.g.so: Subscriptor::~Subscriptor() -#1 /u/bangerth/p/deal.II/1/deal.II/lib/libdeal_II_2d.g.so: FiniteElement<2>::~FiniteElement() -#2 ./step-6: FE_Poly<TensorProductPolynomials<2>, 2>::~FE_Poly() -#3 ./step-6: FE_Q<2>::~FE_Q() -#4 ./step-6: LaplaceProblem<2>::~LaplaceProblem() +#1 /u/bangerth/p/deal.II/1/deal.II/lib/libdeal_II_2d.g.so: FiniteElement<2>::~FiniteElement() +#2 ./step-6: FE_Poly, 2>::~FE_Poly() +#3 ./step-6: FE_Q<2>::~FE_Q() +#4 ./step-6: LaplaceProblem<2>::~LaplaceProblem() #5 ./step-6: main -------------------------------------------------------- make: *** [run] Aborted diff --git a/deal.II/doc/tutorial/chapter-2.step-by-step/step-7.data/results.html b/deal.II/doc/tutorial/chapter-2.step-by-step/step-7.data/results.dox similarity index 94% rename from deal.II/doc/tutorial/chapter-2.step-by-step/step-7.data/results.html rename to deal.II/doc/tutorial/chapter-2.step-by-step/step-7.data/results.dox index 4c2205fdfc..cbed6604ef 100644 --- a/deal.II/doc/tutorial/chapter-2.step-by-step/step-7.data/results.html +++ b/deal.II/doc/tutorial/chapter-2.step-by-step/step-7.data/results.dox @@ -1,26 +1,24 @@

Results

-

+ The program generates two kinds of output. The first are the output files solution-adaptive-q1.gmv, solution-global-q1.gmv, and solution-global-q2.gmv. We show the latter in a 3d view here: -

-

- solution -

+ +@image html step-7.solution.png + + -

Secondly, the program writes tables not only to disk, but also to the screen while running: -

-
-
+
+@code
 examples/step-7> make run
 ============================ Running step-7
 Solving with Q1 elements, adaptive refinement
@@ -142,29 +140,26 @@ n cells  H1      L2
       4  1024 1.571e-02 1.99 1.265e-04  7.88 2.98 
       5  4096 3.937e-03 2.00 1.587e-05  7.97 2.99 
       6 16384 9.847e-04 2.00 1.986e-06  7.99 3.00 
-
-
+@endcode -

One can see the error reduction upon grid refinement, and for the cases where global refinement was performed, also the convergence rates can be seen. The linear and quadratic convergence rates of Q1 -and Q2 elements in the H1 norm can clearly be seen, as -are the quadratic and cubic rates in the L2 norm. -

+and Q2 elements in the $H^1$ norm can clearly be seen, as +are the quadratic and cubic rates in the $L_2$ norm. + + -

Finally, the program generated various LaTeX tables. We show here the convergence table of the Q2 element with global refinement, after converting the format to HTML: -

-
+ - @@ -225,5 +220,5 @@ n cells -

+

n cells H1-error L2-error 7.99 3.00
-
+ + diff --git a/deal.II/doc/tutorial/chapter-2.step-by-step/step-7.data/solution-3d.jpg b/deal.II/doc/tutorial/chapter-2.step-by-step/step-7.data/solution-3d.jpg deleted file mode 100644 index c925435289..0000000000 Binary files a/deal.II/doc/tutorial/chapter-2.step-by-step/step-7.data/solution-3d.jpg and /dev/null differ diff --git a/deal.II/doc/tutorial/chapter-2.step-by-step/step-7.data/step-7.solution.png b/deal.II/doc/tutorial/chapter-2.step-by-step/step-7.data/step-7.solution.png new file mode 100644 index 0000000000..eec6a4f8ef Binary files /dev/null and b/deal.II/doc/tutorial/chapter-2.step-by-step/step-7.data/step-7.solution.png differ