From: wolf
-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
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:
-
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 @@
- @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
Introduction
-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).
-
-
- template <int dim>
- void make_grid (Triangulation<dim> &triangulation)
+@code
+ template
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 if
s or switch
es. 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 @@+ 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+ 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.
-