Glossary

This glossary explains a few terms that are frequently used in the documentation of classes of deal.II. The glossary often only gives a microscopic view of a particular concept; if you struggle with the bigger picture, it may therefore also be worth to consult the global overview of classes on the main/index page.

Active cells

Mesh cells not refined any further in the hierarchy.

block

Blocks were introduced in BlockVector, BlockSparseMatrix and related classes. These are used to reflect the structure of a PDE system in linear algebra, in particular allowing for modular solvers for problems with multiple solution components. How to implement this is described in more detail in the Handling vector valued problems report and the tutorial programs referenced therein.

Originally, this concept was intermixed with the idea of the vector component. Since the introduction of non-primitive elements, they became different. Take for instance the solution of the mixed Laplacian system with FE_RaviartThomas. There, the first dim components are the directional derivatives. Since the shape functions are linear combinations of those, they constitute only a single block. The primal function u would be in the second block, but in the dim+1st component.

In most cases, when you subdivide a matrix or vector into blocks, you do so by creating one block for each vector component. However, this is not always so, and the DoFRenumbering::component_wise function allows to group several vector components into the same block (see, for example, the step-22 or step-31 tutorial programs, as opposed to step-20).

component

For vector functions, component denotes the index in the vector. For instance, in the mixed Laplacian system, the first dim components are the derivatives in each coordinate direction and the last component is the primal function u.

Originally, components were not distinguished from blocks, but since the introduction of non-primitive elements, they have to be distinguished. See FiniteElementData::n_components() and the documentation of FiniteElement

Face orientation

In a triangulation, the normal vector to a face can be deduced from the face orientation by applying the right hand side rule (x,y -> normal). We note, that in the standard orientation of faces in 2d, faces 0 and 2 have normals that point into the cell, and faces 1 and 3 have normals pointing outward. In 3d, faces 0, 2, and 4 have normals that point into the cell, while the normals of faces 1, 3, and 5 point outward. This information, again, can be queried from GeometryInfo<dim>::unit_normal_orientation.

However, it turns out that a significant number of 3d meshes cannot satisfy this convention. This is due to the fact that the face convention for one cell already implies something for the neighbor, since they share a common face and fixing it for the first cell also fixes the normal vectors of the opposite faces of both cells. It is easy to construct cases of loops of cells for which this leads to cases where we cannot find orientations for all faces that are consistent with this convention.

For this reason, above convention is only what we call the standard orientation. deal.II actually allows faces in 3d to have either the standard direction, or its opposite, in which case the lines that make up a cell would have reverted orders, and the normal vector would have the opposite direction. You can ask a cell whether a given face has standard orientation by calling cell->face_orientation(face_no): if the result is true, then the face has standard orientation, otherwise its normal vector is pointing the other direction. There are not very many places in application programs where you need this information actually, but a few places in the library make use of this. Note that in 2d, the result is always true.

The only places in the library where face orientations play a significant role are in the Triangulation and its accessors, and in the QProjector class and its users.

Generalized support points

While support points allow very simple interpolation into the finite element space, their concept is restricted to Lagrange elements. For other elements, more general interpolation operators can be defined, often relying on integral values or moments. Since these integral values are again computed using a Quadrature rule, we consider them a generalization of support points.

Note that there is no simple relation between shape functions and generalized support points as for regular support points. Instead, FiniteElement defines a couple of interpolation functions doing the actual interpolation.

If a finite element is Lagrangian, generalized support points and support points coincide.

hp paper

The "hp paper" is a paper by W. Bangerth and O. Kayser-Herold, titled "Data Structures and Requirements for hp Finite Element Software", that describes many of the algorithms and data structures used in the implementation of the hp framework of deal.II. In particular, it summarizes many of the tricky points that have to be considered for hp finite elements using continuous elements.

The full reference for this paper is as follows:

Article{BK07,
  author =       {Wolfgang Bangerth and Oliver Kayser-Herold},
  title =        {Data Structures and Requirements for hp Finite Element
                  Software},
  journal =      {ACM Trans. Math. Softw.},
  year =         2009,
  volume =       36,
  number =       1,
  pages =        {4/1--4/31}
} 

It is available as Technical Report ISC-07-04-MATH from the Institute for Scientific Computation, Texas A&M University, and also from http://www.math.tamu.edu/~bangerth/publications.html .

The numerical examples shown in that paper are generated with a slightly modified version of step-27. The main difference to that tutorial program is that various operations in the program were timed for the paper to compare different options and show that $hp$ methods are really not all that expensive.

Interpolation with finite elements

The purpose of interpolation with finite elements is computing a vector of coefficients representing a finite element function, such that the node values of the original function and the finite element function coincide. Therefore, the interpolation process consists of evaluating all node functionals Ni for the given function f and store the result as entry i in the coefficient vector.

Lagrange elements

Finite elements based on Lagrangian interpolation at support points.

Node values or node functionals

It is customary to define a FiniteElement as a pair consisting of a local function space and a set of node values $N_i$ on the mesh cells (usually defined on the reference cell). Then, the basis of the local function space is chosen such that $N_i(v_j) = \delta_{ij}$, the Kronecker delta.

This splitting has several advantages, concerning analysis as well as implementation. For the analysis, it means that conformity with certain spaces (FiniteElementData::Conformity), e.g. continuity, is up to the node values. In deal.II, it helps simplifying the implementation of more complex elements like FE_RaviartThomas considerably.

Examples for node functionals are values in support points and moments with respect to Legendre polynomials. Let us give some examples:

Element

Function space

Node values

FE_Q, FE_DGQ

Qk

values in support points

FE_DGP

Pk

moments with respect to Legendre polynomials

FE_RaviartThomas (2d)

Qk+1,k x Qk,k+1

moments on edges and in the interior

FE_RaviartThomasNodal

Qk+1,k x Qk,k+1

Gauss points on edges(faces) and anisotropic Gauss points in the interior

Primitive finite elements

Finite element shape function sets with a unique relation from shape function number to vector component. What this means is that each shape function of a vector-valued element has exactly one-nonzero component if an element is primitive. This includes, in particular, all scalar elements as well as vector-valued elements assembled via the FESystem class from other primitive (for example scalar) elements as shown in step-8, step_29 or step-22. On the other hand, the FE_RaviartThomas class used in step-20 and step-21, or the FE_Nedelec class provide non-primitive finite elements because there each vector-value shape function may have several non-zero components.

Reference cell

The hypercube [0,1]dim, on which all parametric finite element shape functions are defined.

Shape functions

The restriction of the finite element basis functions to a single grid cell.

Support points

Support points are by definition those points $p_i$, such that for the shape functions $v_j$ holds $v_j(p_i) = \delta_{ij}$. Therefore, a finite element interpolation can be defined uniquely by the values in the support points.

Lagrangian elements fill the vector accessed by FiniteElementBase::get_unit_support_points(), such that the function FiniteElementBase::has_support_points() returns true. Naturally, these support points are on the reference cell. Then, FEValues can be used (in conjunction with a Mapping) to access support points on the actual grid cells.

Note:
The concept of support points is restricted to the finite element families based on Lagrange interpolation. For a more general concept, see generalized support points.
Target component

When vectors and matrices are grouped into blocks by component, it is often desirable to collect several of the original components into a single one. This could be for instance, grouping the velocities of a Stokes system into a single block.

Unit cell

See Reference cell.

Unit support points

Support points on the reference cell, defined in FiniteElementBase. For example, the usual Q1 element in 1d has support points at x=0 and x=1 (and similarly, in higher dimensions at the vertices of the unit square or cube). On the other hand, higher order Lagrangian elements have unit support points also in the interior of the unit line, square, or cube.


deal.II documentation generated on Mon Nov 23 22:56:37 2009 by doxygen 1.6.1