| Automatic and symbolic differentiation | A module dedicated to the implementation of functions and classes that relate to automatic and symbolic differentiation |
| deal.II and the C++11 standard | Since version 9.0, deal.II requires a compiler that supports at least C++11. As part of this, many places in the internal implementation of deal.II are now using features that were only introduced in C++11. That said, deal.II also has functions and classes that make using it with C++11 features easier |
| Concepts, or expectations on template parameters | Sometimes imposing constraints on the type of an object without requiring it to belong to a specific inheritance hierarchy is useful. These are usually referred to as concepts in the C++ community. This module lists the concepts commonly used in deal.II with brief descriptions of their intent. The convention in deal.II for listing constraints on a type is to provide the name of the concept as a typename in a template: for example, the type of a Vector depends on the type of the underlying field, and so it is defined as a template: |
| CUDA Wrappers | The classes in this module are concerned with the description of features to be run on GPUs using CUDA |
| ▼Degrees of Freedom | This module groups classes and namespaces that have to do with handling degrees of freedom. The central class of this group is the DoFHandler class: it is built on top of a triangulation and a finite element class and allocated degrees of freedom on each cell of the triangulation as required for the finite element space described by the finite element object. There are other variants of the DoFHandler class such as hp::DoFHandler that do similar things for more special cases |
| Constraints on degrees of freedom | |
| ▼Finite elements | All classes related to shape functions and to access to shape functions. This concerns the actual values of finite elements. For the numbering of degrees of freedom refer to the module on Degrees of Freedom |
| Base classes | The members of this sub-module describe the implementation mechanics of finite element classes, without actually implementing a concrete element. For example, the FiniteElement base class declares the virtual functions a derived class has to implement if it wants to describe a finite element space. Likewise, the FiniteElementData holds variables that describe certain values characterizing a finite element, such as the number of degrees of freedom per vertex, line, or face |
| ▼Finite element access/FEValues classes | The classes in this module are used when one wants to assemble matrices or vectors. They link finite elements, quadrature objects, and mappings: the finite element classes describe a finite element space on a unit cell (i.e. the unit line segment, square, or cube [0,1]^d), the quadrature classes describe where quadrature points are located and what weight they have, and the mapping classes describe how to map a point from the unit cell to a real cell and back. Since integration happens at quadrature points on the real cell, and needs to know their location as well as the values and gradients of finite element shape functions at these points. The FEValues class coordinates getting this information. For integrations on faces (for example for integration on the boundary, or interfaces between cells), the FEFaceValues class offers similar functionality as the FEValues class does for cells. Finally, the FESubfaceValues class offers the possibility to ingrate on parts of faces if the neighboring cell is refined and the present cell shares only a part of its face with the neighboring cell. If vector-valued elements are used, the FEValues and related classes allow access to all vector components; if one wants to pick individual components, there are extractor classes that make this task simpler, as described in the Handling vector valued problems module |
| Handling vector valued problems | Vector-valued problems are systems of partial differential equations. These are problems where the solution variable is not a scalar function, but a vector-valued function or a set of functions. This includes, for example: |
| Finite element space descriptions | The classes here describe finite element spaces, such as the simplest Q1 (bi-/trilinear) spaces, and higher order Lagrangian spaces Qp, but also more specialized spaces such as Nedelec or Raviart-Thomas ones. Concrete implementations are derived from the abstract FiniteElement base class |
| Mappings between reference and real cell | The classes in this module are used to map from unit coordinates to the coordinates of a cell in real cell. Most commonly, one uses the MappingQ1 class that provides a Q1 (bi-/trilinear) mapping (i.e. a mapping that is isoparametric for the usual Q1 elements). However, there are other classes that implement higher-order mappings as well to provide for curvilinear elements. These are discussed in the step-11 and step-12 tutorial programs |
| How Mapping, FiniteElement, and FEValues work together | |
| The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues | |
| Handling vector valued problems | Vector-valued problems are systems of partial differential equations. These are problems where the solution variable is not a scalar function, but a vector-valued function or a set of functions. This includes, for example: |
| Functions | Functions are used in various places in deal.II, for example to describe boundary conditions, coefficients in equations, forcing terms, or exact solutions. Since closed form expressions for equations are often hard to pass along as function arguments, deal.II uses the Function base class to describe these objects. Essentially, the interface of this base class requires derived classes to implement the ability to return the value of a function at one or a list of particular locations, and possibly (if needed) of gradients or second derivatives of the function. With this, function objects can then be used by algorithms like VectorTools::interpolate, VectorTools::project_boundary_values, and other functions |
| The geodynamics demonstration suite | Deal.II's tutorial contains a set of programs that together form the geodynamics demonstration suite. The idea of these programs is to demonstrate techniques for advanced finite element software using applications from geodynamics, i.e. the investigation of processes in the solid earth. By doing so, these programs are supposed to provide a basis for more specialized, dedicated programs that can solve actual geodynamics problems, for example as part of the work of graduate students or postdocs. A more thorough discussion of the motivation for these programs follows below |
| Geometric and other primitives | This group contains a number of classes that act as geometric primitives or primitives for other mathematical objects. For example, the Tensor <rank,dim> class provides tensors of rank rank in dim space dimensions. Likewise, the SymmetricTensor offers symmetric tensors |
| ▼Grid classes | This module groups classes that have to do with the topology and geometry of meshes. A mesh can be thought of as a collection of cells; if the mesh has been refined (possibly in an adaptive way), then this collection is grouped into a hierarchy of refinement levels. In addition to cells, the geometric objects that make up a triangulation are the faces of cells (and in 3d the edges of cells) as well as the vertices of the cells. Note that we abuse the word triangulation somewhat, since deal.II only implements triangulations made up of linear, quadrilateral, and hexahedral cells; triangles and tetrahedra are not supported |
| ▼Iterators on mesh-like containers | Deal.II has several classes which are understood conceptually as meshes. Apart from the obvious Triangulation, these are, for example, DoFHandler and hp::DoFHandler. All of those define a set of iterators, allowing the user to traverse the whole mesh, i.e. the set of cells, faces, edges, etc that comprise the mesh, or portions of it. These iterators are all in a sense derived from the TriaIterator class |
| Accessor classes of the mesh iterators | |
| Manifold description for triangulations | |
| ▼hp finite element support | Classes and functions that have to do with hp finite elements. The step-27 tutorial program gives an overview of how to use the classes in this namespace. A slightly more exotic application is given in step-46 |
| hp Collections | In the implementation of the hp finite element method, each cell might have a different finite element associated with it. To handle this, the hp::DoFHandler must have a whole set of finite element classes associated with it. This concept is represented by the hp::FECollection class: Objects of this type act as containers that hold a whole set of finite element objects. Instead of storing pointers to finite element objects on each cell, we then only store an index for each cell that identifies the finite element object within the collection that should be used by this cell. The DoFHandler object associated with the given cell can then assign degrees of freedom to each cell in accordance with the finite element used for it |
| ▼Integrators | A collection of namespaces and functions which simplify the coding of forms and bilinear forms on finite element spaces. Functions for two different purposes are gathered here: the abstract integration on finite element meshes in MeshWorker and actual implementations of the integration of cell and face terms for concrete problems in LocalIntegrators |
| The MeshWorker interface | A collection of classes and functions simplifying the coding of loops over all cells and faces. All classes and functions of this module are in the MeshWorker namespace, which also contains documentation on the usage |
| ▼Input/Output | This module collects the classes used for reading and writing meshes and data. There are two sub-modules for each of these operations |
| Input | Deal.II can read meshes in a number of different formats. However, all of them are constrained to so-called "coarse meshes", i.e. meshes that have no refinement hierarchy and in particular no hanging nodes. The GridIn class describes in detail what formats are supported |
| Graphical output | Deal.II generates three types of output: it can write triangulations/meshes in formats understood by several mesh readers (including those of deal.II itself), and it can create output used for visualization of data. Finally, it can output matrices in a graphical format |
| Textual output | In addition to classes that provide graphical output formats (see the Graphical output module), deal.II has a number of classes that facilitate textual output in a number of ways. They are collected in this module. See the documentation of these classes for more details |
| ▼Linear algebra classes | This module contains classes that involve linear algebra, i.e., those associated with matrices, vectors, and the solution of linear systems |
| Linear Operators | |
| ▼Matrix classes | Deal.II comes with a number of different matrix classes, tailored to the various purposes for which matrices are used. For example, there are full matrices, sparse matrices using different storage schemes, matrices composed of individual blocks, and matrices implemented as interfaces to other linear algebra classes. As far as possible, all these implementations share a common interface that contains at least the operations necessary to write iterative linear solvers (see Linear solver classes), but also element-wise access to read from and write to a matrix |
| ▼Basic matrices | These are the actual matrix classes provided by deal.II. It is possible to store values in them and retrieve them. Furthermore, they provide the full interface required by linear solvers (see Linear solver classes) |
| ▼Exceptions and assertions | This module contains classes that are used in the exception mechanism of deal.II |
| TrilinosWrappers | The classes in this module are wrappers around functionality provided by the Trilinos library. They provide a modern object-oriented interface that is compatible with the interfaces of the other linear algebra classes in deal.II. All classes and functions in this group reside in a namespace TrilinosWrappers |
| Derived matrices | These matrices are built on top of the basic matrices. They perform special operations using the interface defined by the MatrixType concept |
| ▼Preconditioners and Relaxation Operators | |
| ▼Exceptions and assertions | This module contains classes that are used in the exception mechanism of deal.II |
| TrilinosWrappers | The classes in this module are wrappers around functionality provided by the Trilinos library. They provide a modern object-oriented interface that is compatible with the interfaces of the other linear algebra classes in deal.II. All classes and functions in this group reside in a namespace TrilinosWrappers |
| ▼PETScWrappers | The classes in this module are wrappers around functionality provided by the PETSc library. They provide a modern object-oriented interface that is compatible with the interfaces of the other linear algebra classes in deal.II. All classes and functions in this group reside in a namespace PETScWrappers |
| SLEPcWrappers | The classes in this module are wrappers around functionality provided by the SLEPc library. All classes and functions in this group reside in a namespace PETScWrappers |
| ▼Preconditioners and Relaxation Operators | |
| ▼Exceptions and assertions | This module contains classes that are used in the exception mechanism of deal.II |
| TrilinosWrappers | The classes in this module are wrappers around functionality provided by the Trilinos library. They provide a modern object-oriented interface that is compatible with the interfaces of the other linear algebra classes in deal.II. All classes and functions in this group reside in a namespace TrilinosWrappers |
| SLEPcWrappers | The classes in this module are wrappers around functionality provided by the SLEPc library. All classes and functions in this group reside in a namespace PETScWrappers |
| Linear solver classes | This module groups iterative and direct solvers, eigenvalue solvers, and some control classes. All these classes operate on objects of the matrix and vector classes defined in deal.II |
| ▼Sparsity patterns | Almost all finite element formulations lead to matrices that are "sparse", i.e., for which the number of nonzero elements per row is (i) relatively small compared to the overall size of the matrix, and (ii) bounded by a fixed number that does not grow if the mesh is refined. For such cases, it is more efficient to not store all elements of the matrix, but only those that are actually (or may be) nonzero. This requires storing, for each row, the column indices of the nonzero entries (we call this the "sparsity
pattern") as well as the actual values of these nonzero entries. (In practice, it sometimes happens that some of the nonzero values are, in fact, zero. Sparsity patterns and sparse matrices only intend to provision space for entries that may be nonzero, and do so at a time when we don't know yet what values these entries will ultimately have; they may have a zero value if a coefficient or cell happens to have particular values.) |
| ▼Exceptions and assertions | This module contains classes that are used in the exception mechanism of deal.II |
| TrilinosWrappers | The classes in this module are wrappers around functionality provided by the Trilinos library. They provide a modern object-oriented interface that is compatible with the interfaces of the other linear algebra classes in deal.II. All classes and functions in this group reside in a namespace TrilinosWrappers |
| TrilinosWrappers | The classes in this module are wrappers around functionality provided by the Trilinos library. They provide a modern object-oriented interface that is compatible with the interfaces of the other linear algebra classes in deal.II. All classes and functions in this group reside in a namespace TrilinosWrappers |
| Vector memory management | This module groups a few classes that are used to avoid allocating and deallocating vectors over and over in iterative procedures. These methods all use an object of the base class VectorMemory to get their auxiliary vectors |
| ▼Vector classes | Here, we list all the classes that satisfy the VectorType concept and may be used in linear solvers (see Linear solver classes) and for matrix-vector operations |
| ▼Exceptions and assertions | This module contains classes that are used in the exception mechanism of deal.II |
| TrilinosWrappers | The classes in this module are wrappers around functionality provided by the Trilinos library. They provide a modern object-oriented interface that is compatible with the interfaces of the other linear algebra classes in deal.II. All classes and functions in this group reside in a namespace TrilinosWrappers |
| Matrix-free infrastructure | This module describes the matrix-free infrastructure in deal.II. An outline of how the primary groups of classes in deal.II interact with the matrix-free infrastructure is given by the following clickable graph, with a more detailed description below: |
| Multilevel support | Classes that have to do with multigrid algorithms |
| Numerical algorithms | This module groups a diverse set of classes that generally implement some sort of numerical algorithm on top all the basic triangulation, DoFHandler, and finite element classes in the library. They are generally unconnected to each other |
| ▼Parallel computing | A module discussing the use of multiple processors |
| Parallel computing with multiple processors using distributed memory | A module discussing the use of parallelism on distributed memory clusters |
| Parallel computing with multiple processors accessing shared memory | A module discussing the use of parallelism on shared memory machines. See the detailed documentation and Table of Contents below the lengthy list of members of this module |
| Physics | A module dedicated to the implementation of functions and classes that relate to continuum physics, physical fields and materials |
| Polynomials and polynomial spaces | This module groups classes that define certain families of polynomial functions. In particular, this includes Lagrangian interpolation polynomials for equidistant support points and their tensor products in higher dimensions, but also more exotic ones like Brezzi-Douglas-Marini or Raviart-Thomas spaces |
| Quadrature formulas | This module contains the base class Quadrature as well as the quadrature formulas provided by deal.II. Quadrature formulas provide two essential pieces of data: the locations of quadrature points on the unit cell [0,1]^d, and the weight of each quadrature point |
| ▼Utility functions and classes | This module simply collects a number of functions and classes that provide general tools for tasks that do not usually have much to do with finite element programs in particular, but happen to be required there just as well |
| Memory handling | This group has some basic classes and namespaces for memory handling. The Subscriptor and SmartPointer classes are used for counted memory handling, i.e. whenever a SmartPointer is set to point to an object, it increases a counter in that object; when the pointer is set to point elsewhere, it decreases it again. This way, one always knows how many users of an object there still are. While this is rarely useful in itself, it is used to generate an exception if an object is destroyed while a pointer somewhere is still pointing to it, as any access through that pointer at a later time would otherwise lead to access of invalid memory regions |
| Data storage primitives | Here are a few simple classes that help in storage and viewing data. For example, the Table templates allow to use not only arrays of objects (for which one might want to use the std::vector class), but also two-dimensional (rectangular) tables of arbitrary objects, as well as higher-order analogs up to tables with (presently) seven indices |
| OpenCASCADE | |
1.8.17