From: wolf Date: Wed, 22 Dec 1999 08:25:29 +0000 (+0000) Subject: Add the deal.II report to the online docs. X-Git-Url: https://gitweb.dealii.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=4ee99c720461803cb61b5fb5374f19c97673f122;p=dealii-svn.git Add the deal.II report to the online docs. git-svn-id: https://svn.dealii.org/trunk@2106 0785d39b-7218-0410-832d-ea1e28bc413d --- diff --git a/deal.II/doc/reports/deal.II-paper/footnode.html b/deal.II/doc/reports/deal.II-paper/footnode.html new file mode 100644 index 0000000000..29a1dc70f6 --- /dev/null +++ b/deal.II/doc/reports/deal.II-paper/footnode.html @@ -0,0 +1,101 @@ + + + + +Footnotes + + + + + + + + + + + +
+
...tex2html_comment_mark1 +
We get a similar problem if we have different finite elements on two + adjacent elements. Since the treatment of this problem is along the same + lines as for h-refinement, we do not make explicit reference to + p-refinement in the following. +
.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+
+
...tex2html_comment_mark2 +
For nonconforming finite element spaces, the continuity + requirement has to be substituted by a generalized compatibility + condition, cf. [11]. +
.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+
+
+Wolfgang Bangerth +
1999-12-22 +
+ + diff --git a/deal.II/doc/reports/deal.II-paper/img1.gif b/deal.II/doc/reports/deal.II-paper/img1.gif new file mode 100644 index 0000000000..53a781792f Binary files /dev/null and b/deal.II/doc/reports/deal.II-paper/img1.gif differ diff --git a/deal.II/doc/reports/deal.II-paper/img10.gif b/deal.II/doc/reports/deal.II-paper/img10.gif new file mode 100644 index 0000000000..6cd7f550c3 Binary files /dev/null and b/deal.II/doc/reports/deal.II-paper/img10.gif differ diff --git a/deal.II/doc/reports/deal.II-paper/img11.gif b/deal.II/doc/reports/deal.II-paper/img11.gif new file mode 100644 index 0000000000..f5c8ec1d1f Binary files /dev/null and b/deal.II/doc/reports/deal.II-paper/img11.gif differ diff --git a/deal.II/doc/reports/deal.II-paper/img12.gif b/deal.II/doc/reports/deal.II-paper/img12.gif new file mode 100644 index 0000000000..227454f76a Binary files /dev/null and b/deal.II/doc/reports/deal.II-paper/img12.gif differ diff --git a/deal.II/doc/reports/deal.II-paper/img13.gif b/deal.II/doc/reports/deal.II-paper/img13.gif new file mode 100644 index 0000000000..b68eb1a6fb Binary files /dev/null and b/deal.II/doc/reports/deal.II-paper/img13.gif differ diff --git a/deal.II/doc/reports/deal.II-paper/img14.gif b/deal.II/doc/reports/deal.II-paper/img14.gif new file mode 100644 index 0000000000..7c73412612 Binary files /dev/null and b/deal.II/doc/reports/deal.II-paper/img14.gif differ diff --git a/deal.II/doc/reports/deal.II-paper/img15.gif b/deal.II/doc/reports/deal.II-paper/img15.gif new file mode 100644 index 0000000000..5e9489a90c Binary files /dev/null and b/deal.II/doc/reports/deal.II-paper/img15.gif differ diff --git a/deal.II/doc/reports/deal.II-paper/img16.gif b/deal.II/doc/reports/deal.II-paper/img16.gif new file mode 100644 index 0000000000..2d799ab6de Binary files /dev/null and b/deal.II/doc/reports/deal.II-paper/img16.gif differ diff --git a/deal.II/doc/reports/deal.II-paper/img17.gif b/deal.II/doc/reports/deal.II-paper/img17.gif new file mode 100644 index 0000000000..9cd7184a63 Binary files /dev/null and b/deal.II/doc/reports/deal.II-paper/img17.gif differ diff --git a/deal.II/doc/reports/deal.II-paper/img18.gif b/deal.II/doc/reports/deal.II-paper/img18.gif new file mode 100644 index 0000000000..fbbd496899 Binary files /dev/null and b/deal.II/doc/reports/deal.II-paper/img18.gif differ diff --git a/deal.II/doc/reports/deal.II-paper/img19.gif b/deal.II/doc/reports/deal.II-paper/img19.gif new file mode 100644 index 0000000000..8287153399 Binary files /dev/null and b/deal.II/doc/reports/deal.II-paper/img19.gif differ diff --git a/deal.II/doc/reports/deal.II-paper/img2.gif b/deal.II/doc/reports/deal.II-paper/img2.gif new file mode 100644 index 0000000000..ceed10f791 Binary files /dev/null and b/deal.II/doc/reports/deal.II-paper/img2.gif differ diff --git a/deal.II/doc/reports/deal.II-paper/img20.gif b/deal.II/doc/reports/deal.II-paper/img20.gif new file mode 100644 index 0000000000..9461c081df Binary files /dev/null and b/deal.II/doc/reports/deal.II-paper/img20.gif differ diff --git a/deal.II/doc/reports/deal.II-paper/img21.gif b/deal.II/doc/reports/deal.II-paper/img21.gif new file mode 100644 index 0000000000..b2a64243cc Binary files /dev/null and b/deal.II/doc/reports/deal.II-paper/img21.gif differ diff --git a/deal.II/doc/reports/deal.II-paper/img22.gif b/deal.II/doc/reports/deal.II-paper/img22.gif new file mode 100644 index 0000000000..abde49be8c Binary files /dev/null and b/deal.II/doc/reports/deal.II-paper/img22.gif differ diff --git a/deal.II/doc/reports/deal.II-paper/img23.gif b/deal.II/doc/reports/deal.II-paper/img23.gif new file mode 100644 index 0000000000..847c29b558 Binary files /dev/null and b/deal.II/doc/reports/deal.II-paper/img23.gif differ diff --git a/deal.II/doc/reports/deal.II-paper/img24.gif b/deal.II/doc/reports/deal.II-paper/img24.gif new file mode 100644 index 0000000000..21a4acded7 Binary files /dev/null and b/deal.II/doc/reports/deal.II-paper/img24.gif differ diff --git a/deal.II/doc/reports/deal.II-paper/img25.gif b/deal.II/doc/reports/deal.II-paper/img25.gif new file mode 100644 index 0000000000..92e3b80bd1 Binary files /dev/null and b/deal.II/doc/reports/deal.II-paper/img25.gif differ diff --git a/deal.II/doc/reports/deal.II-paper/img26.gif b/deal.II/doc/reports/deal.II-paper/img26.gif new file mode 100644 index 0000000000..aea33e9f4c Binary files /dev/null and b/deal.II/doc/reports/deal.II-paper/img26.gif differ diff --git a/deal.II/doc/reports/deal.II-paper/img27.gif b/deal.II/doc/reports/deal.II-paper/img27.gif new file mode 100644 index 0000000000..7cbcadcf3f Binary files /dev/null and b/deal.II/doc/reports/deal.II-paper/img27.gif differ diff --git a/deal.II/doc/reports/deal.II-paper/img28.gif b/deal.II/doc/reports/deal.II-paper/img28.gif new file mode 100644 index 0000000000..09a3ddc482 Binary files /dev/null and b/deal.II/doc/reports/deal.II-paper/img28.gif differ diff --git a/deal.II/doc/reports/deal.II-paper/img29.gif b/deal.II/doc/reports/deal.II-paper/img29.gif new file mode 100644 index 0000000000..f0ef214396 Binary files /dev/null and b/deal.II/doc/reports/deal.II-paper/img29.gif differ diff --git a/deal.II/doc/reports/deal.II-paper/img3.gif b/deal.II/doc/reports/deal.II-paper/img3.gif new file mode 100644 index 0000000000..a151425530 Binary files /dev/null and b/deal.II/doc/reports/deal.II-paper/img3.gif differ diff --git a/deal.II/doc/reports/deal.II-paper/img30.gif b/deal.II/doc/reports/deal.II-paper/img30.gif new file mode 100644 index 0000000000..9c59b3206e Binary files /dev/null and b/deal.II/doc/reports/deal.II-paper/img30.gif differ diff --git a/deal.II/doc/reports/deal.II-paper/img31.gif b/deal.II/doc/reports/deal.II-paper/img31.gif new file mode 100644 index 0000000000..e444229b11 Binary files /dev/null and b/deal.II/doc/reports/deal.II-paper/img31.gif differ diff --git a/deal.II/doc/reports/deal.II-paper/img32.gif b/deal.II/doc/reports/deal.II-paper/img32.gif new file mode 100644 index 0000000000..098b28b959 Binary files /dev/null and b/deal.II/doc/reports/deal.II-paper/img32.gif differ diff --git a/deal.II/doc/reports/deal.II-paper/img33.gif b/deal.II/doc/reports/deal.II-paper/img33.gif new file mode 100644 index 0000000000..08f5ed31f5 Binary files /dev/null and b/deal.II/doc/reports/deal.II-paper/img33.gif differ diff --git a/deal.II/doc/reports/deal.II-paper/img34.gif b/deal.II/doc/reports/deal.II-paper/img34.gif new file mode 100644 index 0000000000..8195efe90f Binary files /dev/null and b/deal.II/doc/reports/deal.II-paper/img34.gif differ diff --git a/deal.II/doc/reports/deal.II-paper/img35.gif b/deal.II/doc/reports/deal.II-paper/img35.gif new file mode 100644 index 0000000000..79ec12940b Binary files /dev/null and b/deal.II/doc/reports/deal.II-paper/img35.gif differ diff --git a/deal.II/doc/reports/deal.II-paper/img36.gif b/deal.II/doc/reports/deal.II-paper/img36.gif new file mode 100644 index 0000000000..052460d1d5 Binary files /dev/null and b/deal.II/doc/reports/deal.II-paper/img36.gif differ diff --git a/deal.II/doc/reports/deal.II-paper/img37.gif b/deal.II/doc/reports/deal.II-paper/img37.gif new file mode 100644 index 0000000000..7452fa1bf0 Binary files /dev/null and b/deal.II/doc/reports/deal.II-paper/img37.gif differ diff --git a/deal.II/doc/reports/deal.II-paper/img38.gif b/deal.II/doc/reports/deal.II-paper/img38.gif new file mode 100644 index 0000000000..8a66b898ae Binary files /dev/null and b/deal.II/doc/reports/deal.II-paper/img38.gif differ diff --git a/deal.II/doc/reports/deal.II-paper/img39.gif b/deal.II/doc/reports/deal.II-paper/img39.gif new file mode 100644 index 0000000000..b80d7cf33b Binary files /dev/null and b/deal.II/doc/reports/deal.II-paper/img39.gif differ diff --git a/deal.II/doc/reports/deal.II-paper/img4.gif b/deal.II/doc/reports/deal.II-paper/img4.gif new file mode 100644 index 0000000000..d7966c4dc2 Binary files /dev/null and b/deal.II/doc/reports/deal.II-paper/img4.gif differ diff --git a/deal.II/doc/reports/deal.II-paper/img40.gif b/deal.II/doc/reports/deal.II-paper/img40.gif new file mode 100644 index 0000000000..8c7f53d872 Binary files /dev/null and b/deal.II/doc/reports/deal.II-paper/img40.gif differ diff --git a/deal.II/doc/reports/deal.II-paper/img41.gif b/deal.II/doc/reports/deal.II-paper/img41.gif new file mode 100644 index 0000000000..946be2405e Binary files /dev/null and b/deal.II/doc/reports/deal.II-paper/img41.gif differ diff --git a/deal.II/doc/reports/deal.II-paper/img42.gif b/deal.II/doc/reports/deal.II-paper/img42.gif new file mode 100644 index 0000000000..2a65c649b3 Binary files /dev/null and b/deal.II/doc/reports/deal.II-paper/img42.gif differ diff --git a/deal.II/doc/reports/deal.II-paper/img43.gif b/deal.II/doc/reports/deal.II-paper/img43.gif new file mode 100644 index 0000000000..2e7a94749a Binary files /dev/null and b/deal.II/doc/reports/deal.II-paper/img43.gif differ diff --git a/deal.II/doc/reports/deal.II-paper/img44.gif b/deal.II/doc/reports/deal.II-paper/img44.gif new file mode 100644 index 0000000000..4cf3edef6d Binary files /dev/null and b/deal.II/doc/reports/deal.II-paper/img44.gif differ diff --git a/deal.II/doc/reports/deal.II-paper/img45.gif b/deal.II/doc/reports/deal.II-paper/img45.gif new file mode 100644 index 0000000000..27666b928e Binary files /dev/null and b/deal.II/doc/reports/deal.II-paper/img45.gif differ diff --git a/deal.II/doc/reports/deal.II-paper/img46.gif b/deal.II/doc/reports/deal.II-paper/img46.gif new file mode 100644 index 0000000000..9dc92e087d Binary files /dev/null and b/deal.II/doc/reports/deal.II-paper/img46.gif differ diff --git a/deal.II/doc/reports/deal.II-paper/img47.gif b/deal.II/doc/reports/deal.II-paper/img47.gif new file mode 100644 index 0000000000..c91d615469 Binary files /dev/null and b/deal.II/doc/reports/deal.II-paper/img47.gif differ diff --git a/deal.II/doc/reports/deal.II-paper/img48.gif b/deal.II/doc/reports/deal.II-paper/img48.gif new file mode 100644 index 0000000000..c1c8dd1137 Binary files /dev/null and b/deal.II/doc/reports/deal.II-paper/img48.gif differ diff --git a/deal.II/doc/reports/deal.II-paper/img49.gif b/deal.II/doc/reports/deal.II-paper/img49.gif new file mode 100644 index 0000000000..7f36f4f3e1 Binary files /dev/null and b/deal.II/doc/reports/deal.II-paper/img49.gif differ diff --git a/deal.II/doc/reports/deal.II-paper/img5.gif b/deal.II/doc/reports/deal.II-paper/img5.gif new file mode 100644 index 0000000000..0269741a1d Binary files /dev/null and b/deal.II/doc/reports/deal.II-paper/img5.gif differ diff --git a/deal.II/doc/reports/deal.II-paper/img50.gif b/deal.II/doc/reports/deal.II-paper/img50.gif new file mode 100644 index 0000000000..0aa0e98560 Binary files /dev/null and b/deal.II/doc/reports/deal.II-paper/img50.gif differ diff --git a/deal.II/doc/reports/deal.II-paper/img51.gif b/deal.II/doc/reports/deal.II-paper/img51.gif new file mode 100644 index 0000000000..9d66868548 Binary files /dev/null and b/deal.II/doc/reports/deal.II-paper/img51.gif differ diff --git a/deal.II/doc/reports/deal.II-paper/img52.gif b/deal.II/doc/reports/deal.II-paper/img52.gif new file mode 100644 index 0000000000..89ff08053c Binary files /dev/null and b/deal.II/doc/reports/deal.II-paper/img52.gif differ diff --git a/deal.II/doc/reports/deal.II-paper/img6.gif b/deal.II/doc/reports/deal.II-paper/img6.gif new file mode 100644 index 0000000000..699df4e6eb Binary files /dev/null and b/deal.II/doc/reports/deal.II-paper/img6.gif differ diff --git a/deal.II/doc/reports/deal.II-paper/img7.gif b/deal.II/doc/reports/deal.II-paper/img7.gif new file mode 100644 index 0000000000..2a97b8b4b4 Binary files /dev/null and b/deal.II/doc/reports/deal.II-paper/img7.gif differ diff --git a/deal.II/doc/reports/deal.II-paper/img8.gif b/deal.II/doc/reports/deal.II-paper/img8.gif new file mode 100644 index 0000000000..f56dded0b2 Binary files /dev/null and b/deal.II/doc/reports/deal.II-paper/img8.gif differ diff --git a/deal.II/doc/reports/deal.II-paper/img9.gif b/deal.II/doc/reports/deal.II-paper/img9.gif new file mode 100644 index 0000000000..33dd6ff589 Binary files /dev/null and b/deal.II/doc/reports/deal.II-paper/img9.gif differ diff --git a/deal.II/doc/reports/deal.II-paper/index.html b/deal.II/doc/reports/deal.II-paper/index.html new file mode 100644 index 0000000000..15b02b295f --- /dev/null +++ b/deal.II/doc/reports/deal.II-paper/index.html @@ -0,0 +1,160 @@ + + + + +No Title + + + + + + + + + + + +next +up +previous +
+ Next: Design and evolution of +
+
+ + +

+

+Concepts for Object-Oriented + +

+Finite Element Software - the + +

+deal.II Library + + +

+
+
+ +

+Wolfgang Bangerth and Guido Kanschat + +

+
+
+
+ +

+Institute of Applied Mathematics +
+University of Heidelberg +
+Germany + +

+Email: + wolfgang.bangerth@iwr.uni-heidelberg.de, kanschat@iwr.uni-heidelberg.de +

+

+ +

Abstract:

+
+An overview of the deal.II library is given. This library provides + the functionality needed by modern numerical software used in the finite + element solution of partial differential equations, offering adaptively + refined meshes, different finite element classes, multigrid solvers and + support for one, two and three spatial dimensions. + + We give a description of the basic design criteria used in the + development of the library and how they were transformed into actual + code, and some examples of the use of the library in numerical + analysis. +
+

+

+

+ +  + + +
+
+Wolfgang Bangerth +
1999-12-22 +
+ + diff --git a/deal.II/doc/reports/deal.II-paper/node1.html b/deal.II/doc/reports/deal.II-paper/node1.html new file mode 100644 index 0000000000..1630f517d9 --- /dev/null +++ b/deal.II/doc/reports/deal.II-paper/node1.html @@ -0,0 +1,508 @@ + + + + +Design and evolution of deal.II + + + + + + + + + + + + + + +next + +up + +previous +
+ Next: Grid handling + Up: No Title + Previous: No Title +
+
+ + +Subsections + + +
+ +

  +  +
+Design and evolution of deal.II +

+ +The DEAL project, short for Differential +Equations Analysis Library, was started to +provide means for the implementation of adaptive finite element +methods. In fact, the development of DEAL and adaptive +methods at the Institute of Applied Mathematics in Heidelberg are +closely linked. From this starting point, a finite element library was +needed, that is able to handle grids with strongly varying mesh width +and supports strategies for the computation of error estimates based +on dual problems. + +

+While DEAL was a library developed since 1993, this article gives an +overview of the design criteria, programming models and fields of application +of its successor library, deal.II. + +

+ +

+Design criteria +

+ +

+deal.II was written with the following aims in mind: +

Obviously, some of these criteria are contradictory and must be traded against +each other. In almost all cases, we traded efficiency in favor of +safety and flexibility. However, some decisions were also made with +the performance aspect in mind. +These do not so much affect the +complicated grid handling, which is not overly time-critical, but are +especially found in the use of finite element objects and in the linear algebra +sub-library. + +

+Another important decision for simplicity against flexibility was the +reduction to hypercube (line, quadrilateral, hexahedron) cells and +their transformations to the physical space only. +The previous DEAL library featured the possibility of +combining simplicial (triangle, tetrahedron) and hypercube elements and in the +end this +additional flexibility caused very complicated data structures and violations +of type safety. Since +in all our experiments hypercube cells proved superior to simplicial ones, +the decision was made against the latter. An immediate result of this +decision is the absence of closure cells. Treatment of hanging nodes +is much better done in the numerical than in the geometrical context +(cf. Section [*]). + +

+Two other important criteria in the design of the library, unfortunately not +widely followed in the academic world, were: +

+

+The design goals described above need a programming language with a +high level of abstraction. We chose C++ for implementing the +library. The main reasons for this were: +

+

+These ingredients of the programming language have enabled us to use a +programming model that resembles the style of the C++ standard +library and makes use of templates to support several space dimensions at +once. These points will be explained in detail below. + +

+ +

+Programming model +

+ +

+ +

+Iterators and accessors. +

+The standard template library (STL) introduced the notion of iterators to +C++ from 1993 on. This model, abstracting pointers and, in general, +elements of containers has since then gained wide support in the C++ +world. For a library making heavy use of the standard container classes, it is +therefore natural to offer its data structures in a similar way. In the +present context, a triangulation can be considered a container holding points, +lines, quadrilaterals, etc. accessible like the elements of a +list. + +

+In fact, this mode of addressing elements of a triangulation is a major +abstraction, since the data elements making up one of the objects mentioned +above are distributed over a number of different arrays and other +containers. +By providing classes called iterators, programs can be written as +if data collections were arrays of data; in particular, these classes offer +operators ++ and - that move the pointer-like variable to +the next or previous element, respectively, just like a pointer would behave, +and as do the iterator classes of the standard library. + +

+While pointers in the original sense pointed to actual data which is organized +in a linear fashion in memory, iterators need not do so. For example iterators +may point to the elements of a linked list, which need not have any special +order in physical memory apart from the pointers that link the +different elements. + +

+In the deal.II library, iterators actually point to no data at all. +Dereferenced, they return an object called accessor having +no data elements itself apart from some numbers identifying the line or +quadrilateral it is to represent; it is a collection of functions knowing +how to obtain and manipulate data related to that object. +A typical function, setting a bit for a +quadrilateral in the triangulation that might be used by application programs +would then look like the following extract: +

+  void QuadAccessor::set_user_flag () const
+  {
+    tria->levels[level]->quads.user_flags[index] = true;
+  }
+
level and index denote the address of +the quadrilateral represented by this accessor object within the +hierarchical triangulation. It is obvious that shielding this multiple +dereferencing from the user makes the library much more robust with +regard to changes in the internal data structures. Furthermore, it +allows us to write programs in a much simpler way than by using the +internals directly. They will be much better readable, too. + +

+Using this concept of offering data centralized in an accessor class while +still storing it decentralized in many complex data structures, it is possible +to use the advantages of more +flexible data structures while still having the simplicity of programming +applications on top of these; in addition, the user needs not know anything +about the actual representation of the data, which may thus be changed at any +time as long as the accessor classes are changed accordingly. The actual +knowledge of the data structures is restricted to very small parts of the +library (a few hundred statements), the rest of the library and all user +programs use iterators and accessors to address these data. + +

+ +

+Logical addressing of objects. +

+The most often used operation in finite element programs is looping over all +quadrilaterals within a triangulation of a two dimensional domain and +performing some operations on each of them; an example would be to +compute the contributions of each quadrilateral to the global system matrix. +From this point of view, a +triangulation is composed of vertices, lines, quadrilaterals, etc. + +

+Alternatively, it can be regarded as a collection of cells, faces, etc.; +we call this the +dual topology. This view, which depends on the dimension (a cell +is a line in one space dimension, a quadrilateral in 2d and a hexahedron in +3d) is more natural to the programming of numerical software since +assembling of matrices, computation of error estimators, and so on are done on cells +and their faces. + +

+A typical loop, in this case marking all cells for some future operation, +therefore looks like this: +

+  Triangulation<dim> triangulation;
+  ...                           // triangulate a domain
+  Triangulation<dim>::cell_iterator cell;
+  for (cell=triangulation.begin();
+       cell != triangulation.end();
+       ++cell)
+    {
+      cell->set_user_flag ();
+    };
+
Remember that if cell is dereferenced, we obtain an accessor which +has the member function shown above to perform the wanted operation. + +

+The deal.II library offers both ways of addressing elements of +triangulations. While the first one centered on the dimension of an object is +most often used in the interior of the library, the second way, focused on the +dimension of an object relative to what a cell constitutes, is most helpful for +numerical algorithms and in fact allows to write programs and algorithms +in a dimension independent way. Operations work cell by cell, choosing +finite element shape functions, quadrature rules and the like according to the dimension of the cell. All the application programs presently implemented with +deal.II exclusively use the dual topology instead of the primal one. + +

+ +

+Dimension independent programming. +

+In this approach to programming, the program is actually formed when +the compiler associates a concrete data type, such as a +quadrilateral, to an abstract data type like a cell. This is +done using template manipulations as provided by C++. It +allows to write a function or algorithm in a way that does not depend on the +dimension by using logical data types like cells or faces, which are +parameterized aliases (i.e. typedefs) to concrete data types; the +mapping between these data types depends on the dimension (which is a template +parameter) for which a program is presently compiled. For example, in the +piece of code shown above, if the template parameter dim equals one, +two, or three, the objects marked are lines, quadrilaterals, and cells, +respectively. The code to switch these data types looks roughly like this: +
+  class TriaDimensionInfo<2>
+  {
+    typedef quad_iterator                       cell_iterator;
+    typedef line_iterator                       face_iterator;
+    //...
+  };
+
+  class TriaDimensionInfo<3>
+  {
+    typedef hex_iterator                        cell_iterator;
+    typedef quad_iterator                       face_iterator;
+    //...
+  };
+
+
+  template <int dim>
+  class Triangulation : public TriaDimensionInfo<dim>
+  {
+    typedef TriaDimensionInfo<dim>::cell_iterator cell_iterator;
+    typedef TriaDimensionInfo<dim>::face_iterator face_iterator;
+    //...
+  };
+
By preferring a template +parameter over preprocessor variables, it is possible to retain a greater +amount of type safety as well as the possibility to use parts of programs with +different space dimensions together at the same time. + +

+If an algorithm is not dimension independent, it is possible to specialize +it for some or all dimensions where its form deviates from the general +template. This is typically the case in one space dimension, where algorithms +often work a bit different, since no proper faces exist (we do not +consider points proper objects in the same sense as lines, quadrilaterals, etc. +since their lack of extension in any direction does not permit to define shape +functions on them). + +

+Being called from some dimension independent part of the code, the +compiler automatically figures out which version of a function to +call; dimension independent and dimension dependent code therefore +work together smoothly without the intervention of the programmer. +This approach has proven useful when several programs originally +written for two-dimensional computations ran by mere recompilation in +three space dimension as well when the three dimensional support +within the library became available. + +

+ +

+History +

+ +

+As a last note before we start with the actual description of the library, we +want to give a brief historical overview of the evolution of the project. The +following are some of the more important milestones that should be mentioned: + +

+1991-1992: Needing finite element software for their diploma +theses, Guido Kanschat and Franz-Theo Suttmeier start to develop +finite element codes, first in PASCAL, later in C++. Working +on quasi-regular solutions to variational systems, the need for grid +adaption becomes obvious. A finite element code for solving +two-dimensional problems in plasticity and quasi-linear elliptic +systems evolves [10]. + +

+Since 1993: DEAL, short for Differential +Equations Analysis Library, is developed by +Guido Kanschat and Franz-Theo Suttmeier. C++ becomes the +language of choice for the reasons mentioned in the introduction and +because it is the only advanced programming language portable to a +T805 parallel computer. + +

+1995-1996: Roland Becker joins and the implementation of the +multigrid method allows fast solution of PDE problems. The concept of +a posteriori error estimates based on dual solutions is developed and +used in the theses of the three programmers [4,9,16] +and the article [5]. By this time, the library had grown quite +complex and no documentation was available. Also, some of the +structures had turned out too complicated to allow further +development. + +

+End of 1997: At the time that the first author of this paper +was about to start working on his thesis, it was decided that it was +in time to do a major redesign of the library. The urge for other than +Q1 finite element spaces and the code reduplication in error +estimators demanded for a more flexible structure, while mixed +triangular/quadrilateral grids were not used anymore. We decided to +rewrite the library from scratch, then called deal.II. + +

+Design and implementation of the core of the library, i.e. handling of grids +and degrees of freedom, was done entirely by W. Bangerth, applying the +knowledge accumulated in the use of the predecessor library, DEAL. + +

+Since 1998: Many tools for numerical simulations are added. This +includes, among others, output for different visualization tools, +discontinuous elements, finite elements for systems and mixed discretizations, +and grid transfer operators for time-dependent problems. Multi-level +algorithms are about to be finished by now. + +

+At present, the deal.II library is maintained by W. Bangerth and G. +Kanschat. It is used by several postdoctoral scientists and graduate students +at the Institute of Applied Mathematics and several undergraduate students; it +is also used in teaching at the universities of Heidelberg and Minnesota. + +

+

+ + +next + +up + +previous +
+ Next: Grid handling + Up: No Title + Previous: No Title + +
+Wolfgang Bangerth +
1999-12-22 +
+ + diff --git a/deal.II/doc/reports/deal.II-paper/node2.html b/deal.II/doc/reports/deal.II-paper/node2.html new file mode 100644 index 0000000000..29a899b6ed --- /dev/null +++ b/deal.II/doc/reports/deal.II-paper/node2.html @@ -0,0 +1,229 @@ + + + + +Grid handling + + + + + + + + + + + + + + +next + +up + +previous +
+ Next: Finite element spaces + Up: No Title + Previous: Design and evolution of +
+
+ + +Subsections + + +
+ +

  +  +
+Grid handling +

+ +Since the stated goals of the library included adaptive grids that are easy +to program and should still be fast, hierarchical grids were the only choice +possible. By hierarchical we here mean that the structures of the grid are +described hierarchically (points, lines, quadrilaterals, ...) and that +refinement has to be made hierarchically as well, as opposed to unstructured +grids. The first point, hierarchical description, serves the simplicity of +programming, while the second, hierarchical refinement, allows to use fast +algorithms for grid refinement and in the numerics, such as multigrid solvers. +These two concepts are outlined in the following subsections. + +

+ +

+Hierarchical cell representation +

+ +

+As has been outlined above, one of the design criteria was to focus on +quadrilaterals in two, and hexahedra in three space dimensions. A +triangulation is therefore made up of the objects in Figure +[*]. +
+

   + + + +
Figure: +Topological constituents of a mesh
\begin{figure} +\begin{center} +\unitlength.08\textwidth +\begin{picture} +(12,4)... +...}} +\put(9,-.2){\makebox(0,0)[t]{3. Hex}} +\end{picture} \end{center}\end{figure}
+
+
+If the space dimension is lower than three, this sequence is truncated; if +anyone chooses to implement a finite element code in more than three space +dimensions (e.g. for general relativity), the sequence may be prolonged. + +

+Each of the objects can be made up of a +number of objects of lower level. They are thus hierarchic and one only +needs to store pointers to four lines to characterize a quadrilateral, which +are themselves characterized by two vertices each. A hexahedron is +characterized by six quadrilaterals which are themselves characterized by four +lines each and so on. + +

+Storing objects this way has advantages over the other possibility, i.e. +storing the vertices only, because it is possible to do computations on faces +if they exist as independent objects. This, though obviously also +possible if only vertices are stored, makes the evaluation of jump terms (in +error estimators or using discontinuous finite elements), the handling of +hanging nodes and many more things much simpler, at the expense of a slightly +increased memory consumption. + +

+ +

+Hierarchical grid refinement +

+ +

+The other hierarchical property of grids that is applied in deal.II +is hierarchical refinement. At present, there are two concurrent approaches +to adaptive meshes: +

Since the additional information in structured meshes can be favorably +used in multigrid algorithms as well as in the fast generation of new +meshes from a given one, we chose the second approach. Furthermore, +because the generation of red-green-like refinement rules for +quadrilaterals is relatively complex without recourse to triangles and +because any of these special refinements of some elements destroys the +regularity in the data structures, we chose to impose the +compatibility conditions at interfaces of cells of different +refinement depths as constraints to the system of equations. It should +be noted that these constraints need not be incorporated using a +Lagrangian multiplier (which would lead to saddle point problems), but +can be inserted into the matrix and right hand side, thus retaining +the properties of the matrices (cf. Section [*]). In +particular, symmetric and positive definite matrices retain these properties. + +

+Using the described approach, all lines, quadrilaterals, etc. are refined in a +uniform fashion thus allowing for fast algorithms exploiting this structure. +For these, multigrid algorithms based on hierarchical bases come to mind. +However, the structure is also particularly suited for time dependent problems +with grids that may differ between any two time steps and where the transfer +of the old solution to the new grid can only be done efficiently if the two +grids are related in some way; such a relationship can be obtained by using +the same coarse grid with different refinement depths on the different time +steps. In that case, integration of the old solution with the new test +functions can even be done exactly, leading to both higher accuracy and +dramatic speed improvements compared with unstructured mesh approaches. + +

+

+ + +next + +up + +previous +
+ Next: Finite element spaces + Up: No Title + Previous: Design and evolution of + +
+Wolfgang Bangerth +
1999-12-22 +
+ + diff --git a/deal.II/doc/reports/deal.II-paper/node3.html b/deal.II/doc/reports/deal.II-paper/node3.html new file mode 100644 index 0000000000..0f3516340f --- /dev/null +++ b/deal.II/doc/reports/deal.II-paper/node3.html @@ -0,0 +1,653 @@ + + + + +Finite element spaces + + + + + + + + + + + + + + +next + +up + +previous +
+ Next: Iterative solvers + Up: No Title + Previous: Grid handling +
+
+ + +Subsections + + +
+ +

  +  +
+Finite element spaces +

+ +In finite element theory, the discrete function spaces are represented by the +vector space of node values. Each node value denotes one degree of freedom in +this vector space. The functionals defining the degrees of freedom, for +example the interpolation points of Lagrangian elements or face integrals for +some nonconforming elements, may be associated with any of the basic topological +objects of a mesh, as shown in Figure [*]. The FiniteElement +class describing a certain finite element states the objects on which these +functionals are defined. For neighboring cells, these nodes may coincide, in +which case they are identified. + +

+In case of local refinement (h or p), an interface between two cells might +carry different node values, which we call hanging nodes. Then, +additional compatibility conditions have to be imposed numerically, as we will +explain below in Section [*]. + +

+ +

+Finite element objects +

+ +

+A finite element space can be viewed as the function space spanned by a +number of relatively simple basis functions. These basis functions are chosen +such that they have a small support, in general at most as many cells as may +be adjacent at any one vertex in the triangulation. Furthermore, they are +usually defined on each cell within their domain of support separately, with +some compatibility condition for the interfaces between these subdomains; +compatibility conditions may be e.g. continuity along a face between two cells (for +H1-conforming elements), equality of the mean value of the shape function on both +sides of a face (Crouzeix-Raviart [8], Rannacher-Turek [13]) +or its normal component (Raviart-Thomas [14], Brezzi-Douglas-Marini [7]). + +

+Due to these properties, it is convenient for the implementation to consider a +finite element space as consisting of a set of shape functions defined on a +cell and compatibility conditions at the boundaries of the cell; this +viewpoint stresses a purely local description of the space which enables us to +do computations on each cell separately in most +cases. A further abstraction is possible in some cases, where the shape +functions can be computed on the unit cell and only afterwards need to be +transformed to the actual grid cell; this is possible for interpolation +elements, but not for all elements involving line integrals, normal +derivatives, etc. + +

+With these considerations in mind, the representation of a finite element in +deal.II is a class that provides the shape functions and its +derivatives on the unit cell (if possible, otherwise on the actual grid cell), +and the transformation from unit to real cell and its derivatives. Furthermore, +it provides necessary information to the class managing global degrees of freedom. +This includes the kind of topological object + (i.e. on vertices, line, +quadrilaterals, etc.) a degree of freedom is associated with and the type of +compatibility conditions between adjacent elements. + +

+However, looking at actual finite element programs, one notes that most of the +information listed above is not necessary to application programs. While +compatibility and transformations are of interest to the internal functions of +the library, application programs almost always are only interested in the +restriction of a finite element field or shape function to a grid cell. +Here, however, it is important to note that one usually is not interested in +the finite element as a continuous function, but only at a specified set of +points, for example in quadrature points located on a cell or a face. Since +codes for finite element applications usually do not use the analytical representation of +the shape functions (which can be rather complicated on the cells), but +computations are done using quadrature formulæ. + +

+In order to make access to actual finite elements more efficient and +structured, deal.II offers an abstraction of a finite +element restricted to a set of points on a cell. This interface is provided by +the FEValues class described in the next subsection. The actual finite +element class is hardly ever accessed directly by application programs and +indeed by none of the existing applications built upon deal.II. + +

+ +

+Computation of shape function values +

+Integrating and assembling matrices and right hand sides can consume a +considerable amount of time during the execution of a finite element +program. This is especially true in non-linear applications, where the +process of solving the linear system is not necessarily predominant anymore. +Therefore, the access to finite element shape functions is not only a +question of defining a well structured interface, it is also +a matter of run-time efficiency. + +

+Analyzing finite element software, we observe that shape functions are +always used in the same context: integration on a grid cell. This +means, that shape functions are always used in combination with a +quadrature rule. We exploit this relationship by introducing a special +class FEValues combining quadrature and shape functions; in +fact it can be considered to be the restriction of the trial space on +the whole mesh to the quadrature points of a given quadrature rule +applied to a single element of the triangulation. An object of this +class will compute all values of the shape functions at the +appropriate time and store them in arrays. +These values come basically in two categories: +

+
1. +
Values only depending on the quadrature point on the unit +cell. These are for instance the function values of standard + Lagrangian elements. +
2. +
Values depending on the actual grid cell. In this class are for example + values of derivatives, since they have to be transformed by + the tangent mapping of the transformation between unit cell and + actual cell, but also the actual locations of the quadrature points in physical + space. +
It should be remarked here that the category a certain value belongs +to is dependent on the type of finite element. While for standard +Lagrangian elements, values of the shape functions belong to the +first, in the case of Raviart-Thomas type elements e.g. they are of the +second kind. + +

+The two kinds of behavior are reflected in the fact that the tables of +FEValues are built at different times. Tables of the first +category are already filled upon construction, where FEValues objects +obtain +information about quadrature points and finite element shape functions. This +is usually done before a loop over all cells starts. The second type of +values is computed in a function that has to be +called within the loop for each grid cell before any evaluations are done. + +

+It is up to the interaction of FiniteElement and FEValues to do +these computations as efficiently as possible. The user should give some +hints though: FEValues takes a group of flags, telling it +which fields need to be computed on each cell; if second derivatives are +not used in a loop, they will not be computed on each element. + +

+ +

  +  +
+Hanging nodes +

+ +

+As mentioned briefly above, we obtain hanging nodes at interfaces between +cells of differing refinement, +1 +see Figure [*]. The +degrees of freedom on the refined side of a face (for example the left side of +the face with end points P1 and P2 in the figure) are not all matched by +degrees of freedom on the coarse side, so in order to guarantee continuity +2 +of the finite element space along +this face we need to impose additional constraints. In order to +illustrate the process, let Vh be +the original trial space including the continuity requirement on its +members, while + +$\tilde V_h$ +be a finite element space that is +constructed from the union of the same shape functions as in Vh, but +restricted to each cell separately; + +$\tilde V_h$ +therefore may contain +functions that are discontinuous along refined faces. While hanging +nodes carry degrees of freedom in + +$\tilde V_h$, +they do not do so in Vh. + +

+
+

   + + + +
Figure: +A simple grid with a hanging node.
\begin{figure}\unitlength1.5cm +\begin{center} +\begin{picture} +(4,2.5) +\thinlines... +...{$Q_4$ }} +\put(0,0){\makebox(1,1){$Q_1$ }} +\end{picture}\end{center}\end{figure}
+
+
+

+Since doing computations with functions from + +$\tilde V_h$ +is much simpler +(because it can be done locally on each cell without taking care that there +may be coarser or finer cells around, and because we would like to associate +degrees of freedom to all vertices and lines, irrespective of their +neighborhood), we would like to use + +$\tilde V_h$ +as long as possible and use the +constraints that Vh has over + +$\tilde V_h$ +as late as possible in the solution +of the problem. This can be done in the following way (cf. [9,12]; +[15] also shows how to do this, but the algorithms are significantly +more complex since more than one irregular node is allowed per face). + +

+Assume we had to solve the problem: find $u\in V_h$, +such that for all + $v\in V_h$ +
+\begin{gather*}a(v, u) = (v,f) +\end{gather*} +
+with a bilinear form + +$a(\cdot,\cdot)$ +and the L2 scalar product + + +$(\cdot,\cdot)$. +We would like to state this problem in + +$\tilde V_h$ +instead of +Vh. We take the standard finite element bases + +$\{\varphi_i\}$ +of Vh and + +$\{\tilde\varphi_i\}$ +of + +$\tilde V_h$. +Now, because Vh is a subspace of + +$\tilde V_h$(it is + +$\tilde V_h$ +with some constraints) every function $\varphi_i$ +can be +written as a linear combination of basis functions of + +$\tilde V_h$: + + +$\varphi_i = \sum_{j=1}^{\tilde +N}C_{ij}\tilde\varphi_i$. +This defines a matrix Cij. For example, for +bilinear shape functions the function $\varphi_1$ +associated with node P1in Figure [*] can be written as + + +$\varphi_1=\tilde\varphi_1+\tfrac 12\tilde\varphi_{10}$; +the support of these +three shape functions are + +$\mathrm{supp}(\varphi_1)=Q_0\cup Q_2\cup Q_2$, + + +$\mathrm{supp}(\tilde \varphi_1)=Q_0\cup Q_2$, +and + + +$\mathrm{supp}(\tilde\varphi_{10})=Q_2\cup Q_3$, +respectively. + +$\tilde\varphi_1$ +is +discontinuous along the line P1-P10, while + +$\tilde\varphi_{10}$ +is +discontinuous along the whole line P1-P2, because + + +$\tilde\varphi_{10}\vert _{Q_0}\equiv 0$. + +

+This representation of basis functions +implies that a function $u\in V_h$ +must be representable as + +$u=C\tilde u$ +with +some function + +$\tilde u\in\tilde V_h$, +where in the latter representation we +identified the function u by the vector of its nodal +values. For the grid in Figure [*] and bilinear elements, +the matrix C has the following form: +

+
+ + + +\begin{displaymath}C \in R^{10 \times 11}, \qquad +C_{ii}=1, \qquad +C_{1,10} = C_{2,10} = \tfrac 12. +\end{displaymath} +
+
+

+All other entries are zero. Since most of the columns (notably those belonging to +non-constrained nodes) consist only of the diagonal entry, we only need store +those columns that deviate from this form. Note that for simplicity we have here +numbered the only constrained node such that it is the last one. This way, +nodal numbers for Vh can be chosen to be the same as for + +$\tilde V_h$, +simply +dropping the numbers of constrained nodes following those of unconstrained +ones. If we had not chosen this numbering, we would need to permute the rows +in C, which would move the entries in rows of unconstrained nodes to +nondiagonal places. + +

+We can now restate the problem as follows: find + +$\tilde u\in\tilde V_h$ +such that for all + +$\tilde v\in \tilde V_h$ +
+\begin{gather*}\tilde v_i C_{i j} a(\tilde\varphi_j,\tilde\varphi_k) C_{l k}\tilde u_k += +\tilde v_i C_{i j} (\varphi_j,f), +\end{gather*} +
+which amounts to solving the linear system of equations +
+\begin{gather*}C\tilde A C^T \tilde u = C \tilde f. +\end{gather*} +
+It should be noted that $\tilde A$ +is assembled as usual, i.e. cell-wise +without the need to look at the neighboring cells, and that it is relatively +simple to generate + +$C\tilde A C^T$ +in-place, i.e. without the need for another +matrix where we copy the result into. In particular, the sparsity pattern of +$\tilde A$ +can be obtained from that of A by filling in some additional +places that can be computed beforehand. The same holds for the right hand +side. These properties result from the fact that each hanging node may only be +constrained once, which however limits the difference in refinement to one +level of cells in three space dimensions that are adjacent at one edge only. + +In order to see how this property-conservation can be obtained, we use another +matrix $\hat C$ +instead of C, where we add additional rows for each +constrained node such that it becomes square. In doing so, there is no need to +renumber the degrees of freedom in a way as to order constrained nodes to the +end. The additional rows in $\tilde C$ +are set to zero only and the diagonal +elements of all rows apart from the newly added ones are equal to one, which +allows for very efficient storage mechanisms. Multiplying $\tilde A$by $\hat C^T$ +from the right, only multiplication with rows in $\hat C$ +have +to be taken care of that contain either only zeroes (resulting in a blanked +out column in + +$\tilde A\hat C^T$ +for each constrained node) or that contain +entries other than only the diagonal entry, which are nodes that constrain +another one (resulting in multiples of some columns being added to other +columns). The multiplication with $\hat C$ +from the left can be done along +the same lines. + +

+In practice, due to the special structure of $\hat C$, +multiplication by $\hat C$ +from the left and $\hat C^T$ +from the right can be done at the same time +and with writing the results into the same matrix where previously $\tilde A$was stored. We call this process condensation. Lines and columns +belonging to constrained nodes are filled with zeroes, effectively eliminating +these degrees of freedom from the system of equations in the same way as if we +used the original matrix C. + +

+

+ + +next + +up + +previous +
+ Next: Iterative solvers + Up: No Title + Previous: Grid handling + +
+Wolfgang Bangerth +
1999-12-22 +
+ + diff --git a/deal.II/doc/reports/deal.II-paper/node4.html b/deal.II/doc/reports/deal.II-paper/node4.html new file mode 100644 index 0000000000..d2c10cf8b8 --- /dev/null +++ b/deal.II/doc/reports/deal.II-paper/node4.html @@ -0,0 +1,188 @@ + + + + +Iterative solvers + + + + + + + + + + + + + + +next + +up + +previous +
+ Next: Example applications + Up: No Title + Previous: Finite element spaces +
+
+ + +Subsections + + +
+ +

  +  +
+Iterative solvers +

+ +Solution methods for finite equations are quite generally +iterative. This is true for non-linear equations, where we use +different variations of Newton's method, and linear equations. Even +time-stepping methods fit into this framework. + +

+Since solution methods are used in many different contexts, but are +usually time-critical, they should be implemented as general as is +possible without loosing efficiency. Therefore, linear solvers and +matrix classes are extracted into a separate library called +LAC, short for Linear Algebra Classes. + +

+ +

+Iterative linear solvers of LAC +

+ +

+Solvers in LAC are supposed to be basic multi-purpose tools. In +particular, the requirements for matrix and vector classes involved should be +as low as possible. In LAC we chose to not use abstract base classes +to state these interface requirements. Instead, matrix and vector are template +arguments to the solvers, e.g. SolverCG<Matrix, Vector>. + +

+ +

+Requirements on template parameters +

+A minimal interface for a matrix class used for LAC Solvers +is +
+class Matrix
+{
+  public:
+    void   vmult    (Vector& dst, const Vector& src) const;
+
+    double residual (Vector& dst, const Vector& src,
+                     const Vector& right_hand_side) const;
+};
+
Here, vmult for a matrix A should perform + +vdst = A +vsrc, while residual performs + +vdst = vrhs - A +vsrc and returns the Euclidean norm of the result. + +

+The requirements for a preconditioner are even simpler: +

+class Precondition
+{
+  public:
+    void operator() (Vector& dst, const Vector& src) const;
+};
+
+

+Unfortunately, the interface of the vector class is more complex. To +avoid a lot of unnecessary loops, there are different redundant scaled vector +additions used in the iterative methods. + +

+ +

+Administrative classes +

+The LAC-solvers do not check for the stopping criterion +themselves. Instead, they compute the value used by this +criterion, e.g. the norm of the residual, and hand it over to an +object of a class called SolverControl. This class now decides, +whether the iteration +The provided class SolverControl has a standard version of +this virtual function check built in. It can be replaced by a +derived class, for instance to balance convergence of the linear +solver with some outer iteration. + +

+Most solvers need auxiliary vectors. Since it might be advisable in +many cases that these vectors are pre-allocated and retrieved from a +special memory, the class VectorMemory was introduced. It is +an abstract base class for a memory handler. If more sophisticated +allocation methods are needed, a derived class can implement a vector +pool, where vectors are not deallocated after use, e.g. to avoid +fragmentation of heap memory or to speed up allocation. + +

+

+ + +next + +up + +previous +
+ Next: Example applications + Up: No Title + Previous: Finite element spaces + +
+Wolfgang Bangerth +
1999-12-22 +
+ + diff --git a/deal.II/doc/reports/deal.II-paper/node5.html b/deal.II/doc/reports/deal.II-paper/node5.html new file mode 100644 index 0000000000..fac51116cb --- /dev/null +++ b/deal.II/doc/reports/deal.II-paper/node5.html @@ -0,0 +1,433 @@ + + + + +Example applications + + + + + + + + + + + + + + +next + +up + +previous +
+ Next: Bibliography + Up: No Title + Previous: Iterative solvers +
+
+ + +Subsections + + +
+ +

  +  +
+Example applications +

+ +

+In this section, we give a brief overview of some applications already implemented +with deal.II, to show the range of applicability and to give an idea +of what our motives were to write such a library. + +

+ +

+Conservation Laws +

+ +

+The solution of the nonlinear Burgers equation +
+\begin{align*}u_t + u u_x = 0 +\end{align*} +
+with given initial and boundary conditions in space and time often yields +discontinuous solutions, usually even if the data are smooth. Resolving +these discontinuities without recourse to a globally refined grid is a major +challenge, especially in view of the fact that the same problems with +discontinuous solutions occur with other and more important equations as well, +such as the Euler equations of inviscid, eventually transonic flow. + +

+
+

   + + + +
Figure: +Examples of solutions of conservation laws. Computation: R. Hartmann.
+
+ + +\includegraphics[width=0.4\textwidth] +{pictures/conservation/burgers1.eps} + + + +\includegraphics[width=0.4\textwidth] +{pictures/conservation/burgers2.eps} + + + +\includegraphics[width=0.4\textwidth] +{pictures/conservation/euler.eps} +
+
+
+

+The examples in Figure [*] of computations with locally +refined grids for these equations were done by R. Hartmann. The left and +middle picture show solutions of the nonlinear Burgers equation with two +merging shocks on a coarse grid and a refined one; bilinear discontinuous +elements were used for these computations. On the right, the Euler equations +for the shock tube problem were solved; shock, contact discontinuity and +rarefaction wave can clearly be seen. + +

+ +

+Parameter estimation +

+ +

+In many applications in engineering, one wants to determine the value of a +parameter from measurements. One example would be the estimation of the +elasticity parameters within a body from measurements of the displacement +under a specified load. Another similar problem would be the estimation of the +conductivity in a porous medium from measurements of the hydraulic +head. A prototypic elliptic equation would be +
+\begin{gather*}-\nabla\cdot (q \nabla u) = f +\end{gather*} +
+with some boundary conditions. The coefficient q(x) is to be determined +by minimizing the difference between the solution of this equation for a given +coefficient, uq(x), and a measurement umeas, by variation of q. + +

+Problems of this kind usually are ill-posed, i.e. they do not possess a +continuous dependence of the optimal parameter $q^\ast$ +from the measurement +umeas, which makes them rather difficult to solve. Furthermore, they are +strongly nonlinear and usually require many solutions of the forward problem +(i.e. the elliptic equation for a fixed coefficient) to determine the +coefficient itself, which makes the efficient solution of the forward problem +indispensable. + +

+
+

   + + + +
Figure: +Estimated (left) and true coefficients (middle) in a + parameter estimation problem. The state variable approximating the + measurement is shown in the right column. Top: smooth true + coefficient, bottom: discontinuous true coefficient.
+
+ + +\includegraphics[width=0.34\textwidth] +{pictures/parameter/continuous_est.eps} + + +\includegraphics[width=0.34\textwidth] +{pictures/parameter/continuous_exact.eps} + + +\includegraphics[width=0.34\textwidth] +{pictures/parameter/continuous_state.eps} + + +\includegraphics[width=0.34\textwidth] +{pictures/parameter/discontinuous_est.eps} + + +\includegraphics[width=0.34\textwidth] +{pictures/parameter/discontinuous_exact.eps} + + +\includegraphics[width=0.34\textwidth] +{pictures/parameter/discontinuous_state.eps} +
+
+
+

+In Figure [*] we show two examples of estimated parameters +along with the exact values. In order to reduce the degree of ill-posedness +and to reduce the number of unknowns, the discretization of the parameter qwas performed on a coarser grid than the state variable u. In fact, the +discretization was done on the same grid but we posed additional constraints +such that each patch of four cells can be written as a shape function on the +next coarser grid; these constraints can then be inserted into the system +matrix just as was done for hanging nodes. The discretization of the parameter +was done with discontinuous elements of one degree lower than the polynomial +degree with which the state variable was discretized. + +

+The top row of the picture shows the approximation of a continuous coefficient +on a square domain; the state variable was discretized with bilinear elements, +while the parameter was discretized with discontinuous constant elements. In +the bottom row, a discontinuous coefficient was to be estimated on a circular +domain of which one quarter is shown; state and parameter variables +used bi-quadratic continuous elements and discontinuous bilinear elements, +respectively. No adaptive grid refinement was performed for the second case. + +

+ +

+Wave equation +

+ +

+The acoustic wave equation +
+\begin{align*}\rho u_{t t} - \nabla\cdot (a\nabla u) = 0, +\end{align*} +
+associated with suitable initial and boundary conditions occurs in a variety of +places in physics, among which are water waves, acoustic sound waves in gaseous media, +electro-magnetics and many other fields. Usually, u is the deviation from +the state of rest and $\rho$ +and a denote density and stiffness +coefficient. The solutions of this equation often share the feature that they +form waves traveling through the domain. Often the region where waves +presently are is significantly smaller than the whole domain, so adaptivity +should be able to reduce the number of cells needed for the solution of this +equation by a noticeable amount, because coarse grids can be used wherever no +waves are presently. + +

+On the other hand, if we are not interested in the whole solution but only in +parts of it (say that part traveling in one direction, or an integral over +part of the domain at the end time), the domain of influence of the region +where we evaluate itself also often is significantly smaller than the whole +region, due to the finite speed with which waves spread. Here again a +reasonable reduction of the required number of cells can be obtained. + +

+Typical grids showing this are presented in the following. They were +obtained using the program described in [1,3]. In Figure +[*], a wave traveling outward from the lower left corner of the +domain is shown. We used a simple error indicator to track the spreading of +the wave to adjust the computational meshes accordingly; it can be seen that +rather coarse cells were used where the solution is smooth. + +

+
+

   + + + +
Figure: +Automatically generated grids tracking an acoustic wave + traveling outwards in a three-dimensional domain.
+
+ + +\includegraphics[width=0.3\textwidth] +{pictures/wave3d/grid.0000.eps} + + + +\includegraphics[width=0.3\textwidth] +{pictures/wave3d/grid.0020.eps} + + + +\includegraphics[width=0.3\textwidth] +{pictures/wave3d/grid.0040.eps} + + + +\includegraphics[width=0.3\textwidth] +{pictures/wave3d/grid.0060.eps} +
+
+
+

+ +

+Boundary approximation +

+ +

+In real-life applications such as air flow around a plane or +scattering of waves by objects, the computational boundaries +often are rather complex. In particular, a coarse grid that already +mostly features the contours of the objects usually has many more +cells than is acceptable for a coarse grid. One way to avoid this +problem is to not approximate the boundary with the grid and pose +the boundary values on the boundary of the grid, but to use a mesh +that is not necessarily adapted to the physical boundaries and pose +boundary values in the weak form of the equation. This allows, among +other advantages, to use more regular meshes and a coarse grid with +less cells, which enables us to use efficient multigrid algorithms. + +

+Figure [*] shows examples of solutions to Poisson's +equation using Neumann boundary conditions on an embedded boundary +curve. The interior of the circle is not part of the domain on which +the problem is posed and the solution is set to zero there. + +

+
+

   + + + +
Figure: +Approximation of a circular domain by inclusion of boundary + values into the weak formulation of the equation.
+
+ + +\includegraphics[width=0.5\textwidth]{pictures/helmholtz/helmholtz.eps} +
+
+
+

+ +

+ + +next + +up + +previous +
+ Next: Bibliography + Up: No Title + Previous: Iterative solvers + +
+Wolfgang Bangerth +
1999-12-22 +
+ + diff --git a/deal.II/doc/reports/deal.II-paper/node6.html b/deal.II/doc/reports/deal.II-paper/node6.html new file mode 100644 index 0000000000..4bfaf90921 --- /dev/null +++ b/deal.II/doc/reports/deal.II-paper/node6.html @@ -0,0 +1,164 @@ + + + + +Bibliography + + + + + + + + + + + + + + +next + +up + +previous +
+ Next: About this document ... + Up: No Title + Previous: Example applications +

+ +

Bibliography +

+

1 +
+W. Bangerth. +
Adaptive Finite-Elemente-Methoden zur Lösung der + Wellengleichung mit Anwendung in der Physik der Sonne. +
Diplomarbeit, Institut für Angewandte Mathematik, Universität + Heidelberg, 1998. + +

2 +
+W. Bangerth and G. Kanschat. +
deal.II Homepage. +
http://gaia.iwr.uni-heidelberg.de/~deal/. + +

3 +
+W. Bangerth and R. Rannacher. +
Finite element approximation of the acoustic wave equation: Error + control and mesh adaptation. +
East-West J. Num. Math., (4), 1999. +
submitted. + +

4 +
+R. Becker. +
An Adaptive Finite Element Method for the Incompressible + Navier-Stokes Equations on Time-dependent Domains. +
Dissertation, Universität Heidelberg, 1995. + +

5 +
+R. Becker and R. Rannacher. +
Weighted a posteriori error control in FE methods. +
In ENUMATH 95, Paris, September 1995. +
in [6]. + +

6 +
+H. G. Bock, F. Brezzi, R. Glowinsky, G. Kanschat, Y. A. Kuznetsov, + J. Périaux, and R. Rannacher, editors. +
ENUMATH 97, Proceedings of the 2nd Conference on Numerical + Mathematics and Advanced Applications, Singapore, 1998. World Scientific. + +

7 +
+F. Brezzi and M. Fortin. +
Mixed and Hybrid Finite Element Methods. +
Springer, 1991. + +

8 +
+M. Crouzeix and P. Raviart. +
Conforming and nonconforming finite element methods for solving the + stationary stokes equations, part I. +
RAIRO, R-3:33-76, 1973. + +

9 +
+G. Kanschat. +
Parallel and Adaptive Galerkin Methods for Radiative Transfer + Problems. +
Dissertation, Universität Heidelberg, 1996. + +

10 +
+G. Kanschat and F.-T. Suttmeier. +
Datenstrukturen für die Methode der finiten Elemente. +
unpublished, Bonn-Venusberg, 1992. + +

11 +
+G. Kanschat and F.-T. Suttmeier. +
A posteriori error estimates for nonconforming finite element + schemes. +
Calcolo, 36(3):129-141, 1999. +
to appear. + +

12 +
+G. Kozlovsky. +
Solving partial differential equations using recursive grids. +
Appl. Numer. Math., 14:165-181, 1994. + +

13 +
+R. Rannacher and S. Turek. +
Simple nonconforming quadrilateral stokes element. +
Num. Meth. PDE, 8(2):97-111, March 1992. + +

14 +
+P. Raviart and J.-M. Thomas. +
A mixed finite element method for second order elliptic problems. +
In I. Galligani and E. Magenes, editors, Mathematical Aspects of + the Finite Element Method, pages 292-315, New York, 1977. Springer. + +

15 +
+W. C. Rheinboldt and C. K. Mesztenyi. +
On a data structure for adaptive finite element mesh refinements. +
ACM Trans. Math. Software, 6:166-187, 1980. + +

16 +
+F.-T. Suttmeier. +
Adaptive Finite Element Approximation of Problems in + Elasto-Plasticity Theory. +
Dissertation, Universität Heidelberg, 1996. +
+ +

+

+
+Wolfgang Bangerth +
1999-12-22 +
+ + diff --git a/deal.II/doc/reports/deal.II-paper/node7.html b/deal.II/doc/reports/deal.II-paper/node7.html new file mode 100644 index 0000000000..e4a55e8d49 --- /dev/null +++ b/deal.II/doc/reports/deal.II-paper/node7.html @@ -0,0 +1,61 @@ + + + + +About this document ... + + + + + + + + + + + +next + +up + +previous +
+ Up: No Title + Previous: Bibliography +
+
+ + +

+ About this document ... +

+

+This document was generated using the +LaTeX2HTML translator Version 98.1p1 release (March 2nd, 1998) +

+Copyright © 1993, 1994, 1995, 1996, 1997, +Nikos Drakos, +Computer Based Learning Unit, University of Leeds. +

+The command line arguments were:
+ latex2html -split 4 -antialias main.tex. +

+The translation was initiated by Wolfgang Bangerth on 1999-12-22 +

+
+Wolfgang Bangerth +
1999-12-22 +
+ + diff --git a/deal.II/doc/reports/deal.II-paper/screen.css b/deal.II/doc/reports/deal.II-paper/screen.css new file mode 100644 index 0000000000..6036265c51 --- /dev/null +++ b/deal.II/doc/reports/deal.II-paper/screen.css @@ -0,0 +1,55 @@ + +body { background-image: none; + background-color: white; + } + +frameset { background-color: white; + border-color: white; + border: 0; + frameborder: 0; + } + +td { vertical-align: top; } + +dt { font-weight: bold; } + +.figure { font-weight: bold; + font-size: larger; + } + +.pagetoc {} + +.chapter_title {} + +span.parhead { font-weight: bold; + } + +span.example { font-weight: bold; + font-style: italic; + } +pre.example { padding-left: 2 em; + text-align: left; + text-indent: 0; + } + +table.navbar { } + + +/* Century Schoolbook font is very similar to Computer Modern Math: cmmi */ +.MATH { font-family: "Century Schoolbook", serif; } +.MATH I { font-family: "Century Schoolbook", serif; font-weight: bold } +.BOLDMATH { font-family: "Century Schoolbook", serif; font-weight: bold } + +/* implement both fixed-size and relative sizes */ +SMALL.XTINY { font-size : xx-small } +SMALL.TINY { font-size : x-small } +SMALL.SCRIPTSIZE { font-size : smaller } +SMALL.FOOTNOTESIZE { font-size : small } +SMALL.SMALL { } +BIG.LARGE { } +BIG.XLARGE { font-size : large } +BIG.XXLARGE { font-size : x-large } +BIG.HUGE { font-size : larger } +BIG.XHUGE { font-size : xx-large } + +/* document-specific styles come next */ diff --git a/deal.II/doc/toc.html b/deal.II/doc/toc.html index 49ddbb16f3..1cb5072ca8 100644 --- a/deal.II/doc/toc.html +++ b/deal.II/doc/toc.html @@ -63,6 +63,13 @@

  • We have a few reports written on deal.II, the following of which are online: