It is often convenient to treat a matrix or vector as a collection of individual blocks. For example, in step-20 (and other tutorial programs), we want to consider the global linear system in the form
-It is often convenient to treat a matrix or vector as a collection of individual blocks. For example, in step-20 (and other tutorial programs), we want to consider the global linear system in the form
+
+ \end{eqnarray*}" src="form_92.png"/>
-
where are the values of velocity and pressure degrees of freedom, respectively, is the mass matrix on the velocity space, corresponds to the negative divergence operator, and is its transpose and corresponds to the negative gradient.
+
where are the values of velocity and pressure degrees of freedom, respectively, is the mass matrix on the velocity space, corresponds to the negative divergence operator, and is its transpose and corresponds to the negative gradient.
Using such a decomposition into blocks, one can then define preconditioners that are based on the individual operators that are present in a system of equations (for example the Schur complement, in the case of step-20), rather than the entire matrix. In essence, blocks 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. On the other hand, the matrix and right hand side vector can also treated as a unit, which is convenient for example during assembly of the linear system when one may not want to make a distinction between the individual components, or for an outer Krylov space solver that doesn't care about the block structure (e.g. if only the preconditioner needs the block structure).
Splitting matrices and vectors into blocks is supported by the BlockSparseMatrix, BlockVector, and related classes. See the overview of the various linear algebra classes in the Linear algebra classes module. The objects present two interfaces: one that makes the object look like a matrix or vector with global indexing operations, and one that makes the object look like a collection of sub-blocks that can be individually addressed. Depending on context, one may wish to use one or the other interface.
Typically, one defines the sub-structure of a matrix or vector by grouping the degrees of freedom that make up groups of physical quantities (for example all velocities) into individual blocks of the linear system. This is defined in more detail below in the glossary entry on Block (finite element).
With the exception of the number of blocks, the two objects are the same for all practical purposes, however.
Global degrees of freedom: While we have defined blocks above in terms of the vector components of a vector-valued solution function (or, equivalently, in terms of the vector-valued finite element space), every shape function of a finite element is part of one block or another. Consequently, we can partition all degrees of freedom defined on a DoFHandler into individual blocks. Since by default the DoFHandler class enumerates degrees of freedom in a more or less random way, you will first want to call the DoFRenumbering::component_wise function to make sure that all degrees of freedom that correspond to a single block are enumerated consecutively.
-
If you do this, you naturally partition matrices and vectors into blocks as well (see block (linear algebra)). In most cases, when you subdivide a matrix or vector into blocks, you do so by creating one block for each block defined by the finite element (i.e. in most practical cases the FESystem object). However, this needs not be so: the DoFRenumbering::component_wise function allows to group several vector components or finite element blocks into the same logical block (see, for example, the step-22 or step-31 tutorial programs, as opposed to step-20). As a consequence, using this feature, we can achieve the same result, i.e. subdividing matrices into blocks and vectors into 2 blocks, for the second way of creating a Stokes element outlined above using an extra argument as we would have using the first way of creating the Stokes element with two blocks right away.
+
If you do this, you naturally partition matrices and vectors into blocks as well (see block (linear algebra)). In most cases, when you subdivide a matrix or vector into blocks, you do so by creating one block for each block defined by the finite element (i.e. in most practical cases the FESystem object). However, this needs not be so: the DoFRenumbering::component_wise function allows to group several vector components or finite element blocks into the same logical block (see, for example, the step-22 or step-31 tutorial programs, as opposed to step-20). As a consequence, using this feature, we can achieve the same result, i.e. subdividing matrices into blocks and vectors into 2 blocks, for the second way of creating a Stokes element outlined above using an extra argument as we would have using the first way of creating the Stokes element with two blocks right away.
More information on this topic can be found in the documentation of FESystem, the Handling vector valued problems module and the tutorial programs referenced therein.
Selecting blocks: Many functions allow you to restrict their operation to certain vector components or blocks. For example, this is the case for the functions that interpolate boundary values: one may want to only interpolate the boundary values for the velocity block of a finite element field but not the pressure block. The way to do this is by passing a BlockMask argument to such functions, see the block mask entry of this glossary.
@@ -162,14 +162,14 @@
Boundary form
For a dim-dimensional triangulation in dim-dimensional space, the boundary form is a vector defined on faces. It is the vector product of the image of coordinate vectors on the surface of the unit cell. It is a vector normal to the surface, pointing outwards and having the length of the surface element.
-
A more general definition would be that (at least up to the length of this vector) it is exactly that vector that is necessary when considering integration by parts, i.e. equalities of the form . Using this definition then also explains what this vector should be in the case of domains (and corresponding triangulations) of dimension dim that are embedded in a space spacedim: in that case, the boundary form is still a vector defined on the faces of the triangulation; it is orthogonal to all tangent directions of the boundary and within the tangent plane of the domain. Note that this is compatible with case dim==spacedim since there the tangent plane is the entire space .
+
A more general definition would be that (at least up to the length of this vector) it is exactly that vector that is necessary when considering integration by parts, i.e. equalities of the form . Using this definition then also explains what this vector should be in the case of domains (and corresponding triangulations) of dimension dim that are embedded in a space spacedim: in that case, the boundary form is still a vector defined on the faces of the triangulation; it is orthogonal to all tangent directions of the boundary and within the tangent plane of the domain. Note that this is compatible with case dim==spacedim since there the tangent plane is the entire space .
In either case, the length of the vector equals the determinant of the transformation of reference face to the face of the current cell.
Boundary indicator
In a Triangulation object, every part of the boundary may be associated with a unique number (of type types::boundary_id) that is used to determine what kinds of boundary conditions are to be applied to a particular part of a boundary. The boundary is composed of the faces of the cells and, in 3d, the edges of these faces.
-
By default, all boundary indicators of a mesh are zero, unless you are reading from a mesh file that specifically sets them to something different, or unless you use one of the mesh generation functions in namespace GridGenerator that have a colorize option. A typical piece of code that sets the boundary indicator on part of the boundary to something else would look like this, here setting the boundary indicator to 42 for all faces located at :
for (auto &face : triangulation.active_face_iterators())
+
By default, all boundary indicators of a mesh are zero, unless you are reading from a mesh file that specifically sets them to something different, or unless you use one of the mesh generation functions in namespace GridGenerator that have a colorize option. A typical piece of code that sets the boundary indicator on part of the boundary to something else would look like this, here setting the boundary indicator to 42 for all faces located at :
for (auto &face : triangulation.active_face_iterators())
if (face->at_boundary())
if (face->center()[0] == -1)
face->set_boundary_id (42);
@@ -237,7 +237,7 @@
Component
-
When considering systems of equations in which the solution is not just a single scalar function, we say that we have a vector system with a vector-valued solution. For example, the vector solution in the elasticity equation considered in step-8 is consisting of the displacements in each of the three coordinate directions. The solution then has three elements. Similarly, the 3d Stokes equation considered in step-22 has four elements: . We call the elements of the vector-valued solution components in deal.II. To be well-posed, for the solution to have components, there need to be partial differential equations to describe them. This concept is discussed in great detail in the Handling vector valued problems module.
+
When considering systems of equations in which the solution is not just a single scalar function, we say that we have a vector system with a vector-valued solution. For example, the vector solution in the elasticity equation considered in step-8 is consisting of the displacements in each of the three coordinate directions. The solution then has three elements. Similarly, the 3d Stokes equation considered in step-22 has four elements: . We call the elements of the vector-valued solution components in deal.II. To be well-posed, for the solution to have components, there need to be partial differential equations to describe them. This concept is discussed in great detail in the Handling vector valued problems module.
In finite element programs, one frequently wants to address individual elements (components) of this vector-valued solution, or sets of components. For example, we do this extensively in step-8, and a lot of documentation is also provided in the module on Handling vector valued problems. If you are thinking only in terms of the partial differential equation (not in terms of its discretization), then the concept of components is the natural one.
On the other hand, when talking about finite elements and degrees of freedom, components are not always the correct concept because components are not always individually addressable. In particular, this is the case for non-primitive finite elements. Similarly, one may not always want to address individual components but rather sets of components — e.g. all velocity components together, and separate from the pressure in the Stokes system, without further splitting the velocities into their individual components. In either case, the correct concept to think in is that of a block. Since each component, if individually addressable, is also a block, thinking in terms of blocks is most frequently the better strategy.
would result in a mask [true, true, false] in 2d. Of course, in 3d, the result would be [true, true, true, false].
Note
Just as one can think of composed elements as being made up of components or blocks, there are component masks (represented by the ComponentMask class) and block masks (represented by the BlockMask class). The FiniteElement class has functions that convert between the two kinds of objects.
-Not all component masks actually make sense. For example, if you have a FE_RaviartThomas object in 2d, then it doesn't make any sense to have a component mask of the form [true, false] because you try to select individual vector components of a finite element where each shape function has both and velocities. In essence, while you can of course create such a component mask, there is nothing you can do with it.
+Not all component masks actually make sense. For example, if you have a FE_RaviartThomas object in 2d, then it doesn't make any sense to have a component mask of the form [true, false] because you try to select individual vector components of a finite element where each shape function has both and velocities. In essence, while you can of course create such a component mask, there is nothing you can do with it.
Compressing distributed vectors and matrices
For parallel computations, deal.II uses the vector and matrix classes defined in the PETScWrappers and TrilinosWrappers namespaces. When running programs in parallel using MPI, these classes only store a certain number of rows or elements on the current processor, whereas the rest of the vector or matrix is stored on the other processors that belong to our MPI universe. This presents a certain problem when you assemble linear systems: we add elements to the matrix and right hand side vectors that may or may not be stored locally. Sometimes, we may also want to just set an element, not add to it.
@@ -301,9 +301,9 @@
Degree of freedom
-
The term "degree of freedom" (often abbreviated as "DoF") is commonly used in the finite element community to indicate two slightly different, but related things. The first is that we'd like to represent the finite element solution as a linear combination of shape functions, in the form . Here, is a vector of expansion coefficients. Because we don't know their values yet (we will compute them as the solution of a linear or nonlinear system), they are called "unknowns" or "degrees of freedom". The second meaning of the term can be explained as follows: A mathematical description of finite element problem is often to say that we are looking for a finite dimensional function that satisfies some set of equations (e.g. for all test functions ). In other words, all we say here that the solution needs to lie in some space . However, to actually solve this problem on a computer we need to choose a basis of this space; this is the set of shape functions we have used above in the expansion of with coefficients . There are of course many bases of the space , but we will specifically choose the one that is described by the finite element functions that are traditionally defined locally on the cells of the mesh. Describing "degrees of freedom" in this context requires us to simply enumerate the basis functions of the space . For elements this means simply enumerating the vertices of the mesh in some way, but for higher elements one also has to enumerate the shape functions that are associated with edges, faces, or cell interiors of the mesh. The class that provides this enumeration of the basis functions of is called DoFHandler. The process of enumerating degrees of freedom is referred to as "distributing DoFs" in deal.II.
+
The term "degree of freedom" (often abbreviated as "DoF") is commonly used in the finite element community to indicate two slightly different, but related things. The first is that we'd like to represent the finite element solution as a linear combination of shape functions, in the form . Here, is a vector of expansion coefficients. Because we don't know their values yet (we will compute them as the solution of a linear or nonlinear system), they are called "unknowns" or "degrees of freedom". The second meaning of the term can be explained as follows: A mathematical description of finite element problem is often to say that we are looking for a finite dimensional function that satisfies some set of equations (e.g. for all test functions ). In other words, all we say here that the solution needs to lie in some space . However, to actually solve this problem on a computer we need to choose a basis of this space; this is the set of shape functions we have used above in the expansion of with coefficients . There are of course many bases of the space , but we will specifically choose the one that is described by the finite element functions that are traditionally defined locally on the cells of the mesh. Describing "degrees of freedom" in this context requires us to simply enumerate the basis functions of the space . For elements this means simply enumerating the vertices of the mesh in some way, but for higher elements one also has to enumerate the shape functions that are associated with edges, faces, or cell interiors of the mesh. The class that provides this enumeration of the basis functions of is called DoFHandler. The process of enumerating degrees of freedom is referred to as "distributing DoFs" in deal.II.
Direction flags
@@ -324,7 +324,7 @@
Distorted cells
A distorted cell is a cell for which the mapping from the reference cell to real cell has a Jacobian whose determinant is non-positive somewhere in the cell. Typically, we only check the sign of this determinant at the vertices of the cell. The function GeometryInfo::alternating_form_at_vertices computes these determinants at the vertices.
-
By way of example, if all of the determinants are of roughly equal value and on the order of then the cell is well-shaped. For example, a square cell or face has determinants equal to whereas a strongly sheared parallelogram has a determinant much smaller. Similarly, a cell with very unequal edge lengths will have widely varying determinants. Conversely, a pinched cell in which the location of two or more vertices is collapsed to a single point has a zero determinant at this location. Finally, an inverted or twisted cell in which the location of two vertices is out of order will have negative determinants.
+
By way of example, if all of the determinants are of roughly equal value and on the order of then the cell is well-shaped. For example, a square cell or face has determinants equal to whereas a strongly sheared parallelogram has a determinant much smaller. Similarly, a cell with very unequal edge lengths will have widely varying determinants. Conversely, a pinched cell in which the location of two or more vertices is collapsed to a single point has a zero determinant at this location. Finally, an inverted or twisted cell in which the location of two vertices is out of order will have negative determinants.
The following two images show a well-formed, a pinched, and a twisted cell for both 2d and 3d:
@@ -363,19 +363,19 @@
Generalized support points
-
"Generalized support points" are, as the name suggests, a generalization of support points. The latter are used to describe that a finite element simply interpolates values at individual points (the "support points"). If we call these points (where the hat indicates that these points are defined on the reference cell ), then one typically defines shape functions in such a way that the nodal functionals simply evaluate the function at the support point, i.e., that , and the basis is chosen so that where is the Kronecker delta function. This leads to the common Lagrange elements.
-
(In the vector valued case, the only other piece of information besides the support points that one needs to provide is the vector component the th node functional corresponds, so that .)
-
On the other hand, there are other kinds of elements that are not defined this way. For example, for the lowest order Raviart-Thomas element (see the FE_RaviartThomas class), the node functional evaluates not individual components of a vector-valued finite element function with dim components, but the normal component of this vector: "Generalized support points" are, as the name suggests, a generalization of support points. The latter are used to describe that a finite element simply interpolates values at individual points (the "support points"). If we call these points (where the hat indicates that these points are defined on the reference cell ), then one typically defines shape functions in such a way that the nodal functionals simply evaluate the function at the support point, i.e., that , and the basis is chosen so that where is the Kronecker delta function. This leads to the common Lagrange elements.
+
(In the vector valued case, the only other piece of information besides the support points that one needs to provide is the vector component the th node functional corresponds, so that .)
+
On the other hand, there are other kinds of elements that are not defined this way. For example, for the lowest order Raviart-Thomas element (see the FE_RaviartThomas class), the node functional evaluates not individual components of a vector-valued finite element function with dim components, but the normal component of this vector: , where the are the normal vectors to the face of the cell on which is located. In other words, the node functional is a linear combination of the components of when evaluated at . Similar things happen for the BDM, ABF, and Nedelec elements (see the FE_BDM, FE_ABF, FE_Nedelec classes).
-
In these cases, the element does not have support points because it is not purely interpolatory; however, some kind of interpolation is still involved when defining shape functions as the node functionals still require point evaluations at special points . In these cases, we call the points generalized support points.
-
Finally, there are elements that still do not fit into this scheme. For example, some hierarchical basis functions (see, for example the FE_Q_Hierarchical element) are defined so that the node functionals are moments of finite element functions, , where the are the normal vectors to the face of the cell on which is located. In other words, the node functional is a linear combination of the components of when evaluated at . Similar things happen for the BDM, ABF, and Nedelec elements (see the FE_BDM, FE_ABF, FE_Nedelec classes).
+
In these cases, the element does not have support points because it is not purely interpolatory; however, some kind of interpolation is still involved when defining shape functions as the node functionals still require point evaluations at special points . In these cases, we call the points generalized support points.
+
Finally, there are elements that still do not fit into this scheme. For example, some hierarchical basis functions (see, for example the FE_Q_Hierarchical element) are defined so that the node functionals are moments of finite element functions, in 2d, and similarly for 3d, where the are the order of the moment described by shape function . Some other elements use moments over edges or faces. In all of these cases, node functionals are not defined through interpolation at all, and these elements then have neither support points, nor generalized support points.
+ $" src="form_124.png"/> in 2d, and similarly for 3d, where the are the order of the moment described by shape function . Some other elements use moments over edges or faces. In all of these cases, node functionals are not defined through interpolation at all, and these elements then have neither support points, nor generalized support points.
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 methods are really not all that expensive.
+
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 methods are really not all that expensive.
It frequently appears in the solution of time dependent problems where, if one uses an explicit time stepping method, it then leads to the need to solve problems of the form
-
+ \end{align*}" src="form_127.png"/>
-
in time step , where is the solution to be computed, is the known solution from the first time step, and is a matrix related to the differential operator in the PDE. is the size of the time step. A similar linear system of equations also arises out of the discretization of second-order differential equations.
-
The presence of the matrix on the left side is a nuisance because, even though we have used an explicit time stepping method, we still have to solve a linear system in each time step. It would be much preferable if the matrix were diagonal. "Lumping" the mass matrix is a strategy to replace by a matrix that actually is diagonal, yet does not destroy the accuracy of the resulting solution.
-
Historically, mass lumping was performed by adding the elements of a row together and setting the diagonal entries of to that sum. This works for and elements, for example, and can be understood mechanically by replacing the continuous medium we are discretizating by one where the continuous mass distribution is replaced by one where (finite amounts of) mass are located only at the nodes. That is, we are "lumping together" the mass of an element at its vertices, thus giving rise to the name "lumped mass matrix". A more mathematical perspective is to compute the integral above for via special quadrature rules; in particular, we replace the computation of
-, where is the solution to be computed, is the known solution from the first time step, and is a matrix related to the differential operator in the PDE. is the size of the time step. A similar linear system of equations also arises out of the discretization of second-order differential equations.
+
The presence of the matrix on the left side is a nuisance because, even though we have used an explicit time stepping method, we still have to solve a linear system in each time step. It would be much preferable if the matrix were diagonal. "Lumping" the mass matrix is a strategy to replace by a matrix that actually is diagonal, yet does not destroy the accuracy of the resulting solution.
+
Historically, mass lumping was performed by adding the elements of a row together and setting the diagonal entries of to that sum. This works for and elements, for example, and can be understood mechanically by replacing the continuous medium we are discretizating by one where the continuous mass distribution is replaced by one where (finite amounts of) mass are located only at the nodes. That is, we are "lumping together" the mass of an element at its vertices, thus giving rise to the name "lumped mass matrix". A more mathematical perspective is to compute the integral above for via special quadrature rules; in particular, we replace the computation of
+
+ \end{align*}" src="form_134.png"/>
by quadrature
-
+ \end{align*}" src="form_135.png"/>
where we choose the quadrature points as the nodes at which the shape functions are defined. If we order the quadrature points in the same way as the shape functions, then
-
+ \end{align*}" src="form_136.png"/>
and consequently
-
+ \end{align*}" src="form_137.png"/>
-
where the sum extends over those cells on which is nonzero. The so-computed mass matrix is therefore diagonal.
-
Whether or not this particular choice of quadrature formula is sufficient to retain the convergence rate of the discretization is a separate question. For the usual finite elements (implemented by FE_Q and FE_DGQ), the appropriate quadrature formulas are of QGaussLobatto type. Mass lumping can also be done with FE_SimplexP_Bubbles, for example, if appropriate quadrature rules are chosen.
+
where the sum extends over those cells on which is nonzero. The so-computed mass matrix is therefore diagonal.
+
Whether or not this particular choice of quadrature formula is sufficient to retain the convergence rate of the discretization is a separate question. For the usual finite elements (implemented by FE_Q and FE_DGQ), the appropriate quadrature formulas are of QGaussLobatto type. Mass lumping can also be done with FE_SimplexP_Bubbles, for example, if appropriate quadrature rules are chosen.
For an example of where lumped mass matrices play a role, see step-69.
Manifold indicator
Every object that makes up a Triangulation (cells, faces, edges, etc.), is associated with a unique number (of type types::manifold_id) that is used to identify which manifold object is responsible to generate new points when the mesh is refined.
-
By default, all manifold indicators of a mesh are set to numbers::flat_manifold_id. A typical piece of code that sets the manifold indicator on a object to something else would look like this, here setting the manifold indicator to 42 for all cells whose center has an component less than zero:
+
By default, all manifold indicators of a mesh are set to numbers::flat_manifold_id. A typical piece of code that sets the manifold indicator on a object to something else would look like this, here setting the manifold indicator to 42 for all cells whose center has an component less than zero:
for (auto &cell : triangulation.active_cell_iterators())
Improved: The FEValuesViews objects that one gets when writing things like fe_values[velocities] (see Handling vector valued problems) have become a lot smarter. They now compute a significant amount of data at creation time, rather than on the fly. This means that creating such objects becomes more expensive but using them is cheaper. To offset this cost, FEValuesBase objects now create all possible FEValuesViews objects at creation time, rather than whenever you do things like fe_values[velocities], and simply return a reference to a pre-generated object. This turns an effort into an effort, where is the number of cells.
+
Improved: The FEValuesViews objects that one gets when writing things like fe_values[velocities] (see Handling vector valued problems) have become a lot smarter. They now compute a significant amount of data at creation time, rather than on the fly. This means that creating such objects becomes more expensive but using them is cheaper. To offset this cost, FEValuesBase objects now create all possible FEValuesViews objects at creation time, rather than whenever you do things like fe_values[velocities], and simply return a reference to a pre-generated object. This turns an effort into an effort, where is the number of cells.
(WB 2008/12/10)
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/changes_between_6_2_and_6_3.html differs (JavaScript source, ASCII text, with very long lines (994))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/changes_between_6_2_and_6_3.html 2023-11-25 15:25:50.673410996 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/changes_between_6_2_and_6_3.html 2023-11-25 15:25:50.673410996 +0100
@@ -364,7 +364,7 @@
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/changes_between_7_0_and_7_1.html differs (JavaScript source, ASCII text, with very long lines (1392))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/changes_between_7_0_and_7_1.html 2023-11-25 15:25:50.686744058 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/changes_between_7_0_and_7_1.html 2023-11-25 15:25:50.686744058 +0100
@@ -374,7 +374,7 @@
-
Improved: Evaluation of Lagrangian basis functions has been made stable by exchanging polynomial evaluation from the standard form to a product of linear factors, . This ensures accurate evaluation up to very high order and avoids inaccuracies when using high order finite elements.
+
Improved: Evaluation of Lagrangian basis functions has been made stable by exchanging polynomial evaluation from the standard form to a product of linear factors, . This ensures accurate evaluation up to very high order and avoids inaccuracies when using high order finite elements.
(Martin Kronbichler 2011/07/26)
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/changes_between_7_1_and_7_2.html differs (JavaScript source, ASCII text, with very long lines (1108))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/changes_between_7_1_and_7_2.html 2023-11-25 15:25:50.703410385 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/changes_between_7_1_and_7_2.html 2023-11-25 15:25:50.703410385 +0100
@@ -330,7 +330,7 @@
Fixed: Computing the norm and seminorm in VectorTools::integrate_difference was not implemented. This is now fixed.
(Wolfgang Bangerth 2012/06/02)
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/changes_between_8_1_and_8_2.html differs (JavaScript source, ASCII text, with very long lines (948))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/changes_between_8_1_and_8_2.html 2023-11-25 15:25:50.716743445 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/changes_between_8_1_and_8_2.html 2023-11-25 15:25:50.716743445 +0100
@@ -837,7 +837,7 @@
-
New: There is now a new class Functions::InterpolatedTensorProductGridData that can be used to (bi-/tri-)linearly interpolate data given on a tensor product mesh of (and and ) values, for example to evaluate experimentally determined coefficients, or to assess the accuracy of a solution by comparing with a solution generated by a different code and written in gridded data. There is also a new class Functions::InterpolatedUniformGridData that can perform the same task more efficiently if the data is stored on meshes that are uniform in each coordinate direction.
+
New: There is now a new class Functions::InterpolatedTensorProductGridData that can be used to (bi-/tri-)linearly interpolate data given on a tensor product mesh of (and and ) values, for example to evaluate experimentally determined coefficients, or to assess the accuracy of a solution by comparing with a solution generated by a different code and written in gridded data. There is also a new class Functions::InterpolatedUniformGridData that can perform the same task more efficiently if the data is stored on meshes that are uniform in each coordinate direction.
(Wolfgang Bangerth, 2013/12/20)
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/changes_between_8_4_2_and_8_5_0.html differs (JavaScript source, ASCII text, with very long lines (1360))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/changes_between_8_4_2_and_8_5_0.html 2023-11-25 15:25:50.736743038 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/changes_between_8_4_2_and_8_5_0.html 2023-11-25 15:25:50.736743038 +0100
@@ -516,7 +516,7 @@
-
Fixed: The FE_ABF class reported the maximal polynomial degree (via FiniteElement::degree) for elements of order as , but this is wrong. It should be (see Section 5 of the original paper of Arnold, Boffi, and Falk). This is now fixed.
+
Fixed: The FE_ABF class reported the maximal polynomial degree (via FiniteElement::degree) for elements of order as , but this is wrong. It should be (see Section 5 of the original paper of Arnold, Boffi, and Falk). This is now fixed.
(Wolfgang Bangerth, 2017/01/13)
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/changes_between_9_1_1_and_9_2_0.html differs (JavaScript source, ASCII text, with very long lines (1176))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/changes_between_9_1_1_and_9_2_0.html 2023-11-25 15:25:50.760075899 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/changes_between_9_1_1_and_9_2_0.html 2023-11-25 15:25:50.760075899 +0100
@@ -606,7 +606,7 @@
-
Improved: GridGenerator::hyper_shell() in 3d now supports more n_cells options. While previously only 6, 12, or 96 cells were possible, the function now supports any number of the kind with a non-negative integer. The new cases and correspond to refinement in the azimuthal direction of the 6 or 12 cell case with a single mesh layer in radial direction, and are intended for shells that are thin and should be given more resolution in azimuthal direction.
+
Improved: GridGenerator::hyper_shell() in 3d now supports more n_cells options. While previously only 6, 12, or 96 cells were possible, the function now supports any number of the kind with a non-negative integer. The new cases and correspond to refinement in the azimuthal direction of the 6 or 12 cell case with a single mesh layer in radial direction, and are intended for shells that are thin and should be given more resolution in azimuthal direction.
(Martin Kronbichler, 2020/04/07)
@@ -1560,7 +1560,7 @@
-
Improved: The additional roots of the HermiteLikeInterpolation with degree greater than four have been switched to the roots of the Jacobi polynomial , making the interior bubble functions orthogonal and improving the conditioning of interpolation slightly.
+
Improved: The additional roots of the HermiteLikeInterpolation with degree greater than four have been switched to the roots of the Jacobi polynomial , making the interior bubble functions orthogonal and improving the conditioning of interpolation slightly.
(Martin Kronbichler, 2019/07/12)
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classAffineConstraints.html differs (JavaScript source, ASCII text, with very long lines (1132))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classAffineConstraints.html 2023-11-25 15:25:50.793408553 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classAffineConstraints.html 2023-11-25 15:25:50.790075289 +0100
@@ -357,9 +357,9 @@
The algorithms used in the implementation of this class are described in some detail in the hp-paper. There is also a significant amount of documentation on how to use this class in the Constraints on degrees of freedom module.
Description of constraints
Each "line" in objects of this class corresponds to one constrained degree of freedom, with the number of the line being i, entered by using add_line() or add_lines(). The entries in this line are pairs of the form (j,aij), which are added by add_entry() or add_entries(). The organization is essentially a SparsityPattern, but with only a few lines containing nonzero elements, and therefore no data wasted on the others. For each line, which has been added by the mechanism above, an elimination of the constrained degree of freedom of the form
-
+\]" src="form_1577.png"/>
is performed, where bi is optional and set by set_inhomogeneity(). Thus, if a constraint is formulated for instance as a zero mean value of several degrees of freedom, one of the degrees has to be chosen to be eliminated.
Note that the constraints are linear in the xi, and that there might be a constant (non-homogeneous) term in the constraint. This is exactly the form we need for hanging node constraints, where we need to constrain one degree of freedom in terms of others. There are other conditions of this form possible, for example for implementing mean value conditions as is done in the step-11 tutorial program. The name of the class stems from the fact that these constraints can be represented in matrix form as Xx = b, and this object then describes the matrix X and the vector b. The most frequent way to create/fill objects of this type is using the DoFTools::make_hanging_node_constraints() function. The use of these objects is first explained in step-6.
@@ -929,13 +929,13 @@
-
Add an entry to a given line. In other words, this function adds a term to the constraints for the th degree of freedom.
+
Add an entry to a given line. In other words, this function adds a term to the constraints for the th degree of freedom.
If an entry with the same indices as the one this function call denotes already exists, then this function simply returns provided that the value of the entry is the same. Thus, it does no harm to enter a constraint twice.
Parameters
-
[in]
constrained_dof_index
The index of the degree of freedom that is being constrained.
-
[in]
column
The index of the degree of freedom being entered into the constraint for degree of freedom .
-
[in]
weight
The factor that multiplies .
+
[in]
constrained_dof_index
The index of the degree of freedom that is being constrained.
+
[in]
column
The index of the degree of freedom being entered into the constraint for degree of freedom .
+
[in]
weight
The factor that multiplies .
@@ -1010,11 +1010,11 @@
-
Set an inhomogeneity to the constraint for a degree of freedom. In other words, it adds a constant to the constraint for degree of freedom . For this to work, you need to call add_line() first for the given degree of freedom.
+
Set an inhomogeneity to the constraint for a degree of freedom. In other words, it adds a constant to the constraint for degree of freedom . For this to work, you need to call add_line() first for the given degree of freedom.
Parameters
-
[in]
constrained_dof_index
The index of the degree of freedom that is being constrained.
-
[in]
value
The right hand side value for the constraint on the degree of freedom .
+
[in]
constrained_dof_index
The index of the degree of freedom that is being constrained.
+
[in]
value
The right hand side value for the constraint on the degree of freedom .
@@ -1042,9 +1042,9 @@
Close the filling of entries. Since the lines of a matrix of this type are usually filled in an arbitrary order and since we do not want to use associative constrainers to store the lines, we need to sort the lines and within the lines the columns before usage of the matrix. This is done through this function.
Also, zero entries are discarded, since they are not needed.
After closing, no more entries are accepted. If the object was already closed, then this function returns immediately.
-
This function also resolves chains of constraints. For example, degree of freedom 13 may be constrained to while degree of freedom 7 is itself constrained as . Then, the resolution will be that . Note, however, that cycles in this graph of constraints are not allowed, i.e., for example may not itself be constrained, directly or indirectly, to again.
+
This function also resolves chains of constraints. For example, degree of freedom 13 may be constrained to while degree of freedom 7 is itself constrained as . Then, the resolution will be that . Note, however, that cycles in this graph of constraints are not allowed, i.e., for example may not itself be constrained, directly or indirectly, to again.
@@ -1487,9 +1487,9 @@
Print the constraints represented by the current object to the given stream.
For each constraint of the form
-
+\]" src="form_1586.png"/>
this function will write a sequence of lines that look like this:
42 2 : 0.5
42 14 : 0.25
@@ -2150,7 +2150,7 @@
This function takes a matrix of local contributions (local_matrix) corresponding to the degrees of freedom indices given in local_dof_indices and distributes them to the global matrix. In other words, this function implements a scatter operation. In most cases, these local contributions will be the result of an integration over a cell or face of a cell. However, as long as local_matrix and local_dof_indices have the same number of elements, this function is happy with whatever it is given.
In contrast to the similar function in the DoFAccessor class, this function also takes care of constraints, i.e. if one of the elements of local_dof_indices belongs to a constrained node, then rather than writing the corresponding element of local_matrix into global_matrix, the element is distributed to the entries in the global matrix to which this particular degree of freedom is constrained.
-
With this scheme, we never write into rows or columns of constrained degrees of freedom. In order to make sure that the resulting matrix can still be inverted, we need to do something with the diagonal elements corresponding to constrained nodes. Thus, if a degree of freedom in local_dof_indices is constrained, we distribute the corresponding entries in the matrix, but also add the absolute value of the diagonal entry of the local matrix to the corresponding entry in the global matrix. Assuming the discretized operator is positive definite, this guarantees that the diagonal entry is always non-zero, positive, and of the same order of magnitude as the other entries of the matrix. On the other hand, when solving a source problem the exact value of the diagonal element is not important, since the value of the respective degree of freedom will be overwritten by the distribute() call later on anyway.
+
With this scheme, we never write into rows or columns of constrained degrees of freedom. In order to make sure that the resulting matrix can still be inverted, we need to do something with the diagonal elements corresponding to constrained nodes. Thus, if a degree of freedom in local_dof_indices is constrained, we distribute the corresponding entries in the matrix, but also add the absolute value of the diagonal entry of the local matrix to the corresponding entry in the global matrix. Assuming the discretized operator is positive definite, this guarantees that the diagonal entry is always non-zero, positive, and of the same order of magnitude as the other entries of the matrix. On the other hand, when solving a source problem the exact value of the diagonal element is not important, since the value of the respective degree of freedom will be overwritten by the distribute() call later on anyway.
Note
The procedure described above adds an unforeseeable number of artificial eigenvalues to the spectrum of the matrix. Therefore, it is recommended to use the equivalent function with two local index vectors in such a case.
By using this function to distribute local contributions to the global object, one saves the call to the condense function after the vectors and matrices are fully assembled.
Note
This function in itself is thread-safe, i.e., it works properly also when several threads call it simultaneously. However, the function call is only thread-safe if the underlying global matrix allows for simultaneous access and the access is not to rows with the same global index at the same time. This needs to be made sure from the caller's site. There is no locking mechanism inside this method to prevent data races.
@@ -2200,7 +2200,7 @@
This function does almost the same as the function above but can treat general rectangular matrices. The main difference to achieve this is that the diagonal entries in constrained rows are left untouched instead of being filled with arbitrary values.
-
Since the diagonal entries corresponding to eliminated degrees of freedom are not set, the result may have a zero eigenvalue, if applied to a square matrix. This has to be considered when solving the resulting problems. For solving a source problem , it is possible to set the diagonal entry after building the matrix by a piece of code of the form
+
Since the diagonal entries corresponding to eliminated degrees of freedom are not set, the result may have a zero eigenvalue, if applied to a square matrix. This has to be considered when solving the resulting problems. For solving a source problem , it is possible to set the diagonal entry after building the matrix by a piece of code of the form
for (unsignedint i=0;i<matrix.m();++i)
if (constraints.is_constrained(i))
matrix.diag_element(i) = 1.;
@@ -2541,7 +2541,7 @@
-
Given a vector, set all constrained degrees of freedom to values so that the constraints are satisfied. For example, if the current object stores the constraint , then this function will read the values of and from the given vector and set the element according to this constraints. Similarly, if the current object stores the constraint , then this function will set the 42nd element of the given vector to 208.
+
Given a vector, set all constrained degrees of freedom to values so that the constraints are satisfied. For example, if the current object stores the constraint , then this function will read the values of and from the given vector and set the element according to this constraints. Similarly, if the current object stores the constraint , then this function will set the 42nd element of the given vector to 208.
Note
If this function is called with a parallel vector vec, then the vector must not contain ghost elements.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classAlgorithms_1_1ThetaTimestepping.html differs (JavaScript source, Unicode text, UTF-8 text, with very long lines (950))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classAlgorithms_1_1ThetaTimestepping.html 2023-11-25 15:25:50.813408145 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classAlgorithms_1_1ThetaTimestepping.html 2023-11-25 15:25:50.813408145 +0100
@@ -218,9 +218,9 @@
For fixed theta, the Crank-Nicolson scheme is the only second order scheme. Nevertheless, further stability may be achieved by choosing theta larger than ½, thereby introducing a first order error term. In order to avoid a loss of convergence order, the adaptive theta scheme can be used, where theta=½+c dt.
Assume that we want to solve the equation u' + F(u) = 0 with a step size k. A step of the theta scheme can be written as
-
+\]" src="form_351.png"/>
Here, M is the mass matrix. We see, that the right hand side amounts to an explicit Euler step with modified step size in weak form (up to inversion of M). The left hand side corresponds to an implicit Euler step with modified step size (right hand side given). Thus, the implementation of the theta scheme will use two Operator objects, one for the explicit, one for the implicit part. Each of these will use its own TimestepData to account for the modified step sizes (and different times if the problem is not autonomous). Note that once the explicit part has been computed, the left hand side actually constitutes a linear or nonlinear system which has to be solved.
Now we need to study the application of the implicit and explicit operator. We assume that the pointer matrix points to the matrix created in the main program (the constructor did this for us). Here, we first get the time step size from the AnyData object that was provided as input. Then, if we are in the first step or if the timestep has changed, we fill the local matrix , such that with the given matrix , it becomes
-
+
Now we need to study the application of the implicit and explicit operator. We assume that the pointer matrix points to the matrix created in the main program (the constructor did this for us). Here, we first get the time step size from the AnyData object that was provided as input. Then, if we are in the first step or if the timestep has changed, we fill the local matrix , such that with the given matrix , it becomes
+
After we have worked off the notifications, we clear them, such that the matrix is only generated when necessary.
The operator computing the explicit part of the scheme. This will receive in its input data the value at the current time with name "Current time solution". It should obtain the current time and time step size from explicit_data().
-
Its return value is , where is the current state vector, the mass matrix, the operator in space and is the adjusted time step size .
+
Its return value is , where is the current state vector, the mass matrix, the operator in space and is the adjusted time step size .
The operator solving the implicit part of the scheme. It will receive in its input data the vector "Previous time". Information on the timestep should be obtained from implicit_data().
-
Its return value is the solution u of Mu-cF(u)=f, where f is the dual space vector found in the "Previous time" entry of the input data, M the mass matrix, F the operator in space and c is the adjusted time step size
+
Its return value is the solution u of Mu-cF(u)=f, where f is the dual space vector found in the "Previous time" entry of the input data, M the mass matrix, F the operator in space and c is the adjusted time step size
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classAnisotropicPolynomials.html differs (JavaScript source, ASCII text, with very long lines (1527))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classAnisotropicPolynomials.html 2023-11-25 15:25:50.833407738 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classAnisotropicPolynomials.html 2023-11-25 15:25:50.833407738 +0100
@@ -153,10 +153,10 @@
Detailed Description
template<int dim>
class AnisotropicPolynomials< dim >
Anisotropic tensor product of given polynomials.
-
Given one-dimensional polynomials in -direction, in -direction, and so on, this class generates polynomials of the form . (With obvious generalization if dim is in fact only 2. If dim is in fact only 1, then the result is simply the same set of one-dimensional polynomials passed to the constructor.)
-
If the elements of each set of base polynomials are mutually orthogonal on the interval or , then the tensor product polynomials are orthogonal on or , respectively.
-
The resulting dim-dimensional tensor product polynomials are ordered as follows: We iterate over the coordinates running fastest, then the coordinate, etc. For example, for dim==2, the first few polynomials are thus , , , ..., , , , etc.
+
Given one-dimensional polynomials in -direction, in -direction, and so on, this class generates polynomials of the form . (With obvious generalization if dim is in fact only 2. If dim is in fact only 1, then the result is simply the same set of one-dimensional polynomials passed to the constructor.)
+
If the elements of each set of base polynomials are mutually orthogonal on the interval or , then the tensor product polynomials are orthogonal on or , respectively.
+
The resulting dim-dimensional tensor product polynomials are ordered as follows: We iterate over the coordinates running fastest, then the coordinate, etc. For example, for dim==2, the first few polynomials are thus , , , ..., , , , etc.
Each tensor product polynomial is a product of one-dimensional polynomials in each space direction. Compute the indices of these one- dimensional polynomials for each space direction, given the index i.
+
Each tensor product polynomial is a product of one-dimensional polynomials in each space direction. Compute the indices of these one- dimensional polynomials for each space direction, given the index i.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classArpackSolver.html differs (JavaScript source, ASCII text, with very long lines (1026))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classArpackSolver.html 2023-11-25 15:25:50.850074067 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classArpackSolver.html 2023-11-25 15:25:50.850074067 +0100
@@ -229,14 +229,14 @@
Detailed Description
Interface for using ARPACK. ARPACK is a collection of Fortran77 subroutines designed to solve large scale eigenvalue problems. Here we interface to the routines dnaupd and dneupd of ARPACK. If the operator is specified to be symmetric we use the symmetric interface dsaupd and dseupd of ARPACK instead. The package is designed to compute a few eigenvalues and corresponding eigenvectors of a general n by n matrix A. It is most appropriate for large sparse matrices A.
-
In this class we make use of the method applied to the generalized eigenspectrum problem , for ; where is a system matrix, is a mass matrix, and are a set of eigenvalues and eigenvectors respectively.
+
In this class we make use of the method applied to the generalized eigenspectrum problem , for ; where is a system matrix, is a mass matrix, and are a set of eigenvalues and eigenvectors respectively.
The ArpackSolver can be used in application codes with serial objects in the following way:
for the generalized eigenvalue problem , where the variable size_of_spectrum tells ARPACK the number of eigenvector/eigenvalue pairs to solve for. Here, lambda is a vector that will contain the eigenvalues computed, x a vector that will contain the eigenvectors computed, and OP is an inverse operation for the matrix A. Shift and invert transformation around zero is applied.
+
for the generalized eigenvalue problem , where the variable size_of_spectrum tells ARPACK the number of eigenvector/eigenvalue pairs to solve for. Here, lambda is a vector that will contain the eigenvalues computed, x a vector that will contain the eigenvectors computed, and OP is an inverse operation for the matrix A. Shift and invert transformation around zero is applied.
Through the AdditionalData the user can specify some of the parameters to be set.
For further information on how the ARPACK routines dsaupd, dseupd, dnaupd and dneupd work and also how to set the parameters appropriately please take a look into the ARPACK manual.
Note
Whenever you eliminate degrees of freedom using AffineConstraints, you generate spurious eigenvalues and eigenvectors. If you make sure that the diagonals of eliminated matrix rows are all equal to one, you get a single additional eigenvalue. But beware that some functions in deal.II set these diagonals to rather arbitrary (from the point of view of eigenvalue problems) values. See also step-36 for an example.
@@ -525,7 +525,7 @@
-
Solve the generalized eigensprectrum problem by calling the dsaupd and dseupd or dnaupd and dneupd functions of ARPACK.
+
Solve the generalized eigensprectrum problem by calling the dsaupd and dseupd or dnaupd and dneupd functions of ARPACK.
The function returns a vector of eigenvalues of length n and a vector of eigenvectors of length n in the symmetric case and of length n+1 in the non-symmetric case. In the symmetric case all eigenvectors are real. In the non-symmetric case complex eigenvalues always occur as complex conjugate pairs. Therefore the eigenvector for an eigenvalue with nonzero complex part is stored by putting the real and the imaginary parts in consecutive real-valued vectors. The eigenvector of the complex conjugate eigenvalue does not need to be stored, since it is just the complex conjugate of the stored eigenvector. Thus, if the last n-th eigenvalue has a nonzero imaginary part, Arpack needs in total n+1 real-valued vectors to store real and imaginary parts of the eigenvectors.
Parameters
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classArrayView.html differs (JavaScript source, ASCII text, with very long lines (911))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classArrayView.html 2023-11-25 15:25:50.873406924 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classArrayView.html 2023-11-25 15:25:50.873406924 +0100
@@ -1025,7 +1025,7 @@
-
Return a reference to the th element of the range represented by the current object.
+
Return a reference to the th element of the range represented by the current object.
This function is marked as const because it does not change the view object. It may however return a reference to a non-const memory location depending on whether the template type of the class is const or not.
This function is only allowed to be called if the underlying data is indeed stored in CPU memory.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classAutoDerivativeFunction.html differs (JavaScript source, ASCII text, with very long lines (2139))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classAutoDerivativeFunction.html 2023-11-25 15:25:50.896739784 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classAutoDerivativeFunction.html 2023-11-25 15:25:50.896739784 +0100
@@ -346,27 +346,27 @@
where each value is the relative weight of each vertex (so the centroid is, in 2d, where each ). Since we only consider convex combinations we can rewrite this equation as
+
where each value is the relative weight of each vertex (so the centroid is, in 2d, where each ). Since we only consider convex combinations we can rewrite this equation as
Detailed Description
template<typename VectorType>
class BaseQR< VectorType >
This class and classes derived from it are meant to build and matrices one row/column at a time, i.e., by growing matrix from an empty matrix to , where is the number of added column vectors.
-
As a consequence, matrices which have the same number of rows as each vector (i.e. matrix) is stored as a collection of vectors of VectorType.
+
This class and classes derived from it are meant to build and matrices one row/column at a time, i.e., by growing matrix from an empty matrix to , where is the number of added column vectors.
+
As a consequence, matrices which have the same number of rows as each vector (i.e. matrix) is stored as a collection of vectors of VectorType.
BlockIndices represents a range of indices (such as the range of valid indices for elements of a vector) and how this one range is broken down into smaller but contiguous "blocks" (such as the velocity and pressure parts of a solution vector). In particular, it provides the ability to translate between global indices and the indices within a block. This class is used, for example, in the BlockVector, BlockSparsityPattern, and BlockMatrixBase classes.
+
BlockIndices represents a range of indices (such as the range of valid indices for elements of a vector) and how this one range is broken down into smaller but contiguous "blocks" (such as the velocity and pressure parts of a solution vector). In particular, it provides the ability to translate between global indices and the indices within a block. This class is used, for example, in the BlockVector, BlockSparsityPattern, and BlockMatrixBase classes.
The information that can be obtained from this class falls into two groups. First, it is possible to query the global size of the index space (through the total_size() member function), and the number of blocks and their sizes (via size() and the block_size() functions).
Secondly, this class manages the conversion of global indices to the local indices within this block, and the other way around. This is required, for example, when you address a global element in a block vector and want to know within which block this is, and which index within this block it corresponds to. It is also useful if a matrix is composed of several blocks, where you have to translate global row and column indices to local ones.
A BlockLinearOperator can be sliced to a LinearOperator at any time. This removes all information about the underlying block structure (because above std::function objects are no longer available) - the linear operator interface, however, remains intact.
-
Note
This class makes heavy use of std::function objects and lambda functions. This flexibility comes with a run-time penalty. Only use this object to encapsulate object with medium to large individual block sizes, and small block structure (as a rule of thumb, matrix blocks greater than ).
+
Note
This class makes heavy use of std::function objects and lambda functions. This flexibility comes with a run-time penalty. Only use this object to encapsulate object with medium to large individual block sizes, and small block structure (as a rule of thumb, matrix blocks greater than ).
Return a LinearOperator that performs the operations associated with the Schur complement. There are two additional helper functions, condense_schur_rhs() and postprocess_schur_solution(), that are likely necessary to be used in order to perform any useful tasks in linear algebra with this operator.
We construct the definition of the Schur complement in the following way:
Consider a general system of linear equations that can be decomposed into two major sets of equations:
-
+\end{eqnarray*}" src="form_1852.png"/>
-
where represent general subblocks of the matrix and, similarly, general subvectors of are given by .
+
where represent general subblocks of the matrix and, similarly, general subvectors of are given by .
This is equivalent to the following two statements:
-
+\end{eqnarray*}" src="form_1857.png"/>
-
Assuming that are both square and invertible, we could then perform one of two possible substitutions,
- are both square and invertible, we could then perform one of two possible substitutions,
+
+\end{eqnarray*}" src="form_1859.png"/>
which amount to performing block Gaussian elimination on this system of equations.
For the purpose of the current implementation, we choose to substitute (3) into (2)
-
+\end{eqnarray*}" src="form_1860.png"/>
This leads to the result
-
+\]" src="form_1861.png"/>
-
with being the Schur complement and the modified right-hand side vector arising from the condensation step. Note that for this choice of , submatrix need not be invertible and may thus be the null matrix. Ideally should be well-conditioned.
-
So for any arbitrary vector , the Schur complement performs the following operation:
- being the Schur complement and the modified right-hand side vector arising from the condensation step. Note that for this choice of , submatrix need not be invertible and may thus be the null matrix. Ideally should be well-conditioned.
+
So for any arbitrary vector , the Schur complement performs the following operation:
+
+\]" src="form_1868.png"/>
A typical set of steps needed the solve a linear system (1),(2) would be:
Define iterative inverse matrix such that (6) holds. It is necessary to use a solver with a preconditioner to compute the approximate inverse operation of since we never compute directly, but rather the result of its operation. To achieve this, one may again use the inverse_operator() in conjunction with the Schur complement that we've just constructed. Observe that the both and its preconditioner operate over the same space as .
Define iterative inverse matrix such that (6) holds. It is necessary to use a solver with a preconditioner to compute the approximate inverse operation of since we never compute directly, but rather the result of its operation. To achieve this, one may again use the inverse_operator() in conjunction with the Schur complement that we've just constructed. Observe that the both and its preconditioner operate over the same space as .
In the above example, the preconditioner for was defined as the preconditioner for , which is valid since they operate on the same space. However, if and are too dissimilar, then this may lead to a large number of solver iterations as is not a good approximation for .
-
A better preconditioner in such a case would be one that provides a more representative approximation for . One approach is shown in step-22, where is the null matrix and the preconditioner for is derived from the mass matrix over this space.
-
From another viewpoint, a similar result can be achieved by first constructing an object that represents an approximation for wherein expensive operation, namely , is approximated. Thereafter we construct the approximate inverse operator which is then used as the preconditioner for computing .
// Construction of approximate inverse of Schur complement
+
In the above example, the preconditioner for was defined as the preconditioner for , which is valid since they operate on the same space. However, if and are too dissimilar, then this may lead to a large number of solver iterations as is not a good approximation for .
+
A better preconditioner in such a case would be one that provides a more representative approximation for . One approach is shown in step-22, where is the null matrix and the preconditioner for is derived from the mass matrix over this space.
+
From another viewpoint, a similar result can be achieved by first constructing an object that represents an approximation for wherein expensive operation, namely , is approximated. Thereafter we construct the approximate inverse operator which is then used as the preconditioner for computing .
// Construction of approximate inverse of Schur complement
Note that due to the construction of S_inv_approx and subsequently S_inv, there are a pair of nested iterative solvers which could collectively consume a lot of resources. Therefore care should be taken in the choices leading to the construction of the iterative inverse_operators. One might consider the use of a IterationNumberControl (or a similar mechanism) to limit the number of inner solver iterations. This controls the accuracy of the approximate inverse operation which acts only as the preconditioner for . Furthermore, the preconditioner to , which in this example is , should ideally be computationally inexpensive.
+
Note that due to the construction of S_inv_approx and subsequently S_inv, there are a pair of nested iterative solvers which could collectively consume a lot of resources. Therefore care should be taken in the choices leading to the construction of the iterative inverse_operators. One might consider the use of a IterationNumberControl (or a similar mechanism) to limit the number of inner solver iterations. This controls the accuracy of the approximate inverse operation which acts only as the preconditioner for . Furthermore, the preconditioner to , which in this example is , should ideally be computationally inexpensive.
However, if an iterative solver based on IterationNumberControl is used as a preconditioner then the preconditioning operation is not a linear operation. Here a flexible solver like SolverFGMRES (flexible GMRES) is best employed as an outer solver in order to deal with the variable behavior of the preconditioner. Otherwise the iterative solver can stagnate somewhere near the tolerance of the preconditioner or generally behave erratically. Alternatively, using a ReductionControl would ensure that the preconditioner always solves to the same tolerance, thereby rendering its behavior constant.
Further examples of this functionality can be found in the test-suite, such as tests/lac/schur_complement_01.cc . The solution of a multi- component problem (namely step-22) using the schur_complement can be found in tests/lac/schur_complement_03.cc .
Return the number of blocks in a column (i.e, the number of "block rows", or the number , if interpreted as a block system).
+
Return the number of blocks in a column (i.e, the number of "block rows", or the number , if interpreted as a block system).
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classBlockMatrixBase.html differs (JavaScript source, ASCII text, with very long lines (741))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classBlockMatrixBase.html 2023-11-25 15:25:51.000071013 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classBlockMatrixBase.html 2023-11-25 15:25:51.000071013 +0100
@@ -1440,7 +1440,7 @@
-
Adding Matrix-vector multiplication. Add on with being this matrix.
+
Adding Matrix-vector multiplication. Add on with being this matrix.
@@ -1547,7 +1547,7 @@
-
Compute the matrix scalar product .
+
Compute the matrix scalar product .
@@ -1938,7 +1938,7 @@
-
Matrix-vector multiplication: let with being this matrix.
+
Matrix-vector multiplication: let with being this matrix.
Due to problems with deriving template arguments between the block and non-block versions of the vmult/Tvmult functions, the actual functions are implemented in derived classes, with implementations forwarding the calls to the implementations provided here under a unique name for which template arguments can be derived by the compiler.
@@ -2102,7 +2102,7 @@
-
Matrix-vector multiplication: let with being this matrix. This function does the same as vmult() but takes the transposed matrix.
+
Matrix-vector multiplication: let with being this matrix. This function does the same as vmult() but takes the transposed matrix.
Due to problems with deriving template arguments between the block and non-block versions of the vmult/Tvmult functions, the actual functions are implemented in derived classes, with implementations forwarding the calls to the implementations provided here under a unique name for which template arguments can be derived by the compiler.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classBlockSparseMatrix.html differs (JavaScript source, ASCII text, with very long lines (782))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classBlockSparseMatrix.html 2023-11-25 15:25:51.030070405 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classBlockSparseMatrix.html 2023-11-25 15:25:51.030070405 +0100
@@ -950,7 +950,7 @@
-
Matrix-vector multiplication: let with being this matrix.
+
Matrix-vector multiplication: let with being this matrix.
Adding Matrix-vector multiplication. Add on with being this matrix.
+
Adding Matrix-vector multiplication. Add on with being this matrix.
@@ -2453,7 +2453,7 @@
-
Compute the matrix scalar product .
+
Compute the matrix scalar product .
@@ -2948,7 +2948,7 @@
-
Matrix-vector multiplication: let with being this matrix.
+
Matrix-vector multiplication: let with being this matrix.
Due to problems with deriving template arguments between the block and non-block versions of the vmult/Tvmult functions, the actual functions are implemented in derived classes, with implementations forwarding the calls to the implementations provided here under a unique name for which template arguments can be derived by the compiler.
@@ -3096,7 +3096,7 @@
-
Matrix-vector multiplication: let with being this matrix. This function does the same as vmult() but takes the transposed matrix.
+
Matrix-vector multiplication: let with being this matrix. This function does the same as vmult() but takes the transposed matrix.
Due to problems with deriving template arguments between the block and non-block versions of the vmult/Tvmult functions, the actual functions are implemented in derived classes, with implementations forwarding the calls to the implementations provided here under a unique name for which template arguments can be derived by the compiler.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classBlockSparseMatrixEZ.html differs (JavaScript source, ASCII text, with very long lines (671))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classBlockSparseMatrixEZ.html 2023-11-25 15:25:51.050069998 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classBlockSparseMatrixEZ.html 2023-11-25 15:25:51.050069998 +0100
@@ -799,7 +799,7 @@
-
Matrix-vector multiplication: let with being this matrix.
+
Matrix-vector multiplication: let with being this matrix.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classBlockVector.html differs (JavaScript source, ASCII text, with very long lines (894))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classBlockVector.html 2023-11-25 15:25:51.076736119 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classBlockVector.html 2023-11-25 15:25:51.076736119 +0100
@@ -1848,7 +1848,7 @@
-
Return the square of the -norm.
+
Return the square of the -norm.
@@ -1900,7 +1900,7 @@
-
Return the -norm of the vector, i.e. the sum of the absolute values.
+
Return the -norm of the vector, i.e. the sum of the absolute values.
@@ -1926,7 +1926,7 @@
-
Return the -norm of the vector, i.e. the square root of the sum of the squares of the elements.
+
Return the -norm of the vector, i.e. the square root of the sum of the squares of the elements.
@@ -1952,7 +1952,7 @@
-
Return the maximum absolute value of the elements of this vector, which is the -norm of a vector.
+
Return the maximum absolute value of the elements of this vector, which is the -norm of a vector.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classBlockVectorBase.html differs (JavaScript source, ASCII text, with very long lines (910))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classBlockVectorBase.html 2023-11-25 15:25:51.103402245 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classBlockVectorBase.html 2023-11-25 15:25:51.103402245 +0100
@@ -1233,7 +1233,7 @@
-
Return the square of the -norm.
+
Return the square of the -norm.
@@ -1273,7 +1273,7 @@
-
Return the -norm of the vector, i.e. the sum of the absolute values.
+
Return the -norm of the vector, i.e. the sum of the absolute values.
@@ -1293,7 +1293,7 @@
-
Return the -norm of the vector, i.e. the square root of the sum of the squares of the elements.
+
Return the -norm of the vector, i.e. the square root of the sum of the squares of the elements.
@@ -1313,7 +1313,7 @@
-
Return the maximum absolute value of the elements of this vector, which is the -norm of a vector.
+
Return the maximum absolute value of the elements of this vector, which is the -norm of a vector.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classBoundingBox.html differs (JavaScript source, ASCII text, with very long lines (1101))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classBoundingBox.html 2023-11-25 15:25:51.120068573 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classBoundingBox.html 2023-11-25 15:25:51.120068573 +0100
@@ -165,11 +165,11 @@
&#href_anchor"details" id="details">
Detailed Description
template<int spacedim, typename Number = double>
class BoundingBox< spacedim, Number >
A class that represents a box of arbitrary dimension spacedim and with sides parallel to the coordinate axes, that is, a region
-
+\]" src="form_362.png"/>
-
where and denote the two vertices (bottom left and top right) which are used to represent the box. The quantities and denote the "lower" and "upper" bounds of values that are within the box for each coordinate direction .
+
where and denote the two vertices (bottom left and top right) which are used to represent the box. The quantities and denote the "lower" and "upper" bounds of values that are within the box for each coordinate direction .
Geometrically, a bounding box is thus:
1d: a segment (represented by its vertices in the proper order)
2d: a rectangle (represented by the vertices V at bottom left, top right)
.--------V
@@ -185,7 +185,7 @@
Bounding boxes are, for example, useful in parallel distributed meshes to give a general description of the owners of each portion of the mesh. More generally, bounding boxes are often used to roughly describe a region of space in which an object is contained; if a candidate point is not within the bounding box (a test that is cheap to execute), then it is not necessary to perform an expensive test whether the candidate point is in fact inside the object itself. Bounding boxes are therefore often used as a first, cheap rejection test before more detailed checks. As such, bounding boxes serve many of the same purposes as the convex hull, for which it is also relatively straightforward to compute whether a point is inside or outside, though not quite as cheap as for the bounding box.
-
Taking the cross section of a BoundingBox<spacedim> orthogonal to a given direction gives a box in one dimension lower: BoundingBox<spacedim - 1>. In 3d, the 2 coordinates of the cross section of BoundingBox<3> can be ordered in 2 different ways. That is, if we take the cross section orthogonal to the y direction we could either order a 3d-coordinate into a 2d-coordinate as or as . This class uses the second convention, corresponding to the coordinates being ordered cyclicly To be precise, if we take a cross section:
+
Taking the cross section of a BoundingBox<spacedim> orthogonal to a given direction gives a box in one dimension lower: BoundingBox<spacedim - 1>. In 3d, the 2 coordinates of the cross section of BoundingBox<3> can be ordered in 2 different ways. That is, if we take the cross section orthogonal to the y direction we could either order a 3d-coordinate into a 2d-coordinate as or as . This class uses the second convention, corresponding to the coordinates being ordered cyclicly To be precise, if we take a cross section:
Orthogonal to
Cross section coordinates ordered as
@@ -751,7 +751,7 @@
-
Returns the indexth vertex of the box. Vertex is meant in the same way as for a cell, so that index.
+
Returns the indexth vertex of the box. Vertex is meant in the same way as for a cell, so that index.
Return the square of the norm of the vector with respect to the norm induced by this matrix, i.e., . This is useful, e.g., in the finite context, where the norm of a function equals the matrix norm with respect to the mass matrix of the vector representing the nodal values of the finite element function.
+
Return the square of the norm of the vector with respect to the norm induced by this matrix, i.e., . This is useful, e.g., in the finite context, where the norm of a function equals the matrix norm with respect to the mass matrix of the vector representing the nodal values of the finite element function.
Obviously, the matrix needs to be quadratic for this operation.
Return the -norm of the matrix, that is , (max. sum of rows). This is the natural norm that is compatible to the -norm of vectors, i.e., -norm of the matrix, that is , (max. sum of rows). This is the natural norm that is compatible to the -norm of vectors, i.e., .
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classCellAccessor.html differs (JavaScript source, ASCII text, with very long lines (755))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classCellAccessor.html 2023-11-25 15:25:51.216733272 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classCellAccessor.html 2023-11-25 15:25:51.216733272 +0100
@@ -4164,8 +4164,8 @@
-
This function computes a fast approximate transformation from the real to the unit cell by inversion of an affine approximation of the -linear function from the reference -dimensional cell.
-
The affine approximation of the unit to real cell mapping is found by a least squares fit of an affine function to the vertices of the present object. For any valid mesh cell whose geometry is not degenerate, this operation results in a unique affine mapping. Thus, this function will return a finite result for all given input points, even in cases where the actual transformation by an actual bi-/trilinear or higher order mapping might be singular. Besides only approximating the mapping from the vertex points, this function also ignores the attached manifold descriptions. The result is only exact in case the transformation from the unit to the real cell is indeed affine, such as in one dimension or for Cartesian and affine (parallelogram) meshes in 2d/3d.
+
This function computes a fast approximate transformation from the real to the unit cell by inversion of an affine approximation of the -linear function from the reference -dimensional cell.
+
The affine approximation of the unit to real cell mapping is found by a least squares fit of an affine function to the vertices of the present object. For any valid mesh cell whose geometry is not degenerate, this operation results in a unique affine mapping. Thus, this function will return a finite result for all given input points, even in cases where the actual transformation by an actual bi-/trilinear or higher order mapping might be singular. Besides only approximating the mapping from the vertex points, this function also ignores the attached manifold descriptions. The result is only exact in case the transformation from the unit to the real cell is indeed affine, such as in one dimension or for Cartesian and affine (parallelogram) meshes in 2d/3d.
If dim<spacedim we first project p onto the plane.
@@ -4206,7 +4206,7 @@
-
Center of the object. The center of an object is defined to be the average of the locations of the vertices, which is also where a mapping would map the center of the reference cell. However, you can also ask this function to instead return the average of the vertices as computed by the underlying Manifold object associated with the current object, by setting to true the optional parameter respect_manifold. Manifolds would then typically pull back the coordinates of the vertices to a reference domain (not necessarily the reference cell), compute the average there, and then push forward the coordinates of the averaged point to the physical space again; the resulting point is guaranteed to lie within the manifold, even if the manifold is curved.
+
Center of the object. The center of an object is defined to be the average of the locations of the vertices, which is also where a mapping would map the center of the reference cell. However, you can also ask this function to instead return the average of the vertices as computed by the underlying Manifold object associated with the current object, by setting to true the optional parameter respect_manifold. Manifolds would then typically pull back the coordinates of the vertices to a reference domain (not necessarily the reference cell), compute the average there, and then push forward the coordinates of the averaged point to the physical space again; the resulting point is guaranteed to lie within the manifold, even if the manifold is curved.
When the object uses a different manifold description as its surrounding, like when part of the bounding objects of this TriaAccessor use a non-flat manifold description but the object itself is flat, the result given by the TriaAccessor::center() function may not be accurate enough, even when parameter respect_manifold is set to true. If you find this to be case, than you can further refine the computation of the center by setting to true the second additional parameter interpolate_from_surrounding. This computes the location of the center by a so-called transfinite interpolation from the center of all the bounding objects. For a 2d object, it puts a weight of 1/2 on each of the four surrounding lines and a weight -1/4 on the four vertices. This corresponds to a linear interpolation between the descriptions of the four faces, subtracting the contribution of the vertices that is added twice when coming through both lines adjacent to the vertex. In 3d, the weights for faces are 1/2, the weights for lines are -1/4, and the weights for vertices are 1/8. For further information, also confer to the TransfiniteInterpolationManifold class that is able to not only apply this beneficial description to a single cell but all children of a coarse cell.
Return the barycenter (also called centroid) of the object. The barycenter for an object of dimension in space dimensions is given by the -dimensional vector defined by
+
Return the barycenter (also called centroid) of the object. The barycenter for an object of dimension in space dimensions is given by the -dimensional vector defined by
This function assumes that is mapped by a -linear function from the reference -dimensional cell. Then the integrals above can be pulled back to the reference cell and evaluated exactly (if through lengthy and, compared to the center() function, expensive computations).
+
This function assumes that is mapped by a -linear function from the reference -dimensional cell. Then the integrals above can be pulled back to the reference cell and evaluated exactly (if through lengthy and, compared to the center() function, expensive computations).
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classChartManifold.html differs (JavaScript source, ASCII text, with very long lines (1480))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classChartManifold.html 2023-11-25 15:25:51.240066129 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classChartManifold.html 2023-11-25 15:25:51.240066129 +0100
@@ -204,37 +204,37 @@
Detailed Description
template<int dim, int spacedim = dim, int chartdim = dim>
class ChartManifold< dim, spacedim, chartdim >
This class describes mappings that can be expressed in terms of charts. Specifically, this class with its template arguments describes a chart of dimension chartdim, which is part of a Manifold<dim,spacedim> and is used in an object of type Triangulation<dim,spacedim>: It specializes a Manifold of dimension chartdim embedded in a manifold of dimension spacedim, for which you have explicit pull_back() and push_forward() transformations. Its use is explained in great detail in step-53.
-
This is a helper class which is useful when you have an explicit map from an Euclidean space of dimension chartdim to an Euclidean space of dimension spacedim which represents your manifold, i.e., when your manifold can be represented by a map
-
+
This is a helper class which is useful when you have an explicit map from an Euclidean space of dimension chartdim to an Euclidean space of dimension spacedim which represents your manifold, i.e., when your manifold can be represented by a map
+
(the push_forward() function) and that admits the inverse transformation
The get_new_point() function of the ChartManifold class is implemented by calling the pull_back() method for all surrounding_points, computing their weighted average in the chartdim Euclidean space, and calling the push_forward() method with the resulting point, i.e.,
-
+
Derived classes are required to implement the push_forward() and the pull_back() methods. All other functions (with the exception of the push_forward_gradient() function, see below) that are required by mappings will then be provided by this class.
Providing function gradients
-
In order to compute vectors that are tangent to the manifold (for example, tangent to a surface embedded in higher dimensional space, or simply the three unit vectors of ), one needs to also have access to the gradient of the push-forward function . The gradient is the matrix , where we take the derivative with regard to the chartdim reference coordinates on the flat Euclidean space in which is located. In other words, at a point , is a matrix of size spacedim times chartdim.
+
In order to compute vectors that are tangent to the manifold (for example, tangent to a surface embedded in higher dimensional space, or simply the three unit vectors of ), one needs to also have access to the gradient of the push-forward function . The gradient is the matrix , where we take the derivative with regard to the chartdim reference coordinates on the flat Euclidean space in which is located. In other words, at a point , is a matrix of size spacedim times chartdim.
Only the ChartManifold::get_tangent_vector() function uses the gradient of the push-forward, but only a subset of all finite element codes actually require the computation of tangent vectors. Consequently, while derived classes need to implement the abstract virtual push_forward() and pull_back() functions of this class, they do not need to implement the virtual push_forward_gradient() function. Rather, that function has a default implementation (and consequently is not abstract, therefore not forcing derived classes to overload it), but the default implementation clearly can not compute anything useful and therefore simply triggers and exception.
A note on the template arguments
The dimension arguments chartdim, dim and spacedim must satisfy the following relationships:
dim <= spacedim
chartdim <= spacedim
However, there is no a priori relationship between dim and chartdim. For example, if you want to describe a mapping for an edge (a 1d object) in a 2d triangulation embedded in 3d space, you could do so by parameterizing it via a line
-
+ \]" src="form_1426.png"/>
in which case chartdim is 1. On the other hand, there is no reason why one can't describe this as a mapping
-
+ \]" src="form_1427.png"/>
-
in such a way that the line happens to be mapped onto the edge in question. Here, chartdim is 3. This may seem cumbersome but satisfies the requirements of an invertible function just fine as long as it is possible to get from the edge to the pull-back space and then back again. Finally, given that we are dealing with a 2d triangulation in 3d, one will often have a mapping from, say, the 2d unit square or unit disk to the domain in 3d space, and the edge in question may simply be the mapped edge of the unit domain in 2d space. In this case, chartdim is 2.
+
in such a way that the line happens to be mapped onto the edge in question. Here, chartdim is 3. This may seem cumbersome but satisfies the requirements of an invertible function just fine as long as it is possible to get from the edge to the pull-back space and then back again. Finally, given that we are dealing with a 2d triangulation in 3d, one will often have a mapping from, say, the 2d unit square or unit disk to the domain in 3d space, and the edge in question may simply be the mapped edge of the unit domain in 2d space. In this case, chartdim is 2.
Given a point in the chartdim dimensional Euclidean space, this method returns the derivatives of the function that maps from the chartdim-dimensional to the spacedim-dimensional space. In other words, it is a matrix of size .
+
Given a point in the chartdim dimensional Euclidean space, this method returns the derivatives of the function that maps from the chartdim-dimensional to the spacedim-dimensional space. In other words, it is a matrix of size .
This function is used in the computations required by the get_tangent_vector() function. Since not all users of the Manifold class interface will require calling that function, the current function is implemented but will trigger an exception whenever called. This allows derived classes to avoid implementing the push_forward_gradient function if this functionality is not needed in the user program.
Refer to the general documentation of this class for more information.
@@ -632,24 +632,24 @@
-
Return a vector that, at , is tangential to the geodesic that connects two points . See the documentation of the Manifold class and of Manifold::get_tangent_vector() for a more detailed description.
-
For the current class, we assume that this geodesic is the image under the push_forward() operation of a straight line of the pre-images of x1 and x2 (where pre-images are computed by pulling back the locations x1 and x2). In other words, if these preimages are , then the geodesic in preimage (the chartdim-dimensional Euclidean) space is
-, is tangential to the geodesic that connects two points . See the documentation of the Manifold class and of Manifold::get_tangent_vector() for a more detailed description.
+
For the current class, we assume that this geodesic is the image under the push_forward() operation of a straight line of the pre-images of x1 and x2 (where pre-images are computed by pulling back the locations x1 and x2). In other words, if these preimages are , then the geodesic in preimage (the chartdim-dimensional Euclidean) space is
+
+\end{align*}" src="form_1440.png"/>
In image space, i.e., in the space in which we operate, this leads to the curve
-
+\end{align*}" src="form_1441.png"/>
-
What the current function is supposed to return is . By the chain rule, this is equal to
-. By the chain rule, this is equal to
+
+\end{align*}" src="form_1442.png"/>
This formula may then have to be slightly modified by considering any periodicity that was assumed in the call to the constructor.
-
Thus, the computation of tangent vectors also requires the implementation of derivatives of the push-forward mapping. Here, is a chartdim-dimensional vector, and is a spacedim-times-chartdim-dimensional matrix. Consequently, and as desired, the operation results in a spacedim-dimensional vector.
+
Thus, the computation of tangent vectors also requires the implementation of derivatives of the push-forward mapping. Here, is a chartdim-dimensional vector, and is a spacedim-times-chartdim-dimensional matrix. Consequently, and as desired, the operation results in a spacedim-dimensional vector.
Parameters
x1
The first point that describes the geodesic, and the one at which the "direction" is to be evaluated.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classChunkSparseMatrix.html differs (JavaScript source, ASCII text, with very long lines (699))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classChunkSparseMatrix.html 2023-11-25 15:25:51.263398990 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classChunkSparseMatrix.html 2023-11-25 15:25:51.263398990 +0100
@@ -1071,7 +1071,7 @@
-
Symmetrize the matrix by forming the mean value between the existing matrix and its transpose, .
+
Symmetrize the matrix by forming the mean value between the existing matrix and its transpose, .
This operation assumes that the underlying sparsity pattern represents a symmetric object. If this is not the case, then the result of this operation will not be a symmetric matrix, since it only explicitly symmetrizes by looping over the lower left triangular part for efficiency reasons; if there are entries in the upper right triangle, then these elements are missed in the symmetrization. Symmetrization of the sparsity pattern can be obtain by ChunkSparsityPattern::symmetrize().
@@ -1480,7 +1480,7 @@
-
Return the square of the norm of the vector with respect to the norm induced by this matrix, i.e. . This is useful, e.g. in the finite element context, where the norm of a function equals the matrix norm with respect to the mass matrix of the vector representing the nodal values of the finite element function.
+
Return the square of the norm of the vector with respect to the norm induced by this matrix, i.e. . This is useful, e.g. in the finite element context, where the norm of a function equals the matrix norm with respect to the mass matrix of the vector representing the nodal values of the finite element function.
Obviously, the matrix needs to be quadratic for this operation, and for the result to actually be a norm it also needs to be either real symmetric or complex hermitian.
The underlying template types of both this matrix and the given vector should either both be real or complex-valued, but not mixed, for this function to make sense.
@@ -1513,7 +1513,7 @@
-
Compute the matrix scalar product .
+
Compute the matrix scalar product .
@@ -1570,8 +1570,8 @@
-
Return the l1-norm of the matrix, that is , (max. sum of columns). This is the natural matrix norm that is compatible to the l1-norm for vectors, i.e. . (cf. Haemmerlin-Hoffmann : Numerische Mathematik)
+
Return the l1-norm of the matrix, that is , (max. sum of columns). This is the natural matrix norm that is compatible to the l1-norm for vectors, i.e. . (cf. Haemmerlin-Hoffmann : Numerische Mathematik)
@@ -1591,8 +1591,8 @@
-
Return the linfty-norm of the matrix, that is , (max. sum of rows). This is the natural matrix norm that is compatible to the linfty-norm of vectors, i.e. . (cf. Haemmerlin-Hoffmann : Numerische Mathematik)
+
Return the linfty-norm of the matrix, that is , (max. sum of rows). This is the natural matrix norm that is compatible to the linfty-norm of vectors, i.e. . (cf. Haemmerlin-Hoffmann : Numerische Mathematik)
@@ -2418,7 +2418,7 @@
-
Return the location of entry within the val array.
+
Return the location of entry within the val array.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classChunkSparsityPattern.html differs (JavaScript source, ASCII text, with very long lines (935))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classChunkSparsityPattern.html 2023-11-25 15:25:51.286731848 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classChunkSparsityPattern.html 2023-11-25 15:25:51.286731848 +0100
@@ -1233,7 +1233,7 @@
-
Compute the bandwidth of the matrix represented by this structure. The bandwidth is the maximum of for which the index pair represents a nonzero entry of the matrix. Consequently, the maximum bandwidth a matrix can have is .
+
Compute the bandwidth of the matrix represented by this structure. The bandwidth is the maximum of for which the index pair represents a nonzero entry of the matrix. Consequently, the maximum bandwidth a matrix can have is .
This class represents a mask that can be used to select individual vector components of a finite element (see also this glossary entry). It will typically have as many elements as the finite element has vector components, and one can use operator[] to query whether a particular component has been selected.
-
Note
A "mask" represents a data structure with true and false entries that is generally used to enable or disable an operation for a particular vector component. By this definition, disabled vector components still exist – they are simply not touched. As a consequence, when you apply a component mask for interpolating boundary values (to choose just one example) of a problem with vector components, the input argument that describes the boundary values will still have to provide components even if the mask says that we only want to interpolate a subset of these components onto the finite element space. In other words, a component mask does not represent a reduction operation; it represents a selection.
+
Note
A "mask" represents a data structure with true and false entries that is generally used to enable or disable an operation for a particular vector component. By this definition, disabled vector components still exist – they are simply not touched. As a consequence, when you apply a component mask for interpolating boundary values (to choose just one example) of a problem with vector components, the input argument that describes the boundary values will still have to provide components even if the mask says that we only want to interpolate a subset of these components onto the finite element space. In other words, a component mask does not represent a reduction operation; it represents a selection.
Objects of this kind are used in many places where one wants to restrict operations to a certain subset of components, e.g. in DoFTools::make_zero_boundary_values() or VectorTools::interpolate_boundary_values(). These objects can either be created by hand, or, simpler, by asking the finite element to generate a component mask from certain selected components using code such as this where we create a mask that only denotes the velocity components of a Stokes element (see Handling vector valued problems):
// Q2 element for the velocities, Q1 element for the pressure
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classCompositionManifold.html differs (JavaScript source, ASCII text, with very long lines (1066))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classCompositionManifold.html 2023-11-25 15:25:51.320064500 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classCompositionManifold.html 2023-11-25 15:25:51.320064500 +0100
@@ -631,24 +631,24 @@
-
Return a vector that, at , is tangential to the geodesic that connects two points . See the documentation of the Manifold class and of Manifold::get_tangent_vector() for a more detailed description.
-
For the current class, we assume that this geodesic is the image under the push_forward() operation of a straight line of the pre-images of x1 and x2 (where pre-images are computed by pulling back the locations x1 and x2). In other words, if these preimages are , then the geodesic in preimage (the chartdim-dimensional Euclidean) space is
-, is tangential to the geodesic that connects two points . See the documentation of the Manifold class and of Manifold::get_tangent_vector() for a more detailed description.
+
For the current class, we assume that this geodesic is the image under the push_forward() operation of a straight line of the pre-images of x1 and x2 (where pre-images are computed by pulling back the locations x1 and x2). In other words, if these preimages are , then the geodesic in preimage (the chartdim-dimensional Euclidean) space is
+
+\end{align*}" src="form_1440.png"/>
In image space, i.e., in the space in which we operate, this leads to the curve
-
+\end{align*}" src="form_1441.png"/>
-
What the current function is supposed to return is . By the chain rule, this is equal to
-. By the chain rule, this is equal to
+
+\end{align*}" src="form_1442.png"/>
This formula may then have to be slightly modified by considering any periodicity that was assumed in the call to the constructor.
-
Thus, the computation of tangent vectors also requires the implementation of derivatives of the push-forward mapping. Here, is a chartdim-dimensional vector, and is a spacedim-times-chartdim-dimensional matrix. Consequently, and as desired, the operation results in a spacedim-dimensional vector.
+
Thus, the computation of tangent vectors also requires the implementation of derivatives of the push-forward mapping. Here, is a chartdim-dimensional vector, and is a spacedim-times-chartdim-dimensional matrix. Consequently, and as desired, the operation results in a spacedim-dimensional vector.
Parameters
x1
The first point that describes the geodesic, and the one at which the "direction" is to be evaluated.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classConvergenceTable.html differs (JavaScript source, ASCII text, with very long lines (810))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classConvergenceTable.html 2023-11-25 15:25:51.336730828 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classConvergenceTable.html 2023-11-25 15:25:51.336730828 +0100
@@ -372,14 +372,14 @@
Evaluate the convergence rates of the data column data_column_key due to the RateMode in relation to the reference column reference_column_key. Be sure that the value types of the table entries of the data column and the reference data column is a number, i.e. double, float, (unsigned) int, and so on.
-
As this class has no information on the space dimension upon which the reference column vs. the value column is based upon, it needs to be passed as last argument to this method. The default dimension for the reference column is 2, which is appropriate for the number of cells in 2d. If you work in 3d, set the number to 3. If the reference column is , remember to set the dimension to 1 also when working in 3d to get correct rates.
+
As this class has no information on the space dimension upon which the reference column vs. the value column is based upon, it needs to be passed as last argument to this method. The default dimension for the reference column is 2, which is appropriate for the number of cells in 2d. If you work in 3d, set the number to 3. If the reference column is , remember to set the dimension to 1 also when working in 3d to get correct rates.
The new rate column and the data column will be merged to a supercolumn. The tex caption of the supercolumn will be (by default) the same as the one of the data column. This may be changed by using the set_tex_supercaption (...) function of the base class TableHandler.
This method behaves in the following way:
-
If RateMode is reduction_rate, then the computed output is where is the reference column (no dimension dependence!).
-
If RateMode is reduction_rate_log2, then the computed output is .
-
This is useful, for example, if we use as reference key the number of degrees of freedom or better, the number of cells. Assuming that the error is proportional to in 2d, then this method will produce the rate as a result. For general dimension, as described by the last parameter of this function, the formula needs to be .
+
If RateMode is reduction_rate, then the computed output is where is the reference column (no dimension dependence!).
+
If RateMode is reduction_rate_log2, then the computed output is .
+
This is useful, for example, if we use as reference key the number of degrees of freedom or better, the number of cells. Assuming that the error is proportional to in 2d, then this method will produce the rate as a result. For general dimension, as described by the last parameter of this function, the formula needs to be .
Note
Since this function adds columns to the table after several rows have already been filled, it switches off the auto fill mode of the TableHandler base class. If you intend to add further data with auto fill, you will have to re-enable it after calling this function.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classCylindricalManifold.html differs (JavaScript source, ASCII text, with very long lines (853))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classCylindricalManifold.html 2023-11-25 15:25:51.360063689 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classCylindricalManifold.html 2023-11-25 15:25:51.360063689 +0100
@@ -423,7 +423,7 @@
-
Compute the cylindrical coordinates for the given space point where denotes the distance from the axis, the angle between the given point and the computed normal direction, and the axial position.
+
Compute the cylindrical coordinates for the given space point where denotes the distance from the axis, the angle between the given point and the computed normal direction, and the axial position.
Compute the Cartesian coordinates for a chart point given in cylindrical coordinates , where denotes the distance from the axis, the angle between the given point and the computed normal direction, and the axial position.
+
Compute the Cartesian coordinates for a chart point given in cylindrical coordinates , where denotes the distance from the axis, the angle between the given point and the computed normal direction, and the axial position.
Compute the derivatives of the mapping from cylindrical coordinates to cartesian coordinates where denotes the distance from the axis, the angle between the given point and the computed normal direction, and the axial position.
+
Compute the derivatives of the mapping from cylindrical coordinates to cartesian coordinates where denotes the distance from the axis, the angle between the given point and the computed normal direction, and the axial position.
Given a point in the chartdim dimensional Euclidean space, this method returns the derivatives of the function that maps from the chartdim-dimensional to the spacedim-dimensional space. In other words, it is a matrix of size .
+
Given a point in the chartdim dimensional Euclidean space, this method returns the derivatives of the function that maps from the chartdim-dimensional to the spacedim-dimensional space. In other words, it is a matrix of size .
This function is used in the computations required by the get_tangent_vector() function. Since not all users of the Manifold class interface will require calling that function, the current function is implemented but will trigger an exception whenever called. This allows derived classes to avoid implementing the push_forward_gradient function if this functionality is not needed in the user program.
Refer to the general documentation of this class for more information.
@@ -725,24 +725,24 @@
-
Return a vector that, at , is tangential to the geodesic that connects two points . See the documentation of the Manifold class and of Manifold::get_tangent_vector() for a more detailed description.
-
For the current class, we assume that this geodesic is the image under the push_forward() operation of a straight line of the pre-images of x1 and x2 (where pre-images are computed by pulling back the locations x1 and x2). In other words, if these preimages are , then the geodesic in preimage (the chartdim-dimensional Euclidean) space is
-, is tangential to the geodesic that connects two points . See the documentation of the Manifold class and of Manifold::get_tangent_vector() for a more detailed description.
+
For the current class, we assume that this geodesic is the image under the push_forward() operation of a straight line of the pre-images of x1 and x2 (where pre-images are computed by pulling back the locations x1 and x2). In other words, if these preimages are , then the geodesic in preimage (the chartdim-dimensional Euclidean) space is
+
+\end{align*}" src="form_1440.png"/>
In image space, i.e., in the space in which we operate, this leads to the curve
-
+\end{align*}" src="form_1441.png"/>
-
What the current function is supposed to return is . By the chain rule, this is equal to
-. By the chain rule, this is equal to
+
+\end{align*}" src="form_1442.png"/>
This formula may then have to be slightly modified by considering any periodicity that was assumed in the call to the constructor.
-
Thus, the computation of tangent vectors also requires the implementation of derivatives of the push-forward mapping. Here, is a chartdim-dimensional vector, and is a spacedim-times-chartdim-dimensional matrix. Consequently, and as desired, the operation results in a spacedim-dimensional vector.
+
Thus, the computation of tangent vectors also requires the implementation of derivatives of the push-forward mapping. Here, is a chartdim-dimensional vector, and is a spacedim-times-chartdim-dimensional matrix. Consequently, and as desired, the operation results in a spacedim-dimensional vector.
Parameters
x1
The first point that describes the geodesic, and the one at which the "direction" is to be evaluated.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classDataPostprocessor.html differs (JavaScript source, ASCII text, with very long lines (1573))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classDataPostprocessor.html 2023-11-25 15:25:51.376730014 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classDataPostprocessor.html 2023-11-25 15:25:51.376730014 +0100
@@ -182,7 +182,7 @@
As a consequence, DataOut is forced to take things apart into their real and imaginary parts, and both are output as separate quantities. This is the case for data that is written directly to a file by DataOut, but it is also the case for data that is first routed through DataPostprocessor objects (or objects of their derived classes): All these objects see is a collection of real values, even if the underlying solution vector was complex-valued.
Implementations of the DataPostprocessor::evaluate_vector_field() in derived classes must understand how the solution values are arranged in the DataPostprocessorInputs::Vector objects they receive as input. The rule here is: If the finite element has vector components (including the case , i.e., a scalar element), then the inputs for complex-valued solution vectors will have components. These first contain the values (or gradients, or Hessians) of the real parts of all solution components, and then the values (or gradients, or Hessians) of the imaginary parts of all solution components.
+
Implementations of the DataPostprocessor::evaluate_vector_field() in derived classes must understand how the solution values are arranged in the DataPostprocessorInputs::Vector objects they receive as input. The rule here is: If the finite element has vector components (including the case , i.e., a scalar element), then the inputs for complex-valued solution vectors will have components. These first contain the values (or gradients, or Hessians) of the real parts of all solution components, and then the values (or gradients, or Hessians) of the imaginary parts of all solution components.
step-58 provides an example of how this class (or, rather, the derived DataPostprocessorScalar class) is used in a complex-valued situation.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classDataPostprocessorTensor.html differs (JavaScript source, ASCII text, with very long lines (1315))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classDataPostprocessorTensor.html 2023-11-25 15:25:51.393396343 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classDataPostprocessorTensor.html 2023-11-25 15:25:51.393396343 +0100
@@ -254,7 +254,7 @@
These pictures show an ellipse representing the gradient tensor at, on average, every tenth mesh point. You may want to read through the documentation of the VisIt visualization program (see https://wci.llnl.gov/simulation/computer-codes/visit/) for an interpretation of how exactly tensors are visualizated.
-
In elasticity, one is often interested not in the gradient of the displacement, but in the "strain", i.e., the symmetrized version of the gradient . This is easily facilitated with the following minor modification:
template <int dim>
+
In elasticity, one is often interested not in the gradient of the displacement, but in the "strain", i.e., the symmetrized version of the gradient . This is easily facilitated with the following minor modification:
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classDataPostprocessorVector.html differs (JavaScript source, ASCII text, with very long lines (1411))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classDataPostprocessorVector.html 2023-11-25 15:25:51.410062671 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classDataPostprocessorVector.html 2023-11-25 15:25:51.410062671 +0100
@@ -245,7 +245,7 @@
In the second image, the background color corresponds to the magnitude of the gradient vector and the vector glyphs to the gradient itself. It may be surprising at first to see that from each vertex, multiple vectors originate, going in different directions. But that is because the solution is only continuous: in general, the gradient is discontinuous across edges, and so the multiple vectors originating from each vertex simply represent the differing gradients of the solution at each adjacent cell.
-
The output above – namely, the gradient of the solution – corresponds to the temperature gradient if one interpreted step-6 as solving a steady-state heat transfer problem. It is very small in the central part of the domain because in step-6 we are solving an equation that has a coefficient that is large in the central part and small on the outside. This can be thought as a material that conducts heat well, and consequently the temperature gradient is small. On the other hand, the "heat flux" corresponds to the quantity . For the solution of that equation, the flux should be continuous across the interface. This is easily verified by the following modification of the postprocessor:
template <int dim>
+
The output above – namely, the gradient of the solution – corresponds to the temperature gradient if one interpreted step-6 as solving a steady-state heat transfer problem. It is very small in the central part of the domain because in step-6 we are solving an equation that has a coefficient that is large in the central part and small on the outside. This can be thought as a material that conducts heat well, and consequently the temperature gradient is small. On the other hand, the "heat flux" corresponds to the quantity . For the solution of that equation, the flux should be continuous across the interface. This is easily verified by the following modification of the postprocessor:
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classDerivativeApproximation_1_1internal_1_1SecondDerivative.html differs (JavaScript source, ASCII text, with very long lines (634))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classDerivativeApproximation_1_1internal_1_1SecondDerivative.html 2023-11-25 15:25:51.426728996 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classDerivativeApproximation_1_1internal_1_1SecondDerivative.html 2023-11-25 15:25:51.426728996 +0100
@@ -244,7 +244,7 @@
-
Return the norm of the derivative object. Here, for the (symmetric) tensor of second derivatives, we choose the absolute value of the largest eigenvalue, which is the matrix norm associated to the norm of vectors. It is also the largest value of the curvature of the solution.
+
Return the norm of the derivative object. Here, for the (symmetric) tensor of second derivatives, we choose the absolute value of the largest eigenvalue, which is the matrix norm associated to the norm of vectors. It is also the largest value of the curvature of the solution.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classDerivativeApproximation_1_1internal_1_1ThirdDerivative.html differs (JavaScript source, ASCII text, with very long lines (632))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classDerivativeApproximation_1_1internal_1_1ThirdDerivative.html 2023-11-25 15:25:51.440062061 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classDerivativeApproximation_1_1internal_1_1ThirdDerivative.html 2023-11-25 15:25:51.440062061 +0100
@@ -239,7 +239,7 @@
-
Return the norm of the derivative object. Here, for the (symmetric) tensor of second derivatives, we choose the absolute value of the largest eigenvalue, which is the matrix norm associated to the norm of vectors. It is also the largest value of the curvature of the solution.
+
Return the norm of the derivative object. Here, for the (symmetric) tensor of second derivatives, we choose the absolute value of the largest eigenvalue, which is the matrix norm associated to the norm of vectors. It is also the largest value of the curvature of the solution.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classDerivativeForm.html differs (JavaScript source, ASCII text, with very long lines (1196))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classDerivativeForm.html 2023-11-25 15:25:51.456728389 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classDerivativeForm.html 2023-11-25 15:25:51.456728389 +0100
@@ -163,24 +163,24 @@
DerivativeForm< 1, spacedim, dim, Number >&#href_anchor"memTemplItemRight" valign="bottom">transpose (const DerivativeForm< 1, dim, spacedim, Number > &DF)
&#href_anchor"details" id="details">
Detailed Description
template<int order, int dim, int spacedim, typename Number = double>
-class DerivativeForm< order, dim, spacedim, Number >
This class represents the (tangential) derivatives of a function . Such functions are always used to map the reference dim-dimensional cell into spacedim-dimensional space. For such objects, the first derivative of the function is a linear map from to , i.e., it can be represented as a matrix in . This makes sense since one would represent the first derivative, with . Such functions are always used to map the reference dim-dimensional cell into spacedim-dimensional space. For such objects, the first derivative of the function is a linear map from to , i.e., it can be represented as a matrix in . This makes sense since one would represent the first derivative, with , in such a way that the directional derivative in direction so that
-, in such a way that the directional derivative in direction so that
+
+\end{align*}" src="form_387.png"/>
-
i.e., one needs to be able to multiply the matrix by a vector in , and the result is a difference of function values, which are in . Consequently, the matrix must be of size .
-
Similarly, the second derivative is a bilinear map from to , which one can think of a rank-3 object of size .
+
i.e., one needs to be able to multiply the matrix by a vector in , and the result is a difference of function values, which are in . Consequently, the matrix must be of size .
+
Similarly, the second derivative is a bilinear map from to , which one can think of a rank-3 object of size .
In deal.II we represent these derivatives using objects of type DerivativeForm<1,dim,spacedim,Number>, DerivativeForm<2,dim,spacedim,Number> and so on.
Converts a DerivativeForm <order, dim, dim, Number> to Tensor<order+1, dim, Number>. In particular, if order == 1 and the derivative is the Jacobian of , then Tensor[i] = .
+
Converts a DerivativeForm <order, dim, dim, Number> to Tensor<order+1, dim, Number>. In particular, if order == 1 and the derivative is the Jacobian of , then Tensor[i] = .
@@ -473,7 +473,7 @@
-
Compute the volume element associated with the jacobian of the transformation . That is to say if is square, it computes , in case DF is not square returns .
+
Compute the volume element associated with the jacobian of the transformation . That is to say if is square, it computes , in case DF is not square returns .
@@ -493,7 +493,7 @@
-
Assuming that the current object stores the Jacobian of a mapping , then the current function computes the covariant form of the derivative, namely , where . If , then the current function computes the covariant form of the derivative, namely , where . If is a square matrix (i.e., ), then this function simplifies to computing .
@@ -589,21 +589,21 @@
-
One of the uses of DerivativeForm is to apply it as a linear transformation. This function returns , which approximates the change in when is changed by the amount
-DerivativeForm is to apply it as a linear transformation. This function returns , which approximates the change in when is changed by the amount
+
+\]" src="form_396.png"/>
The transformation corresponds to
-
+\]" src="form_397.png"/>
-
in index notation and corresponds to in matrix notation.
+
in index notation and corresponds to in matrix notation.
Similar to the previous apply_transformation(). Each row of the result corresponds to one of the rows of D_X transformed by grad_F, equivalent to in matrix notation.
+
Similar to the previous apply_transformation(). Each row of the result corresponds to one of the rows of D_X transformed by grad_F, equivalent to in matrix notation.
Similar to the previous apply_transformation(), specialized for the case dim == spacedim where we can return a rank-2 tensor instead of the more general DerivativeForm. Each row of the result corresponds to one of the rows of D_X transformed by grad_F, equivalent to in matrix notation.
+
Similar to the previous apply_transformation(), specialized for the case dim == spacedim where we can return a rank-2 tensor instead of the more general DerivativeForm. Each row of the result corresponds to one of the rows of D_X transformed by grad_F, equivalent to in matrix notation.
Similar to the previous apply_transformation(). In matrix notation, it computes . Moreover, the result of this operation can be interpreted as a metric tensor in which corresponds to the Euclidean metric tensor in . For every pair of vectors , we have:
-apply_transformation(). In matrix notation, it computes . Moreover, the result of this operation can be interpreted as a metric tensor in which corresponds to the Euclidean metric tensor in . For every pair of vectors , we have:
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classDifferentiation_1_1AD_1_1CellLevelBase.html differs (JavaScript source, ASCII text, with very long lines (1216))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classDifferentiation_1_1AD_1_1CellLevelBase.html 2023-11-25 15:25:51.476727982 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classDifferentiation_1_1AD_1_1CellLevelBase.html 2023-11-25 15:25:51.476727982 +0100
@@ -295,8 +295,8 @@
The constructor for the class.
Parameters
-
[in]
n_independent_variables
The number of independent variables that will be used in the definition of the functions that it is desired to compute the sensitivities of. In the computation of , this will be the number of inputs , i.e., the dimension of the domain space.
-
[in]
n_dependent_variables
The number of scalar functions to be defined that will have a sensitivity to the given independent variables. In the computation of , this will be the number of outputs , i.e., the dimension of the image space.
+
[in]
n_independent_variables
The number of independent variables that will be used in the definition of the functions that it is desired to compute the sensitivities of. In the computation of , this will be the number of inputs , i.e., the dimension of the domain space.
+
[in]
n_dependent_variables
The number of scalar functions to be defined that will have a sensitivity to the given independent variables. In the computation of , this will be the number of outputs , i.e., the dimension of the image space.
@@ -525,7 +525,7 @@
-
Compute the value of the residual vector field .
+
Compute the value of the residual vector field .
Parameters
[out]
residual
A Vector object with the value for each component of the vector field evaluated at the point defined by the independent variable values.
@@ -564,9 +564,9 @@
Compute the gradient (first derivative) of the residual vector field with respect to all independent variables, i.e.
-
+\]" src="form_904.png"/>
Parameters
@@ -839,8 +839,8 @@
In the rare case that the number of independent or dependent variables has changed, this can also reconfigured by passing in the appropriate arguments to the function.
Parameters
-
[in]
n_independent_variables
The number of independent variables that will be used in the definition of the functions that it is desired to compute the sensitivities of. In the computation of , this will be the number of inputs , i.e., the dimension of the domain space.
-
[in]
n_dependent_variables
The number of scalar functions to be defined that will have a sensitivity to the given independent variables. In the computation of , this will be the number of outputs , i.e., the dimension of the image space.
+
[in]
n_independent_variables
The number of independent variables that will be used in the definition of the functions that it is desired to compute the sensitivities of. In the computation of , this will be the number of inputs , i.e., the dimension of the domain space.
+
[in]
n_dependent_variables
The number of scalar functions to be defined that will have a sensitivity to the given independent variables. In the computation of , this will be the number of outputs , i.e., the dimension of the image space.
[in]
clear_registered_tapes
A flag that indicates the that list of registered_tapes must be cleared. If set to true then the data structure that tracks which tapes have been recorded is cleared as well. It is then expected that any preexisting tapes be re-recorded.
@@ -1349,7 +1349,7 @@
-
Set the actual value of the independent variable .
+
Set the actual value of the independent variable .
Parameters
[in]
index
The index in the vector of independent variables.
@@ -1396,7 +1396,7 @@
-
Initialize an independent variable such that subsequent operations performed with it are tracked.
+
Initialize an independent variable such that subsequent operations performed with it are tracked.
Note
Care must be taken to mark each independent variable only once.
The order in which the independent variables are marked defines the order of all future internal operations. They must be manipulated in the same order as that in which they are first marked. If not then, for example, ADOL-C won't throw an error, but rather it might complain nonsensically during later computations or produce garbage results.
@@ -1474,7 +1474,7 @@
-
Initialize an independent variable .
+
Initialize an independent variable .
Parameters
[out]
out
An auto-differentiable number that is ready for use in standard computations. The operations that are performed with it are not recorded on the tape, and so should only be used when not in recording mode.
@@ -1605,7 +1605,7 @@
-
Register the definition of the index'th dependent variable .
+
Register the definition of the index'th dependent variable .
Parameters
[in]
index
The index of the entry in the global list of dependent variables that this function belongs to.
@@ -1807,7 +1807,7 @@
-
The set of dependent variables of which the derivatives with respect to will be computed.
+
The set of dependent variables of which the derivatives with respect to will be computed.
The gradients and Hessians of these dependent variables will be computed at the values set with the set_sensitivity_value() function.
Note
These are stored as an ad_type so that we can use them to compute function values and directional derivatives in the case that tapeless numbers are used
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classDifferentiation_1_1AD_1_1EnergyFunctional.html differs (JavaScript source, ASCII text, with very long lines (1228))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classDifferentiation_1_1AD_1_1EnergyFunctional.html 2023-11-25 15:25:51.503394103 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classDifferentiation_1_1AD_1_1EnergyFunctional.html 2023-11-25 15:25:51.503394103 +0100
@@ -430,11 +430,11 @@
The constructor for the class.
Parameters
-
[in]
n_independent_variables
The number of independent variables that will be used in the definition of the functions that it is desired to compute the sensitivities of. In the computation of , this will be the number of inputs , i.e., the dimension of the domain space.
+
[in]
n_independent_variables
The number of independent variables that will be used in the definition of the functions that it is desired to compute the sensitivities of. In the computation of , this will be the number of inputs , i.e., the dimension of the domain space.
-
Note
There is only one dependent variable associated with the total energy attributed to the local finite element. That is to say, this class assumes that the (local) right hand side and matrix contribution is computed from the first and second derivatives of a scalar function .
+
Note
There is only one dependent variable associated with the total energy attributed to the local finite element. That is to say, this class assumes that the (local) right hand side and matrix contribution is computed from the first and second derivatives of a scalar function .
Register the definition of the total cell energy .
+
Register the definition of the total cell energy .
Parameters
[in]
energy
A recorded function that defines the total cell energy. This represents the single dependent variable from which both the residual and its linearization are to be computed.
@@ -515,9 +515,9 @@
Evaluation of the total scalar energy functional for a chosen set of degree of freedom values, i.e.
The value of the energy functional at the evaluation point corresponding to a chosen set of local degree of freedom values.
@@ -551,12 +551,12 @@
-
Evaluation of the residual for a chosen set of degree of freedom values. Underlying this is the computation of the gradient (first derivative) of the scalar function with respect to all independent variables, i.e.
Compute the linearization of the residual vector around a chosen set of degree of freedom values. Underlying this is the computation of the Hessian (second derivative) of the scalar function with respect to all independent variables, i.e.
In the rare case that the number of independent or dependent variables has changed, this can also reconfigured by passing in the appropriate arguments to the function.
Parameters
-
[in]
n_independent_variables
The number of independent variables that will be used in the definition of the functions that it is desired to compute the sensitivities of. In the computation of , this will be the number of inputs , i.e., the dimension of the domain space.
-
[in]
n_dependent_variables
The number of scalar functions to be defined that will have a sensitivity to the given independent variables. In the computation of , this will be the number of outputs , i.e., the dimension of the image space.
+
[in]
n_independent_variables
The number of independent variables that will be used in the definition of the functions that it is desired to compute the sensitivities of. In the computation of , this will be the number of inputs , i.e., the dimension of the domain space.
+
[in]
n_dependent_variables
The number of scalar functions to be defined that will have a sensitivity to the given independent variables. In the computation of , this will be the number of outputs , i.e., the dimension of the image space.
[in]
clear_registered_tapes
A flag that indicates the that list of registered_tapes must be cleared. If set to true then the data structure that tracks which tapes have been recorded is cleared as well. It is then expected that any preexisting tapes be re-recorded.
@@ -1594,7 +1594,7 @@
-
Set the actual value of the independent variable .
+
Set the actual value of the independent variable .
Parameters
[in]
index
The index in the vector of independent variables.
@@ -1641,7 +1641,7 @@
-
Initialize an independent variable such that subsequent operations performed with it are tracked.
+
Initialize an independent variable such that subsequent operations performed with it are tracked.
Note
Care must be taken to mark each independent variable only once.
The order in which the independent variables are marked defines the order of all future internal operations. They must be manipulated in the same order as that in which they are first marked. If not then, for example, ADOL-C won't throw an error, but rather it might complain nonsensically during later computations or produce garbage results.
@@ -1719,7 +1719,7 @@
-
Initialize an independent variable .
+
Initialize an independent variable .
Parameters
[out]
out
An auto-differentiable number that is ready for use in standard computations. The operations that are performed with it are not recorded on the tape, and so should only be used when not in recording mode.
@@ -1850,7 +1850,7 @@
-
Register the definition of the index'th dependent variable .
+
Register the definition of the index'th dependent variable .
Parameters
[in]
index
The index of the entry in the global list of dependent variables that this function belongs to.
@@ -2052,7 +2052,7 @@
-
The set of dependent variables of which the derivatives with respect to will be computed.
+
The set of dependent variables of which the derivatives with respect to will be computed.
The gradients and Hessians of these dependent variables will be computed at the values set with the set_sensitivity_value() function.
Note
These are stored as an ad_type so that we can use them to compute function values and directional derivatives in the case that tapeless numbers are used
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classDifferentiation_1_1AD_1_1HelperBase.html differs (JavaScript source, ASCII text, with very long lines (1204))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classDifferentiation_1_1AD_1_1HelperBase.html 2023-11-25 15:25:51.526726964 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classDifferentiation_1_1AD_1_1HelperBase.html 2023-11-25 15:25:51.526726964 +0100
@@ -195,7 +195,7 @@
A base helper class that facilitates the evaluation of the derivative(s) of a number of user-defined dependent variables with respect to a set of independent variables , that is .
A base helper class that facilitates the evaluation of the derivative(s) of a number of user-defined dependent variables with respect to a set of independent variables , that is .
This class is templated on the floating point type scalar_type of the number that we'd like to differentiate, as well as an enumeration indicating the ADNumberTypeCode . The ADNumberTypeCode dictates which auto-differentiation library is to be used, and what the nature of the underlying auto-differentiable number is. Refer to the Automatic and symbolic differentiation module for more details in this regard.
For all of the classes derived from this base class, there are two possible ways that the code in which they are used can be structured. The one approach is effectively a subset of the other, and which might be necessary to use depends on the nature of the chosen auto-differentiable number.
When "tapeless" numbers are employed, the most simple code structure would be of the following form:
@@ -345,8 +345,8 @@
The constructor for the class.
Parameters
-
[in]
n_independent_variables
The number of independent variables that will be used in the definition of the functions that it is desired to compute the sensitivities of. In the computation of , this will be the number of inputs , i.e., the dimension of the domain space.
-
[in]
n_dependent_variables
The number of scalar functions to be defined that will have a sensitivity to the given independent variables. In the computation of , this will be the number of outputs , i.e., the dimension of the image space.
+
[in]
n_independent_variables
The number of independent variables that will be used in the definition of the functions that it is desired to compute the sensitivities of. In the computation of , this will be the number of inputs , i.e., the dimension of the domain space.
+
[in]
n_dependent_variables
The number of scalar functions to be defined that will have a sensitivity to the given independent variables. In the computation of , this will be the number of outputs , i.e., the dimension of the image space.
@@ -603,8 +603,8 @@
In the rare case that the number of independent or dependent variables has changed, this can also reconfigured by passing in the appropriate arguments to the function.
Parameters
-
[in]
n_independent_variables
The number of independent variables that will be used in the definition of the functions that it is desired to compute the sensitivities of. In the computation of , this will be the number of inputs , i.e., the dimension of the domain space.
-
[in]
n_dependent_variables
The number of scalar functions to be defined that will have a sensitivity to the given independent variables. In the computation of , this will be the number of outputs , i.e., the dimension of the image space.
+
[in]
n_independent_variables
The number of independent variables that will be used in the definition of the functions that it is desired to compute the sensitivities of. In the computation of , this will be the number of inputs , i.e., the dimension of the domain space.
+
[in]
n_dependent_variables
The number of scalar functions to be defined that will have a sensitivity to the given independent variables. In the computation of , this will be the number of outputs , i.e., the dimension of the image space.
[in]
clear_registered_tapes
A flag that indicates the that list of registered_tapes must be cleared. If set to true then the data structure that tracks which tapes have been recorded is cleared as well. It is then expected that any preexisting tapes be re-recorded.
@@ -1033,7 +1033,7 @@
-
Set the actual value of the independent variable .
+
Set the actual value of the independent variable .
Parameters
[in]
index
The index in the vector of independent variables.
@@ -1080,7 +1080,7 @@
-
Initialize an independent variable such that subsequent operations performed with it are tracked.
+
Initialize an independent variable such that subsequent operations performed with it are tracked.
Note
Care must be taken to mark each independent variable only once.
The order in which the independent variables are marked defines the order of all future internal operations. They must be manipulated in the same order as that in which they are first marked. If not then, for example, ADOL-C won't throw an error, but rather it might complain nonsensically during later computations or produce garbage results.
@@ -1158,7 +1158,7 @@
-
Initialize an independent variable .
+
Initialize an independent variable .
Parameters
[out]
out
An auto-differentiable number that is ready for use in standard computations. The operations that are performed with it are not recorded on the tape, and so should only be used when not in recording mode.
@@ -1289,7 +1289,7 @@
-
Register the definition of the index'th dependent variable .
+
Register the definition of the index'th dependent variable .
Parameters
[in]
index
The index of the entry in the global list of dependent variables that this function belongs to.
@@ -1491,7 +1491,7 @@
-
The set of dependent variables of which the derivatives with respect to will be computed.
+
The set of dependent variables of which the derivatives with respect to will be computed.
The gradients and Hessians of these dependent variables will be computed at the values set with the set_sensitivity_value() function.
Note
These are stored as an ad_type so that we can use them to compute function values and directional derivatives in the case that tapeless numbers are used
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classDifferentiation_1_1AD_1_1PointLevelFunctionsBase.html differs (JavaScript source, ASCII text, with very long lines (1256))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classDifferentiation_1_1AD_1_1PointLevelFunctionsBase.html 2023-11-25 15:25:51.550059820 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classDifferentiation_1_1AD_1_1PointLevelFunctionsBase.html 2023-11-25 15:25:51.550059820 +0100
@@ -299,8 +299,8 @@
The constructor for the class.
Parameters
-
[in]
n_independent_variables
The number of independent variables that will be used in the definition of the functions that it is desired to compute the sensitivities of. In the computation of , this will be the number of inputs , i.e., the dimension of the domain space.
-
[in]
n_dependent_variables
The number of scalar functions to be defined that will have a sensitivity to the given independent variables. In the computation of , this will be the number of outputs , i.e., the dimension of the image space.
+
[in]
n_independent_variables
The number of independent variables that will be used in the definition of the functions that it is desired to compute the sensitivities of. In the computation of , this will be the number of inputs , i.e., the dimension of the domain space.
+
[in]
n_dependent_variables
The number of scalar functions to be defined that will have a sensitivity to the given independent variables. In the computation of , this will be the number of outputs , i.e., the dimension of the image space.
@@ -381,8 +381,8 @@
In the rare case that the number of independent or dependent variables has changed, this can also be reconfigured by passing in the appropriate arguments to the function.
Parameters
-
[in]
n_independent_variables
The number of independent variables that will be used in the definition of the functions that it is desired to compute the sensitivities of. In the computation of , this will be the number of inputs , i.e., the dimension of the domain space.
-
[in]
n_dependent_variables
The number of scalar functions to be defined that will have a sensitivity to the given independent variables. In the computation of , this will be the number of outputs , i.e., the dimension of the image space.
+
[in]
n_independent_variables
The number of independent variables that will be used in the definition of the functions that it is desired to compute the sensitivities of. In the computation of , this will be the number of inputs , i.e., the dimension of the domain space.
+
[in]
n_dependent_variables
The number of scalar functions to be defined that will have a sensitivity to the given independent variables. In the computation of , this will be the number of outputs , i.e., the dimension of the image space.
[in]
clear_registered_tapes
A flag that indicates the that list of registered_tapes must be cleared. If set to true then the data structure that tracks which tapes have been recorded is cleared as well. It is then expected that any preexisting tapes be re-recorded.
@@ -455,7 +455,7 @@
-
Register the subset of independent variables .
+
Register the subset of independent variables .
Parameters
[in]
value
A field that defines a number of independent variables. When considering taped AD numbers with branching functions, to avoid potential issues with branch switching it may be a good idea to choose these values close or equal to those that will be later evaluated and differentiated around.
@@ -576,7 +576,7 @@
-
Set the values for a subset of independent variables .
+
Set the values for a subset of independent variables .
Parameters
[in]
value
A field that defines the values of a number of independent variables.
@@ -631,7 +631,7 @@
-
Set the actual value of the independent variable .
+
Set the actual value of the independent variable .
Parameters
[in]
index
The index in the vector of independent variables.
@@ -1414,7 +1414,7 @@
-
Set the actual value of the independent variable .
+
Set the actual value of the independent variable .
Parameters
[in]
index
The index in the vector of independent variables.
@@ -1461,7 +1461,7 @@
-
Initialize an independent variable such that subsequent operations performed with it are tracked.
+
Initialize an independent variable such that subsequent operations performed with it are tracked.
Note
Care must be taken to mark each independent variable only once.
The order in which the independent variables are marked defines the order of all future internal operations. They must be manipulated in the same order as that in which they are first marked. If not then, for example, ADOL-C won't throw an error, but rather it might complain nonsensically during later computations or produce garbage results.
@@ -1539,7 +1539,7 @@
-
Initialize an independent variable .
+
Initialize an independent variable .
Parameters
[out]
out
An auto-differentiable number that is ready for use in standard computations. The operations that are performed with it are not recorded on the tape, and so should only be used when not in recording mode.
@@ -1670,7 +1670,7 @@
-
Register the definition of the index'th dependent variable .
+
Register the definition of the index'th dependent variable .
Parameters
[in]
index
The index of the entry in the global list of dependent variables that this function belongs to.
@@ -1926,7 +1926,7 @@
-
The set of dependent variables of which the derivatives with respect to will be computed.
+
The set of dependent variables of which the derivatives with respect to will be computed.
The gradients and Hessians of these dependent variables will be computed at the values set with the set_sensitivity_value() function.
Note
These are stored as an ad_type so that we can use them to compute function values and directional derivatives in the case that tapeless numbers are used
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classDifferentiation_1_1AD_1_1ResidualLinearization.html differs (JavaScript source, ASCII text, with very long lines (1248))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classDifferentiation_1_1AD_1_1ResidualLinearization.html 2023-11-25 15:25:51.576725946 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classDifferentiation_1_1AD_1_1ResidualLinearization.html 2023-11-25 15:25:51.576725946 +0100
@@ -452,8 +452,8 @@
The constructor for the class.
Parameters
-
[in]
n_independent_variables
The number of independent variables that will be used in the definition of the functions that it is desired to compute the sensitivities of. In the computation of , this will be the number of inputs , i.e., the dimension of the domain space.
-
[in]
n_dependent_variables
The number of scalar functions to be defined that will have a sensitivity to the given independent variables. In the computation of , this will be the number of outputs , i.e., the dimension of the image space.
+
[in]
n_independent_variables
The number of independent variables that will be used in the definition of the functions that it is desired to compute the sensitivities of. In the computation of , this will be the number of inputs , i.e., the dimension of the domain space.
+
[in]
n_dependent_variables
The number of scalar functions to be defined that will have a sensitivity to the given independent variables. In the computation of , this will be the number of outputs , i.e., the dimension of the image space.
@@ -508,7 +508,7 @@
-
Register the definition of the cell residual vector .
+
Register the definition of the cell residual vector .
Parameters
[in]
residual
A vector of recorded functions that defines the residual. The components of this vector represents the dependent variables.
@@ -549,9 +549,9 @@
Evaluation of the residual for a chosen set of degree of freedom values. This corresponds to the computation of the residual vector, i.e.
Compute the linearization of the residual vector around a chosen set of degree of freedom values. Underlying this is the computation of the gradient (first derivative) of the residual vector with respect to all independent variables, i.e.
In the rare case that the number of independent or dependent variables has changed, this can also reconfigured by passing in the appropriate arguments to the function.
Parameters
-
[in]
n_independent_variables
The number of independent variables that will be used in the definition of the functions that it is desired to compute the sensitivities of. In the computation of , this will be the number of inputs , i.e., the dimension of the domain space.
-
[in]
n_dependent_variables
The number of scalar functions to be defined that will have a sensitivity to the given independent variables. In the computation of , this will be the number of outputs , i.e., the dimension of the image space.
+
[in]
n_independent_variables
The number of independent variables that will be used in the definition of the functions that it is desired to compute the sensitivities of. In the computation of , this will be the number of inputs , i.e., the dimension of the domain space.
+
[in]
n_dependent_variables
The number of scalar functions to be defined that will have a sensitivity to the given independent variables. In the computation of , this will be the number of outputs , i.e., the dimension of the image space.
[in]
clear_registered_tapes
A flag that indicates the that list of registered_tapes must be cleared. If set to true then the data structure that tracks which tapes have been recorded is cleared as well. It is then expected that any preexisting tapes be re-recorded.
@@ -1586,7 +1586,7 @@
-
Set the actual value of the independent variable .
+
Set the actual value of the independent variable .
Parameters
[in]
index
The index in the vector of independent variables.
@@ -1633,7 +1633,7 @@
-
Initialize an independent variable such that subsequent operations performed with it are tracked.
+
Initialize an independent variable such that subsequent operations performed with it are tracked.
Note
Care must be taken to mark each independent variable only once.
The order in which the independent variables are marked defines the order of all future internal operations. They must be manipulated in the same order as that in which they are first marked. If not then, for example, ADOL-C won't throw an error, but rather it might complain nonsensically during later computations or produce garbage results.
@@ -1711,7 +1711,7 @@
-
Initialize an independent variable .
+
Initialize an independent variable .
Parameters
[out]
out
An auto-differentiable number that is ready for use in standard computations. The operations that are performed with it are not recorded on the tape, and so should only be used when not in recording mode.
@@ -1842,7 +1842,7 @@
-
Register the definition of the index'th dependent variable .
+
Register the definition of the index'th dependent variable .
Parameters
[in]
index
The index of the entry in the global list of dependent variables that this function belongs to.
@@ -2044,7 +2044,7 @@
-
The set of dependent variables of which the derivatives with respect to will be computed.
+
The set of dependent variables of which the derivatives with respect to will be computed.
The gradients and Hessians of these dependent variables will be computed at the values set with the set_sensitivity_value() function.
Note
These are stored as an ad_type so that we can use them to compute function values and directional derivatives in the case that tapeless numbers are used
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classDifferentiation_1_1AD_1_1ScalarFunction.html differs (JavaScript source, ASCII text, with very long lines (1220))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classDifferentiation_1_1AD_1_1ScalarFunction.html 2023-11-25 15:25:51.603392070 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classDifferentiation_1_1AD_1_1ScalarFunction.html 2023-11-25 15:25:51.603392070 +0100
@@ -457,7 +457,7 @@
The constructor for the class.
Parameters
-
[in]
n_independent_variables
The number of independent variables that will be used in the definition of the functions that it is desired to compute the sensitivities of. In the computation of , this will be the number of inputs , i.e., the dimension of the domain space.
+
[in]
n_independent_variables
The number of independent variables that will be used in the definition of the functions that it is desired to compute the sensitivities of. In the computation of , this will be the number of inputs , i.e., the dimension of the domain space.
@@ -512,7 +512,7 @@
-
Register the definition of the scalar field .
+
Register the definition of the scalar field .
Parameters
[in]
func
The recorded function that defines a dependent variable.
@@ -540,7 +540,7 @@
-
Compute the value of the scalar field using the tape as opposed to executing the source code.
+
Compute the value of the scalar field using the tape as opposed to executing the source code.
Returns
A scalar object with the value for the scalar field evaluated at the point defined by the independent variable values.
Compute the gradient (first derivative) of the scalar field with respect to all independent variables, i.e.
-
+\]" src="form_912.png"/>
Parameters
@@ -598,10 +598,10 @@
Compute the Hessian (second derivative) of the scalar field with respect to all independent variables, i.e.
-
+\]" src="form_913.png"/>
Parameters
@@ -651,10 +651,10 @@
-
Extract the function gradient for a subset of independent variables , i.e.
-, i.e.
+
+\]" src="form_914.png"/>
Parameters
@@ -710,13 +710,13 @@
-
Extract the function Hessian for a subset of independent variables , i.e.
-, i.e.
+
+\]" src="form_916.png"/>
Parameters
@@ -769,11 +769,11 @@
-
Extract the function Hessian for a subset of independent variables , i.e.
-, i.e.
+
+\]" src="form_917.png"/>
This function is a specialization of the above for rank-0 tensors (scalars). This corresponds to extracting a single entry of the Hessian matrix because both extractors imply selection of just a single row or column of the matrix.
@@ -820,11 +820,11 @@
-
Extract the function Hessian for a subset of independent variables , i.e.
-, i.e.
+
+\]" src="form_917.png"/>
This function is a specialization of the above for rank-4 symmetric tensors.
@@ -875,8 +875,8 @@
In the rare case that the number of independent or dependent variables has changed, this can also be reconfigured by passing in the appropriate arguments to the function.
Parameters
-
[in]
n_independent_variables
The number of independent variables that will be used in the definition of the functions that it is desired to compute the sensitivities of. In the computation of , this will be the number of inputs , i.e., the dimension of the domain space.
-
[in]
n_dependent_variables
The number of scalar functions to be defined that will have a sensitivity to the given independent variables. In the computation of , this will be the number of outputs , i.e., the dimension of the image space.
+
[in]
n_independent_variables
The number of independent variables that will be used in the definition of the functions that it is desired to compute the sensitivities of. In the computation of , this will be the number of inputs , i.e., the dimension of the domain space.
+
[in]
n_dependent_variables
The number of scalar functions to be defined that will have a sensitivity to the given independent variables. In the computation of , this will be the number of outputs , i.e., the dimension of the image space.
[in]
clear_registered_tapes
A flag that indicates the that list of registered_tapes must be cleared. If set to true then the data structure that tracks which tapes have been recorded is cleared as well. It is then expected that any preexisting tapes be re-recorded.
@@ -965,7 +965,7 @@
-
Register the subset of independent variables .
+
Register the subset of independent variables .
Parameters
[in]
value
A field that defines a number of independent variables. When considering taped AD numbers with branching functions, to avoid potential issues with branch switching it may be a good idea to choose these values close or equal to those that will be later evaluated and differentiated around.
@@ -1118,7 +1118,7 @@
-
Set the values for a subset of independent variables .
+
Set the values for a subset of independent variables .
Parameters
[in]
value
A field that defines the values of a number of independent variables.
@@ -1173,7 +1173,7 @@
-
Set the actual value of the independent variable .
+
Set the actual value of the independent variable .
Parameters
[in]
index
The index in the vector of independent variables.
@@ -1221,7 +1221,7 @@
-
Set the actual value of the independent variable .
+
Set the actual value of the independent variable .
Parameters
[in]
index
The index in the vector of independent variables.
@@ -2003,7 +2003,7 @@
-
Initialize an independent variable such that subsequent operations performed with it are tracked.
+
Initialize an independent variable such that subsequent operations performed with it are tracked.
Note
Care must be taken to mark each independent variable only once.
The order in which the independent variables are marked defines the order of all future internal operations. They must be manipulated in the same order as that in which they are first marked. If not then, for example, ADOL-C won't throw an error, but rather it might complain nonsensically during later computations or produce garbage results.
@@ -2081,7 +2081,7 @@
-
Initialize an independent variable .
+
Initialize an independent variable .
Parameters
[out]
out
An auto-differentiable number that is ready for use in standard computations. The operations that are performed with it are not recorded on the tape, and so should only be used when not in recording mode.
@@ -2212,7 +2212,7 @@
-
Register the definition of the index'th dependent variable .
+
Register the definition of the index'th dependent variable .
Parameters
[in]
index
The index of the entry in the global list of dependent variables that this function belongs to.
@@ -2468,7 +2468,7 @@
-
The set of dependent variables of which the derivatives with respect to will be computed.
+
The set of dependent variables of which the derivatives with respect to will be computed.
The gradients and Hessians of these dependent variables will be computed at the values set with the set_sensitivity_value() function.
Note
These are stored as an ad_type so that we can use them to compute function values and directional derivatives in the case that tapeless numbers are used
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classDifferentiation_1_1AD_1_1VectorFunction.html differs (JavaScript source, ASCII text, with very long lines (1220))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classDifferentiation_1_1AD_1_1VectorFunction.html 2023-11-25 15:25:51.633391460 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classDifferentiation_1_1AD_1_1VectorFunction.html 2023-11-25 15:25:51.633391460 +0100
@@ -468,8 +468,8 @@
The constructor for the class.
Parameters
-
[in]
n_independent_variables
The number of independent variables that will be used in the definition of the functions that it is desired to compute the sensitivities of. In the computation of , this will be the number of inputs , i.e., the dimension of the domain space.
-
[in]
n_dependent_variables
The number of scalar functions to be defined that will have a sensitivity to the given independent variables. In the computation of , this will be the number of outputs , i.e., the dimension of the image space.
+
[in]
n_independent_variables
The number of independent variables that will be used in the definition of the functions that it is desired to compute the sensitivities of. In the computation of , this will be the number of inputs , i.e., the dimension of the domain space.
+
[in]
n_dependent_variables
The number of scalar functions to be defined that will have a sensitivity to the given independent variables. In the computation of , this will be the number of outputs , i.e., the dimension of the image space.
@@ -524,7 +524,7 @@
-
Register the definition of the vector field .
+
Register the definition of the vector field .
Parameters
[in]
funcs
A vector of recorded functions that defines the dependent variables.
@@ -567,7 +567,7 @@
-
Register the definition of the vector field that may represent a subset of the dependent variables.
+
Register the definition of the vector field that may represent a subset of the dependent variables.
Parameters
[in]
funcs
The recorded functions that define a set of dependent variables.
@@ -598,7 +598,7 @@
-
Compute the value of the vector field .
+
Compute the value of the vector field .
Parameters
[out]
values
A Vector object with the value for each component of the vector field evaluated at the point defined by the independent variable values. The output values vector has a length corresponding to n_dependent_variables.
@@ -628,10 +628,10 @@
Compute the Jacobian (first derivative) of the vector field with respect to all independent variables, i.e.
-
+\]" src="form_920.png"/>
Parameters
@@ -681,7 +681,7 @@
-
Extract the set of functions' values for a subset of dependent variables .
+
Extract the set of functions' values for a subset of dependent variables .
Parameters
[in]
values
A Vector object with the value for each component of the vector field evaluated at the point defined by the independent variable values.
@@ -735,13 +735,13 @@
-
Extract the Jacobian of the subset of dependent functions for a subset of independent variables , i.e.
- for a subset of independent variables , i.e.
+
+\]" src="form_922.png"/>
-
The first index of the Jacobian matrix relates to the dependent variables, while the second index relates to the independent variables.
+
The first index of the Jacobian matrix relates to the dependent variables, while the second index relates to the independent variables.
Parameters
[in]
jacobian
The Jacobian of the vector function with respect to all independent variables, i.e., that returned by compute_jacobian().
@@ -793,11 +793,11 @@
-
Extract the Jacobian of the subset of dependent functions for a subset of independent variables , i.e.
- for a subset of independent variables , i.e.
+
+\]" src="form_922.png"/>
This function is a specialization of the above for rank-0 tensors (scalars). This corresponds to extracting a single entry of the Jacobian matrix because both extractors imply selection of just a single row or column of the matrix.
@@ -844,11 +844,11 @@
-
Extract the Jacobian of the subset of dependent functions for a subset of independent variables , i.e.
- for a subset of independent variables , i.e.
+
+\]" src="form_922.png"/>
This function is a specialization of the above for rank-4 symmetric tensors.
@@ -899,8 +899,8 @@
In the rare case that the number of independent or dependent variables has changed, this can also be reconfigured by passing in the appropriate arguments to the function.
Parameters
-
[in]
n_independent_variables
The number of independent variables that will be used in the definition of the functions that it is desired to compute the sensitivities of. In the computation of , this will be the number of inputs , i.e., the dimension of the domain space.
-
[in]
n_dependent_variables
The number of scalar functions to be defined that will have a sensitivity to the given independent variables. In the computation of , this will be the number of outputs , i.e., the dimension of the image space.
+
[in]
n_independent_variables
The number of independent variables that will be used in the definition of the functions that it is desired to compute the sensitivities of. In the computation of , this will be the number of inputs , i.e., the dimension of the domain space.
+
[in]
n_dependent_variables
The number of scalar functions to be defined that will have a sensitivity to the given independent variables. In the computation of , this will be the number of outputs , i.e., the dimension of the image space.
[in]
clear_registered_tapes
A flag that indicates the that list of registered_tapes must be cleared. If set to true then the data structure that tracks which tapes have been recorded is cleared as well. It is then expected that any preexisting tapes be re-recorded.
@@ -989,7 +989,7 @@
-
Register the subset of independent variables .
+
Register the subset of independent variables .
Parameters
[in]
value
A field that defines a number of independent variables. When considering taped AD numbers with branching functions, to avoid potential issues with branch switching it may be a good idea to choose these values close or equal to those that will be later evaluated and differentiated around.
@@ -1142,7 +1142,7 @@
-
Set the values for a subset of independent variables .
+
Set the values for a subset of independent variables .
Parameters
[in]
value
A field that defines the values of a number of independent variables.
@@ -1197,7 +1197,7 @@
-
Set the actual value of the independent variable .
+
Set the actual value of the independent variable .
Parameters
[in]
index
The index in the vector of independent variables.
@@ -1245,7 +1245,7 @@
-
Set the actual value of the independent variable .
+
Set the actual value of the independent variable .
Parameters
[in]
index
The index in the vector of independent variables.
@@ -2027,7 +2027,7 @@
-
Initialize an independent variable such that subsequent operations performed with it are tracked.
+
Initialize an independent variable such that subsequent operations performed with it are tracked.
Note
Care must be taken to mark each independent variable only once.
The order in which the independent variables are marked defines the order of all future internal operations. They must be manipulated in the same order as that in which they are first marked. If not then, for example, ADOL-C won't throw an error, but rather it might complain nonsensically during later computations or produce garbage results.
@@ -2105,7 +2105,7 @@
-
Initialize an independent variable .
+
Initialize an independent variable .
Parameters
[out]
out
An auto-differentiable number that is ready for use in standard computations. The operations that are performed with it are not recorded on the tape, and so should only be used when not in recording mode.
@@ -2236,7 +2236,7 @@
-
Register the definition of the index'th dependent variable .
+
Register the definition of the index'th dependent variable .
Parameters
[in]
index
The index of the entry in the global list of dependent variables that this function belongs to.
@@ -2492,7 +2492,7 @@
-
The set of dependent variables of which the derivatives with respect to will be computed.
+
The set of dependent variables of which the derivatives with respect to will be computed.
The gradients and Hessians of these dependent variables will be computed at the values set with the set_sensitivity_value() function.
Note
These are stored as an ad_type so that we can use them to compute function values and directional derivatives in the case that tapeless numbers are used
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classDiscreteTime.html differs (JavaScript source, ASCII text, with very long lines (2430))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classDiscreteTime.html 2023-11-25 15:25:51.650057788 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classDiscreteTime.html 2023-11-25 15:25:51.650057788 +0100
@@ -183,7 +183,7 @@
Since time is marched forward in a discrete manner in our simulations, we need to discuss how we increment time. During time stepping we enter two separate alternating regimes in every step.
The snapshot stage (the current stage, the consistent stage): In this part of the algorithm, we are at and all quantities of the simulation (displacements, strains, temperatures, etc.) are up-to-date for . In this stage, current time refers to , next time refers to , previous time refers to . The other useful notation quantities are the next time step size and previous time step size . In this stage, it is a perfect occasion to generate text output using print commands within the user's code. Additionally, post-processed outputs can be prepared here, which can then later be viewed by visualization programs such as Tecplot, Paraview, and VisIt. Additionally, during the snapshot stage, the code can assess the quality of the previous step and decide whether it wants to increase or decrease the time step size. The step size for the next time step can be modified here, by calling set_desired_next_step_size().
-
The update stage (the transition stage, the inconsistent stage): In this section of the program, the internal state of the simulation is getting updated from to . All of the variables need to be updated one by one, the step number is incremented, the time is incremented by , and time-integration algorithms are used to update the other simulation quantities. In the middle of this stage, some variables have been updated to but other variables still represent their value at . Thus, we call this the inconsistent stage, requiring that no post-processing output related to the state variables take place within it. The state variables, namely those related to time, the solution field and any internal variables, are not synchronized and then get updated one by one. In general, the order of updating variables is arbitrary, but some care should be taken if there are interdependencies between them. For example, if some variable such as depends on the calculation of another variable such as , then must be updated before can be updated.
+
The update stage (the transition stage, the inconsistent stage): In this section of the program, the internal state of the simulation is getting updated from to . All of the variables need to be updated one by one, the step number is incremented, the time is incremented by , and time-integration algorithms are used to update the other simulation quantities. In the middle of this stage, some variables have been updated to but other variables still represent their value at . Thus, we call this the inconsistent stage, requiring that no post-processing output related to the state variables take place within it. The state variables, namely those related to time, the solution field and any internal variables, are not synchronized and then get updated one by one. In general, the order of updating variables is arbitrary, but some care should be taken if there are interdependencies between them. For example, if some variable such as depends on the calculation of another variable such as , then must be updated before can be updated.
The question arises whether time should be incremented before updating state quantities. Multiple possibilities exist, depending on program and formulation requirements, and possibly the programmer's preferences:
Time is incremented before the rest of the updates. In this case, even though time is incremented to , not all variables are updated yet. During this update phase, equals the previous time step size. Previous means that it is referring to the of the advance_time() command that was performed previously. In the following example code, we are assuming that a and b are two state variables that need to be updated in this time step.
Given a triangulation and a description of a finite element, this class enumerates degrees of freedom on all vertices, edges, faces, and cells of the triangulation. As a result, it also provides a basis for a discrete space whose elements are finite element functions defined on each cell by a FiniteElement object. This class satisfies the MeshType concept requirements.
+class DoFHandler< dim, spacedim >
Given a triangulation and a description of a finite element, this class enumerates degrees of freedom on all vertices, edges, faces, and cells of the triangulation. As a result, it also provides a basis for a discrete space whose elements are finite element functions defined on each cell by a FiniteElement object. This class satisfies the MeshType concept requirements.
For each 0d, 1d, 2d, and 3d subobject, this class stores a list of the indices of degrees of freedom defined on this DoFHandler. These indices refer to the unconstrained degrees of freedom, i.e. constrained degrees of freedom are numbered in the same way as unconstrained ones, and are only later eliminated. This leads to the fact that indices in global vectors and matrices also refer to all degrees of freedom and some kind of condensation is needed to restrict the systems of equations to the unconstrained degrees of freedom only. The actual layout of storage of the indices is described in the internal::DoFHandlerImplementation::DoFLevel class documentation.
The class offers iterators to traverse all cells, in much the same way as the Triangulation class does. Using the begin() and end() functions (and companions, like begin_active()), one can obtain iterators to walk over cells, and query the degree of freedom structures as well as the triangulation data. These iterators are built on top of those of the Triangulation class, but offer the additional information on degrees of freedom functionality compared to pure triangulation iterators. The order in which dof iterators are presented by the ++ and -- operators is the same as that for the corresponding iterators traversing the triangulation on which this DoFHandler is constructed.
@@ -431,7 +431,7 @@
Like many other classes in deal.II, the DoFHandler class can stream its contents to an archive using BOOST's serialization facilities. The data so stored can later be retrieved again from the archive to restore the contents of this object. This facility is frequently used to save the state of a program to disk for possible later resurrection, often in the context of checkpoint/restart strategies for long running computations or on computers that aren't very reliable (e.g. on very large clusters where individual nodes occasionally fail and then bring down an entire MPI job).
The model for doing so is similar for the DoFHandler class as it is for the Triangulation class (see the section in the general documentation of that class). In particular, the load() function does not exactly restore the same state as was stored previously using the save() function. Rather, the function assumes that you load data into a DoFHandler object that is already associated with a triangulation that has a content that matches the one that was used when the data was saved. Likewise, the load() function assumes that the current object is already associated with a finite element object that matches the one that was associated with it when data was saved; the latter can be achieved by calling DoFHandler::distribute_dofs() using the same kind of finite element before re-loading data from the serialization archive.
hp-adaptive finite element methods
-
Instead of only using one particular FiniteElement on all cells, this class also allows for an enumeration of degrees of freedom on different finite elements on every cells. To this end, one assigns an active_fe_index to every cell that indicates which element within a collection of finite elements (represented by an object of type hp::FECollection) is the one that lives on this cell. The class then enumerates the degree of freedom associated with these finite elements on each cell of a triangulation and, if possible, identifies degrees of freedom at the interfaces of cells if they match. If neighboring cells have degrees of freedom along the common interface that do not immediate match (for example, if you have and elements meeting at a common face), then one needs to compute constraints to ensure that the resulting finite element space on the mesh remains conforming.
+
Instead of only using one particular FiniteElement on all cells, this class also allows for an enumeration of degrees of freedom on different finite elements on every cells. To this end, one assigns an active_fe_index to every cell that indicates which element within a collection of finite elements (represented by an object of type hp::FECollection) is the one that lives on this cell. The class then enumerates the degree of freedom associated with these finite elements on each cell of a triangulation and, if possible, identifies degrees of freedom at the interfaces of cells if they match. If neighboring cells have degrees of freedom along the common interface that do not immediate match (for example, if you have and elements meeting at a common face), then one needs to compute constraints to ensure that the resulting finite element space on the mesh remains conforming.
The whole process of working with objects of this type is explained in step-27. Many of the algorithms this class implements are described in the hp-paper.
Active FE indices and their behavior under mesh refinement
The typical workflow for using this class is to create a mesh, assign an active FE index to every active cell, call DoFHandler::distribute_dofs(), and then assemble a linear system and solve a problem on this finite element space.
@@ -977,7 +977,7 @@
-
Go through the triangulation and "distribute" the degrees of freedom needed for the given finite element. "Distributing" degrees of freedom involves allocating memory to store the indices on all entities on which degrees of freedom can be located (e.g., vertices, edges, faces, etc.) and to then enumerate all degrees of freedom. In other words, while the mesh and the finite element object by themselves simply define a finite element space , the process of distributing degrees of freedom makes sure that there is a basis for this space and that the shape functions of this basis are enumerated in an indexable, predictable way.
+
Go through the triangulation and "distribute" the degrees of freedom needed for the given finite element. "Distributing" degrees of freedom involves allocating memory to store the indices on all entities on which degrees of freedom can be located (e.g., vertices, edges, faces, etc.) and to then enumerate all degrees of freedom. In other words, while the mesh and the finite element object by themselves simply define a finite element space , the process of distributing degrees of freedom makes sure that there is a basis for this space and that the shape functions of this basis are enumerated in an indexable, predictable way.
The exact order in which degrees of freedom on a mesh are ordered, i.e., the order in which basis functions of the finite element space are enumerated, is something that deal.II treats as an implementation detail. By and large, degrees of freedom are enumerated in the same order in which we traverse cells, but you should not rely on any specific numbering. In contrast, if you want a particular ordering, use the functions in namespace DoFRenumbering.
This function is first discussed in the introduction to the step-2 tutorial program.
Note
This function makes a copy of the finite element given as argument, and stores it as a member variable, similarly to the above function set_fe().
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classDynamicSparsityPattern.html differs (JavaScript source, ASCII text, with very long lines (912))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classDynamicSparsityPattern.html 2023-11-25 15:25:51.716723095 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classDynamicSparsityPattern.html 2023-11-25 15:25:51.716723095 +0100
@@ -1181,7 +1181,7 @@
-
Compute the bandwidth of the matrix represented by this structure. The bandwidth is the maximum of for which the index pair represents a nonzero entry of the matrix.
+
Compute the bandwidth of the matrix represented by this structure. The bandwidth is the maximum of for which the index pair represents a nonzero entry of the matrix.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classEigenInverse.html differs (JavaScript source, ASCII text, with very long lines (1094))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classEigenInverse.html 2023-11-25 15:25:51.740055956 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classEigenInverse.html 2023-11-25 15:25:51.743389219 +0100
@@ -190,7 +190,7 @@
template<typename VectorType = Vector<double>>
class EigenInverse< VectorType >
Inverse iteration (Wieland) for eigenvalue computations.
This class implements an adaptive version of the inverse iteration by Wieland.
-
There are two choices for the stopping criterion: by default, the norm of the residual is computed. Since this might not converge to zero for non-symmetric matrices with non-trivial Jordan blocks, it can be replaced by checking the difference of successive eigenvalues. Use AdditionalData::use_residual for switching this option.
+
There are two choices for the stopping criterion: by default, the norm of the residual is computed. Since this might not converge to zero for non-symmetric matrices with non-trivial Jordan blocks, it can be replaced by checking the difference of successive eigenvalues. Use AdditionalData::use_residual for switching this option.
Usually, the initial guess entering this method is updated after each step, replacing it with the new approximation of the eigenvalue. Using a parameter AdditionalData::relaxation between 0 and 1, this update can be damped. With relaxation parameter 0, no update is performed. This damping allows for slower adaption of the shift value to make sure that the method converges to the eigenvalue closest to the initial guess. This can be aided by the parameter AdditionalData::start_adaption, which indicates the first iteration step in which the shift value should be adapted.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classEigenPower.html differs (JavaScript source, ASCII text, with very long lines (1094))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classEigenPower.html 2023-11-25 15:25:51.766722080 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classEigenPower.html 2023-11-25 15:25:51.766722080 +0100
@@ -189,7 +189,7 @@
Detailed Description
template<typename VectorType = Vector<double>>
class EigenPower< VectorType >
Power method (von Mises) for eigenvalue computations.
-
This method determines the largest eigenvalue of a matrix by applying increasing powers of this matrix to a vector. If there is an eigenvalue with dominant absolute value, the iteration vectors will become aligned to its eigenspace and .
+
This method determines the largest eigenvalue of a matrix by applying increasing powers of this matrix to a vector. If there is an eigenvalue with dominant absolute value, the iteration vectors will become aligned to its eigenspace and .
A shift parameter allows to shift the spectrum, so it is possible to compute the smallest eigenvalue, too.
Convergence of this method is known to be slow.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classEllipticalManifold.html differs (JavaScript source, ASCII text, with very long lines (1015))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classEllipticalManifold.html 2023-11-25 15:25:51.800054734 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classEllipticalManifold.html 2023-11-25 15:25:51.800054734 +0100
@@ -221,16 +221,16 @@
Detailed Description
template<int dim, int spacedim = dim>
class EllipticalManifold< dim, spacedim >
Elliptical manifold description derived from ChartManifold. More information on the elliptical coordinate system can be found at Wikipedia .
-
This is based on the definition of elliptic coordinates
-
+
+\]" src="form_1454.png"/>
-
in which are coordinates of the center of the cartesian system.
-
The current implementation uses coordinates , instead of , and fixes according to a given eccentricity. Therefore, this choice of coordinates generates an elliptical manifold characterized by a constant eccentricity: , with .
+
in which are coordinates of the center of the cartesian system.
+
The current implementation uses coordinates , instead of , and fixes according to a given eccentricity. Therefore, this choice of coordinates generates an elliptical manifold characterized by a constant eccentricity: , with .
The constructor of this class will throw an exception if both dim and spacedim are different from two.
This manifold can be used to produce hyper_shells with elliptical curvature. As an example, the test elliptical_manifold_01 produces the following triangulation:
@@ -352,7 +352,7 @@
center
Center of the manifold.
major_axis_direction
Direction of the major axis of the manifold.
-
eccentricity
Eccentricity of the manifold .
+
eccentricity
Eccentricity of the manifold .
@@ -489,7 +489,7 @@
-
Given a point in the chartdim dimensional Euclidean space, this method returns the derivatives of the function that maps from the chartdim-dimensional to the spacedim-dimensional space. In other words, it is a matrix of size .
+
Given a point in the chartdim dimensional Euclidean space, this method returns the derivatives of the function that maps from the chartdim-dimensional to the spacedim-dimensional space. In other words, it is a matrix of size .
This function is used in the computations required by the get_tangent_vector() function. Since not all users of the Manifold class interface will require calling that function, the current function is implemented but will trigger an exception whenever called. This allows derived classes to avoid implementing the push_forward_gradient function if this functionality is not needed in the user program.
Refer to the general documentation of this class for more information.
@@ -521,7 +521,7 @@
Return the periodicity associated with the submanifold.
-
For and , the first coordinate is non-periodic, while the second coordinate has a periodicity of .
+
For and , the first coordinate is non-periodic, while the second coordinate has a periodicity of .
Given a point in the chartdim dimensional Euclidean space, this method returns the derivatives of the function that maps from the chartdim-dimensional to the spacedim-dimensional space. In other words, it is a matrix of size .
+
Given a point in the chartdim dimensional Euclidean space, this method returns the derivatives of the function that maps from the chartdim-dimensional to the spacedim-dimensional space. In other words, it is a matrix of size .
This function is used in the computations required by the get_tangent_vector() function. Since not all users of the Manifold class interface will require calling that function, the current function is implemented but will trigger an exception whenever called. This allows derived classes to avoid implementing the push_forward_gradient function if this functionality is not needed in the user program.
Refer to the general documentation of this class for more information.
@@ -820,24 +820,24 @@
-
Return a vector that, at , is tangential to the geodesic that connects two points . See the documentation of the Manifold class and of Manifold::get_tangent_vector() for a more detailed description.
-
For the current class, we assume that this geodesic is the image under the push_forward() operation of a straight line of the pre-images of x1 and x2 (where pre-images are computed by pulling back the locations x1 and x2). In other words, if these preimages are , then the geodesic in preimage (the chartdim-dimensional Euclidean) space is
-, is tangential to the geodesic that connects two points . See the documentation of the Manifold class and of Manifold::get_tangent_vector() for a more detailed description.
+
For the current class, we assume that this geodesic is the image under the push_forward() operation of a straight line of the pre-images of x1 and x2 (where pre-images are computed by pulling back the locations x1 and x2). In other words, if these preimages are , then the geodesic in preimage (the chartdim-dimensional Euclidean) space is
+
+\end{align*}" src="form_1440.png"/>
In image space, i.e., in the space in which we operate, this leads to the curve
-
+\end{align*}" src="form_1441.png"/>
-
What the current function is supposed to return is . By the chain rule, this is equal to
-. By the chain rule, this is equal to
+
+\end{align*}" src="form_1442.png"/>
This formula may then have to be slightly modified by considering any periodicity that was assumed in the call to the constructor.
-
Thus, the computation of tangent vectors also requires the implementation of derivatives of the push-forward mapping. Here, is a chartdim-dimensional vector, and is a spacedim-times-chartdim-dimensional matrix. Consequently, and as desired, the operation results in a spacedim-dimensional vector.
+
Thus, the computation of tangent vectors also requires the implementation of derivatives of the push-forward mapping. Here, is a chartdim-dimensional vector, and is a spacedim-times-chartdim-dimensional matrix. Consequently, and as desired, the operation results in a spacedim-dimensional vector.
Parameters
x1
The first point that describes the geodesic, and the one at which the "direction" is to be evaluated.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFEEvaluation.html differs (JavaScript source, ASCII text, with very long lines (1236))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFEEvaluation.html 2023-11-25 15:25:51.856720248 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFEEvaluation.html 2023-11-25 15:25:51.856720248 +0100
@@ -453,7 +453,7 @@
Likewise, a gradient of the finite element solution represented by vector can be interpolated to the quadrature points by fe_eval.get_gradient(q). The combination of read_dof_values(), evaluate() and get_value() is similar to what FEValues::get_function_values or FEValues::get_function_gradients does, but it is in general much faster because it makes use of the tensor product, see the description of the evaluation routines below, and can do this operation for several cells at once through vectorization.
-
The second class of tasks done by FEEvaluation are integration tasks for right hand sides. In finite element computations, these typically consist of multiplying a quantity on quadrature points (a function value, or a field interpolated by the finite element space itself) by a set of test functions and integrating over the cell through summation of the values in each quadrature point, multiplied by the quadrature weight and the Jacobian determinant of the transformation. If a generic Function object is given and we want to compute , this is done by the following cell-wise integration:
+
The second class of tasks done by FEEvaluation are integration tasks for right hand sides. In finite element computations, these typically consist of multiplying a quantity on quadrature points (a function value, or a field interpolated by the finite element space itself) by a set of test functions and integrating over the cell through summation of the values in each quadrature point, multiplied by the quadrature weight and the Jacobian determinant of the transformation. If a generic Function object is given and we want to compute , this is done by the following cell-wise integration:
Constructor for the reduced functionality. This constructor is equivalent to the other one except that it makes the object use a mapping (i.e., an object of type MappingQ(1)) implicitly.
+
Constructor for the reduced functionality. This constructor is equivalent to the other one except that it makes the object use a mapping (i.e., an object of type MappingQ(1)) implicitly.
@@ -2142,8 +2142,8 @@
-
Return the derivative of a finite element function at quadrature point number q_point after a call to FEEvaluation::evaluate(EvaluationFlags::gradients) the direction normal to the face:
+
Return the derivative of a finite element function at quadrature point number q_point after a call to FEEvaluation::evaluate(EvaluationFlags::gradients) the direction normal to the face:
This call is equivalent to calling get_gradient() * normal_vector() but will use a more efficient internal representation of data.
Note
The derived class FEEvaluationAccess overloads this operation with specializations for the scalar case (n_components == 1) and for the vector-valued case (n_components == dim).
@@ -2437,7 +2437,7 @@
-
Return the curl of the vector field, after a call to evaluate(EvaluationFlags::gradients).
+
Return the curl of the vector field, after a call to evaluate(EvaluationFlags::gradients).
Note
Only available for the vector-valued case (n_components == dim).
@@ -2956,8 +2956,8 @@
-
Return the inverse and transposed version of the Jacobian of the mapping between the unit to the real cell defined as . The entry of the returned tensor contains , i.e., columns refer to reference space coordinates and rows to real cell coordinates. Thus, the returned tensor represents a covariant transformation, which is used in the FEEvaluationBase::get_gradient() function to transform the unit cell gradients to gradients on the real cell by a multiplication .
+
Return the inverse and transposed version of the Jacobian of the mapping between the unit to the real cell defined as . The entry of the returned tensor contains , i.e., columns refer to reference space coordinates and rows to real cell coordinates. Thus, the returned tensor represents a covariant transformation, which is used in the FEEvaluationBase::get_gradient() function to transform the unit cell gradients to gradients on the real cell by a multiplication .
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFEEvaluationAccess.html differs (JavaScript source, ASCII text, with very long lines (1677))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFEEvaluationAccess.html 2023-11-25 15:25:51.900052697 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFEEvaluationAccess.html 2023-11-25 15:25:51.900052697 +0100
@@ -1223,8 +1223,8 @@
-
Return the derivative of a finite element function at quadrature point number q_point after a call to FEEvaluation::evaluate(EvaluationFlags::gradients) the direction normal to the face:
+
Return the derivative of a finite element function at quadrature point number q_point after a call to FEEvaluation::evaluate(EvaluationFlags::gradients) the direction normal to the face:
This call is equivalent to calling get_gradient() * normal_vector() but will use a more efficient internal representation of data.
Note
The derived class FEEvaluationAccess overloads this operation with specializations for the scalar case (n_components == 1) and for the vector-valued case (n_components == dim).
@@ -1518,7 +1518,7 @@
-
Return the curl of the vector field, after a call to evaluate(EvaluationFlags::gradients).
+
Return the curl of the vector field, after a call to evaluate(EvaluationFlags::gradients).
Note
Only available for the vector-valued case (n_components == dim).
@@ -2037,8 +2037,8 @@
-
Return the inverse and transposed version of the Jacobian of the mapping between the unit to the real cell defined as . The entry of the returned tensor contains , i.e., columns refer to reference space coordinates and rows to real cell coordinates. Thus, the returned tensor represents a covariant transformation, which is used in the FEEvaluationBase::get_gradient() function to transform the unit cell gradients to gradients on the real cell by a multiplication .
+
Return the inverse and transposed version of the Jacobian of the mapping between the unit to the real cell defined as . The entry of the returned tensor contains , i.e., columns refer to reference space coordinates and rows to real cell coordinates. Thus, the returned tensor represents a covariant transformation, which is used in the FEEvaluationBase::get_gradient() function to transform the unit cell gradients to gradients on the real cell by a multiplication .
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFEEvaluationAccess_3_011_00_011_00_01Number_00_01is__face_00_01VectorizedArrayType_01_4.html differs (JavaScript source, ASCII text, with very long lines (1744))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFEEvaluationAccess_3_011_00_011_00_01Number_00_01is__face_00_01VectorizedArrayType_01_4.html 2023-11-25 15:25:51.940051883 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFEEvaluationAccess_3_011_00_011_00_01Number_00_01is__face_00_01VectorizedArrayType_01_4.html 2023-11-25 15:25:51.940051883 +0100
@@ -973,8 +973,8 @@
-
Return the derivative of a finite element function at quadrature point number q_point after a call to FEEvaluation::evaluate(EvaluationFlags::gradients) the direction normal to the face:
+
Return the derivative of a finite element function at quadrature point number q_point after a call to FEEvaluation::evaluate(EvaluationFlags::gradients) the direction normal to the face:
This call is equivalent to calling get_gradient() * normal_vector() but will use a more efficient internal representation of data.
Note
The derived class FEEvaluationAccess overloads this operation with specializations for the scalar case (n_components == 1) and for the vector-valued case (n_components == dim).
@@ -1753,7 +1753,7 @@
-
Return the curl of the vector field, after a call to evaluate(EvaluationFlags::gradients).
+
Return the curl of the vector field, after a call to evaluate(EvaluationFlags::gradients).
Note
Only available for the vector-valued case (n_components == dim).
@@ -2221,8 +2221,8 @@
-
Return the inverse and transposed version of the Jacobian of the mapping between the unit to the real cell defined as . The entry of the returned tensor contains , i.e., columns refer to reference space coordinates and rows to real cell coordinates. Thus, the returned tensor represents a covariant transformation, which is used in the FEEvaluationBase::get_gradient() function to transform the unit cell gradients to gradients on the real cell by a multiplication .
+
Return the inverse and transposed version of the Jacobian of the mapping between the unit to the real cell defined as . The entry of the returned tensor contains , i.e., columns refer to reference space coordinates and rows to real cell coordinates. Thus, the returned tensor represents a covariant transformation, which is used in the FEEvaluationBase::get_gradient() function to transform the unit cell gradients to gradients on the real cell by a multiplication .
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFEEvaluationAccess_3_01dim_00_011_00_01Number_00_01is__face_00_01VectorizedArrayType_01_4.html differs (JavaScript source, ASCII text, with very long lines (1748))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFEEvaluationAccess_3_01dim_00_011_00_01Number_00_01is__face_00_01VectorizedArrayType_01_4.html 2023-11-25 15:25:51.980051072 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFEEvaluationAccess_3_01dim_00_011_00_01Number_00_01is__face_00_01VectorizedArrayType_01_4.html 2023-11-25 15:25:51.980051072 +0100
@@ -946,8 +946,8 @@
-
Return the derivative of a finite element function at quadrature point number q_point after a call to FEEvaluation::evaluate(EvaluationFlags::gradients) the direction normal to the face:
+
Return the derivative of a finite element function at quadrature point number q_point after a call to FEEvaluation::evaluate(EvaluationFlags::gradients) the direction normal to the face:
This call is equivalent to calling get_gradient() * normal_vector() but will use a more efficient internal representation of data.
Note
The derived class FEEvaluationAccess overloads this operation with specializations for the scalar case (n_components == 1) and for the vector-valued case (n_components == dim).
@@ -1653,7 +1653,7 @@
-
Return the curl of the vector field, after a call to evaluate(EvaluationFlags::gradients).
+
Return the curl of the vector field, after a call to evaluate(EvaluationFlags::gradients).
Note
Only available for the vector-valued case (n_components == dim).
@@ -2121,8 +2121,8 @@
-
Return the inverse and transposed version of the Jacobian of the mapping between the unit to the real cell defined as . The entry of the returned tensor contains , i.e., columns refer to reference space coordinates and rows to real cell coordinates. Thus, the returned tensor represents a covariant transformation, which is used in the FEEvaluationBase::get_gradient() function to transform the unit cell gradients to gradients on the real cell by a multiplication .
+
Return the inverse and transposed version of the Jacobian of the mapping between the unit to the real cell defined as . The entry of the returned tensor contains , i.e., columns refer to reference space coordinates and rows to real cell coordinates. Thus, the returned tensor represents a covariant transformation, which is used in the FEEvaluationBase::get_gradient() function to transform the unit cell gradients to gradients on the real cell by a multiplication .
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFEEvaluationAccess_3_01dim_00_01dim_00_01Number_00_01is__face_00_01VectorizedArrayType_01_4.html differs (JavaScript source, ASCII text, with very long lines (1754))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFEEvaluationAccess_3_01dim_00_01dim_00_01Number_00_01is__face_00_01VectorizedArrayType_01_4.html 2023-11-25 15:25:52.016716990 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFEEvaluationAccess_3_01dim_00_01dim_00_01Number_00_01is__face_00_01VectorizedArrayType_01_4.html 2023-11-25 15:25:52.016716990 +0100
@@ -865,7 +865,7 @@
-
Return the curl of the vector field, after a call to evaluate(EvaluationFlags::gradients).
+
Return the curl of the vector field, after a call to evaluate(EvaluationFlags::gradients).
@@ -1463,8 +1463,8 @@
-
Return the derivative of a finite element function at quadrature point number q_point after a call to FEEvaluation::evaluate(EvaluationFlags::gradients) the direction normal to the face:
+
Return the derivative of a finite element function at quadrature point number q_point after a call to FEEvaluation::evaluate(EvaluationFlags::gradients) the direction normal to the face:
This call is equivalent to calling get_gradient() * normal_vector() but will use a more efficient internal representation of data.
Note
The derived class FEEvaluationAccess overloads this operation with specializations for the scalar case (n_components == 1) and for the vector-valued case (n_components == dim).
@@ -1986,8 +1986,8 @@
-
Return the inverse and transposed version of the Jacobian of the mapping between the unit to the real cell defined as . The entry of the returned tensor contains , i.e., columns refer to reference space coordinates and rows to real cell coordinates. Thus, the returned tensor represents a covariant transformation, which is used in the FEEvaluationBase::get_gradient() function to transform the unit cell gradients to gradients on the real cell by a multiplication .
+
Return the inverse and transposed version of the Jacobian of the mapping between the unit to the real cell defined as . The entry of the returned tensor contains , i.e., columns refer to reference space coordinates and rows to real cell coordinates. Thus, the returned tensor represents a covariant transformation, which is used in the FEEvaluationBase::get_gradient() function to transform the unit cell gradients to gradients on the real cell by a multiplication .
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFEEvaluationBase.html differs (JavaScript source, ASCII text, with very long lines (1401))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFEEvaluationBase.html 2023-11-25 15:25:52.056716176 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFEEvaluationBase.html 2023-11-25 15:25:52.056716176 +0100
@@ -1123,8 +1123,8 @@
-
Return the derivative of a finite element function at quadrature point number q_point after a call to FEEvaluation::evaluate(EvaluationFlags::gradients) the direction normal to the face:
+
Return the derivative of a finite element function at quadrature point number q_point after a call to FEEvaluation::evaluate(EvaluationFlags::gradients) the direction normal to the face:
This call is equivalent to calling get_gradient() * normal_vector() but will use a more efficient internal representation of data.
Note
The derived class FEEvaluationAccess overloads this operation with specializations for the scalar case (n_components == 1) and for the vector-valued case (n_components == dim).
@@ -1346,7 +1346,7 @@
-
Return the curl of the vector field, after a call to evaluate(EvaluationFlags::gradients).
+
Return the curl of the vector field, after a call to evaluate(EvaluationFlags::gradients).
Note
Only available for the vector-valued case (n_components == dim).
@@ -1853,8 +1853,8 @@
-
Return the inverse and transposed version of the Jacobian of the mapping between the unit to the real cell defined as . The entry of the returned tensor contains , i.e., columns refer to reference space coordinates and rows to real cell coordinates. Thus, the returned tensor represents a covariant transformation, which is used in the FEEvaluationBase::get_gradient() function to transform the unit cell gradients to gradients on the real cell by a multiplication .
+
Return the inverse and transposed version of the Jacobian of the mapping between the unit to the real cell defined as . The entry of the returned tensor contains , i.e., columns refer to reference space coordinates and rows to real cell coordinates. Thus, the returned tensor represents a covariant transformation, which is used in the FEEvaluationBase::get_gradient() function to transform the unit cell gradients to gradients on the real cell by a multiplication .
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFEEvaluationData.html differs (JavaScript source, ASCII text, with very long lines (811))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFEEvaluationData.html 2023-11-25 15:25:52.090048833 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFEEvaluationData.html 2023-11-25 15:25:52.090048833 +0100
@@ -796,8 +796,8 @@
-
Return the inverse and transposed version of the Jacobian of the mapping between the unit to the real cell defined as . The entry of the returned tensor contains , i.e., columns refer to reference space coordinates and rows to real cell coordinates. Thus, the returned tensor represents a covariant transformation, which is used in the FEEvaluationBase::get_gradient() function to transform the unit cell gradients to gradients on the real cell by a multiplication .
+
Return the inverse and transposed version of the Jacobian of the mapping between the unit to the real cell defined as . The entry of the returned tensor contains , i.e., columns refer to reference space coordinates and rows to real cell coordinates. Thus, the returned tensor represents a covariant transformation, which is used in the FEEvaluationBase::get_gradient() function to transform the unit cell gradients to gradients on the real cell by a multiplication .
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFEFaceEvaluation.html differs (JavaScript source, ASCII text, with very long lines (1540))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFEFaceEvaluation.html 2023-11-25 15:25:52.136714550 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFEFaceEvaluation.html 2023-11-25 15:25:52.136714550 +0100
@@ -1744,8 +1744,8 @@
-
Return the derivative of a finite element function at quadrature point number q_point after a call to FEEvaluation::evaluate(EvaluationFlags::gradients) the direction normal to the face:
+
Return the derivative of a finite element function at quadrature point number q_point after a call to FEEvaluation::evaluate(EvaluationFlags::gradients) the direction normal to the face:
This call is equivalent to calling get_gradient() * normal_vector() but will use a more efficient internal representation of data.
Note
The derived class FEEvaluationAccess overloads this operation with specializations for the scalar case (n_components == 1) and for the vector-valued case (n_components == dim).
@@ -2039,7 +2039,7 @@
-
Return the curl of the vector field, after a call to evaluate(EvaluationFlags::gradients).
+
Return the curl of the vector field, after a call to evaluate(EvaluationFlags::gradients).
Note
Only available for the vector-valued case (n_components == dim).
@@ -2558,8 +2558,8 @@
-
Return the inverse and transposed version of the Jacobian of the mapping between the unit to the real cell defined as . The entry of the returned tensor contains , i.e., columns refer to reference space coordinates and rows to real cell coordinates. Thus, the returned tensor represents a covariant transformation, which is used in the FEEvaluationBase::get_gradient() function to transform the unit cell gradients to gradients on the real cell by a multiplication .
+
Return the inverse and transposed version of the Jacobian of the mapping between the unit to the real cell defined as . The entry of the returned tensor contains , i.e., columns refer to reference space coordinates and rows to real cell coordinates. Thus, the returned tensor represents a covariant transformation, which is used in the FEEvaluationBase::get_gradient() function to transform the unit cell gradients to gradients on the real cell by a multiplication .
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFEFaceValues.html differs (JavaScript source, ASCII text, with very long lines (878))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFEFaceValues.html 2023-11-25 15:25:52.180047000 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFEFaceValues.html 2023-11-25 15:25:52.183380267 +0100
@@ -551,7 +551,7 @@
-
Constructor. This constructor is equivalent to the other one except that it makes the object use a mapping (i.e., an object of type MappingQ(1)) implicitly.
+
Constructor. This constructor is equivalent to the other one except that it makes the object use a mapping (i.e., an object of type MappingQ(1)) implicitly.
@@ -996,7 +996,7 @@
If the shape function is vector-valued, then this returns the only non- zero component. If the shape function has more than one non-zero component (i.e. it is not primitive), then throw an exception of type ExcShapeFunctionNotPrimitive. In that case, use the shape_value_component() function.
Parameters
-
i
Number of the shape function to be evaluated. Note that this number runs from zero to dofs_per_cell, even in the case of an FEFaceValues or FESubfaceValues object.
+
i
Number of the shape function to be evaluated. Note that this number runs from zero to dofs_per_cell, even in the case of an FEFaceValues or FESubfaceValues object.
q_point
Number of the quadrature point at which function is to be evaluated
@@ -1046,7 +1046,7 @@
Compute one vector component of the value of a shape function at a quadrature point. If the finite element is scalar, then only component zero is allowed and the return value equals that of the shape_value() function. If the finite element is vector valued but all shape functions are primitive (i.e. they are non-zero in only one component), then the value returned by shape_value() equals that of this function for exactly one component. This function is therefore only of greater interest if the shape function is not primitive, but then it is necessary since the other function cannot be used.
Parameters
-
i
Number of the shape function to be evaluated.
+
i
Number of the shape function to be evaluated.
q_point
Number of the quadrature point at which function is to be evaluated.
component
vector component to be evaluated.
@@ -1094,7 +1094,7 @@
The same holds for the arguments of this function as for the shape_value() function.
Parameters
-
i
Number of the shape function to be evaluated.
+
i
Number of the shape function to be evaluated.
q_point
Number of the quadrature point at which function is to be evaluated.
@@ -1351,17 +1351,17 @@
-
Return the values of a finite element function at the quadrature points of the current cell, face, or subface (selected the last time the reinit() function was called). That is, if the first argument fe_function is a vector of nodal values of a finite element function defined on a DoFHandler object, then the output vector (the second argument, values) is the vector of values where are the quadrature points on the current cell . This function is first discussed in the Results section of step-4, and the related get_function_gradients() function is also used in step-15 along with numerous other tutorial programs.
+
Return the values of a finite element function at the quadrature points of the current cell, face, or subface (selected the last time the reinit() function was called). That is, if the first argument fe_function is a vector of nodal values of a finite element function defined on a DoFHandler object, then the output vector (the second argument, values) is the vector of values where are the quadrature points on the current cell . This function is first discussed in the Results section of step-4, and the related get_function_gradients() function is also used in step-15 along with numerous other tutorial programs.
If the current cell is not active (i.e., it has children), then the finite element function is, strictly speaking, defined by shape functions that live on these child cells. Rather than evaluating the shape functions on the child cells, with the quadrature points defined on the current cell, this function first interpolates the finite element function to shape functions defined on the current cell, and then evaluates this interpolated function.
This function may only be used if the finite element in use is a scalar one, i.e. has only one vector component. To get values of multi-component elements, there is another get_function_values() below, returning a vector of vectors of results.
Parameters
[in]
fe_function
A vector of values that describes (globally) the finite element function that this function should evaluate at the quadrature points of the current cell.
-
[out]
values
The values of the function specified by fe_function at the quadrature points of the current cell. The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the values of shape function times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument). This happens to be equal to the type of the elements of the solution vector.
+
[out]
values
The values of the function specified by fe_function at the quadrature points of the current cell. The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the values of shape function times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument). This happens to be equal to the type of the elements of the solution vector.
-
Postcondition
values[q] will contain the value of the field described by fe_function at the th quadrature point.
+
Postcondition
values[q] will contain the value of the field described by fe_function at the th quadrature point.
Note
The actual data type of the input vector may be either a Vector<T>, BlockVector<T>, or one of the PETSc or Trilinos vector wrapper classes. It represents a global vector of DoF values associated with the DoFHandler object with which this FEValues object was last initialized.
This function does the same as the other get_function_values(), but applied to multi-component (vector-valued) elements. The meaning of the arguments is as explained there.
-
Postcondition
values[q] is a vector of values of the field described by fe_function at the th quadrature point. The size of the vector accessed by values[q] equals the number of components of the finite element, i.e. values[q](c) returns the value of the th vector component at the th quadrature point.
+
Postcondition
values[q] is a vector of values of the field described by fe_function at the th quadrature point. The size of the vector accessed by values[q] equals the number of components of the finite element, i.e. values[q](c) returns the value of the th vector component at the th quadrature point.
Return the gradients of a finite element function at the quadrature points of the current cell, face, or subface (selected the last time the reinit() function was called). That is, if the first argument fe_function is a vector of nodal values of a finite element function defined on a DoFHandler object, then the output vector (the second argument, values) is the vector of values where are the quadrature points on the current cell . This function is first discussed in the Results section of step-4, and it is also used in step-15 along with numerous other tutorial programs.
+
Return the gradients of a finite element function at the quadrature points of the current cell, face, or subface (selected the last time the reinit() function was called). That is, if the first argument fe_function is a vector of nodal values of a finite element function defined on a DoFHandler object, then the output vector (the second argument, values) is the vector of values where are the quadrature points on the current cell . This function is first discussed in the Results section of step-4, and it is also used in step-15 along with numerous other tutorial programs.
This function may only be used if the finite element in use is a scalar one, i.e. has only one vector component. There is a corresponding function of the same name for vector-valued finite elements.
Parameters
[in]
fe_function
A vector of values that describes (globally) the finite element function that this function should evaluate at the quadrature points of the current cell.
-
[out]
gradients
The gradients of the function specified by fe_function at the quadrature points of the current cell. The gradients are computed in real space (as opposed to on the unit cell). The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the gradients of shape function times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
+
[out]
gradients
The gradients of the function specified by fe_function at the quadrature points of the current cell. The gradients are computed in real space (as opposed to on the unit cell). The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the gradients of shape function times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
-
Postcondition
gradients[q] will contain the gradient of the field described by fe_function at the th quadrature point. gradients[q][d] represents the derivative in coordinate direction at quadrature point .
+
Postcondition
gradients[q] will contain the gradient of the field described by fe_function at the th quadrature point. gradients[q][d] represents the derivative in coordinate direction at quadrature point .
Note
The actual data type of the input vector may be either a Vector<T>, BlockVector<T>, or one of the PETSc or Trilinos vector wrapper classes. It represents a global vector of DoF values associated with the DoFHandler object with which this FEValues object was last initialized.
This function does the same as the other get_function_gradients(), but applied to multi-component (vector-valued) elements. The meaning of the arguments is as explained there.
-
Postcondition
gradients[q] is a vector of gradients of the field described by fe_function at the th quadrature point. The size of the vector accessed by gradients[q] equals the number of components of the finite element, i.e. gradients[q][c] returns the gradient of the th vector component at the th quadrature point. Consequently, gradients[q][c][d] is the derivative in coordinate direction of the th vector component of the vector field at quadrature point of the current cell.
+
Postcondition
gradients[q] is a vector of gradients of the field described by fe_function at the th quadrature point. The size of the vector accessed by gradients[q] equals the number of components of the finite element, i.e. gradients[q][c] returns the gradient of the th vector component at the th quadrature point. Consequently, gradients[q][c][d] is the derivative in coordinate direction of the th vector component of the vector field at quadrature point of the current cell.
A vector of values that describes (globally) the finite element function that this function should evaluate at the quadrature points of the current cell.
-
[out]
hessians
The Hessians of the function specified by fe_function at the quadrature points of the current cell. The Hessians are computed in real space (as opposed to on the unit cell). The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the Hessians of shape function times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
+
[out]
hessians
The Hessians of the function specified by fe_function at the quadrature points of the current cell. The Hessians are computed in real space (as opposed to on the unit cell). The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the Hessians of shape function times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
-
Postcondition
hessians[q] will contain the Hessian of the field described by fe_function at the th quadrature point. hessians[q][i][j] represents the th component of the matrix of second derivatives at quadrature point .
+
Postcondition
hessians[q] will contain the Hessian of the field described by fe_function at the th quadrature point. hessians[q][i][j] represents the th component of the matrix of second derivatives at quadrature point .
Note
The actual data type of the input vector may be either a Vector<T>, BlockVector<T>, or one of the PETSc or Trilinos vector wrapper classes. It represents a global vector of DoF values associated with the DoFHandler object with which this FEValues object was last initialized.
This function does the same as the other get_function_hessians(), but applied to multi-component (vector-valued) elements. The meaning of the arguments is as explained there.
-
Postcondition
hessians[q] is a vector of Hessians of the field described by fe_function at the th quadrature point. The size of the vector accessed by hessians[q] equals the number of components of the finite element, i.e. hessians[q][c] returns the Hessian of the th vector component at the th quadrature point. Consequently, hessians[q][c][i][j] is the th component of the matrix of second derivatives of the th vector component of the vector field at quadrature point of the current cell.
+
Postcondition
hessians[q] is a vector of Hessians of the field described by fe_function at the th quadrature point. The size of the vector accessed by hessians[q] equals the number of components of the finite element, i.e. hessians[q][c] returns the Hessian of the th vector component at the th quadrature point. Consequently, hessians[q][c][i][j] is the th component of the matrix of second derivatives of the th vector component of the vector field at quadrature point of the current cell.
A vector of values that describes (globally) the finite element function that this function should evaluate at the quadrature points of the current cell.
-
[out]
laplacians
The Laplacians of the function specified by fe_function at the quadrature points of the current cell. The Laplacians are computed in real space (as opposed to on the unit cell). The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the Laplacians of shape function times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument). This happens to be equal to the type of the elements of the input vector.
+
[out]
laplacians
The Laplacians of the function specified by fe_function at the quadrature points of the current cell. The Laplacians are computed in real space (as opposed to on the unit cell). The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the Laplacians of shape function times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument). This happens to be equal to the type of the elements of the input vector.
-
Postcondition
laplacians[q] will contain the Laplacian of the field described by fe_function at the th quadrature point.
+
Postcondition
laplacians[q] will contain the Laplacian of the field described by fe_function at the th quadrature point.
For each component of the output vector, there holds laplacians[q]=trace(hessians[q]), where hessians would be the output of the get_function_hessians() function.
Note
The actual data type of the input vector may be either a Vector<T>, BlockVector<T>, or one of the PETSc or Trilinos vector wrapper classes. It represents a global vector of DoF values associated with the DoFHandler object with which this FEValues object was last initialized.
@@ -2070,7 +2070,7 @@
This function does the same as the other get_function_laplacians(), but applied to multi-component (vector-valued) elements. The meaning of the arguments is as explained there.
-
Postcondition
laplacians[q] is a vector of Laplacians of the field described by fe_function at the th quadrature point. The size of the vector accessed by laplacians[q] equals the number of components of the finite element, i.e. laplacians[q][c] returns the Laplacian of the th vector component at the th quadrature point.
+
Postcondition
laplacians[q] is a vector of Laplacians of the field described by fe_function at the th quadrature point. The size of the vector accessed by laplacians[q] equals the number of components of the finite element, i.e. laplacians[q][c] returns the Laplacian of the th vector component at the th quadrature point.
For each component of the output vector, there holds laplacians[q][c]=trace(hessians[q][c]), where hessians would be the output of the get_function_hessians() function.
A vector of values that describes (globally) the finite element function that this function should evaluate at the quadrature points of the current cell.
-
[out]
third_derivatives
The third derivatives of the function specified by fe_function at the quadrature points of the current cell. The third derivatives are computed in real space (as opposed to on the unit cell). The object is assumed to already have the correct size. The data type stored by this output vector must be what you get when you multiply the third derivatives of shape function times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
+
[out]
third_derivatives
The third derivatives of the function specified by fe_function at the quadrature points of the current cell. The third derivatives are computed in real space (as opposed to on the unit cell). The object is assumed to already have the correct size. The data type stored by this output vector must be what you get when you multiply the third derivatives of shape function times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
-
Postcondition
third_derivatives[q] will contain the third derivatives of the field described by fe_function at the th quadrature point. third_derivatives[q][i][j][k] represents the th component of the 3rd order tensor of third derivatives at quadrature point .
+
Postcondition
third_derivatives[q] will contain the third derivatives of the field described by fe_function at the th quadrature point. third_derivatives[q][i][j][k] represents the th component of the 3rd order tensor of third derivatives at quadrature point .
Note
The actual data type of the input vector may be either a Vector<T>, BlockVector<T>, or one of the PETSc or Trilinos vector wrapper classes. It represents a global vector of DoF values associated with the DoFHandler object with which this FEValues object was last initialized.
This function does the same as the other get_function_third_derivatives(), but applied to multi-component (vector- valued) elements. The meaning of the arguments is as explained there.
-
Postcondition
third_derivatives[q] is a vector of third derivatives of the field described by fe_function at the th quadrature point. The size of the vector accessed by third_derivatives[q] equals the number of components of the finite element, i.e. third_derivatives[q][c] returns the third derivative of the th vector component at the th quadrature point. Consequently, third_derivatives[q][c][i][j][k] is the th component of the tensor of third derivatives of the th vector component of the vector field at quadrature point of the current cell.
+
Postcondition
third_derivatives[q] is a vector of third derivatives of the field described by fe_function at the th quadrature point. The size of the vector accessed by third_derivatives[q] equals the number of components of the finite element, i.e. third_derivatives[q][c] returns the third derivative of the th vector component at the th quadrature point. Consequently, third_derivatives[q][c][i][j][k] is the th component of the tensor of third derivatives of the th vector component of the vector field at quadrature point of the current cell.
Mapped quadrature weight. If this object refers to a volume evaluation (i.e. the derived class is of type FEValues), then this is the Jacobi determinant times the weight of the q_pointth unit quadrature point.
For surface evaluations (i.e. classes FEFaceValues or FESubfaceValues), it is the mapped surface element times the weight of the quadrature point.
-
You can think of the quantity returned by this function as the volume or surface element in the integral that we implement here by quadrature.
+
You can think of the quantity returned by this function as the volume or surface element in the integral that we implement here by quadrature.
Return the second derivative of the transformation from unit to real cell, i.e. the first derivative of the Jacobian, at the specified quadrature point, i.e. .
+
Return the second derivative of the transformation from unit to real cell, i.e. the first derivative of the Jacobian, at the specified quadrature point, i.e. .
Return the second derivative of the transformation from unit to real cell, i.e. the first derivative of the Jacobian, at the specified quadrature point, pushed forward to the real cell coordinates, i.e. .
+
Return the second derivative of the transformation from unit to real cell, i.e. the first derivative of the Jacobian, at the specified quadrature point, pushed forward to the real cell coordinates, i.e. .
Note
For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_jacobian_pushed_forward_grads flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFEFaceValuesBase.html differs (JavaScript source, ASCII text, with very long lines (1019))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFEFaceValuesBase.html 2023-11-25 15:25:52.223379453 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFEFaceValuesBase.html 2023-11-25 15:25:52.223379453 +0100
@@ -675,7 +675,7 @@
If the shape function is vector-valued, then this returns the only non- zero component. If the shape function has more than one non-zero component (i.e. it is not primitive), then throw an exception of type ExcShapeFunctionNotPrimitive. In that case, use the shape_value_component() function.
Parameters
-
i
Number of the shape function to be evaluated. Note that this number runs from zero to dofs_per_cell, even in the case of an FEFaceValues or FESubfaceValues object.
+
i
Number of the shape function to be evaluated. Note that this number runs from zero to dofs_per_cell, even in the case of an FEFaceValues or FESubfaceValues object.
q_point
Number of the quadrature point at which function is to be evaluated
@@ -725,7 +725,7 @@
Compute one vector component of the value of a shape function at a quadrature point. If the finite element is scalar, then only component zero is allowed and the return value equals that of the shape_value() function. If the finite element is vector valued but all shape functions are primitive (i.e. they are non-zero in only one component), then the value returned by shape_value() equals that of this function for exactly one component. This function is therefore only of greater interest if the shape function is not primitive, but then it is necessary since the other function cannot be used.
Parameters
-
i
Number of the shape function to be evaluated.
+
i
Number of the shape function to be evaluated.
q_point
Number of the quadrature point at which function is to be evaluated.
component
vector component to be evaluated.
@@ -773,7 +773,7 @@
The same holds for the arguments of this function as for the shape_value() function.
Parameters
-
i
Number of the shape function to be evaluated.
+
i
Number of the shape function to be evaluated.
q_point
Number of the quadrature point at which function is to be evaluated.
@@ -1030,17 +1030,17 @@
-
Return the values of a finite element function at the quadrature points of the current cell, face, or subface (selected the last time the reinit() function was called). That is, if the first argument fe_function is a vector of nodal values of a finite element function defined on a DoFHandler object, then the output vector (the second argument, values) is the vector of values where are the quadrature points on the current cell . This function is first discussed in the Results section of step-4, and the related get_function_gradients() function is also used in step-15 along with numerous other tutorial programs.
+
Return the values of a finite element function at the quadrature points of the current cell, face, or subface (selected the last time the reinit() function was called). That is, if the first argument fe_function is a vector of nodal values of a finite element function defined on a DoFHandler object, then the output vector (the second argument, values) is the vector of values where are the quadrature points on the current cell . This function is first discussed in the Results section of step-4, and the related get_function_gradients() function is also used in step-15 along with numerous other tutorial programs.
If the current cell is not active (i.e., it has children), then the finite element function is, strictly speaking, defined by shape functions that live on these child cells. Rather than evaluating the shape functions on the child cells, with the quadrature points defined on the current cell, this function first interpolates the finite element function to shape functions defined on the current cell, and then evaluates this interpolated function.
This function may only be used if the finite element in use is a scalar one, i.e. has only one vector component. To get values of multi-component elements, there is another get_function_values() below, returning a vector of vectors of results.
Parameters
[in]
fe_function
A vector of values that describes (globally) the finite element function that this function should evaluate at the quadrature points of the current cell.
-
[out]
values
The values of the function specified by fe_function at the quadrature points of the current cell. The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the values of shape function times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument). This happens to be equal to the type of the elements of the solution vector.
+
[out]
values
The values of the function specified by fe_function at the quadrature points of the current cell. The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the values of shape function times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument). This happens to be equal to the type of the elements of the solution vector.
-
Postcondition
values[q] will contain the value of the field described by fe_function at the th quadrature point.
+
Postcondition
values[q] will contain the value of the field described by fe_function at the th quadrature point.
Note
The actual data type of the input vector may be either a Vector<T>, BlockVector<T>, or one of the PETSc or Trilinos vector wrapper classes. It represents a global vector of DoF values associated with the DoFHandler object with which this FEValues object was last initialized.
This function does the same as the other get_function_values(), but applied to multi-component (vector-valued) elements. The meaning of the arguments is as explained there.
-
Postcondition
values[q] is a vector of values of the field described by fe_function at the th quadrature point. The size of the vector accessed by values[q] equals the number of components of the finite element, i.e. values[q](c) returns the value of the th vector component at the th quadrature point.
+
Postcondition
values[q] is a vector of values of the field described by fe_function at the th quadrature point. The size of the vector accessed by values[q] equals the number of components of the finite element, i.e. values[q](c) returns the value of the th vector component at the th quadrature point.
Return the gradients of a finite element function at the quadrature points of the current cell, face, or subface (selected the last time the reinit() function was called). That is, if the first argument fe_function is a vector of nodal values of a finite element function defined on a DoFHandler object, then the output vector (the second argument, values) is the vector of values where are the quadrature points on the current cell . This function is first discussed in the Results section of step-4, and it is also used in step-15 along with numerous other tutorial programs.
+
Return the gradients of a finite element function at the quadrature points of the current cell, face, or subface (selected the last time the reinit() function was called). That is, if the first argument fe_function is a vector of nodal values of a finite element function defined on a DoFHandler object, then the output vector (the second argument, values) is the vector of values where are the quadrature points on the current cell . This function is first discussed in the Results section of step-4, and it is also used in step-15 along with numerous other tutorial programs.
This function may only be used if the finite element in use is a scalar one, i.e. has only one vector component. There is a corresponding function of the same name for vector-valued finite elements.
Parameters
[in]
fe_function
A vector of values that describes (globally) the finite element function that this function should evaluate at the quadrature points of the current cell.
-
[out]
gradients
The gradients of the function specified by fe_function at the quadrature points of the current cell. The gradients are computed in real space (as opposed to on the unit cell). The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the gradients of shape function times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
+
[out]
gradients
The gradients of the function specified by fe_function at the quadrature points of the current cell. The gradients are computed in real space (as opposed to on the unit cell). The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the gradients of shape function times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
-
Postcondition
gradients[q] will contain the gradient of the field described by fe_function at the th quadrature point. gradients[q][d] represents the derivative in coordinate direction at quadrature point .
+
Postcondition
gradients[q] will contain the gradient of the field described by fe_function at the th quadrature point. gradients[q][d] represents the derivative in coordinate direction at quadrature point .
Note
The actual data type of the input vector may be either a Vector<T>, BlockVector<T>, or one of the PETSc or Trilinos vector wrapper classes. It represents a global vector of DoF values associated with the DoFHandler object with which this FEValues object was last initialized.
This function does the same as the other get_function_gradients(), but applied to multi-component (vector-valued) elements. The meaning of the arguments is as explained there.
-
Postcondition
gradients[q] is a vector of gradients of the field described by fe_function at the th quadrature point. The size of the vector accessed by gradients[q] equals the number of components of the finite element, i.e. gradients[q][c] returns the gradient of the th vector component at the th quadrature point. Consequently, gradients[q][c][d] is the derivative in coordinate direction of the th vector component of the vector field at quadrature point of the current cell.
+
Postcondition
gradients[q] is a vector of gradients of the field described by fe_function at the th quadrature point. The size of the vector accessed by gradients[q] equals the number of components of the finite element, i.e. gradients[q][c] returns the gradient of the th vector component at the th quadrature point. Consequently, gradients[q][c][d] is the derivative in coordinate direction of the th vector component of the vector field at quadrature point of the current cell.
A vector of values that describes (globally) the finite element function that this function should evaluate at the quadrature points of the current cell.
-
[out]
hessians
The Hessians of the function specified by fe_function at the quadrature points of the current cell. The Hessians are computed in real space (as opposed to on the unit cell). The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the Hessians of shape function times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
+
[out]
hessians
The Hessians of the function specified by fe_function at the quadrature points of the current cell. The Hessians are computed in real space (as opposed to on the unit cell). The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the Hessians of shape function times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
-
Postcondition
hessians[q] will contain the Hessian of the field described by fe_function at the th quadrature point. hessians[q][i][j] represents the th component of the matrix of second derivatives at quadrature point .
+
Postcondition
hessians[q] will contain the Hessian of the field described by fe_function at the th quadrature point. hessians[q][i][j] represents the th component of the matrix of second derivatives at quadrature point .
Note
The actual data type of the input vector may be either a Vector<T>, BlockVector<T>, or one of the PETSc or Trilinos vector wrapper classes. It represents a global vector of DoF values associated with the DoFHandler object with which this FEValues object was last initialized.
This function does the same as the other get_function_hessians(), but applied to multi-component (vector-valued) elements. The meaning of the arguments is as explained there.
-
Postcondition
hessians[q] is a vector of Hessians of the field described by fe_function at the th quadrature point. The size of the vector accessed by hessians[q] equals the number of components of the finite element, i.e. hessians[q][c] returns the Hessian of the th vector component at the th quadrature point. Consequently, hessians[q][c][i][j] is the th component of the matrix of second derivatives of the th vector component of the vector field at quadrature point of the current cell.
+
Postcondition
hessians[q] is a vector of Hessians of the field described by fe_function at the th quadrature point. The size of the vector accessed by hessians[q] equals the number of components of the finite element, i.e. hessians[q][c] returns the Hessian of the th vector component at the th quadrature point. Consequently, hessians[q][c][i][j] is the th component of the matrix of second derivatives of the th vector component of the vector field at quadrature point of the current cell.
A vector of values that describes (globally) the finite element function that this function should evaluate at the quadrature points of the current cell.
-
[out]
laplacians
The Laplacians of the function specified by fe_function at the quadrature points of the current cell. The Laplacians are computed in real space (as opposed to on the unit cell). The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the Laplacians of shape function times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument). This happens to be equal to the type of the elements of the input vector.
+
[out]
laplacians
The Laplacians of the function specified by fe_function at the quadrature points of the current cell. The Laplacians are computed in real space (as opposed to on the unit cell). The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the Laplacians of shape function times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument). This happens to be equal to the type of the elements of the input vector.
-
Postcondition
laplacians[q] will contain the Laplacian of the field described by fe_function at the th quadrature point.
+
Postcondition
laplacians[q] will contain the Laplacian of the field described by fe_function at the th quadrature point.
For each component of the output vector, there holds laplacians[q]=trace(hessians[q]), where hessians would be the output of the get_function_hessians() function.
Note
The actual data type of the input vector may be either a Vector<T>, BlockVector<T>, or one of the PETSc or Trilinos vector wrapper classes. It represents a global vector of DoF values associated with the DoFHandler object with which this FEValues object was last initialized.
@@ -1749,7 +1749,7 @@
This function does the same as the other get_function_laplacians(), but applied to multi-component (vector-valued) elements. The meaning of the arguments is as explained there.
-
Postcondition
laplacians[q] is a vector of Laplacians of the field described by fe_function at the th quadrature point. The size of the vector accessed by laplacians[q] equals the number of components of the finite element, i.e. laplacians[q][c] returns the Laplacian of the th vector component at the th quadrature point.
+
Postcondition
laplacians[q] is a vector of Laplacians of the field described by fe_function at the th quadrature point. The size of the vector accessed by laplacians[q] equals the number of components of the finite element, i.e. laplacians[q][c] returns the Laplacian of the th vector component at the th quadrature point.
For each component of the output vector, there holds laplacians[q][c]=trace(hessians[q][c]), where hessians would be the output of the get_function_hessians() function.
A vector of values that describes (globally) the finite element function that this function should evaluate at the quadrature points of the current cell.
-
[out]
third_derivatives
The third derivatives of the function specified by fe_function at the quadrature points of the current cell. The third derivatives are computed in real space (as opposed to on the unit cell). The object is assumed to already have the correct size. The data type stored by this output vector must be what you get when you multiply the third derivatives of shape function times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
+
[out]
third_derivatives
The third derivatives of the function specified by fe_function at the quadrature points of the current cell. The third derivatives are computed in real space (as opposed to on the unit cell). The object is assumed to already have the correct size. The data type stored by this output vector must be what you get when you multiply the third derivatives of shape function times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
-
Postcondition
third_derivatives[q] will contain the third derivatives of the field described by fe_function at the th quadrature point. third_derivatives[q][i][j][k] represents the th component of the 3rd order tensor of third derivatives at quadrature point .
+
Postcondition
third_derivatives[q] will contain the third derivatives of the field described by fe_function at the th quadrature point. third_derivatives[q][i][j][k] represents the th component of the 3rd order tensor of third derivatives at quadrature point .
Note
The actual data type of the input vector may be either a Vector<T>, BlockVector<T>, or one of the PETSc or Trilinos vector wrapper classes. It represents a global vector of DoF values associated with the DoFHandler object with which this FEValues object was last initialized.
This function does the same as the other get_function_third_derivatives(), but applied to multi-component (vector- valued) elements. The meaning of the arguments is as explained there.
-
Postcondition
third_derivatives[q] is a vector of third derivatives of the field described by fe_function at the th quadrature point. The size of the vector accessed by third_derivatives[q] equals the number of components of the finite element, i.e. third_derivatives[q][c] returns the third derivative of the th vector component at the th quadrature point. Consequently, third_derivatives[q][c][i][j][k] is the th component of the tensor of third derivatives of the th vector component of the vector field at quadrature point of the current cell.
+
Postcondition
third_derivatives[q] is a vector of third derivatives of the field described by fe_function at the th quadrature point. The size of the vector accessed by third_derivatives[q] equals the number of components of the finite element, i.e. third_derivatives[q][c] returns the third derivative of the th vector component at the th quadrature point. Consequently, third_derivatives[q][c][i][j][k] is the th component of the tensor of third derivatives of the th vector component of the vector field at quadrature point of the current cell.
Mapped quadrature weight. If this object refers to a volume evaluation (i.e. the derived class is of type FEValues), then this is the Jacobi determinant times the weight of the q_pointth unit quadrature point.
For surface evaluations (i.e. classes FEFaceValues or FESubfaceValues), it is the mapped surface element times the weight of the quadrature point.
-
You can think of the quantity returned by this function as the volume or surface element in the integral that we implement here by quadrature.
+
You can think of the quantity returned by this function as the volume or surface element in the integral that we implement here by quadrature.
Return the second derivative of the transformation from unit to real cell, i.e. the first derivative of the Jacobian, at the specified quadrature point, i.e. .
+
Return the second derivative of the transformation from unit to real cell, i.e. the first derivative of the Jacobian, at the specified quadrature point, i.e. .
Return the second derivative of the transformation from unit to real cell, i.e. the first derivative of the Jacobian, at the specified quadrature point, pushed forward to the real cell coordinates, i.e. .
+
Return the second derivative of the transformation from unit to real cell, i.e. the first derivative of the Jacobian, at the specified quadrature point, pushed forward to the real cell coordinates, i.e. .
Note
For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_jacobian_pushed_forward_grads flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.
@@ -2591,7 +2591,7 @@
-
Return the third derivative of the transformation from unit to real cell, i.e. the second derivative of the Jacobian, at the specified quadrature point, i.e. .
+
Return the third derivative of the transformation from unit to real cell, i.e. the second derivative of the Jacobian, at the specified quadrature point, i.e. .
Note
For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_jacobian_2nd_derivatives flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFEInterfaceValues.html differs (JavaScript source, ASCII text, with very long lines (1222))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFEInterfaceValues.html 2023-11-25 15:25:52.250045575 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFEInterfaceValues.html 2023-11-25 15:25:52.250045575 +0100
@@ -523,8 +523,8 @@
If the q_index and mapping_index arguments to this function are explicitly specified (rather than leaving them at their default values), then these indices will be used to select which element of the hp::QCollection and hp::MappingCollection passed to the constructor should serve as the quadrature and mapping to be used.
If one of these arguments is left at its default value, then the function will need to choose a quadrature and/or mapping that is appropriate for the two finite element spaces used on the two cells adjacent to the current interface. As the first choice, if the quadrature or mapping collection we are considering has only one element, then that is clearly the one that should be used.
If the quadrature or mapping collection have multiple elements, then we need to dig further. For quadrature objects, we can compare whether the two quadrature objects that correspond to the active_fe_index values of the two adjacent cells are identical (i.e., have quadrature points at the same locations, and have the same weights). If this is so, then it does not matter which one of the two we take, and we choose one or the other.
-
If this has still not helped, we try to find out which of the two finite element spaces on the two adjacent cells is "larger" (say, if you had used and elements on the two adjacent cells, then the element is the larger one); the determination of which space is "larger" is made using the hp::FECollection::find_dominated_fe() function, which is not necessarily intended for this kind of query, but yields a result that serves just fine for our purposes here. We then operate on the assumption that the quadrature object associated with the "larger" of the two spaces is the appropriate one to use for the face that separates these two spaces.
-
If this function returns that one of the two elements in question is dominated by the other, then presumably it is "larger" one and we take the quadrature formula and mapping that corresponds to this "larger" element is. For example, for the element mentioned above, one would generally use a QGauss(3) quadrature formula, whereas for the element, one would use QGauss(5). To integrate jump and average terms on the interface between cells using these two elements, QGauss(5) is appropriate. Because, typically, people will order elements in the hp::FECollection in the same order as the quadrature and mapping objects in hp::QCollection and hp::MappingCollection, this function will use the index of the "larger" element in the hp::FECollection to also index into the hp::QCollection and hp::MappingCollection to retrieve quadrature and mapping objects appropriate for the current face.
+
If this has still not helped, we try to find out which of the two finite element spaces on the two adjacent cells is "larger" (say, if you had used and elements on the two adjacent cells, then the element is the larger one); the determination of which space is "larger" is made using the hp::FECollection::find_dominated_fe() function, which is not necessarily intended for this kind of query, but yields a result that serves just fine for our purposes here. We then operate on the assumption that the quadrature object associated with the "larger" of the two spaces is the appropriate one to use for the face that separates these two spaces.
+
If this function returns that one of the two elements in question is dominated by the other, then presumably it is "larger" one and we take the quadrature formula and mapping that corresponds to this "larger" element is. For example, for the element mentioned above, one would generally use a QGauss(3) quadrature formula, whereas for the element, one would use QGauss(5). To integrate jump and average terms on the interface between cells using these two elements, QGauss(5) is appropriate. Because, typically, people will order elements in the hp::FECollection in the same order as the quadrature and mapping objects in hp::QCollection and hp::MappingCollection, this function will use the index of the "larger" element in the hp::FECollection to also index into the hp::QCollection and hp::MappingCollection to retrieve quadrature and mapping objects appropriate for the current face.
There are cases where neither element dominates the other. For example, if one uses and elements on neighboring cells, neither of the two spaces dominates the other – or, in the context of the current function, neither space is "larger" than the other. In that case, there is no way for the current function to determine quadrature and mapping objects associated with the two elements are the appropriate ones. If that happens, you will get an error – and the only way to avoid the error is to explicitly specify for these interfaces which quadrature and mapping objects you want to use, by providing non-default values for the q_index and mapping_index arguments to this function.
@@ -865,7 +865,7 @@
Mapped quadrature weight. This value equals the mapped surface element times the weight of the quadrature point.
-
You can think of the quantity returned by this function as the surface element in the integral that we implement here by quadrature.
+
You can think of the quantity returned by this function as the surface element in the integral that we implement here by quadrature.
Return the jump on the interface for the shape function interface_dof_index at the quadrature point q_point of component component.
+
Return the jump on the interface for the shape function interface_dof_index at the quadrature point q_point of component component.
Note that one can define the jump in different ways (the value "there" minus the value "here", or the other way around; both are used in the finite element literature). The definition here uses "value here minus value there", as seen from the first cell.
-
If this is a boundary face (at_boundary() returns true), then , that is "the value here (minus zero)".
+
If this is a boundary face (at_boundary() returns true), then , that is "the value here (minus zero)".
Note
The name of the function is supposed to be read as "the jump
(singular) in the values (plural: one or two possible values)
of the shape function (singular)".
@@ -1225,9 +1225,9 @@
-
Return the jump in the gradient on the interface for the shape function interface_dof_index at the quadrature point q_point of component component.
-
If this is a boundary face (at_boundary() returns true), then .
+
Return the jump in the gradient on the interface for the shape function interface_dof_index at the quadrature point q_point of component component.
+
If this is a boundary face (at_boundary() returns true), then .
Note
The name of the function is supposed to be read as "the jump
(singular) in the gradients (plural: one or two possible gradients)
of the shape function (singular)".
@@ -1299,9 +1299,9 @@
-
Return the jump in the Hessian on the interface for the shape function interface_dof_index at the quadrature point q_point of component component.
-
If this is a boundary face (at_boundary() returns true), then .
+
Return the jump in the Hessian on the interface for the shape function interface_dof_index at the quadrature point q_point of component component.
+
If this is a boundary face (at_boundary() returns true), then .
Note
The name of the function is supposed to be read as "the jump
(singular) in the Hessians (plural: one or two possible values
for the derivative) of the shape function (singular)".
@@ -1373,9 +1373,9 @@
-
Return the jump in the third derivative on the interface for the shape function interface_dof_index at the quadrature point q_point of component component.
-
If this is a boundary face (at_boundary() returns true), then .
+
Return the jump in the third derivative on the interface for the shape function interface_dof_index at the quadrature point q_point of component component.
+
If this is a boundary face (at_boundary() returns true), then .
Note
The name of the function is supposed to be read as "the jump
(singular) in the third derivatives (plural: one or two possible values
for the derivative) of the shape function (singular)".
@@ -1447,9 +1447,9 @@
-
Return the average on the interface for the shape function interface_dof_index at the quadrature point q_point of component component.
-
If this is a boundary face (at_boundary() returns true), then .
+
Return the average on the interface for the shape function interface_dof_index at the quadrature point q_point of component component.
+
If this is a boundary face (at_boundary() returns true), then .
Note
The name of the function is supposed to be read as "the average
(singular) of the values (plural: one or two possible values)
of the shape function (singular)".
@@ -1521,9 +1521,9 @@
-
Return the average of the gradient on the interface for the shape function interface_dof_index at the quadrature point q_point of component component.
-
If this is a boundary face (at_boundary() returns true), then .
+
Return the average of the gradient on the interface for the shape function interface_dof_index at the quadrature point q_point of component component.
+
If this is a boundary face (at_boundary() returns true), then .
Note
The name of the function is supposed to be read as "the average
(singular) of the gradients (plural: one or two possible values
for the gradient) of the shape function (singular)".
@@ -1595,10 +1595,10 @@
-
Return the average of the Hessian on the interface for the shape function interface_dof_index at the quadrature point q_point of component component.
-
If this is a boundary face (at_boundary() returns true), then .
+u_{\text{cell1}}$" src="form_1094.png"/> on the interface for the shape function interface_dof_index at the quadrature point q_point of component component.
+
If this is a boundary face (at_boundary() returns true), then .
Note
The name of the function is supposed to be read as "the average
(singular) of the Hessians (plural: one or two possible values
for the second derivatives) of the shape function (singular)".
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFEInterfaceViews_1_1Scalar.html differs (JavaScript source, ASCII text, with very long lines (610))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFEInterfaceViews_1_1Scalar.html 2023-11-25 15:25:52.270045168 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFEInterfaceViews_1_1Scalar.html 2023-11-25 15:25:52.273378436 +0100
@@ -477,7 +477,7 @@
-
Return the jump on the interface for the shape function interface_dof_index in the quadrature point q_point of the component selected by this view.
+
Return the jump on the interface for the shape function interface_dof_index in the quadrature point q_point of the component selected by this view.
Note
The name of the function is supposed to be read as "the jump
(singular) in the values (plural: one or two possible values) of
the shape function (singular)".
@@ -539,7 +539,7 @@
-
Return the jump of the gradient on the interface for the shape function interface_dof_index in the quadrature point q_point of the component selected by this view.
+
Return the jump of the gradient on the interface for the shape function interface_dof_index in the quadrature point q_point of the component selected by this view.
Note
The name of the function is supposed to be read as "the jump
(singular) in the gradients (plural: one or two possible gradients)
of the shape function (singular)".
@@ -601,8 +601,8 @@
-
Return the jump in the gradient on the interface for the shape function interface_dof_index at the quadrature point q_point of the component selected by this view.
+
Return the jump in the gradient on the interface for the shape function interface_dof_index at the quadrature point q_point of the component selected by this view.
Note
The name of the function is supposed to be read as "the jump
(singular) in the Hessians (plural: one or two possible values
for the second derivative) of the shape function (singular)".
@@ -664,8 +664,8 @@
-
Return the jump in the third derivative on the interface for the shape function interface_dof_index at the quadrature point q_point of the component selected by this view.
+
Return the jump in the third derivative on the interface for the shape function interface_dof_index at the quadrature point q_point of the component selected by this view.
Note
The name of the function is supposed to be read as "the jump
(singular) in the third derivatives (plural: one or two possible values
for the third derivative) of the shape function (singular)".
@@ -727,7 +727,7 @@
-
Return the average value on the interface for the shape function interface_dof_index in the quadrature point q_point of the component selected by this view.
+
Return the average value on the interface for the shape function interface_dof_index in the quadrature point q_point of the component selected by this view.
Note
The name of the function is supposed to be read as "the average
(singular) of the values (plural: one or two possible values) of
the shape function (singular)".
@@ -819,7 +819,7 @@
-
Return the average of the gradient on the interface for the shape function interface_dof_index in the quadrature point q_point of the component selected by this view.
+
Return the average of the gradient on the interface for the shape function interface_dof_index in the quadrature point q_point of the component selected by this view.
Note
The name of the function is supposed to be read as "the average
(singular) of the gradients (plural: one or two possible values of
the derivative) of the shape function (singular)".
@@ -881,9 +881,9 @@
-
Return the average of the Hessian on the interface for the shape function interface_dof_index at the quadrature point q_point of the component selected by this view.
+u_{\text{cell1}}$" src="form_1094.png"/> on the interface for the shape function interface_dof_index at the quadrature point q_point of the component selected by this view.
Note
The name of the function is supposed to be read as "the average
(singular) in the Hessians (plural: one or two possible values of
the second derivative) of the shape function (singular)".
@@ -956,7 +956,7 @@
Return the values of the selected scalar component of the finite element function characterized by fe_function at the quadrature points of the cell interface selected the last time the reinit function of the FEInterfaceValues object was called.
The argument here_or_there selects between the value on cell 0 (here, true) and cell 1 (there, false). You can also interpret it as "upstream" (true) and "downstream" (false) as defined by the direction of the normal vector in this quadrature point. If here_or_there is true, the values from the first cell of the interface is used.
-
The data type stored by the output vector must be what you get when you multiply the values of shape functions (i.e., value_type) times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
+
The data type stored by the output vector must be what you get when you multiply the values of shape functions (i.e., value_type) times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
Return the jump in the values of the selected scalar component of the finite element function characterized by fe_function at the quadrature points of the cell interface selected the last time the reinit function of the FEInterfaceValues object was called.
-
The data type stored by the output vector must be what you get when you multiply the values of shape functions (i.e., value_type) times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
+
The data type stored by the output vector must be what you get when you multiply the values of shape functions (i.e., value_type) times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
Return the jump in the gradients of the selected scalar components of the finite element function characterized by fe_function at the quadrature points of the cell interface selected the last time the reinit function of the FEInterfaceValues object was called.
-
The data type stored by the output vector must be what you get when you multiply the gradients of shape functions (i.e., gradient_type) times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
+
The data type stored by the output vector must be what you get when you multiply the gradients of shape functions (i.e., gradient_type) times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
Return the jump in the Hessians of the selected scalar component of the finite element function characterized by fe_function at the quadrature points of the cell, face or subface selected the last time the reinit function of the FEInterfaceValues object was called.
-
The data type stored by the output vector must be what you get when you multiply the Hessians of shape functions (i.e., hessian_type) times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
+
The data type stored by the output vector must be what you get when you multiply the Hessians of shape functions (i.e., hessian_type) times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
Return the jump in the third derivatives of the selected scalar component of the finite element function characterized by fe_function at the quadrature points of the cell, face or subface selected the last time the reinit function of the FEInterfaceValues object was called.
-
The data type stored by the output vector must be what you get when you multiply the third derivatives of shape functions (i.e., third_derivative_type) times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
+
The data type stored by the output vector must be what you get when you multiply the third derivatives of shape functions (i.e., third_derivative_type) times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
Note
For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_third_derivatives flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.
@@ -1306,7 +1306,7 @@
Return the average of the values of the selected scalar component of the finite element function characterized by fe_function at the quadrature points of the cell interface selected the last time the reinit function of the FEInterfaceValues object was called.
-
The data type stored by the output vector must be what you get when you multiply the values of shape functions (i.e., value_type) times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
+
The data type stored by the output vector must be what you get when you multiply the values of shape functions (i.e., value_type) times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
Return the average of the gradients of the selected scalar components of the finite element function characterized by fe_function at the quadrature points of the cell interface selected the last time the reinit function of the FEInterfaceValues object was called.
-
The data type stored by the output vector must be what you get when you multiply the gradients of shape functions (i.e., gradient_type) times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
+
The data type stored by the output vector must be what you get when you multiply the gradients of shape functions (i.e., gradient_type) times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
Return the average of the Hessians of the selected scalar component of the finite element function characterized by fe_function at the quadrature points of the cell, face or subface selected the last time the reinit function of the FEInterfaceValues object was called.
-
The data type stored by the output vector must be what you get when you multiply the Hessians of shape functions (i.e., hessian_type) times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
+
The data type stored by the output vector must be what you get when you multiply the Hessians of shape functions (i.e., hessian_type) times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFEInterfaceViews_1_1Vector.html differs (JavaScript source, ASCII text, with very long lines (610))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFEInterfaceViews_1_1Vector.html 2023-11-25 15:25:52.293378028 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFEInterfaceViews_1_1Vector.html 2023-11-25 15:25:52.293378028 +0100
@@ -475,7 +475,7 @@
-
Return the jump vector on the interface for the shape function interface_dof_index in the quadrature point q_point.
+
Return the jump vector on the interface for the shape function interface_dof_index in the quadrature point q_point.
Note
The name of the function is supposed to be read as "the jump
(singular) in the values (plural: one or two possible values) of
the shape function (singular)".
@@ -537,8 +537,8 @@
-
Return the jump of the gradient (a tensor of rank 2) on the interface for the shape function interface_dof_index in the quadrature point q_point.
+
Return the jump of the gradient (a tensor of rank 2) on the interface for the shape function interface_dof_index in the quadrature point q_point.
Note
The name of the function is supposed to be read as "the jump
(singular) in the gradients (plural: one or two possible gradients)
of the shape function (singular)".
@@ -600,8 +600,8 @@
-
Return the jump in the gradient on the interface for the shape function interface_dof_index at the quadrature point q_point of the component selected by this view.
+
Return the jump in the gradient on the interface for the shape function interface_dof_index at the quadrature point q_point of the component selected by this view.
Note
The name of the function is supposed to be read as "the jump
(singular) in the Hessians (plural: one or two possible values
for the second derivative) of the shape function (singular)".
@@ -663,8 +663,8 @@
-
Return the jump in the third derivative on the interface for the shape function interface_dof_index at the quadrature point q_point of the component selected by this view.
+
Return the jump in the third derivative on the interface for the shape function interface_dof_index at the quadrature point q_point of the component selected by this view.
Note
The name of the function is supposed to be read as "the jump
(singular) in the third derivatives (plural: one or two possible values
for the third derivative) of the shape function (singular)".
@@ -726,8 +726,8 @@
-
Return the average vector on the interface for the shape function interface_dof_index in the quadrature point q_point.
+
Return the average vector on the interface for the shape function interface_dof_index in the quadrature point q_point.
Note
The name of the function is supposed to be read as "the average
(singular) of the values (plural: one or two possible values) of
the shape function (singular)".
@@ -789,8 +789,8 @@
-
Return the average of the gradient (a tensor of rank 2) on the interface for the shape function interface_dof_index in the quadrature point q_point.
+
Return the average of the gradient (a tensor of rank 2) on the interface for the shape function interface_dof_index in the quadrature point q_point.
Note
The name of the function is supposed to be read as "the average
(singular) of the gradients (plural: one or two possible values
of the derivative) of the shape function (singular)".
@@ -852,9 +852,9 @@
-
Return the average of the Hessian on the interface for the shape function interface_dof_index at the quadrature point q_point of the component selected by this view.
+u_{\text{cell1}}$" src="form_1094.png"/> on the interface for the shape function interface_dof_index at the quadrature point q_point of the component selected by this view.
Note
The name of the function is supposed to be read as "the average
(singular) in the Hessians (plural: one or two possible values of
the second derivative) of the shape function (singular)".
@@ -927,7 +927,7 @@
Return the values of the selected vector component of the finite element function characterized by fe_function at the quadrature points of the cell interface selected the last time the reinit function of the FEInterfaceValues object was called.
The argument here_or_there selects between the value on cell 0 (here, true) and cell 1 (there, false). You can also interpret it as "upstream" (true) and "downstream" (false) as defined by the direction of the normal vector in this quadrature point. If here_or_there is true, the values from the first cell of the interface is used.
-
The data type stored by the output vector must be what you get when you multiply the values of shape functions (i.e., value_type) times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
+
The data type stored by the output vector must be what you get when you multiply the values of shape functions (i.e., value_type) times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
Return the jump in the values of the selected vector component of the finite element function characterized by fe_function at the quadrature points of the cell interface selected the last time the reinit function of the FEInterfaceValues object was called.
-
The data type stored by the output vector must be what you get when you multiply the values of shape functions (i.e., value_type) times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
+
The data type stored by the output vector must be what you get when you multiply the values of shape functions (i.e., value_type) times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
Return the jump in the gradients of the selected vector components of the finite element function characterized by fe_function at the quadrature points of the cell interface selected the last time the reinit function of the FEInterfaceValues object was called.
-
The data type stored by the output vector must be what you get when you multiply the gradients of shape functions (i.e., gradient_type) times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
+
The data type stored by the output vector must be what you get when you multiply the gradients of shape functions (i.e., gradient_type) times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
Return the jump in the Hessians of the selected vector component of the finite element function characterized by fe_function at the quadrature points of the cell, face or subface selected the last time the reinit function of the FEInterfaceValues object was called.
-
The data type stored by the output vector must be what you get when you multiply the Hessians of shape functions (i.e., hessian_type) times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
+
The data type stored by the output vector must be what you get when you multiply the Hessians of shape functions (i.e., hessian_type) times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
Return the jump in the third derivatives of the selected vector component of the finite element function characterized by fe_function at the quadrature points of the cell, face or subface selected the last time the reinit function of the FEInterfaceValues object was called.
-
The data type stored by the output vector must be what you get when you multiply the third derivatives of shape functions (i.e., third_derivative_type) times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
+
The data type stored by the output vector must be what you get when you multiply the third derivatives of shape functions (i.e., third_derivative_type) times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
Note
For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_third_derivatives flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.
@@ -1277,7 +1277,7 @@
Return the average of the values of the selected vector component of the finite element function characterized by fe_function at the quadrature points of the cell interface selected the last time the reinit function of the FEInterfaceValues object was called.
-
The data type stored by the output vector must be what you get when you multiply the values of shape functions (i.e., value_type) times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
+
The data type stored by the output vector must be what you get when you multiply the values of shape functions (i.e., value_type) times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
Return the average of the gradients of the selected vector components of the finite element function characterized by fe_function at the quadrature points of the cell interface selected the last time the reinit function of the FEInterfaceValues object was called.
-
The data type stored by the output vector must be what you get when you multiply the gradients of shape functions (i.e., gradient_type) times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
+
The data type stored by the output vector must be what you get when you multiply the gradients of shape functions (i.e., gradient_type) times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
Return the average of the Hessians of the selected vector component of the finite element function characterized by fe_function at the quadrature points of the cell, face or subface selected the last time the reinit function of the FEInterfaceValues object was called.
-
The data type stored by the output vector must be what you get when you multiply the Hessians of shape functions (i.e., hessian_type) times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
+
The data type stored by the output vector must be what you get when you multiply the Hessians of shape functions (i.e., hessian_type) times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
A class to calculate expansion of a scalar FE (or a single component of vector-valued FE) field into Fourier series on a reference element. The exponential form of the Fourier series is based on completeness and Hermitian orthogonality of the set of exponential functions . For example in 1d the L2-orthogonality condition reads
-Fourier series on a reference element. The exponential form of the Fourier series is based on completeness and Hermitian orthogonality of the set of exponential functions . For example in 1d the L2-orthogonality condition reads
+
+\]" src="form_1176.png"/>
-
Note that .
+
Note that .
The arbitrary scalar FE field on the reference element can be expanded in the complete orthogonal exponential basis as
-
+\]" src="form_1178.png"/>
From the orthogonality property of the basis, it follows that
-
+\]" src="form_1179.png"/>
-
It is this complex-valued expansion coefficients, that are calculated by this class. Note that , where are real-valued FiniteElement shape functions. Consequently and we only need to compute for positive indices .
+
It is this complex-valued expansion coefficients, that are calculated by this class. Note that , where are real-valued FiniteElement shape functions. Consequently and we only need to compute for positive indices .
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFESeries_1_1Legendre.html differs (JavaScript source, ASCII text, with very long lines (1015))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFESeries_1_1Legendre.html 2023-11-25 15:25:52.330043949 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFESeries_1_1Legendre.html 2023-11-25 15:25:52.326710681 +0100
@@ -195,39 +195,39 @@
template<int dim, int spacedim = dim>
class FESeries::Legendre< dim, spacedim >
A class to calculate expansion of a scalar FE (or a single component of vector-valued FE) field into series of Legendre functions on a reference element.
Legendre functions are solutions to Legendre's differential equation
-
+\]" src="form_1185.png"/>
and can be expressed using Rodrigues' formula
-
+\]" src="form_1186.png"/>
-
These polynomials are orthogonal with respect to the inner product on the interval
- inner product on the interval
+
+\]" src="form_1189.png"/>
-
and are complete. A family of -orthogonal polynomials on can be constructed via
--orthogonal polynomials on can be constructed via
+
+\]" src="form_1191.png"/>
-
An arbitrary scalar FE field on the reference element can be expanded in the complete orthogonal basis as
- can be expanded in the complete orthogonal basis as
+
+\]" src="form_1192.png"/>
From the orthogonality property of the basis, it follows that
-
+\]" src="form_1193.png"/>
-
This class calculates coefficients using -dimensional Legendre polynomials constructed from using tensor product rule.
+
This class calculates coefficients using -dimensional Legendre polynomials constructed from using tensor product rule.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFESubfaceValues.html differs (JavaScript source, ASCII text, with very long lines (825))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFESubfaceValues.html 2023-11-25 15:25:52.370043135 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFESubfaceValues.html 2023-11-25 15:25:52.370043135 +0100
@@ -556,7 +556,7 @@
-
Constructor. This constructor is equivalent to the other one except that it makes the object use a mapping (i.e., an object of type MappingQ(1)) implicitly.
+
Constructor. This constructor is equivalent to the other one except that it makes the object use a mapping (i.e., an object of type MappingQ(1)) implicitly.
@@ -1033,7 +1033,7 @@
If the shape function is vector-valued, then this returns the only non- zero component. If the shape function has more than one non-zero component (i.e. it is not primitive), then throw an exception of type ExcShapeFunctionNotPrimitive. In that case, use the shape_value_component() function.
Parameters
-
i
Number of the shape function to be evaluated. Note that this number runs from zero to dofs_per_cell, even in the case of an FEFaceValues or FESubfaceValues object.
+
i
Number of the shape function to be evaluated. Note that this number runs from zero to dofs_per_cell, even in the case of an FEFaceValues or FESubfaceValues object.
q_point
Number of the quadrature point at which function is to be evaluated
@@ -1083,7 +1083,7 @@
Compute one vector component of the value of a shape function at a quadrature point. If the finite element is scalar, then only component zero is allowed and the return value equals that of the shape_value() function. If the finite element is vector valued but all shape functions are primitive (i.e. they are non-zero in only one component), then the value returned by shape_value() equals that of this function for exactly one component. This function is therefore only of greater interest if the shape function is not primitive, but then it is necessary since the other function cannot be used.
Parameters
-
i
Number of the shape function to be evaluated.
+
i
Number of the shape function to be evaluated.
q_point
Number of the quadrature point at which function is to be evaluated.
component
vector component to be evaluated.
@@ -1131,7 +1131,7 @@
The same holds for the arguments of this function as for the shape_value() function.
Parameters
-
i
Number of the shape function to be evaluated.
+
i
Number of the shape function to be evaluated.
q_point
Number of the quadrature point at which function is to be evaluated.
@@ -1388,17 +1388,17 @@
-
Return the values of a finite element function at the quadrature points of the current cell, face, or subface (selected the last time the reinit() function was called). That is, if the first argument fe_function is a vector of nodal values of a finite element function defined on a DoFHandler object, then the output vector (the second argument, values) is the vector of values where are the quadrature points on the current cell . This function is first discussed in the Results section of step-4, and the related get_function_gradients() function is also used in step-15 along with numerous other tutorial programs.
+
Return the values of a finite element function at the quadrature points of the current cell, face, or subface (selected the last time the reinit() function was called). That is, if the first argument fe_function is a vector of nodal values of a finite element function defined on a DoFHandler object, then the output vector (the second argument, values) is the vector of values where are the quadrature points on the current cell . This function is first discussed in the Results section of step-4, and the related get_function_gradients() function is also used in step-15 along with numerous other tutorial programs.
If the current cell is not active (i.e., it has children), then the finite element function is, strictly speaking, defined by shape functions that live on these child cells. Rather than evaluating the shape functions on the child cells, with the quadrature points defined on the current cell, this function first interpolates the finite element function to shape functions defined on the current cell, and then evaluates this interpolated function.
This function may only be used if the finite element in use is a scalar one, i.e. has only one vector component. To get values of multi-component elements, there is another get_function_values() below, returning a vector of vectors of results.
Parameters
[in]
fe_function
A vector of values that describes (globally) the finite element function that this function should evaluate at the quadrature points of the current cell.
-
[out]
values
The values of the function specified by fe_function at the quadrature points of the current cell. The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the values of shape function times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument). This happens to be equal to the type of the elements of the solution vector.
+
[out]
values
The values of the function specified by fe_function at the quadrature points of the current cell. The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the values of shape function times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument). This happens to be equal to the type of the elements of the solution vector.
-
Postcondition
values[q] will contain the value of the field described by fe_function at the th quadrature point.
+
Postcondition
values[q] will contain the value of the field described by fe_function at the th quadrature point.
Note
The actual data type of the input vector may be either a Vector<T>, BlockVector<T>, or one of the PETSc or Trilinos vector wrapper classes. It represents a global vector of DoF values associated with the DoFHandler object with which this FEValues object was last initialized.
This function does the same as the other get_function_values(), but applied to multi-component (vector-valued) elements. The meaning of the arguments is as explained there.
-
Postcondition
values[q] is a vector of values of the field described by fe_function at the th quadrature point. The size of the vector accessed by values[q] equals the number of components of the finite element, i.e. values[q](c) returns the value of the th vector component at the th quadrature point.
+
Postcondition
values[q] is a vector of values of the field described by fe_function at the th quadrature point. The size of the vector accessed by values[q] equals the number of components of the finite element, i.e. values[q](c) returns the value of the th vector component at the th quadrature point.
Return the gradients of a finite element function at the quadrature points of the current cell, face, or subface (selected the last time the reinit() function was called). That is, if the first argument fe_function is a vector of nodal values of a finite element function defined on a DoFHandler object, then the output vector (the second argument, values) is the vector of values where are the quadrature points on the current cell . This function is first discussed in the Results section of step-4, and it is also used in step-15 along with numerous other tutorial programs.
+
Return the gradients of a finite element function at the quadrature points of the current cell, face, or subface (selected the last time the reinit() function was called). That is, if the first argument fe_function is a vector of nodal values of a finite element function defined on a DoFHandler object, then the output vector (the second argument, values) is the vector of values where are the quadrature points on the current cell . This function is first discussed in the Results section of step-4, and it is also used in step-15 along with numerous other tutorial programs.
This function may only be used if the finite element in use is a scalar one, i.e. has only one vector component. There is a corresponding function of the same name for vector-valued finite elements.
Parameters
[in]
fe_function
A vector of values that describes (globally) the finite element function that this function should evaluate at the quadrature points of the current cell.
-
[out]
gradients
The gradients of the function specified by fe_function at the quadrature points of the current cell. The gradients are computed in real space (as opposed to on the unit cell). The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the gradients of shape function times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
+
[out]
gradients
The gradients of the function specified by fe_function at the quadrature points of the current cell. The gradients are computed in real space (as opposed to on the unit cell). The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the gradients of shape function times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
-
Postcondition
gradients[q] will contain the gradient of the field described by fe_function at the th quadrature point. gradients[q][d] represents the derivative in coordinate direction at quadrature point .
+
Postcondition
gradients[q] will contain the gradient of the field described by fe_function at the th quadrature point. gradients[q][d] represents the derivative in coordinate direction at quadrature point .
Note
The actual data type of the input vector may be either a Vector<T>, BlockVector<T>, or one of the PETSc or Trilinos vector wrapper classes. It represents a global vector of DoF values associated with the DoFHandler object with which this FEValues object was last initialized.
This function does the same as the other get_function_gradients(), but applied to multi-component (vector-valued) elements. The meaning of the arguments is as explained there.
-
Postcondition
gradients[q] is a vector of gradients of the field described by fe_function at the th quadrature point. The size of the vector accessed by gradients[q] equals the number of components of the finite element, i.e. gradients[q][c] returns the gradient of the th vector component at the th quadrature point. Consequently, gradients[q][c][d] is the derivative in coordinate direction of the th vector component of the vector field at quadrature point of the current cell.
+
Postcondition
gradients[q] is a vector of gradients of the field described by fe_function at the th quadrature point. The size of the vector accessed by gradients[q] equals the number of components of the finite element, i.e. gradients[q][c] returns the gradient of the th vector component at the th quadrature point. Consequently, gradients[q][c][d] is the derivative in coordinate direction of the th vector component of the vector field at quadrature point of the current cell.
A vector of values that describes (globally) the finite element function that this function should evaluate at the quadrature points of the current cell.
-
[out]
hessians
The Hessians of the function specified by fe_function at the quadrature points of the current cell. The Hessians are computed in real space (as opposed to on the unit cell). The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the Hessians of shape function times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
+
[out]
hessians
The Hessians of the function specified by fe_function at the quadrature points of the current cell. The Hessians are computed in real space (as opposed to on the unit cell). The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the Hessians of shape function times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
-
Postcondition
hessians[q] will contain the Hessian of the field described by fe_function at the th quadrature point. hessians[q][i][j] represents the th component of the matrix of second derivatives at quadrature point .
+
Postcondition
hessians[q] will contain the Hessian of the field described by fe_function at the th quadrature point. hessians[q][i][j] represents the th component of the matrix of second derivatives at quadrature point .
Note
The actual data type of the input vector may be either a Vector<T>, BlockVector<T>, or one of the PETSc or Trilinos vector wrapper classes. It represents a global vector of DoF values associated with the DoFHandler object with which this FEValues object was last initialized.
This function does the same as the other get_function_hessians(), but applied to multi-component (vector-valued) elements. The meaning of the arguments is as explained there.
-
Postcondition
hessians[q] is a vector of Hessians of the field described by fe_function at the th quadrature point. The size of the vector accessed by hessians[q] equals the number of components of the finite element, i.e. hessians[q][c] returns the Hessian of the th vector component at the th quadrature point. Consequently, hessians[q][c][i][j] is the th component of the matrix of second derivatives of the th vector component of the vector field at quadrature point of the current cell.
+
Postcondition
hessians[q] is a vector of Hessians of the field described by fe_function at the th quadrature point. The size of the vector accessed by hessians[q] equals the number of components of the finite element, i.e. hessians[q][c] returns the Hessian of the th vector component at the th quadrature point. Consequently, hessians[q][c][i][j] is the th component of the matrix of second derivatives of the th vector component of the vector field at quadrature point of the current cell.
A vector of values that describes (globally) the finite element function that this function should evaluate at the quadrature points of the current cell.
-
[out]
laplacians
The Laplacians of the function specified by fe_function at the quadrature points of the current cell. The Laplacians are computed in real space (as opposed to on the unit cell). The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the Laplacians of shape function times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument). This happens to be equal to the type of the elements of the input vector.
+
[out]
laplacians
The Laplacians of the function specified by fe_function at the quadrature points of the current cell. The Laplacians are computed in real space (as opposed to on the unit cell). The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the Laplacians of shape function times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument). This happens to be equal to the type of the elements of the input vector.
-
Postcondition
laplacians[q] will contain the Laplacian of the field described by fe_function at the th quadrature point.
+
Postcondition
laplacians[q] will contain the Laplacian of the field described by fe_function at the th quadrature point.
For each component of the output vector, there holds laplacians[q]=trace(hessians[q]), where hessians would be the output of the get_function_hessians() function.
Note
The actual data type of the input vector may be either a Vector<T>, BlockVector<T>, or one of the PETSc or Trilinos vector wrapper classes. It represents a global vector of DoF values associated with the DoFHandler object with which this FEValues object was last initialized.
@@ -2107,7 +2107,7 @@
This function does the same as the other get_function_laplacians(), but applied to multi-component (vector-valued) elements. The meaning of the arguments is as explained there.
-
Postcondition
laplacians[q] is a vector of Laplacians of the field described by fe_function at the th quadrature point. The size of the vector accessed by laplacians[q] equals the number of components of the finite element, i.e. laplacians[q][c] returns the Laplacian of the th vector component at the th quadrature point.
+
Postcondition
laplacians[q] is a vector of Laplacians of the field described by fe_function at the th quadrature point. The size of the vector accessed by laplacians[q] equals the number of components of the finite element, i.e. laplacians[q][c] returns the Laplacian of the th vector component at the th quadrature point.
For each component of the output vector, there holds laplacians[q][c]=trace(hessians[q][c]), where hessians would be the output of the get_function_hessians() function.
A vector of values that describes (globally) the finite element function that this function should evaluate at the quadrature points of the current cell.
-
[out]
third_derivatives
The third derivatives of the function specified by fe_function at the quadrature points of the current cell. The third derivatives are computed in real space (as opposed to on the unit cell). The object is assumed to already have the correct size. The data type stored by this output vector must be what you get when you multiply the third derivatives of shape function times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
+
[out]
third_derivatives
The third derivatives of the function specified by fe_function at the quadrature points of the current cell. The third derivatives are computed in real space (as opposed to on the unit cell). The object is assumed to already have the correct size. The data type stored by this output vector must be what you get when you multiply the third derivatives of shape function times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
-
Postcondition
third_derivatives[q] will contain the third derivatives of the field described by fe_function at the th quadrature point. third_derivatives[q][i][j][k] represents the th component of the 3rd order tensor of third derivatives at quadrature point .
+
Postcondition
third_derivatives[q] will contain the third derivatives of the field described by fe_function at the th quadrature point. third_derivatives[q][i][j][k] represents the th component of the 3rd order tensor of third derivatives at quadrature point .
Note
The actual data type of the input vector may be either a Vector<T>, BlockVector<T>, or one of the PETSc or Trilinos vector wrapper classes. It represents a global vector of DoF values associated with the DoFHandler object with which this FEValues object was last initialized.
This function does the same as the other get_function_third_derivatives(), but applied to multi-component (vector- valued) elements. The meaning of the arguments is as explained there.
-
Postcondition
third_derivatives[q] is a vector of third derivatives of the field described by fe_function at the th quadrature point. The size of the vector accessed by third_derivatives[q] equals the number of components of the finite element, i.e. third_derivatives[q][c] returns the third derivative of the th vector component at the th quadrature point. Consequently, third_derivatives[q][c][i][j][k] is the th component of the tensor of third derivatives of the th vector component of the vector field at quadrature point of the current cell.
+
Postcondition
third_derivatives[q] is a vector of third derivatives of the field described by fe_function at the th quadrature point. The size of the vector accessed by third_derivatives[q] equals the number of components of the finite element, i.e. third_derivatives[q][c] returns the third derivative of the th vector component at the th quadrature point. Consequently, third_derivatives[q][c][i][j][k] is the th component of the tensor of third derivatives of the th vector component of the vector field at quadrature point of the current cell.
Mapped quadrature weight. If this object refers to a volume evaluation (i.e. the derived class is of type FEValues), then this is the Jacobi determinant times the weight of the q_pointth unit quadrature point.
For surface evaluations (i.e. classes FEFaceValues or FESubfaceValues), it is the mapped surface element times the weight of the quadrature point.
-
You can think of the quantity returned by this function as the volume or surface element in the integral that we implement here by quadrature.
+
You can think of the quantity returned by this function as the volume or surface element in the integral that we implement here by quadrature.
Return the second derivative of the transformation from unit to real cell, i.e. the first derivative of the Jacobian, at the specified quadrature point, i.e. .
+
Return the second derivative of the transformation from unit to real cell, i.e. the first derivative of the Jacobian, at the specified quadrature point, i.e. .
Return the second derivative of the transformation from unit to real cell, i.e. the first derivative of the Jacobian, at the specified quadrature point, pushed forward to the real cell coordinates, i.e. .
+
Return the second derivative of the transformation from unit to real cell, i.e. the first derivative of the Jacobian, at the specified quadrature point, pushed forward to the real cell coordinates, i.e. .
Note
For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_jacobian_pushed_forward_grads flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFESystem.html differs (JavaScript source, ASCII text, with very long lines (1148))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFESystem.html 2023-11-25 15:25:52.430041914 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFESystem.html 2023-11-25 15:25:52.430041914 +0100
@@ -499,31 +499,31 @@
This class provides an interface to group several elements together into one, vector-valued element. As example, consider the Taylor-Hood element that is used for the solution of the Stokes and Navier-Stokes equations: There, the velocity (of which there are as many components as the dimension of the domain) is discretized with elements and the pressure with elements. Mathematically, the finite element space for the coupled problem is then often written as where the exponentiation is understood to be the tensor product of spaces – i.e., in 2d, we have – and tensor products lead to vectors where each component of the vector-valued function space corresponds to a scalar function in one of the or spaces. Using the FESystem class, this space is created using
This class provides an interface to group several elements together into one, vector-valued element. As example, consider the Taylor-Hood element that is used for the solution of the Stokes and Navier-Stokes equations: There, the velocity (of which there are as many components as the dimension of the domain) is discretized with elements and the pressure with elements. Mathematically, the finite element space for the coupled problem is then often written as where the exponentiation is understood to be the tensor product of spaces – i.e., in 2d, we have – and tensor products lead to vectors where each component of the vector-valued function space corresponds to a scalar function in one of the or spaces. Using the FESystem class, this space is created using
The creation of this element here corresponds to taking tensor-product powers of the element in the first line of the list of arguments to the FESystem constructor, and then concatenation via another tensor product with the element in the second line. This kind of construction is used, for example, in the step-22 tutorial program.
-
Similarly, step-8 solves an elasticity equation where we need to solve for the displacement of a solid object. The displacement again has components if the domain is -dimensional, and so the combined finite element is created using
where now each (vector) component of the combined element corresponds to a space.
+
The creation of this element here corresponds to taking tensor-product powers of the element in the first line of the list of arguments to the FESystem constructor, and then concatenation via another tensor product with the element in the second line. This kind of construction is used, for example, in the step-22 tutorial program.
+
Similarly, step-8 solves an elasticity equation where we need to solve for the displacement of a solid object. The displacement again has components if the domain is -dimensional, and so the combined finite element is created using
where now each (vector) component of the combined element corresponds to a space.
To the outside world, FESystem objects look just like a usual finite element object, they just happen to be composed of several other finite elements that are possibly of different type. These "base elements" can themselves have multiple components and, in particular, could also be vector-valued – for example, if one of the base elements is an FESystem itself (see also below). An example is given in the documentation of namespace FETools::Compositing, when using the "tensor product" strategy.
An FESystem, except in the most trivial case, produces a vector-valued finite element with several components. The number of components n_components() corresponds to the dimension of the solution function in the PDE system, and correspondingly also to the number of equations your PDE system has. For example, the mixed Laplace system covered in step-20 has components in space dimensions: the scalar pressure and the components of the velocity vector. Similarly, the elasticity equation covered in step-8 has components in space dimensions. In general, the number of components of a FESystem element is the accumulated number of components of all base elements times their multiplicities. A bit more on components is also given in the glossary entry on components.
+
An FESystem, except in the most trivial case, produces a vector-valued finite element with several components. The number of components n_components() corresponds to the dimension of the solution function in the PDE system, and correspondingly also to the number of equations your PDE system has. For example, the mixed Laplace system covered in step-20 has components in space dimensions: the scalar pressure and the components of the velocity vector. Similarly, the elasticity equation covered in step-8 has components in space dimensions. In general, the number of components of a FESystem element is the accumulated number of components of all base elements times their multiplicities. A bit more on components is also given in the glossary entry on components.
While the concept of components is important from the viewpoint of a partial differential equation, the finite element side looks a bit different Since not only FESystem, but also vector-valued elements like FE_RaviartThomas, have several components. The concept needed here is a block. Each block encompasses the set of degrees of freedom associated with a single base element of an FESystem, where base elements with multiplicities count multiple times. These blocks are usually addressed using the information in DoFHandler::block_info(). The number of blocks of a FESystem object is simply the sum of all multiplicities of base elements and is given by n_blocks().
For example, the FESystem for the Taylor-Hood element for the three-dimensional Stokes problem can be built using the code
This example creates an FESystemsys1 with four components, three for the velocity components and one for the pressure, and also four blocks with the degrees of freedom of each of the velocity components and the pressure in a separate block each. The number of blocks is four since the first base element is repeated three times.
On the other hand, a Taylor-Hood element can also be constructed using
The FESystemsys2 created here has the same four components, but the degrees of freedom are distributed into only two blocks. The first block has all velocity degrees of freedom from U, while the second block contains the pressure degrees of freedom. Note that while U itself has 3 blocks, the FESystemsys2 does not attempt to split U into its base elements but considers it a block of its own. By blocking all velocities into one system first as in sys2, we achieve the same block structure that would be generated if instead of using a element for the velocities we had used vector-valued base elements, for instance like using a mixed discretization of Darcy's law using
+
The FESystemsys2 created here has the same four components, but the degrees of freedom are distributed into only two blocks. The first block has all velocity degrees of freedom from U, while the second block contains the pressure degrees of freedom. Note that while U itself has 3 blocks, the FESystemsys2 does not attempt to split U into its base elements but considers it a block of its own. By blocking all velocities into one system first as in sys2, we achieve the same block structure that would be generated if instead of using a element for the velocities we had used vector-valued base elements, for instance like using a mixed discretization of Darcy's law using
Return a block mask with as many elements as this object has blocks and of which exactly the one component is true that corresponds to the given argument. See the glossary for more information.
-
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
scalar
An object that represents a single scalar vector component of this finite element.
@@ -4305,7 +4305,7 @@
Given a component mask (see this glossary entry), produce a block mask (see this glossary entry) that represents the blocks that correspond to the components selected in the input argument. This is essentially a conversion operator from ComponentMask to BlockMask.
-
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
component_mask
The mask that selects individual components of the finite element
@@ -4464,7 +4464,7 @@
Return a vector of generalized support points.
-
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
+
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
For a given degree of freedom, return whether it is logically associated with a vertex, line, quad or hex.
-
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
-
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
-
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
+
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
+
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
+
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
Parameters
[in]
cell_dof_index
The index of a shape function or degree of freedom. This index must be in the range [0,dofs_per_cell).
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFEValues.html differs (JavaScript source, ASCII text, with very long lines (858))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFEValues.html 2023-11-25 15:25:52.470041100 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFEValues.html 2023-11-25 15:25:52.470041100 +0100
@@ -538,7 +538,7 @@
-
Constructor. This constructor is equivalent to the other one except that it makes the object use a mapping (i.e., an object of type MappingQ(1)) implicitly.
+
Constructor. This constructor is equivalent to the other one except that it makes the object use a mapping (i.e., an object of type MappingQ(1)) implicitly.
@@ -776,7 +776,7 @@
If the shape function is vector-valued, then this returns the only non- zero component. If the shape function has more than one non-zero component (i.e. it is not primitive), then throw an exception of type ExcShapeFunctionNotPrimitive. In that case, use the shape_value_component() function.
Parameters
-
i
Number of the shape function to be evaluated. Note that this number runs from zero to dofs_per_cell, even in the case of an FEFaceValues or FESubfaceValues object.
+
i
Number of the shape function to be evaluated. Note that this number runs from zero to dofs_per_cell, even in the case of an FEFaceValues or FESubfaceValues object.
q_point
Number of the quadrature point at which function is to be evaluated
@@ -826,7 +826,7 @@
Compute one vector component of the value of a shape function at a quadrature point. If the finite element is scalar, then only component zero is allowed and the return value equals that of the shape_value() function. If the finite element is vector valued but all shape functions are primitive (i.e. they are non-zero in only one component), then the value returned by shape_value() equals that of this function for exactly one component. This function is therefore only of greater interest if the shape function is not primitive, but then it is necessary since the other function cannot be used.
Parameters
-
i
Number of the shape function to be evaluated.
+
i
Number of the shape function to be evaluated.
q_point
Number of the quadrature point at which function is to be evaluated.
component
vector component to be evaluated.
@@ -874,7 +874,7 @@
The same holds for the arguments of this function as for the shape_value() function.
Parameters
-
i
Number of the shape function to be evaluated.
+
i
Number of the shape function to be evaluated.
q_point
Number of the quadrature point at which function is to be evaluated.
@@ -1131,17 +1131,17 @@
-
Return the values of a finite element function at the quadrature points of the current cell, face, or subface (selected the last time the reinit() function was called). That is, if the first argument fe_function is a vector of nodal values of a finite element function defined on a DoFHandler object, then the output vector (the second argument, values) is the vector of values where are the quadrature points on the current cell . This function is first discussed in the Results section of step-4, and the related get_function_gradients() function is also used in step-15 along with numerous other tutorial programs.
+
Return the values of a finite element function at the quadrature points of the current cell, face, or subface (selected the last time the reinit() function was called). That is, if the first argument fe_function is a vector of nodal values of a finite element function defined on a DoFHandler object, then the output vector (the second argument, values) is the vector of values where are the quadrature points on the current cell . This function is first discussed in the Results section of step-4, and the related get_function_gradients() function is also used in step-15 along with numerous other tutorial programs.
If the current cell is not active (i.e., it has children), then the finite element function is, strictly speaking, defined by shape functions that live on these child cells. Rather than evaluating the shape functions on the child cells, with the quadrature points defined on the current cell, this function first interpolates the finite element function to shape functions defined on the current cell, and then evaluates this interpolated function.
This function may only be used if the finite element in use is a scalar one, i.e. has only one vector component. To get values of multi-component elements, there is another get_function_values() below, returning a vector of vectors of results.
Parameters
[in]
fe_function
A vector of values that describes (globally) the finite element function that this function should evaluate at the quadrature points of the current cell.
-
[out]
values
The values of the function specified by fe_function at the quadrature points of the current cell. The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the values of shape function times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument). This happens to be equal to the type of the elements of the solution vector.
+
[out]
values
The values of the function specified by fe_function at the quadrature points of the current cell. The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the values of shape function times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument). This happens to be equal to the type of the elements of the solution vector.
-
Postcondition
values[q] will contain the value of the field described by fe_function at the th quadrature point.
+
Postcondition
values[q] will contain the value of the field described by fe_function at the th quadrature point.
Note
The actual data type of the input vector may be either a Vector<T>, BlockVector<T>, or one of the PETSc or Trilinos vector wrapper classes. It represents a global vector of DoF values associated with the DoFHandler object with which this FEValues object was last initialized.
This function does the same as the other get_function_values(), but applied to multi-component (vector-valued) elements. The meaning of the arguments is as explained there.
-
Postcondition
values[q] is a vector of values of the field described by fe_function at the th quadrature point. The size of the vector accessed by values[q] equals the number of components of the finite element, i.e. values[q](c) returns the value of the th vector component at the th quadrature point.
+
Postcondition
values[q] is a vector of values of the field described by fe_function at the th quadrature point. The size of the vector accessed by values[q] equals the number of components of the finite element, i.e. values[q](c) returns the value of the th vector component at the th quadrature point.
Return the gradients of a finite element function at the quadrature points of the current cell, face, or subface (selected the last time the reinit() function was called). That is, if the first argument fe_function is a vector of nodal values of a finite element function defined on a DoFHandler object, then the output vector (the second argument, values) is the vector of values where are the quadrature points on the current cell . This function is first discussed in the Results section of step-4, and it is also used in step-15 along with numerous other tutorial programs.
+
Return the gradients of a finite element function at the quadrature points of the current cell, face, or subface (selected the last time the reinit() function was called). That is, if the first argument fe_function is a vector of nodal values of a finite element function defined on a DoFHandler object, then the output vector (the second argument, values) is the vector of values where are the quadrature points on the current cell . This function is first discussed in the Results section of step-4, and it is also used in step-15 along with numerous other tutorial programs.
This function may only be used if the finite element in use is a scalar one, i.e. has only one vector component. There is a corresponding function of the same name for vector-valued finite elements.
Parameters
[in]
fe_function
A vector of values that describes (globally) the finite element function that this function should evaluate at the quadrature points of the current cell.
-
[out]
gradients
The gradients of the function specified by fe_function at the quadrature points of the current cell. The gradients are computed in real space (as opposed to on the unit cell). The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the gradients of shape function times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
+
[out]
gradients
The gradients of the function specified by fe_function at the quadrature points of the current cell. The gradients are computed in real space (as opposed to on the unit cell). The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the gradients of shape function times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
-
Postcondition
gradients[q] will contain the gradient of the field described by fe_function at the th quadrature point. gradients[q][d] represents the derivative in coordinate direction at quadrature point .
+
Postcondition
gradients[q] will contain the gradient of the field described by fe_function at the th quadrature point. gradients[q][d] represents the derivative in coordinate direction at quadrature point .
Note
The actual data type of the input vector may be either a Vector<T>, BlockVector<T>, or one of the PETSc or Trilinos vector wrapper classes. It represents a global vector of DoF values associated with the DoFHandler object with which this FEValues object was last initialized.
This function does the same as the other get_function_gradients(), but applied to multi-component (vector-valued) elements. The meaning of the arguments is as explained there.
-
Postcondition
gradients[q] is a vector of gradients of the field described by fe_function at the th quadrature point. The size of the vector accessed by gradients[q] equals the number of components of the finite element, i.e. gradients[q][c] returns the gradient of the th vector component at the th quadrature point. Consequently, gradients[q][c][d] is the derivative in coordinate direction of the th vector component of the vector field at quadrature point of the current cell.
+
Postcondition
gradients[q] is a vector of gradients of the field described by fe_function at the th quadrature point. The size of the vector accessed by gradients[q] equals the number of components of the finite element, i.e. gradients[q][c] returns the gradient of the th vector component at the th quadrature point. Consequently, gradients[q][c][d] is the derivative in coordinate direction of the th vector component of the vector field at quadrature point of the current cell.
A vector of values that describes (globally) the finite element function that this function should evaluate at the quadrature points of the current cell.
-
[out]
hessians
The Hessians of the function specified by fe_function at the quadrature points of the current cell. The Hessians are computed in real space (as opposed to on the unit cell). The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the Hessians of shape function times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
+
[out]
hessians
The Hessians of the function specified by fe_function at the quadrature points of the current cell. The Hessians are computed in real space (as opposed to on the unit cell). The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the Hessians of shape function times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
-
Postcondition
hessians[q] will contain the Hessian of the field described by fe_function at the th quadrature point. hessians[q][i][j] represents the th component of the matrix of second derivatives at quadrature point .
+
Postcondition
hessians[q] will contain the Hessian of the field described by fe_function at the th quadrature point. hessians[q][i][j] represents the th component of the matrix of second derivatives at quadrature point .
Note
The actual data type of the input vector may be either a Vector<T>, BlockVector<T>, or one of the PETSc or Trilinos vector wrapper classes. It represents a global vector of DoF values associated with the DoFHandler object with which this FEValues object was last initialized.
This function does the same as the other get_function_hessians(), but applied to multi-component (vector-valued) elements. The meaning of the arguments is as explained there.
-
Postcondition
hessians[q] is a vector of Hessians of the field described by fe_function at the th quadrature point. The size of the vector accessed by hessians[q] equals the number of components of the finite element, i.e. hessians[q][c] returns the Hessian of the th vector component at the th quadrature point. Consequently, hessians[q][c][i][j] is the th component of the matrix of second derivatives of the th vector component of the vector field at quadrature point of the current cell.
+
Postcondition
hessians[q] is a vector of Hessians of the field described by fe_function at the th quadrature point. The size of the vector accessed by hessians[q] equals the number of components of the finite element, i.e. hessians[q][c] returns the Hessian of the th vector component at the th quadrature point. Consequently, hessians[q][c][i][j] is the th component of the matrix of second derivatives of the th vector component of the vector field at quadrature point of the current cell.
A vector of values that describes (globally) the finite element function that this function should evaluate at the quadrature points of the current cell.
-
[out]
laplacians
The Laplacians of the function specified by fe_function at the quadrature points of the current cell. The Laplacians are computed in real space (as opposed to on the unit cell). The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the Laplacians of shape function times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument). This happens to be equal to the type of the elements of the input vector.
+
[out]
laplacians
The Laplacians of the function specified by fe_function at the quadrature points of the current cell. The Laplacians are computed in real space (as opposed to on the unit cell). The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the Laplacians of shape function times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument). This happens to be equal to the type of the elements of the input vector.
-
Postcondition
laplacians[q] will contain the Laplacian of the field described by fe_function at the th quadrature point.
+
Postcondition
laplacians[q] will contain the Laplacian of the field described by fe_function at the th quadrature point.
For each component of the output vector, there holds laplacians[q]=trace(hessians[q]), where hessians would be the output of the get_function_hessians() function.
Note
The actual data type of the input vector may be either a Vector<T>, BlockVector<T>, or one of the PETSc or Trilinos vector wrapper classes. It represents a global vector of DoF values associated with the DoFHandler object with which this FEValues object was last initialized.
@@ -1850,7 +1850,7 @@
This function does the same as the other get_function_laplacians(), but applied to multi-component (vector-valued) elements. The meaning of the arguments is as explained there.
-
Postcondition
laplacians[q] is a vector of Laplacians of the field described by fe_function at the th quadrature point. The size of the vector accessed by laplacians[q] equals the number of components of the finite element, i.e. laplacians[q][c] returns the Laplacian of the th vector component at the th quadrature point.
+
Postcondition
laplacians[q] is a vector of Laplacians of the field described by fe_function at the th quadrature point. The size of the vector accessed by laplacians[q] equals the number of components of the finite element, i.e. laplacians[q][c] returns the Laplacian of the th vector component at the th quadrature point.
For each component of the output vector, there holds laplacians[q][c]=trace(hessians[q][c]), where hessians would be the output of the get_function_hessians() function.
A vector of values that describes (globally) the finite element function that this function should evaluate at the quadrature points of the current cell.
-
[out]
third_derivatives
The third derivatives of the function specified by fe_function at the quadrature points of the current cell. The third derivatives are computed in real space (as opposed to on the unit cell). The object is assumed to already have the correct size. The data type stored by this output vector must be what you get when you multiply the third derivatives of shape function times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
+
[out]
third_derivatives
The third derivatives of the function specified by fe_function at the quadrature points of the current cell. The third derivatives are computed in real space (as opposed to on the unit cell). The object is assumed to already have the correct size. The data type stored by this output vector must be what you get when you multiply the third derivatives of shape function times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
-
Postcondition
third_derivatives[q] will contain the third derivatives of the field described by fe_function at the th quadrature point. third_derivatives[q][i][j][k] represents the th component of the 3rd order tensor of third derivatives at quadrature point .
+
Postcondition
third_derivatives[q] will contain the third derivatives of the field described by fe_function at the th quadrature point. third_derivatives[q][i][j][k] represents the th component of the 3rd order tensor of third derivatives at quadrature point .
Note
The actual data type of the input vector may be either a Vector<T>, BlockVector<T>, or one of the PETSc or Trilinos vector wrapper classes. It represents a global vector of DoF values associated with the DoFHandler object with which this FEValues object was last initialized.
This function does the same as the other get_function_third_derivatives(), but applied to multi-component (vector- valued) elements. The meaning of the arguments is as explained there.
-
Postcondition
third_derivatives[q] is a vector of third derivatives of the field described by fe_function at the th quadrature point. The size of the vector accessed by third_derivatives[q] equals the number of components of the finite element, i.e. third_derivatives[q][c] returns the third derivative of the th vector component at the th quadrature point. Consequently, third_derivatives[q][c][i][j][k] is the th component of the tensor of third derivatives of the th vector component of the vector field at quadrature point of the current cell.
+
Postcondition
third_derivatives[q] is a vector of third derivatives of the field described by fe_function at the th quadrature point. The size of the vector accessed by third_derivatives[q] equals the number of components of the finite element, i.e. third_derivatives[q][c] returns the third derivative of the th vector component at the th quadrature point. Consequently, third_derivatives[q][c][i][j][k] is the th component of the tensor of third derivatives of the th vector component of the vector field at quadrature point of the current cell.
Mapped quadrature weight. If this object refers to a volume evaluation (i.e. the derived class is of type FEValues), then this is the Jacobi determinant times the weight of the q_pointth unit quadrature point.
For surface evaluations (i.e. classes FEFaceValues or FESubfaceValues), it is the mapped surface element times the weight of the quadrature point.
-
You can think of the quantity returned by this function as the volume or surface element in the integral that we implement here by quadrature.
+
You can think of the quantity returned by this function as the volume or surface element in the integral that we implement here by quadrature.
Return the second derivative of the transformation from unit to real cell, i.e. the first derivative of the Jacobian, at the specified quadrature point, i.e. .
+
Return the second derivative of the transformation from unit to real cell, i.e. the first derivative of the Jacobian, at the specified quadrature point, i.e. .
Return the second derivative of the transformation from unit to real cell, i.e. the first derivative of the Jacobian, at the specified quadrature point, pushed forward to the real cell coordinates, i.e. .
+
Return the second derivative of the transformation from unit to real cell, i.e. the first derivative of the Jacobian, at the specified quadrature point, pushed forward to the real cell coordinates, i.e. .
Note
For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_jacobian_pushed_forward_grads flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFEValuesBase.html differs (JavaScript source, ASCII text, with very long lines (908))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFEValuesBase.html 2023-11-25 15:25:52.510040284 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFEValuesBase.html 2023-11-25 15:25:52.510040284 +0100
@@ -627,7 +627,7 @@
If the shape function is vector-valued, then this returns the only non- zero component. If the shape function has more than one non-zero component (i.e. it is not primitive), then throw an exception of type ExcShapeFunctionNotPrimitive. In that case, use the shape_value_component() function.
Parameters
-
i
Number of the shape function to be evaluated. Note that this number runs from zero to dofs_per_cell, even in the case of an FEFaceValues or FESubfaceValues object.
+
i
Number of the shape function to be evaluated. Note that this number runs from zero to dofs_per_cell, even in the case of an FEFaceValues or FESubfaceValues object.
q_point
Number of the quadrature point at which function is to be evaluated
@@ -669,7 +669,7 @@
Compute one vector component of the value of a shape function at a quadrature point. If the finite element is scalar, then only component zero is allowed and the return value equals that of the shape_value() function. If the finite element is vector valued but all shape functions are primitive (i.e. they are non-zero in only one component), then the value returned by shape_value() equals that of this function for exactly one component. This function is therefore only of greater interest if the shape function is not primitive, but then it is necessary since the other function cannot be used.
Parameters
-
i
Number of the shape function to be evaluated.
+
i
Number of the shape function to be evaluated.
q_point
Number of the quadrature point at which function is to be evaluated.
component
vector component to be evaluated.
@@ -709,7 +709,7 @@
The same holds for the arguments of this function as for the shape_value() function.
Parameters
-
i
Number of the shape function to be evaluated.
+
i
Number of the shape function to be evaluated.
q_point
Number of the quadrature point at which function is to be evaluated.
@@ -918,17 +918,17 @@
-
Return the values of a finite element function at the quadrature points of the current cell, face, or subface (selected the last time the reinit() function was called). That is, if the first argument fe_function is a vector of nodal values of a finite element function defined on a DoFHandler object, then the output vector (the second argument, values) is the vector of values where are the quadrature points on the current cell . This function is first discussed in the Results section of step-4, and the related get_function_gradients() function is also used in step-15 along with numerous other tutorial programs.
+
Return the values of a finite element function at the quadrature points of the current cell, face, or subface (selected the last time the reinit() function was called). That is, if the first argument fe_function is a vector of nodal values of a finite element function defined on a DoFHandler object, then the output vector (the second argument, values) is the vector of values where are the quadrature points on the current cell . This function is first discussed in the Results section of step-4, and the related get_function_gradients() function is also used in step-15 along with numerous other tutorial programs.
If the current cell is not active (i.e., it has children), then the finite element function is, strictly speaking, defined by shape functions that live on these child cells. Rather than evaluating the shape functions on the child cells, with the quadrature points defined on the current cell, this function first interpolates the finite element function to shape functions defined on the current cell, and then evaluates this interpolated function.
This function may only be used if the finite element in use is a scalar one, i.e. has only one vector component. To get values of multi-component elements, there is another get_function_values() below, returning a vector of vectors of results.
Parameters
[in]
fe_function
A vector of values that describes (globally) the finite element function that this function should evaluate at the quadrature points of the current cell.
-
[out]
values
The values of the function specified by fe_function at the quadrature points of the current cell. The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the values of shape function times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument). This happens to be equal to the type of the elements of the solution vector.
+
[out]
values
The values of the function specified by fe_function at the quadrature points of the current cell. The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the values of shape function times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument). This happens to be equal to the type of the elements of the solution vector.
-
Postcondition
values[q] will contain the value of the field described by fe_function at the th quadrature point.
+
Postcondition
values[q] will contain the value of the field described by fe_function at the th quadrature point.
Note
The actual data type of the input vector may be either a Vector<T>, BlockVector<T>, or one of the PETSc or Trilinos vector wrapper classes. It represents a global vector of DoF values associated with the DoFHandler object with which this FEValues object was last initialized.
This function does the same as the other get_function_values(), but applied to multi-component (vector-valued) elements. The meaning of the arguments is as explained there.
-
Postcondition
values[q] is a vector of values of the field described by fe_function at the th quadrature point. The size of the vector accessed by values[q] equals the number of components of the finite element, i.e. values[q](c) returns the value of the th vector component at the th quadrature point.
+
Postcondition
values[q] is a vector of values of the field described by fe_function at the th quadrature point. The size of the vector accessed by values[q] equals the number of components of the finite element, i.e. values[q](c) returns the value of the th vector component at the th quadrature point.
Return the gradients of a finite element function at the quadrature points of the current cell, face, or subface (selected the last time the reinit() function was called). That is, if the first argument fe_function is a vector of nodal values of a finite element function defined on a DoFHandler object, then the output vector (the second argument, values) is the vector of values where are the quadrature points on the current cell . This function is first discussed in the Results section of step-4, and it is also used in step-15 along with numerous other tutorial programs.
+
Return the gradients of a finite element function at the quadrature points of the current cell, face, or subface (selected the last time the reinit() function was called). That is, if the first argument fe_function is a vector of nodal values of a finite element function defined on a DoFHandler object, then the output vector (the second argument, values) is the vector of values where are the quadrature points on the current cell . This function is first discussed in the Results section of step-4, and it is also used in step-15 along with numerous other tutorial programs.
This function may only be used if the finite element in use is a scalar one, i.e. has only one vector component. There is a corresponding function of the same name for vector-valued finite elements.
Parameters
[in]
fe_function
A vector of values that describes (globally) the finite element function that this function should evaluate at the quadrature points of the current cell.
-
[out]
gradients
The gradients of the function specified by fe_function at the quadrature points of the current cell. The gradients are computed in real space (as opposed to on the unit cell). The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the gradients of shape function times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
+
[out]
gradients
The gradients of the function specified by fe_function at the quadrature points of the current cell. The gradients are computed in real space (as opposed to on the unit cell). The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the gradients of shape function times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
-
Postcondition
gradients[q] will contain the gradient of the field described by fe_function at the th quadrature point. gradients[q][d] represents the derivative in coordinate direction at quadrature point .
+
Postcondition
gradients[q] will contain the gradient of the field described by fe_function at the th quadrature point. gradients[q][d] represents the derivative in coordinate direction at quadrature point .
Note
The actual data type of the input vector may be either a Vector<T>, BlockVector<T>, or one of the PETSc or Trilinos vector wrapper classes. It represents a global vector of DoF values associated with the DoFHandler object with which this FEValues object was last initialized.
This function does the same as the other get_function_gradients(), but applied to multi-component (vector-valued) elements. The meaning of the arguments is as explained there.
-
Postcondition
gradients[q] is a vector of gradients of the field described by fe_function at the th quadrature point. The size of the vector accessed by gradients[q] equals the number of components of the finite element, i.e. gradients[q][c] returns the gradient of the th vector component at the th quadrature point. Consequently, gradients[q][c][d] is the derivative in coordinate direction of the th vector component of the vector field at quadrature point of the current cell.
+
Postcondition
gradients[q] is a vector of gradients of the field described by fe_function at the th quadrature point. The size of the vector accessed by gradients[q] equals the number of components of the finite element, i.e. gradients[q][c] returns the gradient of the th vector component at the th quadrature point. Consequently, gradients[q][c][d] is the derivative in coordinate direction of the th vector component of the vector field at quadrature point of the current cell.
A vector of values that describes (globally) the finite element function that this function should evaluate at the quadrature points of the current cell.
-
[out]
hessians
The Hessians of the function specified by fe_function at the quadrature points of the current cell. The Hessians are computed in real space (as opposed to on the unit cell). The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the Hessians of shape function times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
+
[out]
hessians
The Hessians of the function specified by fe_function at the quadrature points of the current cell. The Hessians are computed in real space (as opposed to on the unit cell). The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the Hessians of shape function times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
-
Postcondition
hessians[q] will contain the Hessian of the field described by fe_function at the th quadrature point. hessians[q][i][j] represents the th component of the matrix of second derivatives at quadrature point .
+
Postcondition
hessians[q] will contain the Hessian of the field described by fe_function at the th quadrature point. hessians[q][i][j] represents the th component of the matrix of second derivatives at quadrature point .
Note
The actual data type of the input vector may be either a Vector<T>, BlockVector<T>, or one of the PETSc or Trilinos vector wrapper classes. It represents a global vector of DoF values associated with the DoFHandler object with which this FEValues object was last initialized.
This function does the same as the other get_function_hessians(), but applied to multi-component (vector-valued) elements. The meaning of the arguments is as explained there.
-
Postcondition
hessians[q] is a vector of Hessians of the field described by fe_function at the th quadrature point. The size of the vector accessed by hessians[q] equals the number of components of the finite element, i.e. hessians[q][c] returns the Hessian of the th vector component at the th quadrature point. Consequently, hessians[q][c][i][j] is the th component of the matrix of second derivatives of the th vector component of the vector field at quadrature point of the current cell.
+
Postcondition
hessians[q] is a vector of Hessians of the field described by fe_function at the th quadrature point. The size of the vector accessed by hessians[q] equals the number of components of the finite element, i.e. hessians[q][c] returns the Hessian of the th vector component at the th quadrature point. Consequently, hessians[q][c][i][j] is the th component of the matrix of second derivatives of the th vector component of the vector field at quadrature point of the current cell.
A vector of values that describes (globally) the finite element function that this function should evaluate at the quadrature points of the current cell.
-
[out]
laplacians
The Laplacians of the function specified by fe_function at the quadrature points of the current cell. The Laplacians are computed in real space (as opposed to on the unit cell). The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the Laplacians of shape function times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument). This happens to be equal to the type of the elements of the input vector.
+
[out]
laplacians
The Laplacians of the function specified by fe_function at the quadrature points of the current cell. The Laplacians are computed in real space (as opposed to on the unit cell). The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the Laplacians of shape function times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument). This happens to be equal to the type of the elements of the input vector.
-
Postcondition
laplacians[q] will contain the Laplacian of the field described by fe_function at the th quadrature point.
+
Postcondition
laplacians[q] will contain the Laplacian of the field described by fe_function at the th quadrature point.
For each component of the output vector, there holds laplacians[q]=trace(hessians[q]), where hessians would be the output of the get_function_hessians() function.
Note
The actual data type of the input vector may be either a Vector<T>, BlockVector<T>, or one of the PETSc or Trilinos vector wrapper classes. It represents a global vector of DoF values associated with the DoFHandler object with which this FEValues object was last initialized.
@@ -1525,7 +1525,7 @@
This function does the same as the other get_function_laplacians(), but applied to multi-component (vector-valued) elements. The meaning of the arguments is as explained there.
-
Postcondition
laplacians[q] is a vector of Laplacians of the field described by fe_function at the th quadrature point. The size of the vector accessed by laplacians[q] equals the number of components of the finite element, i.e. laplacians[q][c] returns the Laplacian of the th vector component at the th quadrature point.
+
Postcondition
laplacians[q] is a vector of Laplacians of the field described by fe_function at the th quadrature point. The size of the vector accessed by laplacians[q] equals the number of components of the finite element, i.e. laplacians[q][c] returns the Laplacian of the th vector component at the th quadrature point.
For each component of the output vector, there holds laplacians[q][c]=trace(hessians[q][c]), where hessians would be the output of the get_function_hessians() function.
A vector of values that describes (globally) the finite element function that this function should evaluate at the quadrature points of the current cell.
-
[out]
third_derivatives
The third derivatives of the function specified by fe_function at the quadrature points of the current cell. The third derivatives are computed in real space (as opposed to on the unit cell). The object is assumed to already have the correct size. The data type stored by this output vector must be what you get when you multiply the third derivatives of shape function times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
+
[out]
third_derivatives
The third derivatives of the function specified by fe_function at the quadrature points of the current cell. The third derivatives are computed in real space (as opposed to on the unit cell). The object is assumed to already have the correct size. The data type stored by this output vector must be what you get when you multiply the third derivatives of shape function times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
-
Postcondition
third_derivatives[q] will contain the third derivatives of the field described by fe_function at the th quadrature point. third_derivatives[q][i][j][k] represents the th component of the 3rd order tensor of third derivatives at quadrature point .
+
Postcondition
third_derivatives[q] will contain the third derivatives of the field described by fe_function at the th quadrature point. third_derivatives[q][i][j][k] represents the th component of the 3rd order tensor of third derivatives at quadrature point .
Note
The actual data type of the input vector may be either a Vector<T>, BlockVector<T>, or one of the PETSc or Trilinos vector wrapper classes. It represents a global vector of DoF values associated with the DoFHandler object with which this FEValues object was last initialized.
This function does the same as the other get_function_third_derivatives(), but applied to multi-component (vector- valued) elements. The meaning of the arguments is as explained there.
-
Postcondition
third_derivatives[q] is a vector of third derivatives of the field described by fe_function at the th quadrature point. The size of the vector accessed by third_derivatives[q] equals the number of components of the finite element, i.e. third_derivatives[q][c] returns the third derivative of the th vector component at the th quadrature point. Consequently, third_derivatives[q][c][i][j][k] is the th component of the tensor of third derivatives of the th vector component of the vector field at quadrature point of the current cell.
+
Postcondition
third_derivatives[q] is a vector of third derivatives of the field described by fe_function at the th quadrature point. The size of the vector accessed by third_derivatives[q] equals the number of components of the finite element, i.e. third_derivatives[q][c] returns the third derivative of the th vector component at the th quadrature point. Consequently, third_derivatives[q][c][i][j][k] is the th component of the tensor of third derivatives of the th vector component of the vector field at quadrature point of the current cell.
Mapped quadrature weight. If this object refers to a volume evaluation (i.e. the derived class is of type FEValues), then this is the Jacobi determinant times the weight of the q_pointth unit quadrature point.
For surface evaluations (i.e. classes FEFaceValues or FESubfaceValues), it is the mapped surface element times the weight of the quadrature point.
-
You can think of the quantity returned by this function as the volume or surface element in the integral that we implement here by quadrature.
+
You can think of the quantity returned by this function as the volume or surface element in the integral that we implement here by quadrature.
Return the second derivative of the transformation from unit to real cell, i.e. the first derivative of the Jacobian, at the specified quadrature point, i.e. .
+
Return the second derivative of the transformation from unit to real cell, i.e. the first derivative of the Jacobian, at the specified quadrature point, i.e. .
Return the second derivative of the transformation from unit to real cell, i.e. the first derivative of the Jacobian, at the specified quadrature point, pushed forward to the real cell coordinates, i.e. .
+
Return the second derivative of the transformation from unit to real cell, i.e. the first derivative of the Jacobian, at the specified quadrature point, pushed forward to the real cell coordinates, i.e. .
Note
For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_jacobian_pushed_forward_grads flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.
@@ -2189,7 +2189,7 @@
-
Return the third derivative of the transformation from unit to real cell, i.e. the second derivative of the Jacobian, at the specified quadrature point, i.e. .
+
Return the third derivative of the transformation from unit to real cell, i.e. the second derivative of the Jacobian, at the specified quadrature point, i.e. .
Note
For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_jacobian_2nd_derivatives flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFEValuesViews_1_1Scalar.html differs (JavaScript source, ASCII text, with very long lines (902))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFEValuesViews_1_1Scalar.html 2023-11-25 15:25:52.533373145 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFEValuesViews_1_1Scalar.html 2023-11-25 15:25:52.533373145 +0100
@@ -734,7 +734,7 @@
Return the values of the selected scalar component of the finite element function characterized by fe_function at the quadrature points of the cell, face or subface selected the last time the reinit function of the FEValues object was called.
This function is the equivalent of the FEValuesBase::get_function_values function but it only works on the selected scalar component.
-
The data type stored by the output vector must be what you get when you multiply the values of shape functions (i.e., value_type) times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
+
The data type stored by the output vector must be what you get when you multiply the values of shape functions (i.e., value_type) times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
Return the gradients of the selected scalar component of the finite element function characterized by fe_function at the quadrature points of the cell, face or subface selected the last time the reinit function of the FEValues object was called.
The data type stored by the output vector must be what you get when you multiply the gradients of shape functions (i.e., gradient_type) times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
+
The data type stored by the output vector must be what you get when you multiply the gradients of shape functions (i.e., gradient_type) times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
Return the Hessians of the selected scalar component of the finite element function characterized by fe_function at the quadrature points of the cell, face or subface selected the last time the reinit function of the FEValues object was called.
The data type stored by the output vector must be what you get when you multiply the Hessians of shape functions (i.e., hessian_type) times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
+
The data type stored by the output vector must be what you get when you multiply the Hessians of shape functions (i.e., hessian_type) times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
Return the Laplacians of the selected scalar component of the finite element function characterized by fe_function at the quadrature points of the cell, face or subface selected the last time the reinit function of the FEValues object was called. The Laplacians are the trace of the Hessians.
The data type stored by the output vector must be what you get when you multiply the Laplacians of shape functions (i.e., value_type) times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
+
The data type stored by the output vector must be what you get when you multiply the Laplacians of shape functions (i.e., value_type) times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
Return the third derivatives of the selected scalar component of the finite element function characterized by fe_function at the quadrature points of the cell, face or subface selected the last time the reinit function of the FEValues object was called.
The data type stored by the output vector must be what you get when you multiply the third derivatives of shape functions (i.e., third_derivative_type) times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
+
The data type stored by the output vector must be what you get when you multiply the third derivatives of shape functions (i.e., third_derivative_type) times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
Note
For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_third_derivatives flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFEValuesViews_1_1SymmetricTensor_3_012_00_01dim_00_01spacedim_01_4.html differs (JavaScript source, ASCII text, with very long lines (902))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFEValuesViews_1_1SymmetricTensor_3_012_00_01dim_00_01spacedim_01_4.html 2023-11-25 15:25:52.553372738 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFEValuesViews_1_1SymmetricTensor_3_012_00_01dim_00_01spacedim_01_4.html 2023-11-25 15:25:52.553372738 +0100
@@ -154,9 +154,9 @@
Detailed Description
template<int dim, int spacedim>
class FEValuesViews::SymmetricTensor< 2, dim, spacedim >
A class representing a view to a set of (dim*dim + dim)/2 components forming a symmetric second-order tensor from a vector-valued finite element. Views are discussed in the Handling vector valued problems module.
-
This class allows to query the value and divergence of (components of) shape functions and solutions representing symmetric tensors. The divergence of a symmetric tensor is defined as , which due to the symmetry of the tensor is also . In other words, it due to the symmetry of it does not matter whether we apply the nabla operator by row or by column to get the divergence.
+
This class allows to query the value and divergence of (components of) shape functions and solutions representing symmetric tensors. The divergence of a symmetric tensor is defined as , which due to the symmetry of the tensor is also . In other words, it due to the symmetry of it does not matter whether we apply the nabla operator by row or by column to get the divergence.
Return the values of the selected vector components of the finite element function characterized by fe_function at the quadrature points of the cell, face or subface selected the last time the reinit function of the FEValues object was called.
This function is the equivalent of the FEValuesBase::get_function_values function but it only works on the selected vector components.
-
The data type stored by the output vector must be what you get when you multiply the values of shape functions (i.e., value_type) times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
+
The data type stored by the output vector must be what you get when you multiply the values of shape functions (i.e., value_type) times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
Return the divergence of the selected vector components of the finite element function characterized by fe_function at the quadrature points of the cell, face or subface selected the last time the reinit function of the FEValues object was called.
There is no equivalent function such as FEValuesBase::get_function_divergences in the FEValues classes but the information can be obtained from FEValuesBase::get_function_gradients, of course.
See the general discussion of this class for a definition of the divergence.
-
The data type stored by the output vector must be what you get when you multiply the divergences of shape functions (i.e., divergence_type) times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
+
The data type stored by the output vector must be what you get when you multiply the divergences of shape functions (i.e., divergence_type) times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFEValuesViews_1_1Tensor_3_012_00_01dim_00_01spacedim_01_4.html differs (JavaScript source, ASCII text, with very long lines (902))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFEValuesViews_1_1Tensor_3_012_00_01dim_00_01spacedim_01_4.html 2023-11-25 15:25:52.570039063 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFEValuesViews_1_1Tensor_3_012_00_01dim_00_01spacedim_01_4.html 2023-11-25 15:25:52.570039063 +0100
@@ -167,8 +167,8 @@
Detailed Description
template<int dim, int spacedim>
class FEValuesViews::Tensor< 2, dim, spacedim >
A class representing a view to a set of dim*dim components forming a second-order tensor from a vector-valued finite element. Views are discussed in the Handling vector valued problems module.
-
This class allows to query the value, gradient and divergence of (components of) shape functions and solutions representing tensors. The divergence of a tensor is defined as , whereas its gradient is .
+
This class allows to query the value, gradient and divergence of (components of) shape functions and solutions representing tensors. The divergence of a tensor is defined as , whereas its gradient is .
Return the values of the selected vector components of the finite element function characterized by fe_function at the quadrature points of the cell, face or subface selected the last time the reinit function of the FEValues object was called.
This function is the equivalent of the FEValuesBase::get_function_values function but it only works on the selected vector components.
-
The data type stored by the output vector must be what you get when you multiply the values of shape functions (i.e., value_type) times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
+
The data type stored by the output vector must be what you get when you multiply the values of shape functions (i.e., value_type) times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
Return the divergence of the selected vector components of the finite element function characterized by fe_function at the quadrature points of the cell, face or subface selected the last time the reinit function of the FEValues object was called.
There is no equivalent function such as FEValuesBase::get_function_divergences in the FEValues classes but the information can be obtained from FEValuesBase::get_function_gradients, of course.
See the general discussion of this class for a definition of the divergence.
-
The data type stored by the output vector must be what you get when you multiply the divergences of shape functions (i.e., divergence_type) times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
+
The data type stored by the output vector must be what you get when you multiply the divergences of shape functions (i.e., divergence_type) times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
Return the gradient of the selected vector components of the finite element function characterized by fe_function at the quadrature points of the cell, face or subface selected the last time the reinit function of the FEValues object was called.
See the general discussion of this class for a definition of the gradient.
-
The data type stored by the output vector must be what you get when you multiply the gradients of shape functions (i.e., gradient_type) times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
+
The data type stored by the output vector must be what you get when you multiply the gradients of shape functions (i.e., gradient_type) times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFEValuesViews_1_1Vector.html differs (JavaScript source, ASCII text, with very long lines (857))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFEValuesViews_1_1Vector.html 2023-11-25 15:25:52.593371923 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFEValuesViews_1_1Vector.html 2023-11-25 15:25:52.593371923 +0100
@@ -228,8 +228,8 @@
template<int dim, int spacedim = dim>
class FEValuesViews::Vector< dim, spacedim >
A class representing a view to a set of spacedim components forming a vector part of a vector-valued finite element. Views are discussed in the Handling vector valued problems module.
Note that in the current context, a vector is meant in the sense physics uses it: it has spacedim components that behave in specific ways under coordinate system transformations. Examples include velocity or displacement fields. This is opposed to how mathematics uses the word "vector" (and how we use this word in other contexts in the library, for example in the Vector class), where it really stands for a collection of numbers. An example of this latter use of the word could be the set of concentrations of chemical species in a flame; however, these are really just a collection of scalar variables, since they do not change if the coordinate system is rotated, unlike the components of a velocity vector, and consequently, this class should not be used for this context.
-
This class allows to query the value, gradient and divergence of (components of) shape functions and solutions representing vectors. The gradient of a vector is defined as .
+
This class allows to query the value, gradient and divergence of (components of) shape functions and solutions representing vectors. The gradient of a vector is defined as .
An alias for the type of symmetrized gradients of the view this class represents. Here, for a set of dim components of the finite element, the symmetrized gradient is a SymmetricTensor<2,spacedim>.
-
The symmetric gradient of a vector field is defined as .
+
The symmetric gradient of a vector field is defined as .
Return the symmetric gradient (a symmetric tensor of rank 2) of the vector component selected by this view, for the shape function and quadrature point selected by the arguments.
-
The symmetric gradient is defined as , where represents the dim components selected from the FEValuesBase object, and is the location of the -th quadrature point.
+
The symmetric gradient is defined as , where represents the dim components selected from the FEValuesBase object, and is the location of the -th quadrature point.
Note
The meaning of the arguments is as documented for the value() function.
Return the vector curl of the vector components selected by this view, for the shape function and quadrature point selected by the arguments. For 1d this function does not make any sense. Thus it is not implemented for spacedim=1. In 2d the curl is defined as
-
+\end{equation*}" src="form_1247.png"/>
whereas in 3d it is given by
-
+\end{equation*}" src="form_1248.png"/>
Note
The meaning of the arguments is as documented for the value() function.
@@ -1004,7 +1004,7 @@
Return the values of the selected vector components of the finite element function characterized by fe_function at the quadrature points of the cell, face or subface selected the last time the reinit function of the FEValues object was called.
This function is the equivalent of the FEValuesBase::get_function_values function but it only works on the selected vector components.
-
The data type stored by the output vector must be what you get when you multiply the values of shape functions (i.e., value_type) times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
+
The data type stored by the output vector must be what you get when you multiply the values of shape functions (i.e., value_type) times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
Return the gradients of the selected vector components of the finite element function characterized by fe_function at the quadrature points of the cell, face or subface selected the last time the reinit function of the FEValues object was called.
The data type stored by the output vector must be what you get when you multiply the gradients of shape functions (i.e., gradient_type) times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
+
The data type stored by the output vector must be what you get when you multiply the gradients of shape functions (i.e., gradient_type) times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
Return the symmetrized gradients of the selected vector components of the finite element function characterized by fe_function at the quadrature points of the cell, face or subface selected the last time the reinit function of the FEValues object was called.
-
The symmetric gradient of a vector field is defined as .
+
The symmetric gradient of a vector field is defined as .
Note
There is no equivalent function such as FEValuesBase::get_function_symmetric_gradients in the FEValues classes but the information can be obtained from FEValuesBase::get_function_gradients, of course.
-
The data type stored by the output vector must be what you get when you multiply the symmetric gradients of shape functions (i.e., symmetric_gradient_type) times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
+
The data type stored by the output vector must be what you get when you multiply the symmetric gradients of shape functions (i.e., symmetric_gradient_type) times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
Return the divergence of the selected vector components of the finite element function characterized by fe_function at the quadrature points of the cell, face or subface selected the last time the reinit function of the FEValues object was called.
There is no equivalent function such as FEValuesBase::get_function_divergences in the FEValues classes but the information can be obtained from FEValuesBase::get_function_gradients, of course.
-
The data type stored by the output vector must be what you get when you multiply the divergences of shape functions (i.e., divergence_type) times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
+
The data type stored by the output vector must be what you get when you multiply the divergences of shape functions (i.e., divergence_type) times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
Return the curl of the selected vector components of the finite element function characterized by fe_function at the quadrature points of the cell, face or subface selected the last time the reinit function of the FEValues object was called.
There is no equivalent function such as FEValuesBase::get_function_curls in the FEValues classes but the information can be obtained from FEValuesBase::get_function_gradients, of course.
-
The data type stored by the output vector must be what you get when you multiply the curls of shape functions (i.e., curl_type) times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
+
The data type stored by the output vector must be what you get when you multiply the curls of shape functions (i.e., curl_type) times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
Return the Hessians of the selected vector components of the finite element function characterized by fe_function at the quadrature points of the cell, face or subface selected the last time the reinit function of the FEValues object was called.
The data type stored by the output vector must be what you get when you multiply the Hessians of shape functions (i.e., hessian_type) times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
+
The data type stored by the output vector must be what you get when you multiply the Hessians of shape functions (i.e., hessian_type) times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
Return the Laplacians of the selected vector components of the finite element function characterized by fe_function at the quadrature points of the cell, face or subface selected the last time the reinit function of the FEValues object was called. The Laplacians are the trace of the Hessians.
The data type stored by the output vector must be what you get when you multiply the Laplacians of shape functions (i.e., laplacian_type) times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
+
The data type stored by the output vector must be what you get when you multiply the Laplacians of shape functions (i.e., laplacian_type) times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
Return the third derivatives of the selected scalar component of the finite element function characterized by fe_function at the quadrature points of the cell, face or subface selected the last time the reinit function of the FEValues object was called.
The data type stored by the output vector must be what you get when you multiply the third derivatives of shape functions (i.e., third_derivative_type) times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
+
The data type stored by the output vector must be what you get when you multiply the third derivatives of shape functions (i.e., third_derivative_type) times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
Note
For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_third_derivatives flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__ABF.html differs (JavaScript source, ASCII text, with very long lines (752))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__ABF.html 2023-11-25 15:25:52.650037437 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__ABF.html 2023-11-25 15:25:52.650037437 +0100
@@ -763,11 +763,11 @@
-
Given the values of a function at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., , where are the node functionals of the element (see also Node values or node functionals). The values are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function , i.e., is the finite element interpolant of with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.
-
In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are and that the node functionals associated with the current element are . Then, the fact that the element is based on generalized support points, implies that if we apply to a (possibly vector-valued) finite element function , the result must have the form – in other words, the value of the node functional applied to only depends on the values of at and not on values anywhere else, or integrals of , or any other kind of information.
-
The exact form of depends on the element. For example, for scalar Lagrange elements, we have that in fact . If you combine multiple scalar Lagrange elements via an FESystem object, then where is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that where is the normal vector of the face at which the shape function is defined.
-
Given all of this, what this function does is the following: If you input a list of values of a function at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in then you will get out a vector where equals dofs_per_cell.
+
Given the values of a function at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., , where are the node functionals of the element (see also Node values or node functionals). The values are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function , i.e., is the finite element interpolant of with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.
+
In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are and that the node functionals associated with the current element are . Then, the fact that the element is based on generalized support points, implies that if we apply to a (possibly vector-valued) finite element function , the result must have the form – in other words, the value of the node functional applied to only depends on the values of at and not on values anywhere else, or integrals of , or any other kind of information.
+
The exact form of depends on the element. For example, for scalar Lagrange elements, we have that in fact . If you combine multiple scalar Lagrange elements via an FESystem object, then where is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that where is the normal vector of the face at which the shape function is defined.
+
Given all of this, what this function does is the following: If you input a list of values of a function at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in then you will get out a vector where equals dofs_per_cell.
Parameters
[in]
support_point_values
An array of size dofs_per_cell (which equals the number of points the get_generalized_support_points() function will return) where each element is a vector with as many entries as the element has vector components. This array should contain the values of a function at the generalized support points of the current element.
@@ -3037,7 +3037,7 @@
Returns
The index of this degree of freedom within the set of degrees of freedom on the entire cell. The returned value will be between zero and dofs_per_cell.
-
Note
This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a , then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
+
Note
This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a , then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
Return a block mask with as many elements as this object has blocks and of which exactly the one component is true that corresponds to the given argument. See the glossary for more information.
-
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
scalar
An object that represents a single scalar vector component of this finite element.
@@ -3866,7 +3866,7 @@
Given a component mask (see this glossary entry), produce a block mask (see this glossary entry) that represents the blocks that correspond to the components selected in the input argument. This is essentially a conversion operator from ComponentMask to BlockMask.
-
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
component_mask
The mask that selects individual components of the finite element
@@ -4126,7 +4126,7 @@
Return a vector of generalized support points.
-
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
+
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
For a given degree of freedom, return whether it is logically associated with a vertex, line, quad or hex.
-
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
-
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
-
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
+
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
+
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
+
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
Parameters
[in]
cell_dof_index
The index of a shape function or degree of freedom. This index must be in the range [0,dofs_per_cell).
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__BDM.html differs (JavaScript source, ASCII text, with very long lines (752))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__BDM.html 2023-11-25 15:25:52.706702951 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__BDM.html 2023-11-25 15:25:52.706702951 +0100
@@ -730,11 +730,11 @@
-
Given the values of a function at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., , where are the node functionals of the element (see also Node values or node functionals). The values are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function , i.e., is the finite element interpolant of with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.
-
In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are and that the node functionals associated with the current element are . Then, the fact that the element is based on generalized support points, implies that if we apply to a (possibly vector-valued) finite element function , the result must have the form – in other words, the value of the node functional applied to only depends on the values of at and not on values anywhere else, or integrals of , or any other kind of information.
-
The exact form of depends on the element. For example, for scalar Lagrange elements, we have that in fact . If you combine multiple scalar Lagrange elements via an FESystem object, then where is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that where is the normal vector of the face at which the shape function is defined.
-
Given all of this, what this function does is the following: If you input a list of values of a function at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in then you will get out a vector where equals dofs_per_cell.
+
Given the values of a function at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., , where are the node functionals of the element (see also Node values or node functionals). The values are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function , i.e., is the finite element interpolant of with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.
+
In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are and that the node functionals associated with the current element are . Then, the fact that the element is based on generalized support points, implies that if we apply to a (possibly vector-valued) finite element function , the result must have the form – in other words, the value of the node functional applied to only depends on the values of at and not on values anywhere else, or integrals of , or any other kind of information.
+
The exact form of depends on the element. For example, for scalar Lagrange elements, we have that in fact . If you combine multiple scalar Lagrange elements via an FESystem object, then where is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that where is the normal vector of the face at which the shape function is defined.
+
Given all of this, what this function does is the following: If you input a list of values of a function at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in then you will get out a vector where equals dofs_per_cell.
Parameters
[in]
support_point_values
An array of size dofs_per_cell (which equals the number of points the get_generalized_support_points() function will return) where each element is a vector with as many entries as the element has vector components. This array should contain the values of a function at the generalized support points of the current element.
@@ -2980,7 +2980,7 @@
Returns
The index of this degree of freedom within the set of degrees of freedom on the entire cell. The returned value will be between zero and dofs_per_cell.
-
Note
This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a , then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
+
Note
This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a , then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
Return a block mask with as many elements as this object has blocks and of which exactly the one component is true that corresponds to the given argument. See the glossary for more information.
-
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
scalar
An object that represents a single scalar vector component of this finite element.
@@ -3809,7 +3809,7 @@
Given a component mask (see this glossary entry), produce a block mask (see this glossary entry) that represents the blocks that correspond to the components selected in the input argument. This is essentially a conversion operator from ComponentMask to BlockMask.
-
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
component_mask
The mask that selects individual components of the finite element
@@ -4069,7 +4069,7 @@
Return a vector of generalized support points.
-
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
+
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
For a given degree of freedom, return whether it is logically associated with a vertex, line, quad or hex.
-
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
-
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
-
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
+
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
+
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
+
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
Parameters
[in]
cell_dof_index
The index of a shape function or degree of freedom. This index must be in the range [0,dofs_per_cell).
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__BernardiRaugel.html differs (JavaScript source, ASCII text, with very long lines (752))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__BernardiRaugel.html 2023-11-25 15:25:52.766701730 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__BernardiRaugel.html 2023-11-25 15:25:52.766701730 +0100
@@ -489,8 +489,8 @@
This class implements the non-standard Bernardi-Raugel (BR) element that can be used as one part of a stable velocity/pressure pair for the Stokes equation. The BR element can be seen as either an enriched version of the element with added bubble functions on each edge (in 2d) or face (in 3d), or as a reduced version of the element. It addresses the fact that the combination is not inf-sup stable (requiring a larger velocity space), and that the combination is stable but sub-optimal since the velocity space is too large relative to the pressure space to provide additional accuracy commensurate with the cost of the large number of velocity unknowns.
+
This class implements the non-standard Bernardi-Raugel (BR) element that can be used as one part of a stable velocity/pressure pair for the Stokes equation. The BR element can be seen as either an enriched version of the element with added bubble functions on each edge (in 2d) or face (in 3d), or as a reduced version of the element. It addresses the fact that the combination is not inf-sup stable (requiring a larger velocity space), and that the combination is stable but sub-optimal since the velocity space is too large relative to the pressure space to provide additional accuracy commensurate with the cost of the large number of velocity unknowns.
The element was introduced in the following paper:
@article{BR85,
author = {Christine Bernardi and Genevi{\`e}ve Raugel},
title = {Analysis of some finite elements for the {S}tokes problem},
@@ -505,7 +505,7 @@
}
Degrees of freedom
The BR1 element has dim degrees of freedom on each vertex and 1 on each face. The shape functions are ordered by the shape functions supported on each vertex, increasing according to vertex ordering on the element in GeometryInfo, then the bubble functions follow in the ordering given in PolynomialsBernardiRaugel.
-
This element only has 1 degree (degree ) because it yields an LBB stable pair BR1-P0 for Stokes problems which is lower degree than the Taylor-Hood element. The pair is sometimes referred to as an enriched P1-P0 element or a reduced P2-P0 element.
+
This element only has 1 degree (degree ) because it yields an LBB stable pair BR1-P0 for Stokes problems which is lower degree than the Taylor-Hood element. The pair is sometimes referred to as an enriched P1-P0 element or a reduced P2-P0 element.
This element does not support hanging nodes or multigrid in the current implementation.
Some numerical experiments have shown that this element may converge with first-order accuracy when using the BR1-Q0 pair for the mixed Laplace equation in step-20.
@@ -637,7 +637,7 @@
Constructor for the Bernardi-Raugel element of degree p. The only supported degree is 1.
Given the values of a function at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., , where are the node functionals of the element (see also Node values or node functionals). The values are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function , i.e., is the finite element interpolant of with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.
-
In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are and that the node functionals associated with the current element are . Then, the fact that the element is based on generalized support points, implies that if we apply to a (possibly vector-valued) finite element function , the result must have the form – in other words, the value of the node functional applied to only depends on the values of at and not on values anywhere else, or integrals of , or any other kind of information.
-
The exact form of depends on the element. For example, for scalar Lagrange elements, we have that in fact . If you combine multiple scalar Lagrange elements via an FESystem object, then where is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that where is the normal vector of the face at which the shape function is defined.
-
Given all of this, what this function does is the following: If you input a list of values of a function at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in then you will get out a vector where equals dofs_per_cell.
+
Given the values of a function at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., , where are the node functionals of the element (see also Node values or node functionals). The values are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function , i.e., is the finite element interpolant of with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.
+
In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are and that the node functionals associated with the current element are . Then, the fact that the element is based on generalized support points, implies that if we apply to a (possibly vector-valued) finite element function , the result must have the form – in other words, the value of the node functional applied to only depends on the values of at and not on values anywhere else, or integrals of , or any other kind of information.
+
The exact form of depends on the element. For example, for scalar Lagrange elements, we have that in fact . If you combine multiple scalar Lagrange elements via an FESystem object, then where is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that where is the normal vector of the face at which the shape function is defined.
+
Given all of this, what this function does is the following: If you input a list of values of a function at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in then you will get out a vector where equals dofs_per_cell.
Parameters
[in]
support_point_values
An array of size dofs_per_cell (which equals the number of points the get_generalized_support_points() function will return) where each element is a vector with as many entries as the element has vector components. This array should contain the values of a function at the generalized support points of the current element.
@@ -2955,7 +2955,7 @@
Returns
The index of this degree of freedom within the set of degrees of freedom on the entire cell. The returned value will be between zero and dofs_per_cell.
-
Note
This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a , then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
+
Note
This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a , then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
Return a block mask with as many elements as this object has blocks and of which exactly the one component is true that corresponds to the given argument. See the glossary for more information.
-
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
scalar
An object that represents a single scalar vector component of this finite element.
@@ -3784,7 +3784,7 @@
Given a component mask (see this glossary entry), produce a block mask (see this glossary entry) that represents the blocks that correspond to the components selected in the input argument. This is essentially a conversion operator from ComponentMask to BlockMask.
-
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
component_mask
The mask that selects individual components of the finite element
@@ -4044,7 +4044,7 @@
Return a vector of generalized support points.
-
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
+
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
For a given degree of freedom, return whether it is logically associated with a vertex, line, quad or hex.
-
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
-
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
-
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
+
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
+
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
+
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
Parameters
[in]
cell_dof_index
The index of a shape function or degree of freedom. This index must be in the range [0,dofs_per_cell).
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__Bernstein.html differs (JavaScript source, ASCII text, with very long lines (759))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__Bernstein.html 2023-11-25 15:25:52.820033975 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__Bernstein.html 2023-11-25 15:25:52.823367243 +0100
@@ -2633,17 +2633,17 @@
Correct the shape Hessians by subtracting the terms corresponding to the Jacobian pushed forward gradient.
Before the correction, the Hessians would be given by
-
+\]" src="form_1140.png"/>
-
where . After the correction, the correct Hessians would be given by
-. After the correction, the correct Hessians would be given by
+
+\]" src="form_1142.png"/>
-
where is the Jacobian pushed-forward derivative.
+
where is the Jacobian pushed-forward derivative.
@@ -2687,21 +2687,21 @@
Correct the shape third derivatives by subtracting the terms corresponding to the Jacobian pushed forward gradient and second derivative.
Before the correction, the third derivatives would be given by
-
+\]" src="form_1144.png"/>
-
where . After the correction, the correct third derivative would be given by
-. After the correction, the correct third derivative would be given by
+
+\]" src="form_1145.png"/>
-
where is the Jacobian pushed-forward derivative and is the Jacobian pushed-forward second derivative.
+
where is the Jacobian pushed-forward derivative and is the Jacobian pushed-forward second derivative.
@@ -3903,7 +3903,7 @@
Return a block mask with as many elements as this object has blocks and of which exactly the one component is true that corresponds to the given argument. See the glossary for more information.
-
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
scalar
An object that represents a single scalar vector component of this finite element.
@@ -4011,7 +4011,7 @@
Given a component mask (see this glossary entry), produce a block mask (see this glossary entry) that represents the blocks that correspond to the components selected in the input argument. This is essentially a conversion operator from ComponentMask to BlockMask.
-
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
component_mask
The mask that selects individual components of the finite element
@@ -4240,7 +4240,7 @@
Return a vector of generalized support points.
-
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
+
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
For a given degree of freedom, return whether it is logically associated with a vertex, line, quad or hex.
-
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
-
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
-
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
+
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
+
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
+
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
Parameters
[in]
cell_dof_index
The index of a shape function or degree of freedom. This index must be in the range [0,dofs_per_cell).
@@ -4346,11 +4346,11 @@
-
Given the values of a function at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., , where are the node functionals of the element (see also Node values or node functionals). The values are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function , i.e., is the finite element interpolant of with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.
-
In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are and that the node functionals associated with the current element are . Then, the fact that the element is based on generalized support points, implies that if we apply to a (possibly vector-valued) finite element function , the result must have the form – in other words, the value of the node functional applied to only depends on the values of at and not on values anywhere else, or integrals of , or any other kind of information.
-
The exact form of depends on the element. For example, for scalar Lagrange elements, we have that in fact . If you combine multiple scalar Lagrange elements via an FESystem object, then where is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that where is the normal vector of the face at which the shape function is defined.
-
Given all of this, what this function does is the following: If you input a list of values of a function at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in then you will get out a vector where equals dofs_per_cell.
+
Given the values of a function at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., , where are the node functionals of the element (see also Node values or node functionals). The values are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function , i.e., is the finite element interpolant of with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.
+
In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are and that the node functionals associated with the current element are . Then, the fact that the element is based on generalized support points, implies that if we apply to a (possibly vector-valued) finite element function , the result must have the form – in other words, the value of the node functional applied to only depends on the values of at and not on values anywhere else, or integrals of , or any other kind of information.
+
The exact form of depends on the element. For example, for scalar Lagrange elements, we have that in fact . If you combine multiple scalar Lagrange elements via an FESystem object, then where is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that where is the normal vector of the face at which the shape function is defined.
+
Given all of this, what this function does is the following: If you input a list of values of a function at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in then you will get out a vector where equals dofs_per_cell.
Parameters
[in]
support_point_values
An array of size dofs_per_cell (which equals the number of points the get_generalized_support_points() function will return) where each element is a vector with as many entries as the element has vector components. This array should contain the values of a function at the generalized support points of the current element.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__DGBDM.html differs (JavaScript source, ASCII text, with very long lines (752))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__DGBDM.html 2023-11-25 15:25:52.880032754 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__DGBDM.html 2023-11-25 15:25:52.880032754 +0100
@@ -2851,7 +2851,7 @@
Returns
The index of this degree of freedom within the set of degrees of freedom on the entire cell. The returned value will be between zero and dofs_per_cell.
-
Note
This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a , then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
+
Note
This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a , then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
Return a block mask with as many elements as this object has blocks and of which exactly the one component is true that corresponds to the given argument. See the glossary for more information.
-
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
scalar
An object that represents a single scalar vector component of this finite element.
@@ -3680,7 +3680,7 @@
Given a component mask (see this glossary entry), produce a block mask (see this glossary entry) that represents the blocks that correspond to the components selected in the input argument. This is essentially a conversion operator from ComponentMask to BlockMask.
-
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
component_mask
The mask that selects individual components of the finite element
@@ -3940,7 +3940,7 @@
Return a vector of generalized support points.
-
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
+
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
For a given degree of freedom, return whether it is logically associated with a vertex, line, quad or hex.
-
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
-
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
-
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
+
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
+
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
+
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
Parameters
[in]
cell_dof_index
The index of a shape function or degree of freedom. This index must be in the range [0,dofs_per_cell).
@@ -4046,11 +4046,11 @@
-
Given the values of a function at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., , where are the node functionals of the element (see also Node values or node functionals). The values are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function , i.e., is the finite element interpolant of with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.
-
In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are and that the node functionals associated with the current element are . Then, the fact that the element is based on generalized support points, implies that if we apply to a (possibly vector-valued) finite element function , the result must have the form – in other words, the value of the node functional applied to only depends on the values of at and not on values anywhere else, or integrals of , or any other kind of information.
-
The exact form of depends on the element. For example, for scalar Lagrange elements, we have that in fact . If you combine multiple scalar Lagrange elements via an FESystem object, then where is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that where is the normal vector of the face at which the shape function is defined.
-
Given all of this, what this function does is the following: If you input a list of values of a function at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in then you will get out a vector where equals dofs_per_cell.
+
Given the values of a function at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., , where are the node functionals of the element (see also Node values or node functionals). The values are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function , i.e., is the finite element interpolant of with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.
+
In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are and that the node functionals associated with the current element are . Then, the fact that the element is based on generalized support points, implies that if we apply to a (possibly vector-valued) finite element function , the result must have the form – in other words, the value of the node functional applied to only depends on the values of at and not on values anywhere else, or integrals of , or any other kind of information.
+
The exact form of depends on the element. For example, for scalar Lagrange elements, we have that in fact . If you combine multiple scalar Lagrange elements via an FESystem object, then where is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that where is the normal vector of the face at which the shape function is defined.
+
Given all of this, what this function does is the following: If you input a list of values of a function at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in then you will get out a vector where equals dofs_per_cell.
Parameters
[in]
support_point_values
An array of size dofs_per_cell (which equals the number of points the get_generalized_support_points() function will return) where each element is a vector with as many entries as the element has vector components. This array should contain the values of a function at the generalized support points of the current element.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__DGNedelec.html differs (JavaScript source, ASCII text, with very long lines (752))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__DGNedelec.html 2023-11-25 15:25:52.936698268 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__DGNedelec.html 2023-11-25 15:25:52.936698268 +0100
@@ -2851,7 +2851,7 @@
Returns
The index of this degree of freedom within the set of degrees of freedom on the entire cell. The returned value will be between zero and dofs_per_cell.
-
Note
This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a , then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
+
Note
This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a , then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
Return a block mask with as many elements as this object has blocks and of which exactly the one component is true that corresponds to the given argument. See the glossary for more information.
-
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
scalar
An object that represents a single scalar vector component of this finite element.
@@ -3680,7 +3680,7 @@
Given a component mask (see this glossary entry), produce a block mask (see this glossary entry) that represents the blocks that correspond to the components selected in the input argument. This is essentially a conversion operator from ComponentMask to BlockMask.
-
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
component_mask
The mask that selects individual components of the finite element
@@ -3940,7 +3940,7 @@
Return a vector of generalized support points.
-
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
+
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
For a given degree of freedom, return whether it is logically associated with a vertex, line, quad or hex.
-
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
-
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
-
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
+
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
+
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
+
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
Parameters
[in]
cell_dof_index
The index of a shape function or degree of freedom. This index must be in the range [0,dofs_per_cell).
@@ -4046,11 +4046,11 @@
-
Given the values of a function at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., , where are the node functionals of the element (see also Node values or node functionals). The values are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function , i.e., is the finite element interpolant of with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.
-
In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are and that the node functionals associated with the current element are . Then, the fact that the element is based on generalized support points, implies that if we apply to a (possibly vector-valued) finite element function , the result must have the form – in other words, the value of the node functional applied to only depends on the values of at and not on values anywhere else, or integrals of , or any other kind of information.
-
The exact form of depends on the element. For example, for scalar Lagrange elements, we have that in fact . If you combine multiple scalar Lagrange elements via an FESystem object, then where is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that where is the normal vector of the face at which the shape function is defined.
-
Given all of this, what this function does is the following: If you input a list of values of a function at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in then you will get out a vector where equals dofs_per_cell.
+
Given the values of a function at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., , where are the node functionals of the element (see also Node values or node functionals). The values are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function , i.e., is the finite element interpolant of with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.
+
In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are and that the node functionals associated with the current element are . Then, the fact that the element is based on generalized support points, implies that if we apply to a (possibly vector-valued) finite element function , the result must have the form – in other words, the value of the node functional applied to only depends on the values of at and not on values anywhere else, or integrals of , or any other kind of information.
+
The exact form of depends on the element. For example, for scalar Lagrange elements, we have that in fact . If you combine multiple scalar Lagrange elements via an FESystem object, then where is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that where is the normal vector of the face at which the shape function is defined.
+
Given all of this, what this function does is the following: If you input a list of values of a function at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in then you will get out a vector where equals dofs_per_cell.
Parameters
[in]
support_point_values
An array of size dofs_per_cell (which equals the number of points the get_generalized_support_points() function will return) where each element is a vector with as many entries as the element has vector components. This array should contain the values of a function at the generalized support points of the current element.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__DGP.html differs (JavaScript source, ASCII text, with very long lines (752))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__DGP.html 2023-11-25 15:25:52.993363783 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__DGP.html 2023-11-25 15:25:52.993363783 +0100
@@ -481,14 +481,14 @@
This class is only partially implemented for the codimension one case (spacedim != dim ), since no passage of information between meshes of different refinement level is possible because the embedding and projection matrices are not computed in the class constructor.
Transformation properties
-
It is worth noting that under a (bi-, tri-)linear mapping, the space described by this element does not contain , even if we use a basis of polynomials of degree . Consequently, for example, on meshes with non-affine cells, a linear function can not be exactly represented by elements of type FE_DGP(1) or FE_DGPMonomial(1).
+
It is worth noting that under a (bi-, tri-)linear mapping, the space described by this element does not contain , even if we use a basis of polynomials of degree . Consequently, for example, on meshes with non-affine cells, a linear function can not be exactly represented by elements of type FE_DGP(1) or FE_DGPMonomial(1).
This can be understood by the following 2-d example: consider the cell with vertices at :
-
For this cell, a bilinear transformation produces the relations and that correlate reference coordinates and coordinates in real space . Under this mapping, the constant function is clearly mapped onto itself, but the two other shape functions of the space, namely produces the relations and that correlate reference coordinates and coordinates in real space . Under this mapping, the constant function is clearly mapped onto itself, but the two other shape functions of the space, namely and are mapped onto where .
-
For the simple case that , i.e. if the real cell is the unit square, the expressions can be simplified to and . However, for all other cases, the functions are not linear any more, and neither is any linear combination of them. Consequently, the linear functions are not within the range of the mapped polynomials.
+
For the simple case that , i.e. if the real cell is the unit square, the expressions can be simplified to and . However, for all other cases, the functions are not linear any more, and neither is any linear combination of them. Consequently, the linear functions are not within the range of the mapped polynomials.
Visualization of shape functions
In 2d, the shape functions of this element look as follows.
element
@@ -504,7 +504,7 @@
-
element
+
element
@@ -516,9 +516,9 @@
-
element, shape function 0
+
element, shape function 0
-
element, shape function 1
+
element, shape function 1
@@ -528,7 +528,7 @@
-
element, shape function 2
+
element, shape function 2
@@ -2573,17 +2573,17 @@
Correct the shape Hessians by subtracting the terms corresponding to the Jacobian pushed forward gradient.
Before the correction, the Hessians would be given by
-
+\]" src="form_1140.png"/>
-
where . After the correction, the correct Hessians would be given by
-. After the correction, the correct Hessians would be given by
+
+\]" src="form_1142.png"/>
-
where is the Jacobian pushed-forward derivative.
+
where is the Jacobian pushed-forward derivative.
@@ -2627,21 +2627,21 @@
Correct the shape third derivatives by subtracting the terms corresponding to the Jacobian pushed forward gradient and second derivative.
Before the correction, the third derivatives would be given by
-
+\]" src="form_1144.png"/>
-
where . After the correction, the correct third derivative would be given by
-. After the correction, the correct third derivative would be given by
+
+\]" src="form_1145.png"/>
-
where is the Jacobian pushed-forward derivative and is the Jacobian pushed-forward second derivative.
+
where is the Jacobian pushed-forward derivative and is the Jacobian pushed-forward second derivative.
@@ -3301,7 +3301,7 @@
Returns
The index of this degree of freedom within the set of degrees of freedom on the entire cell. The returned value will be between zero and dofs_per_cell.
-
Note
This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a , then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
+
Note
This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a , then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
Return a block mask with as many elements as this object has blocks and of which exactly the one component is true that corresponds to the given argument. See the glossary for more information.
-
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
scalar
An object that represents a single scalar vector component of this finite element.
@@ -4130,7 +4130,7 @@
Given a component mask (see this glossary entry), produce a block mask (see this glossary entry) that represents the blocks that correspond to the components selected in the input argument. This is essentially a conversion operator from ComponentMask to BlockMask.
-
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
component_mask
The mask that selects individual components of the finite element
@@ -4359,7 +4359,7 @@
Return a vector of generalized support points.
-
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
+
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
For a given degree of freedom, return whether it is logically associated with a vertex, line, quad or hex.
-
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
-
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
-
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
+
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
+
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
+
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
Parameters
[in]
cell_dof_index
The index of a shape function or degree of freedom. This index must be in the range [0,dofs_per_cell).
@@ -4465,11 +4465,11 @@
-
Given the values of a function at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., , where are the node functionals of the element (see also Node values or node functionals). The values are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function , i.e., is the finite element interpolant of with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.
-
In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are and that the node functionals associated with the current element are . Then, the fact that the element is based on generalized support points, implies that if we apply to a (possibly vector-valued) finite element function , the result must have the form – in other words, the value of the node functional applied to only depends on the values of at and not on values anywhere else, or integrals of , or any other kind of information.
-
The exact form of depends on the element. For example, for scalar Lagrange elements, we have that in fact . If you combine multiple scalar Lagrange elements via an FESystem object, then where is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that where is the normal vector of the face at which the shape function is defined.
-
Given all of this, what this function does is the following: If you input a list of values of a function at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in then you will get out a vector where equals dofs_per_cell.
+
Given the values of a function at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., , where are the node functionals of the element (see also Node values or node functionals). The values are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function , i.e., is the finite element interpolant of with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.
+
In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are and that the node functionals associated with the current element are . Then, the fact that the element is based on generalized support points, implies that if we apply to a (possibly vector-valued) finite element function , the result must have the form – in other words, the value of the node functional applied to only depends on the values of at and not on values anywhere else, or integrals of , or any other kind of information.
+
The exact form of depends on the element. For example, for scalar Lagrange elements, we have that in fact . If you combine multiple scalar Lagrange elements via an FESystem object, then where is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that where is the normal vector of the face at which the shape function is defined.
+
Given all of this, what this function does is the following: If you input a list of values of a function at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in then you will get out a vector where equals dofs_per_cell.
Parameters
[in]
support_point_values
An array of size dofs_per_cell (which equals the number of points the get_generalized_support_points() function will return) where each element is a vector with as many entries as the element has vector components. This array should contain the values of a function at the generalized support points of the current element.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__DGPMonomial.html differs (JavaScript source, ASCII text, with very long lines (752))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__DGPMonomial.html 2023-11-25 15:25:53.056695828 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__DGPMonomial.html 2023-11-25 15:25:53.056695828 +0100
@@ -491,14 +491,14 @@
The basis functions for this element are chosen to be the monomials listed above. Note that this is the main difference to the FE_DGP class that uses a set of polynomials of complete degree p that form a Legendre basis on the unit square. Thus, there, the mass matrix is diagonal, if the grid cells are parallelograms. The basis here does not have this property; however, it is simpler to compute. On the other hand, this element has the additional disadvantage that the local cell matrices usually have a worse condition number than the ones originating from the FE_DGP element.
This class is not implemented for the codimension one case (spacedim != dim).
Transformation properties
-
It is worth noting that under a (bi-, tri-)linear mapping, the space described by this element does not contain , even if we use a basis of polynomials of degree . Consequently, for example, on meshes with non-affine cells, a linear function can not be exactly represented by elements of type FE_DGP(1) or FE_DGPMonomial(1).
+
It is worth noting that under a (bi-, tri-)linear mapping, the space described by this element does not contain , even if we use a basis of polynomials of degree . Consequently, for example, on meshes with non-affine cells, a linear function can not be exactly represented by elements of type FE_DGP(1) or FE_DGPMonomial(1).
This can be understood by the following 2-d example: consider the cell with vertices at :
-
For this cell, a bilinear transformation produces the relations and that correlate reference coordinates and coordinates in real space . Under this mapping, the constant function is clearly mapped onto itself, but the two other shape functions of the space, namely produces the relations and that correlate reference coordinates and coordinates in real space . Under this mapping, the constant function is clearly mapped onto itself, but the two other shape functions of the space, namely and are mapped onto where .
-
For the simple case that , i.e. if the real cell is the unit square, the expressions can be simplified to and . However, for all other cases, the functions are not linear any more, and neither is any linear combination of them. Consequently, the linear functions are not within the range of the mapped polynomials.
+
For the simple case that , i.e. if the real cell is the unit square, the expressions can be simplified to and . However, for all other cases, the functions are not linear any more, and neither is any linear combination of them. Consequently, the linear functions are not within the range of the mapped polynomials.
Visualization of shape functions
In 2d, the shape functions of this element look as follows.
element
@@ -514,7 +514,7 @@
-
element
+
element
@@ -526,9 +526,9 @@
-
element, shape function 0
+
element, shape function 0
-
element, shape function 1
+
element, shape function 1
@@ -538,7 +538,7 @@
-
element, shape function 2
+
element, shape function 2
@@ -2727,17 +2727,17 @@
Correct the shape Hessians by subtracting the terms corresponding to the Jacobian pushed forward gradient.
Before the correction, the Hessians would be given by
-
+\]" src="form_1140.png"/>
-
where . After the correction, the correct Hessians would be given by
-. After the correction, the correct Hessians would be given by
+
+\]" src="form_1142.png"/>
-
where is the Jacobian pushed-forward derivative.
+
where is the Jacobian pushed-forward derivative.
@@ -2781,21 +2781,21 @@
Correct the shape third derivatives by subtracting the terms corresponding to the Jacobian pushed forward gradient and second derivative.
Before the correction, the third derivatives would be given by
-
+\]" src="form_1144.png"/>
-
where . After the correction, the correct third derivative would be given by
-. After the correction, the correct third derivative would be given by
+
+\]" src="form_1145.png"/>
-
where is the Jacobian pushed-forward derivative and is the Jacobian pushed-forward second derivative.
+
where is the Jacobian pushed-forward derivative and is the Jacobian pushed-forward second derivative.
@@ -3689,7 +3689,7 @@
Returns
The index of this degree of freedom within the set of degrees of freedom on the entire cell. The returned value will be between zero and dofs_per_cell.
-
Note
This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a , then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
+
Note
This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a , then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
Return a block mask with as many elements as this object has blocks and of which exactly the one component is true that corresponds to the given argument. See the glossary for more information.
-
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
scalar
An object that represents a single scalar vector component of this finite element.
@@ -4518,7 +4518,7 @@
Given a component mask (see this glossary entry), produce a block mask (see this glossary entry) that represents the blocks that correspond to the components selected in the input argument. This is essentially a conversion operator from ComponentMask to BlockMask.
-
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
component_mask
The mask that selects individual components of the finite element
@@ -4778,7 +4778,7 @@
Return a vector of generalized support points.
-
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
+
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
For a given degree of freedom, return whether it is logically associated with a vertex, line, quad or hex.
-
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
-
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
-
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
+
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
+
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
+
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
Parameters
[in]
cell_dof_index
The index of a shape function or degree of freedom. This index must be in the range [0,dofs_per_cell).
@@ -4884,11 +4884,11 @@
-
Given the values of a function at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., , where are the node functionals of the element (see also Node values or node functionals). The values are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function , i.e., is the finite element interpolant of with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.
-
In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are and that the node functionals associated with the current element are . Then, the fact that the element is based on generalized support points, implies that if we apply to a (possibly vector-valued) finite element function , the result must have the form – in other words, the value of the node functional applied to only depends on the values of at and not on values anywhere else, or integrals of , or any other kind of information.
-
The exact form of depends on the element. For example, for scalar Lagrange elements, we have that in fact . If you combine multiple scalar Lagrange elements via an FESystem object, then where is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that where is the normal vector of the face at which the shape function is defined.
-
Given all of this, what this function does is the following: If you input a list of values of a function at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in then you will get out a vector where equals dofs_per_cell.
+
Given the values of a function at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., , where are the node functionals of the element (see also Node values or node functionals). The values are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function , i.e., is the finite element interpolant of with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.
+
In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are and that the node functionals associated with the current element are . Then, the fact that the element is based on generalized support points, implies that if we apply to a (possibly vector-valued) finite element function , the result must have the form – in other words, the value of the node functional applied to only depends on the values of at and not on values anywhere else, or integrals of , or any other kind of information.
+
The exact form of depends on the element. For example, for scalar Lagrange elements, we have that in fact . If you combine multiple scalar Lagrange elements via an FESystem object, then where is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that where is the normal vector of the face at which the shape function is defined.
+
Given all of this, what this function does is the following: If you input a list of values of a function at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in then you will get out a vector where equals dofs_per_cell.
Parameters
[in]
support_point_values
An array of size dofs_per_cell (which equals the number of points the get_generalized_support_points() function will return) where each element is a vector with as many entries as the element has vector components. This array should contain the values of a function at the generalized support points of the current element.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__DGPNonparametric.html differs (JavaScript source, ASCII text, with very long lines (752))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__DGPNonparametric.html 2023-11-25 15:25:53.113361342 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__DGPNonparametric.html 2023-11-25 15:25:53.113361342 +0100
@@ -475,7 +475,7 @@
template<int dim, int spacedim = dim>
class FE_DGPNonparametric< dim, spacedim >
Discontinuous finite elements evaluated at the mapped quadrature points.
Warning: this class does not work properly, yet. Don't use it!
-
This finite element implements complete polynomial spaces, that is, -dimensional polynomials of order .
+
This finite element implements complete polynomial spaces, that is, -dimensional polynomials of order .
The polynomials are not mapped. Therefore, they are constant, linear, quadratic, etc. on any grid cell.
Since the polynomials are evaluated at the quadrature points of the actual grid cell, no grid transfer and interpolation matrices are available.
The purpose of this class is experimental, therefore the implementation will remain incomplete.
@@ -495,7 +495,7 @@
-
element
+
element
@@ -507,9 +507,9 @@
-
element, shape function 0
+
element, shape function 0
-
element, shape function 1
+
element, shape function 1
@@ -519,7 +519,7 @@
-
element, shape function 2
+
element, shape function 2
@@ -2753,7 +2753,7 @@
Returns
The index of this degree of freedom within the set of degrees of freedom on the entire cell. The returned value will be between zero and dofs_per_cell.
-
Note
This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a , then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
+
Note
This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a , then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
Return a block mask with as many elements as this object has blocks and of which exactly the one component is true that corresponds to the given argument. See the glossary for more information.
-
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
scalar
An object that represents a single scalar vector component of this finite element.
@@ -3582,7 +3582,7 @@
Given a component mask (see this glossary entry), produce a block mask (see this glossary entry) that represents the blocks that correspond to the components selected in the input argument. This is essentially a conversion operator from ComponentMask to BlockMask.
-
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
component_mask
The mask that selects individual components of the finite element
@@ -3842,7 +3842,7 @@
Return a vector of generalized support points.
-
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
+
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
For a given degree of freedom, return whether it is logically associated with a vertex, line, quad or hex.
-
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
-
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
-
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
+
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
+
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
+
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
Parameters
[in]
cell_dof_index
The index of a shape function or degree of freedom. This index must be in the range [0,dofs_per_cell).
@@ -3948,11 +3948,11 @@
-
Given the values of a function at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., , where are the node functionals of the element (see also Node values or node functionals). The values are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function , i.e., is the finite element interpolant of with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.
-
In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are and that the node functionals associated with the current element are . Then, the fact that the element is based on generalized support points, implies that if we apply to a (possibly vector-valued) finite element function , the result must have the form – in other words, the value of the node functional applied to only depends on the values of at and not on values anywhere else, or integrals of , or any other kind of information.
-
The exact form of depends on the element. For example, for scalar Lagrange elements, we have that in fact . If you combine multiple scalar Lagrange elements via an FESystem object, then where is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that where is the normal vector of the face at which the shape function is defined.
-
Given all of this, what this function does is the following: If you input a list of values of a function at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in then you will get out a vector where equals dofs_per_cell.
+
Given the values of a function at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., , where are the node functionals of the element (see also Node values or node functionals). The values are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function , i.e., is the finite element interpolant of with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.
+
In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are and that the node functionals associated with the current element are . Then, the fact that the element is based on generalized support points, implies that if we apply to a (possibly vector-valued) finite element function , the result must have the form – in other words, the value of the node functional applied to only depends on the values of at and not on values anywhere else, or integrals of , or any other kind of information.
+
The exact form of depends on the element. For example, for scalar Lagrange elements, we have that in fact . If you combine multiple scalar Lagrange elements via an FESystem object, then where is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that where is the normal vector of the face at which the shape function is defined.
+
Given all of this, what this function does is the following: If you input a list of values of a function at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in then you will get out a vector where equals dofs_per_cell.
Parameters
[in]
support_point_values
An array of size dofs_per_cell (which equals the number of points the get_generalized_support_points() function will return) where each element is a vector with as many entries as the element has vector components. This array should contain the values of a function at the generalized support points of the current element.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__DGQ.html differs (JavaScript source, ASCII text, with very long lines (752))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__DGQ.html 2023-11-25 15:25:53.170026853 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__DGQ.html 2023-11-25 15:25:53.170026853 +0100
@@ -505,7 +505,7 @@
*
with node 13 being placed in the interior of the hex.
Note, however, that these are just the Lagrange interpolation points of the shape functions. Even though they may physically be on the boundary of the cell, they are logically in the interior since there are no continuity requirements for these shape functions across cell boundaries. While discontinuous, when restricted to a single cell the shape functions of this element are exactly the same as those of the FE_Q element where they are shown visually.
Unit support point distribution and conditioning of interpolation
-
When constructing an FE_DGQ element at polynomial degrees one or two, equidistant support points at 0 and 1 (linear case) or 0, 0.5, and 1 (quadratic case) are used. The unit support or nodal points xi are those points where the jth Lagrange polynomial satisfies the property, i.e., where one polynomial is one and all the others are zero. For higher polynomial degrees, the support points are non-equidistant by default, and chosen to be the support points of the (degree+1)-order Gauss-Lobatto quadrature rule. This point distribution yields well-conditioned Lagrange interpolation at arbitrary polynomial degrees. By contrast, polynomials based on equidistant points get increasingly ill-conditioned as the polynomial degree increases. In interpolation, this effect is known as the Runge phenomenon. For Galerkin methods, the Runge phenomenon is typically not visible in the solution quality but rather in the condition number of the associated system matrices. For example, the elemental mass matrix of equidistant points at degree 10 has condition number 2.6e6, whereas the condition number for Gauss-Lobatto points is around 400.
+
When constructing an FE_DGQ element at polynomial degrees one or two, equidistant support points at 0 and 1 (linear case) or 0, 0.5, and 1 (quadratic case) are used. The unit support or nodal points xi are those points where the jth Lagrange polynomial satisfies the property, i.e., where one polynomial is one and all the others are zero. For higher polynomial degrees, the support points are non-equidistant by default, and chosen to be the support points of the (degree+1)-order Gauss-Lobatto quadrature rule. This point distribution yields well-conditioned Lagrange interpolation at arbitrary polynomial degrees. By contrast, polynomials based on equidistant points get increasingly ill-conditioned as the polynomial degree increases. In interpolation, this effect is known as the Runge phenomenon. For Galerkin methods, the Runge phenomenon is typically not visible in the solution quality but rather in the condition number of the associated system matrices. For example, the elemental mass matrix of equidistant points at degree 10 has condition number 2.6e6, whereas the condition number for Gauss-Lobatto points is around 400.
The Gauss-Lobatto points in 1d include the end points 0 and +1 of the unit interval. The interior points are shifted towards the end points, which gives a denser point distribution close to the element boundary.
Correct the shape Hessians by subtracting the terms corresponding to the Jacobian pushed forward gradient.
Before the correction, the Hessians would be given by
-
+\]" src="form_1140.png"/>
-
where . After the correction, the correct Hessians would be given by
-. After the correction, the correct Hessians would be given by
+
+\]" src="form_1142.png"/>
-
where is the Jacobian pushed-forward derivative.
+
where is the Jacobian pushed-forward derivative.
@@ -2601,21 +2601,21 @@
Correct the shape third derivatives by subtracting the terms corresponding to the Jacobian pushed forward gradient and second derivative.
Before the correction, the third derivatives would be given by
-
+\]" src="form_1144.png"/>
-
where . After the correction, the correct third derivative would be given by
-. After the correction, the correct third derivative would be given by
+
+\]" src="form_1145.png"/>
-
where is the Jacobian pushed-forward derivative and is the Jacobian pushed-forward second derivative.
+
where is the Jacobian pushed-forward derivative and is the Jacobian pushed-forward second derivative.
@@ -3168,7 +3168,7 @@
Returns
The index of this degree of freedom within the set of degrees of freedom on the entire cell. The returned value will be between zero and dofs_per_cell.
-
Note
This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a , then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
+
Note
This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a , then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
Return a block mask with as many elements as this object has blocks and of which exactly the one component is true that corresponds to the given argument. See the glossary for more information.
-
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
scalar
An object that represents a single scalar vector component of this finite element.
@@ -3997,7 +3997,7 @@
Given a component mask (see this glossary entry), produce a block mask (see this glossary entry) that represents the blocks that correspond to the components selected in the input argument. This is essentially a conversion operator from ComponentMask to BlockMask.
-
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
component_mask
The mask that selects individual components of the finite element
@@ -4226,7 +4226,7 @@
Return a vector of generalized support points.
-
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
+
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
For a given degree of freedom, return whether it is logically associated with a vertex, line, quad or hex.
-
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
-
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
-
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
+
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
+
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
+
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
Parameters
[in]
cell_dof_index
The index of a shape function or degree of freedom. This index must be in the range [0,dofs_per_cell).
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__DGQArbitraryNodes.html differs (JavaScript source, ASCII text, with very long lines (752))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__DGQArbitraryNodes.html 2023-11-25 15:25:53.230025634 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__DGQArbitraryNodes.html 2023-11-25 15:25:53.223359103 +0100
@@ -2475,17 +2475,17 @@
Correct the shape Hessians by subtracting the terms corresponding to the Jacobian pushed forward gradient.
Before the correction, the Hessians would be given by
-
+\]" src="form_1140.png"/>
-
where . After the correction, the correct Hessians would be given by
-. After the correction, the correct Hessians would be given by
+
+\]" src="form_1142.png"/>
-
where is the Jacobian pushed-forward derivative.
+
where is the Jacobian pushed-forward derivative.
@@ -2529,21 +2529,21 @@
Correct the shape third derivatives by subtracting the terms corresponding to the Jacobian pushed forward gradient and second derivative.
Before the correction, the third derivatives would be given by
-
+\]" src="form_1144.png"/>
-
where . After the correction, the correct third derivative would be given by
-. After the correction, the correct third derivative would be given by
+
+\]" src="form_1145.png"/>
-
where is the Jacobian pushed-forward derivative and is the Jacobian pushed-forward second derivative.
+
where is the Jacobian pushed-forward derivative and is the Jacobian pushed-forward second derivative.
@@ -3096,7 +3096,7 @@
Returns
The index of this degree of freedom within the set of degrees of freedom on the entire cell. The returned value will be between zero and dofs_per_cell.
-
Note
This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a , then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
+
Note
This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a , then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
Return a block mask with as many elements as this object has blocks and of which exactly the one component is true that corresponds to the given argument. See the glossary for more information.
-
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
scalar
An object that represents a single scalar vector component of this finite element.
@@ -3925,7 +3925,7 @@
Given a component mask (see this glossary entry), produce a block mask (see this glossary entry) that represents the blocks that correspond to the components selected in the input argument. This is essentially a conversion operator from ComponentMask to BlockMask.
-
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
component_mask
The mask that selects individual components of the finite element
@@ -4154,7 +4154,7 @@
Return a vector of generalized support points.
-
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
+
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
For a given degree of freedom, return whether it is logically associated with a vertex, line, quad or hex.
-
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
-
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
-
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
+
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
+
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
+
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
Parameters
[in]
cell_dof_index
The index of a shape function or degree of freedom. This index must be in the range [0,dofs_per_cell).
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__DGQHermite.html differs (JavaScript source, ASCII text, with very long lines (752))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__DGQHermite.html 2023-11-25 15:25:53.283357881 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__DGQHermite.html 2023-11-25 15:25:53.283357881 +0100
@@ -2479,17 +2479,17 @@
Correct the shape Hessians by subtracting the terms corresponding to the Jacobian pushed forward gradient.
Before the correction, the Hessians would be given by
-
+\]" src="form_1140.png"/>
-
where . After the correction, the correct Hessians would be given by
-. After the correction, the correct Hessians would be given by
+
+\]" src="form_1142.png"/>
-
where is the Jacobian pushed-forward derivative.
+
where is the Jacobian pushed-forward derivative.
@@ -2533,21 +2533,21 @@
Correct the shape third derivatives by subtracting the terms corresponding to the Jacobian pushed forward gradient and second derivative.
Before the correction, the third derivatives would be given by
-
+\]" src="form_1144.png"/>
-
where . After the correction, the correct third derivative would be given by
-. After the correction, the correct third derivative would be given by
+
+\]" src="form_1145.png"/>
-
where is the Jacobian pushed-forward derivative and is the Jacobian pushed-forward second derivative.
+
where is the Jacobian pushed-forward derivative and is the Jacobian pushed-forward second derivative.
@@ -3100,7 +3100,7 @@
Returns
The index of this degree of freedom within the set of degrees of freedom on the entire cell. The returned value will be between zero and dofs_per_cell.
-
Note
This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a , then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
+
Note
This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a , then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
Return a block mask with as many elements as this object has blocks and of which exactly the one component is true that corresponds to the given argument. See the glossary for more information.
-
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
scalar
An object that represents a single scalar vector component of this finite element.
@@ -3929,7 +3929,7 @@
Given a component mask (see this glossary entry), produce a block mask (see this glossary entry) that represents the blocks that correspond to the components selected in the input argument. This is essentially a conversion operator from ComponentMask to BlockMask.
-
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
component_mask
The mask that selects individual components of the finite element
@@ -4158,7 +4158,7 @@
Return a vector of generalized support points.
-
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
+
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
For a given degree of freedom, return whether it is logically associated with a vertex, line, quad or hex.
-
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
-
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
-
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
+
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
+
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
+
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
Parameters
[in]
cell_dof_index
The index of a shape function or degree of freedom. This index must be in the range [0,dofs_per_cell).
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__DGQLegendre.html differs (JavaScript source, ASCII text, with very long lines (752))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__DGQLegendre.html 2023-11-25 15:25:53.336690130 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__DGQLegendre.html 2023-11-25 15:25:53.336690130 +0100
@@ -2477,17 +2477,17 @@
Correct the shape Hessians by subtracting the terms corresponding to the Jacobian pushed forward gradient.
Before the correction, the Hessians would be given by
-
+\]" src="form_1140.png"/>
-
where . After the correction, the correct Hessians would be given by
-. After the correction, the correct Hessians would be given by
+
+\]" src="form_1142.png"/>
-
where is the Jacobian pushed-forward derivative.
+
where is the Jacobian pushed-forward derivative.
@@ -2531,21 +2531,21 @@
Correct the shape third derivatives by subtracting the terms corresponding to the Jacobian pushed forward gradient and second derivative.
Before the correction, the third derivatives would be given by
-
+\]" src="form_1144.png"/>
-
where . After the correction, the correct third derivative would be given by
-. After the correction, the correct third derivative would be given by
+
+\]" src="form_1145.png"/>
-
where is the Jacobian pushed-forward derivative and is the Jacobian pushed-forward second derivative.
+
where is the Jacobian pushed-forward derivative and is the Jacobian pushed-forward second derivative.
@@ -3098,7 +3098,7 @@
Returns
The index of this degree of freedom within the set of degrees of freedom on the entire cell. The returned value will be between zero and dofs_per_cell.
-
Note
This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a , then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
+
Note
This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a , then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
Return a block mask with as many elements as this object has blocks and of which exactly the one component is true that corresponds to the given argument. See the glossary for more information.
-
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
scalar
An object that represents a single scalar vector component of this finite element.
@@ -3927,7 +3927,7 @@
Given a component mask (see this glossary entry), produce a block mask (see this glossary entry) that represents the blocks that correspond to the components selected in the input argument. This is essentially a conversion operator from ComponentMask to BlockMask.
-
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
component_mask
The mask that selects individual components of the finite element
@@ -4156,7 +4156,7 @@
Return a vector of generalized support points.
-
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
+
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
For a given degree of freedom, return whether it is logically associated with a vertex, line, quad or hex.
-
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
-
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
-
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
+
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
+
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
+
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
Parameters
[in]
cell_dof_index
The index of a shape function or degree of freedom. This index must be in the range [0,dofs_per_cell).
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__DGRaviartThomas.html differs (JavaScript source, ASCII text, with very long lines (752))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__DGRaviartThomas.html 2023-11-25 15:25:53.393355641 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__DGRaviartThomas.html 2023-11-25 15:25:53.393355641 +0100
@@ -2851,7 +2851,7 @@
Returns
The index of this degree of freedom within the set of degrees of freedom on the entire cell. The returned value will be between zero and dofs_per_cell.
-
Note
This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a , then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
+
Note
This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a , then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
Return a block mask with as many elements as this object has blocks and of which exactly the one component is true that corresponds to the given argument. See the glossary for more information.
-
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
scalar
An object that represents a single scalar vector component of this finite element.
@@ -3680,7 +3680,7 @@
Given a component mask (see this glossary entry), produce a block mask (see this glossary entry) that represents the blocks that correspond to the components selected in the input argument. This is essentially a conversion operator from ComponentMask to BlockMask.
-
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
component_mask
The mask that selects individual components of the finite element
@@ -3940,7 +3940,7 @@
Return a vector of generalized support points.
-
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
+
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
For a given degree of freedom, return whether it is logically associated with a vertex, line, quad or hex.
-
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
-
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
-
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
+
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
+
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
+
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
Parameters
[in]
cell_dof_index
The index of a shape function or degree of freedom. This index must be in the range [0,dofs_per_cell).
@@ -4046,11 +4046,11 @@
-
Given the values of a function at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., , where are the node functionals of the element (see also Node values or node functionals). The values are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function , i.e., is the finite element interpolant of with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.
-
In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are and that the node functionals associated with the current element are . Then, the fact that the element is based on generalized support points, implies that if we apply to a (possibly vector-valued) finite element function , the result must have the form – in other words, the value of the node functional applied to only depends on the values of at and not on values anywhere else, or integrals of , or any other kind of information.
-
The exact form of depends on the element. For example, for scalar Lagrange elements, we have that in fact . If you combine multiple scalar Lagrange elements via an FESystem object, then where is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that where is the normal vector of the face at which the shape function is defined.
-
Given all of this, what this function does is the following: If you input a list of values of a function at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in then you will get out a vector where equals dofs_per_cell.
+
Given the values of a function at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., , where are the node functionals of the element (see also Node values or node functionals). The values are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function , i.e., is the finite element interpolant of with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.
+
In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are and that the node functionals associated with the current element are . Then, the fact that the element is based on generalized support points, implies that if we apply to a (possibly vector-valued) finite element function , the result must have the form – in other words, the value of the node functional applied to only depends on the values of at and not on values anywhere else, or integrals of , or any other kind of information.
+
The exact form of depends on the element. For example, for scalar Lagrange elements, we have that in fact . If you combine multiple scalar Lagrange elements via an FESystem object, then where is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that where is the normal vector of the face at which the shape function is defined.
+
Given all of this, what this function does is the following: If you input a list of values of a function at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in then you will get out a vector where equals dofs_per_cell.
Parameters
[in]
support_point_values
An array of size dofs_per_cell (which equals the number of points the get_generalized_support_points() function will return) where each element is a vector with as many entries as the element has vector components. This array should contain the values of a function at the generalized support points of the current element.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__DGVector.html differs (JavaScript source, ASCII text, with very long lines (752))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__DGVector.html 2023-11-25 15:25:53.453354423 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__DGVector.html 2023-11-25 15:25:53.453354423 +0100
@@ -2869,7 +2869,7 @@
Returns
The index of this degree of freedom within the set of degrees of freedom on the entire cell. The returned value will be between zero and dofs_per_cell.
-
Note
This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a , then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
+
Note
This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a , then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
Return a block mask with as many elements as this object has blocks and of which exactly the one component is true that corresponds to the given argument. See the glossary for more information.
-
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
scalar
An object that represents a single scalar vector component of this finite element.
@@ -3698,7 +3698,7 @@
Given a component mask (see this glossary entry), produce a block mask (see this glossary entry) that represents the blocks that correspond to the components selected in the input argument. This is essentially a conversion operator from ComponentMask to BlockMask.
-
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
component_mask
The mask that selects individual components of the finite element
@@ -3958,7 +3958,7 @@
Return a vector of generalized support points.
-
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
+
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
For a given degree of freedom, return whether it is logically associated with a vertex, line, quad or hex.
-
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
-
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
-
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
+
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
+
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
+
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
Parameters
[in]
cell_dof_index
The index of a shape function or degree of freedom. This index must be in the range [0,dofs_per_cell).
@@ -4064,11 +4064,11 @@
-
Given the values of a function at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., , where are the node functionals of the element (see also Node values or node functionals). The values are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function , i.e., is the finite element interpolant of with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.
-
In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are and that the node functionals associated with the current element are . Then, the fact that the element is based on generalized support points, implies that if we apply to a (possibly vector-valued) finite element function , the result must have the form – in other words, the value of the node functional applied to only depends on the values of at and not on values anywhere else, or integrals of , or any other kind of information.
-
The exact form of depends on the element. For example, for scalar Lagrange elements, we have that in fact . If you combine multiple scalar Lagrange elements via an FESystem object, then where is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that where is the normal vector of the face at which the shape function is defined.
-
Given all of this, what this function does is the following: If you input a list of values of a function at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in then you will get out a vector where equals dofs_per_cell.
+
Given the values of a function at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., , where are the node functionals of the element (see also Node values or node functionals). The values are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function , i.e., is the finite element interpolant of with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.
+
In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are and that the node functionals associated with the current element are . Then, the fact that the element is based on generalized support points, implies that if we apply to a (possibly vector-valued) finite element function , the result must have the form – in other words, the value of the node functional applied to only depends on the values of at and not on values anywhere else, or integrals of , or any other kind of information.
+
The exact form of depends on the element. For example, for scalar Lagrange elements, we have that in fact . If you combine multiple scalar Lagrange elements via an FESystem object, then where is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that where is the normal vector of the face at which the shape function is defined.
+
Given all of this, what this function does is the following: If you input a list of values of a function at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in then you will get out a vector where equals dofs_per_cell.
Parameters
[in]
support_point_values
An array of size dofs_per_cell (which equals the number of points the get_generalized_support_points() function will return) where each element is a vector with as many entries as the element has vector components. This array should contain the values of a function at the generalized support points of the current element.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__Enriched.html differs (JavaScript source, ASCII text, with very long lines (864))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__Enriched.html 2023-11-25 15:25:53.510019933 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__Enriched.html 2023-11-25 15:25:53.510019933 +0100
@@ -483,12 +483,12 @@
Detailed Description
template<int dim, int spacedim = dim>
class FE_Enriched< dim, spacedim >
Implementation of a partition of unity finite element method (PUM) by Babuska and Melenk which enriches a standard finite element with an enrichment function multiplied with another (usually linear) finite element:
where and are the underlying finite elements (including the mapping from the isoparametric element to the real element); are the scalar enrichment functions in real space (e.g. , , etc); and are the standard and enriched DoFs. This allows to include in the finite element space a priori knowledge about the partial differential equation being solved which in turn improves the local approximation properties of the spaces. This can be useful for highly oscillatory solutions, problems with domain corners or on unbounded domains or sudden changes of boundary conditions. PUM method uses finite element spaces which satisfy the partition of unity property (e.g. FE_Q). Among other properties this makes the resulting space to reproduce enrichment functions exactly.
+
where and are the underlying finite elements (including the mapping from the isoparametric element to the real element); are the scalar enrichment functions in real space (e.g. , , etc); and are the standard and enriched DoFs. This allows to include in the finite element space a priori knowledge about the partial differential equation being solved which in turn improves the local approximation properties of the spaces. This can be useful for highly oscillatory solutions, problems with domain corners or on unbounded domains or sudden changes of boundary conditions. PUM method uses finite element spaces which satisfy the partition of unity property (e.g. FE_Q). Among other properties this makes the resulting space to reproduce enrichment functions exactly.
The simplest constructor of this class takes two finite element objects and an enrichment function to be used. For example
In this case, standard DoFs are distributed by FE_Q<dim>(2), whereas enriched DoFs are coming from a single finite element FE_Q<dim>(1) used with a single enrichment function function. In this case, the total number of DoFs on the enriched element is the sum of DoFs from FE_Q<dim>(2) and FE_Q<dim>(1).
-
As an example of an enrichment function, consider , which leads to the following shape functions on the unit element:
+
As an example of an enrichment function, consider , which leads to the following shape functions on the unit element:
@@ -509,7 +509,7 @@
1d element, base and enriched shape functions.
enriched shape function corresponding to the central vertex.
Note that evaluation of gradients (hessians) of the enriched shape functions or the finite element field requires evaluation of gradients (gradients and hessians) of the enrichment functions:
-
+\end{align*}" src="form_1086.png"/>
Using enriched and non-enriched FEs together
-
In most applications it is beneficial to introduce enrichments only in some part of the domain (e.g. around a crack tip) and use standard FE (e.g. FE_Q) elsewhere. This can be achieved by using the hp-finite element framework in deal.II that allows for the use of different elements on different cells. To make the resulting space continuous, it is then necessary for the DoFHandler class and DoFTools::make_hanging_node_constraints() function to be able to figure out what to do at the interface between enriched and non-enriched cells. Specifically, we want the degrees of freedom corresponding to enriched shape functions to be zero at these interfaces. These classes and functions can not to do this automatically, but the effect can be achieved by using not just a regular FE_Q on cells without enrichment, but to wrap the FE_Q into an FE_Enriched object without actually enriching it. This can be done as follows:
In most applications it is beneficial to introduce enrichments only in some part of the domain (e.g. around a crack tip) and use standard FE (e.g. FE_Q) elsewhere. This can be achieved by using the hp-finite element framework in deal.II that allows for the use of different elements on different cells. To make the resulting space continuous, it is then necessary for the DoFHandler class and DoFTools::make_hanging_node_constraints() function to be able to figure out what to do at the interface between enriched and non-enriched cells. Specifically, we want the degrees of freedom corresponding to enriched shape functions to be zero at these interfaces. These classes and functions can not to do this automatically, but the effect can be achieved by using not just a regular FE_Q on cells without enrichment, but to wrap the FE_Q into an FE_Enriched object without actually enriching it. This can be done as follows:
The index of this degree of freedom within the set of degrees of freedom on the entire cell. The returned value will be between zero and dofs_per_cell.
-
Note
This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a , then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
+
Note
This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a , then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
Return a block mask with as many elements as this object has blocks and of which exactly the one component is true that corresponds to the given argument. See the glossary for more information.
-
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
scalar
An object that represents a single scalar vector component of this finite element.
@@ -3726,7 +3726,7 @@
Given a component mask (see this glossary entry), produce a block mask (see this glossary entry) that represents the blocks that correspond to the components selected in the input argument. This is essentially a conversion operator from ComponentMask to BlockMask.
-
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
component_mask
The mask that selects individual components of the finite element
@@ -3986,7 +3986,7 @@
Return a vector of generalized support points.
-
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
+
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
For a given degree of freedom, return whether it is logically associated with a vertex, line, quad or hex.
-
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
-
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
-
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
+
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
+
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
+
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
Parameters
[in]
cell_dof_index
The index of a shape function or degree of freedom. This index must be in the range [0,dofs_per_cell).
@@ -4092,11 +4092,11 @@
-
Given the values of a function at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., , where are the node functionals of the element (see also Node values or node functionals). The values are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function , i.e., is the finite element interpolant of with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.
-
In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are and that the node functionals associated with the current element are . Then, the fact that the element is based on generalized support points, implies that if we apply to a (possibly vector-valued) finite element function , the result must have the form – in other words, the value of the node functional applied to only depends on the values of at and not on values anywhere else, or integrals of , or any other kind of information.
-
The exact form of depends on the element. For example, for scalar Lagrange elements, we have that in fact . If you combine multiple scalar Lagrange elements via an FESystem object, then where is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that where is the normal vector of the face at which the shape function is defined.
-
Given all of this, what this function does is the following: If you input a list of values of a function at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in then you will get out a vector where equals dofs_per_cell.
+
Given the values of a function at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., , where are the node functionals of the element (see also Node values or node functionals). The values are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function , i.e., is the finite element interpolant of with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.
+
In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are and that the node functionals associated with the current element are . Then, the fact that the element is based on generalized support points, implies that if we apply to a (possibly vector-valued) finite element function , the result must have the form – in other words, the value of the node functional applied to only depends on the values of at and not on values anywhere else, or integrals of , or any other kind of information.
+
The exact form of depends on the element. For example, for scalar Lagrange elements, we have that in fact . If you combine multiple scalar Lagrange elements via an FESystem object, then where is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that where is the normal vector of the face at which the shape function is defined.
+
Given all of this, what this function does is the following: If you input a list of values of a function at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in then you will get out a vector where equals dofs_per_cell.
Parameters
[in]
support_point_values
An array of size dofs_per_cell (which equals the number of points the get_generalized_support_points() function will return) where each element is a vector with as many entries as the element has vector components. This array should contain the values of a function at the generalized support points of the current element.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__FaceP.html differs (JavaScript source, ASCII text, with very long lines (752))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__FaceP.html 2023-11-25 15:25:53.566685447 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__FaceP.html 2023-11-25 15:25:53.566685447 +0100
@@ -2936,7 +2936,7 @@
Returns
The index of this degree of freedom within the set of degrees of freedom on the entire cell. The returned value will be between zero and dofs_per_cell.
-
Note
This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a , then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
+
Note
This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a , then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
Return a block mask with as many elements as this object has blocks and of which exactly the one component is true that corresponds to the given argument. See the glossary for more information.
-
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
scalar
An object that represents a single scalar vector component of this finite element.
@@ -3765,7 +3765,7 @@
Given a component mask (see this glossary entry), produce a block mask (see this glossary entry) that represents the blocks that correspond to the components selected in the input argument. This is essentially a conversion operator from ComponentMask to BlockMask.
-
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
component_mask
The mask that selects individual components of the finite element
@@ -3994,7 +3994,7 @@
Return a vector of generalized support points.
-
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
+
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
For a given degree of freedom, return whether it is logically associated with a vertex, line, quad or hex.
-
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
-
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
-
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
+
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
+
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
+
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
Parameters
[in]
cell_dof_index
The index of a shape function or degree of freedom. This index must be in the range [0,dofs_per_cell).
@@ -4100,11 +4100,11 @@
-
Given the values of a function at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., , where are the node functionals of the element (see also Node values or node functionals). The values are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function , i.e., is the finite element interpolant of with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.
-
In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are and that the node functionals associated with the current element are . Then, the fact that the element is based on generalized support points, implies that if we apply to a (possibly vector-valued) finite element function , the result must have the form – in other words, the value of the node functional applied to only depends on the values of at and not on values anywhere else, or integrals of , or any other kind of information.
-
The exact form of depends on the element. For example, for scalar Lagrange elements, we have that in fact . If you combine multiple scalar Lagrange elements via an FESystem object, then where is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that where is the normal vector of the face at which the shape function is defined.
-
Given all of this, what this function does is the following: If you input a list of values of a function at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in then you will get out a vector where equals dofs_per_cell.
+
Given the values of a function at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., , where are the node functionals of the element (see also Node values or node functionals). The values are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function , i.e., is the finite element interpolant of with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.
+
In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are and that the node functionals associated with the current element are . Then, the fact that the element is based on generalized support points, implies that if we apply to a (possibly vector-valued) finite element function , the result must have the form – in other words, the value of the node functional applied to only depends on the values of at and not on values anywhere else, or integrals of , or any other kind of information.
+
The exact form of depends on the element. For example, for scalar Lagrange elements, we have that in fact . If you combine multiple scalar Lagrange elements via an FESystem object, then where is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that where is the normal vector of the face at which the shape function is defined.
+
Given all of this, what this function does is the following: If you input a list of values of a function at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in then you will get out a vector where equals dofs_per_cell.
Parameters
[in]
support_point_values
An array of size dofs_per_cell (which equals the number of points the get_generalized_support_points() function will return) where each element is a vector with as many entries as the element has vector components. This array should contain the values of a function at the generalized support points of the current element.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__FaceP_3_011_00_01spacedim_01_4.html differs (JavaScript source, ASCII text, with very long lines (752))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__FaceP_3_011_00_01spacedim_01_4.html 2023-11-25 15:25:53.620017697 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__FaceP_3_011_00_01spacedim_01_4.html 2023-11-25 15:25:53.620017697 +0100
@@ -3140,7 +3140,7 @@
Returns
The index of this degree of freedom within the set of degrees of freedom on the entire cell. The returned value will be between zero and dofs_per_cell.
-
Note
This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a , then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
+
Note
This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a , then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
@@ -3811,7 +3811,7 @@
Return a block mask with as many elements as this object has blocks and of which exactly the one component is true that corresponds to the given argument. See the glossary for more information.
-
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
scalar
An object that represents a single scalar vector component of this finite element.
@@ -3913,7 +3913,7 @@
Given a component mask (see this glossary entry), produce a block mask (see this glossary entry) that represents the blocks that correspond to the components selected in the input argument. This is essentially a conversion operator from ComponentMask to BlockMask.
-
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
component_mask
The mask that selects individual components of the finite element
@@ -4124,7 +4124,7 @@
Return a vector of generalized support points.
-
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
+
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
For a given degree of freedom, return whether it is logically associated with a vertex, line, quad or hex.
-
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
-
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
-
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
+
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
+
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
+
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
Parameters
[in]
cell_dof_index
The index of a shape function or degree of freedom. This index must be in the range [0,dofs_per_cell).
@@ -4224,11 +4224,11 @@
-
Given the values of a function at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., , where are the node functionals of the element (see also Node values or node functionals). The values are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function , i.e., is the finite element interpolant of with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.
-
In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are and that the node functionals associated with the current element are . Then, the fact that the element is based on generalized support points, implies that if we apply to a (possibly vector-valued) finite element function , the result must have the form – in other words, the value of the node functional applied to only depends on the values of at and not on values anywhere else, or integrals of , or any other kind of information.
-
The exact form of depends on the element. For example, for scalar Lagrange elements, we have that in fact . If you combine multiple scalar Lagrange elements via an FESystem object, then where is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that where is the normal vector of the face at which the shape function is defined.
-
Given all of this, what this function does is the following: If you input a list of values of a function at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in then you will get out a vector where equals dofs_per_cell.
+
Given the values of a function at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., , where are the node functionals of the element (see also Node values or node functionals). The values are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function , i.e., is the finite element interpolant of with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.
+
In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are and that the node functionals associated with the current element are . Then, the fact that the element is based on generalized support points, implies that if we apply to a (possibly vector-valued) finite element function , the result must have the form – in other words, the value of the node functional applied to only depends on the values of at and not on values anywhere else, or integrals of , or any other kind of information.
+
The exact form of depends on the element. For example, for scalar Lagrange elements, we have that in fact . If you combine multiple scalar Lagrange elements via an FESystem object, then where is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that where is the normal vector of the face at which the shape function is defined.
+
Given all of this, what this function does is the following: If you input a list of values of a function at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in then you will get out a vector where equals dofs_per_cell.
Parameters
[in]
support_point_values
An array of size dofs_per_cell (which equals the number of points the get_generalized_support_points() function will return) where each element is a vector with as many entries as the element has vector components. This array should contain the values of a function at the generalized support points of the current element.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__FaceQ.html differs (JavaScript source, ASCII text, with very long lines (752))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__FaceQ.html 2023-11-25 15:25:53.676683211 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__FaceQ.html 2023-11-25 15:25:53.683349739 +0100
@@ -2987,7 +2987,7 @@
Returns
The index of this degree of freedom within the set of degrees of freedom on the entire cell. The returned value will be between zero and dofs_per_cell.
-
Note
This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a , then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
+
Note
This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a , then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
Return a block mask with as many elements as this object has blocks and of which exactly the one component is true that corresponds to the given argument. See the glossary for more information.
-
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
scalar
An object that represents a single scalar vector component of this finite element.
@@ -3816,7 +3816,7 @@
Given a component mask (see this glossary entry), produce a block mask (see this glossary entry) that represents the blocks that correspond to the components selected in the input argument. This is essentially a conversion operator from ComponentMask to BlockMask.
-
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
component_mask
The mask that selects individual components of the finite element
@@ -4045,7 +4045,7 @@
Return a vector of generalized support points.
-
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
+
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
For a given degree of freedom, return whether it is logically associated with a vertex, line, quad or hex.
-
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
-
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
-
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
+
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
+
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
+
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
Parameters
[in]
cell_dof_index
The index of a shape function or degree of freedom. This index must be in the range [0,dofs_per_cell).
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__FaceQ_3_011_00_01spacedim_01_4.html differs (JavaScript source, ASCII text, with very long lines (752))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__FaceQ_3_011_00_01spacedim_01_4.html 2023-11-25 15:25:53.736681990 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__FaceQ_3_011_00_01spacedim_01_4.html 2023-11-25 15:25:53.736681990 +0100
@@ -2606,7 +2606,7 @@
Returns
The index of this degree of freedom within the set of degrees of freedom on the entire cell. The returned value will be between zero and dofs_per_cell.
-
Note
This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a , then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
+
Note
This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a , then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
@@ -3277,7 +3277,7 @@
Return a block mask with as many elements as this object has blocks and of which exactly the one component is true that corresponds to the given argument. See the glossary for more information.
-
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
scalar
An object that represents a single scalar vector component of this finite element.
@@ -3379,7 +3379,7 @@
Given a component mask (see this glossary entry), produce a block mask (see this glossary entry) that represents the blocks that correspond to the components selected in the input argument. This is essentially a conversion operator from ComponentMask to BlockMask.
-
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
component_mask
The mask that selects individual components of the finite element
@@ -3590,7 +3590,7 @@
Return a vector of generalized support points.
-
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
+
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
For a given degree of freedom, return whether it is logically associated with a vertex, line, quad or hex.
-
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
-
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
-
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
+
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
+
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
+
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
Parameters
[in]
cell_dof_index
The index of a shape function or degree of freedom. This index must be in the range [0,dofs_per_cell).
@@ -3690,11 +3690,11 @@
-
Given the values of a function at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., , where are the node functionals of the element (see also Node values or node functionals). The values are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function , i.e., is the finite element interpolant of with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.
-
In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are and that the node functionals associated with the current element are . Then, the fact that the element is based on generalized support points, implies that if we apply to a (possibly vector-valued) finite element function , the result must have the form – in other words, the value of the node functional applied to only depends on the values of at and not on values anywhere else, or integrals of , or any other kind of information.
-
The exact form of depends on the element. For example, for scalar Lagrange elements, we have that in fact . If you combine multiple scalar Lagrange elements via an FESystem object, then where is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that where is the normal vector of the face at which the shape function is defined.
-
Given all of this, what this function does is the following: If you input a list of values of a function at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in then you will get out a vector where equals dofs_per_cell.
+
Given the values of a function at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., , where are the node functionals of the element (see also Node values or node functionals). The values are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function , i.e., is the finite element interpolant of with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.
+
In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are and that the node functionals associated with the current element are . Then, the fact that the element is based on generalized support points, implies that if we apply to a (possibly vector-valued) finite element function , the result must have the form – in other words, the value of the node functional applied to only depends on the values of at and not on values anywhere else, or integrals of , or any other kind of information.
+
The exact form of depends on the element. For example, for scalar Lagrange elements, we have that in fact . If you combine multiple scalar Lagrange elements via an FESystem object, then where is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that where is the normal vector of the face at which the shape function is defined.
+
Given all of this, what this function does is the following: If you input a list of values of a function at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in then you will get out a vector where equals dofs_per_cell.
Parameters
[in]
support_point_values
An array of size dofs_per_cell (which equals the number of points the get_generalized_support_points() function will return) where each element is a vector with as many entries as the element has vector components. This array should contain the values of a function at the generalized support points of the current element.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__Nedelec.html differs (JavaScript source, ASCII text, with very long lines (752))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__Nedelec.html 2023-11-25 15:25:53.796680768 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__Nedelec.html 2023-11-25 15:25:53.796680768 +0100
@@ -507,12 +507,12 @@
Several aspects of the implementation are experimental. For the moment, it is safe to use the element on globally refined meshes with consistent orientation of faces. See the todo entries below for more detailed caveats.
-
Implementation of Nédélec elements. The Nédélec space is designed to solve problems in which the solution only lives in the space , rather than in the more commonly used space . In other words, the solution must be a vector field whose curl is square integrable, but for which the gradient may not be square integrable. The typical application for this space (and these elements) is to the Maxwell equations and corresponding simplifications, such as the reduced version of the Maxwell equation that only involves the electric field which has to satisfy the equation in the time independent case when no currents are present, or the equation that the magnetic vector potential has to satisfy in the time independent case.
-
The defining characteristic of functions in is that they are in general discontinuous – but that if you draw a line in 2d (or a surface in 3d), then the tangential component(s) of the vector field must be continuous across the line (or surface) even though the normal component may not be. As a consequence, the Nédélec element is constructed in such a way that (i) it is vector-valued, (ii) the shape functions are discontinuous, but (iii) the tangential component(s) of the vector field represented by each shape function are continuous across the faces of cells.
+
Implementation of Nédélec elements. The Nédélec space is designed to solve problems in which the solution only lives in the space , rather than in the more commonly used space . In other words, the solution must be a vector field whose curl is square integrable, but for which the gradient may not be square integrable. The typical application for this space (and these elements) is to the Maxwell equations and corresponding simplifications, such as the reduced version of the Maxwell equation that only involves the electric field which has to satisfy the equation in the time independent case when no currents are present, or the equation that the magnetic vector potential has to satisfy in the time independent case.
+
The defining characteristic of functions in is that they are in general discontinuous – but that if you draw a line in 2d (or a surface in 3d), then the tangential component(s) of the vector field must be continuous across the line (or surface) even though the normal component may not be. As a consequence, the Nédélec element is constructed in such a way that (i) it is vector-valued, (ii) the shape functions are discontinuous, but (iii) the tangential component(s) of the vector field represented by each shape function are continuous across the faces of cells.
Other properties of the Nédélec element are that (i) it is not a primitive element ; (ii) the shape functions are defined so that certain integrals over the faces are either zero or one, rather than the common case of certain point values being either zero or one.
We follow the commonly used – though confusing – definition of the "degree" of Nédélec elements. Specifically, the "degree" of the element denotes the polynomial degree of the largest complete polynomial subspace contained in the finite element space, even if the space may contain shape functions of higher polynomial degree. The lowest order element is consequently FE_Nedelec(0), i.e., the Raviart-Thomas element "of degree
zero", even though the functions of this space are in general polynomials of degree one in each variable. This choice of "degree" implies that the approximation order of the function itself is degree+1, as with usual polynomial spaces. The numbering so chosen implies the sequence
-
+\]" src="form_1119.png"/>
Note that this follows the convention of Brezzi and Raviart, though not the one used in the original paper by Nédélec.
This class is not implemented for the codimension one case (spacedim != dim).
@@ -1421,11 +1421,11 @@
-
Given the values of a function at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., , where are the node functionals of the element (see also Node values or node functionals). The values are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function , i.e., is the finite element interpolant of with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.
-
In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are and that the node functionals associated with the current element are . Then, the fact that the element is based on generalized support points, implies that if we apply to a (possibly vector-valued) finite element function , the result must have the form – in other words, the value of the node functional applied to only depends on the values of at and not on values anywhere else, or integrals of , or any other kind of information.
-
The exact form of depends on the element. For example, for scalar Lagrange elements, we have that in fact . If you combine multiple scalar Lagrange elements via an FESystem object, then where is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that where is the normal vector of the face at which the shape function is defined.
-
Given all of this, what this function does is the following: If you input a list of values of a function at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in then you will get out a vector where equals dofs_per_cell.
+
Given the values of a function at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., , where are the node functionals of the element (see also Node values or node functionals). The values are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function , i.e., is the finite element interpolant of with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.
+
In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are and that the node functionals associated with the current element are . Then, the fact that the element is based on generalized support points, implies that if we apply to a (possibly vector-valued) finite element function , the result must have the form – in other words, the value of the node functional applied to only depends on the values of at and not on values anywhere else, or integrals of , or any other kind of information.
+
The exact form of depends on the element. For example, for scalar Lagrange elements, we have that in fact . If you combine multiple scalar Lagrange elements via an FESystem object, then where is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that where is the normal vector of the face at which the shape function is defined.
+
Given all of this, what this function does is the following: If you input a list of values of a function at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in then you will get out a vector where equals dofs_per_cell.
Parameters
[in]
support_point_values
An array of size dofs_per_cell (which equals the number of points the get_generalized_support_points() function will return) where each element is a vector with as many entries as the element has vector components. This array should contain the values of a function at the generalized support points of the current element.
@@ -3801,7 +3801,7 @@
Returns
The index of this degree of freedom within the set of degrees of freedom on the entire cell. The returned value will be between zero and dofs_per_cell.
-
Note
This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a , then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
+
Note
This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a , then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
Return a block mask with as many elements as this object has blocks and of which exactly the one component is true that corresponds to the given argument. See the glossary for more information.
-
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
scalar
An object that represents a single scalar vector component of this finite element.
@@ -4630,7 +4630,7 @@
Given a component mask (see this glossary entry), produce a block mask (see this glossary entry) that represents the blocks that correspond to the components selected in the input argument. This is essentially a conversion operator from ComponentMask to BlockMask.
-
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
component_mask
The mask that selects individual components of the finite element
@@ -4859,7 +4859,7 @@
Return a vector of generalized support points.
-
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
+
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
For a given degree of freedom, return whether it is logically associated with a vertex, line, quad or hex.
-
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
-
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
-
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
+
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
+
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
+
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
Parameters
[in]
cell_dof_index
The index of a shape function or degree of freedom. This index must be in the range [0,dofs_per_cell).
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__NedelecSZ.html differs (JavaScript source, ASCII text, with very long lines (752))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__NedelecSZ.html 2023-11-25 15:25:53.850013017 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__NedelecSZ.html 2023-11-25 15:25:53.850013017 +0100
@@ -2489,7 +2489,7 @@
Returns
The index of this degree of freedom within the set of degrees of freedom on the entire cell. The returned value will be between zero and dofs_per_cell.
-
Note
This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a , then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
+
Note
This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a , then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
@@ -3160,7 +3160,7 @@
Return a block mask with as many elements as this object has blocks and of which exactly the one component is true that corresponds to the given argument. See the glossary for more information.
-
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
scalar
An object that represents a single scalar vector component of this finite element.
@@ -3262,7 +3262,7 @@
Given a component mask (see this glossary entry), produce a block mask (see this glossary entry) that represents the blocks that correspond to the components selected in the input argument. This is essentially a conversion operator from ComponentMask to BlockMask.
-
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
component_mask
The mask that selects individual components of the finite element
@@ -3500,7 +3500,7 @@
Return a vector of generalized support points.
-
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
+
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
For a given degree of freedom, return whether it is logically associated with a vertex, line, quad or hex.
-
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
-
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
-
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
+
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
+
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
+
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
Parameters
[in]
cell_dof_index
The index of a shape function or degree of freedom. This index must be in the range [0,dofs_per_cell).
@@ -3600,11 +3600,11 @@
-
Given the values of a function at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., , where are the node functionals of the element (see also Node values or node functionals). The values are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function , i.e., is the finite element interpolant of with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.
-
In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are and that the node functionals associated with the current element are . Then, the fact that the element is based on generalized support points, implies that if we apply to a (possibly vector-valued) finite element function , the result must have the form – in other words, the value of the node functional applied to only depends on the values of at and not on values anywhere else, or integrals of , or any other kind of information.
-
The exact form of depends on the element. For example, for scalar Lagrange elements, we have that in fact . If you combine multiple scalar Lagrange elements via an FESystem object, then where is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that where is the normal vector of the face at which the shape function is defined.
-
Given all of this, what this function does is the following: If you input a list of values of a function at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in then you will get out a vector where equals dofs_per_cell.
+
Given the values of a function at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., , where are the node functionals of the element (see also Node values or node functionals). The values are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function , i.e., is the finite element interpolant of with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.
+
In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are and that the node functionals associated with the current element are . Then, the fact that the element is based on generalized support points, implies that if we apply to a (possibly vector-valued) finite element function , the result must have the form – in other words, the value of the node functional applied to only depends on the values of at and not on values anywhere else, or integrals of , or any other kind of information.
+
The exact form of depends on the element. For example, for scalar Lagrange elements, we have that in fact . If you combine multiple scalar Lagrange elements via an FESystem object, then where is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that where is the normal vector of the face at which the shape function is defined.
+
Given all of this, what this function does is the following: If you input a list of values of a function at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in then you will get out a vector where equals dofs_per_cell.
Parameters
[in]
support_point_values
An array of size dofs_per_cell (which equals the number of points the get_generalized_support_points() function will return) where each element is a vector with as many entries as the element has vector components. This array should contain the values of a function at the generalized support points of the current element.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__NedelecSZ_1_1InternalData.html differs (JavaScript source, ASCII text, with very long lines (787))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__NedelecSZ_1_1InternalData.html 2023-11-25 15:25:53.863346078 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__NedelecSZ_1_1InternalData.html 2023-11-25 15:25:53.863346078 +0100
@@ -146,9 +146,9 @@
class FE_NedelecSZ< dim, spacedim >::InternalData
Derived Internal data which is used to store cell-independent data. Note that due to the nature of this element, a number of useful pre-computed quantities are stored for the computation of cell-dependent shape functions.
The main quantities which are stored are associated with edge and face parameterizations. These are:
- - trilinear function, equal to one at the -th vertex and zero at all other vertices.
+ - trilinear function, equal to one at the -th vertex and zero at all other vertices.
- - linear functional associated with the -th vertex.
+ - linear functional associated with the -th vertex.
The definitions of these functionals, as well as the edge and face parameterizations and edge and face extension parameters, can be found on page 82 of Zaglmayr's thesis. The details of the definition of the globally-defined edge and face orientations can be found on page 67.
@@ -279,9 +279,9 @@
Storage for all possible edge parameterization between vertices. These are required in the computation of edge- and face-based DoFs, which are cell-dependent.
-
The edge parameterization of an edge, E, starting at vertex i and ending at vertex is given by .
-
sigma_imj_values[q][i][j] stores the value of the edge parameterization connected by vertices and at the q-th quadrature point.
-
Note that not all of the and combinations result in valid edges on the hexahedral cell, but they are computed in this fashion for use with non-standard edge and face orientations.
+
The edge parameterization of an edge, E, starting at vertex i and ending at vertex is given by .
+
sigma_imj_values[q][i][j] stores the value of the edge parameterization connected by vertices and at the q-th quadrature point.
+
Note that not all of the and combinations result in valid edges on the hexahedral cell, but they are computed in this fashion for use with non-standard edge and face orientations.
Storage for gradients of all possible edge parameterizations between vertices. These are required in the computation of edge- and face-based DoFs, which are cell-dependent. Note that the components of the gradient are constant.
-
The edge parameterization of an edge, , starting at vertex and ending at vertex is given by .
-
sigma_imj_grads[i][j][d] stores the gradient of the edge parameterization connected by vertices and in component .
+
The edge parameterization of an edge, , starting at vertex and ending at vertex is given by .
+
sigma_imj_grads[i][j][d] stores the gradient of the edge parameterization connected by vertices and in component .
Note that the gradient of the edge parameterization is constant on an edge, so we do not need to store it at every quadrature point.
Storage for edge extension parameters at quadrature points. These are stored for the 12 edges such that the global vertex numbering would follow the order defined by the "standard" deal.II cell.
-
The edge extension parameter of an edge, , starting at vertex and ending at vertex is given by .
-
Note that under this definition, the values of do not change with the orientation of the edge.
-
edge_lambda_values[m][q] stores the edge extension parameter value at the -th quadrature point on edge .
+
The edge extension parameter of an edge, , starting at vertex and ending at vertex is given by .
+
Note that under this definition, the values of do not change with the orientation of the edge.
+
edge_lambda_values[m][q] stores the edge extension parameter value at the -th quadrature point on edge .
Storage for gradients of edge extension parameters in 2d. In this case they are constant. These are stored for the 12 edges such that the global vertex numbering* would follow the order defined by the "standard" deal.II cell.
-
edge_lambda_grads_2d[m][d] stores the gradient of the edge extension parameter for component on edge .
+
edge_lambda_grads_2d[m][d] stores the gradient of the edge extension parameter for component on edge .
Storage for gradients of edge extension parameters in 3d. In this case they are non-constant. These are stored for the 12 edges such that the global vertex numbering* would follow the order defined by the "standard" deal.II cell.
-
edge_lambda_grads_3d[m][q][d] stores the gradient of the edge extension parameter for component at the -th quadrature point on edge m.
+
edge_lambda_grads_3d[m][q][d] stores the gradient of the edge extension parameter for component at the -th quadrature point on edge m.
Storage for 2nd derivatives of edge extension parameters in 3d, which are constant across the cell. These are stored for the 12 edges such that the global vertex numbering* would follow the order defined by the "standard" deal.II cell.
-
edge_lambda_gradgrads_3d[m][d1][d2] stores the 2nd derivatives of the edge extension parameters with respect to components d1 and d2 on edge .
+
edge_lambda_gradgrads_3d[m][d1][d2] stores the 2nd derivatives of the edge extension parameters with respect to components d1 and d2 on edge .
Storage for the face extension parameters. These are stored for the 6 faces such that the global vertex numbering would follow the order defined by the "standard" deal.II cell.
-
The face extension parameter of a face, F, defined by the vertices v1, v2, v3, v4 is given by .
-
Note that under this definition, the values of do not change with the orientation of the face.
-
face_lambda_values[m][q] stores the face extension parameter value at the -th quadrature point on face .
+
The face extension parameter of a face, F, defined by the vertices v1, v2, v3, v4 is given by .
+
Note that under this definition, the values of do not change with the orientation of the face.
+
face_lambda_values[m][q] stores the face extension parameter value at the -th quadrature point on face .
Storage for gradients of face extension parameters. These are stored for the 6 faces such that the global vertex numbering would follow the order defined by the "standard" deal.II cell.
-
face_lambda_grads[m][d] stores the gradient of the face extension parameters for component on face .
+
face_lambda_grads[m][d] stores the gradient of the face extension parameters for component on face .
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__Nothing.html differs (JavaScript source, ASCII text, with very long lines (1483))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__Nothing.html 2023-11-25 15:25:53.916678324 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__Nothing.html 2023-11-25 15:25:53.916678324 +0100
@@ -465,7 +465,7 @@
class FE_Nothing< dim, spacedim >
Definition of a finite element space with zero degrees of freedom and that, consequently, can only represent a single function: the zero function.
This class is useful (in the context of an hp-method) to represent empty cells in the triangulation on which no degrees of freedom should be allocated, or to describe a field that is extended by zero to a part of the domain where we don't need it. Thus a triangulation may be divided into two regions: an active region where normal elements are used, and an inactive region where FE_Nothing elements are used. The DoFHandler will therefore assign no degrees of freedom to the FE_Nothing cells, and this subregion is therefore implicitly deleted from the computation. step-10 and step-46 show use cases for this element. An interesting application for this element is also presented in the paper [Cangiani2012].
Finite elements are often best interpreted as forming a function space, i.e., a set of functions that form a vector space. One can indeed interpret FE_Nothing in this light: It corresponds to the function space , i.e., the set of functions that are zero everywhere. (The constructor can take an argument that, if greater than one, extends the space to one of vector-valued functions with more than one component, with all components equal to zero everywhere.) Indeed, this is a vector space since every linear combination of elements in the vector space is also an element in the vector space, as is every multiple of the single element zero. It is obvious that the function space has no degrees of freedom, thus the name of the class.
+
Finite elements are often best interpreted as forming a function space, i.e., a set of functions that form a vector space. One can indeed interpret FE_Nothing in this light: It corresponds to the function space , i.e., the set of functions that are zero everywhere. (The constructor can take an argument that, if greater than one, extends the space to one of vector-valued functions with more than one component, with all components equal to zero everywhere.) Indeed, this is a vector space since every linear combination of elements in the vector space is also an element in the vector space, as is every multiple of the single element zero. It is obvious that the function space has no degrees of freedom, thus the name of the class.
In situations such as those of step-46, one uses FE_Nothing on cells where one is not interested in a solution variable. For example, in fluid structure interaction problems, the fluid velocity is only defined on cells inside the fluid part of the domain. One then uses FE_Nothing on cells in the solid part of the domain to describe the finite element space for the velocity. In other words, the velocity lives everywhere conceptually, but it is identically zero in those parts of the domain where it is not of interest and doesn't use up any degrees of freedom there.
The question is what happens at the interface between areas where one is interested in the solution (and uses a "normal" finite element) and where one is not interested (and uses FE_Nothing): Should the solution at that interface be zero – i.e., we consider a "continuous" finite element field that happens to be zero in that area where FE_Nothing is used – or is there no requirement for continuity at the interface. In the deal.II language, this is encoded by what the function FiniteElement::compare_for_domination() returns: If the FE_Nothing "dominates", then the solution must be zero at the interface; if it does not, then there is no requirement and one can think of FE_Nothing as a function space that is in general discontinuous (i.e., there is no requirement for any kind of continuity at cell interfaces) but on every cell equal to zero.
@@ -633,7 +633,7 @@
[in]
type
Specifies the reference-cell type.
[in]
n_components
Denotes the number of vector components to give this finite element. The default is one.
-
[in]
dominate
Decides whether FE_Nothing will dominate any other FE in compare_for_domination() (with the default being false). Therefore at interfaces where, for example, a meets an FE_Nothing, we will force the traces of the two functions to be the same. Because the FE_Nothing encodes a space that is zero everywhere, this means that the field will be forced to become zero at this interface. See also the discussion in the general documentation of this class.
+
[in]
dominate
Decides whether FE_Nothing will dominate any other FE in compare_for_domination() (with the default being false). Therefore at interfaces where, for example, a meets an FE_Nothing, we will force the traces of the two functions to be the same. Because the FE_Nothing encodes a space that is zero everywhere, this means that the field will be forced to become zero at this interface. See also the discussion in the general documentation of this class.
@@ -2499,7 +2499,7 @@
Returns
The index of this degree of freedom within the set of degrees of freedom on the entire cell. The returned value will be between zero and dofs_per_cell.
-
Note
This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a , then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
+
Note
This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a , then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
Return a block mask with as many elements as this object has blocks and of which exactly the one component is true that corresponds to the given argument. See the glossary for more information.
-
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
scalar
An object that represents a single scalar vector component of this finite element.
@@ -3328,7 +3328,7 @@
Given a component mask (see this glossary entry), produce a block mask (see this glossary entry) that represents the blocks that correspond to the components selected in the input argument. This is essentially a conversion operator from ComponentMask to BlockMask.
-
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
component_mask
The mask that selects individual components of the finite element
@@ -3557,7 +3557,7 @@
Return a vector of generalized support points.
-
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
+
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
For a given degree of freedom, return whether it is logically associated with a vertex, line, quad or hex.
-
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
-
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
-
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
+
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
+
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
+
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
Parameters
[in]
cell_dof_index
The index of a shape function or degree of freedom. This index must be in the range [0,dofs_per_cell).
@@ -3663,11 +3663,11 @@
-
Given the values of a function at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., , where are the node functionals of the element (see also Node values or node functionals). The values are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function , i.e., is the finite element interpolant of with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.
-
In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are and that the node functionals associated with the current element are . Then, the fact that the element is based on generalized support points, implies that if we apply to a (possibly vector-valued) finite element function , the result must have the form – in other words, the value of the node functional applied to only depends on the values of at and not on values anywhere else, or integrals of , or any other kind of information.
-
The exact form of depends on the element. For example, for scalar Lagrange elements, we have that in fact . If you combine multiple scalar Lagrange elements via an FESystem object, then where is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that where is the normal vector of the face at which the shape function is defined.
-
Given all of this, what this function does is the following: If you input a list of values of a function at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in then you will get out a vector where equals dofs_per_cell.
+
Given the values of a function at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., , where are the node functionals of the element (see also Node values or node functionals). The values are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function , i.e., is the finite element interpolant of with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.
+
In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are and that the node functionals associated with the current element are . Then, the fact that the element is based on generalized support points, implies that if we apply to a (possibly vector-valued) finite element function , the result must have the form – in other words, the value of the node functional applied to only depends on the values of at and not on values anywhere else, or integrals of , or any other kind of information.
+
The exact form of depends on the element. For example, for scalar Lagrange elements, we have that in fact . If you combine multiple scalar Lagrange elements via an FESystem object, then where is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that where is the normal vector of the face at which the shape function is defined.
+
Given all of this, what this function does is the following: If you input a list of values of a function at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in then you will get out a vector where equals dofs_per_cell.
Parameters
[in]
support_point_values
An array of size dofs_per_cell (which equals the number of points the get_generalized_support_points() function will return) where each element is a vector with as many entries as the element has vector components. This array should contain the values of a function at the generalized support points of the current element.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__P1NC.html differs (JavaScript source, ASCII text, with very long lines (752))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__P1NC.html 2023-11-25 15:25:53.970010574 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__P1NC.html 2023-11-25 15:25:53.970010574 +0100
@@ -471,14 +471,14 @@
Detailed Description
Implementation of the scalar version of the P1 nonconforming finite element, a piecewise linear element on quadrilaterals in 2d. This implementation is only for 2d cells in a 2d space (i.e., codimension 0).
-
Unlike the usual continuous, conforming finite elements, the P1 nonconforming element does not enforce continuity across edges. However, it requires the continuity in an integral sense: any function in the space should have the same integral values on two sides of the common edge shared by two adjacent elements.
-
Thus, each function in the nonconforming element space can be discontinuous, and consequently not included in , just like the basis functions in Discontinuous Galerkin (DG) finite element spaces. On the other hand, basis functions in DG spaces are completely discontinuous across edges without any relation between the values from both sides. This is a reason why usual weak formulations for DG schemes contain additional penalty terms for jump across edges to control discontinuity. However, nonconforming elements usually do not need additional terms in their weak formulations because their integrals along edges are the same from both sides, i.e., there is some level of continuity.
+
Unlike the usual continuous, conforming finite elements, the P1 nonconforming element does not enforce continuity across edges. However, it requires the continuity in an integral sense: any function in the space should have the same integral values on two sides of the common edge shared by two adjacent elements.
+
Thus, each function in the nonconforming element space can be discontinuous, and consequently not included in , just like the basis functions in Discontinuous Galerkin (DG) finite element spaces. On the other hand, basis functions in DG spaces are completely discontinuous across edges without any relation between the values from both sides. This is a reason why usual weak formulations for DG schemes contain additional penalty terms for jump across edges to control discontinuity. However, nonconforming elements usually do not need additional terms in their weak formulations because their integrals along edges are the same from both sides, i.e., there is some level of continuity.
Dice Rule
Since any function in the P1 nonconforming space is piecewise linear on each element, the function value at the midpoint of each edge is same as the mean value on the edge. Thus the continuity of the integral value across each edge is equivalent to the continuity of the midpoint value of each edge in this case.
Thus for the P1 nonconforming element, the function values at midpoints on edges of a cell are important. The first attempt to define (local) degrees of freedom (DoFs) on a quadrilateral is by using midpoint values of a function.
However, these 4 functionals are not linearly independent because a linear function on 2d is uniquely determined by only 3 independent values. A simple observation reads that any linear function on a quadrilateral should satisfy the 'dice rule': the sum of two function values at the midpoints of the edge pair on opposite sides of a cell is equal to the sum of those at the midpoints of the other edge pair. This is called the 'dice rule' because the number of points on opposite sides of a dice always adds up to the same number as well (in the case of dice, to seven).
-
In formulas, the dice rule is written as for all in the function space where is the midpoint of the edge . Here, we assume the standard numbering convention for edges used in deal.II and described in class GeometryInfo.
+
In formulas, the dice rule is written as for all in the function space where is the midpoint of the edge . Here, we assume the standard numbering convention for edges used in deal.II and described in class GeometryInfo.
Conversely if 4 values at midpoints satisfying the dice rule are given, then there always exists the unique linear function which coincides with 4 midpoints values.
Due to the dice rule, three values at any three midpoints can determine the last value at the last midpoint. It means that the number of independent local functionals on a cell is 3, and this is also the dimension of the linear polynomial space on a cell in 2d.
For each vertex of given cell, there are two edges of which is one of end points. Consider a linear function such that it has value 0.5 at the midpoints of two adjacent edges, and 0.0 at the two midpoints of the other edges. Note that the set of these values satisfies the dice rule which is described above. We denote such a function associated with vertex by . Then the set of 4 shape functions is a partition of unity on a cell: . (This is easy to see: at each edge midpoint, the sum of the four function adds up to one because two functions have value 0.5 and the other value 0.0. Because the function is globally linear, the only function that can have value 1 at four points must also be globally equal to one.)
-
The following figures represent for with their midpoint values:
+*
For each vertex of given cell, there are two edges of which is one of end points. Consider a linear function such that it has value 0.5 at the midpoints of two adjacent edges, and 0.0 at the two midpoints of the other edges. Note that the set of these values satisfies the dice rule which is described above. We denote such a function associated with vertex by . Then the set of 4 shape functions is a partition of unity on a cell: . (This is easy to see: at each edge midpoint, the sum of the four function adds up to one because two functions have value 0.5 and the other value 0.0. Because the function is globally linear, the only function that can have value 1 at four points must also be globally equal to one.)
+
The following figures represent for with their midpoint values:
We next have to consider the global basis functions for the element because the system of equations which we ultimately have to solve is for a global system, not local. The global basis functions associated with a node are defined by a cell-wise composition of local shape functions associated with the node on each element.
There is a theoretical result about the linear independence of the global basis functions depending on the type of the boundary condition we consider.
-
When homogeneous Dirichlet boundary conditions are given, the global basis functions associated with interior nodes are linearly independent. Then, the number of DoFs is equal to the number of interior nodes, and consequently the same as the number of DoFs for the standard bilinear finite element.
-
When Neumann boundary conditions are given, the global basis functions associated with all nodes (including boundary nodes) are actually not linearly independent. There exists one redundancy. Thus in this case, the number of DoFs is equal to the number of all nodes minus 1. This is, again as for the regular element.
+
When homogeneous Dirichlet boundary conditions are given, the global basis functions associated with interior nodes are linearly independent. Then, the number of DoFs is equal to the number of interior nodes, and consequently the same as the number of DoFs for the standard bilinear finite element.
+
When Neumann boundary conditions are given, the global basis functions associated with all nodes (including boundary nodes) are actually not linearly independent. There exists one redundancy. Thus in this case, the number of DoFs is equal to the number of all nodes minus 1. This is, again as for the regular element.
Unit support points
For a smooth function, we construct a piecewise linear function which belongs to the element space by using its nodal values as DoF values.
Note that for the P1 nonconforming element, two nodal values of a smooth function and its interpolant do not coincide in general, in contrast to ordinary Lagrange finite elements. Of course, it is meaningless to refer 'nodal value' because the element space has nonconformity. But it is also true even though the single global basis function associated with a node is considered the unique 'nodal value' at the node. For instance, consider the basis function associated with a node. Consider two lines representing the level sets for value 0.5 and 0, respectively, by connecting two midpoints. Then we cut the quad into two sub-triangles by the diagonal which is placed along those two lines. It gives another level set for value 0.25 which coincides with the cutting diagonal. Therefore these three level sets are all parallel in the quad and it gives the value 0.75 at the base node, not value 1. This is true whether the quadrilateral is a rectangle, parallelogram, or any other shape.
@@ -871,8 +871,8 @@
-
Return the coefficients of 4 local linear shape functions on given cell. For each local shape function, the array consists of three coefficients is in order of a,b and c.
+
Return the coefficients of 4 local linear shape functions on given cell. For each local shape function, the array consists of three coefficients is in order of a,b and c.
The index of this degree of freedom within the set of degrees of freedom on the entire cell. The returned value will be between zero and dofs_per_cell.
-
Note
This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a , then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
+
Note
This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a , then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
@@ -3215,7 +3215,7 @@
Return a block mask with as many elements as this object has blocks and of which exactly the one component is true that corresponds to the given argument. See the glossary for more information.
-
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
scalar
An object that represents a single scalar vector component of this finite element.
@@ -3317,7 +3317,7 @@
Given a component mask (see this glossary entry), produce a block mask (see this glossary entry) that represents the blocks that correspond to the components selected in the input argument. This is essentially a conversion operator from ComponentMask to BlockMask.
-
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
component_mask
The mask that selects individual components of the finite element
@@ -3555,7 +3555,7 @@
Return a vector of generalized support points.
-
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
+
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
For a given degree of freedom, return whether it is logically associated with a vertex, line, quad or hex.
-
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
-
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
-
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
+
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
+
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
+
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
Parameters
[in]
cell_dof_index
The index of a shape function or degree of freedom. This index must be in the range [0,dofs_per_cell).
@@ -3655,11 +3655,11 @@
-
Given the values of a function at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., , where are the node functionals of the element (see also Node values or node functionals). The values are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function , i.e., is the finite element interpolant of with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.
-
In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are and that the node functionals associated with the current element are . Then, the fact that the element is based on generalized support points, implies that if we apply to a (possibly vector-valued) finite element function , the result must have the form – in other words, the value of the node functional applied to only depends on the values of at and not on values anywhere else, or integrals of , or any other kind of information.
-
The exact form of depends on the element. For example, for scalar Lagrange elements, we have that in fact . If you combine multiple scalar Lagrange elements via an FESystem object, then where is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that where is the normal vector of the face at which the shape function is defined.
-
Given all of this, what this function does is the following: If you input a list of values of a function at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in then you will get out a vector where equals dofs_per_cell.
+
Given the values of a function at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., , where are the node functionals of the element (see also Node values or node functionals). The values are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function , i.e., is the finite element interpolant of with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.
+
In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are and that the node functionals associated with the current element are . Then, the fact that the element is based on generalized support points, implies that if we apply to a (possibly vector-valued) finite element function , the result must have the form – in other words, the value of the node functional applied to only depends on the values of at and not on values anywhere else, or integrals of , or any other kind of information.
+
The exact form of depends on the element. For example, for scalar Lagrange elements, we have that in fact . If you combine multiple scalar Lagrange elements via an FESystem object, then where is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that where is the normal vector of the face at which the shape function is defined.
+
Given all of this, what this function does is the following: If you input a list of values of a function at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in then you will get out a vector where equals dofs_per_cell.
Parameters
[in]
support_point_values
An array of size dofs_per_cell (which equals the number of points the get_generalized_support_points() function will return) where each element is a vector with as many entries as the element has vector components. This array should contain the values of a function at the generalized support points of the current element.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__Poly.html differs (JavaScript source, ASCII text, with very long lines (851))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__Poly.html 2023-11-25 15:25:54.030009353 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__Poly.html 2023-11-25 15:25:54.030009353 +0100
@@ -1545,17 +1545,17 @@
Correct the shape Hessians by subtracting the terms corresponding to the Jacobian pushed forward gradient.
Before the correction, the Hessians would be given by
-
+\]" src="form_1140.png"/>
-
where . After the correction, the correct Hessians would be given by
-. After the correction, the correct Hessians would be given by
+
+\]" src="form_1142.png"/>
-
where is the Jacobian pushed-forward derivative.
+
where is the Jacobian pushed-forward derivative.
@@ -1599,21 +1599,21 @@
Correct the shape third derivatives by subtracting the terms corresponding to the Jacobian pushed forward gradient and second derivative.
Before the correction, the third derivatives would be given by
-
+\]" src="form_1144.png"/>
-
where . After the correction, the correct third derivative would be given by
-. After the correction, the correct third derivative would be given by
+
+\]" src="form_1145.png"/>
-
where is the Jacobian pushed-forward derivative and is the Jacobian pushed-forward second derivative.
+
where is the Jacobian pushed-forward derivative and is the Jacobian pushed-forward second derivative.
@@ -2641,7 +2641,7 @@
Returns
The index of this degree of freedom within the set of degrees of freedom on the entire cell. The returned value will be between zero and dofs_per_cell.
-
Note
This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a , then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
+
Note
This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a , then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
Return a block mask with as many elements as this object has blocks and of which exactly the one component is true that corresponds to the given argument. See the glossary for more information.
-
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
scalar
An object that represents a single scalar vector component of this finite element.
@@ -3470,7 +3470,7 @@
Given a component mask (see this glossary entry), produce a block mask (see this glossary entry) that represents the blocks that correspond to the components selected in the input argument. This is essentially a conversion operator from ComponentMask to BlockMask.
-
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
component_mask
The mask that selects individual components of the finite element
@@ -3730,7 +3730,7 @@
Return a vector of generalized support points.
-
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
+
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
For a given degree of freedom, return whether it is logically associated with a vertex, line, quad or hex.
-
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
-
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
-
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
+
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
+
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
+
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
Parameters
[in]
cell_dof_index
The index of a shape function or degree of freedom. This index must be in the range [0,dofs_per_cell).
@@ -3836,11 +3836,11 @@
-
Given the values of a function at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., , where are the node functionals of the element (see also Node values or node functionals). The values are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function , i.e., is the finite element interpolant of with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.
-
In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are and that the node functionals associated with the current element are . Then, the fact that the element is based on generalized support points, implies that if we apply to a (possibly vector-valued) finite element function , the result must have the form – in other words, the value of the node functional applied to only depends on the values of at and not on values anywhere else, or integrals of , or any other kind of information.
-
The exact form of depends on the element. For example, for scalar Lagrange elements, we have that in fact . If you combine multiple scalar Lagrange elements via an FESystem object, then where is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that where is the normal vector of the face at which the shape function is defined.
-
Given all of this, what this function does is the following: If you input a list of values of a function at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in then you will get out a vector where equals dofs_per_cell.
+
Given the values of a function at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., , where are the node functionals of the element (see also Node values or node functionals). The values are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function , i.e., is the finite element interpolant of with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.
+
In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are and that the node functionals associated with the current element are . Then, the fact that the element is based on generalized support points, implies that if we apply to a (possibly vector-valued) finite element function , the result must have the form – in other words, the value of the node functional applied to only depends on the values of at and not on values anywhere else, or integrals of , or any other kind of information.
+
The exact form of depends on the element. For example, for scalar Lagrange elements, we have that in fact . If you combine multiple scalar Lagrange elements via an FESystem object, then where is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that where is the normal vector of the face at which the shape function is defined.
+
Given all of this, what this function does is the following: If you input a list of values of a function at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in then you will get out a vector where equals dofs_per_cell.
Parameters
[in]
support_point_values
An array of size dofs_per_cell (which equals the number of points the get_generalized_support_points() function will return) where each element is a vector with as many entries as the element has vector components. This array should contain the values of a function at the generalized support points of the current element.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__PolyFace.html differs (JavaScript source, ASCII text, with very long lines (752))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__PolyFace.html 2023-11-25 15:25:54.086674867 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__PolyFace.html 2023-11-25 15:25:54.086674867 +0100
@@ -2517,7 +2517,7 @@
Returns
The index of this degree of freedom within the set of degrees of freedom on the entire cell. The returned value will be between zero and dofs_per_cell.
-
Note
This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a , then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
+
Note
This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a , then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
Return a block mask with as many elements as this object has blocks and of which exactly the one component is true that corresponds to the given argument. See the glossary for more information.
-
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
scalar
An object that represents a single scalar vector component of this finite element.
@@ -3346,7 +3346,7 @@
Given a component mask (see this glossary entry), produce a block mask (see this glossary entry) that represents the blocks that correspond to the components selected in the input argument. This is essentially a conversion operator from ComponentMask to BlockMask.
-
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
component_mask
The mask that selects individual components of the finite element
@@ -3606,7 +3606,7 @@
Return a vector of generalized support points.
-
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
+
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
For a given degree of freedom, return whether it is logically associated with a vertex, line, quad or hex.
-
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
-
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
-
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
+
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
+
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
+
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
Parameters
[in]
cell_dof_index
The index of a shape function or degree of freedom. This index must be in the range [0,dofs_per_cell).
@@ -3712,11 +3712,11 @@
-
Given the values of a function at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., , where are the node functionals of the element (see also Node values or node functionals). The values are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function , i.e., is the finite element interpolant of with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.
-
In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are and that the node functionals associated with the current element are . Then, the fact that the element is based on generalized support points, implies that if we apply to a (possibly vector-valued) finite element function , the result must have the form – in other words, the value of the node functional applied to only depends on the values of at and not on values anywhere else, or integrals of , or any other kind of information.
-
The exact form of depends on the element. For example, for scalar Lagrange elements, we have that in fact . If you combine multiple scalar Lagrange elements via an FESystem object, then where is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that where is the normal vector of the face at which the shape function is defined.
-
Given all of this, what this function does is the following: If you input a list of values of a function at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in then you will get out a vector where equals dofs_per_cell.
+
Given the values of a function at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., , where are the node functionals of the element (see also Node values or node functionals). The values are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function , i.e., is the finite element interpolant of with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.
+
In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are and that the node functionals associated with the current element are . Then, the fact that the element is based on generalized support points, implies that if we apply to a (possibly vector-valued) finite element function , the result must have the form – in other words, the value of the node functional applied to only depends on the values of at and not on values anywhere else, or integrals of , or any other kind of information.
+
The exact form of depends on the element. For example, for scalar Lagrange elements, we have that in fact . If you combine multiple scalar Lagrange elements via an FESystem object, then where is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that where is the normal vector of the face at which the shape function is defined.
+
Given all of this, what this function does is the following: If you input a list of values of a function at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in then you will get out a vector where equals dofs_per_cell.
Parameters
[in]
support_point_values
An array of size dofs_per_cell (which equals the number of points the get_generalized_support_points() function will return) where each element is a vector with as many entries as the element has vector components. This array should contain the values of a function at the generalized support points of the current element.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__PolyTensor.html differs (JavaScript source, ASCII text, with very long lines (808))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__PolyTensor.html 2023-11-25 15:25:54.146673646 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__PolyTensor.html 2023-11-25 15:25:54.146673646 +0100
@@ -492,12 +492,12 @@
Similarly, in many cases, node functionals depend on the shape of the mesh cell, since they evaluate normal or tangential components on the faces. In order to allow for a set of transformations, the variable mapping_kind has been introduced. It needs be set in the constructor of a derived class.
Any derived class must decide on the polynomial space to use. This polynomial space should be implemented simply as a set of vector valued polynomials like PolynomialsBDM and PolynomialsRaviartThomas. In order to facilitate this implementation, which basis the polynomial space chooses is not of importance to the current class – as described next, this class handles the transformation from the basis chosen by the polynomial space template argument to the basis we want to use for finite element computations internally.
Determining the correct basis
-
In most cases, the basis used by the class that describes the polynomial space, , does not match the one we want to use for the finite element description, . Rather, we need to express the finite element shape functions as a linear combination of the basis provided by the polynomial space:
-, does not match the one we want to use for the finite element description, . Rather, we need to express the finite element shape functions as a linear combination of the basis provided by the polynomial space:
+
+\end{align*}" src="form_1149.png"/>
-
These expansion coefficients are typically computed in the constructors of derived classes. To facilitate this, this class at first (unless told otherwise, see below), assumes that the shape functions should be exactly the ones provided by the polynomial space. In the constructor of the derived class, one then typically has code of the form
// Now compute the inverse node matrix, generating the correct
+
These expansion coefficients are typically computed in the constructors of derived classes. To facilitate this, this class at first (unless told otherwise, see below), assumes that the shape functions should be exactly the ones provided by the polynomial space. In the constructor of the derived class, one then typically has code of the form
// Now compute the inverse node matrix, generating the correct
// basis functions from the raw ones. For a discussion of what
// exactly happens here, see FETools::compute_node_matrix.
The FETools::compute_node_matrix() function explains in more detail what exactly it computes, and how; in any case, the result is that inverse_node_matrix now contains the expansion coefficients , and the fact that this block of code now sets the matrix to a non-zero size indicates to the functions of the current class that it should from then on use the expanded basis, , and no longer the original, "raw" basis when asked for values or derivatives of shape functions.
+
The FETools::compute_node_matrix() function explains in more detail what exactly it computes, and how; in any case, the result is that inverse_node_matrix now contains the expansion coefficients , and the fact that this block of code now sets the matrix to a non-zero size indicates to the functions of the current class that it should from then on use the expanded basis, , and no longer the original, "raw" basis when asked for values or derivatives of shape functions.
In order for this scheme to work, it is important to ensure that the size of the inverse_node_matrix be zero at the time when FETools::compute_node_matrix() is called; thus, the call to this function cannot be inlined into the last line – the result of the call really does need to be stored in the temporary object M.
Setting the transformation
In most cases, vector valued basis functions must be transformed when mapped from the reference cell to the actual grid cell. These transformations can be selected from the set MappingKind and stored in mapping_kind. Therefore, each constructor should contain a line like:
The index of this degree of freedom within the set of degrees of freedom on the entire cell. The returned value will be between zero and dofs_per_cell.
-
Note
This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a , then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
+
Note
This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a , then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
Return a block mask with as many elements as this object has blocks and of which exactly the one component is true that corresponds to the given argument. See the glossary for more information.
-
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
scalar
An object that represents a single scalar vector component of this finite element.
@@ -3372,7 +3372,7 @@
Given a component mask (see this glossary entry), produce a block mask (see this glossary entry) that represents the blocks that correspond to the components selected in the input argument. This is essentially a conversion operator from ComponentMask to BlockMask.
-
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
component_mask
The mask that selects individual components of the finite element
@@ -3632,7 +3632,7 @@
Return a vector of generalized support points.
-
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
+
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
For a given degree of freedom, return whether it is logically associated with a vertex, line, quad or hex.
-
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
-
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
-
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
+
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
+
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
+
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
Parameters
[in]
cell_dof_index
The index of a shape function or degree of freedom. This index must be in the range [0,dofs_per_cell).
@@ -3738,11 +3738,11 @@
-
Given the values of a function at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., , where are the node functionals of the element (see also Node values or node functionals). The values are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function , i.e., is the finite element interpolant of with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.
-
In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are and that the node functionals associated with the current element are . Then, the fact that the element is based on generalized support points, implies that if we apply to a (possibly vector-valued) finite element function , the result must have the form – in other words, the value of the node functional applied to only depends on the values of at and not on values anywhere else, or integrals of , or any other kind of information.
-
The exact form of depends on the element. For example, for scalar Lagrange elements, we have that in fact . If you combine multiple scalar Lagrange elements via an FESystem object, then where is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that where is the normal vector of the face at which the shape function is defined.
-
Given all of this, what this function does is the following: If you input a list of values of a function at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in then you will get out a vector where equals dofs_per_cell.
+
Given the values of a function at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., , where are the node functionals of the element (see also Node values or node functionals). The values are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function , i.e., is the finite element interpolant of with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.
+
In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are and that the node functionals associated with the current element are . Then, the fact that the element is based on generalized support points, implies that if we apply to a (possibly vector-valued) finite element function , the result must have the form – in other words, the value of the node functional applied to only depends on the values of at and not on values anywhere else, or integrals of , or any other kind of information.
+
The exact form of depends on the element. For example, for scalar Lagrange elements, we have that in fact . If you combine multiple scalar Lagrange elements via an FESystem object, then where is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that where is the normal vector of the face at which the shape function is defined.
+
Given all of this, what this function does is the following: If you input a list of values of a function at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in then you will get out a vector where equals dofs_per_cell.
Parameters
[in]
support_point_values
An array of size dofs_per_cell (which equals the number of points the get_generalized_support_points() function will return) where each element is a vector with as many entries as the element has vector components. This array should contain the values of a function at the generalized support points of the current element.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__PyramidDGP.html differs (JavaScript source, ASCII text, with very long lines (752))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__PyramidDGP.html 2023-11-25 15:25:54.203339159 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__PyramidDGP.html 2023-11-25 15:25:54.203339159 +0100
@@ -469,7 +469,7 @@
Implementation of a scalar Lagrange finite element on a pyramid that yields the finite element space of discontinuous, piecewise polynomials of degree .
+class FE_PyramidDGP< dim, spacedim >
Implementation of a scalar Lagrange finite element on a pyramid that yields the finite element space of discontinuous, piecewise polynomials of degree .
Note
Currently, only linear polynomials (degree=1) are implemented. See also the documentation of ScalarLagrangePolynomialPyramid.
Given the values of a function at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., , where are the node functionals of the element (see also Node values or node functionals). The values are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function , i.e., is the finite element interpolant of with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.
-
In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are and that the node functionals associated with the current element are . Then, the fact that the element is based on generalized support points, implies that if we apply to a (possibly vector-valued) finite element function , the result must have the form – in other words, the value of the node functional applied to only depends on the values of at and not on values anywhere else, or integrals of , or any other kind of information.
-
The exact form of depends on the element. For example, for scalar Lagrange elements, we have that in fact . If you combine multiple scalar Lagrange elements via an FESystem object, then where is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that where is the normal vector of the face at which the shape function is defined.
-
Given all of this, what this function does is the following: If you input a list of values of a function at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in then you will get out a vector where equals dofs_per_cell.
+
Given the values of a function at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., , where are the node functionals of the element (see also Node values or node functionals). The values are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function , i.e., is the finite element interpolant of with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.
+
In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are and that the node functionals associated with the current element are . Then, the fact that the element is based on generalized support points, implies that if we apply to a (possibly vector-valued) finite element function , the result must have the form – in other words, the value of the node functional applied to only depends on the values of at and not on values anywhere else, or integrals of , or any other kind of information.
+
The exact form of depends on the element. For example, for scalar Lagrange elements, we have that in fact . If you combine multiple scalar Lagrange elements via an FESystem object, then where is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that where is the normal vector of the face at which the shape function is defined.
+
Given all of this, what this function does is the following: If you input a list of values of a function at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in then you will get out a vector where equals dofs_per_cell.
Parameters
[in]
support_point_values
An array of size dofs_per_cell (which equals the number of points the get_generalized_support_points() function will return) where each element is a vector with as many entries as the element has vector components. This array should contain the values of a function at the generalized support points of the current element.
@@ -1951,17 +1951,17 @@
Correct the shape Hessians by subtracting the terms corresponding to the Jacobian pushed forward gradient.
Before the correction, the Hessians would be given by
-
+\]" src="form_1140.png"/>
-
where . After the correction, the correct Hessians would be given by
-. After the correction, the correct Hessians would be given by
+
+\]" src="form_1142.png"/>
-
where is the Jacobian pushed-forward derivative.
+
where is the Jacobian pushed-forward derivative.
@@ -2005,21 +2005,21 @@
Correct the shape third derivatives by subtracting the terms corresponding to the Jacobian pushed forward gradient and second derivative.
Before the correction, the third derivatives would be given by
-
+\]" src="form_1144.png"/>
-
where . After the correction, the correct third derivative would be given by
-. After the correction, the correct third derivative would be given by
+
+\]" src="form_1145.png"/>
-
where is the Jacobian pushed-forward derivative and is the Jacobian pushed-forward second derivative.
+
where is the Jacobian pushed-forward derivative and is the Jacobian pushed-forward second derivative.
@@ -2985,7 +2985,7 @@
Returns
The index of this degree of freedom within the set of degrees of freedom on the entire cell. The returned value will be between zero and dofs_per_cell.
-
Note
This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a , then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
+
Note
This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a , then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
Return a block mask with as many elements as this object has blocks and of which exactly the one component is true that corresponds to the given argument. See the glossary for more information.
-
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
scalar
An object that represents a single scalar vector component of this finite element.
@@ -3814,7 +3814,7 @@
Given a component mask (see this glossary entry), produce a block mask (see this glossary entry) that represents the blocks that correspond to the components selected in the input argument. This is essentially a conversion operator from ComponentMask to BlockMask.
-
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
component_mask
The mask that selects individual components of the finite element
@@ -4074,7 +4074,7 @@
Return a vector of generalized support points.
-
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
+
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
For a given degree of freedom, return whether it is logically associated with a vertex, line, quad or hex.
-
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
-
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
-
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
+
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
+
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
+
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
Parameters
[in]
cell_dof_index
The index of a shape function or degree of freedom. This index must be in the range [0,dofs_per_cell).
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__PyramidP.html differs (JavaScript source, ASCII text, with very long lines (752))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__PyramidP.html 2023-11-25 15:25:54.260004673 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__PyramidP.html 2023-11-25 15:25:54.260004673 +0100
@@ -469,7 +469,7 @@
Given the values of a function at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., , where are the node functionals of the element (see also Node values or node functionals). The values are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function , i.e., is the finite element interpolant of with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.
-
In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are and that the node functionals associated with the current element are . Then, the fact that the element is based on generalized support points, implies that if we apply to a (possibly vector-valued) finite element function , the result must have the form – in other words, the value of the node functional applied to only depends on the values of at and not on values anywhere else, or integrals of , or any other kind of information.
-
The exact form of depends on the element. For example, for scalar Lagrange elements, we have that in fact . If you combine multiple scalar Lagrange elements via an FESystem object, then where is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that where is the normal vector of the face at which the shape function is defined.
-
Given all of this, what this function does is the following: If you input a list of values of a function at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in then you will get out a vector where equals dofs_per_cell.
+
Given the values of a function at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., , where are the node functionals of the element (see also Node values or node functionals). The values are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function , i.e., is the finite element interpolant of with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.
+
In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are and that the node functionals associated with the current element are . Then, the fact that the element is based on generalized support points, implies that if we apply to a (possibly vector-valued) finite element function , the result must have the form – in other words, the value of the node functional applied to only depends on the values of at and not on values anywhere else, or integrals of , or any other kind of information.
+
The exact form of depends on the element. For example, for scalar Lagrange elements, we have that in fact . If you combine multiple scalar Lagrange elements via an FESystem object, then where is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that where is the normal vector of the face at which the shape function is defined.
+
Given all of this, what this function does is the following: If you input a list of values of a function at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in then you will get out a vector where equals dofs_per_cell.
Parameters
[in]
support_point_values
An array of size dofs_per_cell (which equals the number of points the get_generalized_support_points() function will return) where each element is a vector with as many entries as the element has vector components. This array should contain the values of a function at the generalized support points of the current element.
@@ -2106,17 +2106,17 @@
Correct the shape Hessians by subtracting the terms corresponding to the Jacobian pushed forward gradient.
Before the correction, the Hessians would be given by
-
+\]" src="form_1140.png"/>
-
where . After the correction, the correct Hessians would be given by
-. After the correction, the correct Hessians would be given by
+
+\]" src="form_1142.png"/>
-
where is the Jacobian pushed-forward derivative.
+
where is the Jacobian pushed-forward derivative.
@@ -2160,21 +2160,21 @@
Correct the shape third derivatives by subtracting the terms corresponding to the Jacobian pushed forward gradient and second derivative.
Before the correction, the third derivatives would be given by
-
+\]" src="form_1144.png"/>
-
where . After the correction, the correct third derivative would be given by
-. After the correction, the correct third derivative would be given by
+
+\]" src="form_1145.png"/>
-
where is the Jacobian pushed-forward derivative and is the Jacobian pushed-forward second derivative.
+
where is the Jacobian pushed-forward derivative and is the Jacobian pushed-forward second derivative.
@@ -3001,7 +3001,7 @@
Returns
The index of this degree of freedom within the set of degrees of freedom on the entire cell. The returned value will be between zero and dofs_per_cell.
-
Note
This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a , then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
+
Note
This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a , then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
Return a block mask with as many elements as this object has blocks and of which exactly the one component is true that corresponds to the given argument. See the glossary for more information.
-
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
scalar
An object that represents a single scalar vector component of this finite element.
@@ -3830,7 +3830,7 @@
Given a component mask (see this glossary entry), produce a block mask (see this glossary entry) that represents the blocks that correspond to the components selected in the input argument. This is essentially a conversion operator from ComponentMask to BlockMask.
-
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
component_mask
The mask that selects individual components of the finite element
@@ -4090,7 +4090,7 @@
Return a vector of generalized support points.
-
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
+
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
For a given degree of freedom, return whether it is logically associated with a vertex, line, quad or hex.
-
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
-
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
-
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
+
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
+
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
+
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
Parameters
[in]
cell_dof_index
The index of a shape function or degree of freedom. This index must be in the range [0,dofs_per_cell).
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__PyramidPoly.html differs (JavaScript source, ASCII text, with very long lines (752))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__PyramidPoly.html 2023-11-25 15:25:54.316670187 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__PyramidPoly.html 2023-11-25 15:25:54.316670187 +0100
@@ -657,11 +657,11 @@
-
Given the values of a function at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., , where are the node functionals of the element (see also Node values or node functionals). The values are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function , i.e., is the finite element interpolant of with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.
-
In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are and that the node functionals associated with the current element are . Then, the fact that the element is based on generalized support points, implies that if we apply to a (possibly vector-valued) finite element function , the result must have the form – in other words, the value of the node functional applied to only depends on the values of at and not on values anywhere else, or integrals of , or any other kind of information.
-
The exact form of depends on the element. For example, for scalar Lagrange elements, we have that in fact . If you combine multiple scalar Lagrange elements via an FESystem object, then where is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that where is the normal vector of the face at which the shape function is defined.
-
Given all of this, what this function does is the following: If you input a list of values of a function at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in then you will get out a vector where equals dofs_per_cell.
+
Given the values of a function at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., , where are the node functionals of the element (see also Node values or node functionals). The values are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function , i.e., is the finite element interpolant of with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.
+
In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are and that the node functionals associated with the current element are . Then, the fact that the element is based on generalized support points, implies that if we apply to a (possibly vector-valued) finite element function , the result must have the form – in other words, the value of the node functional applied to only depends on the values of at and not on values anywhere else, or integrals of , or any other kind of information.
+
The exact form of depends on the element. For example, for scalar Lagrange elements, we have that in fact . If you combine multiple scalar Lagrange elements via an FESystem object, then where is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that where is the normal vector of the face at which the shape function is defined.
+
Given all of this, what this function does is the following: If you input a list of values of a function at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in then you will get out a vector where equals dofs_per_cell.
Parameters
[in]
support_point_values
An array of size dofs_per_cell (which equals the number of points the get_generalized_support_points() function will return) where each element is a vector with as many entries as the element has vector components. This array should contain the values of a function at the generalized support points of the current element.
@@ -1905,17 +1905,17 @@
Correct the shape Hessians by subtracting the terms corresponding to the Jacobian pushed forward gradient.
Before the correction, the Hessians would be given by
-
+\]" src="form_1140.png"/>
-
where . After the correction, the correct Hessians would be given by
-. After the correction, the correct Hessians would be given by
+
+\]" src="form_1142.png"/>
-
where is the Jacobian pushed-forward derivative.
+
where is the Jacobian pushed-forward derivative.
@@ -1959,21 +1959,21 @@
Correct the shape third derivatives by subtracting the terms corresponding to the Jacobian pushed forward gradient and second derivative.
Before the correction, the third derivatives would be given by
-
+\]" src="form_1144.png"/>
-
where . After the correction, the correct third derivative would be given by
-. After the correction, the correct third derivative would be given by
+
+\]" src="form_1145.png"/>
-
where is the Jacobian pushed-forward derivative and is the Jacobian pushed-forward second derivative.
+
where is the Jacobian pushed-forward derivative and is the Jacobian pushed-forward second derivative.
@@ -3001,7 +3001,7 @@
Returns
The index of this degree of freedom within the set of degrees of freedom on the entire cell. The returned value will be between zero and dofs_per_cell.
-
Note
This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a , then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
+
Note
This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a , then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
Return a block mask with as many elements as this object has blocks and of which exactly the one component is true that corresponds to the given argument. See the glossary for more information.
-
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
scalar
An object that represents a single scalar vector component of this finite element.
@@ -3830,7 +3830,7 @@
Given a component mask (see this glossary entry), produce a block mask (see this glossary entry) that represents the blocks that correspond to the components selected in the input argument. This is essentially a conversion operator from ComponentMask to BlockMask.
-
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
component_mask
The mask that selects individual components of the finite element
@@ -4090,7 +4090,7 @@
Return a vector of generalized support points.
-
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
+
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
For a given degree of freedom, return whether it is logically associated with a vertex, line, quad or hex.
-
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
-
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
-
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
+
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
+
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
+
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
Parameters
[in]
cell_dof_index
The index of a shape function or degree of freedom. This index must be in the range [0,dofs_per_cell).
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__Q.html differs (JavaScript source, ASCII text, with very long lines (759))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__Q.html 2023-11-25 15:25:54.376668965 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__Q.html 2023-11-25 15:25:54.376668965 +0100
@@ -483,7 +483,7 @@
The constructor creates a TensorProductPolynomials object that includes the tensor product of LagrangeEquidistant polynomials of degree p. This TensorProductPolynomials object provides all values and derivatives of the shape functions. In case a quadrature rule is given, the constructor creates a TensorProductPolynomials object that includes the tensor product of Lagrange polynomials with the support points from points.
Furthermore the constructor fills the interface_constraints, the prolongation (embedding) and the restriction matrices. These are implemented only up to a certain degree and may not be available for very high polynomial degree.
Unit support point distribution and conditioning of interpolation
-
When constructing an FE_Q element at polynomial degrees one or two, equidistant support points at 0 and 1 (linear case) or 0, 0.5, and 1 (quadratic case) are used. The unit support or nodal points xi are those points where the jth Lagrange polynomial satisfies the property, i.e., where one polynomial is one and all the others are zero. For higher polynomial degrees, the support points are non-equidistant by default, and chosen to be the support points of the (degree+1)-order Gauss-Lobatto quadrature rule. This point distribution yields well-conditioned Lagrange interpolation at arbitrary polynomial degrees. By contrast, polynomials based on equidistant points get increasingly ill-conditioned as the polynomial degree increases. In interpolation, this effect is known as the Runge phenomenon. For Galerkin methods, the Runge phenomenon is typically not visible in the solution quality but rather in the condition number of the associated system matrices. For example, the elemental mass matrix of equidistant points at degree 10 has condition number 2.6e6, whereas the condition number for Gauss-Lobatto points is around 400.
+
When constructing an FE_Q element at polynomial degrees one or two, equidistant support points at 0 and 1 (linear case) or 0, 0.5, and 1 (quadratic case) are used. The unit support or nodal points xi are those points where the jth Lagrange polynomial satisfies the property, i.e., where one polynomial is one and all the others are zero. For higher polynomial degrees, the support points are non-equidistant by default, and chosen to be the support points of the (degree+1)-order Gauss-Lobatto quadrature rule. This point distribution yields well-conditioned Lagrange interpolation at arbitrary polynomial degrees. By contrast, polynomials based on equidistant points get increasingly ill-conditioned as the polynomial degree increases. In interpolation, this effect is known as the Runge phenomenon. For Galerkin methods, the Runge phenomenon is typically not visible in the solution quality but rather in the condition number of the associated system matrices. For example, the elemental mass matrix of equidistant points at degree 10 has condition number 2.6e6, whereas the condition number for Gauss-Lobatto points is around 400.
The Gauss-Lobatto points in 1d include the end points 0 and +1 of the unit interval. The interior points are shifted towards the end points, which gives a denser point distribution close to the element boundary.
If combined with Gauss-Lobatto quadrature, FE_Q based on the default support points gives diagonal mass matrices. This case is demonstrated in step-48. However, this element can be combined with arbitrary quadrature rules through the usual FEValues approach, including full Gauss quadrature. In the general case, the mass matrix is non-diagonal.
Numbering of the degrees of freedom (DoFs)
@@ -544,9 +544,9 @@
-
element, shape function 0
+
element, shape function 0
-
element, shape function 1
+
element, shape function 1
@@ -559,9 +559,9 @@
-
element, shape function 2
+
element, shape function 2
-
element, shape function 3
+
element, shape function 3
Q2 elements
@@ -669,9 +669,9 @@
-
element, shape function 0
+
element, shape function 0
-
element, shape function 1
+
element, shape function 1
@@ -684,9 +684,9 @@
-
element, shape function 2
+
element, shape function 2
-
element, shape function 3
+
element, shape function 3
@@ -699,9 +699,9 @@
-
element, shape function 4
+
element, shape function 4
-
element, shape function 5
+
element, shape function 5
@@ -714,9 +714,9 @@
-
element, shape function 6
+
element, shape function 6
-
element, shape function 7
+
element, shape function 7
@@ -726,7 +726,7 @@
-
element, shape function 8
+
element, shape function 8
@@ -895,9 +895,9 @@
-
element, shape function 0
+
element, shape function 0
-
element, shape function 1
+
element, shape function 1
@@ -910,9 +910,9 @@
-
element, shape function 2
+
element, shape function 2
-
element, shape function 3
+
element, shape function 3
@@ -925,9 +925,9 @@
-
element, shape function 4
+
element, shape function 4
-
element, shape function 5
+
element, shape function 5
@@ -940,9 +940,9 @@
-
element, shape function 6
+
element, shape function 6
-
element, shape function 7
+
element, shape function 7
@@ -955,9 +955,9 @@
-
element, shape function 8
+
element, shape function 8
-
element, shape function 9
+
element, shape function 9
@@ -970,9 +970,9 @@
-
element, shape function 10
+
element, shape function 10
-
element, shape function 11
+
element, shape function 11
@@ -985,9 +985,9 @@
-
element, shape function 12
+
element, shape function 12
-
element, shape function 13
+
element, shape function 13
@@ -1000,9 +1000,9 @@
-
element, shape function 14
+
element, shape function 14
-
element, shape function 15
+
element, shape function 15
@@ -1015,9 +1015,9 @@
-
element, shape function 16
+
element, shape function 16
-
element, shape function 17
+
element, shape function 17
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__Q__Base.html differs (JavaScript source, ASCII text, with very long lines (759))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__Q__Base.html 2023-11-25 15:25:54.433334479 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__Q__Base.html 2023-11-25 15:25:54.433334479 +0100
@@ -2523,17 +2523,17 @@
Correct the shape Hessians by subtracting the terms corresponding to the Jacobian pushed forward gradient.
Before the correction, the Hessians would be given by
-
+\]" src="form_1140.png"/>
-
where . After the correction, the correct Hessians would be given by
-. After the correction, the correct Hessians would be given by
+
+\]" src="form_1142.png"/>
-
where is the Jacobian pushed-forward derivative.
+
where is the Jacobian pushed-forward derivative.
@@ -2577,21 +2577,21 @@
Correct the shape third derivatives by subtracting the terms corresponding to the Jacobian pushed forward gradient and second derivative.
Before the correction, the third derivatives would be given by
-
+\]" src="form_1144.png"/>
-
where . After the correction, the correct third derivative would be given by
-. After the correction, the correct third derivative would be given by
+
+\]" src="form_1145.png"/>
-
where is the Jacobian pushed-forward derivative and is the Jacobian pushed-forward second derivative.
+
where is the Jacobian pushed-forward derivative and is the Jacobian pushed-forward second derivative.
@@ -3895,7 +3895,7 @@
Return a block mask with as many elements as this object has blocks and of which exactly the one component is true that corresponds to the given argument. See the glossary for more information.
-
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
scalar
An object that represents a single scalar vector component of this finite element.
@@ -4003,7 +4003,7 @@
Given a component mask (see this glossary entry), produce a block mask (see this glossary entry) that represents the blocks that correspond to the components selected in the input argument. This is essentially a conversion operator from ComponentMask to BlockMask.
-
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
component_mask
The mask that selects individual components of the finite element
@@ -4232,7 +4232,7 @@
Return a vector of generalized support points.
-
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
+
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
For a given degree of freedom, return whether it is logically associated with a vertex, line, quad or hex.
-
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
-
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
-
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
+
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
+
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
+
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
Parameters
[in]
cell_dof_index
The index of a shape function or degree of freedom. This index must be in the range [0,dofs_per_cell).
@@ -4338,11 +4338,11 @@
-
Given the values of a function at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., , where are the node functionals of the element (see also Node values or node functionals). The values are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function , i.e., is the finite element interpolant of with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.
-
In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are and that the node functionals associated with the current element are . Then, the fact that the element is based on generalized support points, implies that if we apply to a (possibly vector-valued) finite element function , the result must have the form – in other words, the value of the node functional applied to only depends on the values of at and not on values anywhere else, or integrals of , or any other kind of information.
-
The exact form of depends on the element. For example, for scalar Lagrange elements, we have that in fact . If you combine multiple scalar Lagrange elements via an FESystem object, then where is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that where is the normal vector of the face at which the shape function is defined.
-
Given all of this, what this function does is the following: If you input a list of values of a function at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in then you will get out a vector where equals dofs_per_cell.
+
Given the values of a function at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., , where are the node functionals of the element (see also Node values or node functionals). The values are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function , i.e., is the finite element interpolant of with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.
+
In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are and that the node functionals associated with the current element are . Then, the fact that the element is based on generalized support points, implies that if we apply to a (possibly vector-valued) finite element function , the result must have the form – in other words, the value of the node functional applied to only depends on the values of at and not on values anywhere else, or integrals of , or any other kind of information.
+
The exact form of depends on the element. For example, for scalar Lagrange elements, we have that in fact . If you combine multiple scalar Lagrange elements via an FESystem object, then where is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that where is the normal vector of the face at which the shape function is defined.
+
Given all of this, what this function does is the following: If you input a list of values of a function at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in then you will get out a vector where equals dofs_per_cell.
Parameters
[in]
support_point_values
An array of size dofs_per_cell (which equals the number of points the get_generalized_support_points() function will return) where each element is a vector with as many entries as the element has vector components. This array should contain the values of a function at the generalized support points of the current element.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__Q__Bubbles.html differs (JavaScript source, ASCII text, with very long lines (759))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__Q__Bubbles.html 2023-11-25 15:25:54.489999993 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__Q__Bubbles.html 2023-11-25 15:25:54.489999993 +0100
@@ -484,17 +484,17 @@
Implementation of a scalar Lagrange finite element that yields the finite element space of continuous, piecewise polynomials of degree p in each coordinate direction plus some (non-normalized) bubble enrichment space spanned by the additional shape function that yields the finite element space of continuous, piecewise polynomials of degree p in each coordinate direction plus some (non-normalized) bubble enrichment space spanned by the additional shape function . for . If is one, then the first factor disappears and one receives the usual bubble function centered at the mid-point of the cell. Because these last shape functions have polynomial degree is , the overall polynomial degree of the shape functions in the space described by this class is .
+\left[\prod_{i=0}^{dim-1}(x_i(1-x_i))\right]$" src="form_1157.png"/>. for . If is one, then the first factor disappears and one receives the usual bubble function centered at the mid-point of the cell. Because these last shape functions have polynomial degree is , the overall polynomial degree of the shape functions in the space described by this class is .
This class is realized using tensor product polynomials based on equidistant or given support points, in the same way as one can provide support points to the FE_Q class's constructors.
For more information about the spacedim template parameter check the documentation of the FiniteElement class, or the one of Triangulation.
-
Due to the fact that the enrichments are small almost everywhere for large , the condition number for the mass and stiffness matrix quickly increaseses with increasing . Below you see a comparison with FE_Q(QGaussLobatto(p+1)) for dim=1.
+
Due to the fact that the enrichments are small almost everywhere for large , the condition number for the mass and stiffness matrix quickly increaseses with increasing . Below you see a comparison with FE_Q(QGaussLobatto(p+1)) for dim=1.
-
Therefore, this element should be used with care for .
+
Therefore, this element should be used with care for .
Implementation
The constructor creates a TensorProductPolynomials object that includes the tensor product of LagrangeEquidistant polynomials of degree p plus the bubble enrichments. This TensorProductPolynomialsBubbles object provides all values and derivatives of the shape functions. In case a quadrature rule is given, the constructor creates a TensorProductPolynomialsBubbles object that includes the tensor product of Lagrange polynomials with the support points from points and the bubble enrichments as defined above.
Furthermore the constructor fills the interface_constrains, the prolongation (embedding) and the restriction matrices.
@@ -720,11 +720,11 @@
-
Given the values of a function at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., , where are the node functionals of the element (see also Node values or node functionals). The values are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function , i.e., is the finite element interpolant of with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.
-
In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are and that the node functionals associated with the current element are . Then, the fact that the element is based on generalized support points, implies that if we apply to a (possibly vector-valued) finite element function , the result must have the form – in other words, the value of the node functional applied to only depends on the values of at and not on values anywhere else, or integrals of , or any other kind of information.
-
The exact form of depends on the element. For example, for scalar Lagrange elements, we have that in fact . If you combine multiple scalar Lagrange elements via an FESystem object, then where is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that where is the normal vector of the face at which the shape function is defined.
-
Given all of this, what this function does is the following: If you input a list of values of a function at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in then you will get out a vector where equals dofs_per_cell.
+
Given the values of a function at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., , where are the node functionals of the element (see also Node values or node functionals). The values are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function , i.e., is the finite element interpolant of with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.
+
In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are and that the node functionals associated with the current element are . Then, the fact that the element is based on generalized support points, implies that if we apply to a (possibly vector-valued) finite element function , the result must have the form – in other words, the value of the node functional applied to only depends on the values of at and not on values anywhere else, or integrals of , or any other kind of information.
+
The exact form of depends on the element. For example, for scalar Lagrange elements, we have that in fact . If you combine multiple scalar Lagrange elements via an FESystem object, then where is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that where is the normal vector of the face at which the shape function is defined.
+
Given all of this, what this function does is the following: If you input a list of values of a function at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in then you will get out a vector where equals dofs_per_cell.
Parameters
[in]
support_point_values
An array of size dofs_per_cell (which equals the number of points the get_generalized_support_points() function will return) where each element is a vector with as many entries as the element has vector components. This array should contain the values of a function at the generalized support points of the current element.
@@ -2759,17 +2759,17 @@
Correct the shape Hessians by subtracting the terms corresponding to the Jacobian pushed forward gradient.
Before the correction, the Hessians would be given by
-
+\]" src="form_1140.png"/>
-
where . After the correction, the correct Hessians would be given by
-. After the correction, the correct Hessians would be given by
+
+\]" src="form_1142.png"/>
-
where is the Jacobian pushed-forward derivative.
+
where is the Jacobian pushed-forward derivative.
@@ -2813,21 +2813,21 @@
Correct the shape third derivatives by subtracting the terms corresponding to the Jacobian pushed forward gradient and second derivative.
Before the correction, the third derivatives would be given by
-
+\]" src="form_1144.png"/>
-
where . After the correction, the correct third derivative would be given by
-. After the correction, the correct third derivative would be given by
+
+\]" src="form_1145.png"/>
-
where is the Jacobian pushed-forward derivative and is the Jacobian pushed-forward second derivative.
+
where is the Jacobian pushed-forward derivative and is the Jacobian pushed-forward second derivative.
@@ -4029,7 +4029,7 @@
Return a block mask with as many elements as this object has blocks and of which exactly the one component is true that corresponds to the given argument. See the glossary for more information.
-
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
scalar
An object that represents a single scalar vector component of this finite element.
@@ -4137,7 +4137,7 @@
Given a component mask (see this glossary entry), produce a block mask (see this glossary entry) that represents the blocks that correspond to the components selected in the input argument. This is essentially a conversion operator from ComponentMask to BlockMask.
-
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
component_mask
The mask that selects individual components of the finite element
@@ -4366,7 +4366,7 @@
Return a vector of generalized support points.
-
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
+
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
For a given degree of freedom, return whether it is logically associated with a vertex, line, quad or hex.
-
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
-
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
-
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
+
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
+
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
+
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
Parameters
[in]
cell_dof_index
The index of a shape function or degree of freedom. This index must be in the range [0,dofs_per_cell).
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__Q__DG0.html differs (JavaScript source, ASCII text, with very long lines (759))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__Q__DG0.html 2023-11-25 15:25:54.546665504 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__Q__DG0.html 2023-11-25 15:25:54.546665504 +0100
@@ -891,11 +891,11 @@
-
Given the values of a function at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., , where are the node functionals of the element (see also Node values or node functionals). The values are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function , i.e., is the finite element interpolant of with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.
-
In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are and that the node functionals associated with the current element are . Then, the fact that the element is based on generalized support points, implies that if we apply to a (possibly vector-valued) finite element function , the result must have the form – in other words, the value of the node functional applied to only depends on the values of at and not on values anywhere else, or integrals of , or any other kind of information.
-
The exact form of depends on the element. For example, for scalar Lagrange elements, we have that in fact . If you combine multiple scalar Lagrange elements via an FESystem object, then where is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that where is the normal vector of the face at which the shape function is defined.
-
Given all of this, what this function does is the following: If you input a list of values of a function at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in then you will get out a vector where equals dofs_per_cell.
+
Given the values of a function at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., , where are the node functionals of the element (see also Node values or node functionals). The values are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function , i.e., is the finite element interpolant of with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.
+
In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are and that the node functionals associated with the current element are . Then, the fact that the element is based on generalized support points, implies that if we apply to a (possibly vector-valued) finite element function , the result must have the form – in other words, the value of the node functional applied to only depends on the values of at and not on values anywhere else, or integrals of , or any other kind of information.
+
The exact form of depends on the element. For example, for scalar Lagrange elements, we have that in fact . If you combine multiple scalar Lagrange elements via an FESystem object, then where is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that where is the normal vector of the face at which the shape function is defined.
+
Given all of this, what this function does is the following: If you input a list of values of a function at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in then you will get out a vector where equals dofs_per_cell.
Parameters
[in]
support_point_values
An array of size dofs_per_cell (which equals the number of points the get_generalized_support_points() function will return) where each element is a vector with as many entries as the element has vector components. This array should contain the values of a function at the generalized support points of the current element.
@@ -2907,17 +2907,17 @@
Correct the shape Hessians by subtracting the terms corresponding to the Jacobian pushed forward gradient.
Before the correction, the Hessians would be given by
-
+\]" src="form_1140.png"/>
-
where . After the correction, the correct Hessians would be given by
-. After the correction, the correct Hessians would be given by
+
+\]" src="form_1142.png"/>
-
where is the Jacobian pushed-forward derivative.
+
where is the Jacobian pushed-forward derivative.
@@ -2961,21 +2961,21 @@
Correct the shape third derivatives by subtracting the terms corresponding to the Jacobian pushed forward gradient and second derivative.
Before the correction, the third derivatives would be given by
-
+\]" src="form_1144.png"/>
-
where . After the correction, the correct third derivative would be given by
-. After the correction, the correct third derivative would be given by
+
+\]" src="form_1145.png"/>
-
where is the Jacobian pushed-forward derivative and is the Jacobian pushed-forward second derivative.
+
where is the Jacobian pushed-forward derivative and is the Jacobian pushed-forward second derivative.
@@ -4177,7 +4177,7 @@
Return a block mask with as many elements as this object has blocks and of which exactly the one component is true that corresponds to the given argument. See the glossary for more information.
-
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
scalar
An object that represents a single scalar vector component of this finite element.
@@ -4285,7 +4285,7 @@
Given a component mask (see this glossary entry), produce a block mask (see this glossary entry) that represents the blocks that correspond to the components selected in the input argument. This is essentially a conversion operator from ComponentMask to BlockMask.
-
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
component_mask
The mask that selects individual components of the finite element
@@ -4514,7 +4514,7 @@
Return a vector of generalized support points.
-
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
+
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
For a given degree of freedom, return whether it is logically associated with a vertex, line, quad or hex.
-
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
-
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
-
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
+
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
+
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
+
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
Parameters
[in]
cell_dof_index
The index of a shape function or degree of freedom. This index must be in the range [0,dofs_per_cell).
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__Q__Hierarchical.html differs (JavaScript source, ASCII text, with very long lines (752))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__Q__Hierarchical.html 2023-11-25 15:25:54.613330814 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__Q__Hierarchical.html 2023-11-25 15:25:54.613330814 +0100
@@ -519,7 +519,7 @@
Numbering of the degrees of freedom (DoFs)
The original ordering of the shape functions represented by the TensorProductPolynomials is a tensor product numbering. However, the shape functions on a cell are renumbered beginning with the shape functions whose support points are at the vertices, then on the line, on the quads, and finally (for 3d) on the hexes. To be explicit, these numberings are listed in the following:
Q1 elements
-
The element is of polynomial degree one and, consequently, is exactly the same as the element in class FE_Q. In particular, the shape function are defined in the exact same way:
+
The element is of polynomial degree one and, consequently, is exactly the same as the element in class FE_Q. In particular, the shape function are defined in the exact same way:
1d case:
* 0-------1
@@ -575,9 +575,9 @@
-
element, shape function 0
+
element, shape function 0
-
element, shape function 1
+
element, shape function 1
@@ -590,9 +590,9 @@
-
element, shape function 2
+
element, shape function 2
-
element, shape function 3
+
element, shape function 3
Q2 elements
@@ -700,9 +700,9 @@
-
element, shape function 0
+
element, shape function 0
-
element, shape function 1
+
element, shape function 1
@@ -715,9 +715,9 @@
-
element, shape function 2
+
element, shape function 2
-
element, shape function 3
+
element, shape function 3
@@ -730,9 +730,9 @@
-
element, shape function 4
+
element, shape function 4
-
element, shape function 5
+
element, shape function 5
@@ -745,9 +745,9 @@
-
element, shape function 6
+
element, shape function 6
-
element, shape function 7
+
element, shape function 7
@@ -757,7 +757,7 @@
-
element, shape function 8
+
element, shape function 8
@@ -788,9 +788,9 @@
-
element, shape function 0
+
element, shape function 0
-
element, shape function 1
+
element, shape function 1
@@ -803,9 +803,9 @@
-
element, shape function 2
+
element, shape function 2
-
element, shape function 3
+
element, shape function 3
@@ -818,9 +818,9 @@
-
element, shape function 4
+
element, shape function 4
-
element, shape function 5
+
element, shape function 5
@@ -833,9 +833,9 @@
-
element, shape function 6
+
element, shape function 6
-
element, shape function 7
+
element, shape function 7
@@ -848,9 +848,9 @@
-
element, shape function 8
+
element, shape function 8
-
element, shape function 9
+
element, shape function 9
@@ -863,9 +863,9 @@
-
element, shape function 10
+
element, shape function 10
-
element, shape function 11
+
element, shape function 11
@@ -878,9 +878,9 @@
-
element, shape function 12
+
element, shape function 12
-
element, shape function 13
+
element, shape function 13
@@ -893,9 +893,9 @@
-
element, shape function 14
+
element, shape function 14
-
element, shape function 15
+
element, shape function 15
Q4 elements
@@ -926,9 +926,9 @@
-
element, shape function 0
+
element, shape function 0
-
element, shape function 1
+
element, shape function 1
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__Q__iso__Q1.html differs (JavaScript source, ASCII text, with very long lines (759))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__Q__iso__Q1.html 2023-11-25 15:25:54.669996329 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__Q__iso__Q1.html 2023-11-25 15:25:54.666663064 +0100
@@ -486,7 +486,7 @@
-
Stokes/Navier Stokes systems such as the one discussed in step-22 could be solved with Q2-iso-Q1 elements for velocities instead of elements. Combined with pressures they give a stable mixed element pair. However, they perform worse than the standard (Taylor-Hood ) approach in most situations. (See, for example, [Boffi2011] .) This combination of subdivided elements for the velocity and non-subdivided elements for the pressure is sometimes called the "Bercovier-Pironneau
+
Stokes/Navier Stokes systems such as the one discussed in step-22 could be solved with Q2-iso-Q1 elements for velocities instead of elements. Combined with pressures they give a stable mixed element pair. However, they perform worse than the standard (Taylor-Hood ) approach in most situations. (See, for example, [Boffi2011] .) This combination of subdivided elements for the velocity and non-subdivided elements for the pressure is sometimes called the "Bercovier-Pironneau
element" and dates back to around the same time as the Taylor-Hood element (namely, the mid-1970s). For more information, see the paper by Bercovier and Pironneau from 1979 [Bercovier1979], and for the origins of the comparable Taylor-Hood element see [Taylor73] from 1973.
@@ -2688,17 +2688,17 @@
Correct the shape Hessians by subtracting the terms corresponding to the Jacobian pushed forward gradient.
Before the correction, the Hessians would be given by
-
+\]" src="form_1140.png"/>
-
where . After the correction, the correct Hessians would be given by
-. After the correction, the correct Hessians would be given by
+
+\]" src="form_1142.png"/>
-
where is the Jacobian pushed-forward derivative.
+
where is the Jacobian pushed-forward derivative.
@@ -2742,21 +2742,21 @@
Correct the shape third derivatives by subtracting the terms corresponding to the Jacobian pushed forward gradient and second derivative.
Before the correction, the third derivatives would be given by
-
+\]" src="form_1144.png"/>
-
where . After the correction, the correct third derivative would be given by
-. After the correction, the correct third derivative would be given by
+
+\]" src="form_1145.png"/>
-
where is the Jacobian pushed-forward derivative and is the Jacobian pushed-forward second derivative.
+
where is the Jacobian pushed-forward derivative and is the Jacobian pushed-forward second derivative.
@@ -3958,7 +3958,7 @@
Return a block mask with as many elements as this object has blocks and of which exactly the one component is true that corresponds to the given argument. See the glossary for more information.
-
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
scalar
An object that represents a single scalar vector component of this finite element.
@@ -4066,7 +4066,7 @@
Given a component mask (see this glossary entry), produce a block mask (see this glossary entry) that represents the blocks that correspond to the components selected in the input argument. This is essentially a conversion operator from ComponentMask to BlockMask.
-
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
component_mask
The mask that selects individual components of the finite element
@@ -4295,7 +4295,7 @@
Return a vector of generalized support points.
-
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
+
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
For a given degree of freedom, return whether it is logically associated with a vertex, line, quad or hex.
-
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
-
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
-
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
+
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
+
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
+
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
Parameters
[in]
cell_dof_index
The index of a shape function or degree of freedom. This index must be in the range [0,dofs_per_cell).
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__RT__Bubbles.html differs (JavaScript source, ASCII text, with very long lines (752))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__RT__Bubbles.html 2023-11-25 15:25:54.726661843 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__RT__Bubbles.html 2023-11-25 15:25:54.726661843 +0100
@@ -493,7 +493,7 @@
class FE_RT_Bubbles< dim >
This class implements a curl-enhanced Raviart-Thomas elements, conforming with Hdiv space. The node functionals are defined as point values in Gauss-Lobatto points. These elements generate vector fields with normal components continuous between mesh cells. The purpose of this finite element is in localizing the interactions between degrees of freedom around the nodes when an appropriate quadrature rule is used, leading to a block-diagonal mass matrix (even with full-tensor coefficient).
The elements are defined through enrichment of classical Raviart-Thomas elements with extra curls, so that the Hdiv conformity is preserved, and the total number of degrees of freedom of FE_RT_Bubbles of order k is equal to the number of DoFs in dim copies of FE_Q of order k.
Note
Unlike Raviart-Thomas, the lowest possible order for this enhanced finite element is 1, i.e. .
-
The matching pressure space for FE_RT_Bubbles of order k is FE_DGQ of order k-1. With the exact integration, this pair yields -st order of convergence in -norm for a vector variable and -th order in -norm for a scalar one (same as ).
+
The matching pressure space for FE_RT_Bubbles of order k is FE_DGQ of order k-1. With the exact integration, this pair yields -st order of convergence in -norm for a vector variable and -th order in -norm for a scalar one (same as ).
For this enhanced Raviart-Thomas element, the node values are not cell and face moments with respect to certain polynomials, but the values in Gauss-Lobatto quadrature points. The nodal values on edges (faces in 3d) are evaluated first, according to the natural ordering of the edges (faces) of a cell. The interior degrees of freedom are evaluated last.
For an RT-Bubbles element of degree k, we choose (k+1)dim-1 Gauss-Lobatto points on each face. These points are ordered lexicographically with respect to the orientation of the face. In the interior of the cells, the values are computed using an anisotropic Gauss-Lobatto formula for integration. The mass matrix assembled with the use of this same quadrature rule, is block diagonal with blocks corresponding to quadrature points. See "Higher order multipoint flux
mixed finite element methods on quadrilaterals and hexahedra" for more details.
Given the values of a function at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., , where are the node functionals of the element (see also Node values or node functionals). The values are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function , i.e., is the finite element interpolant of with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.
-
In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are and that the node functionals associated with the current element are . Then, the fact that the element is based on generalized support points, implies that if we apply to a (possibly vector-valued) finite element function , the result must have the form – in other words, the value of the node functional applied to only depends on the values of at and not on values anywhere else, or integrals of , or any other kind of information.
-
The exact form of depends on the element. For example, for scalar Lagrange elements, we have that in fact . If you combine multiple scalar Lagrange elements via an FESystem object, then where is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that where is the normal vector of the face at which the shape function is defined.
-
Given all of this, what this function does is the following: If you input a list of values of a function at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in then you will get out a vector where equals dofs_per_cell.
+
Given the values of a function at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., , where are the node functionals of the element (see also Node values or node functionals). The values are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function , i.e., is the finite element interpolant of with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.
+
In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are and that the node functionals associated with the current element are . Then, the fact that the element is based on generalized support points, implies that if we apply to a (possibly vector-valued) finite element function , the result must have the form – in other words, the value of the node functional applied to only depends on the values of at and not on values anywhere else, or integrals of , or any other kind of information.
+
The exact form of depends on the element. For example, for scalar Lagrange elements, we have that in fact . If you combine multiple scalar Lagrange elements via an FESystem object, then where is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that where is the normal vector of the face at which the shape function is defined.
+
Given all of this, what this function does is the following: If you input a list of values of a function at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in then you will get out a vector where equals dofs_per_cell.
Parameters
[in]
support_point_values
An array of size dofs_per_cell (which equals the number of points the get_generalized_support_points() function will return) where each element is a vector with as many entries as the element has vector components. This array should contain the values of a function at the generalized support points of the current element.
@@ -3016,7 +3016,7 @@
Returns
The index of this degree of freedom within the set of degrees of freedom on the entire cell. The returned value will be between zero and dofs_per_cell.
-
Note
This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a , then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
+
Note
This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a , then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
Return a block mask with as many elements as this object has blocks and of which exactly the one component is true that corresponds to the given argument. See the glossary for more information.
-
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
scalar
An object that represents a single scalar vector component of this finite element.
@@ -3845,7 +3845,7 @@
Given a component mask (see this glossary entry), produce a block mask (see this glossary entry) that represents the blocks that correspond to the components selected in the input argument. This is essentially a conversion operator from ComponentMask to BlockMask.
-
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
component_mask
The mask that selects individual components of the finite element
@@ -4105,7 +4105,7 @@
Return a vector of generalized support points.
-
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
+
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
For a given degree of freedom, return whether it is logically associated with a vertex, line, quad or hex.
-
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
-
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
-
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
+
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
+
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
+
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
Parameters
[in]
cell_dof_index
The index of a shape function or degree of freedom. This index must be in the range [0,dofs_per_cell).
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__RannacherTurek.html differs (JavaScript source, ASCII text, with very long lines (752))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__RannacherTurek.html 2023-11-25 15:25:54.783327356 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__RannacherTurek.html 2023-11-25 15:25:54.783327356 +0100
@@ -479,8 +479,8 @@
Implementation of the Rannacher-Turek element. This element is used to generate a stable pair of function spaces for the Stokes equation without having to increase the polynomial degree of the velocity space as much as one would do for the stable Taylor-Hood element which uses the pair for velocity and pressure. That said, like many other non-conforming elements, it can also be used for the discretization of the Laplace equation. The element was first described in R. Rannacher and S. Turek: "Simple non-conforming quadrilateral Stokes element", Numerical Methods for Partial Differential Equations, vol. 8, pp. 97-112, 1992.
-
The shape functions generated by this element are in general discontinuous, and consequently the element is not conforming (i.e., it is a "non-conforming" element). However, the shape functions are constructed in such a way that the jump along faces has mean value zero, and consequently there is some sort of conformity in the element: a conforming element would have a pointwise zero jump, a completely discontinuous element like the FE_DGQ elements can have entirely arbitrary values for the jump across a face, and the current element is somewhere in the middle because its jump is nonzero but at least has mean value zero.
+class FE_RannacherTurek< dim >
Implementation of the Rannacher-Turek element. This element is used to generate a stable pair of function spaces for the Stokes equation without having to increase the polynomial degree of the velocity space as much as one would do for the stable Taylor-Hood element which uses the pair for velocity and pressure. That said, like many other non-conforming elements, it can also be used for the discretization of the Laplace equation. The element was first described in R. Rannacher and S. Turek: "Simple non-conforming quadrilateral Stokes element", Numerical Methods for Partial Differential Equations, vol. 8, pp. 97-112, 1992.
+
The shape functions generated by this element are in general discontinuous, and consequently the element is not conforming (i.e., it is a "non-conforming" element). However, the shape functions are constructed in such a way that the jump along faces has mean value zero, and consequently there is some sort of conformity in the element: a conforming element would have a pointwise zero jump, a completely discontinuous element like the FE_DGQ elements can have entirely arbitrary values for the jump across a face, and the current element is somewhere in the middle because its jump is nonzero but at least has mean value zero.
The element is currently implemented only in dimension 2, for the lowest polynomial order, and without hanging nodes and restriction/prolongation.
Interpolation
Node values
@@ -731,11 +731,11 @@
-
Given the values of a function at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., , where are the node functionals of the element (see also Node values or node functionals). The values are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function , i.e., is the finite element interpolant of with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.
-
In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are and that the node functionals associated with the current element are . Then, the fact that the element is based on generalized support points, implies that if we apply to a (possibly vector-valued) finite element function , the result must have the form – in other words, the value of the node functional applied to only depends on the values of at and not on values anywhere else, or integrals of , or any other kind of information.
-
The exact form of depends on the element. For example, for scalar Lagrange elements, we have that in fact . If you combine multiple scalar Lagrange elements via an FESystem object, then where is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that where is the normal vector of the face at which the shape function is defined.
-
Given all of this, what this function does is the following: If you input a list of values of a function at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in then you will get out a vector where equals dofs_per_cell.
+
Given the values of a function at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., , where are the node functionals of the element (see also Node values or node functionals). The values are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function , i.e., is the finite element interpolant of with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.
+
In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are and that the node functionals associated with the current element are . Then, the fact that the element is based on generalized support points, implies that if we apply to a (possibly vector-valued) finite element function , the result must have the form – in other words, the value of the node functional applied to only depends on the values of at and not on values anywhere else, or integrals of , or any other kind of information.
+
The exact form of depends on the element. For example, for scalar Lagrange elements, we have that in fact . If you combine multiple scalar Lagrange elements via an FESystem object, then where is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that where is the normal vector of the face at which the shape function is defined.
+
Given all of this, what this function does is the following: If you input a list of values of a function at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in then you will get out a vector where equals dofs_per_cell.
Parameters
[in]
support_point_values
An array of size dofs_per_cell (which equals the number of points the get_generalized_support_points() function will return) where each element is a vector with as many entries as the element has vector components. This array should contain the values of a function at the generalized support points of the current element.
@@ -2033,17 +2033,17 @@
Correct the shape Hessians by subtracting the terms corresponding to the Jacobian pushed forward gradient.
Before the correction, the Hessians would be given by
-
+\]" src="form_1140.png"/>
-
where . After the correction, the correct Hessians would be given by
-. After the correction, the correct Hessians would be given by
+
+\]" src="form_1142.png"/>
-
where is the Jacobian pushed-forward derivative.
+
where is the Jacobian pushed-forward derivative.
@@ -2087,21 +2087,21 @@
Correct the shape third derivatives by subtracting the terms corresponding to the Jacobian pushed forward gradient and second derivative.
Before the correction, the third derivatives would be given by
-
+\]" src="form_1144.png"/>
-
where . After the correction, the correct third derivative would be given by
-. After the correction, the correct third derivative would be given by
+
+\]" src="form_1145.png"/>
-
where is the Jacobian pushed-forward derivative and is the Jacobian pushed-forward second derivative.
+
where is the Jacobian pushed-forward derivative and is the Jacobian pushed-forward second derivative.
@@ -3067,7 +3067,7 @@
Returns
The index of this degree of freedom within the set of degrees of freedom on the entire cell. The returned value will be between zero and dofs_per_cell.
-
Note
This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a , then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
+
Note
This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a , then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
Return a block mask with as many elements as this object has blocks and of which exactly the one component is true that corresponds to the given argument. See the glossary for more information.
-
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
scalar
An object that represents a single scalar vector component of this finite element.
@@ -3896,7 +3896,7 @@
Given a component mask (see this glossary entry), produce a block mask (see this glossary entry) that represents the blocks that correspond to the components selected in the input argument. This is essentially a conversion operator from ComponentMask to BlockMask.
-
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
component_mask
The mask that selects individual components of the finite element
@@ -4156,7 +4156,7 @@
Return a vector of generalized support points.
-
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
+
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
For a given degree of freedom, return whether it is logically associated with a vertex, line, quad or hex.
-
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
-
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
-
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
+
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
+
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
+
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
Parameters
[in]
cell_dof_index
The index of a shape function or degree of freedom. This index must be in the range [0,dofs_per_cell).
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__RaviartThomas.html differs (JavaScript source, ASCII text, with very long lines (752))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__RaviartThomas.html 2023-11-25 15:25:54.843326135 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__RaviartThomas.html 2023-11-25 15:25:54.843326135 +0100
@@ -502,11 +502,11 @@
Implementation of Raviart-Thomas (RT) elements. The Raviart-Thomas space is designed to solve problems in which the solution only lives in the space , rather than in the more commonly used space . In other words, the solution must be a vector field whose divergence is square integrable, but for which the gradient may not be square integrable. The typical application for this space (and these elements) is to the mixed formulation of the Laplace equation and related situations, see for example step-20. The defining characteristic of functions in is that they are in general discontinuous – but that if you draw a line in 2d (or a surface in 3d), then the normal component of the vector field must be continuous across the line (or surface) even though the tangential component may not be. As a consequence, the Raviart-Thomas element is constructed in such a way that (i) it is vector-valued, (ii) the shape functions are discontinuous, but (iii) the normal component of the vector field represented by each shape function is continuous across the faces of cells.
+class FE_RaviartThomas< dim >
Implementation of Raviart-Thomas (RT) elements. The Raviart-Thomas space is designed to solve problems in which the solution only lives in the space , rather than in the more commonly used space . In other words, the solution must be a vector field whose divergence is square integrable, but for which the gradient may not be square integrable. The typical application for this space (and these elements) is to the mixed formulation of the Laplace equation and related situations, see for example step-20. The defining characteristic of functions in is that they are in general discontinuous – but that if you draw a line in 2d (or a surface in 3d), then the normal component of the vector field must be continuous across the line (or surface) even though the tangential component may not be. As a consequence, the Raviart-Thomas element is constructed in such a way that (i) it is vector-valued, (ii) the shape functions are discontinuous, but (iii) the normal component of the vector field represented by each shape function is continuous across the faces of cells.
Other properties of the Raviart-Thomas element are that (i) it is not a primitive element ; (ii) the shape functions are defined so that certain integrals over the faces are either zero or one, rather than the common case of certain point values being either zero or one. (There is, however, the FE_RaviartThomasNodal element that uses point values.)
We follow the commonly used – though confusing – definition of the "degree" of RT elements. Specifically, the "degree" of the element denotes the polynomial degree of the largest complete polynomial subspace contained in the finite element space, even if the space may contain shape functions of higher polynomial degree. The lowest order element is consequently FE_RaviartThomas(0), i.e., the Raviart-Thomas element "of
degree zero", even though the functions of this space are in general polynomials of degree one in each variable. This choice of "degree" implies that the approximation order of the function itself is degree+1, as with usual polynomial spaces. The numbering so chosen implies the sequence
-
+\]" src="form_1119.png"/>
This class is not implemented for the codimension one case (spacedim != dim).
Interpolation
@@ -797,11 +797,11 @@
-
Given the values of a function at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., , where are the node functionals of the element (see also Node values or node functionals). The values are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function , i.e., is the finite element interpolant of with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.
-
In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are and that the node functionals associated with the current element are . Then, the fact that the element is based on generalized support points, implies that if we apply to a (possibly vector-valued) finite element function , the result must have the form – in other words, the value of the node functional applied to only depends on the values of at and not on values anywhere else, or integrals of , or any other kind of information.
-
The exact form of depends on the element. For example, for scalar Lagrange elements, we have that in fact . If you combine multiple scalar Lagrange elements via an FESystem object, then where is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that where is the normal vector of the face at which the shape function is defined.
-
Given all of this, what this function does is the following: If you input a list of values of a function at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in then you will get out a vector where equals dofs_per_cell.
+
Given the values of a function at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., , where are the node functionals of the element (see also Node values or node functionals). The values are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function , i.e., is the finite element interpolant of with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.
+
In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are and that the node functionals associated with the current element are . Then, the fact that the element is based on generalized support points, implies that if we apply to a (possibly vector-valued) finite element function , the result must have the form – in other words, the value of the node functional applied to only depends on the values of at and not on values anywhere else, or integrals of , or any other kind of information.
+
The exact form of depends on the element. For example, for scalar Lagrange elements, we have that in fact . If you combine multiple scalar Lagrange elements via an FESystem object, then where is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that where is the normal vector of the face at which the shape function is defined.
+
Given all of this, what this function does is the following: If you input a list of values of a function at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in then you will get out a vector where equals dofs_per_cell.
Parameters
[in]
support_point_values
An array of size dofs_per_cell (which equals the number of points the get_generalized_support_points() function will return) where each element is a vector with as many entries as the element has vector components. This array should contain the values of a function at the generalized support points of the current element.
@@ -991,7 +991,7 @@
Fill the necessary tables defined in base classes such as adjust_quad_dof_index_for_face_orientation_table declared in fe.cc. We need to fill it with the correct values in case of non-standard, flipped (rotated by +180 degrees) or rotated (rotated by +90 degrees) faces. These are given in the form three flags (face_orientation, face_flip, face_rotation), see the documentation in GeometryInfo<dim> and this glossary entry on face orientation.
Example: Raviart-Thomas Elements of order 2 (tensor polynomial degree 3)
-
The dofs on a face are connected to a matrix where here n=3. In our example we can imagine the following dofs on a quad (face):
+
The dofs on a face are connected to a matrix where here n=3. In our example we can imagine the following dofs on a quad (face):
The index of this degree of freedom within the set of degrees of freedom on the entire cell. The returned value will be between zero and dofs_per_cell.
-
Note
This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a , then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
+
Note
This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a , then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
Return a block mask with as many elements as this object has blocks and of which exactly the one component is true that corresponds to the given argument. See the glossary for more information.
-
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
scalar
An object that represents a single scalar vector component of this finite element.
@@ -3952,7 +3952,7 @@
Given a component mask (see this glossary entry), produce a block mask (see this glossary entry) that represents the blocks that correspond to the components selected in the input argument. This is essentially a conversion operator from ComponentMask to BlockMask.
-
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
component_mask
The mask that selects individual components of the finite element
@@ -4181,7 +4181,7 @@
Return a vector of generalized support points.
-
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
+
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
For a given degree of freedom, return whether it is logically associated with a vertex, line, quad or hex.
-
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
-
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
-
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
+
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
+
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
+
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
Parameters
[in]
cell_dof_index
The index of a shape function or degree of freedom. This index must be in the range [0,dofs_per_cell).
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__RaviartThomasNodal.html differs (JavaScript source, ASCII text, with very long lines (752))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__RaviartThomasNodal.html 2023-11-25 15:25:54.903324912 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__RaviartThomasNodal.html 2023-11-25 15:25:54.903324912 +0100
@@ -487,8 +487,8 @@
class FE_RaviartThomasNodal< dim >
The Raviart-Thomas elements with node functionals defined as point values in Gauss-Lobatto points.
Description of node values
For this Raviart-Thomas element, the node values are not cell and face moments with respect to certain polynomials, but the values at quadrature points. Following the general scheme for numbering degrees of freedom, the node values on faces (edges in 2d, quads in 3d) are first, face by face, according to the natural ordering of the faces of a cell. The interior degrees of freedom are last.
-
For an RT-element of degree k, we choose (k+1)d-1 Gauss-Lobatto points on each face, as defined by QGaussLobatto. For degree , the midpoint is chosen. These points are ordered lexicographically with respect to the orientation of the face. This way, the normal component which is in Qk, is uniquely determined.
-
These face polynomials are extended into the interior by the means of a QGaussLobatto formula for the normal direction. In other words, the polynomials are the tensor product of Lagrange polynomials on the points of a QGaussLobatto formula with points in the normal direction with Lagrange polynomials on the points of a QGaussLobatto quadrature formula with points.
+
For an RT-element of degree k, we choose (k+1)d-1 Gauss-Lobatto points on each face, as defined by QGaussLobatto. For degree , the midpoint is chosen. These points are ordered lexicographically with respect to the orientation of the face. This way, the normal component which is in Qk, is uniquely determined.
+
These face polynomials are extended into the interior by the means of a QGaussLobatto formula for the normal direction. In other words, the polynomials are the tensor product of Lagrange polynomials on the points of a QGaussLobatto formula with points in the normal direction with Lagrange polynomials on the points of a QGaussLobatto quadrature formula with points.
Given the values of a function at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., , where are the node functionals of the element (see also Node values or node functionals). The values are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function , i.e., is the finite element interpolant of with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.
-
In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are and that the node functionals associated with the current element are . Then, the fact that the element is based on generalized support points, implies that if we apply to a (possibly vector-valued) finite element function , the result must have the form – in other words, the value of the node functional applied to only depends on the values of at and not on values anywhere else, or integrals of , or any other kind of information.
-
The exact form of depends on the element. For example, for scalar Lagrange elements, we have that in fact . If you combine multiple scalar Lagrange elements via an FESystem object, then where is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that where is the normal vector of the face at which the shape function is defined.
-
Given all of this, what this function does is the following: If you input a list of values of a function at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in then you will get out a vector where equals dofs_per_cell.
+
Given the values of a function at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., , where are the node functionals of the element (see also Node values or node functionals). The values are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function , i.e., is the finite element interpolant of with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.
+
In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are and that the node functionals associated with the current element are . Then, the fact that the element is based on generalized support points, implies that if we apply to a (possibly vector-valued) finite element function , the result must have the form – in other words, the value of the node functional applied to only depends on the values of at and not on values anywhere else, or integrals of , or any other kind of information.
+
The exact form of depends on the element. For example, for scalar Lagrange elements, we have that in fact . If you combine multiple scalar Lagrange elements via an FESystem object, then where is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that where is the normal vector of the face at which the shape function is defined.
+
Given all of this, what this function does is the following: If you input a list of values of a function at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in then you will get out a vector where equals dofs_per_cell.
Parameters
[in]
support_point_values
An array of size dofs_per_cell (which equals the number of points the get_generalized_support_points() function will return) where each element is a vector with as many entries as the element has vector components. This array should contain the values of a function at the generalized support points of the current element.
@@ -3186,7 +3186,7 @@
Returns
The index of this degree of freedom within the set of degrees of freedom on the entire cell. The returned value will be between zero and dofs_per_cell.
-
Note
This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a , then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
+
Note
This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a , then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
Return a block mask with as many elements as this object has blocks and of which exactly the one component is true that corresponds to the given argument. See the glossary for more information.
-
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
scalar
An object that represents a single scalar vector component of this finite element.
@@ -4015,7 +4015,7 @@
Given a component mask (see this glossary entry), produce a block mask (see this glossary entry) that represents the blocks that correspond to the components selected in the input argument. This is essentially a conversion operator from ComponentMask to BlockMask.
-
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
component_mask
The mask that selects individual components of the finite element
@@ -4275,7 +4275,7 @@
Return a vector of generalized support points.
-
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
+
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
For a given degree of freedom, return whether it is logically associated with a vertex, line, quad or hex.
-
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
-
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
-
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
+
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
+
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
+
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
Parameters
[in]
cell_dof_index
The index of a shape function or degree of freedom. This index must be in the range [0,dofs_per_cell).
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__SimplexDGP.html differs (JavaScript source, ASCII text, with very long lines (752))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__SimplexDGP.html 2023-11-25 15:25:54.956657162 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__SimplexDGP.html 2023-11-25 15:25:54.956657162 +0100
@@ -465,7 +465,7 @@
Implementation of a scalar discontinuous Lagrange finite element , sometimes denoted as , that yields the finite element space of discontinuous, piecewise polynomials of degree .
+class FE_SimplexDGP< dim, spacedim >
Implementation of a scalar discontinuous Lagrange finite element , sometimes denoted as , that yields the finite element space of discontinuous, piecewise polynomials of degree .
Given the values of a function at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., , where are the node functionals of the element (see also Node values or node functionals). The values are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function , i.e., is the finite element interpolant of with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.
-
In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are and that the node functionals associated with the current element are . Then, the fact that the element is based on generalized support points, implies that if we apply to a (possibly vector-valued) finite element function , the result must have the form – in other words, the value of the node functional applied to only depends on the values of at and not on values anywhere else, or integrals of , or any other kind of information.
-
The exact form of depends on the element. For example, for scalar Lagrange elements, we have that in fact . If you combine multiple scalar Lagrange elements via an FESystem object, then where is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that where is the normal vector of the face at which the shape function is defined.
-
Given all of this, what this function does is the following: If you input a list of values of a function at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in then you will get out a vector where equals dofs_per_cell.
+
Given the values of a function at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., , where are the node functionals of the element (see also Node values or node functionals). The values are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function , i.e., is the finite element interpolant of with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.
+
In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are and that the node functionals associated with the current element are . Then, the fact that the element is based on generalized support points, implies that if we apply to a (possibly vector-valued) finite element function , the result must have the form – in other words, the value of the node functional applied to only depends on the values of at and not on values anywhere else, or integrals of , or any other kind of information.
+
The exact form of depends on the element. For example, for scalar Lagrange elements, we have that in fact . If you combine multiple scalar Lagrange elements via an FESystem object, then where is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that where is the normal vector of the face at which the shape function is defined.
+
Given all of this, what this function does is the following: If you input a list of values of a function at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in then you will get out a vector where equals dofs_per_cell.
Parameters
[in]
support_point_values
An array of size dofs_per_cell (which equals the number of points the get_generalized_support_points() function will return) where each element is a vector with as many entries as the element has vector components. This array should contain the values of a function at the generalized support points of the current element.
@@ -2300,17 +2300,17 @@
Correct the shape Hessians by subtracting the terms corresponding to the Jacobian pushed forward gradient.
Before the correction, the Hessians would be given by
-
+\]" src="form_1140.png"/>
-
where . After the correction, the correct Hessians would be given by
-. After the correction, the correct Hessians would be given by
+
+\]" src="form_1142.png"/>
-
where is the Jacobian pushed-forward derivative.
+
where is the Jacobian pushed-forward derivative.
@@ -2354,21 +2354,21 @@
Correct the shape third derivatives by subtracting the terms corresponding to the Jacobian pushed forward gradient and second derivative.
Before the correction, the third derivatives would be given by
-
+\]" src="form_1144.png"/>
-
where . After the correction, the correct third derivative would be given by
-. After the correction, the correct third derivative would be given by
+
+\]" src="form_1145.png"/>
-
where is the Jacobian pushed-forward derivative and is the Jacobian pushed-forward second derivative.
+
where is the Jacobian pushed-forward derivative and is the Jacobian pushed-forward second derivative.
@@ -3040,7 +3040,7 @@
Returns
The index of this degree of freedom within the set of degrees of freedom on the entire cell. The returned value will be between zero and dofs_per_cell.
-
Note
This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a , then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
+
Note
This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a , then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
Return a block mask with as many elements as this object has blocks and of which exactly the one component is true that corresponds to the given argument. See the glossary for more information.
-
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
scalar
An object that represents a single scalar vector component of this finite element.
@@ -3869,7 +3869,7 @@
Given a component mask (see this glossary entry), produce a block mask (see this glossary entry) that represents the blocks that correspond to the components selected in the input argument. This is essentially a conversion operator from ComponentMask to BlockMask.
-
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
component_mask
The mask that selects individual components of the finite element
@@ -4098,7 +4098,7 @@
Return a vector of generalized support points.
-
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
+
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
For a given degree of freedom, return whether it is logically associated with a vertex, line, quad or hex.
-
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
-
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
-
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
+
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
+
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
+
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
Parameters
[in]
cell_dof_index
The index of a shape function or degree of freedom. This index must be in the range [0,dofs_per_cell).
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__SimplexP.html differs (JavaScript source, ASCII text, with very long lines (752))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__SimplexP.html 2023-11-25 15:25:55.009989408 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__SimplexP.html 2023-11-25 15:25:55.009989408 +0100
@@ -465,7 +465,7 @@
Given the values of a function at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., , where are the node functionals of the element (see also Node values or node functionals). The values are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function , i.e., is the finite element interpolant of with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.
-
In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are and that the node functionals associated with the current element are . Then, the fact that the element is based on generalized support points, implies that if we apply to a (possibly vector-valued) finite element function , the result must have the form – in other words, the value of the node functional applied to only depends on the values of at and not on values anywhere else, or integrals of , or any other kind of information.
-
The exact form of depends on the element. For example, for scalar Lagrange elements, we have that in fact . If you combine multiple scalar Lagrange elements via an FESystem object, then where is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that where is the normal vector of the face at which the shape function is defined.
-
Given all of this, what this function does is the following: If you input a list of values of a function at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in then you will get out a vector where equals dofs_per_cell.
+
Given the values of a function at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., , where are the node functionals of the element (see also Node values or node functionals). The values are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function , i.e., is the finite element interpolant of with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.
+
In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are and that the node functionals associated with the current element are . Then, the fact that the element is based on generalized support points, implies that if we apply to a (possibly vector-valued) finite element function , the result must have the form – in other words, the value of the node functional applied to only depends on the values of at and not on values anywhere else, or integrals of , or any other kind of information.
+
The exact form of depends on the element. For example, for scalar Lagrange elements, we have that in fact . If you combine multiple scalar Lagrange elements via an FESystem object, then where is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that where is the normal vector of the face at which the shape function is defined.
+
Given all of this, what this function does is the following: If you input a list of values of a function at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in then you will get out a vector where equals dofs_per_cell.
Parameters
[in]
support_point_values
An array of size dofs_per_cell (which equals the number of points the get_generalized_support_points() function will return) where each element is a vector with as many entries as the element has vector components. This array should contain the values of a function at the generalized support points of the current element.
@@ -2300,17 +2300,17 @@
Correct the shape Hessians by subtracting the terms corresponding to the Jacobian pushed forward gradient.
Before the correction, the Hessians would be given by
-
+\]" src="form_1140.png"/>
-
where . After the correction, the correct Hessians would be given by
-. After the correction, the correct Hessians would be given by
+
+\]" src="form_1142.png"/>
-
where is the Jacobian pushed-forward derivative.
+
where is the Jacobian pushed-forward derivative.
@@ -2354,21 +2354,21 @@
Correct the shape third derivatives by subtracting the terms corresponding to the Jacobian pushed forward gradient and second derivative.
Before the correction, the third derivatives would be given by
-
+\]" src="form_1144.png"/>
-
where . After the correction, the correct third derivative would be given by
-. After the correction, the correct third derivative would be given by
+
+\]" src="form_1145.png"/>
-
where is the Jacobian pushed-forward derivative and is the Jacobian pushed-forward second derivative.
+
where is the Jacobian pushed-forward derivative and is the Jacobian pushed-forward second derivative.
@@ -3040,7 +3040,7 @@
Returns
The index of this degree of freedom within the set of degrees of freedom on the entire cell. The returned value will be between zero and dofs_per_cell.
-
Note
This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a , then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
+
Note
This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a , then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
Return a block mask with as many elements as this object has blocks and of which exactly the one component is true that corresponds to the given argument. See the glossary for more information.
-
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
scalar
An object that represents a single scalar vector component of this finite element.
@@ -3869,7 +3869,7 @@
Given a component mask (see this glossary entry), produce a block mask (see this glossary entry) that represents the blocks that correspond to the components selected in the input argument. This is essentially a conversion operator from ComponentMask to BlockMask.
-
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
component_mask
The mask that selects individual components of the finite element
@@ -4098,7 +4098,7 @@
Return a vector of generalized support points.
-
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
+
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
For a given degree of freedom, return whether it is logically associated with a vertex, line, quad or hex.
-
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
-
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
-
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
+
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
+
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
+
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
Parameters
[in]
cell_dof_index
The index of a shape function or degree of freedom. This index must be in the range [0,dofs_per_cell).
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__SimplexP__Bubbles.html differs (JavaScript source, ASCII text, with very long lines (752))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__SimplexP__Bubbles.html 2023-11-25 15:25:55.066654923 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__SimplexP__Bubbles.html 2023-11-25 15:25:55.066654923 +0100
@@ -950,11 +950,11 @@
-
Given the values of a function at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., , where are the node functionals of the element (see also Node values or node functionals). The values are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function , i.e., is the finite element interpolant of with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.
-
In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are and that the node functionals associated with the current element are . Then, the fact that the element is based on generalized support points, implies that if we apply to a (possibly vector-valued) finite element function , the result must have the form – in other words, the value of the node functional applied to only depends on the values of at and not on values anywhere else, or integrals of , or any other kind of information.
-
The exact form of depends on the element. For example, for scalar Lagrange elements, we have that in fact . If you combine multiple scalar Lagrange elements via an FESystem object, then where is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that where is the normal vector of the face at which the shape function is defined.
-
Given all of this, what this function does is the following: If you input a list of values of a function at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in then you will get out a vector where equals dofs_per_cell.
+
Given the values of a function at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., , where are the node functionals of the element (see also Node values or node functionals). The values are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function , i.e., is the finite element interpolant of with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.
+
In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are and that the node functionals associated with the current element are . Then, the fact that the element is based on generalized support points, implies that if we apply to a (possibly vector-valued) finite element function , the result must have the form – in other words, the value of the node functional applied to only depends on the values of at and not on values anywhere else, or integrals of , or any other kind of information.
+
The exact form of depends on the element. For example, for scalar Lagrange elements, we have that in fact . If you combine multiple scalar Lagrange elements via an FESystem object, then where is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that where is the normal vector of the face at which the shape function is defined.
+
Given all of this, what this function does is the following: If you input a list of values of a function at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in then you will get out a vector where equals dofs_per_cell.
Parameters
[in]
support_point_values
An array of size dofs_per_cell (which equals the number of points the get_generalized_support_points() function will return) where each element is a vector with as many entries as the element has vector components. This array should contain the values of a function at the generalized support points of the current element.
@@ -2198,17 +2198,17 @@
Correct the shape Hessians by subtracting the terms corresponding to the Jacobian pushed forward gradient.
Before the correction, the Hessians would be given by
-
+\]" src="form_1140.png"/>
-
where . After the correction, the correct Hessians would be given by
-. After the correction, the correct Hessians would be given by
+
+\]" src="form_1142.png"/>
-
where is the Jacobian pushed-forward derivative.
+
where is the Jacobian pushed-forward derivative.
@@ -2252,21 +2252,21 @@
Correct the shape third derivatives by subtracting the terms corresponding to the Jacobian pushed forward gradient and second derivative.
Before the correction, the third derivatives would be given by
-
+\]" src="form_1144.png"/>
-
where . After the correction, the correct third derivative would be given by
-. After the correction, the correct third derivative would be given by
+
+\]" src="form_1145.png"/>
-
where is the Jacobian pushed-forward derivative and is the Jacobian pushed-forward second derivative.
+
where is the Jacobian pushed-forward derivative and is the Jacobian pushed-forward second derivative.
@@ -3038,7 +3038,7 @@
Returns
The index of this degree of freedom within the set of degrees of freedom on the entire cell. The returned value will be between zero and dofs_per_cell.
-
Note
This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a , then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
+
Note
This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a , then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
Return a block mask with as many elements as this object has blocks and of which exactly the one component is true that corresponds to the given argument. See the glossary for more information.
-
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
scalar
An object that represents a single scalar vector component of this finite element.
@@ -3867,7 +3867,7 @@
Given a component mask (see this glossary entry), produce a block mask (see this glossary entry) that represents the blocks that correspond to the components selected in the input argument. This is essentially a conversion operator from ComponentMask to BlockMask.
-
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
component_mask
The mask that selects individual components of the finite element
@@ -4096,7 +4096,7 @@
Return a vector of generalized support points.
-
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
+
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
For a given degree of freedom, return whether it is logically associated with a vertex, line, quad or hex.
-
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
-
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
-
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
+
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
+
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
+
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
Parameters
[in]
cell_dof_index
The index of a shape function or degree of freedom. This index must be in the range [0,dofs_per_cell).
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__SimplexPoly.html differs (JavaScript source, ASCII text, with very long lines (1003))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__SimplexPoly.html 2023-11-25 15:25:55.119987172 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__SimplexPoly.html 2023-11-25 15:25:55.123320437 +0100
@@ -904,11 +904,11 @@
-
Given the values of a function at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., , where are the node functionals of the element (see also Node values or node functionals). The values are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function , i.e., is the finite element interpolant of with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.
-
In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are and that the node functionals associated with the current element are . Then, the fact that the element is based on generalized support points, implies that if we apply to a (possibly vector-valued) finite element function , the result must have the form – in other words, the value of the node functional applied to only depends on the values of at and not on values anywhere else, or integrals of , or any other kind of information.
-
The exact form of depends on the element. For example, for scalar Lagrange elements, we have that in fact . If you combine multiple scalar Lagrange elements via an FESystem object, then where is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that where is the normal vector of the face at which the shape function is defined.
-
Given all of this, what this function does is the following: If you input a list of values of a function at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in then you will get out a vector where equals dofs_per_cell.
+
Given the values of a function at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., , where are the node functionals of the element (see also Node values or node functionals). The values are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function , i.e., is the finite element interpolant of with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.
+
In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are and that the node functionals associated with the current element are . Then, the fact that the element is based on generalized support points, implies that if we apply to a (possibly vector-valued) finite element function , the result must have the form – in other words, the value of the node functional applied to only depends on the values of at and not on values anywhere else, or integrals of , or any other kind of information.
+
The exact form of depends on the element. For example, for scalar Lagrange elements, we have that in fact . If you combine multiple scalar Lagrange elements via an FESystem object, then where is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that where is the normal vector of the face at which the shape function is defined.
+
Given all of this, what this function does is the following: If you input a list of values of a function at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in then you will get out a vector where equals dofs_per_cell.
Parameters
[in]
support_point_values
An array of size dofs_per_cell (which equals the number of points the get_generalized_support_points() function will return) where each element is a vector with as many entries as the element has vector components. This array should contain the values of a function at the generalized support points of the current element.
@@ -2152,17 +2152,17 @@
Correct the shape Hessians by subtracting the terms corresponding to the Jacobian pushed forward gradient.
Before the correction, the Hessians would be given by
-
+\]" src="form_1140.png"/>
-
where . After the correction, the correct Hessians would be given by
-. After the correction, the correct Hessians would be given by
+
+\]" src="form_1142.png"/>
-
where is the Jacobian pushed-forward derivative.
+
where is the Jacobian pushed-forward derivative.
@@ -2206,21 +2206,21 @@
Correct the shape third derivatives by subtracting the terms corresponding to the Jacobian pushed forward gradient and second derivative.
Before the correction, the third derivatives would be given by
-
+\]" src="form_1144.png"/>
-
where . After the correction, the correct third derivative would be given by
-. After the correction, the correct third derivative would be given by
+
+\]" src="form_1145.png"/>
-
where is the Jacobian pushed-forward derivative and is the Jacobian pushed-forward second derivative.
+
where is the Jacobian pushed-forward derivative and is the Jacobian pushed-forward second derivative.
@@ -3054,7 +3054,7 @@
Returns
The index of this degree of freedom within the set of degrees of freedom on the entire cell. The returned value will be between zero and dofs_per_cell.
-
Note
This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a , then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
+
Note
This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a , then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
Return a block mask with as many elements as this object has blocks and of which exactly the one component is true that corresponds to the given argument. See the glossary for more information.
-
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
scalar
An object that represents a single scalar vector component of this finite element.
@@ -3883,7 +3883,7 @@
Given a component mask (see this glossary entry), produce a block mask (see this glossary entry) that represents the blocks that correspond to the components selected in the input argument. This is essentially a conversion operator from ComponentMask to BlockMask.
-
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
component_mask
The mask that selects individual components of the finite element
@@ -4112,7 +4112,7 @@
Return a vector of generalized support points.
-
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
+
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
For a given degree of freedom, return whether it is logically associated with a vertex, line, quad or hex.
-
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
-
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
-
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
+
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
+
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
+
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
Parameters
[in]
cell_dof_index
The index of a shape function or degree of freedom. This index must be in the range [0,dofs_per_cell).
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__TraceQ.html differs (JavaScript source, ASCII text, with very long lines (752))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__TraceQ.html 2023-11-25 15:25:55.176652683 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__TraceQ.html 2023-11-25 15:25:55.176652683 +0100
@@ -2980,7 +2980,7 @@
Returns
The index of this degree of freedom within the set of degrees of freedom on the entire cell. The returned value will be between zero and dofs_per_cell.
-
Note
This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a , then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
+
Note
This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a , then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
Return a block mask with as many elements as this object has blocks and of which exactly the one component is true that corresponds to the given argument. See the glossary for more information.
-
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
scalar
An object that represents a single scalar vector component of this finite element.
@@ -3809,7 +3809,7 @@
Given a component mask (see this glossary entry), produce a block mask (see this glossary entry) that represents the blocks that correspond to the components selected in the input argument. This is essentially a conversion operator from ComponentMask to BlockMask.
-
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
component_mask
The mask that selects individual components of the finite element
@@ -4038,7 +4038,7 @@
Return a vector of generalized support points.
-
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
+
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
For a given degree of freedom, return whether it is logically associated with a vertex, line, quad or hex.
-
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
-
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
-
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
+
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
+
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
+
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
Parameters
[in]
cell_dof_index
The index of a shape function or degree of freedom. This index must be in the range [0,dofs_per_cell).
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__TraceQ_3_011_00_01spacedim_01_4.html differs (JavaScript source, ASCII text, with very long lines (752))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__TraceQ_3_011_00_01spacedim_01_4.html 2023-11-25 15:25:55.226651668 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__TraceQ_3_011_00_01spacedim_01_4.html 2023-11-25 15:25:55.226651668 +0100
@@ -3140,7 +3140,7 @@
Returns
The index of this degree of freedom within the set of degrees of freedom on the entire cell. The returned value will be between zero and dofs_per_cell.
-
Note
This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a , then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
+
Note
This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a , then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
@@ -3811,7 +3811,7 @@
Return a block mask with as many elements as this object has blocks and of which exactly the one component is true that corresponds to the given argument. See the glossary for more information.
-
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
scalar
An object that represents a single scalar vector component of this finite element.
@@ -3913,7 +3913,7 @@
Given a component mask (see this glossary entry), produce a block mask (see this glossary entry) that represents the blocks that correspond to the components selected in the input argument. This is essentially a conversion operator from ComponentMask to BlockMask.
-
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
component_mask
The mask that selects individual components of the finite element
@@ -4124,7 +4124,7 @@
Return a vector of generalized support points.
-
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
+
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
For a given degree of freedom, return whether it is logically associated with a vertex, line, quad or hex.
-
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
-
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
-
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
+
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
+
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
+
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
Parameters
[in]
cell_dof_index
The index of a shape function or degree of freedom. This index must be in the range [0,dofs_per_cell).
@@ -4224,11 +4224,11 @@
-
Given the values of a function at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., , where are the node functionals of the element (see also Node values or node functionals). The values are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function , i.e., is the finite element interpolant of with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.
-
In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are and that the node functionals associated with the current element are . Then, the fact that the element is based on generalized support points, implies that if we apply to a (possibly vector-valued) finite element function , the result must have the form – in other words, the value of the node functional applied to only depends on the values of at and not on values anywhere else, or integrals of , or any other kind of information.
-
The exact form of depends on the element. For example, for scalar Lagrange elements, we have that in fact . If you combine multiple scalar Lagrange elements via an FESystem object, then where is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that where is the normal vector of the face at which the shape function is defined.
-
Given all of this, what this function does is the following: If you input a list of values of a function at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in then you will get out a vector where equals dofs_per_cell.
+
Given the values of a function at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., , where are the node functionals of the element (see also Node values or node functionals). The values are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function , i.e., is the finite element interpolant of with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.
+
In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are and that the node functionals associated with the current element are . Then, the fact that the element is based on generalized support points, implies that if we apply to a (possibly vector-valued) finite element function , the result must have the form – in other words, the value of the node functional applied to only depends on the values of at and not on values anywhere else, or integrals of , or any other kind of information.
+
The exact form of depends on the element. For example, for scalar Lagrange elements, we have that in fact . If you combine multiple scalar Lagrange elements via an FESystem object, then where is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that where is the normal vector of the face at which the shape function is defined.
+
Given all of this, what this function does is the following: If you input a list of values of a function at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in then you will get out a vector where equals dofs_per_cell.
Parameters
[in]
support_point_values
An array of size dofs_per_cell (which equals the number of points the get_generalized_support_points() function will return) where each element is a vector with as many entries as the element has vector components. This array should contain the values of a function at the generalized support points of the current element.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__WedgeDGP.html differs (JavaScript source, ASCII text, with very long lines (752))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__WedgeDGP.html 2023-11-25 15:25:55.283317179 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__WedgeDGP.html 2023-11-25 15:25:55.283317179 +0100
@@ -469,7 +469,7 @@
Given the values of a function at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., , where are the node functionals of the element (see also Node values or node functionals). The values are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function , i.e., is the finite element interpolant of with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.
-
In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are and that the node functionals associated with the current element are . Then, the fact that the element is based on generalized support points, implies that if we apply to a (possibly vector-valued) finite element function , the result must have the form – in other words, the value of the node functional applied to only depends on the values of at and not on values anywhere else, or integrals of , or any other kind of information.
-
The exact form of depends on the element. For example, for scalar Lagrange elements, we have that in fact . If you combine multiple scalar Lagrange elements via an FESystem object, then where is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that where is the normal vector of the face at which the shape function is defined.
-
Given all of this, what this function does is the following: If you input a list of values of a function at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in then you will get out a vector where equals dofs_per_cell.
+
Given the values of a function at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., , where are the node functionals of the element (see also Node values or node functionals). The values are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function , i.e., is the finite element interpolant of with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.
+
In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are and that the node functionals associated with the current element are . Then, the fact that the element is based on generalized support points, implies that if we apply to a (possibly vector-valued) finite element function , the result must have the form – in other words, the value of the node functional applied to only depends on the values of at and not on values anywhere else, or integrals of , or any other kind of information.
+
The exact form of depends on the element. For example, for scalar Lagrange elements, we have that in fact . If you combine multiple scalar Lagrange elements via an FESystem object, then where is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that where is the normal vector of the face at which the shape function is defined.
+
Given all of this, what this function does is the following: If you input a list of values of a function at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in then you will get out a vector where equals dofs_per_cell.
Parameters
[in]
support_point_values
An array of size dofs_per_cell (which equals the number of points the get_generalized_support_points() function will return) where each element is a vector with as many entries as the element has vector components. This array should contain the values of a function at the generalized support points of the current element.
@@ -1951,17 +1951,17 @@
Correct the shape Hessians by subtracting the terms corresponding to the Jacobian pushed forward gradient.
Before the correction, the Hessians would be given by
-
+\]" src="form_1140.png"/>
-
where . After the correction, the correct Hessians would be given by
-. After the correction, the correct Hessians would be given by
+
+\]" src="form_1142.png"/>
-
where is the Jacobian pushed-forward derivative.
+
where is the Jacobian pushed-forward derivative.
@@ -2005,21 +2005,21 @@
Correct the shape third derivatives by subtracting the terms corresponding to the Jacobian pushed forward gradient and second derivative.
Before the correction, the third derivatives would be given by
-
+\]" src="form_1144.png"/>
-
where . After the correction, the correct third derivative would be given by
-. After the correction, the correct third derivative would be given by
+
+\]" src="form_1145.png"/>
-
where is the Jacobian pushed-forward derivative and is the Jacobian pushed-forward second derivative.
+
where is the Jacobian pushed-forward derivative and is the Jacobian pushed-forward second derivative.
@@ -2985,7 +2985,7 @@
Returns
The index of this degree of freedom within the set of degrees of freedom on the entire cell. The returned value will be between zero and dofs_per_cell.
-
Note
This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a , then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
+
Note
This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a , then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
Return a block mask with as many elements as this object has blocks and of which exactly the one component is true that corresponds to the given argument. See the glossary for more information.
-
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
scalar
An object that represents a single scalar vector component of this finite element.
@@ -3814,7 +3814,7 @@
Given a component mask (see this glossary entry), produce a block mask (see this glossary entry) that represents the blocks that correspond to the components selected in the input argument. This is essentially a conversion operator from ComponentMask to BlockMask.
-
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
component_mask
The mask that selects individual components of the finite element
@@ -4074,7 +4074,7 @@
Return a vector of generalized support points.
-
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
+
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
For a given degree of freedom, return whether it is logically associated with a vertex, line, quad or hex.
-
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
-
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
-
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
+
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
+
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
+
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
Parameters
[in]
cell_dof_index
The index of a shape function or degree of freedom. This index must be in the range [0,dofs_per_cell).
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__WedgeP.html differs (JavaScript source, ASCII text, with very long lines (752))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__WedgeP.html 2023-11-25 15:25:55.336649429 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__WedgeP.html 2023-11-25 15:25:55.339982693 +0100
@@ -469,7 +469,7 @@
Given the values of a function at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., , where are the node functionals of the element (see also Node values or node functionals). The values are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function , i.e., is the finite element interpolant of with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.
-
In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are and that the node functionals associated with the current element are . Then, the fact that the element is based on generalized support points, implies that if we apply to a (possibly vector-valued) finite element function , the result must have the form – in other words, the value of the node functional applied to only depends on the values of at and not on values anywhere else, or integrals of , or any other kind of information.
-
The exact form of depends on the element. For example, for scalar Lagrange elements, we have that in fact . If you combine multiple scalar Lagrange elements via an FESystem object, then where is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that where is the normal vector of the face at which the shape function is defined.
-
Given all of this, what this function does is the following: If you input a list of values of a function at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in then you will get out a vector where equals dofs_per_cell.
+
Given the values of a function at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., , where are the node functionals of the element (see also Node values or node functionals). The values are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function , i.e., is the finite element interpolant of with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.
+
In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are and that the node functionals associated with the current element are . Then, the fact that the element is based on generalized support points, implies that if we apply to a (possibly vector-valued) finite element function , the result must have the form – in other words, the value of the node functional applied to only depends on the values of at and not on values anywhere else, or integrals of , or any other kind of information.
+
The exact form of depends on the element. For example, for scalar Lagrange elements, we have that in fact . If you combine multiple scalar Lagrange elements via an FESystem object, then where is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that where is the normal vector of the face at which the shape function is defined.
+
Given all of this, what this function does is the following: If you input a list of values of a function at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in then you will get out a vector where equals dofs_per_cell.
Parameters
[in]
support_point_values
An array of size dofs_per_cell (which equals the number of points the get_generalized_support_points() function will return) where each element is a vector with as many entries as the element has vector components. This array should contain the values of a function at the generalized support points of the current element.
@@ -2106,17 +2106,17 @@
Correct the shape Hessians by subtracting the terms corresponding to the Jacobian pushed forward gradient.
Before the correction, the Hessians would be given by
-
+\]" src="form_1140.png"/>
-
where . After the correction, the correct Hessians would be given by
-. After the correction, the correct Hessians would be given by
+
+\]" src="form_1142.png"/>
-
where is the Jacobian pushed-forward derivative.
+
where is the Jacobian pushed-forward derivative.
@@ -2160,21 +2160,21 @@
Correct the shape third derivatives by subtracting the terms corresponding to the Jacobian pushed forward gradient and second derivative.
Before the correction, the third derivatives would be given by
-
+\]" src="form_1144.png"/>
-
where . After the correction, the correct third derivative would be given by
-. After the correction, the correct third derivative would be given by
+
+\]" src="form_1145.png"/>
-
where is the Jacobian pushed-forward derivative and is the Jacobian pushed-forward second derivative.
+
where is the Jacobian pushed-forward derivative and is the Jacobian pushed-forward second derivative.
@@ -3001,7 +3001,7 @@
Returns
The index of this degree of freedom within the set of degrees of freedom on the entire cell. The returned value will be between zero and dofs_per_cell.
-
Note
This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a , then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
+
Note
This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a , then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
Return a block mask with as many elements as this object has blocks and of which exactly the one component is true that corresponds to the given argument. See the glossary for more information.
-
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
scalar
An object that represents a single scalar vector component of this finite element.
@@ -3830,7 +3830,7 @@
Given a component mask (see this glossary entry), produce a block mask (see this glossary entry) that represents the blocks that correspond to the components selected in the input argument. This is essentially a conversion operator from ComponentMask to BlockMask.
-
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
component_mask
The mask that selects individual components of the finite element
@@ -4090,7 +4090,7 @@
Return a vector of generalized support points.
-
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
+
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
For a given degree of freedom, return whether it is logically associated with a vertex, line, quad or hex.
-
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
-
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
-
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
+
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
+
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
+
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
Parameters
[in]
cell_dof_index
The index of a shape function or degree of freedom. This index must be in the range [0,dofs_per_cell).
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__WedgePoly.html differs (JavaScript source, ASCII text, with very long lines (752))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__WedgePoly.html 2023-11-25 15:25:55.393314943 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFE__WedgePoly.html 2023-11-25 15:25:55.396648208 +0100
@@ -657,11 +657,11 @@
-
Given the values of a function at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., , where are the node functionals of the element (see also Node values or node functionals). The values are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function , i.e., is the finite element interpolant of with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.
-
In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are and that the node functionals associated with the current element are . Then, the fact that the element is based on generalized support points, implies that if we apply to a (possibly vector-valued) finite element function , the result must have the form – in other words, the value of the node functional applied to only depends on the values of at and not on values anywhere else, or integrals of , or any other kind of information.
-
The exact form of depends on the element. For example, for scalar Lagrange elements, we have that in fact . If you combine multiple scalar Lagrange elements via an FESystem object, then where is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that where is the normal vector of the face at which the shape function is defined.
-
Given all of this, what this function does is the following: If you input a list of values of a function at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in then you will get out a vector where equals dofs_per_cell.
+
Given the values of a function at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., , where are the node functionals of the element (see also Node values or node functionals). The values are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function , i.e., is the finite element interpolant of with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.
+
In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are and that the node functionals associated with the current element are . Then, the fact that the element is based on generalized support points, implies that if we apply to a (possibly vector-valued) finite element function , the result must have the form – in other words, the value of the node functional applied to only depends on the values of at and not on values anywhere else, or integrals of , or any other kind of information.
+
The exact form of depends on the element. For example, for scalar Lagrange elements, we have that in fact . If you combine multiple scalar Lagrange elements via an FESystem object, then where is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that where is the normal vector of the face at which the shape function is defined.
+
Given all of this, what this function does is the following: If you input a list of values of a function at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in then you will get out a vector where equals dofs_per_cell.
Parameters
[in]
support_point_values
An array of size dofs_per_cell (which equals the number of points the get_generalized_support_points() function will return) where each element is a vector with as many entries as the element has vector components. This array should contain the values of a function at the generalized support points of the current element.
@@ -1905,17 +1905,17 @@
Correct the shape Hessians by subtracting the terms corresponding to the Jacobian pushed forward gradient.
Before the correction, the Hessians would be given by
-
+\]" src="form_1140.png"/>
-
where . After the correction, the correct Hessians would be given by
-. After the correction, the correct Hessians would be given by
+
+\]" src="form_1142.png"/>
-
where is the Jacobian pushed-forward derivative.
+
where is the Jacobian pushed-forward derivative.
@@ -1959,21 +1959,21 @@
Correct the shape third derivatives by subtracting the terms corresponding to the Jacobian pushed forward gradient and second derivative.
Before the correction, the third derivatives would be given by
-
+\]" src="form_1144.png"/>
-
where . After the correction, the correct third derivative would be given by
-. After the correction, the correct third derivative would be given by
+
+\]" src="form_1145.png"/>
-
where is the Jacobian pushed-forward derivative and is the Jacobian pushed-forward second derivative.
+
where is the Jacobian pushed-forward derivative and is the Jacobian pushed-forward second derivative.
@@ -3001,7 +3001,7 @@
Returns
The index of this degree of freedom within the set of degrees of freedom on the entire cell. The returned value will be between zero and dofs_per_cell.
-
Note
This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a , then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
+
Note
This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a , then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
Return a block mask with as many elements as this object has blocks and of which exactly the one component is true that corresponds to the given argument. See the glossary for more information.
-
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
scalar
An object that represents a single scalar vector component of this finite element.
@@ -3830,7 +3830,7 @@
Given a component mask (see this glossary entry), produce a block mask (see this glossary entry) that represents the blocks that correspond to the components selected in the input argument. This is essentially a conversion operator from ComponentMask to BlockMask.
-
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
component_mask
The mask that selects individual components of the finite element
@@ -4090,7 +4090,7 @@
Return a vector of generalized support points.
-
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
+
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
For a given degree of freedom, return whether it is logically associated with a vertex, line, quad or hex.
-
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
-
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
-
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
+
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
+
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
+
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
Parameters
[in]
cell_dof_index
The index of a shape function or degree of freedom. This index must be in the range [0,dofs_per_cell).
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFiniteElement.html differs (JavaScript source, ASCII text, with very long lines (752))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFiniteElement.html 2023-11-25 15:25:55.453313721 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFiniteElement.html 2023-11-25 15:25:55.453313721 +0100
@@ -483,8 +483,8 @@
template<int dim, int spacedim = dim>
class FiniteElement< dim, spacedim >
This is the base class for finite elements in arbitrary dimensions. It declares the interface both in terms of member variables and public member functions through which properties of a concrete implementation of a finite element can be accessed. This interface generally consists of a number of groups of variables and functions that can roughly be delineated as follows:
Basic information about the finite element, such as the number of degrees of freedom per vertex, edge, or cell. This kind of data is stored in the FiniteElementData base class. (Though the FiniteElement::get_name() member function also falls into this category.)
-
A description of the shape functions and their derivatives on the reference cell , if an element is indeed defined by mapping shape functions from the reference cell to an actual cell.
-
Matrices (and functions that access them) that describe how an element's shape functions related to those on parent or child cells (restriction or prolongation) or neighboring cells (for hanging node constraints), as well as to other finite element spaces defined on the same cell (e.g., when doing refinement).
+
A description of the shape functions and their derivatives on the reference cell , if an element is indeed defined by mapping shape functions from the reference cell to an actual cell.
+
Matrices (and functions that access them) that describe how an element's shape functions related to those on parent or child cells (restriction or prolongation) or neighboring cells (for hanging node constraints), as well as to other finite element spaces defined on the same cell (e.g., when doing refinement).
For elements that are interpolatory, such as the common Lagrange elements, data that describes where their support points are located.
Functions that define the interface to the FEValues class that is almost always used to access finite element shape functions from user code.
@@ -493,7 +493,7 @@
As a general rule, there are three ways by which derived classes provide this information:
A number of fields that are generally easy to compute and that are initialized by the constructor of this class (or the constructor of the FiniteElementData base class) and derived classes therefore have to compute in the process of calling this class's constructor. This is, specifically, the case for the basic information and parts of the descriptive information about shape functions mentioned above.
Some common matrices that are widely used in the library and for which this class provides protected member variables that the constructors of derived classes need to fill. The purpose of providing these matrices in this class is that (i) they are frequently used, and (ii) they are expensive to compute. Consequently, it makes sense to only compute them once, rather than every time they are used. In most cases, the constructor of the current class already sets them to their correct size, and derived classes therefore only have to fill them. Examples of this include the matrices that relate the shape functions on one cell to the shape functions on neighbors, children, and parents.
-
Uncommon information, or information that depends on specific input arguments, and that needs to be implemented by derived classes. For these, this base class only declares abstract virtual member functions and derived classes then have to implement them. Examples of this category would include the functions that compute values and derivatives of shape functions on the reference cell for which it is not possible to tabulate values because there are infinitely many points at which one may want to evaluate them. In some cases, derived classes may choose to simply not implement all possible interfaces (or may not yet have a complete implementation); for uncommon functions, there is then often a member function derived classes can overload that describes whether a particular feature is implemented. An example is whether an element implements the information necessary to use it in the finite element context (see hp-finite element support).
+
Uncommon information, or information that depends on specific input arguments, and that needs to be implemented by derived classes. For these, this base class only declares abstract virtual member functions and derived classes then have to implement them. Examples of this category would include the functions that compute values and derivatives of shape functions on the reference cell for which it is not possible to tabulate values because there are infinitely many points at which one may want to evaluate them. In some cases, derived classes may choose to simply not implement all possible interfaces (or may not yet have a complete implementation); for uncommon functions, there is then often a member function derived classes can overload that describes whether a particular feature is implemented. An example is whether an element implements the information necessary to use it in the finite element context (see hp-finite element support).
Nomenclature
Finite element classes have to define a large number of different properties describing a finite element space. The following subsections describe some nomenclature that will be used in the documentation below.
@@ -568,8 +568,8 @@
21
1
0
8
1
-
What we see is the following: there are a total of 22 degrees-of-freedom on this element with components ranging from 0 to 2. Each DoF corresponds to one of the two base elements used to build FESystem : or . Since FE_Q are primitive elements, we have a total of 9 distinct scalar-valued shape functions for the quadratic element and 4 for the linear element. Finally, for DoFs corresponding to the first base element multiplicity is either zero or one, meaning that we use the same scalar valued for both and components of the velocity field . For DoFs corresponding to the second base element multiplicity is zero.
+
What we see is the following: there are a total of 22 degrees-of-freedom on this element with components ranging from 0 to 2. Each DoF corresponds to one of the two base elements used to build FESystem : or . Since FE_Q are primitive elements, we have a total of 9 distinct scalar-valued shape functions for the quadratic element and 4 for the linear element. Finally, for DoFs corresponding to the first base element multiplicity is either zero or one, meaning that we use the same scalar valued for both and components of the velocity field . For DoFs corresponding to the second base element multiplicity is zero.
Support points
Finite elements are frequently defined by defining a polynomial space and a set of dual functionals. If these functionals involve point evaluations, then the element is "interpolatory" and it is possible to interpolate an arbitrary (but sufficiently smooth) function onto the finite element space by evaluating it at these points. We call these points "support points".
Most finite elements are defined by mapping from the reference cell to a concrete cell. Consequently, the support points are then defined on the reference ("unit") cell, see this glossary entry. The support points on a concrete cell can then be computed by mapping the unit support points, using the Mapping class interface and derived classes, typically via the FEValues class.
@@ -595,14 +595,14 @@
Interpolation matrices in one dimension
In one space dimension (i.e., for dim==1 and any value of spacedim), finite element classes implementing the interface of the current base class need only set the restriction and prolongation matrices that describe the interpolation of the finite element space on one cell to that of its parent cell, and to that on its children, respectively. The constructor of the current class in one dimension presets the interface_constraints matrix (used to describe hanging node constraints at the interface between cells of different refinement levels) to have size zero because there are no hanging nodes in 1d.
Interpolation matrices in two dimensions
-
In addition to the fields discussed above for 1d, a constraint matrix is needed to describe hanging node constraints if the finite element has degrees of freedom located on edges or vertices. These constraints are represented by an -matrix interface_constraints, where m is the number of degrees of freedom on the refined side without the corner vertices (those dofs on the middle vertex plus those on the two lines), and n is that of the unrefined side (those dofs on the two vertices plus those on the line). The matrix is thus a rectangular one. The size of the interface_constraints matrix can also be accessed through the interface_constraints_size() function.
-
The mapping of the dofs onto the indices of the matrix on the unrefined side is as follows: let be the number of dofs on a vertex, that on a line, then refers to the dofs on vertex zero of the unrefined line, to those on vertex one, to those on the line.
-
Similarly, refers to the dofs on the middle vertex of the refined side (vertex one of child line zero, vertex zero of child line one), refers to the dofs on child line zero, refers to the dofs on child line one. Please note that we do not need to reserve space for the dofs on the end vertices of the refined lines, since these must be mapped one-to-one to the appropriate dofs of the vertices of the unrefined line.
+
In addition to the fields discussed above for 1d, a constraint matrix is needed to describe hanging node constraints if the finite element has degrees of freedom located on edges or vertices. These constraints are represented by an -matrix interface_constraints, where m is the number of degrees of freedom on the refined side without the corner vertices (those dofs on the middle vertex plus those on the two lines), and n is that of the unrefined side (those dofs on the two vertices plus those on the line). The matrix is thus a rectangular one. The size of the interface_constraints matrix can also be accessed through the interface_constraints_size() function.
+
The mapping of the dofs onto the indices of the matrix on the unrefined side is as follows: let be the number of dofs on a vertex, that on a line, then refers to the dofs on vertex zero of the unrefined line, to those on vertex one, to those on the line.
+
Similarly, refers to the dofs on the middle vertex of the refined side (vertex one of child line zero, vertex zero of child line one), refers to the dofs on child line zero, refers to the dofs on child line one. Please note that we do not need to reserve space for the dofs on the end vertices of the refined lines, since these must be mapped one-to-one to the appropriate dofs of the vertices of the unrefined line.
Through this construction, the degrees of freedom on the child faces are constrained to the degrees of freedom on the parent face. The information so provided is typically consumed by the DoFTools::make_hanging_node_constraints() function.
For the interface constraints, the 3d case is similar to the 2d case. The numbering for the indices on the mother face is obvious and keeps to the usual numbering of degrees of freedom on quadrilaterals.
-
The numbering of the degrees of freedom on the interior of the refined faces for the index is as follows: let and be as above, and be the number of degrees of freedom per quadrilateral (and therefore per face), then denote the dofs on the vertex at the center, for the dofs on the vertices at the center of the bounding lines of the quadrilateral, are for the degrees of freedom on the four lines connecting the center vertex to the outer boundary of the mother face, for the degrees of freedom on the small lines surrounding the quad, and for the dofs on the four child faces. Note the direction of the lines at the boundary of the quads, as shown below.
+
For the interface constraints, the 3d case is similar to the 2d case. The numbering for the indices on the mother face is obvious and keeps to the usual numbering of degrees of freedom on quadrilaterals.
+
The numbering of the degrees of freedom on the interior of the refined faces for the index is as follows: let and be as above, and be the number of degrees of freedom per quadrilateral (and therefore per face), then denote the dofs on the vertex at the center, for the dofs on the vertices at the center of the bounding lines of the quadrilateral, are for the degrees of freedom on the four lines connecting the center vertex to the outer boundary of the mother face, for the degrees of freedom on the small lines surrounding the quad, and for the dofs on the four child faces. Note the direction of the lines at the boundary of the quads, as shown below.
The order of the twelve lines and the four child faces can be extracted from the following sketch, where the overall order of the different dof groups is depicted:
As in this example, prolongation is almost always implemented via embedding, i.e., the nodal values of the function on the children may be different from the nodal values of the function on the parent cell, but as a function of , the finite element field on the child is the same as on the parent.
+
As in this example, prolongation is almost always implemented via embedding, i.e., the nodal values of the function on the children may be different from the nodal values of the function on the parent cell, but as a function of , the finite element field on the child is the same as on the parent.
Computing restriction matrices
The opposite operation, restricting a finite element function defined on the children to the parent cell is typically implemented by interpolating the finite element function on the children to the nodal values of the parent cell. In deal.II, the restriction operation is implemented as a loop over the children of a cell that each apply a matrix to the vector of unknowns on that child cell (these matrices are stored in restriction and are accessed by get_restriction_matrix()). The operation that then needs to be implemented turns out to be surprisingly difficult to describe, but is instructive to describe because it also defines the meaning of the restriction_is_additive_flags array (accessed via the restriction_is_additive() function).
-
To give a concrete example, assume we use a element in 1d, and that on each of the parent and child cells degrees of freedom are (locally and globally) numbered as follows:
meshes: *-------* *---*---*
+
To give a concrete example, assume we use a element in 1d, and that on each of the parent and child cells degrees of freedom are (locally and globally) numbered as follows:
Then we want the restriction operation to take the value of the zeroth DoF on child 0 as the value of the zeroth DoF on the parent, and take the value of the first DoF on child 1 as the value of the first DoF on the parent. Ideally, we would like to write this follows
-
+ \]" src="form_1015.png"/>
-
where and . Writing the requested operation like this would here be possible by choosing
- and . Writing the requested operation like this would here be possible by choosing
+
+ \]" src="form_1018.png"/>
-
However, this approach already fails if we go to a element with the following degrees of freedom:
meshes: *-------* *----*----*
+
However, this approach already fails if we go to a element with the following degrees of freedom:
In other words, each nonzero element of overwrites, rather than adds to the corresponding element of . This typically also implies that the restriction matrices from two different cells should agree on a value for coarse degrees of freedom that they both want to touch (otherwise the result would depend on the order in which we loop over children, which would be unreasonable because the order of children is an otherwise arbitrary convention). For example, in the example above, the restriction matrices will be
-overwrites, rather than adds to the corresponding element of . This typically also implies that the restriction matrices from two different cells should agree on a value for coarse degrees of freedom that they both want to touch (otherwise the result would depend on the order in which we loop over children, which would be unreasonable because the order of children is an otherwise arbitrary convention). For example, in the example above, the restriction matrices will be
+
+ \]" src="form_1023.png"/>
-
and the compatibility condition is the because they both indicate that should be set to one times and .
+
and the compatibility condition is the because they both indicate that should be set to one times and .
Unfortunately, not all finite elements allow to write the restriction operation in this way. For example, for the piecewise constant FE_DGQ(0) element, the value of the finite element field on the parent cell can not be determined by interpolation from the children. Rather, the only reasonable choice is to take it as the average value between the children – so we are back to the sum operation, rather than the concatenation. Further thought shows that whether restriction should be additive or not is a property of the individual shape function, not of the finite element as a whole. Consequently, the FiniteElement::restriction_is_additive() function returns whether a particular shape function should act via concatenation (a return value of false) or via addition (return value of true), and the correct code for the overall operation is then as follows (and as, in fact, implemented in DoFAccessor::get_interpolated_dof_values()):
for (unsignedint child=0; child<cell->n_children(); ++child)
The index of this degree of freedom within the set of degrees of freedom on the entire cell. The returned value will be between zero and dofs_per_cell.
-
Note
This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a , then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
+
Note
This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a , then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
Return a block mask with as many elements as this object has blocks and of which exactly the one component is true that corresponds to the given argument. See the glossary for more information.
-
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
scalar
An object that represents a single scalar vector component of this finite element.
@@ -2914,7 +2914,7 @@
Given a component mask (see this glossary entry), produce a block mask (see this glossary entry) that represents the blocks that correspond to the components selected in the input argument. This is essentially a conversion operator from ComponentMask to BlockMask.
-
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
Parameters
component_mask
The mask that selects individual components of the finite element
@@ -3134,7 +3134,7 @@
Return a vector of generalized support points.
-
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
+
Note
The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
For a given degree of freedom, return whether it is logically associated with a vertex, line, quad or hex.
-
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
-
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
-
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
+
For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.
+
To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.
+
On the other hand, for discontinuous elements of type , a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).
Parameters
[in]
cell_dof_index
The index of a shape function or degree of freedom. This index must be in the range [0,dofs_per_cell).
@@ -3224,11 +3224,11 @@
-
Given the values of a function at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., , where are the node functionals of the element (see also Node values or node functionals). The values are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function , i.e., is the finite element interpolant of with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.
-
In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are and that the node functionals associated with the current element are . Then, the fact that the element is based on generalized support points, implies that if we apply to a (possibly vector-valued) finite element function , the result must have the form – in other words, the value of the node functional applied to only depends on the values of at and not on values anywhere else, or integrals of , or any other kind of information.
-
The exact form of depends on the element. For example, for scalar Lagrange elements, we have that in fact . If you combine multiple scalar Lagrange elements via an FESystem object, then where is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that where is the normal vector of the face at which the shape function is defined.
-
Given all of this, what this function does is the following: If you input a list of values of a function at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in then you will get out a vector where equals dofs_per_cell.
+
Given the values of a function at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., , where are the node functionals of the element (see also Node values or node functionals). The values are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function , i.e., is the finite element interpolant of with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.
+
In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are and that the node functionals associated with the current element are . Then, the fact that the element is based on generalized support points, implies that if we apply to a (possibly vector-valued) finite element function , the result must have the form – in other words, the value of the node functional applied to only depends on the values of at and not on values anywhere else, or integrals of , or any other kind of information.
+
The exact form of depends on the element. For example, for scalar Lagrange elements, we have that in fact . If you combine multiple scalar Lagrange elements via an FESystem object, then where is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that where is the normal vector of the face at which the shape function is defined.
+
Given all of this, what this function does is the following: If you input a list of values of a function at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in then you will get out a vector where equals dofs_per_cell.
Parameters
[in]
support_point_values
An array of size dofs_per_cell (which equals the number of points the get_generalized_support_points() function will return) where each element is a vector with as many entries as the element has vector components. This array should contain the values of a function at the generalized support points of the current element.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFiniteElementData.html differs (JavaScript source, ASCII text, with very long lines (1263))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFiniteElementData.html 2023-11-25 15:25:55.476646578 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFiniteElementData.html 2023-11-25 15:25:55.476646578 +0100
@@ -317,10 +317,10 @@
Constructor, computing all necessary values from the distribution of dofs to geometrical objects.
Parameters
-
[in]
dofs_per_object
A vector that describes the number of degrees of freedom on geometrical objects for each dimension. This vector must have size dim+1, and entry 0 describes the number of degrees of freedom per vertex, entry 1 the number of degrees of freedom per line, etc. As an example, for the common Lagrange element in 2d, this vector would have elements (1,0,0). On the other hand, for a element in 3d, it would have entries (1,2,4,8).
+
[in]
dofs_per_object
A vector that describes the number of degrees of freedom on geometrical objects for each dimension. This vector must have size dim+1, and entry 0 describes the number of degrees of freedom per vertex, entry 1 the number of degrees of freedom per line, etc. As an example, for the common Lagrange element in 2d, this vector would have elements (1,0,0). On the other hand, for a element in 3d, it would have entries (1,2,4,8).
[in]
n_components
Number of vector components of the element.
-
[in]
degree
The maximal polynomial degree of any of the shape functions of this element in any variable on the reference element. For example, for the element (in any space dimension), this would be one; this is so despite the fact that the element has a shape function of the form (in 2d) and (in 3d), which, although quadratic and cubic polynomials, are still only linear in each reference variable separately. The information provided by this variable is typically used in determining what an appropriate quadrature formula is.
-
[in]
conformity
A variable describing which Sobolev space this element conforms to. For example, the Lagrange elements (implemented by the FE_Q class) are conforming, whereas the Raviart-Thomas element (implemented by the FE_RaviartThomas class) is conforming; finally, completely discontinuous elements (implemented by the FE_DGQ class) are only conforming.
+
[in]
degree
The maximal polynomial degree of any of the shape functions of this element in any variable on the reference element. For example, for the element (in any space dimension), this would be one; this is so despite the fact that the element has a shape function of the form (in 2d) and (in 3d), which, although quadratic and cubic polynomials, are still only linear in each reference variable separately. The information provided by this variable is typically used in determining what an appropriate quadrature formula is.
+
[in]
conformity
A variable describing which Sobolev space this element conforms to. For example, the Lagrange elements (implemented by the FE_Q class) are conforming, whereas the Raviart-Thomas element (implemented by the FE_RaviartThomas class) is conforming; finally, completely discontinuous elements (implemented by the FE_DGQ class) are only conforming.
[in]
block_indices
An argument that describes how the base elements of a finite element are grouped. The default value constructs a single block that consists of all dofs_per_cell degrees of freedom. This is appropriate for all "atomic" elements (including non-primitive ones) and these can therefore omit this argument. On the other hand, composed elements such as FESystem will want to pass a different value here.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFiniteSizeHistory.html differs (JavaScript source, ASCII text, with very long lines (874))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFiniteSizeHistory.html 2023-11-25 15:25:55.486646374 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFiniteSizeHistory.html 2023-11-25 15:25:55.486646374 +0100
@@ -127,7 +127,7 @@
template<typename T>
class FiniteSizeHistory< T >
A helper class to store a finite-size collection of objects of type T. If the number of elements exceeds the specified maximum size of the container, the oldest element is removed. Additionally, random access and removal of elements is implemented. Indexing is done relative to the last added element.
In order to optimize the container for usage with memory-demanding objects (i.e. linear algebra vectors), the removal of an element does not free the memory. Instead the element is being kept in a separate cache so that subsequent addition does not require re-allocation of memory.
-
The primary usage of this class is in solvers to store a history of vectors. That is, if at the iteration we store vectors from previous iterations , then addition of the new element will make the object contain elements from iterations .
+
The primary usage of this class is in solvers to store a history of vectors. That is, if at the iteration we store vectors from previous iterations , then addition of the new element will make the object contain elements from iterations .
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFlatManifold.html differs (JavaScript source, ASCII text, with very long lines (899))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFlatManifold.html 2023-11-25 15:25:55.509979235 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFlatManifold.html 2023-11-25 15:25:55.509979235 +0100
@@ -528,7 +528,7 @@
-
Return a vector that, at , is tangential to the geodesic that connects two points . For the current class, we assume that the manifold is flat, so the geodesic is the straight line between the two points, and we return . The normalization of the vector is chosen so that it fits the convention described in Manifold::get_tangent_vector().
+
Return a vector that, at , is tangential to the geodesic that connects two points . For the current class, we assume that the manifold is flat, so the geodesic is the straight line between the two points, and we return . The normalization of the vector is chosen so that it fits the convention described in Manifold::get_tangent_vector().
Note
If you use this class as a stepping stone to build a manifold that only "slightly" deviates from a flat manifold, by overloading the project_to_manifold() function.
Parameters
@@ -537,7 +537,7 @@
-
Returns
A "direction" vector tangential to the geodesic. Here, this is , possibly modified by the periodicity of the domain as set in the constructor, to use the "shortest" connection between the points through the periodic boundary as necessary.
+
Returns
A "direction" vector tangential to the geodesic. Here, this is , possibly modified by the periodicity of the domain as set in the constructor, to use the "shortest" connection between the points through the periodic boundary as necessary.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFullMatrix.html differs (JavaScript source, ASCII text, with very long lines (804))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFullMatrix.html 2023-11-25 15:25:55.533312092 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFullMatrix.html 2023-11-25 15:25:55.533312092 +0100
@@ -1173,8 +1173,8 @@
-
Return the l1-norm of the matrix, where (maximum of the sums over columns).
+
Return the l1-norm of the matrix, where (maximum of the sums over columns).
@@ -1194,8 +1194,8 @@
-
Return the -norm of the matrix, where (maximum of the sums over rows).
+
Return the -norm of the matrix, where (maximum of the sums over rows).
@@ -2323,7 +2323,7 @@
A=Inverse(A). A must be a square matrix. Inversion of this matrix by Gauss-Jordan algorithm with partial pivoting. This process is well-behaved for positive definite matrices, but be aware of round-off errors in the indefinite case.
In case deal.II was configured with LAPACK, the functions Xgetrf and Xgetri build an LU factorization and invert the matrix upon that factorization, providing best performance up to matrices with a few hundreds rows and columns.
-
The numerical effort to invert an matrix is of the order .
+
The numerical effort to invert an matrix is of the order .
@@ -2367,7 +2367,7 @@
-
Assign the Cholesky decomposition of the given matrix to *this, where is lower triangular matrix. The given matrix must be symmetric positive definite.
+
Assign the Cholesky decomposition of the given matrix to *this, where is lower triangular matrix. The given matrix must be symmetric positive definite.
ExcMatrixNotPositiveDefinite will be thrown in the case that the matrix is not positive definite.
@@ -2399,7 +2399,7 @@
-
*this(i,j) = where are vectors of the same length.
+
*this(i,j) = where are vectors of the same length.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFunction.html differs (JavaScript source, ASCII text, with very long lines (5897))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFunction.html 2023-11-25 15:25:55.553311684 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFunction.html 2023-11-25 15:25:55.553311684 +0100
@@ -248,7 +248,7 @@
C}^{n_\text{components}}$" src="form_455.png"/>. In such cases, you can choose a value different than the default double for the second template argument of this class: it describes the scalar type to be used for each component of your return values. It defaults to double, but in the example above, it could be set to std::complex<double>. step-58 is an example of this.
Template Parameters
-
dim
The space dimension of the range space within which the domain of the function lies. Consequently, the function will be evaluated at objects of type Point<dim>.
+
dim
The space dimension of the range space within which the domain of the function lies. Consequently, the function will be evaluated at objects of type Point<dim>.
RangeNumberType
The scalar type of the vector space that is the range (or image) of this function. As discussed above, objects of the current type represent functions from to where is the underlying scalar type of the vector space. The type of is given by the RangeNumberType template argument.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFunctionDerivative.html differs (JavaScript source, ASCII text, with very long lines (687))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFunctionDerivative.html 2023-11-25 15:25:55.576644545 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFunctionDerivative.html 2023-11-25 15:25:55.576644545 +0100
@@ -342,27 +342,27 @@
Names of difference formulas.
Enumerator
Euler
The symmetric Euler formula of second order:
-
+\]" src="form_359.png"/>
UpwindEuler
The upwind Euler formula of first order:
-
+\]" src="form_360.png"/>
FourthOrder
The fourth order scheme
-
+\]" src="form_361.png"/>
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFunctionManifold.html differs (JavaScript source, ASCII text, with very long lines (1359))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFunctionManifold.html 2023-11-25 15:25:55.599977403 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFunctionManifold.html 2023-11-25 15:25:55.599977403 +0100
@@ -569,7 +569,7 @@
-
Given a point in the chartdim dimensional Euclidean space, this method returns the derivatives of the function that maps from the sub_manifold coordinate system to the Euclidean coordinate system. In other words, it is a matrix of size .
+
Given a point in the chartdim dimensional Euclidean space, this method returns the derivatives of the function that maps from the sub_manifold coordinate system to the Euclidean coordinate system. In other words, it is a matrix of size .
This function is used in the computations required by the get_tangent_vector() function. The default implementation calls the get_gradient() method of the FunctionManifold::push_forward_function() member class. If you construct this object using the constructor that takes two string expression, then the default implementation of this method uses a finite difference scheme to compute the gradients(see the
AutoDerivativeFunction() class for details), and you can specify the size of the spatial step size at construction time with the h parameter.
Refer to the general documentation of this class for more information.
@@ -783,24 +783,24 @@
-
Return a vector that, at , is tangential to the geodesic that connects two points . See the documentation of the Manifold class and of Manifold::get_tangent_vector() for a more detailed description.
-
For the current class, we assume that this geodesic is the image under the push_forward() operation of a straight line of the pre-images of x1 and x2 (where pre-images are computed by pulling back the locations x1 and x2). In other words, if these preimages are , then the geodesic in preimage (the chartdim-dimensional Euclidean) space is
-, is tangential to the geodesic that connects two points . See the documentation of the Manifold class and of Manifold::get_tangent_vector() for a more detailed description.
+
For the current class, we assume that this geodesic is the image under the push_forward() operation of a straight line of the pre-images of x1 and x2 (where pre-images are computed by pulling back the locations x1 and x2). In other words, if these preimages are , then the geodesic in preimage (the chartdim-dimensional Euclidean) space is
+
+\end{align*}" src="form_1440.png"/>
In image space, i.e., in the space in which we operate, this leads to the curve
-
+\end{align*}" src="form_1441.png"/>
-
What the current function is supposed to return is . By the chain rule, this is equal to
-. By the chain rule, this is equal to
+
+\end{align*}" src="form_1442.png"/>
This formula may then have to be slightly modified by considering any periodicity that was assumed in the call to the constructor.
-
Thus, the computation of tangent vectors also requires the implementation of derivatives of the push-forward mapping. Here, is a chartdim-dimensional vector, and is a spacedim-times-chartdim-dimensional matrix. Consequently, and as desired, the operation results in a spacedim-dimensional vector.
+
Thus, the computation of tangent vectors also requires the implementation of derivatives of the push-forward mapping. Here, is a chartdim-dimensional vector, and is a spacedim-times-chartdim-dimensional matrix. Consequently, and as desired, the operation results in a spacedim-dimensional vector.
Parameters
x1
The first point that describes the geodesic, and the one at which the "direction" is to be evaluated.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFunctionParser.html differs (JavaScript source, ASCII text, with very long lines (1494))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFunctionParser.html 2023-11-25 15:25:55.626643528 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFunctionParser.html 2023-11-25 15:25:55.623310260 +0100
@@ -503,27 +503,27 @@
Names of difference formulas.
Enumerator
Euler
The symmetric Euler formula of second order:
-
+\]" src="form_359.png"/>
UpwindEuler
The upwind Euler formula of first order:
-
+\]" src="form_360.png"/>
FourthOrder
The fourth order scheme
-
+\]" src="form_361.png"/>
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFunctions_1_1CoordinateRestriction.html differs (JavaScript source, ASCII text, with very long lines (1321))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFunctions_1_1CoordinateRestriction.html 2023-11-25 15:25:55.646643120 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFunctions_1_1CoordinateRestriction.html 2023-11-25 15:25:55.646643120 +0100
@@ -215,7 +215,7 @@
Detailed Description
template<int dim>
-class Functions::CoordinateRestriction< dim >
This class takes a function in dim + 1 dimensions and creates a new function in one dimension lower by restricting one of the coordinates to a given value. Mathematically this corresponds to taking a function , a fixed value, , and defining a new function (the restriction) . Using this class, this translates to
This class takes a function in dim + 1 dimensions and creates a new function in one dimension lower by restricting one of the coordinates to a given value. Mathematically this corresponds to taking a function , a fixed value, , and defining a new function (the restriction) . Using this class, this translates to
The dim-dimensional coordinates on the restriction are ordered starting from the restricted (dim + 1)-coordinate. In particular, this means that if the -coordinate is locked to in 3d, the coordinates are ordered as on the restriction: . This is the same convention as in BoundingBox::cross_section.
+
The dim-dimensional coordinates on the restriction are ordered starting from the restricted (dim + 1)-coordinate. In particular, this means that if the -coordinate is locked to in 3d, the coordinates are ordered as on the restriction: . This is the same convention as in BoundingBox::cross_section.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFunctions_1_1CutOffFunctionC1.html differs (JavaScript source, ASCII text, with very long lines (1029))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFunctions_1_1CutOffFunctionC1.html 2023-11-25 15:25:55.666642713 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFunctions_1_1CutOffFunctionC1.html 2023-11-25 15:25:55.666642713 +0100
@@ -238,8 +238,8 @@
Detailed Description
template<int dim>
-class Functions::CutOffFunctionC1< dim >
A cut-off function for an arbitrarily-sized ball that is in the space (i.e., continuously differentiable). This is a cut-off function that is often used in the literature of the Immersed Boundary Method.
-
The expression of the function in radial coordinates is given by where is the distance to the center, and is the radius of the sphere. If vector valued, it can be restricted to a single component.
+class Functions::CutOffFunctionC1< dim >
A cut-off function for an arbitrarily-sized ball that is in the space (i.e., continuously differentiable). This is a cut-off function that is often used in the literature of the Immersed Boundary Method.
+
The expression of the function in radial coordinates is given by where is the distance to the center, and is the radius of the sphere. If vector valued, it can be restricted to a single component.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFunctions_1_1CutOffFunctionCinfty.html differs (JavaScript source, ASCII text, with very long lines (1037))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFunctions_1_1CutOffFunctionCinfty.html 2023-11-25 15:25:55.686642306 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFunctions_1_1CutOffFunctionCinfty.html 2023-11-25 15:25:55.689975570 +0100
@@ -238,7 +238,7 @@
Detailed Description
template<int dim>
-class Functions::CutOffFunctionCinfty< dim >
Cut-off function for an arbitrary ball. This is the traditional cut-off function in C-infinity for a ball of certain radius around center, , where is the distance to the center, and is the radius of the sphere. If vector valued, it can be restricted to a single component.
+class Functions::CutOffFunctionCinfty< dim >
Cut-off function for an arbitrary ball. This is the traditional cut-off function in C-infinity for a ball of certain radius around center, , where is the distance to the center, and is the radius of the sphere. If vector valued, it can be restricted to a single component.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFunctions_1_1CutOffFunctionLinfty.html differs (JavaScript source, ASCII text, with very long lines (1043))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFunctions_1_1CutOffFunctionLinfty.html 2023-11-25 15:25:55.709975163 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFunctions_1_1CutOffFunctionLinfty.html 2023-11-25 15:25:55.709975163 +0100
@@ -239,7 +239,7 @@
Detailed Description
template<int dim>
class Functions::CutOffFunctionLinfty< dim >
Cut-off function in L-infinity for an arbitrary ball. This function is the characteristic function of a ball around center with a specified radius, that is,
-
+
If vector valued, it can be restricted to a single component.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFunctions_1_1FourierCosineFunction.html differs (JavaScript source, ASCII text, with very long lines (1279))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFunctions_1_1FourierCosineFunction.html 2023-11-25 15:25:55.729974756 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFunctions_1_1FourierCosineFunction.html 2023-11-25 15:25:55.729974756 +0100
@@ -211,8 +211,8 @@
Detailed Description
template<int dim>
-class Functions::FourierCosineFunction< dim >
Given a wavenumber vector generate a cosine function. The wavenumber coefficient is given as a -dimensional point in Fourier space, and the function is then recovered as .
+class Functions::FourierCosineFunction< dim >
Given a wavenumber vector generate a cosine function. The wavenumber coefficient is given as a -dimensional point in Fourier space, and the function is then recovered as .
The class has its name from the fact that it resembles one component of a Fourier cosine decomposition.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFunctions_1_1FourierCosineSum.html differs (JavaScript source, ASCII text, with very long lines (870))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFunctions_1_1FourierCosineSum.html 2023-11-25 15:25:55.749974351 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFunctions_1_1FourierCosineSum.html 2023-11-25 15:25:55.749974351 +0100
@@ -213,8 +213,8 @@
Detailed Description
template<int dim>
-class Functions::FourierCosineSum< dim >
Given a sequence of wavenumber vectors and weights generate a sum of cosine functions. Each wavenumber coefficient is given as a -dimensional point in Fourier space, and the entire function is then recovered as .
+class Functions::FourierCosineSum< dim >
Given a sequence of wavenumber vectors and weights generate a sum of cosine functions. Each wavenumber coefficient is given as a -dimensional point in Fourier space, and the entire function is then recovered as .
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFunctions_1_1FourierSineFunction.html differs (JavaScript source, ASCII text, with very long lines (1337))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFunctions_1_1FourierSineFunction.html 2023-11-25 15:25:55.769973944 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFunctions_1_1FourierSineFunction.html 2023-11-25 15:25:55.769973944 +0100
@@ -211,8 +211,8 @@
Detailed Description
template<int dim>
-class Functions::FourierSineFunction< dim >
Given a wavenumber vector generate a sine function. The wavenumber coefficient is given as a -dimensional point in Fourier space, and the function is then recovered as .
+class Functions::FourierSineFunction< dim >
Given a wavenumber vector generate a sine function. The wavenumber coefficient is given as a -dimensional point in Fourier space, and the function is then recovered as .
The class has its name from the fact that it resembles one component of a Fourier sine decomposition.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFunctions_1_1FourierSineSum.html differs (JavaScript source, ASCII text, with very long lines (870))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFunctions_1_1FourierSineSum.html 2023-11-25 15:25:55.786640269 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFunctions_1_1FourierSineSum.html 2023-11-25 15:25:55.786640269 +0100
@@ -213,7 +213,7 @@
Detailed Description
template<int dim>
-class Functions::FourierSineSum< dim >
Given a sequence of wavenumber vectors and weights generate a sum of sine functions. Each wavenumber coefficient is given as a -dimensional point in Fourier space, and the entire function is then recovered as .
+class Functions::FourierSineSum< dim >
Given a sequence of wavenumber vectors and weights generate a sum of sine functions. Each wavenumber coefficient is given as a -dimensional point in Fourier space, and the entire function is then recovered as .
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFunctions_1_1InterpolatedTensorProductGridData.html differs (JavaScript source, ASCII text, with very long lines (1313))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFunctions_1_1InterpolatedTensorProductGridData.html 2023-11-25 15:25:55.809973130 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFunctions_1_1InterpolatedTensorProductGridData.html 2023-11-25 15:25:55.809973130 +0100
@@ -226,11 +226,11 @@
Detailed Description
template<int dim>
-class Functions::InterpolatedTensorProductGridData< dim >
A scalar function that computes its values by (bi-, tri-)linear interpolation from a set of point data that are arranged on a possibly non-uniform tensor product mesh. In other words, considering the three- dimensional case, let there be points , , , and data defined at point , then evaluating the function at a point will find the box so that , and do a trilinear interpolation of the data on this cell. Similar operations are done in lower dimensions.
+class Functions::InterpolatedTensorProductGridData< dim >
A scalar function that computes its values by (bi-, tri-)linear interpolation from a set of point data that are arranged on a possibly non-uniform tensor product mesh. In other words, considering the three- dimensional case, let there be points , , , and data defined at point , then evaluating the function at a point will find the box so that , and do a trilinear interpolation of the data on this cell. Similar operations are done in lower dimensions.
This class is most often used for either evaluating coefficients or right hand sides that are provided experimentally at a number of points inside the domain, or for comparing outputs of a solution on a finite element mesh against previously obtained data defined on a grid.
-
Note
If the points are actually equally spaced on an interval and the same is true for the other data points in higher dimensions, you should use the InterpolatedUniformGridData class instead.
+
Note
If the points are actually equally spaced on an interval and the same is true for the other data points in higher dimensions, you should use the InterpolatedUniformGridData class instead.
If a point is requested outside the box defined by the end points of the coordinate arrays, then the function is assumed to simply extend by constant values beyond the last data point in each coordinate direction. (The class does not throw an error if a point lies outside the box since it frequently happens that a point lies just outside the box by an amount on the order of numerical roundoff.)
Constructor to initialize this class instance with the data given in data_values.
Parameters
-
coordinate_values
An array of dim arrays. Each of the inner arrays contains the coordinate values and similarly for the other coordinate directions. These arrays need not have the same size. Obviously, we need dim such arrays for a dim- dimensional function object. The coordinate values within this array are assumed to be strictly ascending to allow for efficient lookup.
+
coordinate_values
An array of dim arrays. Each of the inner arrays contains the coordinate values and similarly for the other coordinate directions. These arrays need not have the same size. Obviously, we need dim such arrays for a dim- dimensional function object. The coordinate values within this array are assumed to be strictly ascending to allow for efficient lookup.
data_values
A dim-dimensional table of data at each of the mesh points defined by the coordinate arrays above. The data passed in is copied into internal data structures. Note that the Table class has a number of conversion constructors that allow converting other data types into a table where you specify this argument.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFunctions_1_1InterpolatedUniformGridData.html differs (JavaScript source, ASCII text, with very long lines (2095))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFunctions_1_1InterpolatedUniformGridData.html 2023-11-25 15:25:55.829972723 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFunctions_1_1InterpolatedUniformGridData.html 2023-11-25 15:25:55.829972723 +0100
@@ -219,10 +219,10 @@
Detailed Description
template<int dim>
-class Functions::InterpolatedUniformGridData< dim >
A scalar function that computes its values by (bi-, tri-)linear interpolation from a set of point data that are arranged on a uniformly spaced tensor product mesh. In other words, considering the three- dimensional case, let there be points that result from a uniform subdivision of the interval into sub-intervals of size , and similarly , . Also consider data defined at point , then evaluating the function at a point will find the box so that , and do a trilinear interpolation of the data on this cell. Similar operations are done in lower dimensions.
+class Functions::InterpolatedUniformGridData< dim >
A scalar function that computes its values by (bi-, tri-)linear interpolation from a set of point data that are arranged on a uniformly spaced tensor product mesh. In other words, considering the three- dimensional case, let there be points that result from a uniform subdivision of the interval into sub-intervals of size , and similarly , . Also consider data defined at point , then evaluating the function at a point will find the box so that , and do a trilinear interpolation of the data on this cell. Similar operations are done in lower dimensions.
This class is most often used for either evaluating coefficients or right hand sides that are provided experimentally at a number of points inside the domain, or for comparing outputs of a solution on a finite element mesh against previously obtained data defined on a grid.
-
Note
If you have a problem where the points are not equally spaced (e.g., they result from a computation on a graded mesh that is denser closer to one boundary), then use the InterpolatedTensorProductGridData class instead.
+
Note
If you have a problem where the points are not equally spaced (e.g., they result from a computation on a graded mesh that is denser closer to one boundary), then use the InterpolatedTensorProductGridData class instead.
If a point is requested outside the box defined by the end points of the coordinate arrays, then the function is assumed to simply extend by constant values beyond the last data point in each coordinate direction. (The class does not throw an error if a point lies outside the box since it frequently happens that a point lies just outside the box by an amount on the order of numerical roundoff.)
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFunctions_1_1LSingularityFunction.html differs (JavaScript source, ASCII text, with very long lines (1072))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFunctions_1_1LSingularityFunction.html 2023-11-25 15:25:55.846639051 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFunctions_1_1LSingularityFunction.html 2023-11-25 15:25:55.846639051 +0100
@@ -215,14 +215,14 @@
Detailed Description
A function that solves the Laplace equation (with specific boundary values but zero right hand side) and that has a singularity at the center of the L-shaped domain in 2d (i.e., at the location of the re-entrant corner of this non-convex domain).
-
The function is given in polar coordinates by with a singularity at the origin and should be used with GridGenerator::hyper_L(). Here, is defined as the clockwise angle against the positive -axis.
+
The function is given in polar coordinates by with a singularity at the origin and should be used with GridGenerator::hyper_L(). Here, is defined as the clockwise angle against the positive -axis.
This function is often used to illustrate that the solutions of the Laplace equation
-
+\]" src="form_468.png"/>
-
can be singular even if the boundary values are smooth. (Here, if the domain is the L-shaped domain , the boundary values for are zero on the two line segments adjacent to the origin, and equal to on the remaining parts of the boundary.) The function itself remains bounded on the domain, but its gradient is of the form in the vicinity of the origin and consequently diverges as one approaches the origin.
+
can be singular even if the boundary values are smooth. (Here, if the domain is the L-shaped domain , the boundary values for are zero on the two line segments adjacent to the origin, and equal to on the remaining parts of the boundary.) The function itself remains bounded on the domain, but its gradient is of the form in the vicinity of the origin and consequently diverges as one approaches the origin.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFunctions_1_1Monomial.html differs (JavaScript source, ASCII text, with very long lines (2228))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFunctions_1_1Monomial.html 2023-11-25 15:25:55.866638644 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFunctions_1_1Monomial.html 2023-11-25 15:25:55.866638644 +0100
@@ -213,7 +213,7 @@
Detailed Description
template<int dim, typename Number = double>
-class Functions::Monomial< dim, Number >
A class that represents a function object for a monomial. Monomials are polynomials with only a single term, i.e. in 1-d they have the form , in 2-d the form , and in 3-d . Monomials are therefore described by a -tuple of exponents. Consequently, the class's constructor takes a Tensor<1,dim> to describe the set of exponents. Most of the time these exponents will of course be integers, but real exponents are of course equally valid. Exponents can't be real when the bases are negative numbers.
+class Functions::Monomial< dim, Number >
A class that represents a function object for a monomial. Monomials are polynomials with only a single term, i.e. in 1-d they have the form , in 2-d the form , and in 3-d . Monomials are therefore described by a -tuple of exponents. Consequently, the class's constructor takes a Tensor<1,dim> to describe the set of exponents. Most of the time these exponents will of course be integers, but real exponents are of course equally valid. Exponents can't be real when the bases are negative numbers.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFunctions_1_1ParsedFunction.html differs (JavaScript source, ASCII text, with very long lines (655))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFunctions_1_1ParsedFunction.html 2023-11-25 15:25:55.889971502 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFunctions_1_1ParsedFunction.html 2023-11-25 15:25:55.889971502 +0100
@@ -374,27 +374,27 @@
Names of difference formulas.
Enumerator
Euler
The symmetric Euler formula of second order:
-
+\]" src="form_359.png"/>
UpwindEuler
The upwind Euler formula of first order:
-
+\]" src="form_360.png"/>
FourthOrder
The fourth order scheme
-
+\]" src="form_361.png"/>
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFunctions_1_1PointRestriction.html differs (JavaScript source, ASCII text, with very long lines (1076))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFunctions_1_1PointRestriction.html 2023-11-25 15:25:55.909971095 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFunctions_1_1PointRestriction.html 2023-11-25 15:25:55.909971095 +0100
@@ -218,7 +218,7 @@
Detailed Description
template<int dim>
-class Functions::PointRestriction< dim >
This class creates a 1-dimensional function from a dim + 1 dimensional function by restricting dim of the coordinate values to a given point. Mathematically this corresponds to taking a function, , and a point , and defining a new function . Using this class, this translates to
This class creates a 1-dimensional function from a dim + 1 dimensional function by restricting dim of the coordinate values to a given point. Mathematically this corresponds to taking a function, , and a point , and defining a new function . Using this class, this translates to
The coordinates of the point will be expanded in the higher-dimensional functions coordinates starting from the open-direction (and wrapping around). In particular, if we restrict to a point and choose to keep the y-direction open, the restriction that is created is the function . This is consistent with the convention in BoundingBox::cross_section.
+
The coordinates of the point will be expanded in the higher-dimensional functions coordinates starting from the open-direction (and wrapping around). In particular, if we restrict to a point and choose to keep the y-direction open, the restriction that is created is the function . This is consistent with the convention in BoundingBox::cross_section.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFunctions_1_1Polynomial.html differs (JavaScript source, ASCII text, with very long lines (2228))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFunctions_1_1Polynomial.html 2023-11-25 15:25:55.929970688 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFunctions_1_1Polynomial.html 2023-11-25 15:25:55.929970688 +0100
@@ -214,8 +214,8 @@
Detailed Description
template<int dim>
-class Functions::Polynomial< dim >
A class that represents a function object for a polynomial. A polynomial is composed by the summation of multiple monomials. If the polynomial has n monomials and the dimension is equal to dim, the polynomial can be written as , where are the coefficients of the monomials and are their exponents. The class's constructor takes a Table<2,double> to describe the set of exponents and a Vector<double> to describe the set of coefficients.
+class Functions::Polynomial< dim >
A class that represents a function object for a polynomial. A polynomial is composed by the summation of multiple monomials. If the polynomial has n monomials and the dimension is equal to dim, the polynomial can be written as , where are the coefficients of the monomials and are their exponents. The class's constructor takes a Table<2,double> to describe the set of exponents and a Vector<double> to describe the set of coefficients.
Constructor. The coefficients and the exponents of the polynomial are passed as arguments. The Table<2, double> exponents has a number of rows equal to the number of monomials of the polynomial and a number of columns equal to dim. The i-th row of the exponents table contains the exponents of the i-th monomial . The i-th element of the coefficients vector contains the coefficient for the i-th monomial.
+
Constructor. The coefficients and the exponents of the polynomial are passed as arguments. The Table<2, double> exponents has a number of rows equal to the number of monomials of the polynomial and a number of columns equal to dim. The i-th row of the exponents table contains the exponents of the i-th monomial . The i-th element of the coefficients vector contains the coefficient for the i-th monomial.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFunctions_1_1SignedDistance_1_1Ellipsoid.html differs (JavaScript source, ASCII text, with very long lines (870))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFunctions_1_1SignedDistance_1_1Ellipsoid.html 2023-11-25 15:25:55.949970279 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFunctions_1_1SignedDistance_1_1Ellipsoid.html 2023-11-25 15:25:55.949970279 +0100
@@ -225,11 +225,11 @@
template<int dim>
class Functions::SignedDistance::Ellipsoid< dim >
Signed-distance level set function to an ellipsoid defined by:
-
+\]" src="form_527.png"/>
-
Here, are the coordinates of the center of the ellipsoid and are the elliptic radii. This function is zero on the ellipsoid, negative inside the ellipsoid and positive outside the ellipsoid.
+
Here, are the coordinates of the center of the ellipsoid and are the elliptic radii. This function is zero on the ellipsoid, negative inside the ellipsoid and positive outside the ellipsoid.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFunctions_1_1SignedDistance_1_1Plane.html differs (JavaScript source, ASCII text, with very long lines (2228))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFunctions_1_1SignedDistance_1_1Plane.html 2023-11-25 15:25:55.969969872 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFunctions_1_1SignedDistance_1_1Plane.html 2023-11-25 15:25:55.969969872 +0100
@@ -213,7 +213,7 @@
Detailed Description
template<int dim>
-class Functions::SignedDistance::Plane< dim >
Signed level set function of a plane in : . Here, is the plane normal and is a point in the plane. Thus, with respect to the direction of the normal, this function is positive above the plane, zero in the plane, and negative below the plane. If the normal is normalized, will be the signed distance to the closest point in the plane.
+class Functions::SignedDistance::Plane< dim >
Signed level set function of a plane in : . Here, is the plane normal and is a point in the plane. Thus, with respect to the direction of the normal, this function is positive above the plane, zero in the plane, and negative below the plane. If the normal is normalized, will be the signed distance to the closest point in the plane.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFunctions_1_1SignedDistance_1_1Rectangle.html differs (JavaScript source, ASCII text, with very long lines (4365))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFunctions_1_1SignedDistance_1_1Rectangle.html 2023-11-25 15:25:55.989969465 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFunctions_1_1SignedDistance_1_1Rectangle.html 2023-11-25 15:25:55.989969465 +0100
@@ -213,7 +213,7 @@
Detailed Description
template<int dim>
class Functions::SignedDistance::Rectangle< dim >
Signed-distance level set function of a rectangle.
-
This function is zero on the rectangle, negative "inside" and positive in the rest of .
+
This function is zero on the rectangle, negative "inside" and positive in the rest of .
Contour surfaces of the signed distance function of a 3D rectangle are illustrated below:
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFunctions_1_1SignedDistance_1_1Sphere.html differs (JavaScript source, ASCII text, with very long lines (2228))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFunctions_1_1SignedDistance_1_1Sphere.html 2023-11-25 15:25:56.009969058 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFunctions_1_1SignedDistance_1_1Sphere.html 2023-11-25 15:25:56.009969058 +0100
@@ -213,9 +213,9 @@
Detailed Description
template<int dim>
-class Functions::SignedDistance::Sphere< dim >
Signed-distance level set function of a sphere: . Here, is the center of the sphere and is its radius. This function is thus zero on the sphere, negative "inside" the ball having the sphere as its boundary, and positive in the rest of .
-
This function has gradient and Hessian equal to , , where is the Kronecker delta function.
+class Functions::SignedDistance::Sphere< dim >
Signed-distance level set function of a sphere: . Here, is the center of the sphere and is its radius. This function is thus zero on the sphere, negative "inside" the ball having the sphere as its boundary, and positive in the rest of .
+
This function has gradient and Hessian equal to , , where is the Kronecker delta function.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFunctions_1_1SignedDistance_1_1ZalesakDisk.html differs (JavaScript source, ASCII text, with very long lines (4365))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFunctions_1_1SignedDistance_1_1ZalesakDisk.html 2023-11-25 15:25:56.029968651 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFunctions_1_1SignedDistance_1_1ZalesakDisk.html 2023-11-25 15:25:56.029968651 +0100
@@ -214,8 +214,8 @@
Detailed Description
template<int dim>
class Functions::SignedDistance::ZalesakDisk< dim >
Signed-distance level set function of Zalesak's disk proposed in [zalesak1979fully].
-
It is calculated by the set difference of the level set functions of a sphere and a rectangle . This function is zero on the surface of the disk, negative "inside" and positive in the rest of .
+
It is calculated by the set difference of the level set functions of a sphere and a rectangle . This function is zero on the surface of the disk, negative "inside" and positive in the rest of .
Contour surfaces of the signed distance function of a 3D Zalesak's disk are illustrated below:
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFunctions_1_1Spherical.html differs (JavaScript source, ASCII text, with very long lines (1010))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFunctions_1_1Spherical.html 2023-11-25 15:25:56.049968243 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFunctions_1_1Spherical.html 2023-11-25 15:25:56.049968243 +0100
@@ -216,7 +216,7 @@
Detailed Description
template<int dim>
-class Functions::Spherical< dim >
An abstract base class for a scalar-valued function defined in spherical coordinates. This class wraps transformation of values, gradients and hessians from spherical coordinates to the Cartesian coordinate system used by the Function base class. Therefore derived classes only need to implement those functions in spherical coordinates (specifically svalue(), sgradient() and shessian() ). The convention for angles is the same as in GeometricUtilities::Coordinates.
+class Functions::Spherical< dim >
An abstract base class for a scalar-valued function defined in spherical coordinates. This class wraps transformation of values, gradients and hessians from spherical coordinates to the Cartesian coordinate system used by the Function base class. Therefore derived classes only need to implement those functions in spherical coordinates (specifically svalue(), sgradient() and shessian() ). The convention for angles is the same as in GeometricUtilities::Coordinates.
Note
This function is currently only implemented for dim==3 .
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFunctions_1_1StokesLSingularity.html differs (JavaScript source, ASCII text, with very long lines (1470))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFunctions_1_1StokesLSingularity.html 2023-11-25 15:25:56.073301104 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFunctions_1_1StokesLSingularity.html 2023-11-25 15:25:56.073301104 +0100
@@ -262,7 +262,7 @@
Detailed Description
A singular solution to Stokes' equations on a 2d L-shaped domain.
-
This function satisfies and represents a typical singular solution around a reentrant corner of an L-shaped domain that can be created using GridGenerator::hyper_L(). The velocity vanishes on the two faces of the re-entrant corner and and are singular at the origin while they are smooth in the rest of the domain because they can be written as a product of a smooth function and the term where is the radius and is a fixed parameter.
+
This function satisfies and represents a typical singular solution around a reentrant corner of an L-shaped domain that can be created using GridGenerator::hyper_L(). The velocity vanishes on the two faces of the re-entrant corner and and are singular at the origin while they are smooth in the rest of the domain because they can be written as a product of a smooth function and the term where is the radius and is a fixed parameter.
Taken from Houston, Schötzau, Wihler, proceeding ENUMATH 2003.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classGridIn.html differs (JavaScript source, ASCII text, with very long lines (1540))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classGridIn.html 2023-11-25 15:25:56.093300697 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classGridIn.html 2023-11-25 15:25:56.093300697 +0100
@@ -951,7 +951,7 @@
Returns
This function returns a struct containing some extra data stored by the ExodusII file that cannot be loaded into a Triangulation - see ExodusIIData for more information.
-
A cell face in ExodusII can be in an arbitrary number of sidesets (i.e., it can have an arbitrary number of sideset ids) - however, a boundary cell face in deal.II has exactly one boundary id. All boundary faces that are not in a sideset are given the (default) boundary id of . This function then groups sidesets together into unique sets and gives each one a boundary id. For example: Consider a single-quadrilateral mesh whose left side has no sideset id, right side has sideset ids and , and whose bottom and top sides have sideset ids of . The left face will have a boundary id of , the top and bottom faces boundary ids of , and the right face a boundary id of . Hence the vector returned by this function in that case will be .
+
A cell face in ExodusII can be in an arbitrary number of sidesets (i.e., it can have an arbitrary number of sideset ids) - however, a boundary cell face in deal.II has exactly one boundary id. All boundary faces that are not in a sideset are given the (default) boundary id of . This function then groups sidesets together into unique sets and gives each one a boundary id. For example: Consider a single-quadrilateral mesh whose left side has no sideset id, right side has sideset ids and , and whose bottom and top sides have sideset ids of . The left face will have a boundary id of , the top and bottom faces boundary ids of , and the right face a boundary id of . Hence the vector returned by this function in that case will be .
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classHouseholder.html differs (JavaScript source, ASCII text, with very long lines (2195))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classHouseholder.html 2023-11-25 15:25:56.106633757 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classHouseholder.html 2023-11-25 15:25:56.106633757 +0100
@@ -136,10 +136,10 @@
Detailed Description
template<typename number>
class Householder< number >
QR-decomposition of a full matrix.
-
This class computes the QR-decomposition of given matrix by the Householder algorithm. Then, the function least_squares() can be used to compute the vector minimizing for a given vector . The QR decomposition of is useful for this purpose because the minimizer is given by the equation which is easy to compute because is an orthogonal matrix, and consequently . Thus, . Furthermore, is triangular, so applying to a vector only involves a backward or forward solve.
+
This class computes the QR-decomposition of given matrix by the Householder algorithm. Then, the function least_squares() can be used to compute the vector minimizing for a given vector . The QR decomposition of is useful for this purpose because the minimizer is given by the equation which is easy to compute because is an orthogonal matrix, and consequently . Thus, . Furthermore, is triangular, so applying to a vector only involves a backward or forward solve.
Implementation details
-
The class does not in fact store the and factors explicitly as matrices. It does store , but the factor is stored as the product of Householder reflections of the form where the vectors are so that they can be stored in the lower-triangular part of an underlying matrix object, whereas is stored in the upper triangular part.
-
The vectors and the matrix now are in conflict because they both want to use the diagonal entry of the matrix, but we can only store one in these positions, of course. Consequently, the entries are stored separately in the diagonal member variable.
+
The class does not in fact store the and factors explicitly as matrices. It does store , but the factor is stored as the product of Householder reflections of the form where the vectors are so that they can be stored in the lower-triangular part of an underlying matrix object, whereas is stored in the upper triangular part.
+
The vectors and the matrix now are in conflict because they both want to use the diagonal entry of the matrix, but we can only store one in these positions, of course. Consequently, the entries are stored separately in the diagonal member variable.
Note
Instantiations for this template are provided for <float> and <double>; others can be generated in application programs (see the section on Template instantiations in the manual).
Create an object holding the QR-decomposition of the matrix .
+
Create an object holding the QR-decomposition of the matrix .
@@ -233,7 +233,7 @@
-
Compute the QR-decomposition of the given matrix .
+
Compute the QR-decomposition of the given matrix .
This overwrites any previously computed QR decomposition.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classIdentityMatrix.html differs (JavaScript source, ASCII text, with very long lines (609))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classIdentityMatrix.html 2023-11-25 15:25:56.116633554 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classIdentityMatrix.html 2023-11-25 15:25:56.116633554 +0100
@@ -132,13 +132,13 @@
Detailed Description
-
Implementation of a simple class representing the identity matrix of a given size, i.e. a matrix with entries . While it has the most important ingredients of a matrix, in particular that one can ask for its size and perform matrix-vector products with it, a matrix of this type is really only useful in two contexts: preconditioning and initializing other matrices.
+
Implementation of a simple class representing the identity matrix of a given size, i.e. a matrix with entries . While it has the most important ingredients of a matrix, in particular that one can ask for its size and perform matrix-vector products with it, a matrix of this type is really only useful in two contexts: preconditioning and initializing other matrices.
Initialization
The main usefulness of this class lies in its ability to initialize other matrix, like this:
This creates a matrix with ones on the diagonal and zeros everywhere else. Most matrix types, in particular FullMatrix and SparseMatrix, have conversion constructors and assignment operators for IdentityMatrix, and can therefore be filled rather easily with identity matrices.
+
This creates a matrix with ones on the diagonal and zeros everywhere else. Most matrix types, in particular FullMatrix and SparseMatrix, have conversion constructors and assignment operators for IdentityMatrix, and can therefore be filled rather easily with identity matrices.
Preconditioning
No preconditioning at all is equivalent to preconditioning with preconditioning with the identity matrix. deal.II has a specialized class for this purpose, PreconditionIdentity, than can be used in a context as shown in the documentation of that class. The present class can be used in much the same way, although without any additional benefit:
A class to obtain the triangular matrix of the factorization together with the matrix itself. The orthonormal matrix is not stored explicitly, the name of the class. The multiplication with can be represented as , whereas the multiplication with is given by .
+class ImplicitQR< VectorType >
A class to obtain the triangular matrix of the factorization together with the matrix itself. The orthonormal matrix is not stored explicitly, the name of the class. The multiplication with can be represented as , whereas the multiplication with is given by .
The class is designed to update a given (possibly empty) QR factorization due to the addition of a new column vector. This is equivalent to constructing an orthonormal basis by the Gram-Schmidt procedure. The class also provides update functionality when the column is removed.
The VectorType template argument may either be a parallel and serial vector, and only need to have basic operations such as additions, scalar product, etc. It also needs to have a copy-constructor.
Connect a slot to implement a custom check of linear dependency during addition of a column.
-
Here, u is the last column of the to-be R matrix, rho is its diagonal and col_norm_sqr is the square of the norm of the column. The function should return true if the new column is linearly independent.
+
Here, u is the last column of the to-be R matrix, rho is its diagonal and col_norm_sqr is the square of the norm of the column. The function should return true if the new column is linearly independent.
@@ -521,7 +521,7 @@
-
Apply givens rotation in the (i,k)-plane to zero out .
+
Apply givens rotation in the (i,k)-plane to zero out .
@@ -621,7 +621,7 @@
-
Solve . Vectors x and y should be consistent with the current size of the subspace. If transpose is true, is solved instead.
+
Solve . Vectors x and y should be consistent with the current size of the subspace. If transpose is true, is solved instead.
@@ -689,7 +689,7 @@
-
Compute where is the matrix formed by the column vectors stored by this object.
+
Compute where is the matrix formed by the column vectors stored by this object.
@@ -755,7 +755,7 @@
Signal used to decide if the new column is linear dependent.
-
Here, u is the last column of the to-be R matrix, rho is its diagonal and col_norm_sqr is the square of the norm of the column. The function should return true if the new column is linearly independent.
+
Here, u is the last column of the to-be R matrix, rho is its diagonal and col_norm_sqr is the square of the norm of the column. The function should return true if the new column is linearly independent.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classIndexSet.html differs (JavaScript source, ASCII text, with very long lines (812))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classIndexSet.html 2023-11-25 15:25:56.153299474 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classIndexSet.html 2023-11-25 15:25:56.153299474 +0100
@@ -250,8 +250,8 @@
Detailed Description
-
A class that represents a subset of indices among a larger set. For example, it can be used to denote the set of degrees of freedom within the range that belongs to a particular subdomain, or those among all degrees of freedom that are stored on a particular processor in a distributed parallel computation.
-
This class can represent a collection of half-open ranges of indices as well as individual elements. For practical purposes it also stores the overall range these indices can assume. In other words, you need to specify the size of the index space of which objects of this class are a subset.
+
A class that represents a subset of indices among a larger set. For example, it can be used to denote the set of degrees of freedom within the range that belongs to a particular subdomain, or those among all degrees of freedom that are stored on a particular processor in a distributed parallel computation.
+
This class can represent a collection of half-open ranges of indices as well as individual elements. For practical purposes it also stores the overall range these indices can assume. In other words, you need to specify the size of the index space of which objects of this class are a subset.
There are two ways to iterate over the IndexSets: First, begin() and end() allow iteration over individual indices in the set. Second, begin_interval() and end_interval() allow iteration over the half-open ranges as described above.
The data structures used in this class along with a rationale can be found in the Distributed Computing paper.
@@ -608,7 +608,7 @@
-
Add the half-open range to the set of indices represented by this class.
Parameters
+
Add the half-open range to the set of indices represented by this class.
Parameters
[in]
begin
The first element of the range to be added.
[in]
end
The past-the-end element of the range to be added.
@@ -831,7 +831,7 @@
-
Return whether the IndexSets are ascending with respect to MPI process number and 1:1, i.e., each index is contained in exactly one IndexSet (among those stored on the different processes), each process stores contiguous subset of indices, and the index set on process starts at the index one larger than the last one stored on process . In case there is only one MPI process, this just means that the IndexSet is complete.
+
Return whether the IndexSets are ascending with respect to MPI process number and 1:1, i.e., each index is contained in exactly one IndexSet (among those stored on the different processes), each process stores contiguous subset of indices, and the index set on process starts at the index one larger than the last one stored on process . In case there is only one MPI process, this just means that the IndexSet is complete.
Remove all elements contained in other from this set. In other words, if is the current object and the argument, then we compute is the current object and the argument, then we compute .
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classIntegratedLegendreSZ.html differs (JavaScript source, ASCII text, with very long lines (541))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classIntegratedLegendreSZ.html 2023-11-25 15:25:56.169965804 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classIntegratedLegendreSZ.html 2023-11-25 15:25:56.173299067 +0100
@@ -225,13 +225,13 @@
Class implementing the integrated Legendre polynomials described in the PhD thesis of Sabine Zaglmayr.
This class was written based upon the existing deal.II Legendre class as a base, but with the coefficients adjusted so that the recursive formula is for the integrated Legendre polynomials described in the PhD thesis of Sabine Zaglmayr. The polynomials can be generated recursively from:
-
(added so that it can be generated recursively from 0)
-
-
-
.
+
(added so that it can be generated recursively from 0)
+
+
+
.
However, it is also possible to generate them directly from the Legendre polynomials:
so that for the Laplace equation. The functions of this class compute a vector of values that corresponds to (i.e., the square root of the quantity above).
+
so that for the Laplace equation. The functions of this class compute a vector of values that corresponds to (i.e., the square root of the quantity above).
In the paper of Ainsworth , but this factor is a bit esoteric, stemming from interpolation estimates and stability constants which may hold for the Poisson problem, but may not hold for more general situations. Alternatively, we consider the case when , where is the diameter of the face and is the maximum polynomial degree of adjacent elements; or . The choice between these factors is done by means of the enumerator, provided as the last argument in all functions.
To perform the integration, use is made of the FEFaceValues and FESubfaceValues classes. The integration is performed by looping over all cells and integrating over faces that are not yet treated. This way we avoid integration on faces twice, once for each time we visit one of the adjacent cells. In a second loop over all cells, we sum up the contributions of the faces (which are the integrated square of the jumps times some factor) of each cell and take the square root.
The integration is done using a quadrature formula on the face provided by the caller of the estimate() functions declared by this class. For linear trial functions (FE_Q(1)), QGauss with two points or even the QMidpoint rule might actually suffice. For higher order elements, it is necessary to utilize higher order quadrature formulae with fe.degree+1 Gauss points.
@@ -180,7 +180,7 @@
-
where is the Neumann boundary function, and for the Kelly and hp-estimator, respectively. If the finite element is vector- valued, then obviously the function denoting the Neumann boundary conditions needs to be vector-valued as well.
+
where is the Neumann boundary function, and for the Kelly and hp-estimator, respectively. If the finite element is vector- valued, then obviously the function denoting the Neumann boundary conditions needs to be vector-valued as well.
@@ -213,8 +213,8 @@
Enumerator
cell_diameter_over_24
Kelly error estimator with the factor .
-
face_diameter_over_twice_max_degree
the boundary residual estimator with the factor .
+
face_diameter_over_twice_max_degree
the boundary residual estimator with the factor .
cell_diameter
Kelly error estimator with the factor .
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classKellyErrorEstimator_3_011_00_01spacedim_01_4.html differs (JavaScript source, ASCII text, with very long lines (1985))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classKellyErrorEstimator_3_011_00_01spacedim_01_4.html 2023-11-25 15:25:56.206631725 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classKellyErrorEstimator_3_011_00_01spacedim_01_4.html 2023-11-25 15:25:56.206631725 +0100
@@ -161,8 +161,8 @@
Enumerator
cell_diameter_over_24&#href_anchor"fielddoc">
Kelly error estimator with the factor .
-
face_diameter_over_twice_max_degree
the boundary residual estimator with the factor .
+
face_diameter_over_twice_max_degree
the boundary residual estimator with the factor .
cell_diameter
Kelly error estimator with the factor .
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classLAPACKFullMatrix.html differs (JavaScript source, ASCII text, with very long lines (851))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classLAPACKFullMatrix.html 2023-11-25 15:25:56.239964379 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classLAPACKFullMatrix.html 2023-11-25 15:25:56.243297642 +0100
@@ -2317,7 +2317,7 @@
Compute eigenvalues and eigenvectors of a real symmetric matrix. Only eigenvalues in the interval are computed with the absolute tolerance . An approximate eigenvalue is accepted as converged when it is determined to lie in an interval of width less than or equal to , where is the machine precision. If is less than or equal to zero, then will be used in its place, where is the 1-norm of the tridiagonal matrix obtained by reducing to tridiagonal form. Eigenvalues will be computed most accurately when is set to twice the underflow threshold, not zero. After this routine has been called, all eigenvalues in , where is the machine precision. If is less than or equal to zero, then will be used in its place, where is the 1-norm of the tridiagonal matrix obtained by reducing to tridiagonal form. Eigenvalues will be computed most accurately when is set to twice the underflow threshold, not zero. After this routine has been called, all eigenvalues in will be stored in eigenvalues and the corresponding eigenvectors will be stored in the columns of eigenvectors, whose dimension is set accordingly.
Note
Calls the LAPACK function Xsyevx.
@@ -2384,8 +2384,8 @@
itype = 2:
itype = 3:
-
where is this matrix. and are assumed to be symmetric, and has to be positive definite. Only eigenvalues in the interval are computed with the absolute tolerance . An approximate eigenvalue is accepted as converged when it is determined to lie in an interval of width less than or equal to , where is the machine precision. If is less than or equal to zero, then will be used in its place, where is the 1-norm of the tridiagonal matrix obtained by reducing to tridiagonal form. Eigenvalues will be computed most accurately when is set to twice the underflow threshold, not zero. After this routine has been called, all eigenvalues in will be stored in eigenvalues and the corresponding eigenvectors will be stored in eigenvectors, whose dimension is set accordingly.
+
where is this matrix. and are assumed to be symmetric, and has to be positive definite. Only eigenvalues in the interval are computed with the absolute tolerance . An approximate eigenvalue is accepted as converged when it is determined to lie in an interval of width less than or equal to , where is the machine precision. If is less than or equal to zero, then will be used in its place, where is the 1-norm of the tridiagonal matrix obtained by reducing to tridiagonal form. Eigenvalues will be computed most accurately when is set to twice the underflow threshold, not zero. After this routine has been called, all eigenvalues in will be stored in eigenvalues and the corresponding eigenvectors will be stored in eigenvectors, whose dimension is set accordingly.
For a singular value decomposition, the inverse is simply computed by replacing all singular values by their reciprocal values. If the matrix does not have maximal rank, singular values 0 are not touched, thus computing the minimal norm right inverse of the matrix.
-
The parameter threshold determines, when a singular value should be considered zero. It is the ratio of the smallest to the largest nonzero singular value . Thus, the inverses of all singular values less than will be set to zero.
+
The parameter threshold determines, when a singular value should be considered zero. It is the ratio of the smallest to the largest nonzero singular value . Thus, the inverses of all singular values less than will be set to zero.
After a call to compute_eigenvalues(), this function returns the matrix of (right) eigenvectors in a decomposition of the form . Note that this function constructs the associated matrix on the fly, since LAPACK packs complex-conjugate eigenvalue/eigenvector pairs of real-valued matrices into a real-valued return matrix. This call only succeeds in case the respective flag right_eigenvectors in compute_eigenvalues() has been set to true.
+
After a call to compute_eigenvalues(), this function returns the matrix of (right) eigenvectors in a decomposition of the form . Note that this function constructs the associated matrix on the fly, since LAPACK packs complex-conjugate eigenvalue/eigenvector pairs of real-valued matrices into a real-valued return matrix. This call only succeeds in case the respective flag right_eigenvectors in compute_eigenvalues() has been set to true.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classLinearAlgebra_1_1ReadWriteVector.html differs (JavaScript source, ASCII text, with very long lines (1069))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classLinearAlgebra_1_1ReadWriteVector.html 2023-11-25 15:25:56.286630096 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classLinearAlgebra_1_1ReadWriteVector.html 2023-11-25 15:25:56.289963360 +0100
@@ -313,7 +313,7 @@
Detailed Description
template<typename Number>
-class LinearAlgebra::ReadWriteVector< Number >
ReadWriteVector is intended to represent vectors in for which it stores all or a subset of elements. The latter case in important in parallel computations, where may be so large that no processor can actually all elements of a solution vector, but where this is also not necessary: one typically only has to store the values of degrees of freedom that live on cells that are locally owned plus potentially those degrees of freedom that live on ghost cells.
+class LinearAlgebra::ReadWriteVector< Number >
ReadWriteVector is intended to represent vectors in for which it stores all or a subset of elements. The latter case in important in parallel computations, where may be so large that no processor can actually all elements of a solution vector, but where this is also not necessary: one typically only has to store the values of degrees of freedom that live on cells that are locally owned plus potentially those degrees of freedom that live on ghost cells.
Most of the time, one will simply read from or write into a vector of the current class using the global numbers of these degrees of freedom. This is done using operator()() or operator[]() which call global_to_local() to transform the global index into a local one. In such cases, it is clear that one can only access elements of the vector that the current object indeed stores.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classLinearAlgebra_1_1distributed_1_1BlockVector.html differs (JavaScript source, ASCII text, with very long lines (1022))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classLinearAlgebra_1_1distributed_1_1BlockVector.html 2023-11-25 15:25:56.319962749 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classLinearAlgebra_1_1distributed_1_1BlockVector.html 2023-11-25 15:25:56.319962749 +0100
@@ -1512,7 +1512,7 @@
-
-norm of the vector. The pth root of the sum of the pth powers of the absolute values of the elements.
+
-norm of the vector. The pth root of the sum of the pth powers of the absolute values of the elements.
@@ -1851,7 +1851,7 @@
-
Calculate the scalar product between each block of this vector and V and store the result in a full matrix matrix. This function computes the result by forming where and indicate the th block (not element!) of and the th block of , respectively. If symmetric is true, it is assumed that inner product results in a square symmetric matrix and almost half of the scalar products can be avoided.
+
Calculate the scalar product between each block of this vector and V and store the result in a full matrix matrix. This function computes the result by forming where and indicate the th block (not element!) of and the th block of , respectively. If symmetric is true, it is assumed that inner product results in a square symmetric matrix and almost half of the scalar products can be avoided.
Obviously, this function can only be used if all blocks of both vectors are of the same size.
Note
Internally, a single global reduction will be called to accumulate scalar product between locally owned degrees of freedom.
@@ -1889,7 +1889,7 @@
-
Calculate the scalar product between each block of this vector and V using a metric tensor matrix. This function computes the result of where and indicate the th block (not element) of and the th block of , respectively. If symmetric is true, it is assumed that and are symmetric matrices and almost half of the scalar products can be avoided.
+
Calculate the scalar product between each block of this vector and V using a metric tensor matrix. This function computes the result of where and indicate the th block (not element) of and the th block of , respectively. If symmetric is true, it is assumed that and are symmetric matrices and almost half of the scalar products can be avoided.
Obviously, this function can only be used if all blocks of both vectors are of the same size.
Note
Internally, a single global reduction will be called to accumulate the scalar product between locally owned degrees of freedom.
@@ -1935,7 +1935,7 @@
-
Set each block of this vector as follows: where and indicate the th block (not element) of and the th block of , respectively.
+
Set each block of this vector as follows: where and indicate the th block (not element) of and the th block of , respectively.
Obviously, this function can only be used if all blocks of both vectors are of the same size.
@@ -2266,7 +2266,7 @@
-
Return the norm of the vector (i.e., the square root of the sum of the square of all entries among all processors).
+
Return the norm of the vector (i.e., the square root of the sum of the square of all entries among all processors).
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classLinearAlgebra_1_1distributed_1_1Vector.html differs (JavaScript source, ASCII text, with very long lines (847))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classLinearAlgebra_1_1distributed_1_1Vector.html 2023-11-25 15:25:56.356628671 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classLinearAlgebra_1_1distributed_1_1Vector.html 2023-11-25 15:25:56.356628671 +0100
@@ -1109,7 +1109,7 @@
Initialize vector with local_size locally-owned and ghost_size ghost degrees of freedoms.
The optional argument comm_sm, which consists of processes on the same shared-memory domain, allows users have read-only access to both locally-owned and ghost values of processes combined in the shared-memory communicator. See the general documentation of this class for more information about this argument.
-
Note
In the created underlying partitioner, the local index range is translated to global indices in an ascending and one-to-one fashion, i.e., the indices of process sit exactly between the indices of the processes and , respectively. Setting the ghost_size variable to an appropriate value provides memory space for the ghost data in a vector's memory allocation as and allows access to it via local_element(). However, the associated global indices must be handled externally in this case.
+
Note
In the created underlying partitioner, the local index range is translated to global indices in an ascending and one-to-one fashion, i.e., the indices of process sit exactly between the indices of the processes and , respectively. Setting the ghost_size variable to an appropriate value provides memory space for the ghost data in a vector's memory allocation as and allows access to it via local_element(). However, the associated global indices must be handled externally in this case.
@@ -1281,7 +1281,7 @@
Initiates communication for the compress() function with non- blocking communication. This function does not wait for the transfer to finish, in order to allow for other computations during the time it takes until all data arrives.
Before the data is actually exchanged, the function must be followed by a call to compress_finish().
-
In case this function is called for more than one vector before compress_finish() is invoked, it is mandatory to specify a unique communication channel to each such call, in order to avoid several messages with the same ID that will corrupt this operation. Any communication channel less than 100 is a valid value (in particular, the range is reserved for LinearAlgebra::distributed::BlockVector).
+
In case this function is called for more than one vector before compress_finish() is invoked, it is mandatory to specify a unique communication channel to each such call, in order to avoid several messages with the same ID that will corrupt this operation. Any communication channel less than 100 is a valid value (in particular, the range is reserved for LinearAlgebra::distributed::BlockVector).
@@ -1327,7 +1327,7 @@
Initiates communication for the update_ghost_values() function with non-blocking communication. This function does not wait for the transfer to finish, in order to allow for other computations during the time it takes until all data arrives.
In case this function is called for more than one vector before update_ghost_values_finish() is invoked, it is mandatory to specify a unique communication channel to each such call, in order to avoid several messages with the same ID that will corrupt this operation. Any communication channel less than 100 is a valid value (in particular, the range is reserved for LinearAlgebra::distributed::BlockVector).
+
In case this function is called for more than one vector before update_ghost_values_finish() is invoked, it is mandatory to specify a unique communication channel to each such call, in order to avoid several messages with the same ID that will corrupt this operation. Any communication channel less than 100 is a valid value (in particular, the range is reserved for LinearAlgebra::distributed::BlockVector).
@@ -2122,7 +2122,7 @@
-
Return the norm of the vector (i.e., the square root of the sum of the square of all entries among all processors).
+
Return the norm of the vector (i.e., the square root of the sum of the square of all entries among all processors).
that store the knowledge how to initialize (resize + internal data structures) an arbitrary vector of the Range and Domain space.
The primary purpose of this class is to provide syntactic sugar for complex matrix-vector operations and free the user from having to create, set up and handle intermediate storage locations by hand.
-
As an example consider the operation , where , and denote (possible different) matrices. In order to construct a LinearOperatorop that stores the knowledge of this operation, one can write:
+
As an example consider the operation , where , and denote (possible different) matrices. In order to construct a LinearOperatorop that stores the knowledge of this operation, one can write:
This class makes heavy use of std::function objects and lambda functions. This flexibility comes with a run-time penalty. Only use this object to encapsulate matrix object of medium to large size (as a rule of thumb, sparse matrices with a size , or larger).
+
Note
This class makes heavy use of std::function objects and lambda functions. This flexibility comes with a run-time penalty. Only use this object to encapsulate matrix object of medium to large size (as a rule of thumb, sparse matrices with a size , or larger).
In order to use Trilinos or PETSc sparse matrices and preconditioners in conjunction with the LinearOperator class, it is necessary to extend the functionality of the LinearOperator class by means of an additional Payload.
For example: LinearOperator instances representing matrix inverses usually require calling some linear solver. These solvers may not have interfaces to the LinearOperator (which, for example, may represent a composite operation). The TrilinosWrappers::internal::LinearOperatorImplementation::TrilinosPayload therefore provides an interface extension to the LinearOperator so that it can be passed to the solver and used by the solver as if it were a Trilinos operator. This implies that all of the necessary functionality of the specific Trilinos operator has been overloaded within the Payload class. This includes operator-vector multiplication and inverse operator-vector multiplication, where the operator can be either a TrilinosWrappers::SparseMatrix or a TrilinosWrappers::PreconditionBase and the vector is a native Trilinos vector.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classManifold.html differs (JavaScript source, ASCII text, with very long lines (2267))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classManifold.html 2023-11-25 15:25:56.396627856 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classManifold.html 2023-11-25 15:25:56.396627856 +0100
@@ -202,11 +202,11 @@
In the most essential use of manifolds, manifold descriptions are used to create a "point between other points". For example, when a triangulation creates a new vertex on a cell, face, or edge, it determines the new vertex' coordinates through the following function call:
Here, points is a collection of points in spacedim dimension, and a collection of corresponding weights. The points in this context will then be the vertices of the cell, face, or edge, and the weights are typically one over the number of points when a new midpoint of the cell, face, or edge is needed. Derived classes then will implement the Manifold::get_new_point() function in a way that computes the location of this new point. In the simplest case, for example in the FlatManifold class, the function simply computes the arithmetic average (with given weights) of the given points. However, other classes do something differently; for example, the SphericalManifold class, which is used to describe domains that form (part of) the sphere, will ensure that, given the two vertices of an edge at the boundary, the new returned point will lie on the grand circle that connects the two points, rather than choosing a point that is half-way between the two points in .
+
Here, points is a collection of points in spacedim dimension, and a collection of corresponding weights. The points in this context will then be the vertices of the cell, face, or edge, and the weights are typically one over the number of points when a new midpoint of the cell, face, or edge is needed. Derived classes then will implement the Manifold::get_new_point() function in a way that computes the location of this new point. In the simplest case, for example in the FlatManifold class, the function simply computes the arithmetic average (with given weights) of the given points. However, other classes do something differently; for example, the SphericalManifold class, which is used to describe domains that form (part of) the sphere, will ensure that, given the two vertices of an edge at the boundary, the new returned point will lie on the grand circle that connects the two points, rather than choosing a point that is half-way between the two points in .
Note
Unlike almost all other cases in the library, we here interpret the points to be in real space, not on the reference cell.
Manifold::get_new_point() has a default implementation that can simplify this process somewhat: Internally, the function calls the Manifold::get_intermediate_point() to compute pair-wise intermediate points. Internally the Manifold::get_intermediate_point() calls the Manifold::project_to_manifold() function after computing the convex combination of the given points. This allows derived classes to only overload Manifold::project_to_manifold() for simple situations. This is often useful when describing manifolds that are embedded in higher dimensional space, e.g., the surface of a sphere. In those cases, the desired new point may be computed simply by the (weighted) average of the provided points, projected back out onto the sphere.
Common use case: Computing tangent vectors
-
The second use of this class is in computing directions on domains and boundaries. For example, we may need to compute the normal vector to a face in order to impose the no-flow boundary condition (see the VectorTools::compute_no_normal_flux_constraints() as an example). Similarly, we may need normal vectors in the computation of the normal component of the gradient of the numerical solution in order to compute the jump in the gradient of the solution in error estimators (see, for example, the KellyErrorEstimator class).
+
The second use of this class is in computing directions on domains and boundaries. For example, we may need to compute the normal vector to a face in order to impose the no-flow boundary condition (see the VectorTools::compute_no_normal_flux_constraints() as an example). Similarly, we may need normal vectors in the computation of the normal component of the gradient of the numerical solution in order to compute the jump in the gradient of the solution in error estimators (see, for example, the KellyErrorEstimator class).
To make this possible, the Manifold class provides a member function (to be implemented by derived classes) that computes a "vector tangent
to the manifold at one point, in direction of another point" via the Manifold::get_tangent_vector() function. For example, in 2d, one would use this function with the two vertices of an edge at the boundary to compute a "tangential" vector along the edge, and then get the normal vector by rotation by 90 degrees. In 3d, one would compute the two vectors "tangential" to the two edges of a boundary face adjacent to a boundary vertex, and then take the cross product of these two to obtain a vector normal to the boundary.
For reasons that are more difficult to understand, these direction vectors are normalized in a very specific way, rather than to have unit norm. See the documentation of Manifold::get_tangent_vector(), as well as below, for more information.
@@ -214,11 +214,11 @@
A unified description
The "real" way to understand what this class does is to see it in the framework of differential geometry. More specifically, differential geometry is fundamentally based on the assumption that two sufficiently close points are connected via a line of "shortest distance". This line is called a "geodesic", and it is selected from all other lines that connect the two points by the property that it is shortest if distances are measured in terms of the "metric" that describes a manifold. To give examples, recall that the geodesics of a flat manifold (implemented in the FlatManifold class) are simply the straight lines connecting two points, whereas for spherical manifolds (see the SphericalManifold class) geodesics between two points of same distance are the grand circles, and are in general curved lines when connecting two lines of different distance from the origin.
In the following discussion, and for the purposes of implementing the current class, the concept of "metrics" that is so fundamental to differential geometry is no longer of great importance to us. Rather, everything can simply be described by postulating the existence of geodesics connecting points on a manifold.
-
Given geodesics, the operations discussed in the previous two sections can be described in a more formal way. In essence, they rely on the fact that we can assume that a geodesic is parameterized by a "time" like variable so that describes the curve and so that is the location of the first and the location of the second point. Furthermore, traces out the geodesic at constant speed, covering equal distance in equal time (as measured by the metric). Note that this parameterization uses time, not arc length to denote progress along the geodesic.
-
In this picture, computing a mid-point between points and , with weights and , simply requires computing the point . Computing a new point as a weighted average of more than two points can be done by considering pairwise geodesics, finding suitable points on the geodetic between the first two points, then on the geodetic between this new point and the third given point, etc.
-
Likewise, the "tangential" vector described above is simply the velocity vector, , evaluated at one of the end points of a geodesic (i.e., at or ). In the case of a flat manifold, the geodesic is simply the straight line connecting two points, and the velocity vector is just the connecting vector in that case. On the other hand, for two points on a spherical manifold, the geodesic is a grand circle, and the velocity vector is tangent to the spherical surface.
-
Note that if we wanted to, we could use this to compute the length of the geodesic that connects two points and by computing along the geodesic that connects them, but this operation will not be of use to us in practice. One could also conceive computing the direction vector using the "new point" operation above, using the formula where all we need to do is compute the new point with weights and along the geodesic connecting and . The default implementation of the function does this, by evaluating the quotient for a small but finite weight . In practice, however, it is almost always possible to explicitly compute the direction vector, i.e., without the need to numerically approximate the limit process, and derived classes should do so.
+
Given geodesics, the operations discussed in the previous two sections can be described in a more formal way. In essence, they rely on the fact that we can assume that a geodesic is parameterized by a "time" like variable so that describes the curve and so that is the location of the first and the location of the second point. Furthermore, traces out the geodesic at constant speed, covering equal distance in equal time (as measured by the metric). Note that this parameterization uses time, not arc length to denote progress along the geodesic.
+
In this picture, computing a mid-point between points and , with weights and , simply requires computing the point . Computing a new point as a weighted average of more than two points can be done by considering pairwise geodesics, finding suitable points on the geodetic between the first two points, then on the geodetic between this new point and the third given point, etc.
+
Likewise, the "tangential" vector described above is simply the velocity vector, , evaluated at one of the end points of a geodesic (i.e., at or ). In the case of a flat manifold, the geodesic is simply the straight line connecting two points, and the velocity vector is just the connecting vector in that case. On the other hand, for two points on a spherical manifold, the geodesic is a grand circle, and the velocity vector is tangent to the spherical surface.
+
Note that if we wanted to, we could use this to compute the length of the geodesic that connects two points and by computing along the geodesic that connects them, but this operation will not be of use to us in practice. One could also conceive computing the direction vector using the "new point" operation above, using the formula where all we need to do is compute the new point with weights and along the geodesic connecting and . The default implementation of the function does this, by evaluating the quotient for a small but finite weight . In practice, however, it is almost always possible to explicitly compute the direction vector, i.e., without the need to numerically approximate the limit process, and derived classes should do so.
Return a vector that, at , is tangential to the geodesic that connects two points . The geodesic is the shortest line between these two points, where "shortest" is defined via a metric specific to a particular implementation of this class in a derived class. For example, in the case of a FlatManifold, the shortest line between two points is just the straight line, and in this case the tangent vector is just the difference . On the other hand, for a manifold that describes a surface embedded in a higher dimensional space (e.g., the surface of a sphere), then the tangent vector is tangential to the surface, and consequently may point in a different direction than the straight line that connects the two points.
-
While tangent vectors are often normalized to unit length, the vectors returned by this function are normalized as described in the introduction of this class. Specifically, if traces out the geodesic between the two points where and , then the returned vector must equal . In other words, the norm of the returned vector also encodes, in some sense, the length of the geodesic because a curve must move "faster" if the two points it connects between arguments and are farther apart.
-
The default implementation of this function approximates for a small value of , and the evaluation of is done by calling get_new_point(). If possible, derived classes should override this function by an implementation of the exact derivative.
+
Return a vector that, at , is tangential to the geodesic that connects two points . The geodesic is the shortest line between these two points, where "shortest" is defined via a metric specific to a particular implementation of this class in a derived class. For example, in the case of a FlatManifold, the shortest line between two points is just the straight line, and in this case the tangent vector is just the difference . On the other hand, for a manifold that describes a surface embedded in a higher dimensional space (e.g., the surface of a sphere), then the tangent vector is tangential to the surface, and consequently may point in a different direction than the straight line that connects the two points.
+
While tangent vectors are often normalized to unit length, the vectors returned by this function are normalized as described in the introduction of this class. Specifically, if traces out the geodesic between the two points where and , then the returned vector must equal . In other words, the norm of the returned vector also encodes, in some sense, the length of the geodesic because a curve must move "faster" if the two points it connects between arguments and are farther apart.
+
The default implementation of this function approximates for a small value of , and the evaluation of is done by calling get_new_point(). If possible, derived classes should override this function by an implementation of the exact derivative.
Parameters
x1
The first point that describes the geodesic, and the one at which the "direction" is to be evaluated.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classMapping.html differs (JavaScript source, ASCII text, with very long lines (1165))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classMapping.html 2023-11-25 15:25:56.423293982 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classMapping.html 2023-11-25 15:25:56.423293982 +0100
@@ -228,84 +228,84 @@
class Mapping< dim, spacedim >
Abstract base class for mapping classes.
This class declares the interface for the functionality to describe mappings from the reference (unit) cell to a cell in real space, as well as for filling the information necessary to use the FEValues, FEFaceValues, and FESubfaceValues classes. Concrete implementations of these interfaces are provided in derived classes.
Mathematics of the mapping
-
The mapping is a transformation which maps points in the reference cell to points in the actual grid cell . Many of the applications of such mappings require the Jacobian of this mapping, . For instance, if dim=spacedim=2, we have
- which maps points in the reference cell to points in the actual grid cell . Many of the applications of such mappings require the Jacobian of this mapping, . For instance, if dim=spacedim=2, we have
+
+\]" src="form_1265.png"/>
Mapping of scalar functions
The shape functions of scalar finite elements are typically defined on a reference cell and are then simply mapped according to the rule
-
+\]" src="form_1266.png"/>
Mapping of integrals
-
Using simply a change of variables, integrals of scalar functions over a cell can be expressed as an integral over the reference cell . Specifically, The volume form is transformed so that
- can be expressed as an integral over the reference cell . Specifically, The volume form is transformed so that
+
+\]" src="form_1268.png"/>
In expressions where such integrals are approximated by quadrature, this then leads to terms of the form
-
+\]" src="form_1269.png"/>
-
Here, the weights of each quadrature point (where JxW mnemonically stands for Jacobian times Quadrature Weights) take the role of the in the original integral. Consequently, they appear in all code that computes integrals approximated by quadrature, and are accessed by FEValues::JxW().
+
Here, the weights of each quadrature point (where JxW mnemonically stands for Jacobian times Quadrature Weights) take the role of the in the original integral. Consequently, they appear in all code that computes integrals approximated by quadrature, and are accessed by FEValues::JxW().
Mapping of vector fields, differential forms and gradients of vector fields
The transformation of vector fields or differential forms (gradients of scalar functions) , and gradients of vector fields follows the general form
-
+\]" src="form_1272.png"/>
The differential forms A and B are determined by the kind of object being transformed. These transformations are performed through the transform() functions, and the type of object being transformed is specified by their MappingKind argument. See the documentation there for possible choices.
Derivatives of the mapping
-
Some applications require the derivatives of the mapping, of which the first order derivative is the mapping Jacobian, , described above. Higher order derivatives of the mapping are similarly defined, for example the Jacobian derivative, , and the Jacobian second derivative, . It is also useful to define the "pushed-forward" versions of the higher order derivatives: the Jacobian pushed-forward derivative, , described above. Higher order derivatives of the mapping are similarly defined, for example the Jacobian derivative, , and the Jacobian second derivative, . It is also useful to define the "pushed-forward" versions of the higher order derivatives: the Jacobian pushed-forward derivative, , and the Jacobian pushed-forward second derivative, , and the Jacobian pushed-forward second derivative, . These pushed-forward versions can be used to compute the higher order derivatives of functions defined on the reference cell with respect to the real cell coordinates. For instance, the Jacobian derivative with respect to the real cell coordinates is given by:
+x_L}(J_{jJ})^{-1}(J_{kK})^{-1}(J_{lL})^{-1}$" src="form_1277.png"/>. These pushed-forward versions can be used to compute the higher order derivatives of functions defined on the reference cell with respect to the real cell coordinates. For instance, the Jacobian derivative with respect to the real cell coordinates is given by:
-
+\]" src="form_1278.png"/>
and the derivative of the Jacobian inverse with respect to the real cell coordinates is similarly given by:
-
+\]" src="form_1279.png"/>
In a similar fashion, higher order derivatives, with respect to the real cell coordinates, of functions defined on the reference cell can be defined using the Jacobian pushed-forward higher-order derivatives. For example, the derivative, with respect to the real cell coordinates, of the Jacobian pushed-forward derivative is given by:
-
+\]" src="form_1280.png"/>
References
A general publication on differential geometry and finite elements is the survey
@@ -1089,10 +1089,10 @@
Compute information about the mapping from the reference cell to the real cell indicated by the first argument to this function. Derived classes will have to implement this function based on the kind of mapping they represent. It is called by FEValues::reinit().
-
Conceptually, this function's represents the application of the mapping from reference coordinates to real space coordinates for a given cell . Its purpose is to compute the following kinds of data:
+
Conceptually, this function's represents the application of the mapping from reference coordinates to real space coordinates for a given cell . Its purpose is to compute the following kinds of data:
-
Data that results from the application of the mapping itself, e.g., computing the location of quadrature points on the real cell, and that is directly useful to users of FEValues, for example during assembly.
-
Data that is necessary for finite element implementations to compute their shape functions on the real cell. To this end, the FEValues::reinit() function calls FiniteElement::fill_fe_values() after the current function, and the output of this function serves as input to FiniteElement::fill_fe_values(). Examples of information that needs to be computed here for use by the finite element classes is the Jacobian of the mapping, or its inverse, for example to transform the gradients of shape functions on the reference cell to the gradients of shape functions on the real cell.
+
Data that results from the application of the mapping itself, e.g., computing the location of quadrature points on the real cell, and that is directly useful to users of FEValues, for example during assembly.
+
Data that is necessary for finite element implementations to compute their shape functions on the real cell. To this end, the FEValues::reinit() function calls FiniteElement::fill_fe_values() after the current function, and the output of this function serves as input to FiniteElement::fill_fe_values(). Examples of information that needs to be computed here for use by the finite element classes is the Jacobian of the mapping, or its inverse, for example to transform the gradients of shape functions on the reference cell to the gradients of shape functions on the real cell.
The information computed by this function is used to fill the various member variables of the output argument of this function. Which of the member variables of that structure should be filled is determined by the update flags stored in the Mapping::InternalDataBase object passed to this function.
The mapping kinds currently implemented by derived classes are:
mapping_contravariant: maps a vector field on the reference cell to the physical cell through the Jacobian:
-
+\]" src="form_1285.png"/>
In physics, this is usually referred to as the contravariant transformation. Mathematically, it is the push forward of a vector field.
mapping_covariant: maps a field of one-forms on the reference cell to a field of one-forms on the physical cell. (Theoretically this would refer to a DerivativeForm<1,dim,1> but we canonically identify this type with a Tensor<1,dim>). Mathematically, it is the pull back of the differential form
-
+\]" src="form_1286.png"/>
Gradients of scalar differentiable functions are transformed this way.
In the case when dim=spacedim the previous formula reduces to
-
+\]" src="form_1287.png"/>
because we assume that the mapping is always invertible, and consequently its Jacobian is an invertible matrix.
mapping_piola: A field of dim-1-forms on the reference cell is also represented by a vector field, but again transforms differently, namely by the Piola transform
-
+\]" src="form_1288.png"/>
@@ -1489,21 +1489,21 @@
-
Transform a field of differential forms from the reference cell to the physical cell. It is useful to think of and , with a vector field. The mapping kinds currently implemented by derived classes are:
+
Transform a field of differential forms from the reference cell to the physical cell. It is useful to think of and , with a vector field. The mapping kinds currently implemented by derived classes are:
mapping_covariant: maps a field of forms on the reference cell to a field of forms on the physical cell. Mathematically, it is the pull back of the differential form
-
+\]" src="form_1291.png"/>
Jacobians of spacedim-vector valued differentiable functions are transformed this way.
In the case when dim=spacedim the previous formula reduces to
-
+\]" src="form_1292.png"/>
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classMappingC1.html differs (JavaScript source, ASCII text, with very long lines (1098))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classMappingC1.html 2023-11-25 15:25:56.453293371 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classMappingC1.html 2023-11-25 15:25:56.453293371 +0100
@@ -866,37 +866,37 @@
The mapping kinds currently implemented by derived classes are:
mapping_contravariant: maps a vector field on the reference cell to the physical cell through the Jacobian:
-
+\]" src="form_1285.png"/>
In physics, this is usually referred to as the contravariant transformation. Mathematically, it is the push forward of a vector field.
mapping_covariant: maps a field of one-forms on the reference cell to a field of one-forms on the physical cell. (Theoretically this would refer to a DerivativeForm<1,dim,1> but we canonically identify this type with a Tensor<1,dim>). Mathematically, it is the pull back of the differential form
-
+\]" src="form_1286.png"/>
Gradients of scalar differentiable functions are transformed this way.
In the case when dim=spacedim the previous formula reduces to
-
+\]" src="form_1287.png"/>
because we assume that the mapping is always invertible, and consequently its Jacobian is an invertible matrix.
mapping_piola: A field of dim-1-forms on the reference cell is also represented by a vector field, but again transforms differently, namely by the Piola transform
-
+\]" src="form_1288.png"/>
@@ -960,21 +960,21 @@
-
Transform a field of differential forms from the reference cell to the physical cell. It is useful to think of and , with a vector field. The mapping kinds currently implemented by derived classes are:
+
Transform a field of differential forms from the reference cell to the physical cell. It is useful to think of and , with a vector field. The mapping kinds currently implemented by derived classes are:
mapping_covariant: maps a field of forms on the reference cell to a field of forms on the physical cell. Mathematically, it is the pull back of the differential form
-
+\]" src="form_1291.png"/>
Jacobians of spacedim-vector valued differentiable functions are transformed this way.
In the case when dim=spacedim the previous formula reduces to
-
+\]" src="form_1292.png"/>
@@ -1041,35 +1041,35 @@
Transform a tensor field from the reference cell to the physical cell. These tensors are usually the Jacobians in the reference cell of vector fields that have been pulled back from the physical cell. The mapping kinds currently implemented by derived classes are:
-mapping_contravariant_gradient: it assumes so that
- so that
+
+\]" src="form_1294.png"/>
-mapping_covariant_gradient: it assumes so that
- so that
+
+\]" src="form_1296.png"/>
-mapping_piola_gradient: it assumes so that
- so that
+
+\]" src="form_1298.png"/>
@@ -1138,21 +1138,21 @@
The mapping kinds currently implemented by derived classes are:
mapping_covariant_gradient: maps a field of forms on the reference cell to a field of forms on the physical cell. Mathematically, it is the pull back of the differential form
Hessians of spacedim-vector valued differentiable functions are transformed this way (After subtraction of the product of the derivative with the Jacobian gradient).
In the case when dim=spacedim the previous formula reduces to
-
+
Parameters
@@ -1214,40 +1214,40 @@
-
Transform a field of 3-differential forms from the reference cell to the physical cell. It is useful to think of and , with a vector field.
+
Transform a field of 3-differential forms from the reference cell to the physical cell. It is useful to think of and , with a vector field.
The mapping kinds currently implemented by derived classes are:
-mapping_contravariant_hessian: it assumes so that
- so that
+
+\]" src="form_1306.png"/>
-mapping_covariant_hessian: it assumes so that
- so that
+
+\]" src="form_1308.png"/>
-mapping_piola_hessian: it assumes so that
- so that
+
Detailed Description
template<int dim, int spacedim = dim>
class MappingCartesian< dim, spacedim >
A class providing a mapping from the reference cell to cells that are axiparallel, i.e., that have the shape of rectangles (in 2d) or boxes (in 3d) with edges parallel to the coordinate directions. The class therefore provides functionality that is equivalent to what, for example, MappingQ would provide for such cells. However, knowledge of the shape of cells allows this class to be substantially more efficient.
-
Specifically, the mapping is meant for cells for which the mapping from the reference to the real cell is a scaling along the coordinate directions: The transformation from reference coordinates to real coordinates on each cell is of the form
- to real coordinates on each cell is of the form
+
+\end{align*}" src="form_1312.png"/>
in 2d, and
-
+\end{align*}" src="form_1313.png"/>
-
in 3d, where is the bottom left vertex and are the extents of the cell along the axes.
+
in 3d, where is the bottom left vertex and are the extents of the cell along the axes.
The class is intended for efficiency, and it does not do a whole lot of error checking. If you apply this mapping to a cell that does not conform to the requirements above, you will get strange results.
The mapping kinds currently implemented by derived classes are:
mapping_contravariant: maps a vector field on the reference cell to the physical cell through the Jacobian:
-
+\]" src="form_1285.png"/>
In physics, this is usually referred to as the contravariant transformation. Mathematically, it is the push forward of a vector field.
mapping_covariant: maps a field of one-forms on the reference cell to a field of one-forms on the physical cell. (Theoretically this would refer to a DerivativeForm<1,dim,1> but we canonically identify this type with a Tensor<1,dim>). Mathematically, it is the pull back of the differential form
-
+\]" src="form_1286.png"/>
Gradients of scalar differentiable functions are transformed this way.
In the case when dim=spacedim the previous formula reduces to
-
+\]" src="form_1287.png"/>
because we assume that the mapping is always invertible, and consequently its Jacobian is an invertible matrix.
mapping_piola: A field of dim-1-forms on the reference cell is also represented by a vector field, but again transforms differently, namely by the Piola transform
-
+\]" src="form_1288.png"/>
@@ -638,21 +638,21 @@
-
Transform a field of differential forms from the reference cell to the physical cell. It is useful to think of and , with a vector field. The mapping kinds currently implemented by derived classes are:
+
Transform a field of differential forms from the reference cell to the physical cell. It is useful to think of and , with a vector field. The mapping kinds currently implemented by derived classes are:
mapping_covariant: maps a field of forms on the reference cell to a field of forms on the physical cell. Mathematically, it is the pull back of the differential form
-
+\]" src="form_1291.png"/>
Jacobians of spacedim-vector valued differentiable functions are transformed this way.
In the case when dim=spacedim the previous formula reduces to
-
+\]" src="form_1292.png"/>
@@ -719,35 +719,35 @@
Transform a tensor field from the reference cell to the physical cell. These tensors are usually the Jacobians in the reference cell of vector fields that have been pulled back from the physical cell. The mapping kinds currently implemented by derived classes are:
-mapping_contravariant_gradient: it assumes so that
- so that
+
+\]" src="form_1294.png"/>
-mapping_covariant_gradient: it assumes so that
- so that
+
+\]" src="form_1296.png"/>
-mapping_piola_gradient: it assumes so that
- so that
+
+\]" src="form_1298.png"/>
@@ -816,21 +816,21 @@
The mapping kinds currently implemented by derived classes are:
mapping_covariant_gradient: maps a field of forms on the reference cell to a field of forms on the physical cell. Mathematically, it is the pull back of the differential form
Hessians of spacedim-vector valued differentiable functions are transformed this way (After subtraction of the product of the derivative with the Jacobian gradient).
In the case when dim=spacedim the previous formula reduces to
-
+
Parameters
@@ -892,40 +892,40 @@
-
Transform a field of 3-differential forms from the reference cell to the physical cell. It is useful to think of and , with a vector field.
+
Transform a field of 3-differential forms from the reference cell to the physical cell. It is useful to think of and , with a vector field.
The mapping kinds currently implemented by derived classes are:
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classMappingFE.html differs (JavaScript source, ASCII text, with very long lines (1099))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classMappingFE.html 2023-11-25 15:25:56.506625620 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classMappingFE.html 2023-11-25 15:25:56.506625620 +0100
@@ -639,37 +639,37 @@
The mapping kinds currently implemented by derived classes are:
mapping_contravariant: maps a vector field on the reference cell to the physical cell through the Jacobian:
-
+\]" src="form_1285.png"/>
In physics, this is usually referred to as the contravariant transformation. Mathematically, it is the push forward of a vector field.
mapping_covariant: maps a field of one-forms on the reference cell to a field of one-forms on the physical cell. (Theoretically this would refer to a DerivativeForm<1,dim,1> but we canonically identify this type with a Tensor<1,dim>). Mathematically, it is the pull back of the differential form
-
+\]" src="form_1286.png"/>
Gradients of scalar differentiable functions are transformed this way.
In the case when dim=spacedim the previous formula reduces to
-
+\]" src="form_1287.png"/>
because we assume that the mapping is always invertible, and consequently its Jacobian is an invertible matrix.
mapping_piola: A field of dim-1-forms on the reference cell is also represented by a vector field, but again transforms differently, namely by the Piola transform
-
+\]" src="form_1288.png"/>
@@ -733,21 +733,21 @@
-
Transform a field of differential forms from the reference cell to the physical cell. It is useful to think of and , with a vector field. The mapping kinds currently implemented by derived classes are:
+
Transform a field of differential forms from the reference cell to the physical cell. It is useful to think of and , with a vector field. The mapping kinds currently implemented by derived classes are:
mapping_covariant: maps a field of forms on the reference cell to a field of forms on the physical cell. Mathematically, it is the pull back of the differential form
-
+\]" src="form_1291.png"/>
Jacobians of spacedim-vector valued differentiable functions are transformed this way.
In the case when dim=spacedim the previous formula reduces to
-
+\]" src="form_1292.png"/>
@@ -814,35 +814,35 @@
Transform a tensor field from the reference cell to the physical cell. These tensors are usually the Jacobians in the reference cell of vector fields that have been pulled back from the physical cell. The mapping kinds currently implemented by derived classes are:
-mapping_contravariant_gradient: it assumes so that
- so that
+
+\]" src="form_1294.png"/>
-mapping_covariant_gradient: it assumes so that
- so that
+
+\]" src="form_1296.png"/>
-mapping_piola_gradient: it assumes so that
- so that
+
+\]" src="form_1298.png"/>
@@ -911,21 +911,21 @@
The mapping kinds currently implemented by derived classes are:
mapping_covariant_gradient: maps a field of forms on the reference cell to a field of forms on the physical cell. Mathematically, it is the pull back of the differential form
Hessians of spacedim-vector valued differentiable functions are transformed this way (After subtraction of the product of the derivative with the Jacobian gradient).
In the case when dim=spacedim the previous formula reduces to
-
+
Parameters
@@ -987,40 +987,40 @@
-
Transform a field of 3-differential forms from the reference cell to the physical cell. It is useful to think of and , with a vector field.
+
Transform a field of 3-differential forms from the reference cell to the physical cell. It is useful to think of and , with a vector field.
The mapping kinds currently implemented by derived classes are:
-mapping_contravariant_hessian: it assumes so that
- so that
+
+\]" src="form_1306.png"/>
-mapping_covariant_hessian: it assumes so that
- so that
+
+\]" src="form_1308.png"/>
-mapping_piola_hessian: it assumes so that
- so that
+mapping_contravariant: maps a vector field on the reference cell to the physical cell through the Jacobian:
-
+\]" src="form_1285.png"/>
In physics, this is usually referred to as the contravariant transformation. Mathematically, it is the push forward of a vector field.
mapping_covariant: maps a field of one-forms on the reference cell to a field of one-forms on the physical cell. (Theoretically this would refer to a DerivativeForm<1,dim,1> but we canonically identify this type with a Tensor<1,dim>). Mathematically, it is the pull back of the differential form
-
+\]" src="form_1286.png"/>
Gradients of scalar differentiable functions are transformed this way.
In the case when dim=spacedim the previous formula reduces to
-
+\]" src="form_1287.png"/>
because we assume that the mapping is always invertible, and consequently its Jacobian is an invertible matrix.
mapping_piola: A field of dim-1-forms on the reference cell is also represented by a vector field, but again transforms differently, namely by the Piola transform
-
+\]" src="form_1288.png"/>
@@ -805,21 +805,21 @@
-
Transform a field of differential forms from the reference cell to the physical cell. It is useful to think of and , with a vector field. The mapping kinds currently implemented by derived classes are:
+
Transform a field of differential forms from the reference cell to the physical cell. It is useful to think of and , with a vector field. The mapping kinds currently implemented by derived classes are:
mapping_covariant: maps a field of forms on the reference cell to a field of forms on the physical cell. Mathematically, it is the pull back of the differential form
-
+\]" src="form_1291.png"/>
Jacobians of spacedim-vector valued differentiable functions are transformed this way.
In the case when dim=spacedim the previous formula reduces to
-
+\]" src="form_1292.png"/>
@@ -886,35 +886,35 @@
Transform a tensor field from the reference cell to the physical cell. These tensors are usually the Jacobians in the reference cell of vector fields that have been pulled back from the physical cell. The mapping kinds currently implemented by derived classes are:
-mapping_contravariant_gradient: it assumes so that
- so that
+
+\]" src="form_1294.png"/>
-mapping_covariant_gradient: it assumes so that
- so that
+
+\]" src="form_1296.png"/>
-mapping_piola_gradient: it assumes so that
- so that
+
+\]" src="form_1298.png"/>
@@ -983,21 +983,21 @@
The mapping kinds currently implemented by derived classes are:
mapping_covariant_gradient: maps a field of forms on the reference cell to a field of forms on the physical cell. Mathematically, it is the pull back of the differential form
Hessians of spacedim-vector valued differentiable functions are transformed this way (After subtraction of the product of the derivative with the Jacobian gradient).
In the case when dim=spacedim the previous formula reduces to
-
+
Parameters
@@ -1059,40 +1059,40 @@
-
Transform a field of 3-differential forms from the reference cell to the physical cell. It is useful to think of and , with a vector field.
+
Transform a field of 3-differential forms from the reference cell to the physical cell. It is useful to think of and , with a vector field.
The mapping kinds currently implemented by derived classes are:
-mapping_contravariant_hessian: it assumes so that
- so that
+
+\]" src="form_1306.png"/>
-mapping_covariant_hessian: it assumes so that
- so that
+
+\]" src="form_1308.png"/>
-mapping_piola_hessian: it assumes so that
- so that
+
-
Tensors of contravariant transformation at each of the quadrature points. The contravariant matrix is the Jacobian of the transformation, i.e. .
+
Tensors of contravariant transformation at each of the quadrature points. The contravariant matrix is the Jacobian of the transformation, i.e. .
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classMappingManifold.html differs (JavaScript source, ASCII text, with very long lines (1105))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classMappingManifold.html 2023-11-25 15:25:56.593290523 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classMappingManifold.html 2023-11-25 15:25:56.593290523 +0100
@@ -560,37 +560,37 @@
The mapping kinds currently implemented by derived classes are:
mapping_contravariant: maps a vector field on the reference cell to the physical cell through the Jacobian:
-
+\]" src="form_1285.png"/>
In physics, this is usually referred to as the contravariant transformation. Mathematically, it is the push forward of a vector field.
mapping_covariant: maps a field of one-forms on the reference cell to a field of one-forms on the physical cell. (Theoretically this would refer to a DerivativeForm<1,dim,1> but we canonically identify this type with a Tensor<1,dim>). Mathematically, it is the pull back of the differential form
-
+\]" src="form_1286.png"/>
Gradients of scalar differentiable functions are transformed this way.
In the case when dim=spacedim the previous formula reduces to
-
+\]" src="form_1287.png"/>
because we assume that the mapping is always invertible, and consequently its Jacobian is an invertible matrix.
mapping_piola: A field of dim-1-forms on the reference cell is also represented by a vector field, but again transforms differently, namely by the Piola transform
-
+\]" src="form_1288.png"/>
@@ -654,21 +654,21 @@
-
Transform a field of differential forms from the reference cell to the physical cell. It is useful to think of and , with a vector field. The mapping kinds currently implemented by derived classes are:
+
Transform a field of differential forms from the reference cell to the physical cell. It is useful to think of and , with a vector field. The mapping kinds currently implemented by derived classes are:
mapping_covariant: maps a field of forms on the reference cell to a field of forms on the physical cell. Mathematically, it is the pull back of the differential form
-
+\]" src="form_1291.png"/>
Jacobians of spacedim-vector valued differentiable functions are transformed this way.
In the case when dim=spacedim the previous formula reduces to
-
+\]" src="form_1292.png"/>
@@ -735,35 +735,35 @@
Transform a tensor field from the reference cell to the physical cell. These tensors are usually the Jacobians in the reference cell of vector fields that have been pulled back from the physical cell. The mapping kinds currently implemented by derived classes are:
-mapping_contravariant_gradient: it assumes so that
- so that
+
+\]" src="form_1294.png"/>
-mapping_covariant_gradient: it assumes so that
- so that
+
+\]" src="form_1296.png"/>
-mapping_piola_gradient: it assumes so that
- so that
+
+\]" src="form_1298.png"/>
@@ -832,21 +832,21 @@
The mapping kinds currently implemented by derived classes are:
mapping_covariant_gradient: maps a field of forms on the reference cell to a field of forms on the physical cell. Mathematically, it is the pull back of the differential form
Hessians of spacedim-vector valued differentiable functions are transformed this way (After subtraction of the product of the derivative with the Jacobian gradient).
In the case when dim=spacedim the previous formula reduces to
-
+
Parameters
@@ -908,40 +908,40 @@
-
Transform a field of 3-differential forms from the reference cell to the physical cell. It is useful to think of and , with a vector field.
+
Transform a field of 3-differential forms from the reference cell to the physical cell. It is useful to think of and , with a vector field.
The mapping kinds currently implemented by derived classes are:
-mapping_contravariant_hessian: it assumes so that
- so that
+
+\]" src="form_1306.png"/>
-mapping_covariant_hessian: it assumes so that
- so that
+
+\]" src="form_1308.png"/>
-mapping_piola_hessian: it assumes so that
- so that
+
-
A vector of weights for use in Manifold::get_new_point(). For each point (interior to a cell), we compute the weight each vertex has for this point. If the point lies at a vertex, then this vertex has weight one and all others have weight zero. If the point lies interior to a cell, then the weight every vertex has is just the -linear shape functions associated with each vertex evaluated at that point.
+
A vector of weights for use in Manifold::get_new_point(). For each point (interior to a cell), we compute the weight each vertex has for this point. If the point lies at a vertex, then this vertex has weight one and all others have weight zero. If the point lies interior to a cell, then the weight every vertex has is just the -linear shape functions associated with each vertex evaluated at that point.
This class implements the functionality for polynomial mappings of polynomial degree that will be used on all cells of the mesh. In order to get a genuine higher-order mapping for all cells, it is important to provide information about how interior edges and faces of the mesh should be curved. This is typically done by associating a Manifold with interior cells and edges. A simple example of this is discussed in the "Results" section of step-6; a full discussion of manifolds is provided in step-53. If manifolds are only attached to the boundaries of a domain, the current class with higher polynomial degrees will provide the same information as a mere MappingQ1 object. If you are working on meshes that describe a (curved) manifold embedded in higher space dimensions, i.e., if dim!=spacedim, then every cell is at the boundary of the domain you will likely already have attached a manifold object to all cells that can then also be used by the mapping classes for higher order mappings.
+class MappingQ< dim, spacedim >
This class implements the functionality for polynomial mappings of polynomial degree that will be used on all cells of the mesh. In order to get a genuine higher-order mapping for all cells, it is important to provide information about how interior edges and faces of the mesh should be curved. This is typically done by associating a Manifold with interior cells and edges. A simple example of this is discussed in the "Results" section of step-6; a full discussion of manifolds is provided in step-53. If manifolds are only attached to the boundaries of a domain, the current class with higher polynomial degrees will provide the same information as a mere MappingQ1 object. If you are working on meshes that describe a (curved) manifold embedded in higher space dimensions, i.e., if dim!=spacedim, then every cell is at the boundary of the domain you will likely already have attached a manifold object to all cells that can then also be used by the mapping classes for higher order mappings.
Behavior along curved boundaries and with different manifolds
For a number of applications, one only knows a manifold description of a surface but not the interior of the computational domain. In such a case, a FlatManifold object will be assigned to the interior entities that describes a usual planar coordinate system where the additional points for the higher order mapping are placed exactly according to a bi-/trilinear mapping. When combined with a non-flat manifold on the boundary, for example a circle bulging into the interior of a square cell, the two manifold descriptions are in general incompatible. For example, a FlatManifold defined solely through the cell's vertices would put an interior point located at some small distance epsilon away from the boundary along a straight line and thus in general outside the concave part of a circle. If the polynomial degree of MappingQ is sufficiently high, the transformation from the reference cell to such a cell would in general contain inverted regions close to the boundary.
In order to avoid this situation, this class applies an algorithm for making this transition smooth using a so-called transfinite interpolation that is essentially a linear blend between the descriptions along the surrounding entities. In the algorithm that computes additional points, the compute_mapping_support_points() method, all the entities of the cells are passed through hierarchically, starting from the lines to the quads and finally hexes. Points on objects higher up in the hierarchy are obtained from the manifold associated with that object, taking into account all the points previously computed by the manifolds associated with the lower-dimensional objects, not just the vertices. If only a line is assigned a curved boundary but the adjacent quad is on a flat manifold, the flat manifold on the quad will take the points on the deformed line into account when interpolating the position of the additional points inside the quad and thus always result in a well-defined transformation.
@@ -741,37 +741,37 @@
The mapping kinds currently implemented by derived classes are:
mapping_contravariant: maps a vector field on the reference cell to the physical cell through the Jacobian:
-
+\]" src="form_1285.png"/>
In physics, this is usually referred to as the contravariant transformation. Mathematically, it is the push forward of a vector field.
mapping_covariant: maps a field of one-forms on the reference cell to a field of one-forms on the physical cell. (Theoretically this would refer to a DerivativeForm<1,dim,1> but we canonically identify this type with a Tensor<1,dim>). Mathematically, it is the pull back of the differential form
-
+\]" src="form_1286.png"/>
Gradients of scalar differentiable functions are transformed this way.
In the case when dim=spacedim the previous formula reduces to
-
+\]" src="form_1287.png"/>
because we assume that the mapping is always invertible, and consequently its Jacobian is an invertible matrix.
mapping_piola: A field of dim-1-forms on the reference cell is also represented by a vector field, but again transforms differently, namely by the Piola transform
-
+\]" src="form_1288.png"/>
@@ -835,21 +835,21 @@
-
Transform a field of differential forms from the reference cell to the physical cell. It is useful to think of and , with a vector field. The mapping kinds currently implemented by derived classes are:
+
Transform a field of differential forms from the reference cell to the physical cell. It is useful to think of and , with a vector field. The mapping kinds currently implemented by derived classes are:
mapping_covariant: maps a field of forms on the reference cell to a field of forms on the physical cell. Mathematically, it is the pull back of the differential form
-
+\]" src="form_1291.png"/>
Jacobians of spacedim-vector valued differentiable functions are transformed this way.
In the case when dim=spacedim the previous formula reduces to
-
+\]" src="form_1292.png"/>
@@ -916,35 +916,35 @@
Transform a tensor field from the reference cell to the physical cell. These tensors are usually the Jacobians in the reference cell of vector fields that have been pulled back from the physical cell. The mapping kinds currently implemented by derived classes are:
-mapping_contravariant_gradient: it assumes so that
- so that
+
+\]" src="form_1294.png"/>
-mapping_covariant_gradient: it assumes so that
- so that
+
+\]" src="form_1296.png"/>
-mapping_piola_gradient: it assumes so that
- so that
+
+\]" src="form_1298.png"/>
@@ -1013,21 +1013,21 @@
The mapping kinds currently implemented by derived classes are:
mapping_covariant_gradient: maps a field of forms on the reference cell to a field of forms on the physical cell. Mathematically, it is the pull back of the differential form
Hessians of spacedim-vector valued differentiable functions are transformed this way (After subtraction of the product of the derivative with the Jacobian gradient).
In the case when dim=spacedim the previous formula reduces to
-
+
Parameters
@@ -1089,40 +1089,40 @@
-
Transform a field of 3-differential forms from the reference cell to the physical cell. It is useful to think of and , with a vector field.
+
Transform a field of 3-differential forms from the reference cell to the physical cell. It is useful to think of and , with a vector field.
The mapping kinds currently implemented by derived classes are:
-mapping_contravariant_hessian: it assumes so that
Implementation of a -linear mapping from the reference cell to a general quadrilateral/hexahedron.
-
The mapping implemented by this class maps the reference (unit) cell to a general grid cell with straight lines in dimensions. (Note, however, that in 3d the faces of a general, trilinearly mapped cell may be curved, even if the edges are not). This is the standard mapping used for polyhedral domains. It is also the mapping used throughout deal.II for many functions that come in two variants, one that allows to pass a mapping argument explicitly and one that simply falls back to the MappingQ1 class declared here. (Or, in fact, to an object of kind MappingQ(1), which implements exactly the functionality of this class.)
+class MappingQ1< dim, spacedim >
Implementation of a -linear mapping from the reference cell to a general quadrilateral/hexahedron.
+
The mapping implemented by this class maps the reference (unit) cell to a general grid cell with straight lines in dimensions. (Note, however, that in 3d the faces of a general, trilinearly mapped cell may be curved, even if the edges are not). This is the standard mapping used for polyhedral domains. It is also the mapping used throughout deal.II for many functions that come in two variants, one that allows to pass a mapping argument explicitly and one that simply falls back to the MappingQ1 class declared here. (Or, in fact, to an object of kind MappingQ(1), which implements exactly the functionality of this class.)
The shape functions for this mapping are the same as for the finite element FE_Q of polynomial degree 1. Therefore, coupling these two yields an isoparametric element.
Note
This class is, in all reality, nothing more than a different name for calling MappingQ with a polynomial degree of one as argument.
@@ -676,37 +676,37 @@
The mapping kinds currently implemented by derived classes are:
mapping_contravariant: maps a vector field on the reference cell to the physical cell through the Jacobian:
-
+\]" src="form_1285.png"/>
In physics, this is usually referred to as the contravariant transformation. Mathematically, it is the push forward of a vector field.
mapping_covariant: maps a field of one-forms on the reference cell to a field of one-forms on the physical cell. (Theoretically this would refer to a DerivativeForm<1,dim,1> but we canonically identify this type with a Tensor<1,dim>). Mathematically, it is the pull back of the differential form
-
+\]" src="form_1286.png"/>
Gradients of scalar differentiable functions are transformed this way.
In the case when dim=spacedim the previous formula reduces to
-
+\]" src="form_1287.png"/>
because we assume that the mapping is always invertible, and consequently its Jacobian is an invertible matrix.
mapping_piola: A field of dim-1-forms on the reference cell is also represented by a vector field, but again transforms differently, namely by the Piola transform
-
+\]" src="form_1288.png"/>
@@ -770,21 +770,21 @@
-
Transform a field of differential forms from the reference cell to the physical cell. It is useful to think of and , with a vector field. The mapping kinds currently implemented by derived classes are:
+
Transform a field of differential forms from the reference cell to the physical cell. It is useful to think of and , with a vector field. The mapping kinds currently implemented by derived classes are:
mapping_covariant: maps a field of forms on the reference cell to a field of forms on the physical cell. Mathematically, it is the pull back of the differential form
-
+\]" src="form_1291.png"/>
Jacobians of spacedim-vector valued differentiable functions are transformed this way.
In the case when dim=spacedim the previous formula reduces to
-
+\]" src="form_1292.png"/>
@@ -851,35 +851,35 @@
Transform a tensor field from the reference cell to the physical cell. These tensors are usually the Jacobians in the reference cell of vector fields that have been pulled back from the physical cell. The mapping kinds currently implemented by derived classes are:
-mapping_contravariant_gradient: it assumes so that
- so that
+
+\]" src="form_1294.png"/>
-mapping_covariant_gradient: it assumes so that
- so that
+
+\]" src="form_1296.png"/>
-mapping_piola_gradient: it assumes so that
- so that
+
+\]" src="form_1298.png"/>
@@ -948,21 +948,21 @@
The mapping kinds currently implemented by derived classes are:
mapping_covariant_gradient: maps a field of forms on the reference cell to a field of forms on the physical cell. Mathematically, it is the pull back of the differential form
Hessians of spacedim-vector valued differentiable functions are transformed this way (After subtraction of the product of the derivative with the Jacobian gradient).
In the case when dim=spacedim the previous formula reduces to
-
+
Parameters
@@ -1024,40 +1024,40 @@
-
Transform a field of 3-differential forms from the reference cell to the physical cell. It is useful to think of and , with a vector field.
+
Transform a field of 3-differential forms from the reference cell to the physical cell. It is useful to think of and , with a vector field.
The mapping kinds currently implemented by derived classes are:
-mapping_contravariant_hessian: it assumes so that
- so that
+
+\]" src="form_1306.png"/>
-mapping_covariant_hessian: it assumes so that
- so that
+
+\]" src="form_1308.png"/>
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classMappingQ1Eulerian.html differs (JavaScript source, ASCII text, with very long lines (1260))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classMappingQ1Eulerian.html 2023-11-25 15:25:56.696621751 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classMappingQ1Eulerian.html 2023-11-25 15:25:56.696621751 +0100
@@ -243,7 +243,7 @@
This class provides a mapping that adds to the location of each cell a -linear displacement field. (The generalization to higher order polynomials is provided in the MappingQEulerian class.) Each cell is thus shifted in space by values given to the mapping through a finite element field.
This class provides a mapping that adds to the location of each cell a -linear displacement field. (The generalization to higher order polynomials is provided in the MappingQEulerian class.) Each cell is thus shifted in space by values given to the mapping through a finite element field.
Usage
The constructor of this class takes two arguments: a reference to the vector that defines the mapping from the reference configuration to the current configuration and a reference to the DoFHandler. The vector should then represent a (flattened out version of a) vector valued field defined at nodes defined by the DoFHandler, where the number of components of the vector field equals the number of space dimensions. Thus, the DoFHandler shall operate on a finite element that has as many components as space dimensions. As an additional requirement, we impose that it have as many degree of freedom per vertex as there are space dimensions; since this object only evaluates the finite element field at the vertices, the values of all other degrees of freedom (not associated to vertices) are ignored. These requirements are met if the finite element which the given DoFHandler operates on is constructed as a system element (FESystem) from dim continuous FE_Q() objects.
In many cases, the shift vector will also be the solution vector of the problem under investigation. If this is not the case (i.e. the number of components of the solution variable is not equal to the space dimension, e.g. for scalar problems in dim>1 where the Eulerian coordinates only give a background field) or for coupled problems where more variables are computed than just the flow field), then a different DoFHandler has to be set up on the given triangulation, and the shift vector has then to be associated to it.
@@ -831,37 +831,37 @@
The mapping kinds currently implemented by derived classes are:
mapping_contravariant: maps a vector field on the reference cell to the physical cell through the Jacobian:
-
+\]" src="form_1285.png"/>
In physics, this is usually referred to as the contravariant transformation. Mathematically, it is the push forward of a vector field.
mapping_covariant: maps a field of one-forms on the reference cell to a field of one-forms on the physical cell. (Theoretically this would refer to a DerivativeForm<1,dim,1> but we canonically identify this type with a Tensor<1,dim>). Mathematically, it is the pull back of the differential form
-
+\]" src="form_1286.png"/>
Gradients of scalar differentiable functions are transformed this way.
In the case when dim=spacedim the previous formula reduces to
-
+\]" src="form_1287.png"/>
because we assume that the mapping is always invertible, and consequently its Jacobian is an invertible matrix.
mapping_piola: A field of dim-1-forms on the reference cell is also represented by a vector field, but again transforms differently, namely by the Piola transform
-
+\]" src="form_1288.png"/>
@@ -925,21 +925,21 @@
-
Transform a field of differential forms from the reference cell to the physical cell. It is useful to think of and , with a vector field. The mapping kinds currently implemented by derived classes are:
+
Transform a field of differential forms from the reference cell to the physical cell. It is useful to think of and , with a vector field. The mapping kinds currently implemented by derived classes are:
mapping_covariant: maps a field of forms on the reference cell to a field of forms on the physical cell. Mathematically, it is the pull back of the differential form
-
+\]" src="form_1291.png"/>
Jacobians of spacedim-vector valued differentiable functions are transformed this way.
In the case when dim=spacedim the previous formula reduces to
-
+\]" src="form_1292.png"/>
@@ -1006,35 +1006,35 @@
Transform a tensor field from the reference cell to the physical cell. These tensors are usually the Jacobians in the reference cell of vector fields that have been pulled back from the physical cell. The mapping kinds currently implemented by derived classes are:
-mapping_contravariant_gradient: it assumes so that
- so that
+
+\]" src="form_1294.png"/>
-mapping_covariant_gradient: it assumes so that
- so that
+
+\]" src="form_1296.png"/>
-mapping_piola_gradient: it assumes so that
- so that
+
+\]" src="form_1298.png"/>
@@ -1103,21 +1103,21 @@
The mapping kinds currently implemented by derived classes are:
mapping_covariant_gradient: maps a field of forms on the reference cell to a field of forms on the physical cell. Mathematically, it is the pull back of the differential form
Hessians of spacedim-vector valued differentiable functions are transformed this way (After subtraction of the product of the derivative with the Jacobian gradient).
In the case when dim=spacedim the previous formula reduces to
-
+
Parameters
@@ -1179,40 +1179,40 @@
-
Transform a field of 3-differential forms from the reference cell to the physical cell. It is useful to think of and , with a vector field.
+
Transform a field of 3-differential forms from the reference cell to the physical cell. It is useful to think of and , with a vector field.
The mapping kinds currently implemented by derived classes are:
-mapping_contravariant_hessian: it assumes so that
- so that
+
+\]" src="form_1306.png"/>
-mapping_covariant_hessian: it assumes so that
- so that
+
+\]" src="form_1308.png"/>
-mapping_piola_hessian: it assumes
-
Initialize the data cache by letting the function given as an argument provide the mapping support points for all cells (on all levels) of the given triangulation. The function must return a vector of Point<spacedim> whose length is the same as the size of the polynomial space, , where is the polynomial degree of the mapping, and it must be in the order the mapping or FE_Q sort their points, i.e., all vertex points first, then the points on the lines, quads, and hexes according to the usual hierarchical numbering. No attempt is made to validate these points internally, except for the number of given points.
+
Initialize the data cache by letting the function given as an argument provide the mapping support points for all cells (on all levels) of the given triangulation. The function must return a vector of Point<spacedim> whose length is the same as the size of the polynomial space, , where is the polynomial degree of the mapping, and it must be in the order the mapping or FE_Q sort their points, i.e., all vertex points first, then the points on the lines, quads, and hexes according to the usual hierarchical numbering. No attempt is made to validate these points internally, except for the number of given points.
Note
If multiple threads are enabled, this function will run in parallel, invoking the function passed in several times. Thus, in case MultithreadInfo::n_threads()>1, the user code must make sure that the function, typically a lambda, does not write into data shared with other threads.
The mapping kinds currently implemented by derived classes are:
mapping_contravariant: maps a vector field on the reference cell to the physical cell through the Jacobian:
-
+\]" src="form_1285.png"/>
In physics, this is usually referred to as the contravariant transformation. Mathematically, it is the push forward of a vector field.
mapping_covariant: maps a field of one-forms on the reference cell to a field of one-forms on the physical cell. (Theoretically this would refer to a DerivativeForm<1,dim,1> but we canonically identify this type with a Tensor<1,dim>). Mathematically, it is the pull back of the differential form
-
+\]" src="form_1286.png"/>
Gradients of scalar differentiable functions are transformed this way.
In the case when dim=spacedim the previous formula reduces to
-
+\]" src="form_1287.png"/>
because we assume that the mapping is always invertible, and consequently its Jacobian is an invertible matrix.
mapping_piola: A field of dim-1-forms on the reference cell is also represented by a vector field, but again transforms differently, namely by the Piola transform
-
+\]" src="form_1288.png"/>
@@ -1198,21 +1198,21 @@
-
Transform a field of differential forms from the reference cell to the physical cell. It is useful to think of and , with a vector field. The mapping kinds currently implemented by derived classes are:
+
Transform a field of differential forms from the reference cell to the physical cell. It is useful to think of and , with a vector field. The mapping kinds currently implemented by derived classes are:
mapping_covariant: maps a field of forms on the reference cell to a field of forms on the physical cell. Mathematically, it is the pull back of the differential form
-
+\]" src="form_1291.png"/>
Jacobians of spacedim-vector valued differentiable functions are transformed this way.
In the case when dim=spacedim the previous formula reduces to
-
+\]" src="form_1292.png"/>
@@ -1279,35 +1279,35 @@
Transform a tensor field from the reference cell to the physical cell. These tensors are usually the Jacobians in the reference cell of vector fields that have been pulled back from the physical cell. The mapping kinds currently implemented by derived classes are:
-mapping_contravariant_gradient: it assumes so that
- so that
+
+\]" src="form_1294.png"/>
-mapping_covariant_gradient: it assumes so that
- so that
+
+\]" src="form_1296.png"/>
-mapping_piola_gradient: it assumes so that
- so that
+
+\]" src="form_1298.png"/>
@@ -1376,21 +1376,21 @@
The mapping kinds currently implemented by derived classes are:
mapping_covariant_gradient: maps a field of forms on the reference cell to a field of forms on the physical cell. Mathematically, it is the pull back of the differential form
Hessians of spacedim-vector valued differentiable functions are transformed this way (After subtraction of the product of the derivative with the Jacobian gradient).
In the case when dim=spacedim the previous formula reduces to
-
+
Parameters
@@ -1452,40 +1452,40 @@
-
Transform a field of 3-differential forms from the reference cell to the physical cell. It is useful to think of and , with a vector field.
+
Transform a field of 3-differential forms from the reference cell to the physical cell. It is useful to think of and , with a vector field.
The mapping kinds currently implemented by derived classes are:
-mapping_contravariant_hessian: it assumes so that
- so that
+
+\]" src="form_1306.png"/>
-mapping_covariant_hessian: it assumes so that
- so that
+
+\]" src="form_1308.png"/>
-mapping_piola_hessian: it assumes
-
Return the locations of support points for the mapping. For example, for mappings these are the vertices, and for higher order polynomial mappings they are the vertices plus interior points on edges, faces, and the cell interior that are placed in consultation with the Manifold description of the domain and its boundary. However, other classes may override this function differently. In particular, the MappingQ1Eulerian class does exactly this by not computing the support points from the geometry of the current cell but instead evaluating an externally given displacement field in addition to the geometry of the cell.
+
Return the locations of support points for the mapping. For example, for mappings these are the vertices, and for higher order polynomial mappings they are the vertices plus interior points on edges, faces, and the cell interior that are placed in consultation with the Manifold description of the domain and its boundary. However, other classes may override this function differently. In particular, the MappingQ1Eulerian class does exactly this by not computing the support points from the geometry of the current cell but instead evaluating an externally given displacement field in addition to the geometry of the cell.
The default implementation of this function is appropriate for most cases. It takes the locations of support points on the boundary of the cell from the underlying manifold. Interior support points (ie. support points in quads for 2d, in hexes for 3d) are then computed using an interpolation from the lower-dimensional entities (lines, quads) in order to make the transformation as smooth as possible without introducing additional boundary layers within the cells due to the placement of support points.
The function works its way from the vertices (which it takes from the given cell) via the support points on the line (for which it calls the add_line_support_points() function) and the support points on the quad faces (in 3d, for which it calls the add_quad_support_points() function). It then adds interior support points that are either computed by interpolation from the surrounding points using weights for transfinite interpolation, or if dim<spacedim, it asks the underlying manifold for the locations of interior points.
@@ -859,37 +859,37 @@
The mapping kinds currently implemented by derived classes are:
mapping_contravariant: maps a vector field on the reference cell to the physical cell through the Jacobian:
-
+\]" src="form_1285.png"/>
In physics, this is usually referred to as the contravariant transformation. Mathematically, it is the push forward of a vector field.
mapping_covariant: maps a field of one-forms on the reference cell to a field of one-forms on the physical cell. (Theoretically this would refer to a DerivativeForm<1,dim,1> but we canonically identify this type with a Tensor<1,dim>). Mathematically, it is the pull back of the differential form
-
+\]" src="form_1286.png"/>
Gradients of scalar differentiable functions are transformed this way.
In the case when dim=spacedim the previous formula reduces to
-
+\]" src="form_1287.png"/>
because we assume that the mapping is always invertible, and consequently its Jacobian is an invertible matrix.
mapping_piola: A field of dim-1-forms on the reference cell is also represented by a vector field, but again transforms differently, namely by the Piola transform
-
+\]" src="form_1288.png"/>
@@ -953,21 +953,21 @@
-
Transform a field of differential forms from the reference cell to the physical cell. It is useful to think of and , with a vector field. The mapping kinds currently implemented by derived classes are:
+
Transform a field of differential forms from the reference cell to the physical cell. It is useful to think of and , with a vector field. The mapping kinds currently implemented by derived classes are:
mapping_covariant: maps a field of forms on the reference cell to a field of forms on the physical cell. Mathematically, it is the pull back of the differential form
-
+\]" src="form_1291.png"/>
Jacobians of spacedim-vector valued differentiable functions are transformed this way.
In the case when dim=spacedim the previous formula reduces to
-
+\]" src="form_1292.png"/>
@@ -1034,35 +1034,35 @@
Transform a tensor field from the reference cell to the physical cell. These tensors are usually the Jacobians in the reference cell of vector fields that have been pulled back from the physical cell. The mapping kinds currently implemented by derived classes are:
-mapping_contravariant_gradient: it assumes so that
- so that
+
+\]" src="form_1294.png"/>
-mapping_covariant_gradient: it assumes so that
- so that
+
+\]" src="form_1296.png"/>
-mapping_piola_gradient: it assumes so that
- so that
+
+\]" src="form_1298.png"/>
@@ -1131,21 +1131,21 @@
The mapping kinds currently implemented by derived classes are:
mapping_covariant_gradient: maps a field of forms on the reference cell to a field of forms on the physical cell. Mathematically, it is the pull back of the differential form
Hessians of spacedim-vector valued differentiable functions are transformed this way (After subtraction of the product of the derivative with the Jacobian gradient).
In the case when dim=spacedim the previous formula reduces to
-
+
Parameters
@@ -1207,40 +1207,40 @@
-
Transform a field of 3-differential forms from the reference cell to the physical cell. It is useful to think of and , with a vector field.
+
Transform a field of 3-differential forms from the reference cell to the physical cell. It is useful to think of and , with a vector field.
The mapping kinds currently implemented by derived classes are:
-mapping_contravariant_hessian: it assumes so that
- so that
+
+\]" src="form_1306.png"/>
-mapping_covariant_hessian: it assumes so that
- so that
+
+\]" src="form_1308.png"/>
-mapping_piola_hessian: it assumes
Number of shape functions. If this is a Q1 mapping, then it is simply the number of vertices per cell. However, since also derived classes use this class (e.g. the Mapping_Q() class), the number of shape functions may also be different.
-
In general, it is , where is the polynomial degree of the mapping.
+
In general, it is , where is the polynomial degree of the mapping.
This class implements the operation of the action of a Laplace matrix, namely , where is the scalar heterogeneity coefficient.
Note that this class only supports the non-blocked vector variant of the Base operator because only a single FEEvaluation object is used in the apply function.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classNonMatching_1_1FEImmersedSurfaceValues.html differs (JavaScript source, ASCII text, with very long lines (883))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classNonMatching_1_1FEImmersedSurfaceValues.html 2023-11-25 15:25:56.886617886 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classNonMatching_1_1FEImmersedSurfaceValues.html 2023-11-25 15:25:56.886617886 +0100
@@ -519,7 +519,7 @@
Returns the surface gradient of the shape function with index function_no at the quadrature point with index quadrature_point.
-
The surface gradient is defined as the projection of the gradient to the tangent plane of the surface: , where is the unit normal to the surface.
+
The surface gradient is defined as the projection of the gradient to the tangent plane of the surface: , where is the unit normal to the surface.
Note
For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_gradients | update_normal_vectors flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.
If the shape function is vector-valued, then this returns the only non- zero component. If the shape function has more than one non-zero component (i.e. it is not primitive), then throw an exception of type ExcShapeFunctionNotPrimitive. In that case, use the shape_value_component() function.
Parameters
-
i
Number of the shape function to be evaluated. Note that this number runs from zero to dofs_per_cell, even in the case of an FEFaceValues or FESubfaceValues object.
+
i
Number of the shape function to be evaluated. Note that this number runs from zero to dofs_per_cell, even in the case of an FEFaceValues or FESubfaceValues object.
q_point
Number of the quadrature point at which function is to be evaluated
@@ -726,7 +726,7 @@
Compute one vector component of the value of a shape function at a quadrature point. If the finite element is scalar, then only component zero is allowed and the return value equals that of the shape_value() function. If the finite element is vector valued but all shape functions are primitive (i.e. they are non-zero in only one component), then the value returned by shape_value() equals that of this function for exactly one component. This function is therefore only of greater interest if the shape function is not primitive, but then it is necessary since the other function cannot be used.
Parameters
-
i
Number of the shape function to be evaluated.
+
i
Number of the shape function to be evaluated.
q_point
Number of the quadrature point at which function is to be evaluated.
component
vector component to be evaluated.
@@ -772,7 +772,7 @@
The same holds for the arguments of this function as for the shape_value() function.
Parameters
-
i
Number of the shape function to be evaluated.
+
i
Number of the shape function to be evaluated.
q_point
Number of the quadrature point at which function is to be evaluated.
@@ -1015,17 +1015,17 @@
-
Return the values of a finite element function at the quadrature points of the current cell, face, or subface (selected the last time the reinit() function was called). That is, if the first argument fe_function is a vector of nodal values of a finite element function defined on a DoFHandler object, then the output vector (the second argument, values) is the vector of values where are the quadrature points on the current cell . This function is first discussed in the Results section of step-4, and the related get_function_gradients() function is also used in step-15 along with numerous other tutorial programs.
+
Return the values of a finite element function at the quadrature points of the current cell, face, or subface (selected the last time the reinit() function was called). That is, if the first argument fe_function is a vector of nodal values of a finite element function defined on a DoFHandler object, then the output vector (the second argument, values) is the vector of values where are the quadrature points on the current cell . This function is first discussed in the Results section of step-4, and the related get_function_gradients() function is also used in step-15 along with numerous other tutorial programs.
If the current cell is not active (i.e., it has children), then the finite element function is, strictly speaking, defined by shape functions that live on these child cells. Rather than evaluating the shape functions on the child cells, with the quadrature points defined on the current cell, this function first interpolates the finite element function to shape functions defined on the current cell, and then evaluates this interpolated function.
This function may only be used if the finite element in use is a scalar one, i.e. has only one vector component. To get values of multi-component elements, there is another get_function_values() below, returning a vector of vectors of results.
Parameters
[in]
fe_function
A vector of values that describes (globally) the finite element function that this function should evaluate at the quadrature points of the current cell.
-
[out]
values
The values of the function specified by fe_function at the quadrature points of the current cell. The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the values of shape function times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument). This happens to be equal to the type of the elements of the solution vector.
+
[out]
values
The values of the function specified by fe_function at the quadrature points of the current cell. The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the values of shape function times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument). This happens to be equal to the type of the elements of the solution vector.
-
Postcondition
values[q] will contain the value of the field described by fe_function at the th quadrature point.
+
Postcondition
values[q] will contain the value of the field described by fe_function at the th quadrature point.
Note
The actual data type of the input vector may be either a Vector<T>, BlockVector<T>, or one of the PETSc or Trilinos vector wrapper classes. It represents a global vector of DoF values associated with the DoFHandler object with which this FEValues object was last initialized.
This function does the same as the other get_function_values(), but applied to multi-component (vector-valued) elements. The meaning of the arguments is as explained there.
-
Postcondition
values[q] is a vector of values of the field described by fe_function at the th quadrature point. The size of the vector accessed by values[q] equals the number of components of the finite element, i.e. values[q](c) returns the value of the th vector component at the th quadrature point.
+
Postcondition
values[q] is a vector of values of the field described by fe_function at the th quadrature point. The size of the vector accessed by values[q] equals the number of components of the finite element, i.e. values[q](c) returns the value of the th vector component at the th quadrature point.
Return the gradients of a finite element function at the quadrature points of the current cell, face, or subface (selected the last time the reinit() function was called). That is, if the first argument fe_function is a vector of nodal values of a finite element function defined on a DoFHandler object, then the output vector (the second argument, values) is the vector of values where are the quadrature points on the current cell . This function is first discussed in the Results section of step-4, and it is also used in step-15 along with numerous other tutorial programs.
+
Return the gradients of a finite element function at the quadrature points of the current cell, face, or subface (selected the last time the reinit() function was called). That is, if the first argument fe_function is a vector of nodal values of a finite element function defined on a DoFHandler object, then the output vector (the second argument, values) is the vector of values where are the quadrature points on the current cell . This function is first discussed in the Results section of step-4, and it is also used in step-15 along with numerous other tutorial programs.
This function may only be used if the finite element in use is a scalar one, i.e. has only one vector component. There is a corresponding function of the same name for vector-valued finite elements.
Parameters
[in]
fe_function
A vector of values that describes (globally) the finite element function that this function should evaluate at the quadrature points of the current cell.
-
[out]
gradients
The gradients of the function specified by fe_function at the quadrature points of the current cell. The gradients are computed in real space (as opposed to on the unit cell). The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the gradients of shape function times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
+
[out]
gradients
The gradients of the function specified by fe_function at the quadrature points of the current cell. The gradients are computed in real space (as opposed to on the unit cell). The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the gradients of shape function times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
-
Postcondition
gradients[q] will contain the gradient of the field described by fe_function at the th quadrature point. gradients[q][d] represents the derivative in coordinate direction at quadrature point .
+
Postcondition
gradients[q] will contain the gradient of the field described by fe_function at the th quadrature point. gradients[q][d] represents the derivative in coordinate direction at quadrature point .
Note
The actual data type of the input vector may be either a Vector<T>, BlockVector<T>, or one of the PETSc or Trilinos vector wrapper classes. It represents a global vector of DoF values associated with the DoFHandler object with which this FEValues object was last initialized.
This function does the same as the other get_function_gradients(), but applied to multi-component (vector-valued) elements. The meaning of the arguments is as explained there.
-
Postcondition
gradients[q] is a vector of gradients of the field described by fe_function at the th quadrature point. The size of the vector accessed by gradients[q] equals the number of components of the finite element, i.e. gradients[q][c] returns the gradient of the th vector component at the th quadrature point. Consequently, gradients[q][c][d] is the derivative in coordinate direction of the th vector component of the vector field at quadrature point of the current cell.
+
Postcondition
gradients[q] is a vector of gradients of the field described by fe_function at the th quadrature point. The size of the vector accessed by gradients[q] equals the number of components of the finite element, i.e. gradients[q][c] returns the gradient of the th vector component at the th quadrature point. Consequently, gradients[q][c][d] is the derivative in coordinate direction of the th vector component of the vector field at quadrature point of the current cell.
A vector of values that describes (globally) the finite element function that this function should evaluate at the quadrature points of the current cell.
-
[out]
hessians
The Hessians of the function specified by fe_function at the quadrature points of the current cell. The Hessians are computed in real space (as opposed to on the unit cell). The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the Hessians of shape function times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
+
[out]
hessians
The Hessians of the function specified by fe_function at the quadrature points of the current cell. The Hessians are computed in real space (as opposed to on the unit cell). The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the Hessians of shape function times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
-
Postcondition
hessians[q] will contain the Hessian of the field described by fe_function at the th quadrature point. hessians[q][i][j] represents the th component of the matrix of second derivatives at quadrature point .
+
Postcondition
hessians[q] will contain the Hessian of the field described by fe_function at the th quadrature point. hessians[q][i][j] represents the th component of the matrix of second derivatives at quadrature point .
Note
The actual data type of the input vector may be either a Vector<T>, BlockVector<T>, or one of the PETSc or Trilinos vector wrapper classes. It represents a global vector of DoF values associated with the DoFHandler object with which this FEValues object was last initialized.
This function does the same as the other get_function_hessians(), but applied to multi-component (vector-valued) elements. The meaning of the arguments is as explained there.
-
Postcondition
hessians[q] is a vector of Hessians of the field described by fe_function at the th quadrature point. The size of the vector accessed by hessians[q] equals the number of components of the finite element, i.e. hessians[q][c] returns the Hessian of the th vector component at the th quadrature point. Consequently, hessians[q][c][i][j] is the th component of the matrix of second derivatives of the th vector component of the vector field at quadrature point of the current cell.
+
Postcondition
hessians[q] is a vector of Hessians of the field described by fe_function at the th quadrature point. The size of the vector accessed by hessians[q] equals the number of components of the finite element, i.e. hessians[q][c] returns the Hessian of the th vector component at the th quadrature point. Consequently, hessians[q][c][i][j] is the th component of the matrix of second derivatives of the th vector component of the vector field at quadrature point of the current cell.
A vector of values that describes (globally) the finite element function that this function should evaluate at the quadrature points of the current cell.
-
[out]
laplacians
The Laplacians of the function specified by fe_function at the quadrature points of the current cell. The Laplacians are computed in real space (as opposed to on the unit cell). The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the Laplacians of shape function times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument). This happens to be equal to the type of the elements of the input vector.
+
[out]
laplacians
The Laplacians of the function specified by fe_function at the quadrature points of the current cell. The Laplacians are computed in real space (as opposed to on the unit cell). The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the Laplacians of shape function times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument). This happens to be equal to the type of the elements of the input vector.
-
Postcondition
laplacians[q] will contain the Laplacian of the field described by fe_function at the th quadrature point.
+
Postcondition
laplacians[q] will contain the Laplacian of the field described by fe_function at the th quadrature point.
For each component of the output vector, there holds laplacians[q]=trace(hessians[q]), where hessians would be the output of the get_function_hessians() function.
Note
The actual data type of the input vector may be either a Vector<T>, BlockVector<T>, or one of the PETSc or Trilinos vector wrapper classes. It represents a global vector of DoF values associated with the DoFHandler object with which this FEValues object was last initialized.
@@ -1678,7 +1678,7 @@
This function does the same as the other get_function_laplacians(), but applied to multi-component (vector-valued) elements. The meaning of the arguments is as explained there.
-
Postcondition
laplacians[q] is a vector of Laplacians of the field described by fe_function at the th quadrature point. The size of the vector accessed by laplacians[q] equals the number of components of the finite element, i.e. laplacians[q][c] returns the Laplacian of the th vector component at the th quadrature point.
+
Postcondition
laplacians[q] is a vector of Laplacians of the field described by fe_function at the th quadrature point. The size of the vector accessed by laplacians[q] equals the number of components of the finite element, i.e. laplacians[q][c] returns the Laplacian of the th vector component at the th quadrature point.
For each component of the output vector, there holds laplacians[q][c]=trace(hessians[q][c]), where hessians would be the output of the get_function_hessians() function.
A vector of values that describes (globally) the finite element function that this function should evaluate at the quadrature points of the current cell.
-
[out]
third_derivatives
The third derivatives of the function specified by fe_function at the quadrature points of the current cell. The third derivatives are computed in real space (as opposed to on the unit cell). The object is assumed to already have the correct size. The data type stored by this output vector must be what you get when you multiply the third derivatives of shape function times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
+
[out]
third_derivatives
The third derivatives of the function specified by fe_function at the quadrature points of the current cell. The third derivatives are computed in real space (as opposed to on the unit cell). The object is assumed to already have the correct size. The data type stored by this output vector must be what you get when you multiply the third derivatives of shape function times the type used to store the values of the unknowns of your finite element vector (represented by the fe_function argument).
-
Postcondition
third_derivatives[q] will contain the third derivatives of the field described by fe_function at the th quadrature point. third_derivatives[q][i][j][k] represents the th component of the 3rd order tensor of third derivatives at quadrature point .
+
Postcondition
third_derivatives[q] will contain the third derivatives of the field described by fe_function at the th quadrature point. third_derivatives[q][i][j][k] represents the th component of the 3rd order tensor of third derivatives at quadrature point .
Note
The actual data type of the input vector may be either a Vector<T>, BlockVector<T>, or one of the PETSc or Trilinos vector wrapper classes. It represents a global vector of DoF values associated with the DoFHandler object with which this FEValues object was last initialized.
This function does the same as the other get_function_third_derivatives(), but applied to multi-component (vector- valued) elements. The meaning of the arguments is as explained there.
-
Postcondition
third_derivatives[q] is a vector of third derivatives of the field described by fe_function at the th quadrature point. The size of the vector accessed by third_derivatives[q] equals the number of components of the finite element, i.e. third_derivatives[q][c] returns the third derivative of the th vector component at the th quadrature point. Consequently, third_derivatives[q][c][i][j][k] is the th component of the tensor of third derivatives of the th vector component of the vector field at quadrature point of the current cell.
+
Postcondition
third_derivatives[q] is a vector of third derivatives of the field described by fe_function at the th quadrature point. The size of the vector accessed by third_derivatives[q] equals the number of components of the finite element, i.e. third_derivatives[q][c] returns the third derivative of the th vector component at the th quadrature point. Consequently, third_derivatives[q][c][i][j][k] is the th component of the tensor of third derivatives of the th vector component of the vector field at quadrature point of the current cell.
Mapped quadrature weight. If this object refers to a volume evaluation (i.e. the derived class is of type FEValues), then this is the Jacobi determinant times the weight of the q_pointth unit quadrature point.
For surface evaluations (i.e. classes FEFaceValues or FESubfaceValues), it is the mapped surface element times the weight of the quadrature point.
-
You can think of the quantity returned by this function as the volume or surface element in the integral that we implement here by quadrature.
+
You can think of the quantity returned by this function as the volume or surface element in the integral that we implement here by quadrature.
Return the second derivative of the transformation from unit to real cell, i.e. the first derivative of the Jacobian, at the specified quadrature point, i.e. .
+
Return the second derivative of the transformation from unit to real cell, i.e. the first derivative of the Jacobian, at the specified quadrature point, i.e. .
Return the second derivative of the transformation from unit to real cell, i.e. the first derivative of the Jacobian, at the specified quadrature point, pushed forward to the real cell coordinates, i.e. .
+
Return the second derivative of the transformation from unit to real cell, i.e. the first derivative of the Jacobian, at the specified quadrature point, pushed forward to the real cell coordinates, i.e. .
Note
For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_jacobian_pushed_forward_grads flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classNonMatching_1_1FEInterfaceValues.html differs (JavaScript source, ASCII text, with very long lines (1631))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classNonMatching_1_1FEInterfaceValues.html 2023-11-25 15:25:56.906617479 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classNonMatching_1_1FEInterfaceValues.html 2023-11-25 15:25:56.906617479 +0100
@@ -157,11 +157,11 @@
Detailed Description
template<int dim>
-class NonMatching::FEInterfaceValues< dim >
This class is intended to facilitate assembling interface terms on faces in immersed (in the sense of cut) finite element methods. These types of terms occur mainly in cut discontinuous Galerkin methods. This class works analogously to NonMatching::FEValues. The domain is assumed to be described by a level set function, , and this class assumes that we want to integrate over two different regions of each face, :
-NonMatching::FEValues. The domain is assumed to be described by a level set function, , and this class assumes that we want to integrate over two different regions of each face, :
+
+\]" src="form_2029.png"/>
which we as before refer to as the "inside" and "outside" regions of the face.
void reinit(const CellIteratorType &cell, const unsigned int face_no, const unsigned int sub_face_no, const CellNeighborIteratorType &cell_neighbor, const unsigned int face_no_neighbor, const unsigned int sub_face_no_neighbor)
-
To reduce the amount of work, the reinit() function of this class uses the MeshClassifier passed to the constructor to check how the incoming cell relates to the level set function. The immersed quadrature rules are only generated if the cell is intersected. If the cell is completely inside or outside, it returns a cached FEInterfaceValues object created with a quadrature over the reference cell: .
+
To reduce the amount of work, the reinit() function of this class uses the MeshClassifier passed to the constructor to check how the incoming cell relates to the level set function. The immersed quadrature rules are only generated if the cell is intersected. If the cell is completely inside or outside, it returns a cached FEInterfaceValues object created with a quadrature over the reference cell: .
Collection of Quadrature rules over that should be used when a face is not intersected and we do not need to generate immersed quadrature rules.
+
q_collection
Collection of Quadrature rules over that should be used when a face is not intersected and we do not need to generate immersed quadrature rules.
q_collection_1d
Collection of 1-dimensional quadrature rules used to generate the immersed quadrature rules. See the QuadratureGenerator class.
mesh_classifier
Object used to determine when the immersed quadrature rules need to be generated.
region_update_flags
Struct storing UpdateFlags for the inside/outside region of the cell.
@@ -476,7 +476,7 @@
-
Return an FEInterfaceValues object reinitialized with a quadrature for the inside region of the cell: .
+
Return an FEInterfaceValues object reinitialized with a quadrature for the inside region of the cell: .
Note
If the quadrature rule over the region is empty, e.g. because the cell is completely located in the outside domain, the returned optional will not contain a value.
Return an FEInterfaceValues object reinitialized with a quadrature for the outside region of the cell: .
+
Return an FEInterfaceValues object reinitialized with a quadrature for the outside region of the cell: .
Note
If the quadrature rule over the region is empty, e.g. because the cell is completely located in the inside domain, the returned optional will not contain a value.
For each element in the FECollection passed to the constructor, this object contains an FEInterfaceValues object created with a quadrature rule over the full reference cell: and UpdateFlags for the inside region. Thus, these optionals should always contain a value.
+
For each element in the FECollection passed to the constructor, this object contains an FEInterfaceValues object created with a quadrature rule over the full reference cell: and UpdateFlags for the inside region. Thus, these optionals should always contain a value.
When LocationToLevelSet of the cell is INSIDE (and we do not need to generate an immersed quadrature), we return the FEInterfaceValues object in this container corresponding to the cell's active_fe_index.
This container is a std::deque, which is compatible with the FEInterfaceValues class that does not have a copy-constructor.
@@ -819,7 +819,7 @@
-
For each element in the FECollection passed to the constructor, this object contains an FEInterfaceValues object created with a quadrature rule over the full reference cell: and UpdateFlags for the outside region. Thus, these optionals should always contain a value.
+
For each element in the FECollection passed to the constructor, this object contains an FEInterfaceValues object created with a quadrature rule over the full reference cell: and UpdateFlags for the outside region. Thus, these optionals should always contain a value.
When LocationToLevelSet of the cell is OUTSIDE (and we do not need to generate an immersed quadrature), we return the FEValues object in this container corresponding to the cell's active_fe_index.
This container is a std::deque, which is compatible with the FEInterfaceValues class that does not have a copy-constructor.
@@ -848,7 +848,7 @@
-
FEInterfaceValues object created with a quadrature rule integrating over the inside region, , that was generated in the last call to reinit(..). If the cell in the last call was not intersected or if 0 quadrature points were generated, this optional will not contain a value.
+
FEInterfaceValues object created with a quadrature rule integrating over the inside region, , that was generated in the last call to reinit(..). If the cell in the last call was not intersected or if 0 quadrature points were generated, this optional will not contain a value.
FEInterfaceValues object created with a quadrature rule integrating over the outside region, , that was generated in the last call to reinit(..). If the cell in the last call was not intersected or if 0 quadrature points were generated, this optional will not contain a value.
+
FEInterfaceValues object created with a quadrature rule integrating over the outside region, , that was generated in the last call to reinit(..). If the cell in the last call was not intersected or if 0 quadrature points were generated, this optional will not contain a value.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classNonMatching_1_1FEValues.html differs (JavaScript source, ASCII text, with very long lines (2374))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classNonMatching_1_1FEValues.html 2023-11-25 15:25:56.923283807 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classNonMatching_1_1FEValues.html 2023-11-25 15:25:56.923283807 +0100
@@ -157,17 +157,17 @@
Detailed Description
template<int dim>
-class NonMatching::FEValues< dim >
This class is intended to facilitate assembling in immersed (in the sense of cut) finite element methods when the domain is described by a level set function, . In this type of method, we typically need to integrate over 3 different regions of each cell, :
-. In this type of method, we typically need to integrate over 3 different regions of each cell, :
+
+\]" src="form_2026.png"/>
Thus we need quadrature rules for these 3 regions:
-
As in the QuadratureGenerator class, we refer to , , and as the inside, outside, and surface regions. The constructor of this class takes a discrete level set function described by a DoFHandler and a Vector. When the reinit() function is called, the QuadratureGenerator will be called in the background to create these immersed quadrature rules. This class then creates FEValues objects for the inside/outside regions and an FEImmersedSurfaceValues object for the surface region. These objects can then be accessed through one of the functions: get_inside_fe_values(), get_outside_fe_values(), or get_surface_fe_values(). Since a cut between a cell and the domain can be arbitrarily small, the underlying algorithm may generate a quadrature rule with 0 points. This can, for example, happen if the relative size of the cut is similar to the floating-point accuracy. Since the FEValues-like objects are not allowed to contain 0 points, the object that get_inside/outside/surface_fe_values() returns is wrapped in a std_cxx17::optional. This requires us to check if the returned FEValues-like object contains a value before we use it:
As in the QuadratureGenerator class, we refer to , , and as the inside, outside, and surface regions. The constructor of this class takes a discrete level set function described by a DoFHandler and a Vector. When the reinit() function is called, the QuadratureGenerator will be called in the background to create these immersed quadrature rules. This class then creates FEValues objects for the inside/outside regions and an FEImmersedSurfaceValues object for the surface region. These objects can then be accessed through one of the functions: get_inside_fe_values(), get_outside_fe_values(), or get_surface_fe_values(). Since a cut between a cell and the domain can be arbitrarily small, the underlying algorithm may generate a quadrature rule with 0 points. This can, for example, happen if the relative size of the cut is similar to the floating-point accuracy. Since the FEValues-like objects are not allowed to contain 0 points, the object that get_inside/outside/surface_fe_values() returns is wrapped in a std_cxx17::optional. This requires us to check if the returned FEValues-like object contains a value before we use it:
Of course, it is somewhat expensive to generate the immersed quadrature rules and create FEValues objects with the generated quadratures. To reduce the amount of work, the reinit() function of this class uses the MeshClassifier passed to the constructor to check how the incoming cell relates to the level set function. It only generates the immersed quadrature rules if the cell is intersected. If the cell is completely inside or outside, it returns a cached FEValues object created with a quadrature over the reference cell: .
+
Of course, it is somewhat expensive to generate the immersed quadrature rules and create FEValues objects with the generated quadratures. To reduce the amount of work, the reinit() function of this class uses the MeshClassifier passed to the constructor to check how the incoming cell relates to the level set function. It only generates the immersed quadrature rules if the cell is intersected. If the cell is completely inside or outside, it returns a cached FEValues object created with a quadrature over the reference cell: .
Collection of Quadrature rules over that should be used when a cell is not intersected and we do not need to generate immersed quadrature rules.
+
q_collection
Collection of Quadrature rules over that should be used when a cell is not intersected and we do not need to generate immersed quadrature rules.
q_collection_1d
Collection of 1-dimensional quadrature rules used to generate the immersed quadrature rules. See the QuadratureGenerator class.
mesh_classifier
Object used to determine when the immersed quadrature rules need to be generated.
region_update_flags
Struct storing UpdateFlags for the inside/outside/surface region of the cell.
@@ -407,7 +407,7 @@
-
Return an FEValues object reinitialized with a quadrature for the inside region of the cell: .
+
Return an FEValues object reinitialized with a quadrature for the inside region of the cell: .
Note
If the quadrature rule over the region is empty, e.g. because the cell is completely located in the outside domain, the returned optional will not contain a value.
Return an FEValues object reinitialized with a quadrature for the outside region of the cell: .
+
Return an FEValues object reinitialized with a quadrature for the outside region of the cell: .
Note
If the quadrature rule over the region is empty, e.g. because the cell is completely located in the inside domain, the returned optional will not contain a value.
For each element in the FECollection passed to the constructor, this object contains an FEValues object created with a quadrature rule over the full reference cell: and UpdateFlags for the inside region. Thus, these optionals should always contain a value.
+
For each element in the FECollection passed to the constructor, this object contains an FEValues object created with a quadrature rule over the full reference cell: and UpdateFlags for the inside region. Thus, these optionals should always contain a value.
When LocationToLevelSet of the cell is INSIDE (and we do not need to generate an immersed quadrature), we return the FEValues object in this container corresponding to the cell's active_fe_index.
This container is a std::deque, which is compatible with the FEValues class that does not have a copy-constructor.
@@ -724,7 +724,7 @@
-
For each element in the FECollection passed to the constructor, this object contains an FEValues object created with a quadrature rule over the full reference cell: and UpdateFlags for the outside region. Thus, these optionals should always contain a value.
+
For each element in the FECollection passed to the constructor, this object contains an FEValues object created with a quadrature rule over the full reference cell: and UpdateFlags for the outside region. Thus, these optionals should always contain a value.
When LocationToLevelSet of the cell is OUTSIDE (and we do not need to generate an immersed quadrature), we return the FEValues object in this container corresponding to the cell's active_fe_index.
This container is a std::deque, which is compatible with the FEValues class that does not have a copy-constructor.
@@ -753,7 +753,7 @@
-
FEValues object created with a quadrature rule integrating over the inside region, , that was generated in the last call to reinit(..). If the cell in the last call was not intersected or if 0 quadrature points were generated, this optional will not contain a value.
+
FEValues object created with a quadrature rule integrating over the inside region, , that was generated in the last call to reinit(..). If the cell in the last call was not intersected or if 0 quadrature points were generated, this optional will not contain a value.
FEValues object created with a quadrature rule integrating over the outside region, , that was generated in the last call to reinit(..). If the cell in the last call was not intersected or if 0 quadrature points were generated, this optional will not contain a value.
+
FEValues object created with a quadrature rule integrating over the outside region, , that was generated in the last call to reinit(..). If the cell in the last call was not intersected or if 0 quadrature points were generated, this optional will not contain a value.
FEImmersedSurfaceValues object created with a quadrature rule integrating over the surface region, , that was generated in the last call to reinit(..). If the cell in the last call was not intersected or if 0 quadrature points were generated, this optional will not contain a value.
+
FEImmersedSurfaceValues object created with a quadrature rule integrating over the surface region, , that was generated in the last call to reinit(..). If the cell in the last call was not intersected or if 0 quadrature points were generated, this optional will not contain a value.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classNonMatching_1_1FaceQuadratureGenerator.html differs (JavaScript source, ASCII text, with very long lines (1581))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classNonMatching_1_1FaceQuadratureGenerator.html 2023-11-25 15:25:56.936616868 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classNonMatching_1_1FaceQuadratureGenerator.html 2023-11-25 15:25:56.936616868 +0100
@@ -132,16 +132,16 @@
Detailed Description
template<int dim>
-class NonMatching::FaceQuadratureGenerator< dim >
This class creates immersed quadrature rules over a face, , of a BoundingBox, when the domain is described by a level set function, .
-
In the same way as in the QuadratureGenerator class, this class generates quadrature rules to integrate over 3 different regions of the face, :
-, of a BoundingBox, when the domain is described by a level set function, .
+
In the same way as in the QuadratureGenerator class, this class generates quadrature rules to integrate over 3 different regions of the face, :
+
+\]" src="form_2069.png"/>
-
which are again referred to as the "inside", , "outside", , and "surface" region, . These type of quadrature rules are in general needed in immersed discontinuous Galerkin methods.
-
Under the hood, this class uses the QuadratureGenerator class to build these rules. This is done by restricting the dim-dimensional level set function to the face, thus creating a (dim-1)-dimensional level set function, . It then creates the (dim-1)-dimensional quadratures by calling QuadratureGenerator with . This means that what holds for the QuadratureGenerator class in general also holds for this class. In particular, if the 1d-quadrature that is used as base contains points, the number of points will be proportional to in the in the inside/outside quadratures and to in the surface quadrature.
+
which are again referred to as the "inside", , "outside", , and "surface" region, . These type of quadrature rules are in general needed in immersed discontinuous Galerkin methods.
+
Under the hood, this class uses the QuadratureGenerator class to build these rules. This is done by restricting the dim-dimensional level set function to the face, thus creating a (dim-1)-dimensional level set function, . It then creates the (dim-1)-dimensional quadratures by calling QuadratureGenerator with . This means that what holds for the QuadratureGenerator class in general also holds for this class. In particular, if the 1d-quadrature that is used as base contains points, the number of points will be proportional to in the in the inside/outside quadratures and to in the surface quadrature.
This class defines a quadrature formula to integrate over the intersection between an oriented surface, , and a cell or face. The word "immersed" in the class name reflects that the surface may intersect the cell/face in an arbitrary way.
-
The spacedim template parameter of this class is the dimension that the (spacedim-1)-dimensional surface is embedded in: . The dim parameter describes the dimension of the "object" that the surface intersects. That is, dim = spacedim corresponds to the surface intersecting a cell and dim = spacedim - 1 corresponds to the surface intersecting a face. The quadrature formula is described by a set of quadrature points, , weights, , and normalized surface normals, .
-
Consider first the case dim = spacedim. We typically want to compute integrals in real space. A surface, , intersecting a cell, , in real space can be mapped onto a surface, , intersecting the unit cell, . Thus an integral over in real space can be transformed to an integral over according to
-, and a cell or face. The word "immersed" in the class name reflects that the surface may intersect the cell/face in an arbitrary way.
+
The spacedim template parameter of this class is the dimension that the (spacedim-1)-dimensional surface is embedded in: . The dim parameter describes the dimension of the "object" that the surface intersects. That is, dim = spacedim corresponds to the surface intersecting a cell and dim = spacedim - 1 corresponds to the surface intersecting a face. The quadrature formula is described by a set of quadrature points, , weights, , and normalized surface normals, .
+
Consider first the case dim = spacedim. We typically want to compute integrals in real space. A surface, , intersecting a cell, , in real space can be mapped onto a surface, , intersecting the unit cell, . Thus an integral over in real space can be transformed to an integral over according to
+
+\]" src="form_2043.png"/>
-
where is the mapping from reference to real space and is its Jacobian matrix. This transformation is possible since the continuous surface elements are vectors: , which are parallel to the normals of and . That is, the normal is needed to do the transformation. Thus, in addition to storing points and weights, this quadrature stores also the normalized normal for each quadrature point. This can be viewed as storing a discrete surface element,
- is the mapping from reference to real space and is its Jacobian matrix. This transformation is possible since the continuous surface elements are vectors: , which are parallel to the normals of and . That is, the normal is needed to do the transformation. Thus, in addition to storing points and weights, this quadrature stores also the normalized normal for each quadrature point. This can be viewed as storing a discrete surface element,
+
+\]" src="form_2046.png"/>
for each quadrature point. The surface integral in real space would then be approximated as
-
+\]" src="form_2047.png"/>
-
When dim = spacedim - 1, this class represents a (spacedim-2)-dimensional integral. That is, if spacedim = 3 we have a line integral immersed in a face. Let , be an arc-length parameterizations of , i.e., the part of the surface that intersects the face in reference space. This means that is a parameterization of . The transformation of the line integral now reads
-, be an arc-length parameterizations of , i.e., the part of the surface that intersects the face in reference space. This means that is a parameterization of . The transformation of the line integral now reads
+
+\]" src="form_2053.png"/>
-
where is the tangent to the curve at . This tangent can also be computed as where is the face normal. It would be possible to compute the tangent by only knowing the normal to the curve in the face plane (i.e. the dim-dimensional normal). However, when these quadratures are used, the weak form typically involves the so-called conormal, which can not be computed without knowing the surface normal in . The conormal is the unit vector parallel to the projection of the face normal into the surface plane. This is the same as the normalized boundary form.
+
where is the tangent to the curve at . This tangent can also be computed as where is the face normal. It would be possible to compute the tangent by only knowing the normal to the curve in the face plane (i.e. the dim-dimensional normal). However, when these quadratures are used, the weak form typically involves the so-called conormal, which can not be computed without knowing the surface normal in . The conormal is the unit vector parallel to the projection of the face normal into the surface plane. This is the same as the normalized boundary form.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classNonMatching_1_1QuadratureGenerator.html differs (JavaScript source, ASCII text, with very long lines (1947))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classNonMatching_1_1QuadratureGenerator.html 2023-11-25 15:25:56.979949318 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classNonMatching_1_1QuadratureGenerator.html 2023-11-25 15:25:56.979949318 +0100
@@ -130,24 +130,24 @@
Detailed Description
template<int dim>
-class NonMatching::QuadratureGenerator< dim >
This class creates immersed quadrature rules over a BoundingBox, , when the domain is described by a level set function, .
+class NonMatching::QuadratureGenerator< dim >
This class creates immersed quadrature rules over a BoundingBox, , when the domain is described by a level set function, .
This class creates quadrature rules for the intersections between the box and the three different regions defined by the level set function. That is, it creates quadrature rules to integrate over the following regions
-
+\]" src="form_2063.png"/>
-
When working with level set functions, the most common is to describe a domain, , as
-, as
+
+\]" src="form_2064.png"/>
-
Given this, we shall use the name convention that is the "inside" region (i.e. inside ), is the "outside" region and is the "surface" region. The "inside" and "outside" quadratures will also be referred to as the "bulk"-quadratures.
-
The underlying algorithm use a 1-dimensional quadrature rule as base for creating the immersed quadrature rules. Gauss-Legendre quadrature (QGauss) is recommended. The constructor takes an hp::QCollection<1>. One can select which 1d-quadrature in the collection should be used through the set_1d_quadrature() function. The number of quadrature points in the constructed quadratures will vary depending on the level set function. More quadrature points will be created if the intersection is "bad", for example, if the zero-contour has a high curvature compared to the size of the box. However, if the number of points in the 1d quadrature is the number of points will be proportional to in the bulk quadratures and to in the surface quadrature. For example, in the 2d-example in the above figure, there are 2 points in the 1d-quadrature. If the 1d-quadrature is a Gauss-Legendre quadrature and the grid has size , the immersed quadratures typically give global errors proportional to , both for the bulk and surface integrals. If the 1d-quadrature has positive weights, the weights of the immersed quadratures will also be positive.
+
Given this, we shall use the name convention that is the "inside" region (i.e. inside ), is the "outside" region and is the "surface" region. The "inside" and "outside" quadratures will also be referred to as the "bulk"-quadratures.
+
The underlying algorithm use a 1-dimensional quadrature rule as base for creating the immersed quadrature rules. Gauss-Legendre quadrature (QGauss) is recommended. The constructor takes an hp::QCollection<1>. One can select which 1d-quadrature in the collection should be used through the set_1d_quadrature() function. The number of quadrature points in the constructed quadratures will vary depending on the level set function. More quadrature points will be created if the intersection is "bad", for example, if the zero-contour has a high curvature compared to the size of the box. However, if the number of points in the 1d quadrature is the number of points will be proportional to in the bulk quadratures and to in the surface quadrature. For example, in the 2d-example in the above figure, there are 2 points in the 1d-quadrature. If the 1d-quadrature is a Gauss-Legendre quadrature and the grid has size , the immersed quadratures typically give global errors proportional to , both for the bulk and surface integrals. If the 1d-quadrature has positive weights, the weights of the immersed quadratures will also be positive.
A detailed description of the underlying algorithm can be found in "High-Order %Quadrature Methods for Implicitly Defined Surfaces and
Volumes in Hyperrectangles, R. I. Saye, SIAM J. Sci. Comput., 37(2), <a
href="http://www.dx.doi.org/10.1137/140966290">
@@ -254,7 +254,7 @@
-
Return the quadrature rule for the region created in the previous call to generate(). Here, is BoundingBox passed to generate().
+
Return the quadrature rule for the region created in the previous call to generate(). Here, is BoundingBox passed to generate().
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classNonMatching_1_1internal_1_1DiscreteQuadratureGeneratorImplementation_1_1RefSpaceFEFieldFunction.html differs (JavaScript source, ASCII text, with very long lines (870))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classNonMatching_1_1internal_1_1DiscreteQuadratureGeneratorImplementation_1_1RefSpaceFEFieldFunction.html 2023-11-25 15:25:56.999948914 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classNonMatching_1_1internal_1_1DiscreteQuadratureGeneratorImplementation_1_1RefSpaceFEFieldFunction.html 2023-11-25 15:25:56.999948914 +0100
@@ -228,10 +228,10 @@
template<int dim, class VectorType = Vector<double>>
class NonMatching::internal::DiscreteQuadratureGeneratorImplementation::RefSpaceFEFieldFunction< dim, VectorType >
This class evaluates a function defined by a solution vector and a DoFHandler transformed to reference space. To be precise, if we let be a point on the reference cell, this class implements the function
,
-
where are the local solution values and are the local reference space shape functions. The gradient and Hessian of this function are thus derivatives with respect to the reference space coordinates, .
+
where are the local solution values and are the local reference space shape functions. The gradient and Hessian of this function are thus derivatives with respect to the reference space coordinates, .
Note that this class is similar to FEFieldFunction, but that FEFieldFunction implements the following function on a given cell, ,
,
-
which has the same coefficients but uses real space basis functions. Here, is the mapping from the reference cell to the real cell.
+
which has the same coefficients but uses real space basis functions. Here, is the mapping from the reference cell to the real cell.
Before calling the value/gradient/hessian function, the set_active_cell function must be called to specify which cell the function should be evaluated on.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classNonMatching_1_1internal_1_1QuadratureGeneratorImplementation_1_1QGenerator.html differs (JavaScript source, ASCII text, with very long lines (1698))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classNonMatching_1_1internal_1_1QuadratureGeneratorImplementation_1_1QGenerator.html 2023-11-25 15:25:57.016615239 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classNonMatching_1_1internal_1_1QuadratureGeneratorImplementation_1_1QGenerator.html 2023-11-25 15:25:57.016615239 +0100
@@ -149,20 +149,20 @@
Detailed Description
template<int dim, int spacedim>
class NonMatching::internal::QuadratureGeneratorImplementation::QGenerator< dim, spacedim >
This class implements the Saye-algorithm cited in the documentation of the QuadratureGenerator class.
-
The generate function takes a number of -dimensional level set functions, , and a BoundingBox<dim>, and builds a partitioning of quadratures, as defined in documentation of the QPartitioning class. That is, this class builds an object of type QPartitioning<dim>.
-
If all passed to generate can be determined to be positive or negative definite, the QPartitioning will consist of a single quadrature forming a tensor product.
-
If this is not the case, the algorithm uses recursion over the spatial dimension. The spacedim template parameter denotes the dimension we started with and dim denotes on what level we are in the recursion. That is, we first construct a QPartitioning<dim - 1> and then build the higher dimensional quadratures from these. What we in the end actually want is a spacedim-dimensional partitioning of quadratures, for a single level set function, .
-
The algorithm is based on the implicit function theorem. Starting with a single level set function, , we try to find a direction , such that
-
.
+
The generate function takes a number of -dimensional level set functions, , and a BoundingBox<dim>, and builds a partitioning of quadratures, as defined in documentation of the QPartitioning class. That is, this class builds an object of type QPartitioning<dim>.
+
If all passed to generate can be determined to be positive or negative definite, the QPartitioning will consist of a single quadrature forming a tensor product.
+
If this is not the case, the algorithm uses recursion over the spatial dimension. The spacedim template parameter denotes the dimension we started with and dim denotes on what level we are in the recursion. That is, we first construct a QPartitioning<dim - 1> and then build the higher dimensional quadratures from these. What we in the end actually want is a spacedim-dimensional partitioning of quadratures, for a single level set function, .
+
The algorithm is based on the implicit function theorem. Starting with a single level set function, , we try to find a direction , such that
+
.
throughout the whole box. This means that the zero-contour of the level set function can be parameterized by an implicit function
-
,
+
,
so that
-
,
-
over a subset, , of the cross section, , of the box (see BoundingBox::cross_section). Here, is the "indefinite"-region defined in the QPartitioning class. To follow convention in the original paper, we will -refer to as the "height-function" and to as the "height-function direction".
-
If a height function direction can be found, we go down in dimension by creating two new level set functions, , which are the restriction of to the top and bottom faces of the box (in the height function direction). We then delegate to QGenerator<dim-1, spacedim> to create a QPartitioning<dim-1> over the cross section.
+
,
+
over a subset, , of the cross section, , of the box (see BoundingBox::cross_section). Here, is the "indefinite"-region defined in the QPartitioning class. To follow convention in the original paper, we will -refer to as the "height-function" and to as the "height-function direction".
+
If a height function direction can be found, we go down in dimension by creating two new level set functions, , which are the restriction of to the top and bottom faces of the box (in the height function direction). We then delegate to QGenerator<dim-1, spacedim> to create a QPartitioning<dim-1> over the cross section.
When we reach the base case, , the creation of QPartitioning<1> is simple. See the documentation in specialized class: QGenerator<1, spacedim>.
As we go up through the dimensions and create the higher dimensional quadratures, we need to know the function value of the height functions at the lower dimensional quadrature points. Since the functions are implicit, we need to do root-finding on the level set functions to find the function values. For this we use the class UpThroughDimensionCreator, see documentation there.
-
When we have level set functions (i.e. after having gone down in dimension), we try to find a height function direction, which works for all those which are intersected by the zero contour (i.e. those not positive or negative definite). If such a direction exist, we will have a maximum of associated implicit height functions, . Each parametrize the -coordinate of the zero-contour over a region, . The indefinite region in the lower dimensional partitioning is the union of these .
+
When we have level set functions (i.e. after having gone down in dimension), we try to find a height function direction, which works for all those which are intersected by the zero contour (i.e. those not positive or negative definite). If such a direction exist, we will have a maximum of associated implicit height functions, . Each parametrize the -coordinate of the zero-contour over a region, . The indefinite region in the lower dimensional partitioning is the union of these .
As we try to find a height function direction, we estimate bounds on the gradient components by approximating each component as a 1st-order Taylor-polynomial. If a direction can not be found, the box is split and we recurse on each smaller box. This makes an implicit function more likely to exist since we seek it over a smaller portion of the zero contour. It also makes the estimated bounds tighter since we extrapolate the Taylor-polynomial a shorter distance.
Since we can not split a box forever, there is an maximum number of allowed splits on the additional data struct passed to the constructor. If this is reached, the algorithm uses the midpoint method as a last resort.
@@ -346,7 +346,7 @@
-
Gets the -dimensional quadratures from the lower dimensional algorithm and creates the -dimensional quadrature rules over the box from the lower dimensional ones.
+
Gets the -dimensional quadratures from the lower dimensional algorithm and creates the -dimensional quadrature rules over the box from the lower dimensional ones.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classNonMatching_1_1internal_1_1QuadratureGeneratorImplementation_1_1QGenerator_3_011_00_01spacedim_01_4.html differs (JavaScript source, ASCII text, with very long lines (1964))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classNonMatching_1_1internal_1_1QuadratureGeneratorImplementation_1_1QGenerator_3_011_00_01spacedim_01_4.html 2023-11-25 15:25:57.029948303 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classNonMatching_1_1internal_1_1QuadratureGeneratorImplementation_1_1QGenerator_3_011_00_01spacedim_01_4.html 2023-11-25 15:25:57.029948303 +0100
@@ -150,8 +150,8 @@
Detailed Description
template<int spacedim>
class NonMatching::internal::QuadratureGeneratorImplementation::QGenerator< 1, spacedim >
The 1d-base case of the recursive algorithm QGenerator<dim, spacedim>.
-
Let and be the left and right bounds of the one-dimensional BoundingBox. This interval is partitioned into where , , and the remaining are the roots of the level set functions in the interval . In each interval, , quadrature points are distributed according to a 1d-quadrature rule. These points are added to one of the regions of QPartitioning determined from the signs of the level set functions on the interval (see documentation of QPartitioning).
-
If spacedim = 1 the points are also added as surface quadrature points to QPartitioning::surface.
+
Let and be the left and right bounds of the one-dimensional BoundingBox. This interval is partitioned into where , , and the remaining are the roots of the level set functions in the interval . In each interval, , quadrature points are distributed according to a 1d-quadrature rule. These points are added to one of the regions of QPartitioning determined from the signs of the level set functions on the interval (see documentation of QPartitioning).
+
If spacedim = 1 the points are also added as surface quadrature points to QPartitioning::surface.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classNonMatching_1_1internal_1_1QuadratureGeneratorImplementation_1_1QPartitioning.html differs (JavaScript source, ASCII text, with very long lines (1168))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classNonMatching_1_1internal_1_1QuadratureGeneratorImplementation_1_1QPartitioning.html 2023-11-25 15:25:57.043281364 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classNonMatching_1_1internal_1_1QuadratureGeneratorImplementation_1_1QPartitioning.html 2023-11-25 15:25:57.043281364 +0100
@@ -118,18 +118,18 @@
Detailed Description
template<int dim>
class NonMatching::internal::QuadratureGeneratorImplementation::QPartitioning< dim >
Class that stores quadrature rules to integrate over 4 different regions of a single BoundingBox, . Given multiple level set functions,
-
, ,
-
the box, , is partitioned into a "negative", "positive", and "indefinite" region, , according to the signs of over each region:
+
, ,
+
the box, , is partitioned into a "negative", "positive", and "indefinite" region, , according to the signs of over each region:
-
+\]" src="form_2088.png"/>
-
Thus, all are positive over and negative over . Over the level set functions differ in sign. This class holds quadrature rules for each of these regions. In addition, when there is a single level set function, , it holds a surface quadrature for the zero contour of :
-
.
-
Note that when there is a single level set function, is empty and and are the regions that one typically integrates over in an immersed finite element method.
+
Thus, all are positive over and negative over . Over the level set functions differ in sign. This class holds quadrature rules for each of these regions. In addition, when there is a single level set function, , it holds a surface quadrature for the zero contour of :
+
.
+
Note that when there is a single level set function, is empty and and are the regions that one typically integrates over in an immersed finite element method.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classNonMatching_1_1internal_1_1QuadratureGeneratorImplementation_1_1RootFinder.html differs (JavaScript source, ASCII text, with very long lines (1344))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classNonMatching_1_1internal_1_1QuadratureGeneratorImplementation_1_1RootFinder.html 2023-11-25 15:25:57.053281161 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classNonMatching_1_1internal_1_1QuadratureGeneratorImplementation_1_1RootFinder.html 2023-11-25 15:25:57.053281161 +0100
@@ -120,7 +120,7 @@
Detailed Description
-
A class that attempts to find multiple distinct roots of a function, , over an interval, . This is done as follows. If there is a sign change in function value between the interval end points, we solve for the root. If there is no sign change, we attempt to bound the function value away from zero on , to conclude that no roots exist. If we can't exclude that there are roots, we split the interval in two: , , and use the same algorithm recursively on each interval. This means that we can typically find 2 distinct roots, but not 3.
+
A class that attempts to find multiple distinct roots of a function, , over an interval, . This is done as follows. If there is a sign change in function value between the interval end points, we solve for the root. If there is no sign change, we attempt to bound the function value away from zero on , to conclude that no roots exist. If we can't exclude that there are roots, we split the interval in two: , , and use the same algorithm recursively on each interval. This means that we can typically find 2 distinct roots, but not 3.
The bounds on the functions values are estimated using the function taylor_estimate_function_bounds, which approximates the function as a second order Taylor-polynomial around the interval midpoint. When we have a sign change on an interval, this class uses boost::math::tools::toms748_solve for finding roots .
For each of the incoming functions, attempt to find the roots over the interval defined by interval and add these to roots. The returned roots will be sorted in ascending order: and duplicate roots (with respect to the tolerance in AdditionalData) will be removed.
+
For each of the incoming functions, attempt to find the roots over the interval defined by interval and add these to roots. The returned roots will be sorted in ascending order: and duplicate roots (with respect to the tolerance in AdditionalData) will be removed.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classNonMatching_1_1internal_1_1QuadratureGeneratorImplementation_1_1UpThroughDimensionCreator.html differs (JavaScript source, ASCII text, with very long lines (1787))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classNonMatching_1_1internal_1_1QuadratureGeneratorImplementation_1_1UpThroughDimensionCreator.html 2023-11-25 15:25:57.066614221 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classNonMatching_1_1internal_1_1QuadratureGeneratorImplementation_1_1UpThroughDimensionCreator.html 2023-11-25 15:25:57.066614221 +0100
@@ -129,13 +129,13 @@
Detailed Description
template<int dim, int spacedim>
-class NonMatching::internal::QuadratureGeneratorImplementation::UpThroughDimensionCreator< dim, spacedim >
This class is responsible for creating quadrature points for the -dimensional quadrature partitioning from an -dimensional "indefinite" quadrature (see QPartitioning documentation).
-
To be precise, let be the extents of the box in the height function direction and let be the lower dimensional indefinite region. This class will create quadrature points over and in the case , points for the surface quadrature.
-
For each lower dimensional quadrature point, in the indefinite quadrature, we create several 1d-level set functions by restricting to . We then partition the interval into , where , , and the remaining are the roots of the 1d-level set functions in . Since the level set functions change sign between the roots, each interval belong to different regions in the quadrature partitioning.
-
In each interval, , we distribute points according to the 1d-base quadrature, and take the cartesian product with to create the -dimensional quadrature points, : , .
-
When , we have a single level set function, . Since we have fulfilled the implicit function theorem, there is a single root . The point, , will be added as a point in the surface quadrature. One can show that the correct weight of this point is
This class is responsible for creating quadrature points for the -dimensional quadrature partitioning from an -dimensional "indefinite" quadrature (see QPartitioning documentation).
+
To be precise, let be the extents of the box in the height function direction and let be the lower dimensional indefinite region. This class will create quadrature points over and in the case , points for the surface quadrature.
+
For each lower dimensional quadrature point, in the indefinite quadrature, we create several 1d-level set functions by restricting to . We then partition the interval into , where , , and the remaining are the roots of the 1d-level set functions in . Since the level set functions change sign between the roots, each interval belong to different regions in the quadrature partitioning.
+
In each interval, , we distribute points according to the 1d-base quadrature, and take the cartesian product with to create the -dimensional quadrature points, : , .
+
When , we have a single level set function, . Since we have fulfilled the implicit function theorem, there is a single root . The point, , will be added as a point in the surface quadrature. One can show that the correct weight of this point is
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classNonlinearSolverSelector.html differs (JavaScript source, ASCII text, with very long lines (607))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classNonlinearSolverSelector.html 2023-11-25 15:25:57.083280550 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classNonlinearSolverSelector.html 2023-11-25 15:25:57.083280550 +0100
@@ -538,11 +538,11 @@
A function object that users may supply and that is intended to prepare the linear solver for subsequent calls to solve_jacobian_system().
The job of setup_jacobian() is to prepare the linear solver for subsequent calls to solve_with_jacobian(), in the solution of linear systems . The exact nature of this system depends on the SolutionStrategy that has been selected.
-
In the cases strategy = SolutionStrategy::newton or SolutionStrategy::linesearch, is the Jacobian . If strategy = SolutionStrategy::picard, is the approximate Jacobian matrix .
+
In the cases strategy = SolutionStrategy::newton or SolutionStrategy::linesearch, is the Jacobian . If strategy = SolutionStrategy::picard, is the approximate Jacobian matrix .
Parameters
-
current_u
Current value of
+
current_u
Current value of
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classNonlinearSolverSelector_1_1AdditionalData.html differs (JavaScript source, ASCII text, with very long lines (1630))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classNonlinearSolverSelector_1_1AdditionalData.html 2023-11-25 15:25:57.093280347 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classNonlinearSolverSelector_1_1AdditionalData.html 2023-11-25 15:25:57.093280347 +0100
@@ -361,7 +361,7 @@
-
Relative tolerance of the residual to be reached.
+
Relative tolerance of the residual to be reached.
Note
Solver terminates successfully if either the function tolerance or the relative tolerance has been reached.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classOpenCASCADE_1_1ArclengthProjectionLineManifold.html differs (JavaScript source, ASCII text, with very long lines (949))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classOpenCASCADE_1_1ArclengthProjectionLineManifold.html 2023-11-25 15:25:57.116613206 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classOpenCASCADE_1_1ArclengthProjectionLineManifold.html 2023-11-25 15:25:57.116613206 +0100
@@ -605,7 +605,7 @@
-
Given a point in the chartdim dimensional Euclidean space, this method returns the derivatives of the function that maps from the chartdim-dimensional to the spacedim-dimensional space. In other words, it is a matrix of size .
+
Given a point in the chartdim dimensional Euclidean space, this method returns the derivatives of the function that maps from the chartdim-dimensional to the spacedim-dimensional space. In other words, it is a matrix of size .
This function is used in the computations required by the get_tangent_vector() function. Since not all users of the Manifold class interface will require calling that function, the current function is implemented but will trigger an exception whenever called. This allows derived classes to avoid implementing the push_forward_gradient function if this functionality is not needed in the user program.
Refer to the general documentation of this class for more information.
@@ -644,24 +644,24 @@
-
Return a vector that, at , is tangential to the geodesic that connects two points . See the documentation of the Manifold class and of Manifold::get_tangent_vector() for a more detailed description.
-
For the current class, we assume that this geodesic is the image under the push_forward() operation of a straight line of the pre-images of x1 and x2 (where pre-images are computed by pulling back the locations x1 and x2). In other words, if these preimages are , then the geodesic in preimage (the chartdim-dimensional Euclidean) space is
-, is tangential to the geodesic that connects two points . See the documentation of the Manifold class and of Manifold::get_tangent_vector() for a more detailed description.
+
For the current class, we assume that this geodesic is the image under the push_forward() operation of a straight line of the pre-images of x1 and x2 (where pre-images are computed by pulling back the locations x1 and x2). In other words, if these preimages are , then the geodesic in preimage (the chartdim-dimensional Euclidean) space is
+
+\end{align*}" src="form_1440.png"/>
In image space, i.e., in the space in which we operate, this leads to the curve
-
+\end{align*}" src="form_1441.png"/>
-
What the current function is supposed to return is . By the chain rule, this is equal to
-. By the chain rule, this is equal to
+
+\end{align*}" src="form_1442.png"/>
This formula may then have to be slightly modified by considering any periodicity that was assumed in the call to the constructor.
-
Thus, the computation of tangent vectors also requires the implementation of derivatives of the push-forward mapping. Here, is a chartdim-dimensional vector, and is a spacedim-times-chartdim-dimensional matrix. Consequently, and as desired, the operation results in a spacedim-dimensional vector.
+
Thus, the computation of tangent vectors also requires the implementation of derivatives of the push-forward mapping. Here, is a chartdim-dimensional vector, and is a spacedim-times-chartdim-dimensional matrix. Consequently, and as desired, the operation results in a spacedim-dimensional vector.
Parameters
x1
The first point that describes the geodesic, and the one at which the "direction" is to be evaluated.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classOpenCASCADE_1_1DirectionalProjectionManifold.html differs (JavaScript source, ASCII text, with very long lines (899))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classOpenCASCADE_1_1DirectionalProjectionManifold.html 2023-11-25 15:25:57.136612799 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classOpenCASCADE_1_1DirectionalProjectionManifold.html 2023-11-25 15:25:57.136612799 +0100
@@ -540,7 +540,7 @@
-
Return a vector that, at , is tangential to the geodesic that connects two points . For the current class, we assume that the manifold is flat, so the geodesic is the straight line between the two points, and we return . The normalization of the vector is chosen so that it fits the convention described in Manifold::get_tangent_vector().
+
Return a vector that, at , is tangential to the geodesic that connects two points . For the current class, we assume that the manifold is flat, so the geodesic is the straight line between the two points, and we return . The normalization of the vector is chosen so that it fits the convention described in Manifold::get_tangent_vector().
Note
If you use this class as a stepping stone to build a manifold that only "slightly" deviates from a flat manifold, by overloading the project_to_manifold() function.
Parameters
@@ -549,7 +549,7 @@
-
Returns
A "direction" vector tangential to the geodesic. Here, this is , possibly modified by the periodicity of the domain as set in the constructor, to use the "shortest" connection between the points through the periodic boundary as necessary.
+
Returns
A "direction" vector tangential to the geodesic. Here, this is , possibly modified by the periodicity of the domain as set in the constructor, to use the "shortest" connection between the points through the periodic boundary as necessary.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classOpenCASCADE_1_1NURBSPatchManifold.html differs (JavaScript source, ASCII text, with very long lines (897))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classOpenCASCADE_1_1NURBSPatchManifold.html 2023-11-25 15:25:57.159945657 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classOpenCASCADE_1_1NURBSPatchManifold.html 2023-11-25 15:25:57.156612392 +0100
@@ -452,7 +452,7 @@
-
Given a point in the spacedim dimensional Euclidean space, this method returns the derivatives of the function that maps from the uv coordinate system to the Euclidean coordinate system. In other words, it is a matrix of size .
+
Given a point in the spacedim dimensional Euclidean space, this method returns the derivatives of the function that maps from the uv coordinate system to the Euclidean coordinate system. In other words, it is a matrix of size .
This function is used in the computations required by the get_tangent_vector() function.
Refer to the general documentation of this class for more information.
@@ -666,7 +666,7 @@
-
Given a point in the chartdim dimensional Euclidean space, this method returns the derivatives of the function that maps from the chartdim-dimensional to the spacedim-dimensional space. In other words, it is a matrix of size .
+
Given a point in the chartdim dimensional Euclidean space, this method returns the derivatives of the function that maps from the chartdim-dimensional to the spacedim-dimensional space. In other words, it is a matrix of size .
This function is used in the computations required by the get_tangent_vector() function. Since not all users of the Manifold class interface will require calling that function, the current function is implemented but will trigger an exception whenever called. This allows derived classes to avoid implementing the push_forward_gradient function if this functionality is not needed in the user program.
Refer to the general documentation of this class for more information.
@@ -705,24 +705,24 @@
-
Return a vector that, at , is tangential to the geodesic that connects two points . See the documentation of the Manifold class and of Manifold::get_tangent_vector() for a more detailed description.
-
For the current class, we assume that this geodesic is the image under the push_forward() operation of a straight line of the pre-images of x1 and x2 (where pre-images are computed by pulling back the locations x1 and x2). In other words, if these preimages are , then the geodesic in preimage (the chartdim-dimensional Euclidean) space is
-, is tangential to the geodesic that connects two points . See the documentation of the Manifold class and of Manifold::get_tangent_vector() for a more detailed description.
+
For the current class, we assume that this geodesic is the image under the push_forward() operation of a straight line of the pre-images of x1 and x2 (where pre-images are computed by pulling back the locations x1 and x2). In other words, if these preimages are , then the geodesic in preimage (the chartdim-dimensional Euclidean) space is
+
+\end{align*}" src="form_1440.png"/>
In image space, i.e., in the space in which we operate, this leads to the curve
-
+\end{align*}" src="form_1441.png"/>
-
What the current function is supposed to return is . By the chain rule, this is equal to
-. By the chain rule, this is equal to
+
+\end{align*}" src="form_1442.png"/>
This formula may then have to be slightly modified by considering any periodicity that was assumed in the call to the constructor.
-
Thus, the computation of tangent vectors also requires the implementation of derivatives of the push-forward mapping. Here, is a chartdim-dimensional vector, and is a spacedim-times-chartdim-dimensional matrix. Consequently, and as desired, the operation results in a spacedim-dimensional vector.
+
Thus, the computation of tangent vectors also requires the implementation of derivatives of the push-forward mapping. Here, is a chartdim-dimensional vector, and is a spacedim-times-chartdim-dimensional matrix. Consequently, and as desired, the operation results in a spacedim-dimensional vector.
Parameters
x1
The first point that describes the geodesic, and the one at which the "direction" is to be evaluated.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classOpenCASCADE_1_1NormalProjectionManifold.html differs (JavaScript source, ASCII text, with very long lines (899))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classOpenCASCADE_1_1NormalProjectionManifold.html 2023-11-25 15:25:57.179945250 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classOpenCASCADE_1_1NormalProjectionManifold.html 2023-11-25 15:25:57.179945250 +0100
@@ -534,7 +534,7 @@
-
Return a vector that, at , is tangential to the geodesic that connects two points . For the current class, we assume that the manifold is flat, so the geodesic is the straight line between the two points, and we return . The normalization of the vector is chosen so that it fits the convention described in Manifold::get_tangent_vector().
+
Return a vector that, at , is tangential to the geodesic that connects two points . For the current class, we assume that the manifold is flat, so the geodesic is the straight line between the two points, and we return . The normalization of the vector is chosen so that it fits the convention described in Manifold::get_tangent_vector().
Note
If you use this class as a stepping stone to build a manifold that only "slightly" deviates from a flat manifold, by overloading the project_to_manifold() function.
Parameters
@@ -543,7 +543,7 @@
-
Returns
A "direction" vector tangential to the geodesic. Here, this is , possibly modified by the periodicity of the domain as set in the constructor, to use the "shortest" connection between the points through the periodic boundary as necessary.
+
Returns
A "direction" vector tangential to the geodesic. Here, this is , possibly modified by the periodicity of the domain as set in the constructor, to use the "shortest" connection between the points through the periodic boundary as necessary.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classOpenCASCADE_1_1NormalToMeshProjectionManifold.html differs (JavaScript source, ASCII text, with very long lines (899))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classOpenCASCADE_1_1NormalToMeshProjectionManifold.html 2023-11-25 15:25:57.203278106 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classOpenCASCADE_1_1NormalToMeshProjectionManifold.html 2023-11-25 15:25:57.203278106 +0100
@@ -534,7 +534,7 @@
-
Return a vector that, at , is tangential to the geodesic that connects two points . For the current class, we assume that the manifold is flat, so the geodesic is the straight line between the two points, and we return . The normalization of the vector is chosen so that it fits the convention described in Manifold::get_tangent_vector().
+
Return a vector that, at , is tangential to the geodesic that connects two points . For the current class, we assume that the manifold is flat, so the geodesic is the straight line between the two points, and we return . The normalization of the vector is chosen so that it fits the convention described in Manifold::get_tangent_vector().
Note
If you use this class as a stepping stone to build a manifold that only "slightly" deviates from a flat manifold, by overloading the project_to_manifold() function.
Parameters
@@ -543,7 +543,7 @@
-
Returns
A "direction" vector tangential to the geodesic. Here, this is , possibly modified by the periodicity of the domain as set in the constructor, to use the "shortest" connection between the points through the periodic boundary as necessary.
+
Returns
A "direction" vector tangential to the geodesic. Here, this is , possibly modified by the periodicity of the domain as set in the constructor, to use the "shortest" connection between the points through the periodic boundary as necessary.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classPArpackSolver.html differs (JavaScript source, ASCII text, with very long lines (1026))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classPArpackSolver.html 2023-11-25 15:25:57.223277702 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classPArpackSolver.html 2023-11-25 15:25:57.223277702 +0100
@@ -272,7 +272,7 @@
Detailed Description
template<typename VectorType>
class PArpackSolver< VectorType >
Interface for using PARPACK. PARPACK is a collection of Fortran77 subroutines designed to solve large scale eigenvalue problems. Here we interface to the routines pdneupd, pdseupd, pdnaupd, pdsaupd of PARPACK. The package is designed to compute a few eigenvalues and corresponding eigenvectors of a general n by n matrix A. It is most appropriate for large sparse matrices A.
-
In this class we make use of the method applied to the generalized eigenspectrum problem , for ; where is a system matrix, is a mass matrix, and are a set of eigenvalues and eigenvectors respectively.
+
In this class we make use of the method applied to the generalized eigenspectrum problem , for ; where is a system matrix, is a mass matrix, and are a set of eigenvalues and eigenvectors respectively.
The ArpackSolver can be used in application codes in the following way:
for the generalized eigenvalue problem , where the variable size_of_spectrum tells PARPACK the number of eigenvector/eigenvalue pairs to solve for. Here, lambda is a vector that will contain the eigenvalues computed, x a vector of objects of type V that will contain the eigenvectors computed.
+
for the generalized eigenvalue problem , where the variable size_of_spectrum tells PARPACK the number of eigenvector/eigenvalue pairs to solve for. Here, lambda is a vector that will contain the eigenvalues computed, x a vector of objects of type V that will contain the eigenvectors computed.
Currently, only three modes of (P)Arpack are implemented. In mode 3 (default), OP is an inverse operation for the matrix A - sigma * B, where sigma is a shift value, set to zero by default. Whereas in mode 2, OP is an inverse of M. Finally, mode 1 corresponds to standard eigenvalue problem without spectral transformation . The mode can be specified via AdditionalData object. Note that for shift-and-invert (mode=3), the sought eigenpairs are those after the spectral transformation is applied.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classPETScWrappers_1_1CommunicationPattern.html differs (JavaScript source, ASCII text, with very long lines (696))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classPETScWrappers_1_1CommunicationPattern.html 2023-11-25 15:25:57.236610763 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classPETScWrappers_1_1CommunicationPattern.html 2023-11-25 15:25:57.236610763 +0100
@@ -318,7 +318,7 @@
Reinitialization that takes the number of locally-owned degrees of freedom local_size and an index set for the required ghost indices ghost_indices.
-
The local index range is translated to global indices in an ascending and one-to-one fashion, i.e., the indices of process sit exactly between the indices of the processes and , respectively.
+
The local index range is translated to global indices in an ascending and one-to-one fashion, i.e., the indices of process sit exactly between the indices of the processes and , respectively.
The export_to_ghost_array will populate an array containing values from locally-owned AND ghost indices, as for the relevant set of dofs of a usual FEM simulation.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classPETScWrappers_1_1FullMatrix.html differs (JavaScript source, ASCII text, with very long lines (829))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classPETScWrappers_1_1FullMatrix.html 2023-11-25 15:25:57.259943620 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classPETScWrappers_1_1FullMatrix.html 2023-11-25 15:25:57.259943620 +0100
@@ -1682,8 +1682,8 @@
-
Return the l1-norm of the matrix, that is , (max. sum of columns). This is the natural matrix norm that is compatible to the l1-norm for vectors, i.e. . (cf. Haemmerlin-Hoffmann: Numerische Mathematik)
+
Return the l1-norm of the matrix, that is , (max. sum of columns). This is the natural matrix norm that is compatible to the l1-norm for vectors, i.e. . (cf. Haemmerlin-Hoffmann: Numerische Mathematik)
Return the linfty-norm of the matrix, that is , (max. sum of rows). This is the natural matrix norm that is compatible to the linfty-norm of vectors, i.e. . (cf. Haemmerlin-Hoffmann: Numerische Mathematik)
+
Return the linfty-norm of the matrix, that is , (max. sum of rows). This is the natural matrix norm that is compatible to the linfty-norm of vectors, i.e. . (cf. Haemmerlin-Hoffmann: Numerische Mathematik)
Return the square of the norm of the vector with respect to the norm induced by this matrix, i.e. . This is useful, e.g. in the finite element context, where the norm of a function equals the matrix norm with respect to the mass matrix of the vector representing the nodal values of the finite element function.
+
Return the square of the norm of the vector with respect to the norm induced by this matrix, i.e. . This is useful, e.g. in the finite element context, where the norm of a function equals the matrix norm with respect to the mass matrix of the vector representing the nodal values of the finite element function.
Obviously, the matrix needs to be quadratic for this operation.
The implementation of this function is not as efficient as the one in the MatrixBase class used in deal.II (i.e. the original one, not the PETSc wrapper class) since PETSc doesn't support this operation and needs a temporary vector.
Note that if the current object represents a parallel distributed matrix (of type PETScWrappers::MPI::SparseMatrix), then the given vector has to be a distributed vector as well. Conversely, if the matrix is not distributed, then neither may the vector be.
@@ -1808,7 +1808,7 @@
-
Compute the matrix scalar product .
+
Compute the matrix scalar product .
The implementation of this function is not as efficient as the one in the MatrixBase class used in deal.II (i.e. the original one, not the PETSc wrapper class) since PETSc doesn't support this operation and needs a temporary vector.
Note that if the current object represents a parallel distributed matrix (of type PETScWrappers::MPI::SparseMatrix), then both vectors have to be distributed vectors as well. Conversely, if the matrix is not distributed, then neither of the vectors may be.
@@ -2315,7 +2315,7 @@
-
Test whether a matrix is symmetric. Default tolerance is -bit machine precision.
+
Test whether a matrix is symmetric. Default tolerance is -bit machine precision.
Base function to perform the matrix-matrix multiplication , or, if a vector whose size is compatible with B is given, , where defines a diagonal matrix with the vector entries.
-
This function assumes that the calling matrix and have compatible sizes. The size of will be set within this function.
-
The content as well as the sparsity pattern of the matrix will be reset by this function, so make sure that the sparsity pattern is not used somewhere else in your program. This is an expensive operation, so think twice before you use this function.
+
Base function to perform the matrix-matrix multiplication , or, if a vector whose size is compatible with B is given, , where defines a diagonal matrix with the vector entries.
+
This function assumes that the calling matrix and have compatible sizes. The size of will be set within this function.
+
The content as well as the sparsity pattern of the matrix will be reset by this function, so make sure that the sparsity pattern is not used somewhere else in your program. This is an expensive operation, so think twice before you use this function.
Base function to perform the matrix-matrix multiplication with the transpose of this, i.e., , or, if an optional vector whose size is compatible with is given, , where defines a diagonal matrix with the vector entries.
-
This function assumes that the calling matrix and have compatible sizes. The size of will be set within this function.
-
The content as well as the sparsity pattern of the matrix will be changed by this function, so make sure that the sparsity pattern is not used somewhere else in your program. This is an expensive operation, so think twice before you use this function.
+
Base function to perform the matrix-matrix multiplication with the transpose of this, i.e., , or, if an optional vector whose size is compatible with is given, , where defines a diagonal matrix with the vector entries.
+
This function assumes that the calling matrix and have compatible sizes. The size of will be set within this function.
+
The content as well as the sparsity pattern of the matrix will be changed by this function, so make sure that the sparsity pattern is not used somewhere else in your program. This is an expensive operation, so think twice before you use this function.
Adding Matrix-vector multiplication. Add on with being this matrix.
+
Adding Matrix-vector multiplication. Add on with being this matrix.
@@ -2420,7 +2420,7 @@
-
Compute the matrix scalar product .
+
Compute the matrix scalar product .
@@ -2941,7 +2941,7 @@
-
Matrix-vector multiplication: let with being this matrix.
+
Matrix-vector multiplication: let with being this matrix.
Due to problems with deriving template arguments between the block and non-block versions of the vmult/Tvmult functions, the actual functions are implemented in derived classes, with implementations forwarding the calls to the implementations provided here under a unique name for which template arguments can be derived by the compiler.
@@ -3089,7 +3089,7 @@
-
Matrix-vector multiplication: let with being this matrix. This function does the same as vmult() but takes the transposed matrix.
+
Matrix-vector multiplication: let with being this matrix. This function does the same as vmult() but takes the transposed matrix.
Due to problems with deriving template arguments between the block and non-block versions of the vmult/Tvmult functions, the actual functions are implemented in derived classes, with implementations forwarding the calls to the implementations provided here under a unique name for which template arguments can be derived by the compiler.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classPETScWrappers_1_1MPI_1_1BlockVector.html differs (JavaScript source, ASCII text, with very long lines (990))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classPETScWrappers_1_1MPI_1_1BlockVector.html 2023-11-25 15:25:57.319942401 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classPETScWrappers_1_1MPI_1_1BlockVector.html 2023-11-25 15:25:57.319942401 +0100
@@ -2055,7 +2055,7 @@
-
Return the square of the -norm.
+
Return the square of the -norm.
@@ -2107,7 +2107,7 @@
-
Return the -norm of the vector, i.e. the sum of the absolute values.
+
Return the -norm of the vector, i.e. the sum of the absolute values.
@@ -2133,7 +2133,7 @@
-
Return the -norm of the vector, i.e. the square root of the sum of the squares of the elements.
+
Return the -norm of the vector, i.e. the square root of the sum of the squares of the elements.
@@ -2159,7 +2159,7 @@
-
Return the maximum absolute value of the elements of this vector, which is the -norm of a vector.
+
Return the maximum absolute value of the elements of this vector, which is the -norm of a vector.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classPETScWrappers_1_1MPI_1_1SparseMatrix.html differs (JavaScript source, ASCII text, with very long lines (906))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classPETScWrappers_1_1MPI_1_1SparseMatrix.html 2023-11-25 15:25:57.346608523 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classPETScWrappers_1_1MPI_1_1SparseMatrix.html 2023-11-25 15:25:57.346608523 +0100
@@ -863,7 +863,7 @@
-
Return the square of the norm of the vector with respect to the norm induced by this matrix, i.e. . This is useful, e.g. in the finite element context, where the norm of a function equals the matrix norm with respect to the mass matrix of the vector representing the nodal values of the finite element function.
+
Return the square of the norm of the vector with respect to the norm induced by this matrix, i.e. . This is useful, e.g. in the finite element context, where the norm of a function equals the matrix norm with respect to the mass matrix of the vector representing the nodal values of the finite element function.
Obviously, the matrix needs to be quadratic for this operation.
The implementation of this function is not as efficient as the one in the MatrixBase class used in deal.II (i.e. the original one, not the PETSc wrapper class) since PETSc doesn't support this operation and needs a temporary vector.
@@ -894,7 +894,7 @@
-
Compute the matrix scalar product .
+
Compute the matrix scalar product .
The implementation of this function is not as efficient as the one in the MatrixBase class used in deal.II (i.e. the original one, not the PETSc wrapper class) since PETSc doesn't support this operation and needs a temporary vector.
Return the l1-norm of the matrix, that is , (max. sum of columns). This is the natural matrix norm that is compatible to the l1-norm for vectors, i.e. . (cf. Haemmerlin-Hoffmann: Numerische Mathematik)
+
Return the l1-norm of the matrix, that is , (max. sum of columns). This is the natural matrix norm that is compatible to the l1-norm for vectors, i.e. . (cf. Haemmerlin-Hoffmann: Numerische Mathematik)
Return the linfty-norm of the matrix, that is , (max. sum of rows). This is the natural matrix norm that is compatible to the linfty-norm of vectors, i.e. . (cf. Haemmerlin-Hoffmann: Numerische Mathematik)
+
Return the linfty-norm of the matrix, that is , (max. sum of rows). This is the natural matrix norm that is compatible to the linfty-norm of vectors, i.e. . (cf. Haemmerlin-Hoffmann: Numerische Mathematik)
Return the square of the norm of the vector with respect to the norm induced by this matrix, i.e. . This is useful, e.g. in the finite element context, where the norm of a function equals the matrix norm with respect to the mass matrix of the vector representing the nodal values of the finite element function.
+
Return the square of the norm of the vector with respect to the norm induced by this matrix, i.e. . This is useful, e.g. in the finite element context, where the norm of a function equals the matrix norm with respect to the mass matrix of the vector representing the nodal values of the finite element function.
Obviously, the matrix needs to be quadratic for this operation.
The implementation of this function is not as efficient as the one in the MatrixBase class used in deal.II (i.e. the original one, not the PETSc wrapper class) since PETSc doesn't support this operation and needs a temporary vector.
Note that if the current object represents a parallel distributed matrix (of type PETScWrappers::MPI::SparseMatrix), then the given vector has to be a distributed vector as well. Conversely, if the matrix is not distributed, then neither may the vector be.
@@ -2431,7 +2431,7 @@
-
Compute the matrix scalar product .
+
Compute the matrix scalar product .
The implementation of this function is not as efficient as the one in the MatrixBase class used in deal.II (i.e. the original one, not the PETSc wrapper class) since PETSc doesn't support this operation and needs a temporary vector.
Note that if the current object represents a parallel distributed matrix (of type PETScWrappers::MPI::SparseMatrix), then both vectors have to be distributed vectors as well. Conversely, if the matrix is not distributed, then neither of the vectors may be.
@@ -2938,7 +2938,7 @@
-
Test whether a matrix is symmetric. Default tolerance is -bit machine precision.
+
Test whether a matrix is symmetric. Default tolerance is -bit machine precision.
Base function to perform the matrix-matrix multiplication , or, if a vector whose size is compatible with B is given, , where defines a diagonal matrix with the vector entries.
-
This function assumes that the calling matrix and have compatible sizes. The size of will be set within this function.
-
The content as well as the sparsity pattern of the matrix will be reset by this function, so make sure that the sparsity pattern is not used somewhere else in your program. This is an expensive operation, so think twice before you use this function.
+
Base function to perform the matrix-matrix multiplication , or, if a vector whose size is compatible with B is given, , where defines a diagonal matrix with the vector entries.
+
This function assumes that the calling matrix and have compatible sizes. The size of will be set within this function.
+
The content as well as the sparsity pattern of the matrix will be reset by this function, so make sure that the sparsity pattern is not used somewhere else in your program. This is an expensive operation, so think twice before you use this function.
Base function to perform the matrix-matrix multiplication with the transpose of this, i.e., , or, if an optional vector whose size is compatible with is given, , where defines a diagonal matrix with the vector entries.
-
This function assumes that the calling matrix and have compatible sizes. The size of will be set within this function.
-
The content as well as the sparsity pattern of the matrix will be changed by this function, so make sure that the sparsity pattern is not used somewhere else in your program. This is an expensive operation, so think twice before you use this function.
+
Base function to perform the matrix-matrix multiplication with the transpose of this, i.e., , or, if an optional vector whose size is compatible with is given, , where defines a diagonal matrix with the vector entries.
+
This function assumes that the calling matrix and have compatible sizes. The size of will be set within this function.
+
The content as well as the sparsity pattern of the matrix will be changed by this function, so make sure that the sparsity pattern is not used somewhere else in your program. This is an expensive operation, so think twice before you use this function.
-norm of the vector. The sum of the absolute values.
+
-norm of the vector. The sum of the absolute values.
Note
In complex-valued PETSc priori to 3.7.0 this norm is implemented as the sum of absolute values of real and imaginary parts of elements of a complex vector.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classPETScWrappers_1_1MatrixBase.html differs (JavaScript source, ASCII text, with very long lines (844))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classPETScWrappers_1_1MatrixBase.html 2023-11-25 15:25:57.399940773 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classPETScWrappers_1_1MatrixBase.html 2023-11-25 15:25:57.399940773 +0100
@@ -1431,8 +1431,8 @@
-
Return the l1-norm of the matrix, that is , (max. sum of columns). This is the natural matrix norm that is compatible to the l1-norm for vectors, i.e. . (cf. Haemmerlin-Hoffmann: Numerische Mathematik)
+
Return the l1-norm of the matrix, that is , (max. sum of columns). This is the natural matrix norm that is compatible to the l1-norm for vectors, i.e. . (cf. Haemmerlin-Hoffmann: Numerische Mathematik)
Return the linfty-norm of the matrix, that is , (max. sum of rows). This is the natural matrix norm that is compatible to the linfty-norm of vectors, i.e. . (cf. Haemmerlin-Hoffmann: Numerische Mathematik)
+
Return the linfty-norm of the matrix, that is , (max. sum of rows). This is the natural matrix norm that is compatible to the linfty-norm of vectors, i.e. . (cf. Haemmerlin-Hoffmann: Numerische Mathematik)
Return the square of the norm of the vector with respect to the norm induced by this matrix, i.e. . This is useful, e.g. in the finite element context, where the norm of a function equals the matrix norm with respect to the mass matrix of the vector representing the nodal values of the finite element function.
+
Return the square of the norm of the vector with respect to the norm induced by this matrix, i.e. . This is useful, e.g. in the finite element context, where the norm of a function equals the matrix norm with respect to the mass matrix of the vector representing the nodal values of the finite element function.
Obviously, the matrix needs to be quadratic for this operation.
The implementation of this function is not as efficient as the one in the MatrixBase class used in deal.II (i.e. the original one, not the PETSc wrapper class) since PETSc doesn't support this operation and needs a temporary vector.
Note that if the current object represents a parallel distributed matrix (of type PETScWrappers::MPI::SparseMatrix), then the given vector has to be a distributed vector as well. Conversely, if the matrix is not distributed, then neither may the vector be.
@@ -1525,7 +1525,7 @@
-
Compute the matrix scalar product .
+
Compute the matrix scalar product .
The implementation of this function is not as efficient as the one in the MatrixBase class used in deal.II (i.e. the original one, not the PETSc wrapper class) since PETSc doesn't support this operation and needs a temporary vector.
Note that if the current object represents a parallel distributed matrix (of type PETScWrappers::MPI::SparseMatrix), then both vectors have to be distributed vectors as well. Conversely, if the matrix is not distributed, then neither of the vectors may be.
@@ -1933,7 +1933,7 @@
-
Test whether a matrix is symmetric. Default tolerance is -bit machine precision.
+
Test whether a matrix is symmetric. Default tolerance is -bit machine precision.
Base function to perform the matrix-matrix multiplication , or, if a vector whose size is compatible with B is given, , where defines a diagonal matrix with the vector entries.
-
This function assumes that the calling matrix and have compatible sizes. The size of will be set within this function.
-
The content as well as the sparsity pattern of the matrix will be reset by this function, so make sure that the sparsity pattern is not used somewhere else in your program. This is an expensive operation, so think twice before you use this function.
+
Base function to perform the matrix-matrix multiplication , or, if a vector whose size is compatible with B is given, , where defines a diagonal matrix with the vector entries.
+
This function assumes that the calling matrix and have compatible sizes. The size of will be set within this function.
+
The content as well as the sparsity pattern of the matrix will be reset by this function, so make sure that the sparsity pattern is not used somewhere else in your program. This is an expensive operation, so think twice before you use this function.
Base function to perform the matrix-matrix multiplication with the transpose of this, i.e., , or, if an optional vector whose size is compatible with is given, , where defines a diagonal matrix with the vector entries.
-
This function assumes that the calling matrix and have compatible sizes. The size of will be set within this function.
-
The content as well as the sparsity pattern of the matrix will be changed by this function, so make sure that the sparsity pattern is not used somewhere else in your program. This is an expensive operation, so think twice before you use this function.
+
Base function to perform the matrix-matrix multiplication with the transpose of this, i.e., , or, if an optional vector whose size is compatible with is given, , where defines a diagonal matrix with the vector entries.
+
This function assumes that the calling matrix and have compatible sizes. The size of will be set within this function.
+
The content as well as the sparsity pattern of the matrix will be changed by this function, so make sure that the sparsity pattern is not used somewhere else in your program. This is an expensive operation, so think twice before you use this function.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classPETScWrappers_1_1MatrixFree.html differs (JavaScript source, ASCII text, with very long lines (986))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classPETScWrappers_1_1MatrixFree.html 2023-11-25 15:25:57.429940162 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classPETScWrappers_1_1MatrixFree.html 2023-11-25 15:25:57.429940162 +0100
@@ -2235,8 +2235,8 @@
-
Return the l1-norm of the matrix, that is , (max. sum of columns). This is the natural matrix norm that is compatible to the l1-norm for vectors, i.e. . (cf. Haemmerlin-Hoffmann: Numerische Mathematik)
+
Return the l1-norm of the matrix, that is , (max. sum of columns). This is the natural matrix norm that is compatible to the l1-norm for vectors, i.e. . (cf. Haemmerlin-Hoffmann: Numerische Mathematik)
Return the linfty-norm of the matrix, that is , (max. sum of rows). This is the natural matrix norm that is compatible to the linfty-norm of vectors, i.e. . (cf. Haemmerlin-Hoffmann: Numerische Mathematik)
+
Return the linfty-norm of the matrix, that is , (max. sum of rows). This is the natural matrix norm that is compatible to the linfty-norm of vectors, i.e. . (cf. Haemmerlin-Hoffmann: Numerische Mathematik)
Return the square of the norm of the vector with respect to the norm induced by this matrix, i.e. . This is useful, e.g. in the finite element context, where the norm of a function equals the matrix norm with respect to the mass matrix of the vector representing the nodal values of the finite element function.
+
Return the square of the norm of the vector with respect to the norm induced by this matrix, i.e. . This is useful, e.g. in the finite element context, where the norm of a function equals the matrix norm with respect to the mass matrix of the vector representing the nodal values of the finite element function.
Obviously, the matrix needs to be quadratic for this operation.
The implementation of this function is not as efficient as the one in the MatrixBase class used in deal.II (i.e. the original one, not the PETSc wrapper class) since PETSc doesn't support this operation and needs a temporary vector.
Note that if the current object represents a parallel distributed matrix (of type PETScWrappers::MPI::SparseMatrix), then the given vector has to be a distributed vector as well. Conversely, if the matrix is not distributed, then neither may the vector be.
@@ -2361,7 +2361,7 @@
-
Compute the matrix scalar product .
+
Compute the matrix scalar product .
The implementation of this function is not as efficient as the one in the MatrixBase class used in deal.II (i.e. the original one, not the PETSc wrapper class) since PETSc doesn't support this operation and needs a temporary vector.
Note that if the current object represents a parallel distributed matrix (of type PETScWrappers::MPI::SparseMatrix), then both vectors have to be distributed vectors as well. Conversely, if the matrix is not distributed, then neither of the vectors may be.
@@ -2712,7 +2712,7 @@
-
Test whether a matrix is symmetric. Default tolerance is -bit machine precision.
+
Test whether a matrix is symmetric. Default tolerance is -bit machine precision.
Base function to perform the matrix-matrix multiplication , or, if a vector whose size is compatible with B is given, , where defines a diagonal matrix with the vector entries.
-
This function assumes that the calling matrix and have compatible sizes. The size of will be set within this function.
-
The content as well as the sparsity pattern of the matrix will be reset by this function, so make sure that the sparsity pattern is not used somewhere else in your program. This is an expensive operation, so think twice before you use this function.
+
Base function to perform the matrix-matrix multiplication , or, if a vector whose size is compatible with B is given, , where defines a diagonal matrix with the vector entries.
+
This function assumes that the calling matrix and have compatible sizes. The size of will be set within this function.
+
The content as well as the sparsity pattern of the matrix will be reset by this function, so make sure that the sparsity pattern is not used somewhere else in your program. This is an expensive operation, so think twice before you use this function.
Base function to perform the matrix-matrix multiplication with the transpose of this, i.e., , or, if an optional vector whose size is compatible with is given, , where defines a diagonal matrix with the vector entries.
-
This function assumes that the calling matrix and have compatible sizes. The size of will be set within this function.
-
The content as well as the sparsity pattern of the matrix will be changed by this function, so make sure that the sparsity pattern is not used somewhere else in your program. This is an expensive operation, so think twice before you use this function.
+
Base function to perform the matrix-matrix multiplication with the transpose of this, i.e., , or, if an optional vector whose size is compatible with is given, , where defines a diagonal matrix with the vector entries.
+
This function assumes that the calling matrix and have compatible sizes. The size of will be set within this function.
+
The content as well as the sparsity pattern of the matrix will be changed by this function, so make sure that the sparsity pattern is not used somewhere else in your program. This is an expensive operation, so think twice before you use this function.
In particular, the supported types are the ones that can wrap PETSc's native vector and matrix classes, that are able to modify them in place, and that can return PETSc native types when requested.
-
To use the solvers the user needs to provide the implementation of via the NonlinearSolver::residual callback.
+
To use the solvers the user needs to provide the implementation of via the NonlinearSolver::residual callback.
The default linearization procedure of a solver instantiated with this class consists in using Jacobian-Free-Newton-Krylov; the action of tangent matrices inside a linear solver process are approximated via matrix-free finite-differencing of the nonlinear residual equations. For details, consult the PETSc manual.
In alternative, users can also provide the implementation of the Jacobian. This can be accomplished in two ways:
This variable represents a user provided callback. See there for a description of how to deal with errors and other requirements and conventions.
@@ -636,7 +636,7 @@
Callback for the computation of the energy function.
-
This is usually not needed, since by default SNES assumes that the objective function to be minimized is .
+
This is usually not needed, since by default SNES assumes that the objective function to be minimized is .
However, if the nonlinear equations are derived from energy arguments, it may be useful to use this callback to perform linesearch or to test for the reduction in a trust region step.
The value of the energy function must be returned in energy_value.
Note
This variable represents a user provided callback. See there for a description of how to deal with errors and other requirements and conventions.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classPETScWrappers_1_1SparseMatrix.html differs (JavaScript source, ASCII text, with very long lines (949))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classPETScWrappers_1_1SparseMatrix.html 2023-11-25 15:25:57.473272612 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classPETScWrappers_1_1SparseMatrix.html 2023-11-25 15:25:57.473272612 +0100
@@ -890,7 +890,7 @@
Return the l1-norm of the matrix, that is , (max. sum of columns). This is the natural matrix norm that is compatible to the l1-norm for vectors, i.e. . (cf. Haemmerlin-Hoffmann: Numerische Mathematik)
+
Return the l1-norm of the matrix, that is , (max. sum of columns). This is the natural matrix norm that is compatible to the l1-norm for vectors, i.e. . (cf. Haemmerlin-Hoffmann: Numerische Mathematik)
Return the linfty-norm of the matrix, that is , (max. sum of rows). This is the natural matrix norm that is compatible to the linfty-norm of vectors, i.e. . (cf. Haemmerlin-Hoffmann: Numerische Mathematik)
+
Return the linfty-norm of the matrix, that is , (max. sum of rows). This is the natural matrix norm that is compatible to the linfty-norm of vectors, i.e. . (cf. Haemmerlin-Hoffmann: Numerische Mathematik)
Return the square of the norm of the vector with respect to the norm induced by this matrix, i.e. . This is useful, e.g. in the finite element context, where the norm of a function equals the matrix norm with respect to the mass matrix of the vector representing the nodal values of the finite element function.
+
Return the square of the norm of the vector with respect to the norm induced by this matrix, i.e. . This is useful, e.g. in the finite element context, where the norm of a function equals the matrix norm with respect to the mass matrix of the vector representing the nodal values of the finite element function.
Obviously, the matrix needs to be quadratic for this operation.
The implementation of this function is not as efficient as the one in the MatrixBase class used in deal.II (i.e. the original one, not the PETSc wrapper class) since PETSc doesn't support this operation and needs a temporary vector.
Note that if the current object represents a parallel distributed matrix (of type PETScWrappers::MPI::SparseMatrix), then the given vector has to be a distributed vector as well. Conversely, if the matrix is not distributed, then neither may the vector be.
@@ -2325,7 +2325,7 @@
-
Compute the matrix scalar product .
+
Compute the matrix scalar product .
The implementation of this function is not as efficient as the one in the MatrixBase class used in deal.II (i.e. the original one, not the PETSc wrapper class) since PETSc doesn't support this operation and needs a temporary vector.
Note that if the current object represents a parallel distributed matrix (of type PETScWrappers::MPI::SparseMatrix), then both vectors have to be distributed vectors as well. Conversely, if the matrix is not distributed, then neither of the vectors may be.
@@ -2832,7 +2832,7 @@
-
Test whether a matrix is symmetric. Default tolerance is -bit machine precision.
+
Test whether a matrix is symmetric. Default tolerance is -bit machine precision.
Base function to perform the matrix-matrix multiplication , or, if a vector whose size is compatible with B is given, , where defines a diagonal matrix with the vector entries.
-
This function assumes that the calling matrix and have compatible sizes. The size of will be set within this function.
-
The content as well as the sparsity pattern of the matrix will be reset by this function, so make sure that the sparsity pattern is not used somewhere else in your program. This is an expensive operation, so think twice before you use this function.
+
Base function to perform the matrix-matrix multiplication , or, if a vector whose size is compatible with B is given, , where defines a diagonal matrix with the vector entries.
+
This function assumes that the calling matrix and have compatible sizes. The size of will be set within this function.
+
The content as well as the sparsity pattern of the matrix will be reset by this function, so make sure that the sparsity pattern is not used somewhere else in your program. This is an expensive operation, so think twice before you use this function.
Base function to perform the matrix-matrix multiplication with the transpose of this, i.e., , or, if an optional vector whose size is compatible with is given, , where defines a diagonal matrix with the vector entries.
-
This function assumes that the calling matrix and have compatible sizes. The size of will be set within this function.
-
The content as well as the sparsity pattern of the matrix will be changed by this function, so make sure that the sparsity pattern is not used somewhere else in your program. This is an expensive operation, so think twice before you use this function.
+
Base function to perform the matrix-matrix multiplication with the transpose of this, i.e., , or, if an optional vector whose size is compatible with is given, , where defines a diagonal matrix with the vector entries.
+
This function assumes that the calling matrix and have compatible sizes. The size of will be set within this function.
+
The content as well as the sparsity pattern of the matrix will be changed by this function, so make sure that the sparsity pattern is not used somewhere else in your program. This is an expensive operation, so think twice before you use this function.
Interface to the PETSc TS solver for Ordinary Differential Equations and Differential-Algebraic Equations. The TS solver is described in the PETSc manual.
This class supports two kinds of formulations. The explicit formulation:
-
+\]" src="form_1737.png"/>
and the implicit formulation:
-
+\]" src="form_1738.png"/>
The interface to PETSc is realized by means of std::function callbacks like in the SUNDIALS::IDA and SUNDIALS::ARKode classes.
TimeStepper supports any vector and matrix type having constructors and methods:
@@ -207,7 +207,7 @@
Mat & petsc_matrix();
...
In particular, the supported types are the ones that can wrap PETSc's native vector and matrix classes, that are able to modify them in place, and that can return PETSc native types when requested.
-
To use explicit solvers (like for example explicit Runge-Kutta methods), the user only needs to provide the implementation of via the TimeStepper::explicit_function. For implicit solvers, users have also the alternative of providing the function via TimeStepper::implicit_function. IMEX methods are also supported by providing both callbacks.
+
To use explicit solvers (like for example explicit Runge-Kutta methods), the user only needs to provide the implementation of via the TimeStepper::explicit_function. For implicit solvers, users have also the alternative of providing the function via TimeStepper::implicit_function. IMEX methods are also supported by providing both callbacks.
The default linearization procedure of an implicit solver instantiated with this class consists in using Jacobian-Free-Newton-Krylov; the action of tangent matrices inside a linear solver process are approximated via matrix-free finite-differencing of the nonlinear residual equations that are ODE-solver specific. For details, consult the PETSc manual.
In alternative, users can also provide the implementations of the Jacobians. This can be accomplished in two ways:
-norm of the vector. The sum of the absolute values.
+
-norm of the vector. The sum of the absolute values.
Note
In complex-valued PETSc priori to 3.7.0 this norm is implemented as the sum of absolute values of real and imaginary parts of elements of a complex vector.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classParticles_1_1ParticleHandler.html differs (JavaScript source, ASCII text, with very long lines (1085))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classParticles_1_1ParticleHandler.html 2023-11-25 15:25:57.563270783 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classParticles_1_1ParticleHandler.html 2023-11-25 15:25:57.563270783 +0100
@@ -1022,7 +1022,7 @@
Insert a particle into the collection of particles. Return an iterator to the new position of the particle. This function involves a copy of the particle and its properties. Note that this function is of complexity for particles.
+N)$" src="form_2421.png"/> complexity for particles.
List from the active cells on the present MPI process to positions in either owned_particles or ghost_particles for fast access to the particles of a cell.
+
List from the active cells on the present MPI process to positions in either owned_particles or ghost_particles for fast access to the particles of a cell.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classParticles_1_1PropertyPool.html differs (JavaScript source, ASCII text, with very long lines (683))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classParticles_1_1PropertyPool.html 2023-11-25 15:25:57.579937108 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classParticles_1_1PropertyPool.html 2023-11-25 15:25:57.579937108 +0100
@@ -646,7 +646,7 @@
-
This function makes sure that all internally stored memory blocks are sorted in the same order as one would loop over the handles_to_sort container. This makes sure memory access is contiguous with actual memory location. Because the ordering is given in the input argument the complexity of this function is where is the number of elements in the input argument.
+
This function makes sure that all internally stored memory blocks are sorted in the same order as one would loop over the handles_to_sort container. This makes sure memory access is contiguous with actual memory location. Because the ordering is given in the input argument the complexity of this function is where is the number of elements in the input argument.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classPersistentTriangulation.html differs (JavaScript source, ASCII text, with very long lines (748))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classPersistentTriangulation.html 2023-11-25 15:25:57.633269358 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classPersistentTriangulation.html 2023-11-25 15:25:57.633269358 +0100
@@ -1820,7 +1820,7 @@
-
Refine all cells times times. In other words, in each one of the times iterations, loop over all cells and refine each cell uniformly into children. In practice, this function repeats the following operations times times: call set_all_refine_flags() followed by execute_coarsening_and_refinement(). The end result is that the number of cells increases by a factor of .
+
Refine all cells times times. In other words, in each one of the times iterations, loop over all cells and refine each cell uniformly into children. In practice, this function repeats the following operations times times: call set_all_refine_flags() followed by execute_coarsening_and_refinement(). The end result is that the number of cells increases by a factor of .
The execute_coarsening_and_refinement() function called in this loop may throw an exception if it creates cells that are distorted (see its documentation for an explanation). This exception will be propagated through this function if that happens, and you may not get the actual number of refinement steps in that case.
Note
This function triggers the pre- and post-refinement signals before and after doing each individual refinement cycle (i.e. more than once if times > 1) . See the section on signals in the general documentation of this class.
@@ -6233,7 +6233,7 @@
-
Iterator to the first quad, used or not, on the given level. If a level has no quads, a past-the-end iterator is returned. If quads are no cells, i.e. for no level argument must be given.
+
Iterator to the first quad, used or not, on the given level. If a level has no quads, a past-the-end iterator is returned. If quads are no cells, i.e. for no level argument must be given.
Note
The given level argument needs to correspond to a level of the triangulation, i.e., should be less than the value returned by n_levels(). On the other hand, for parallel computations using a parallel::distributed::Triangulation object, it is often convenient to write loops over the cells of all levels of the global mesh, even if the local portion of the triangulation does not actually have cells at one of the higher levels. In those cases, the level argument is accepted if it is less than what the n_global_levels() function returns. If the given level is between the values returned by n_levels() and n_global_levels(), then no cells exist in the local portion of the triangulation at this level, and the function simply returns what end() would return.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classPhysics_1_1Elasticity_1_1StandardTensors.html differs (JavaScript source, ASCII text, with very long lines (527))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classPhysics_1_1Elasticity_1_1StandardTensors.html 2023-11-25 15:25:57.646602418 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classPhysics_1_1Elasticity_1_1StandardTensors.html 2023-11-25 15:25:57.646602418 +0100
@@ -158,47 +158,47 @@
Return the fourth-order referential deviatoric tensor, as constructed from the deformation gradient tensor F. Also known as the deviatoric operator, this tensor projects a second-order symmetric tensor onto a deviatoric space (for which the hydrostatic component is removed).
This referential isochoric projection tensor is defined as
-
+\]" src="form_2453.png"/>
with
-
+\]" src="form_2454.png"/>
such that, for any second-order (referential) symmetric tensor, the following holds:
-
+\]" src="form_2455.png"/>
It can therefore be readily shown that
-
+\]" src="form_2456.png"/>
Note
It may be observed that we have defined the tensor as the transpose of that adopted by Wriggers (2008). We have done this so that it may be strictly applied through the chain rule to achieve the definition of the second Piola-Kirchhoff stress, i.e.
-
+\]" src="form_2457.png"/>
-Comparing the definition of this tensor in Holzapfel (2001) to that adopted here, the inclusion of the extra factor does not, at the outset, seem to be a reasonable choice. However, in the author's view it makes direct implementation of the expressions for isochoric (referential) stress contributions and their linearization simpler in practise.
+Comparing the definition of this tensor in Holzapfel (2001) to that adopted here, the inclusion of the extra factor does not, at the outset, seem to be a reasonable choice. However, in the author's view it makes direct implementation of the expressions for isochoric (referential) stress contributions and their linearization simpler in practise.
For a discussion of the background of this function, see P. Wriggers: "Nonlinear finite element methods" (2008), and in particular formula (3.125) on p. 46 (or thereabouts).
@@ -233,12 +233,12 @@
Return the transpose of the fourth-order referential deviatoric tensor, as constructed from the deformation gradient tensor F. The result performs the following operation:
-
+\]" src="form_2459.png"/>
@@ -269,16 +269,16 @@
-
Return the derivative of the volumetric Jacobian with respect to the right Cauchy-Green tensor, as constructed from the deformation gradient tensor F. The computed result is
- with respect to the right Cauchy-Green tensor, as constructed from the deformation gradient tensor F. The computed result is
+
+\]" src="form_2461.png"/>
with
-
+\]" src="form_2462.png"/>
Note
For a discussion of the background of this function, see P. Wriggers: "Nonlinear finite element methods" (2008), and in particular formula (3.124) on p. 46 (or thereabouts).
@@ -348,12 +348,12 @@
The second-order referential/spatial symmetric identity (metric) tensor .
This is defined such that, for any rank-2 tensor or symmetric tensor, the following holds:
-
+\]" src="form_2443.png"/>
This definition aligns with the rank-2 symmetric tensor returned by unit_symmetric_tensor(). If one is to interpret the tensor as a matrix, then this simply corresponds to the identity matrix.
@@ -383,20 +383,20 @@
The fourth-order referential/spatial unit symmetric tensor .
-
This is defined such that for a general rank-2 tensor the following holds:
- the following holds:
+
+\]" src="form_2445.png"/>
-
As a corollary to this, for any second-order symmetric tensor
-
+
+\]" src="form_2447.png"/>
This definition aligns with the fourth-order symmetric tensor introduced in the Physics::Elasticity namespace description and that which is returned by identity_tensor().
Note
If you apply this to a standard tensor then it doesn't behave like the fourth-order identity tensor, but rather as a symmetrization operator.
The fourth-order spatial deviatoric tensor. Also known as the deviatoric operator, this tensor projects a second-order symmetric tensor onto a deviatoric space (for which the hydrostatic component is removed).
This is defined as
-
+\]" src="form_2450.png"/>
where is the fourth-order unit symmetric tensor and is the second-order identity tensor.
For any second-order (spatial) symmetric tensor the following holds:
-
+\]" src="form_2451.png"/>
and, therefore,
-
+\]" src="form_2452.png"/>
This definition aligns with the fourth-order symmetric tensor that is returned by deviator_tensor().
Note
For a discussion of the background of this function, see P. Wriggers: "Nonlinear finite element methods" (2008), and in particular formula (3.129) on p. 47 (or thereabouts).
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classPoint.html differs (JavaScript source, ASCII text, with very long lines (912))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classPoint.html 2023-11-25 15:25:57.669935279 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classPoint.html 2023-11-25 15:25:57.669935279 +0100
@@ -811,7 +811,7 @@
-
Return the Euclidean distance of this point to the point p, i.e. the norm of the difference between the vectors representing the two points.
+
Return the Euclidean distance of this point to the point p, i.e. the norm of the difference between the vectors representing the two points.
The dot product (single contraction) for tensors. This function return a tensor of rank that is the contraction of the last index of a tensor src1 of rank rank_1 with the first index of a tensor src2 of rank rank_2:
- that is the contraction of the last index of a tensor src1 of rank rank_1 with the first index of a tensor src2 of rank rank_2:
+
+\]" src="form_827.png"/>
Note
For the Tensor class, the multiplication operator only performs a contraction over a single pair of indices. This is in contrast to the multiplication operator for SymmetricTensor, for which the corresponding operator*() performs a double contraction. The origin of the difference in how operator*() is implemented between Tensor and SymmetricTensor is that for the former, the product between two Tensor objects of same rank and dimension results in another Tensor object – that it, operator*() corresponds to the multiplicative group action within the group of tensors. On the other hand, there is no corresponding multiplicative group action with the set of symmetric tensors because, in general, the product of two symmetric tensors is a nonsymmetric tensor. As a consequence, for a mathematician, it is clear that operator*() for symmetric tensors must have a different meaning: namely the dot or scalar product that maps two symmetric tensors of rank 2 to a scalar. This corresponds to the double-dot (colon) operator whose meaning is then extended to the product of any two even-ranked symmetric tensors.
-In case the contraction yields a tensor of rank 0, that is, if rank_1==rank_2==1, then a scalar number is returned as an unwrapped number type. Return the norm of the given rank-2 tensor, where (maximum of the sums over columns).
+In case the contraction yields a tensor of rank 0, that is, if rank_1==rank_2==1, then a scalar number is returned as an unwrapped number type. Return the norm of the given rank-2 tensor, where (maximum of the sums over columns).
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classPolarManifold.html differs (JavaScript source, ASCII text, with very long lines (1036))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classPolarManifold.html 2023-11-25 15:25:57.693268137 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classPolarManifold.html 2023-11-25 15:25:57.693268137 +0100
@@ -439,7 +439,7 @@
-
Given a point in the spacedim dimensional Euclidean space, this method returns the derivatives of the function that maps from the polar coordinate system to the Euclidean coordinate system. In other words, it is a matrix of size .
+
Given a point in the spacedim dimensional Euclidean space, this method returns the derivatives of the function that maps from the polar coordinate system to the Euclidean coordinate system. In other words, it is a matrix of size .
This function is used in the computations required by the get_tangent_vector() function.
Refer to the general documentation of this class for more information.
@@ -713,7 +713,7 @@
-
Given a point in the chartdim dimensional Euclidean space, this method returns the derivatives of the function that maps from the chartdim-dimensional to the spacedim-dimensional space. In other words, it is a matrix of size .
+
Given a point in the chartdim dimensional Euclidean space, this method returns the derivatives of the function that maps from the chartdim-dimensional to the spacedim-dimensional space. In other words, it is a matrix of size .
This function is used in the computations required by the get_tangent_vector() function. Since not all users of the Manifold class interface will require calling that function, the current function is implemented but will trigger an exception whenever called. This allows derived classes to avoid implementing the push_forward_gradient function if this functionality is not needed in the user program.
Refer to the general documentation of this class for more information.
@@ -756,24 +756,24 @@
-
Return a vector that, at , is tangential to the geodesic that connects two points . See the documentation of the Manifold class and of Manifold::get_tangent_vector() for a more detailed description.
-
For the current class, we assume that this geodesic is the image under the push_forward() operation of a straight line of the pre-images of x1 and x2 (where pre-images are computed by pulling back the locations x1 and x2). In other words, if these preimages are , then the geodesic in preimage (the chartdim-dimensional Euclidean) space is
-, is tangential to the geodesic that connects two points . See the documentation of the Manifold class and of Manifold::get_tangent_vector() for a more detailed description.
+
For the current class, we assume that this geodesic is the image under the push_forward() operation of a straight line of the pre-images of x1 and x2 (where pre-images are computed by pulling back the locations x1 and x2). In other words, if these preimages are , then the geodesic in preimage (the chartdim-dimensional Euclidean) space is
+
+\end{align*}" src="form_1440.png"/>
In image space, i.e., in the space in which we operate, this leads to the curve
-
+\end{align*}" src="form_1441.png"/>
-
What the current function is supposed to return is . By the chain rule, this is equal to
-. By the chain rule, this is equal to
+
+\end{align*}" src="form_1442.png"/>
This formula may then have to be slightly modified by considering any periodicity that was assumed in the call to the constructor.
-
Thus, the computation of tangent vectors also requires the implementation of derivatives of the push-forward mapping. Here, is a chartdim-dimensional vector, and is a spacedim-times-chartdim-dimensional matrix. Consequently, and as desired, the operation results in a spacedim-dimensional vector.
+
Thus, the computation of tangent vectors also requires the implementation of derivatives of the push-forward mapping. Here, is a chartdim-dimensional vector, and is a spacedim-times-chartdim-dimensional matrix. Consequently, and as desired, the operation results in a spacedim-dimensional vector.
Parameters
x1
The first point that describes the geodesic, and the one at which the "direction" is to be evaluated.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classPolynomialsBernardiRaugel.html differs (JavaScript source, Unicode text, UTF-8 text, with very long lines (1174))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classPolynomialsBernardiRaugel.html 2023-11-25 15:25:57.706601197 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classPolynomialsBernardiRaugel.html 2023-11-25 15:25:57.706601197 +0100
@@ -142,7 +142,7 @@
template<int dim>
class PolynomialsBernardiRaugel< dim >
This class implements the Bernardi-Raugel polynomials similarly to the description in the Mathematics of Computation paper from 1985 by Christine Bernardi and Geneviève Raugel.
The Bernardi-Raugel polynomials are originally defined as an enrichment of the elements on simplicial meshes for Stokes problems by the addition of bubble functions, yielding a locking-free finite element which is a subset of elements. This implementation is an enrichment of elements which is a subset of elements for quadrilateral and hexahedral meshes.
-
The bubble functions are defined to have magnitude 1 at the center of face and direction normal to face , and magnitude 0 on all other vertices and faces. Ordering is consistent with the face numbering in GeometryInfo. The vector points in the positive axis direction and not necessarily normal to the element for consistent orientation across edges.
+
The bubble functions are defined to have magnitude 1 at the center of face and direction normal to face , and magnitude 0 on all other vertices and faces. Ordering is consistent with the face numbering in GeometryInfo. The vector points in the positive axis direction and not necessarily normal to the element for consistent orientation across edges.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classPolynomialsRT__Bubbles.html differs (JavaScript source, ASCII text, with very long lines (965))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classPolynomialsRT__Bubbles.html 2023-11-25 15:25:57.739933854 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classPolynomialsRT__Bubbles.html 2023-11-25 15:25:57.739933854 +0100
@@ -138,18 +138,18 @@
This space is of the form Vk = RTk-1 + Bk, where Bk is defined as follows:
In 2d:
-
+\end{align*}" src="form_706.png"/>
In 3d:
-
+ \end{align*}" src="form_707.png"/>
-
where .
+
where .
Note
Unlike the classical Raviart-Thomas space, the lowest order for the enhanced space is 1, similarly to the Brezzi-Douglas-Marini (BDM) polynomial space.
The total dimension of the space dim(Vk) = d*(k+1)^d, where d is the space dimension. This allows to associate shape functions with the Gauss-Lobatto quadrature points as shown in the figures below.
These polynomials are the integrated Legendre polynomials on [0,1]. The first two polynomials are the standard linear shape functions given by and . For we use the definition , where denotes the -th Legendre polynomial on . The Lobatto polynomials form a complete basis of the polynomials space of degree .
+
These polynomials are the integrated Legendre polynomials on [0,1]. The first two polynomials are the standard linear shape functions given by and . For we use the definition , where denotes the -th Legendre polynomial on . The Lobatto polynomials form a complete basis of the polynomials space of degree .
Calling the constructor with a given index k will generate the polynomial with index k. But only for the index equals the degree of the polynomial. For k==0 also a polynomial of degree 1 is generated.
These polynomials are used for the construction of the shape functions of Nédélec elements of arbitrary order.
@@ -1278,7 +1278,7 @@
-
If the polynomial is in Lagrange product form, i.e., constructed as a product , store the shifts .
+
If the polynomial is in Lagrange product form, i.e., constructed as a product , store the shifts .
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classPolynomials_1_1PiecewisePolynomial.html differs (JavaScript source, ASCII text, with very long lines (908))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classPolynomials_1_1PiecewisePolynomial.html 2023-11-25 15:25:57.879931003 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classPolynomials_1_1PiecewisePolynomial.html 2023-11-25 15:25:57.879931003 +0100
@@ -192,7 +192,7 @@
Detailed Description
template<typename number>
-class Polynomials::PiecewisePolynomial< number >
Definition of piecewise 1d polynomials for the unit interval. This space allows the description of interpolating polynomials on parts of the unit interval, similarly to the definition of finite element basis functions on subdivided elements. The primary purpose of this class is to allow constructing the shape functions of the FE_Q_iso_Q1 class that has a number of interpolation points in each coordinate direction, but instead of using them for higher-order polynomials just chooses piecewise linear shape functions – in effect, it is a element defined on a subdivision of the reference cell, and replicated on each of these sub-cells.
+class Polynomials::PiecewisePolynomial< number >
Definition of piecewise 1d polynomials for the unit interval. This space allows the description of interpolating polynomials on parts of the unit interval, similarly to the definition of finite element basis functions on subdivided elements. The primary purpose of this class is to allow constructing the shape functions of the FE_Q_iso_Q1 class that has a number of interpolation points in each coordinate direction, but instead of using them for higher-order polynomials just chooses piecewise linear shape functions – in effect, it is a element defined on a subdivision of the reference cell, and replicated on each of these sub-cells.
This class is not derived from the ScalarPolynomialsBase base class because it is not actually a polynomial – it is a piecewise polynomial. However, it is interface-compatible with the Polynomials::Polynomial class, and consequently can be used as template argument for TensorProductPolynomials.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classPolynomials_1_1PolynomialsHermite.html differs (JavaScript source, ASCII text, with very long lines (3111))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classPolynomials_1_1PolynomialsHermite.html 2023-11-25 15:25:57.916596925 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classPolynomials_1_1PolynomialsHermite.html 2023-11-25 15:25:57.916596925 +0100
@@ -225,8 +225,8 @@
Detailed Description
-
This class implements Hermite interpolation polynomials (see [CiarletRiavart1972interpolation]) enforcing the maximum possible level of regularity in the FEM basis given a polynomial degree of . The polynomials all represent either a non-zero shape value or derivative at and on the reference interval .
-
Indices refer to polynomials corresponding to a non-zero derivative (or shape value for ) of order at , and indices refer to polynomials with a non-zero derivative of order (or value for ) at . In particular, the function has a value of at , and the function has a value of at .The basis is rescaled such that a function corresponding to a non-zero derivative has derivative value at the corresponding node. This is done to prevent the -norm of the basis functions from reducing exponentially with the chosen regularity.
+
This class implements Hermite interpolation polynomials (see [CiarletRiavart1972interpolation]) enforcing the maximum possible level of regularity in the FEM basis given a polynomial degree of . The polynomials all represent either a non-zero shape value or derivative at and on the reference interval .
+
Indices refer to polynomials corresponding to a non-zero derivative (or shape value for ) of order at , and indices refer to polynomials with a non-zero derivative of order (or value for ) at . In particular, the function has a value of at , and the function has a value of at .The basis is rescaled such that a function corresponding to a non-zero derivative has derivative value at the corresponding node. This is done to prevent the -norm of the basis functions from reducing exponentially with the chosen regularity.
Constructor for an individual Hermite polynomial. We write for a polynomial that has a non-zero derivative at and for a polynomial with a non-zero derivative at , meaning will have index and will have index. The resulting polynomials will be degree and obey the following conditions:
- for a polynomial that has a non-zero derivative at and for a polynomial with a non-zero derivative at , meaning will have index and will have index. The resulting polynomials will be degree and obey the following conditions:
+
+\end{align*}" src="form_680.png"/>
-
where is equal to whenever , and equal to otherwise. These polynomials have explicit formulas given by
- is equal to whenever , and equal to otherwise. These polynomials have explicit formulas given by
+
+\end{align*}" src="form_684.png"/>
-
where is the binomial coefficient of degree .
+
where is the binomial coefficient of degree .
Parameters
regularity
The highest derivative for which the basis is used to enforce regularity.
@@ -367,7 +367,7 @@
-
This function generates a vector of Polynomial objects representing a complete basis of degree on the reference interval .
+
This function generates a vector of Polynomial objects representing a complete basis of degree on the reference interval .
Parameters
regularity
The generated basis can be used to strongly enforce continuity in all derivatives up to and including this order.
@@ -1279,7 +1279,7 @@
-
The order of the highest derivative in which the Hermite basis can be used to impose continuity across element boundaries. It's related to the degree by .
+
The order of the highest derivative in which the Hermite basis can be used to impose continuity across element boundaries. It's related to the degree by .
Gauss-Chebyshev quadrature rules integrate the weighted product with weight given by: . The nodes and weights are known analytically, and are exact for monomials up to the order , where is the number of quadrature points. Here we rescale the quadrature formula so that it is defined on the interval instead of . So the quadrature formulas integrate exactly the integral with the weight: with weight given by: . The nodes and weights are known analytically, and are exact for monomials up to the order , where is the number of quadrature points. Here we rescale the quadrature formula so that it is defined on the interval instead of . So the quadrature formulas integrate exactly the integral with the weight: . For details see: M. Abramowitz & I.A. Stegun: Handbook of Mathematical Functions, par. 25.4.38
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classQGaussLobatto.html differs (JavaScript source, ASCII text, with very long lines (719))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classQGaussLobatto.html 2023-11-25 15:25:57.949929581 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classQGaussLobatto.html 2023-11-25 15:25:57.949929581 +0100
@@ -197,7 +197,7 @@
class QGaussLobatto< dim >
The Gauss-Lobatto family of quadrature rules for numerical integration.
This modification of the Gauss quadrature uses the two interval end points as well. Being exact for polynomials of degree 2n-3, this formula is suboptimal by two degrees.
The quadrature points are interval end points plus the roots of the derivative of the Legendre polynomial Pn-1 of degree n-1. The quadrature weights are 2/(n(n-1)(Pn-1(xi)2).
-
Note
This implementation has not been optimized concerning numerical stability and efficiency. It can be easily adapted to the general case of Gauss-Lobatto-Jacobi-Bouzitat quadrature with arbitrary parameters , , of which the Gauss-Lobatto-Legendre quadrature (
Note
This implementation has not been optimized concerning numerical stability and efficiency. It can be easily adapted to the general case of Gauss-Lobatto-Jacobi-Bouzitat quadrature with arbitrary parameters , , of which the Gauss-Lobatto-Legendre quadrature ( ) is a special case.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classQGaussLobattoChebyshev.html differs (JavaScript source, ASCII text, with very long lines (1989))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classQGaussLobattoChebyshev.html 2023-11-25 15:25:57.963262642 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classQGaussLobattoChebyshev.html 2023-11-25 15:25:57.963262642 +0100
@@ -196,7 +196,7 @@
Detailed Description
template<int dim>
-class QGaussLobattoChebyshev< dim >
Gauss-Lobatto-Chebyshev quadrature rules integrate the weighted product with weight given by: , with the additional constraint that two of the quadrature points are located at the endpoints of the quadrature interval. The nodes and weights are known analytically, and are exact for monomials up to the order , where is the number of quadrature points. Here we rescale the quadrature formula so that it is defined on the interval instead of . So the quadrature formulas integrate exactly the integral with the weight: . For details see: M. Abramowitz & I.A. Stegun: Handbook of Mathematical Functions, par. 25.4.40
+class QGaussLobattoChebyshev< dim >
Gauss-Lobatto-Chebyshev quadrature rules integrate the weighted product with weight given by: , with the additional constraint that two of the quadrature points are located at the endpoints of the quadrature interval. The nodes and weights are known analytically, and are exact for monomials up to the order , where is the number of quadrature points. Here we rescale the quadrature formula so that it is defined on the interval instead of . So the quadrature formulas integrate exactly the integral with the weight: . For details see: M. Abramowitz & I.A. Stegun: Handbook of Mathematical Functions, par. 25.4.40
A class for Gauss quadrature with logarithmic weighting function. This formula is used to integrate on the interval , where is a smooth function without singularities. The collection of quadrature points and weights has been obtained using Numerical Recipes.
-
Notice that only the function should be provided, i.e., on the interval , where is a smooth function without singularities. The collection of quadrature points and weights has been obtained using Numerical Recipes.
+
Notice that only the function should be provided, i.e., . Setting the revert flag to true at construction time switches the weight from to .
The weights and functions have been tabulated up to order 12.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classQGaussLogR.html differs (JavaScript source, ASCII text, with very long lines (1263))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classQGaussLogR.html 2023-11-25 15:25:57.999928563 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classQGaussLogR.html 2023-11-25 15:25:57.999928563 +0100
@@ -197,15 +197,15 @@
A class for Gauss quadrature with arbitrary logarithmic weighting function. This formula is used to integrate on the interval , where is a smooth function without singularities, and and are given at construction time, and are the location of the singularity and an arbitrary scaling factor in the singularity.
-
You have to make sure that the point is not one of the Gauss quadrature points of order , otherwise an exception is thrown, since the quadrature weights cannot be computed correctly.
+class QGaussLogR< dim >
A class for Gauss quadrature with arbitrary logarithmic weighting function. This formula is used to integrate on the interval , where is a smooth function without singularities, and and are given at construction time, and are the location of the singularity and an arbitrary scaling factor in the singularity.
+
You have to make sure that the point is not one of the Gauss quadrature points of order , otherwise an exception is thrown, since the quadrature weights cannot be computed correctly.
This quadrature formula is rather expensive, since it uses internally two Gauss quadrature formulas of order n to integrate the nonsingular part of the factor, and two GaussLog quadrature formulas to integrate on the separate segments and . If the singularity is one of the extremes and the factor alpha is 1, then this quadrature is the same as QGaussLog.
The last argument from the constructor allows you to use this quadrature rule in one of two possible ways:
-
Which one of the two sets of weights is provided, can be selected by the factor_out_singular_weight parameter. If it is false (the default), then the weights are computed, and you should provide only the smooth function , since the singularity is included inside the quadrature. If the parameter is set to true, then the singularity is factored out of the quadrature formula, and you should provide a function , which should at least be similar to .
+
Which one of the two sets of weights is provided, can be selected by the factor_out_singular_weight parameter. If it is false (the default), then the weights are computed, and you should provide only the smooth function , since the singularity is included inside the quadrature. If the parameter is set to true, then the singularity is factored out of the quadrature formula, and you should provide a function , which should at least be similar to .
Notice that this quadrature rule is worthless if you try to use it for regular functions once you factored out the singularity.
The weights and functions have been tabulated up to order 12.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classQGaussOneOverR.html differs (JavaScript source, ASCII text, with very long lines (1424))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classQGaussOneOverR.html 2023-11-25 15:25:58.016594888 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classQGaussOneOverR.html 2023-11-25 15:25:58.016594888 +0100
@@ -202,9 +202,9 @@
A class for Gauss quadrature with weighting function. This formula can be used to integrate on the reference element , where is a smooth function without singularities, and is the distance from the point to the vertex , given at construction time by specifying its index. Notice that this distance is evaluated in the reference element.
-
This quadrature formula is obtained from two QGauss quadrature formulas, upon transforming them into polar coordinate system centered at the singularity, and then again into another reference element. This allows for the singularity to be cancelled by part of the Jacobian of the transformation, which contains . In practice the reference element is transformed into a triangle by collapsing one of the sides adjacent to the singularity. The Jacobian of this transformation contains , which is removed before scaling the original quadrature, and this process is repeated for the next half element.
-
Upon construction it is possible to specify whether we want the singularity removed, or not. In other words, this quadrature can be used to integrate , or simply , with the factor already included in the quadrature weights.
+class QGaussOneOverR< dim >
A class for Gauss quadrature with weighting function. This formula can be used to integrate on the reference element , where is a smooth function without singularities, and is the distance from the point to the vertex , given at construction time by specifying its index. Notice that this distance is evaluated in the reference element.
+
This quadrature formula is obtained from two QGauss quadrature formulas, upon transforming them into polar coordinate system centered at the singularity, and then again into another reference element. This allows for the singularity to be cancelled by part of the Jacobian of the transformation, which contains . In practice the reference element is transformed into a triangle by collapsing one of the sides adjacent to the singularity. The Jacobian of this transformation contains , which is removed before scaling the original quadrature, and this process is repeated for the next half element.
+
Upon construction it is possible to specify whether we want the singularity removed, or not. In other words, this quadrature can be used to integrate , or simply , with the factor already included in the quadrature weights.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classQGaussRadauChebyshev.html differs (JavaScript source, ASCII text, with very long lines (2028))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classQGaussRadauChebyshev.html 2023-11-25 15:25:58.033261217 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classQGaussRadauChebyshev.html 2023-11-25 15:25:58.033261217 +0100
@@ -204,7 +204,7 @@
Detailed Description
template<int dim>
-class QGaussRadauChebyshev< dim >
Gauss-Radau-Chebyshev quadrature rules integrate the weighted product with weight given by: with the additional constraint that a quadrature point lies at one of the two extrema of the interval. The nodes and weights are known analytically, and are exact for monomials up to the order , where is the number of quadrature points. Here we rescale the quadrature formula so that it is defined on the interval instead of . So the quadrature formulas integrate exactly the integral with the weight: . By default the quadrature is constructed with the left endpoint as quadrature node, but the quadrature node can be imposed at the right endpoint through the variable ep that can assume the values left or right.
+class QGaussRadauChebyshev< dim >
Gauss-Radau-Chebyshev quadrature rules integrate the weighted product with weight given by: with the additional constraint that a quadrature point lies at one of the two extrema of the interval. The nodes and weights are known analytically, and are exact for monomials up to the order , where is the number of quadrature points. Here we rescale the quadrature formula so that it is defined on the interval instead of . So the quadrature formulas integrate exactly the integral with the weight: . By default the quadrature is constructed with the left endpoint as quadrature node, but the quadrature node can be imposed at the right endpoint through the variable ep that can assume the values left or right.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classQR.html differs (JavaScript source, ASCII text, with very long lines (684))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classQR.html 2023-11-25 15:25:58.043261012 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classQR.html 2023-11-25 15:25:58.046594280 +0100
@@ -166,7 +166,7 @@
Detailed Description
template<typename VectorType>
class QR< VectorType >
A class to compute and store the QR factorization of a matrix represented by a set of column vectors.
-
The class is design to update a given (possibly empty) QR factorization of a matrix (constructed incrementally by providing its columns) due to the addition of a new column vector to . This is equivalent to constructing an orthonormal basis by the Gram-Schmidt procedure. The class also provides update functionality when the first column is removed.
+
The class is design to update a given (possibly empty) QR factorization of a matrix (constructed incrementally by providing its columns) due to the addition of a new column vector to . This is equivalent to constructing an orthonormal basis by the Gram-Schmidt procedure. The class also provides update functionality when the first column is removed.
The VectorType template argument may either be a parallel and serial vector, and only need to have basic operations such as additions, scalar product, etc. It also needs to have a copy-constructor.
Solve . Vectors x and y should be consistent with the current size of the subspace. If transpose is true, is solved instead.
+
Solve . Vectors x and y should be consistent with the current size of the subspace. If transpose is true, is solved instead.
@@ -723,7 +723,7 @@
-
Compute where is the matrix formed by the column vectors stored by this object.
+
Compute where is the matrix formed by the column vectors stored by this object.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classQTelles.html differs (JavaScript source, Unicode text, UTF-8 text, with very long lines (981))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classQTelles.html 2023-11-25 15:25:58.063260605 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classQTelles.html 2023-11-25 15:25:58.063260605 +0100
@@ -222,7 +222,7 @@
\end{align*}" src="form_741.png"/>
Since the library assumes as reference interval, we will map these values on the proper reference interval in the implementation.
-
This variable change can be used to integrate singular integrals. One example is on the reference interval , where is given at construction time, and is the location of the singularity , and is a smooth non singular function.
+
This variable change can be used to integrate singular integrals. One example is on the reference interval , where is given at construction time, and is the location of the singularity , and is a smooth non singular function.
Singular quadrature formula are rather expensive, nevertheless Telles' quadrature formula are much easier to compute with respect to other singular integration techniques as Lachat-Watson.
We have implemented the case for . When we deal the case we have computed the quadrature formula has a tensorial product of one dimensional Telles' quadrature formulas considering the different components of the singularity.
The weights and functions for Gauss Legendre formula have been tabulated up to order 12.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classQWitherdenVincentSimplex.html differs (JavaScript source, ASCII text, with very long lines (1196))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classQWitherdenVincentSimplex.html 2023-11-25 15:25:58.076593670 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classQWitherdenVincentSimplex.html 2023-11-25 15:25:58.079926935 +0100
@@ -199,7 +199,7 @@
Detailed Description
template<int dim>
class QWitherdenVincentSimplex< dim >
Witherden-Vincent rules for simplex entities.
-
Like QGauss, users should specify a number n_points_1d as an indication of what polynomial degree to be integrated exactly (e.g., for points, the rule can integrate polynomials of degree exactly). Additionally, since these rules were derived for simplices, there are also even-ordered rules (i.e., they integrate polynomials of degree ) available which do not have analogous 1d rules.
+
Like QGauss, users should specify a number n_points_1d as an indication of what polynomial degree to be integrated exactly (e.g., for points, the rule can integrate polynomials of degree exactly). Additionally, since these rules were derived for simplices, there are also even-ordered rules (i.e., they integrate polynomials of degree ) available which do not have analogous 1d rules.
The given value for n_points_1d = 1, 2, 3, 4, 5, 6, 7 (where the last two are only implemented in 2d) results in the following number of quadrature points in 2d and 3d:
2d: odd (default): 1, 6, 7, 15, 19, 28, 37
2d: even: 3, 6, 12, 16, 25, 33, 42
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classQuadrature.html differs (JavaScript source, ASCII text, with very long lines (1257))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classQuadrature.html 2023-11-25 15:25:58.096593263 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classQuadrature.html 2023-11-25 15:25:58.096593263 +0100
@@ -220,9 +220,9 @@
At least for quadrilaterals and hexahedra (or, more precisely, since we work on reference cells: for the unit square and the unit cube), quadrature formulas are typically tensor products of one-dimensional formulas (see also the section on implementation detail below).
In order to allow for dimension independent programming, a quadrature formula of dimension zero exists. Since an integral over zero dimensions is the evaluation at a single point, any constructor of such a formula initializes to a single quadrature point with weight one. Access to the weight is possible, while access to the quadrature point is not permitted, since a Point of dimension zero contains no information. The main purpose of these formulae is their use in QProjector, which will create a useful formula of dimension one out of them.
Mathematical background
-
For each quadrature formula we denote by m, the maximal degree of polynomials integrated exactly on the reference cell the quadrature formula corresponds to. This number is given in the documentation of each formula. The order of the integration error is m+1, that is, the error is the size of the cell to the m+1 by the Bramble-Hilbert Lemma. The number m is to be found in the documentation of each concrete formula. For the optimal formulae QGauss we have , where is the constructor parameter to QGauss. The tensor product formulae are exact on tensor product polynomials of degree m in each space direction, but they are still only of (m+1)st order.
+
For each quadrature formula we denote by m, the maximal degree of polynomials integrated exactly on the reference cell the quadrature formula corresponds to. This number is given in the documentation of each formula. The order of the integration error is m+1, that is, the error is the size of the cell to the m+1 by the Bramble-Hilbert Lemma. The number m is to be found in the documentation of each concrete formula. For the optimal formulae QGauss we have , where is the constructor parameter to QGauss. The tensor product formulae are exact on tensor product polynomials of degree m in each space direction, but they are still only of (m+1)st order.
At least for hypercube reference cells (i.e., squares and cubes), most integration formulae in more than one space dimension are tensor products of quadrature formulae in one space dimension, or more generally the tensor product of a formula in (dim-1) dimensions and one in one dimension. There is a special constructor to generate a quadrature formula from two others. For example, the QGauss<dim> formulae include Ndim quadrature points in dim dimensions, where is the constructor parameter of QGauss.
+
At least for hypercube reference cells (i.e., squares and cubes), most integration formulae in more than one space dimension are tensor products of quadrature formulae in one space dimension, or more generally the tensor product of a formula in (dim-1) dimensions and one in one dimension. There is a special constructor to generate a quadrature formula from two others. For example, the QGauss<dim> formulae include Ndim quadrature points in dim dimensions, where is the constructor parameter of QGauss.
Other uses of this class
Quadrature objects are used in a number of places within deal.II where integration is performed, most notably via the FEValues and related classes. Some of these classes are also used in contexts where no integrals are involved, but where functions need to be evaluated at specific points, for example to evaluate the solution at individual points or to create graphical output. Examples are the implementation of VectorTools::point_value() and the DataOut and related classes (in particular in connection with the DataPostprocessor class). In such contexts, one often creates specific "Quadrature" objects in which the "quadrature points" are simply the points (in the coordinate system of the reference cell) at which one wants to evaluate the solution. In these kinds of cases, the weights stored by the current class are not used and the name "quadrature object" is interpreted as "list of evaluation points".
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classReferenceCell.html differs (JavaScript source, ASCII text, with very long lines (847))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classReferenceCell.html 2023-11-25 15:25:58.119926120 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classReferenceCell.html 2023-11-25 15:25:58.119926120 +0100
@@ -490,7 +490,7 @@
-
Compute the value of the -th linear shape function at location for the current reference-cell type.
+
Compute the value of the -th linear shape function at location for the current reference-cell type.
Return a default linear mapping matching the current reference cell. If this reference cell is a hypercube, then the returned mapping is a MappingQ1; otherwise, it is an object of type MappingFE initialized with FE_SimplexP (if the reference cell is a triangle or tetrahedron), with FE_PyramidP (if the reference cell is a pyramid), or with FE_WedgeP (if the reference cell is a wedge). In other words, the term "linear" in the name of the function has to be understood as -linear (i.e., bilinear or trilinear) for some of the coordinate directions.
+
Return a default linear mapping matching the current reference cell. If this reference cell is a hypercube, then the returned mapping is a MappingQ1; otherwise, it is an object of type MappingFE initialized with FE_SimplexP (if the reference cell is a triangle or tetrahedron), with FE_PyramidP (if the reference cell is a pyramid), or with FE_WedgeP (if the reference cell is a wedge). In other words, the term "linear" in the name of the function has to be understood as -linear (i.e., bilinear or trilinear) for some of the coordinate directions.
Return the -dimensional volume of the reference cell that corresponds to the current object, where is the dimension of the space it lives in. For example, since the quadrilateral reference cell is , its volume is one, whereas the volume of the reference triangle is 0.5 because it occupies the area .
+
Return the -dimensional volume of the reference cell that corresponds to the current object, where is the dimension of the space it lives in. For example, since the quadrilateral reference cell is , its volume is one, whereas the volume of the reference triangle is 0.5 because it occupies the area .
For ReferenceCells::Vertex, the reference cell is a zero-dimensional point in a zero-dimensional space. As a consequence, one cannot meaningfully define a volume for it. The function returns one for this case, because this makes it possible to define useful quadrature rules based on the center of a reference cell and its volume.
Return the barycenter (i.e., the center of mass) of the reference cell that corresponds to the current object. The function is not called center() because one can define the center of an object in a number of different ways whereas the barycenter of a reference cell is unambiguously defined as
-
+\]" src="form_1470.png"/>
where is the volume of the reference cell (see also the volume() function).
@@ -1485,7 +1485,7 @@
-
Return true if the given point is inside the reference cell of the present space dimension up to some tolerance. This function accepts an additional parameter (which defaults to zero) which specifies by how much the point position may actually be outside the true reference cell. This is useful because in practice we may often not be able to compute the coordinates of a point in reference coordinates exactly, but only up to numerical roundoff. For example, strictly speaking one would expect that for points on the boundary of the reference cell, the function would return true if the tolerance was zero. But in practice, this may or may not actually be true; for example, the point is on the boundary of the reference triangle because , but since neither of its coordinates are exactly representable in floating point arithmetic, the floating point representations of and may or may not add up to anything that is less than or equal to one.
+
Return true if the given point is inside the reference cell of the present space dimension up to some tolerance. This function accepts an additional parameter (which defaults to zero) which specifies by how much the point position may actually be outside the true reference cell. This is useful because in practice we may often not be able to compute the coordinates of a point in reference coordinates exactly, but only up to numerical roundoff. For example, strictly speaking one would expect that for points on the boundary of the reference cell, the function would return true if the tolerance was zero. But in practice, this may or may not actually be true; for example, the point is on the boundary of the reference triangle because , but since neither of its coordinates are exactly representable in floating point arithmetic, the floating point representations of and may or may not add up to anything that is less than or equal to one.
The tolerance parameter may be less than zero, indicating that the point should be safely inside the cell.
Return -th unit tangential vector of a face of the reference cell. The vectors are arranged such that the cross product between the two vectors returns the unit normal vector.
-
Precondition
must be between zero and dim-1.
+
Return -th unit tangential vector of a face of the reference cell. The vectors are arranged such that the cross product between the two vectors returns the unit normal vector.
Given a set of node indices of the form or or (depending on whether the reference cell is in 1d, 2d, or 3d), return the index the VTK format uses for this node for cells that are subdivided as many times in each of the coordinate directions as described by the second argument. For a uniformly subdivided cell, the second argument is an array whose elements will all be equal.
+
Given a set of node indices of the form or or (depending on whether the reference cell is in 1d, 2d, or 3d), return the index the VTK format uses for this node for cells that are subdivided as many times in each of the coordinate directions as described by the second argument. For a uniformly subdivided cell, the second argument is an array whose elements will all be equal.
The last argument, legacy_format, indicates whether to use the old, VTK legacy format (when true) or the new, VTU format (when false).
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classRol_1_1VectorAdaptor.html differs (JavaScript source, ASCII text, with very long lines (688))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classRol_1_1VectorAdaptor.html 2023-11-25 15:25:58.136592448 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classRol_1_1VectorAdaptor.html 2023-11-25 15:25:58.136592448 +0100
@@ -500,7 +500,7 @@
-
Return the norm of the wrapped vector.
+
Return the norm of the wrapped vector.
The returned type is of VectorAdaptor::value_type so as to maintain consistency with ROL::Vector<VectorAdaptor::value_type> and more importantly to not to create an overloaded version namely, VectorAdaptor::real_typenorm() const; if real_type and value_type are not of the same type.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classSLEPcWrappers_1_1SolverArnoldi.html differs (JavaScript source, ASCII text, with very long lines (772))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classSLEPcWrappers_1_1SolverArnoldi.html 2023-11-25 15:25:58.149925508 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classSLEPcWrappers_1_1SolverArnoldi.html 2023-11-25 15:25:58.149925508 +0100
@@ -310,9 +310,9 @@
-
Same as above, but here a composite method for solving the system , for real matrices, vectors, and values .
+
Same as above, but here a composite method for solving the system , for real matrices, vectors, and values .
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classSUNDIALS_1_1ARKode.html differs (JavaScript source, ASCII text, with very long lines (1421))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classSUNDIALS_1_1ARKode.html 2023-11-25 15:25:58.279922865 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classSUNDIALS_1_1ARKode.html 2023-11-25 15:25:58.279922865 +0100
@@ -192,85 +192,85 @@
The class ARKode is a wrapper to SUNDIALS variable-step, embedded, additive Runge-Kutta solver which is a general purpose solver for systems of ordinary differential equations characterized by the presence of both fast and slow dynamics.
Fast dynamics are treated implicitly, and slow dynamics are treated explicitly, using nested families of implicit and explicit Runge-Kutta solvers.
ARKode solves ODE initial value problems (IVPs) in . These problems should be posed in explicit form as
+
ARKode solves ODE initial value problems (IVPs) in . These problems should be posed in explicit form as
-
+ \]" src="form_2555.png"/>
-
Here, is the independent variable (e.g. time), and the dependent variables are given by , and we use notation to denote . is a user-supplied nonsingular operator from . This operator may depend on but not on .
-
For standard systems of ordinary differential equations and for problems arising from the spatial semi-discretization of partial differential equations using finite difference or finite volume methods, is typically the identity matrix, . For PDEs using a finite-element spatial semi-discretization is typically a well-conditioned mass matrix.
+
Here, is the independent variable (e.g. time), and the dependent variables are given by , and we use notation to denote . is a user-supplied nonsingular operator from . This operator may depend on but not on .
+
For standard systems of ordinary differential equations and for problems arising from the spatial semi-discretization of partial differential equations using finite difference or finite volume methods, is typically the identity matrix, . For PDEs using a finite-element spatial semi-discretization is typically a well-conditioned mass matrix.
The two right-hand side functions may be described as:
-
: contains the "slow" time scale components of the system. This will be integrated using explicit methods.
-
: contains the "fast" time scale components of the system. This will be integrated using implicit methods.
+
: contains the "slow" time scale components of the system. This will be integrated using explicit methods.
+
: contains the "fast" time scale components of the system. This will be integrated using implicit methods.
-
ARKode may be used to solve stiff, nonstiff and multi-rate problems. Roughly speaking, stiffness is characterized by the presence of at least one rapidly damped mode, whose time constant is small compared to the time scale of the solution itself. In the implicit/explicit (ImEx) splitting above, these stiff components should be included in the right-hand side function .
-
For multi-rate problems, a user should provide both of the functions and that define the IVP system.
-
For nonstiff problems, only should be provided, and is assumed to be zero, i.e. the system reduces to the non-split IVP:
+
ARKode may be used to solve stiff, nonstiff and multi-rate problems. Roughly speaking, stiffness is characterized by the presence of at least one rapidly damped mode, whose time constant is small compared to the time scale of the solution itself. In the implicit/explicit (ImEx) splitting above, these stiff components should be included in the right-hand side function .
+
For multi-rate problems, a user should provide both of the functions and that define the IVP system.
+
For nonstiff problems, only should be provided, and is assumed to be zero, i.e. the system reduces to the non-split IVP:
-
+ \]" src="form_2565.png"/>
-
In this scenario, the ARK methods reduce to classical explicit Runge-Kutta methods (ERK). For these classes of methods, ARKode allows orders of accuracy , with embeddings of orders . These default to the Heun-Euler-2-1-2, Bogacki-Shampine-4-2-3, Zonneveld-5-3-4, Cash-Karp-6-4-5, Verner-8-5-6 and Fehlberg-13-7-8 methods, respectively.
-
Finally, for stiff (linear or nonlinear) problems the user may provide only , implying that , so that the system reduces to the non-split IVP
+
In this scenario, the ARK methods reduce to classical explicit Runge-Kutta methods (ERK). For these classes of methods, ARKode allows orders of accuracy , with embeddings of orders . These default to the Heun-Euler-2-1-2, Bogacki-Shampine-4-2-3, Zonneveld-5-3-4, Cash-Karp-6-4-5, Verner-8-5-6 and Fehlberg-13-7-8 methods, respectively.
+
Finally, for stiff (linear or nonlinear) problems the user may provide only , implying that , so that the system reduces to the non-split IVP
-
+ \]" src="form_2569.png"/>
-
Similarly to ERK methods, in this scenario the ARK methods reduce to classical diagonally-implicit Runge-Kutta methods (DIRK). For these classes of methods, ARKode allows orders of accuracy , with embeddings of orders . These default to the SDIRK-2-1-2, ARK-4-2-3 (implicit), SDIRK-5-3-4 and ARK-8-4-5 (implicit) methods, respectively.
+
Similarly to ERK methods, in this scenario the ARK methods reduce to classical diagonally-implicit Runge-Kutta methods (DIRK). For these classes of methods, ARKode allows orders of accuracy , with embeddings of orders . These default to the SDIRK-2-1-2, ARK-4-2-3 (implicit), SDIRK-5-3-4 and ARK-8-4-5 (implicit) methods, respectively.
For both DIRK and ARK methods, an implicit system of the form
-
+ \]" src="form_2572.png"/>
-
must be solved for each stage , where we have the data
-, where we have the data
+
+ \]" src="form_2574.png"/>
for the ARK methods, or
-
+ \]" src="form_2575.png"/>
-
for the DIRK methods. Here and are the Butcher's tables for the chosen solver.
-
If depends nonlinearly on then the systems above correspond to a nonlinear system of equations; if depends linearly on then this is a linear system of equations. By specifying the flag implicit_function_is_linear, ARKode takes some shortcuts that allow a faster solution process.
+
for the DIRK methods. Here and are the Butcher's tables for the chosen solver.
+
If depends nonlinearly on then the systems above correspond to a nonlinear system of equations; if depends linearly on then this is a linear system of equations. By specifying the flag implicit_function_is_linear, ARKode takes some shortcuts that allow a faster solution process.
For systems of either type, ARKode allows a choice of solution strategy. The default solver choice is a variant of Newton's method,
-
+ \]" src="form_2579.png"/>
-
where is the Newton step index, and the Newton update requires the solution of the linear Newton system
- is the Newton step index, and the Newton update requires the solution of the linear Newton system
+
+ \]" src="form_2581.png"/>
where
-
+ \]" src="form_2582.png"/>
-
As an alternate to Newton's method, ARKode may solve for each stage using an Anderson-accelerated fixed point iteration
-ARKode may solve for each stage using an Anderson-accelerated fixed point iteration
+
+ \]" src="form_2584.png"/>
Unlike with Newton's method, this option does not require the solution of a linear system at each iteration, instead opting for solution of a low-dimensional least-squares solution to construct the nonlinear update.
-
Finally, if the user specifies implicit_function_is_linear, i.e., depends linearly on , and if the Newton-based nonlinear solver is chosen, then the system will be solved using only a single Newton iteration. Notice that in order for the Newton solver to be used, then jacobian_times_vector() should be supplied. If it is not supplied then only the fixed-point iteration will be supported, and the implicit_function_is_linear setting is ignored.
-
The optimal solver (Newton vs fixed-point) is highly problem-dependent. Since fixed-point solvers do not require the solution of any linear systems, each iteration may be significantly less costly than their Newton counterparts. However, this can come at the cost of slower convergence (or even divergence) in comparison with Newton-like methods. These fixed-point solvers do allow for user specification of the Anderson-accelerated subspace size, . While the required amount of solver memory grows proportionately to , larger values of may result in faster convergence.
-
This improvement may be significant even for "small" values, e.g. , and convergence may not improve (or even deteriorate) for larger values of . While ARKode uses a Newton-based iteration as its default solver due to its increased robustness on very stiff problems, it is highly recommended that users also consider the fixed-point solver for their cases when attempting a new problem.
-
For either the Newton or fixed-point solvers, it is well-known that both the efficiency and robustness of the algorithm intimately depends on the choice of a good initial guess. In ARKode, the initial guess for either nonlinear solution method is a predicted value that is computed explicitly from the previously-computed data (e.g. , and where ). Additional information on the specific predictor algorithms implemented in ARKode is provided in ARKode documentation.
+
Finally, if the user specifies implicit_function_is_linear, i.e., depends linearly on , and if the Newton-based nonlinear solver is chosen, then the system will be solved using only a single Newton iteration. Notice that in order for the Newton solver to be used, then jacobian_times_vector() should be supplied. If it is not supplied then only the fixed-point iteration will be supported, and the implicit_function_is_linear setting is ignored.
+
The optimal solver (Newton vs fixed-point) is highly problem-dependent. Since fixed-point solvers do not require the solution of any linear systems, each iteration may be significantly less costly than their Newton counterparts. However, this can come at the cost of slower convergence (or even divergence) in comparison with Newton-like methods. These fixed-point solvers do allow for user specification of the Anderson-accelerated subspace size, . While the required amount of solver memory grows proportionately to , larger values of may result in faster convergence.
+
This improvement may be significant even for "small" values, e.g. , and convergence may not improve (or even deteriorate) for larger values of . While ARKode uses a Newton-based iteration as its default solver due to its increased robustness on very stiff problems, it is highly recommended that users also consider the fixed-point solver for their cases when attempting a new problem.
+
For either the Newton or fixed-point solvers, it is well-known that both the efficiency and robustness of the algorithm intimately depends on the choice of a good initial guess. In ARKode, the initial guess for either nonlinear solution method is a predicted value that is computed explicitly from the previously-computed data (e.g. , and where ). Additional information on the specific predictor algorithms implemented in ARKode is provided in ARKode documentation.
The user has to provide the implementation of at least one (or both) of the following std::functions:
A function object that users may supply and that is intended to compute the explicit part of the IVP right hand side. Sets .
+
A function object that users may supply and that is intended to compute the explicit part of the IVP right hand side. Sets .
At least one of explicit_function() or implicit_function() must be provided. According to which one is provided, explicit, implicit, or mixed RK methods are used.
Note
This variable represents a user provided callback. See there for a description of how to deal with errors and other requirements and conventions. In particular, ARKode can deal with "recoverable" errors in some circumstances, so callbacks can throw exceptions of type RecoverableUserCallbackError.
@@ -807,8 +807,8 @@
-
A function object that users may supply and that is intended to compute the implicit part of the IVP right hand side. Sets .
+
A function object that users may supply and that is intended to compute the implicit part of the IVP right hand side. Sets .
At least one of explicit_function() or implicit_function() must be provided. According to which one is provided, explicit, implicit, or mixed RK methods are used.
Note
This variable represents a user provided callback. See there for a description of how to deal with errors and other requirements and conventions. In particular, ARKode can deal with "recoverable" errors in some circumstances, so callbacks can throw exceptions of type RecoverableUserCallbackError.
@@ -830,7 +830,7 @@
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classSUNDIALS_1_1IDA.html differs (JavaScript source, ASCII text, with very long lines (1392))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classSUNDIALS_1_1IDA.html 2023-11-25 15:25:58.296589190 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classSUNDIALS_1_1IDA.html 2023-11-25 15:25:58.296589190 +0100
@@ -183,69 +183,69 @@
Consider a system of Differential-Algebraic Equations written in the general form
-
+ \]" src="form_2611.png"/>
-
where are vectors in , is often the time (but can also be a parametric quantity), and . Such problem is solved using Newton iteration augmented with a line search global strategy. The integration method used in IDA is the variable-order, variable-coefficient BDF (Backward Differentiation Formula), in fixed-leading-coefficient. The method order ranges from 1 to 5, with the BDF of order given by the multistep formula
+
where are vectors in , is often the time (but can also be a parametric quantity), and . Such problem is solved using Newton iteration augmented with a line search global strategy. The integration method used in IDA is the variable-order, variable-coefficient BDF (Backward Differentiation Formula), in fixed-leading-coefficient. The method order ranges from 1 to 5, with the BDF of order given by the multistep formula
-
+ \]" src="form_2615.png"/>
-
where and are the computed approximations of and , respectively, and the step size is . The coefficients are uniquely determined by the order , and the history of the step sizes. The application of the BDF method to the DAE system results in a nonlinear algebraic system to be solved at each time step:
+
where and are the computed approximations of and , respectively, and the step size is . The coefficients are uniquely determined by the order , and the history of the step sizes. The application of the BDF method to the DAE system results in a nonlinear algebraic system to be solved at each time step:
-
+ \]" src="form_2622.png"/>
The Newton method leads to a linear system of the form
-
+ \]" src="form_2623.png"/>
-
where is the -th approximation to , and is the approximation of the system Jacobian
+
where is the -th approximation to , and is the approximation of the system Jacobian
-
+ \]" src="form_2625.png"/>
-
and . It is worth mentioning that the scalar changes whenever the step size or method order changes.
+
and . It is worth mentioning that the scalar changes whenever the step size or method order changes.
To provide a simple example, consider the following harmonic oscillator problem:
-
+ \]" src="form_2627.png"/>
We write it in terms of a first order ode:
-
+ \]" src="form_2628.png"/>
-
That is where A =
- where A =
+
+ \]" src="form_2630.png"/>
-
and , .
-
The exact solution is , , .
-
The Jacobian to assemble is the following: .
+
and , .
+
The exact solution is , , .
+
The Jacobian to assemble is the following: .
This is achieved by the following snippet of code:
use_y_diff: compute the algebraic components of y and differential components of y_dot, given the differential components of y. This option requires that the user specifies differential and algebraic components in the function get_differential_components.
use_y_dot: compute all components of y, given y_dot.
-
By default, this class assumes that all components are differential, and that you want to solve a standard ode. In this case, the initial component type is set to use_y_diff, so that the y_dot at time t=initial_time is computed by solving the nonlinear problem in the variable y_dot.
+
By default, this class assumes that all components are differential, and that you want to solve a standard ode. In this case, the initial component type is set to use_y_diff, so that the y_dot at time t=initial_time is computed by solving the nonlinear problem in the variable y_dot.
Notice that a Newton solver is used for this computation. The Newton solver parameters can be tweaked by acting on ic_alpha and ic_max_iter.
If you reset the solver at some point, you may want to select a different computation for the initial conditions after reset. Say, for example, that you have refined a grid, and after transferring the solution to the new grid, the initial conditions are no longer consistent. Then you can choose how these are made consistent, using the same three options that you used for the initial conditions in reset_type.
Parameters
@@ -631,7 +631,7 @@
-
Compute residual. Return .
+
Compute residual. Return .
Note
This variable represents a user provided callback. See there for a description of how to deal with errors and other requirements and conventions. In particular, IDA can deal with "recoverable" errors in some circumstances, so callbacks can throw exceptions of type RecoverableUserCallbackError.
Compute Jacobian. This function is called by IDA any time a Jacobian update is required. The user should compute the Jacobian (or update all the variables that allow the application of the Jacobian). This function is called by IDA once, before any call to solve_jacobian_system() or solve_with_jacobian().
The Jacobian should be a (possibly inexact) computation of
-
+\]" src="form_2636.png"/>
If the user uses a matrix based computation of the Jacobian, then this is the right place where an assembly routine should be called to assemble both a matrix and a preconditioner for the Jacobian system. Subsequent calls (possibly more than one) to solve_jacobian_system() or solve_with_jacobian() can assume that this function has been called at least once.
-
Notice that no assumption is made by this interface on what the user should do in this function. IDA only assumes that after a call to setup_jacobian() it is possible to call solve_jacobian_system() or solve_with_jacobian() to obtain a solution to the system .
+
Notice that no assumption is made by this interface on what the user should do in this function. IDA only assumes that after a call to setup_jacobian() it is possible to call solve_jacobian_system() or solve_with_jacobian() to obtain a solution to the system .
Note
This variable represents a user provided callback. See there for a description of how to deal with errors and other requirements and conventions. In particular, IDA can deal with "recoverable" errors in some circumstances, so callbacks can throw exceptions of type RecoverableUserCallbackError.
Solve the Jacobian linear system. This function will be called by IDA (possibly several times) after setup_jacobian() has been called at least once. IDA tries to do its best to call setup_jacobian() the minimum amount of times. If convergence can be achieved without updating the Jacobian, then IDA does not call setup_jacobian() again. If, on the contrary, internal IDA convergence tests fail, then IDA calls again setup_jacobian() with updated vectors and coefficients so that successive calls to solve_jacobian_systems() lead to better convergence in the Newton process.
The jacobian should be (an approximation of) the system Jacobian
-
+\]" src="form_2636.png"/>
-
A call to this function should store in dst the result of applied to src, i.e., J*dst = src. It is the users responsibility to set up proper solvers and preconditioners inside this function.
+
A call to this function should store in dst the result of applied to src, i.e., J*dst = src. It is the users responsibility to set up proper solvers and preconditioners inside this function.
Note
This variable represents a user provided callback. See there for a description of how to deal with errors and other requirements and conventions. In particular, IDA can deal with "recoverable" errors in some circumstances, so callbacks can throw exceptions of type RecoverableUserCallbackError.
Solve the Jacobian linear system up to a specified tolerance. This function will be called by IDA (possibly several times) after setup_jacobian() has been called at least once. IDA tries to do its best to call setup_jacobian() the minimum number of times. If convergence can be achieved without updating the Jacobian, then IDA does not call setup_jacobian() again. If, on the contrary, internal IDA convergence tests fail, then IDA calls again setup_jacobian() with updated vectors and coefficients so that successive calls to solve_with_jacobian() lead to better convergence in the Newton process.
The Jacobian should be (an approximation of) the system Jacobian
-
+\]" src="form_2636.png"/>
Arguments to the function are:
Parameters
[in]
rhs
The system right hand side to solve for.
-
[out]
dst
The solution of .
+
[out]
dst
The solution of .
[in]
tolerance
The tolerance with which to solve the linear system of equations.
-
A call to this function should store in dst the result of applied to src, i.e., the solution of the linear system J*dst = src. It is the user's responsibility to set up proper solvers and preconditioners either inside this function, or already within the setup_jacobian() function. (The latter is, for example, what the step-77 program does: All expensive operations happen in setup_jacobian(), given that that function is called far less often than the current one.)
+
A call to this function should store in dst the result of applied to src, i.e., the solution of the linear system J*dst = src. It is the user's responsibility to set up proper solvers and preconditioners either inside this function, or already within the setup_jacobian() function. (The latter is, for example, what the step-77 program does: All expensive operations happen in setup_jacobian(), given that that function is called far less often than the current one.)
Note
This variable represents a user provided callback. See there for a description of how to deal with errors and other requirements and conventions. In particular, IDA can deal with "recoverable" errors in some circumstances, so callbacks can throw exceptions of type RecoverableUserCallbackError.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classSUNDIALS_1_1IDA_1_1AdditionalData.html differs (JavaScript source, ASCII text, with very long lines (2466))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classSUNDIALS_1_1IDA_1_1AdditionalData.html 2023-11-25 15:25:58.309922254 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classSUNDIALS_1_1IDA_1_1AdditionalData.html 2023-11-25 15:25:58.313255519 +0100
@@ -567,8 +567,8 @@
Type of correction for initial conditions.
-
If you do not provide consistent initial conditions, (i.e., conditions for which ), you can ask SUNDIALS to compute initial conditions for you by using the ic_type parameter at construction time.
-
Notice that you could in principle use this capabilities to solve for steady state problems by setting y_dot to zero, and asking to compute that satisfies , however the nonlinear solver used inside IDA may not be robust enough for complex problems with several millions unknowns.
+
If you do not provide consistent initial conditions, (i.e., conditions for which ), you can ask SUNDIALS to compute initial conditions for you by using the ic_type parameter at construction time.
+
Notice that you could in principle use this capabilities to solve for steady state problems by setting y_dot to zero, and asking to compute that satisfies , however the nonlinear solver used inside IDA may not be robust enough for complex problems with several millions unknowns.
KINSOL is a solver for nonlinear algebraic systems in residual form or fixed point form , where is a vector which we will assume to be in or , but that may also have a block structure and may be distributed in parallel computations; the functions and satisfy or . It includes a Newton-Krylov solver as well as Picard and fixed point solvers, both of which can be accelerated with Anderson acceleration. KINSOL is based on the previous Fortran package NKSOL of Brown and Saad. An example of using KINSOL can be found in the step-77 tutorial program.
+
KINSOL is a solver for nonlinear algebraic systems in residual form or fixed point form , where is a vector which we will assume to be in or , but that may also have a block structure and may be distributed in parallel computations; the functions and satisfy or . It includes a Newton-Krylov solver as well as Picard and fixed point solvers, both of which can be accelerated with Anderson acceleration. KINSOL is based on the previous Fortran package NKSOL of Brown and Saad. An example of using KINSOL can be found in the step-77 tutorial program.
KINSOL's Newton solver employs the inexact Newton method. As this solver is intended mainly for large systems, the user is required to provide their own solver function.
At the highest level, KINSOL implements the following iteration scheme:
-
set = an initial guess
-
For until convergence do:
-
Solve
-
Set
+
set = an initial guess
+
For until convergence do:
+
Solve
+
Set
Test for convergence
-
Here, is the -th iterate to , and is the system Jacobian. At each stage in the iteration process, a scalar multiple of the step , is added to to produce a new iterate, . A test for convergence is made before the iteration continues.
+
Here, is the -th iterate to , and is the system Jacobian. At each stage in the iteration process, a scalar multiple of the step , is added to to produce a new iterate, . A test for convergence is made before the iteration continues.
Unless specified otherwise by the user, KINSOL strives to update Jacobian information as infrequently as possible to balance the high costs of matrix operations against other costs. Specifically, these updates occur when:
the problem is initialized,
-
(inexact Newton only, see below for a definition of )
+
(inexact Newton only, see below for a definition of )
a specified number of nonlinear iterations have passed since the last update,
the linear solver failed recoverably with outdated Jacobian information,
the global strategy failed with outdated Jacobian information, or
-
tolerance with outdated Jacobian information.
+
tolerance with outdated Jacobian information.
KINSOL allows changes to the above strategy through optional solver inputs. The user can disable the initial Jacobian information evaluation or change the default value of the number of nonlinear iterations after which a Jacobian information update is enforced.
-
To address the case of ill-conditioned nonlinear systems, KINSOL allows prescribing scaling factors both for the solution vector and for the residual vector. For scaling to be used, the user may supply the function get_solution_scaling(), that returns values , which are diagonal elements of the scaling matrix such that has all components roughly the same magnitude when is close to a solution, and get_function_scaling(), that supply values , which are diagonal scaling matrix elements such that has all components roughly the same magnitude when is not too close to a solution.
+
To address the case of ill-conditioned nonlinear systems, KINSOL allows prescribing scaling factors both for the solution vector and for the residual vector. For scaling to be used, the user may supply the function get_solution_scaling(), that returns values , which are diagonal elements of the scaling matrix such that has all components roughly the same magnitude when is close to a solution, and get_function_scaling(), that supply values , which are diagonal scaling matrix elements such that has all components roughly the same magnitude when is not too close to a solution.
When scaling values are provided for the solution vector, these values are automatically incorporated into the calculation of the perturbations used for the default difference quotient approximations for Jacobian information if the user does not supply a Jacobian solver through the solve_with_jacobian() function.
-
Two methods of applying a computed step to the previously computed solution vector are implemented. The first and simplest is the standard Newton strategy which applies the update with a constant always set to 1. The other method is a global strategy, which attempts to use the direction implied by in the most efficient way for furthering convergence of the nonlinear problem. This technique is implemented in the second strategy, called Linesearch. This option employs both the and conditions of the Goldstein-Armijo linesearch algorithm given in [DennisSchnabel96] , where is chosen to guarantee a sufficient decrease in relative to the step length as well as a minimum step length relative to the initial rate of decrease of . One property of the algorithm is that the full Newton step tends to be taken close to the solution.
+
Two methods of applying a computed step to the previously computed solution vector are implemented. The first and simplest is the standard Newton strategy which applies the update with a constant always set to 1. The other method is a global strategy, which attempts to use the direction implied by in the most efficient way for furthering convergence of the nonlinear problem. This technique is implemented in the second strategy, called Linesearch. This option employs both the and conditions of the Goldstein-Armijo linesearch algorithm given in [DennisSchnabel96] , where is chosen to guarantee a sufficient decrease in relative to the step length as well as a minimum step length relative to the initial rate of decrease of . One property of the algorithm is that the full Newton step tends to be taken close to the solution.
The basic fixed-point iteration scheme implemented in KINSOL is given by:
-
Set an initial guess
-
For until convergence do:
-
Set
+
Set an initial guess
+
For until convergence do:
+
Set
Test for convergence
-
At each stage in the iteration process, function is applied to the current iterate to produce a new iterate, . A test for convergence is made before the iteration continues.
-
For Picard iteration, as implemented in KINSOL, we consider a special form of the nonlinear function , such that , where is a constant nonsingular matrix and is (in general) nonlinear.
-
Then the fixed-point function is defined as . Within each iteration, the Picard step is computed then added to to produce the new iterate. Next, the nonlinear residual function is evaluated at the new iterate, and convergence is checked. The Picard and fixed point methods can be significantly accelerated using Anderson's acceleration method.
+
At each stage in the iteration process, function is applied to the current iterate to produce a new iterate, . A test for convergence is made before the iteration continues.
+
For Picard iteration, as implemented in KINSOL, we consider a special form of the nonlinear function , such that , where is a constant nonsingular matrix and is (in general) nonlinear.
+
Then the fixed-point function is defined as . Within each iteration, the Picard step is computed then added to to produce the new iterate. Next, the nonlinear residual function is evaluated at the new iterate, and convergence is checked. The Picard and fixed point methods can be significantly accelerated using Anderson's acceleration method.
The user has to provide the implementation of the following std::functions:
reinit_vector; and only one of
residual; or
iteration_function;
-
Specifying residual() allows the user to use Newton and Picard strategies (i.e., will be solved), while specifying iteration_function(), a fixed point iteration will be used (i.e., will be solved). An error will be thrown if iteration_function() is set for Picard or Newton.
+
Specifying residual() allows the user to use Newton and Picard strategies (i.e., will be solved), while specifying iteration_function(), a fixed point iteration will be used (i.e., will be solved). An error will be thrown if iteration_function() is set for Picard or Newton.
If the use of a Newton or Picard method is desired, then the user should also supply
solve_jacobian_system or solve_with_jacobian; and optionally
setup_jacobian;
@@ -440,13 +440,13 @@
A function object that users may supply and that is intended to prepare the linear solver for subsequent calls to solve_with_jacobian().
The job of setup_jacobian() is to prepare the linear solver for subsequent calls to solve_with_jacobian(), in the solution of linear systems . The exact nature of this system depends on the SolutionStrategy that has been selected.
-
In the cases strategy = SolutionStrategy::newton or SolutionStrategy::linesearch, is the Jacobian . If strategy = SolutionStrategy::picard, is the approximate Jacobian matrix . If strategy = SolutionStrategy::fixed_point, then linear systems do not arise, and this function is never called.
+
In the cases strategy = SolutionStrategy::newton or SolutionStrategy::linesearch, is the Jacobian . If strategy = SolutionStrategy::picard, is the approximate Jacobian matrix . If strategy = SolutionStrategy::fixed_point, then linear systems do not arise, and this function is never called.
The setup_jacobian() function may call a user-supplied function, or a function within the linear solver module, to compute Jacobian-related data that is required by the linear solver. It may also preprocess that data as needed for solve_with_jacobian(), which may involve calling a generic function (such as for LU factorization) or, more generally, build preconditioners from the assembled Jacobian. In any case, the data so generated may then be used whenever a linear system is solved.
The point of this function is that setup_jacobian() function is not called at every Newton iteration, but only as frequently as the solver determines that it is appropriate to perform the setup task. In this way, Jacobian-related data generated by setup_jacobian() is expected to be used over a number of Newton iterations. KINSOL determines itself when it is beneficial to regenerate the Jacobian and associated information (such as preconditioners computed for the Jacobian), thereby saving the effort to regenerate the Jacobian matrix and a preconditioner for it whenever possible.
Versions of SUNDIALS after 4.0 no longer provide all of the information necessary for this callback (see below). Use the solve_with_jacobian callback described below.
A function object that users may supply and that is intended to solve a linear system with the Jacobian matrix. This function will be called by KINSOL (possibly several times) after setup_jacobian() has been called at least once. KINSOL tries to do its best to call setup_jacobian() the minimum number of times. If convergence can be achieved without updating the Jacobian, then KINSOL does not call setup_jacobian() again. If, on the contrary, internal KINSOL convergence tests fail, then KINSOL calls setup_jacobian() again with updated vectors and coefficients so that successive calls to solve_jacobian_system() lead to better convergence in the Newton process.
If you do not specify a solve_jacobian_system or solve_with_jacobian function, then only a fixed point iteration strategy can be used. Notice that this may not converge, or may converge very slowly.
-
A call to this function should store in dst the result of applied to rhs, i.e., . It is the user's responsibility to set up proper solvers and preconditioners inside this function (or in the setup_jacobian callback above).
+
A call to this function should store in dst the result of applied to rhs, i.e., . It is the user's responsibility to set up proper solvers and preconditioners inside this function (or in the setup_jacobian callback above).
Arguments to the function are:
Parameters
-
[in]
ycur
The current vector for the current KINSOL internal step. In the documentation above, this vector is generally denoted by .
-
[in]
fcur
The current value of the implicit right-hand side at ycur, .
+
[in]
ycur
The current vector for the current KINSOL internal step. In the documentation above, this vector is generally denoted by .
+
[in]
fcur
The current value of the implicit right-hand side at ycur, .
[in]
rhs
The system right hand side to solve for
-
[out]
dst
The solution of
+
[out]
dst
The solution of
@@ -511,12 +511,12 @@
A function object that users may supply and that is intended to solve a linear system with the Jacobian matrix. This function will be called by KINSOL (possibly several times) after setup_jacobian() has been called at least once. KINSOL tries to do its best to call setup_jacobian() the minimum number of times. If convergence can be achieved without updating the Jacobian, then KINSOL does not call setup_jacobian() again. If, on the contrary, internal KINSOL convergence tests fail, then KINSOL calls setup_jacobian() again with updated vectors and coefficients so that successive calls to solve_with_jacobian() lead to better convergence in the Newton process.
If you do not specify a solve_with_jacobian function, then only a fixed point iteration strategy can be used. Notice that this may not converge, or may converge very slowly.
-
A call to this function should store in dst the result of applied to rhs, i.e., . It is the user's responsibility to set up proper solvers and preconditioners inside this function (or in the setup_jacobian callback above). The function attached to this callback is also provided with a tolerance to the linear solver, indicating that it is not necessary to solve the linear system with the Jacobian matrix exactly, but only to a tolerance that KINSOL will adapt over time.
+
A call to this function should store in dst the result of applied to rhs, i.e., . It is the user's responsibility to set up proper solvers and preconditioners inside this function (or in the setup_jacobian callback above). The function attached to this callback is also provided with a tolerance to the linear solver, indicating that it is not necessary to solve the linear system with the Jacobian matrix exactly, but only to a tolerance that KINSOL will adapt over time.
Arguments to the function are:
Parameters
[in]
rhs
The system right hand side to solve for.
-
[out]
dst
The solution of .
+
[out]
dst
The solution of .
[in]
tolerance
The tolerance with which to solve the linear system of equations.
@@ -541,7 +541,7 @@
A function object that users may supply and that is intended to return a vector whose components are the weights used by KINSOL to compute the vector norm of the solution. The implementation of this function is optional, and it is used only if implemented.
-
The intent for this scaling factor is for problems in which the different components of a solution have vastly different numerical magnitudes – typically because they have different physical units and represent different things. For example, if one were to solve a nonlinear Stokes problem, the solution vector has components that correspond to velocities and other components that correspond to pressures. These have different physical units and depending on which units one chooses, they may have roughly comparable numerical sizes or maybe they don't. To give just one example, in simulations of flow in the Earth's interior, one has velocities on the order of maybe ten centimeters per year, and pressures up to around 100 GPa. If one expresses this in SI units, this corresponds to velocities of around m/s, and pressures around , i.e., vastly different. In such cases, computing the norm of a solution-type vector (e.g., the difference between the previous and the current solution) makes no sense because the norm will either be dominated by the velocity components or the pressure components. The scaling vector this function returns is intended to provide each component of the solution with a scaling factor that is generally chosen as the inverse of a "typical velocity" or "typical pressure" so that upon multiplication of a vector component by the corresponding scaling vector component, one obtains a number that is of order of magnitude of one (i.e., a reasonably small multiple of one times the typical velocity/pressure). The KINSOL manual states this as follows: "The user should supply values \_form#href_anchor".
+
The intent for this scaling factor is for problems in which the different components of a solution have vastly different numerical magnitudes – typically because they have different physical units and represent different things. For example, if one were to solve a nonlinear Stokes problem, the solution vector has components that correspond to velocities and other components that correspond to pressures. These have different physical units and depending on which units one chooses, they may have roughly comparable numerical sizes or maybe they don't. To give just one example, in simulations of flow in the Earth's interior, one has velocities on the order of maybe ten centimeters per year, and pressures up to around 100 GPa. If one expresses this in SI units, this corresponds to velocities of around m/s, and pressures around , i.e., vastly different. In such cases, computing the norm of a solution-type vector (e.g., the difference between the previous and the current solution) makes no sense because the norm will either be dominated by the velocity components or the pressure components. The scaling vector this function returns is intended to provide each component of the solution with a scaling factor that is generally chosen as the inverse of a "typical velocity" or "typical pressure" so that upon multiplication of a vector component by the corresponding scaling vector component, one obtains a number that is of order of magnitude of one (i.e., a reasonably small multiple of one times the typical velocity/pressure). The KINSOL manual states this as follows: "The user should supply values \_form#href_anchor".
If no function is provided to a KINSOL object, then this is interpreted as implicitly saying that all of these scaling factors should be considered as one.
Note
This variable represents a user provided callback. See there for a description of how to deal with errors and other requirements and conventions. In particular, KINSOL can deal with "recoverable" errors in some circumstances, so callbacks can throw exceptions of type RecoverableUserCallbackError.
@@ -563,7 +563,7 @@
A function object that users may supply and that is intended to return a vector whose components are the weights used by KINSOL to compute the vector norm of the function evaluation away from the solution. The implementation of this function is optional, and it is used only if implemented.
-
The point of this function and the scaling vector it returns is similar to the one discussed above for get_solution_scaling, except that it is for a vector that scales the components of the function , rather than the components of , when computing norms. As above, if no function is provided, then this is equivalent to using a scaling vector whose components are all equal to one.
+
The point of this function and the scaling vector it returns is similar to the one discussed above for get_solution_scaling, except that it is for a vector that scales the components of the function , rather than the components of , when computing norms. As above, if no function is provided, then this is equivalent to using a scaling vector whose components are all equal to one.
Note
This variable represents a user provided callback. See there for a description of how to deal with errors and other requirements and conventions. In particular, KINSOL can deal with "recoverable" errors in some circumstances, so callbacks can throw exceptions of type RecoverableUserCallbackError.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classScaLAPACKMatrix.html differs (JavaScript source, ASCII text, with very long lines (1291))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classScaLAPACKMatrix.html 2023-11-25 15:25:58.359921237 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classScaLAPACKMatrix.html 2023-11-25 15:25:58.363254500 +0100
@@ -358,15 +358,15 @@
Detailed Description
template<typename NumberType>
class ScaLAPACKMatrix< NumberType >
A wrapper class around ScaLAPACK parallel dense linear algebra.
-
ScaLAPACK assumes that matrices are distributed according to the block-cyclic decomposition scheme. An by matrix is first decomposed into by blocks which are then uniformly distributed across the 2d process grid with processes, where are grid dimensions and is the total number of processes. The parameters MB and NB are referred to as row and column block size and determine the granularity of the block-cyclic distribution.
-
In the following the block-cyclic distribution of a matrix onto a Cartesian process grid with block sizes is displayed.
+
ScaLAPACK assumes that matrices are distributed according to the block-cyclic decomposition scheme. An by matrix is first decomposed into by blocks which are then uniformly distributed across the 2d process grid with processes, where are grid dimensions and is the total number of processes. The parameters MB and NB are referred to as row and column block size and determine the granularity of the block-cyclic distribution.
+
In the following the block-cyclic distribution of a matrix onto a Cartesian process grid with block sizes is displayed.
Block-Cyclic Distribution
-
Note that the odd number of columns of the local matrices owned by the processes P2, P5 and P8 accounts for not being an integral multiple of .
+
Note that the odd number of columns of the local matrices owned by the processes P2, P5 and P8 accounts for not being an integral multiple of .
The choice of the block sizes is a compromise between a sufficiently large size for efficient local/serial BLAS, but one that is also small enough to achieve good parallel load balance.
Below we show a strong scaling example of ScaLAPACKMatrix::invert() on up to 5 nodes each composed of two Intel Xeon 2660v2 IvyBridge sockets 2.20GHz, 10 cores/socket. Calculations are performed on square processor grids 1x1, 2x2, 3x3, 4x4, 5x5, 6x6, 7x7, 8x8, 9x9, 10x10.
@@ -621,7 +621,7 @@
Constructor for a rectangular matrix with n_rows and n_cols and distributed using the grid process_grid.
-
The parameters row_block_size and column_block_size are the block sizes used for the block-cyclic distribution of the matrix. In general, it is recommended to use powers of , e.g. .
+
The parameters row_block_size and column_block_size are the block sizes used for the block-cyclic distribution of the matrix. In general, it is recommended to use powers of , e.g. .
Constructor for a square matrix of size size, and distributed using the process grid in process_grid.
-
The parameter block_size is used for the block-cyclic distribution of the matrix. An identical block size is used for the rows and columns of the matrix. In general, it is recommended to use powers of , e.g. .
+
The parameter block_size is used for the block-cyclic distribution of the matrix. An identical block size is used for the rows and columns of the matrix. In general, it is recommended to use powers of , e.g. .
Constructor for a general rectangular matrix that is read from the file filename and distributed using the grid process_grid.
Loads the matrix from file filename using HDF5. In case that deal.II was built without HDF5 a call to this function will cause an exception to be thrown.
-
The parameters row_block_size and column_block_size are the block sizes used for the block-cyclic distribution of the matrix. In general, it is recommended to use powers of , e.g. .
+
The parameters row_block_size and column_block_size are the block sizes used for the block-cyclic distribution of the matrix. In general, it is recommended to use powers of , e.g. .
Initialize the rectangular matrix with n_rows and n_cols and distributed using the grid process_grid.
-
The parameters row_block_size and column_block_size are the block sizes used for the block-cyclic distribution of the matrix. In general, it is recommended to use powers of , e.g. .
+
The parameters row_block_size and column_block_size are the block sizes used for the block-cyclic distribution of the matrix. In general, it is recommended to use powers of , e.g. .
Initialize the square matrix of size size and distributed using the grid process_grid.
-
The parameter block_size is used for the block-cyclic distribution of the matrix. An identical block size is used for the rows and columns of the matrix. In general, it is recommended to use powers of , e.g. .
+
The parameter block_size is used for the block-cyclic distribution of the matrix. An identical block size is used for the rows and columns of the matrix. In general, it is recommended to use powers of , e.g. .
We will denote this solution function described by this DoFHandler and vector object by where is a vector with just one component, and consequently is not shown in boldface. Then assume that we want this to be used as a boundary condition for a 2d problem at the line . Let's say that this line corresponds to boundary indicator 123. If we say that the 2d problem is associated with
We will denote this solution function described by this DoFHandler and vector object by where is a vector with just one component, and consequently is not shown in boldface. Then assume that we want this to be used as a boundary condition for a 2d problem at the line . Let's say that this line corresponds to boundary indicator 123. If we say that the 2d problem is associated with
The question here is what to use as the Function object that can be passed as third argument. It needs to be a Function<2> object, i.e., it receives a 2d input point and is supposed to return the value at that point. What we want it to do is to just take the component of the input point and evaluate the 1d solution at that point, knowing that at the boundary with indicator 123, the component of the input point must be zero. This all can be achieved via the following function object:
The question here is what to use as the Function object that can be passed as third argument. It needs to be a Function<2> object, i.e., it receives a 2d input point and is supposed to return the value at that point. What we want it to do is to just take the component of the input point and evaluate the 1d solution at that point, knowing that at the boundary with indicator 123, the component of the input point must be zero. This all can be achieved via the following function object:
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classSolutionTransfer.html differs (JavaScript source, ASCII text, with very long lines (999))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classSolutionTransfer.html 2023-11-25 15:25:58.399920423 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classSolutionTransfer.html 2023-11-25 15:25:58.399920423 +0100
@@ -278,7 +278,7 @@
Interaction with hanging nodes
-
This class does its best to represent on the new mesh the finite element function that existed on the old mesh, but this may lead to situations where the function on the new mesh is no longer conforming at hanging nodes. To this end, consider a situation of a twice refined mesh that started with a single square cell (i.e., we now have 16 cells). Consider also that we coarsen 4 of the cells back to the first refinement level. In this case, we end up with a mesh that will look as follows if we were to use a element:
+
This class does its best to represent on the new mesh the finite element function that existed on the old mesh, but this may lead to situations where the function on the new mesh is no longer conforming at hanging nodes. To this end, consider a situation of a twice refined mesh that started with a single square cell (i.e., we now have 16 cells). Consider also that we coarsen 4 of the cells back to the first refinement level. In this case, we end up with a mesh that will look as follows if we were to use a element:
The function compute takes two arguments indicating the values of and of the gradient . When called, it needs to update the gradient at the given location and return the value of the function being minimized, i.e., .
+
The function compute takes two arguments indicating the values of and of the gradient . When called, it needs to update the gradient at the given location and return the value of the function being minimized, i.e., .
@@ -395,7 +395,7 @@
Connect a slot to perform a custom line-search.
-
Given the value of function f, the current value of unknown x, the gradient g and the search direction p, return the size of the step , and update x, g and f accordingly.
+
Given the value of function f, the current value of unknown x, the gradient g and the search direction p, return the size of the step , and update x, g and f accordingly.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classSolverCG.html differs (JavaScript source, ASCII text, with very long lines (1094))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classSolverCG.html 2023-11-25 15:25:58.433253075 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classSolverCG.html 2023-11-25 15:25:58.433253075 +0100
@@ -477,7 +477,7 @@
-
Solve the linear system for x.
+
Solve the linear system for x.
@@ -1115,7 +1115,7 @@
-
Flag to indicate whether the classical Fletcher–Reeves update formula for the parameter (standard CG algorithm, minimal storage needs) or the flexible conjugate gradient method with Polak-Ribiere formula for should be used. This base class implementation of SolverCG will always use the former method, whereas the derived class SolverFlexibleCG will use the latter.
+
Flag to indicate whether the classical Fletcher–Reeves update formula for the parameter (standard CG algorithm, minimal storage needs) or the flexible conjugate gradient method with Polak-Ribiere formula for should be used. This base class implementation of SolverCG will always use the former method, whereas the derived class SolverFlexibleCG will use the latter.
FIRE (Fast Inertial Relaxation Engine) for minimization of (potentially non-linear) objective function , is a vector of variables ( is the number of variables of the objective function). Like all other solver classes, it can work on any kind of vector and matrix as long as they satisfy certain requirements (for the requirements on matrices and vectors in order to work with this class, see the documentation of the Solver base class). The type of the solution vector must be passed as template argument, and defaults to Vector<double>.
+class SolverFIRE< VectorType >
FIRE (Fast Inertial Relaxation Engine) for minimization of (potentially non-linear) objective function , is a vector of variables ( is the number of variables of the objective function). Like all other solver classes, it can work on any kind of vector and matrix as long as they satisfy certain requirements (for the requirements on matrices and vectors in order to work with this class, see the documentation of the Solver base class). The type of the solution vector must be passed as template argument, and defaults to Vector<double>.
FIRE is a damped dynamics method described in Structural Relaxation Made Simple by Bitzek et al. 2006, typically used to find stable equilibrium configurations of atomistic systems in computational material science. Starting from a given initial configuration of the atomistic system, the algorithm relies on inertia to obtain (nearest) configuration with least potential energy.
Notation:
-
The global vector of unknown variables: .
-
Objective function: .
+
The global vector of unknown variables: .
+
Objective function: .
Rate of change of unknowns: .
-
Gradient of the objective function w.r.t unknowns: .
-
Mass matrix: .
-
Initial guess of unknowns: .
-
Time step: .
+
Gradient of the objective function w.r.t unknowns: .
+
Mass matrix: .
+
Initial guess of unknowns: .
+
Time step: .
-
Given initial values for , , , and along with a given mass matrix , FIRE algorithm is as follows,
-
Calculate and check for convergence ( ).
-
Update and using simple (forward) Euler integration step,
- ,
- .
-
Calculate .
-
Set .
-
If and number of steps since was last negative is larger than certain value, then increase time step and decrease .
-
If , then decrease the time step, freeze the system i.e., and reset .
+
Given initial values for , , , and along with a given mass matrix , FIRE algorithm is as follows,
+
Calculate and check for convergence ( ).
+
Update and using simple (forward) Euler integration step,
+ ,
+ .
+
Calculate .
+
Set .
+
If and number of steps since was last negative is larger than certain value, then increase time step and decrease .
+
If , then decrease the time step, freeze the system i.e., and reset .
This class implements a flexible variant of the conjugate gradient method, which is based on a different formula to compute in the process of constructing a new search direction that is A-orthogonal against the previous one. Rather than using the Fletcher–Reeves update formula with for computing the new search direction (here is the residual in step and ) as in the classical conjugate gradient algorithm, this class selects the Polak-Ribiere formula in the process of constructing a new search direction that is A-orthogonal against the previous one. Rather than using the Fletcher–Reeves update formula with for computing the new search direction (here is the residual in step and ) as in the classical conjugate gradient algorithm, this class selects the Polak-Ribiere formula . The additional term is zero for linear symmetric-positive definite preconditioners due to the construction of the search directions, so the behavior of SolverFlexibleCG is equivalent for those kinds of situations and merely increases costs by requiring an additional stored vector and associated vector operations. While there are no theoretical guarantees for convergence as in the classical CG algorithm, the current class has been documented to be much more robust for variable preconditioners (e.g., involving some iterative inverse that is not fully converged) or a preconditioner with some slight non-symmetry (like weighted Schwarz methods), which results from the local optimality of the search direction with at least as good progress as the locally optimal steepest descent method.
+\mathbf{z}_{k}\right)}{\mathbf{r}^T_{k} \mathbf{z}_{k}}$" src="form_1891.png"/>. The additional term is zero for linear symmetric-positive definite preconditioners due to the construction of the search directions, so the behavior of SolverFlexibleCG is equivalent for those kinds of situations and merely increases costs by requiring an additional stored vector and associated vector operations. While there are no theoretical guarantees for convergence as in the classical CG algorithm, the current class has been documented to be much more robust for variable preconditioners (e.g., involving some iterative inverse that is not fully converged) or a preconditioner with some slight non-symmetry (like weighted Schwarz methods), which results from the local optimality of the search direction with at least as good progress as the locally optimal steepest descent method.
Flag to indicate whether the classical Fletcher–Reeves update formula for the parameter (standard CG algorithm, minimal storage needs) or the flexible conjugate gradient method with Polak-Ribiere formula for should be used. This base class implementation of SolverCG will always use the former method, whereas the derived class SolverFlexibleCG will use the latter.
+
Flag to indicate whether the classical Fletcher–Reeves update formula for the parameter (standard CG algorithm, minimal storage needs) or the flexible conjugate gradient method with Polak-Ribiere formula for should be used. This base class implementation of SolverCG will always use the former method, whereas the derived class SolverFlexibleCG will use the latter.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classSolverGMRES.html differs (JavaScript source, ASCII text, with very long lines (1094))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classSolverGMRES.html 2023-11-25 15:25:58.499918386 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classSolverGMRES.html 2023-11-25 15:25:58.499918386 +0100
@@ -446,7 +446,7 @@
-
Solve the linear system for x.
+
Solve the linear system for x.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classSolverMinRes.html differs (JavaScript source, ASCII text, with very long lines (1094))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classSolverMinRes.html 2023-11-25 15:25:58.516584715 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classSolverMinRes.html 2023-11-25 15:25:58.516584715 +0100
@@ -403,7 +403,7 @@
-
Solve the linear system for x.
+
Solve the linear system for x.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classSolverQMRS.html differs (JavaScript source, ASCII text, with very long lines (1094))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classSolverQMRS.html 2023-11-25 15:25:58.533251043 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classSolverQMRS.html 2023-11-25 15:25:58.533251043 +0100
@@ -374,7 +374,7 @@
-
Solve the linear system for x.
+
Solve the linear system for x.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classSolverRichardson.html differs (JavaScript source, ASCII text, with very long lines (1094))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classSolverRichardson.html 2023-11-25 15:25:58.546584104 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classSolverRichardson.html 2023-11-25 15:25:58.546584104 +0100
@@ -404,7 +404,7 @@
-
Solve the linear system for x.
+
Solve the linear system for x.
@@ -448,7 +448,7 @@
-
Solve for .
+
Solve for .
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classSparseDirectUMFPACK.html differs (JavaScript source, ASCII text, with very long lines (708))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classSparseDirectUMFPACK.html 2023-11-25 15:25:58.566583697 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classSparseDirectUMFPACK.html 2023-11-25 15:25:58.566583697 +0100
@@ -617,8 +617,8 @@
The solution will be returned in place of the right hand side vector.
Parameters
-
[in,out]
rhs_and_solution
A vector that contains the right hand side of a linear system upon calling this function, and that contains the solution of the linear system after calling this function.
-
[in]
transpose
If set to true, this function solves the linear instead of .
+
[in,out]
rhs_and_solution
A vector that contains the right hand side of a linear system upon calling this function, and that contains the solution of the linear system after calling this function.
+
[in]
transpose
If set to true, this function solves the linear instead of .
@@ -652,7 +652,7 @@
Like the previous function, but for a complex-valued right hand side and solution vector.
-
If the matrix that was previously factorized had complex-valued entries, then the rhs_and_solution vector will, upon return from this function, simply contain the solution of the linear system . If the matrix was real-valued, then this is also true, but the solution will simply be computed by applying the factorized to both the real and imaginary parts of the right hand side vector.
+
If the matrix that was previously factorized had complex-valued entries, then the rhs_and_solution vector will, upon return from this function, simply contain the solution of the linear system . If the matrix was real-valued, then this is also true, but the solution will simply be computed by applying the factorized to both the real and imaginary parts of the right hand side vector.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classSparseILU.html differs (JavaScript source, ASCII text, with very long lines (670))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classSparseILU.html 2023-11-25 15:25:58.596583085 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classSparseILU.html 2023-11-25 15:25:58.596583085 +0100
@@ -2086,7 +2086,7 @@
-
Symmetrize the matrix by forming the mean value between the existing matrix and its transpose, .
+
Symmetrize the matrix by forming the mean value between the existing matrix and its transpose, .
This operation assumes that the underlying sparsity pattern represents a symmetric object. If this is not the case, then the result of this operation will not be a symmetric matrix, since it only explicitly symmetrizes by looping over the lower left triangular part for efficiency reasons; if there are entries in the upper right triangle, then these elements are missed in the symmetrization. Symmetrization of the sparsity pattern can be obtain by SparsityPattern::symmetrize().
@@ -2381,7 +2381,7 @@
-
Return the square of the norm of the vector with respect to the norm induced by this matrix, i.e. . This is useful, e.g. in the finite element context, where the norm of a function equals the matrix norm with respect to the mass matrix of the vector representing the nodal values of the finite element function.
+
Return the square of the norm of the vector with respect to the norm induced by this matrix, i.e. . This is useful, e.g. in the finite element context, where the norm of a function equals the matrix norm with respect to the mass matrix of the vector representing the nodal values of the finite element function.
Obviously, the matrix needs to be quadratic for this operation, and for the result to actually be a norm it also needs to be either real symmetric or complex hermitian.
The underlying template types of both this matrix and the given vector should either both be real or complex-valued, but not mixed, for this function to make sense.
Note
If deal.II is configured with threads, this operation will run multi-threaded by splitting the work into smaller chunks (assuming there is enough work to make this worthwhile).
@@ -2423,7 +2423,7 @@
-
Compute the matrix scalar product .
+
Compute the matrix scalar product .
Note
If deal.II is configured with threads, this operation will run multi-threaded by splitting the work into smaller chunks (assuming there is enough work to make this worthwhile).
@@ -2518,7 +2518,7 @@
Perform the matrix-matrix multiplication C = A * B, or, if an optional vector argument is given, C = A * diag(V) * B, where diag(V) defines a diagonal matrix with the vector entries.
This function assumes that the calling matrix A and the argument B have compatible sizes. By default, the output matrix C will be resized appropriately.
-
By default, i.e., if the optional argument rebuild_sparsity_pattern is true, the sparsity pattern of the matrix C will be changed to ensure that all entries that result from the product can be stored in . This is an expensive operation, and if there is a way to predict the sparsity pattern up front, you should probably build it yourself before calling this function with false as last argument. In this case, the rebuilding of the sparsity pattern is bypassed.
+
By default, i.e., if the optional argument rebuild_sparsity_pattern is true, the sparsity pattern of the matrix C will be changed to ensure that all entries that result from the product can be stored in . This is an expensive operation, and if there is a way to predict the sparsity pattern up front, you should probably build it yourself before calling this function with false as last argument. In this case, the rebuilding of the sparsity pattern is bypassed.
When setting rebuild_sparsity_pattern to true (i.e., leaving it at the default value), it is important to realize that the matrix C passed as first argument still has to be initialized with a sparsity pattern (either at the time of creation of the SparseMatrix object, or via the SparseMatrix::reinit() function). This is because we could create a sparsity pattern inside the current function, and then associate C with it, but there would be no way to transfer ownership of this sparsity pattern to anyone once the current function finishes. Consequently, the function requires that C be already associated with a sparsity pattern object, and this object is then reset to fit the product of A and B.
As a consequence of this, however, it is also important to realize that the sparsity pattern of C is modified and that this would render invalid all other SparseMatrix objects that happen to also use that sparsity pattern object.
@@ -2598,8 +2598,8 @@
-
Return the -norm of the matrix, that is , (max. sum of columns). This is the natural matrix norm that is compatible to the -norm for vectors, i.e. . (cf. Haemmerlin- Hoffmann: Numerische Mathematik)
+
Return the -norm of the matrix, that is , (max. sum of columns). This is the natural matrix norm that is compatible to the -norm for vectors, i.e. . (cf. Haemmerlin- Hoffmann: Numerische Mathematik)
@@ -2627,8 +2627,8 @@
-
Return the -norm of the matrix, that is , (max. sum of rows). This is the natural matrix norm that is compatible to the -norm of vectors, i.e. -norm of the matrix, that is , (max. sum of rows). This is the natural matrix norm that is compatible to the -norm of vectors, i.e. . (cf. Haemmerlin-Hoffmann: Numerische Mathematik)
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classSparseLUDecomposition.html differs (JavaScript source, ASCII text, with very long lines (706))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classSparseLUDecomposition.html 2023-11-25 15:25:58.629915742 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classSparseLUDecomposition.html 2023-11-25 15:25:58.629915742 +0100
@@ -1854,7 +1854,7 @@
-
Symmetrize the matrix by forming the mean value between the existing matrix and its transpose, .
+
Symmetrize the matrix by forming the mean value between the existing matrix and its transpose, .
This operation assumes that the underlying sparsity pattern represents a symmetric object. If this is not the case, then the result of this operation will not be a symmetric matrix, since it only explicitly symmetrizes by looping over the lower left triangular part for efficiency reasons; if there are entries in the upper right triangle, then these elements are missed in the symmetrization. Symmetrization of the sparsity pattern can be obtain by SparsityPattern::symmetrize().
@@ -2252,7 +2252,7 @@
-
Return the square of the norm of the vector with respect to the norm induced by this matrix, i.e. . This is useful, e.g. in the finite element context, where the norm of a function equals the matrix norm with respect to the mass matrix of the vector representing the nodal values of the finite element function.
+
Return the square of the norm of the vector with respect to the norm induced by this matrix, i.e. . This is useful, e.g. in the finite element context, where the norm of a function equals the matrix norm with respect to the mass matrix of the vector representing the nodal values of the finite element function.
Obviously, the matrix needs to be quadratic for this operation, and for the result to actually be a norm it also needs to be either real symmetric or complex hermitian.
The underlying template types of both this matrix and the given vector should either both be real or complex-valued, but not mixed, for this function to make sense.
Note
If deal.II is configured with threads, this operation will run multi-threaded by splitting the work into smaller chunks (assuming there is enough work to make this worthwhile).
@@ -2294,7 +2294,7 @@
-
Compute the matrix scalar product .
+
Compute the matrix scalar product .
Note
If deal.II is configured with threads, this operation will run multi-threaded by splitting the work into smaller chunks (assuming there is enough work to make this worthwhile).
@@ -2389,7 +2389,7 @@
Perform the matrix-matrix multiplication C = A * B, or, if an optional vector argument is given, C = A * diag(V) * B, where diag(V) defines a diagonal matrix with the vector entries.
This function assumes that the calling matrix A and the argument B have compatible sizes. By default, the output matrix C will be resized appropriately.
-
By default, i.e., if the optional argument rebuild_sparsity_pattern is true, the sparsity pattern of the matrix C will be changed to ensure that all entries that result from the product can be stored in . This is an expensive operation, and if there is a way to predict the sparsity pattern up front, you should probably build it yourself before calling this function with false as last argument. In this case, the rebuilding of the sparsity pattern is bypassed.
+
By default, i.e., if the optional argument rebuild_sparsity_pattern is true, the sparsity pattern of the matrix C will be changed to ensure that all entries that result from the product can be stored in . This is an expensive operation, and if there is a way to predict the sparsity pattern up front, you should probably build it yourself before calling this function with false as last argument. In this case, the rebuilding of the sparsity pattern is bypassed.
When setting rebuild_sparsity_pattern to true (i.e., leaving it at the default value), it is important to realize that the matrix C passed as first argument still has to be initialized with a sparsity pattern (either at the time of creation of the SparseMatrix object, or via the SparseMatrix::reinit() function). This is because we could create a sparsity pattern inside the current function, and then associate C with it, but there would be no way to transfer ownership of this sparsity pattern to anyone once the current function finishes. Consequently, the function requires that C be already associated with a sparsity pattern object, and this object is then reset to fit the product of A and B.
As a consequence of this, however, it is also important to realize that the sparsity pattern of C is modified and that this would render invalid all other SparseMatrix objects that happen to also use that sparsity pattern object.
@@ -2469,8 +2469,8 @@
-
Return the -norm of the matrix, that is , (max. sum of columns). This is the natural matrix norm that is compatible to the -norm for vectors, i.e. . (cf. Haemmerlin- Hoffmann: Numerische Mathematik)
+
Return the -norm of the matrix, that is , (max. sum of columns). This is the natural matrix norm that is compatible to the -norm for vectors, i.e. . (cf. Haemmerlin- Hoffmann: Numerische Mathematik)
@@ -2498,8 +2498,8 @@
-
Return the -norm of the matrix, that is , (max. sum of rows). This is the natural matrix norm that is compatible to the -norm of vectors, i.e. -norm of the matrix, that is , (max. sum of rows). This is the natural matrix norm that is compatible to the -norm of vectors, i.e. . (cf. Haemmerlin-Hoffmann: Numerische Mathematik)
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classSparseMIC.html differs (JavaScript source, ASCII text, with very long lines (670))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classSparseMIC.html 2023-11-25 15:25:58.663248397 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classSparseMIC.html 2023-11-25 15:25:58.663248397 +0100
@@ -425,8 +425,8 @@
template<typename number>
class SparseMIC< number >
Implementation of the Modified Incomplete Cholesky (MIC(0)) preconditioner for symmetric matrices. This class conforms to the state and usage specification in SparseLUDecomposition.
The decomposition
-
Let a symmetric, positive-definite, sparse matrix be in the form , where is the diagonal part of and is a strictly lower triangular matrix. The MIC(0) decomposition of the matrix is defined by , where is a diagonal matrix defined by the condition .
+
Let a symmetric, positive-definite, sparse matrix be in the form , where is the diagonal part of and is a strictly lower triangular matrix. The MIC(0) decomposition of the matrix is defined by , where is a diagonal matrix defined by the condition .
Symmetrize the matrix by forming the mean value between the existing matrix and its transpose, .
+
Symmetrize the matrix by forming the mean value between the existing matrix and its transpose, .
This operation assumes that the underlying sparsity pattern represents a symmetric object. If this is not the case, then the result of this operation will not be a symmetric matrix, since it only explicitly symmetrizes by looping over the lower left triangular part for efficiency reasons; if there are entries in the upper right triangle, then these elements are missed in the symmetrization. Symmetrization of the sparsity pattern can be obtain by SparsityPattern::symmetrize().
@@ -2447,7 +2447,7 @@
-
Return the square of the norm of the vector with respect to the norm induced by this matrix, i.e. . This is useful, e.g. in the finite element context, where the norm of a function equals the matrix norm with respect to the mass matrix of the vector representing the nodal values of the finite element function.
+
Return the square of the norm of the vector with respect to the norm induced by this matrix, i.e. . This is useful, e.g. in the finite element context, where the norm of a function equals the matrix norm with respect to the mass matrix of the vector representing the nodal values of the finite element function.
Obviously, the matrix needs to be quadratic for this operation, and for the result to actually be a norm it also needs to be either real symmetric or complex hermitian.
The underlying template types of both this matrix and the given vector should either both be real or complex-valued, but not mixed, for this function to make sense.
Note
If deal.II is configured with threads, this operation will run multi-threaded by splitting the work into smaller chunks (assuming there is enough work to make this worthwhile).
@@ -2489,7 +2489,7 @@
-
Compute the matrix scalar product .
+
Compute the matrix scalar product .
Note
If deal.II is configured with threads, this operation will run multi-threaded by splitting the work into smaller chunks (assuming there is enough work to make this worthwhile).
@@ -2584,7 +2584,7 @@
Perform the matrix-matrix multiplication C = A * B, or, if an optional vector argument is given, C = A * diag(V) * B, where diag(V) defines a diagonal matrix with the vector entries.
This function assumes that the calling matrix A and the argument B have compatible sizes. By default, the output matrix C will be resized appropriately.
-
By default, i.e., if the optional argument rebuild_sparsity_pattern is true, the sparsity pattern of the matrix C will be changed to ensure that all entries that result from the product can be stored in . This is an expensive operation, and if there is a way to predict the sparsity pattern up front, you should probably build it yourself before calling this function with false as last argument. In this case, the rebuilding of the sparsity pattern is bypassed.
+
By default, i.e., if the optional argument rebuild_sparsity_pattern is true, the sparsity pattern of the matrix C will be changed to ensure that all entries that result from the product can be stored in . This is an expensive operation, and if there is a way to predict the sparsity pattern up front, you should probably build it yourself before calling this function with false as last argument. In this case, the rebuilding of the sparsity pattern is bypassed.
When setting rebuild_sparsity_pattern to true (i.e., leaving it at the default value), it is important to realize that the matrix C passed as first argument still has to be initialized with a sparsity pattern (either at the time of creation of the SparseMatrix object, or via the SparseMatrix::reinit() function). This is because we could create a sparsity pattern inside the current function, and then associate C with it, but there would be no way to transfer ownership of this sparsity pattern to anyone once the current function finishes. Consequently, the function requires that C be already associated with a sparsity pattern object, and this object is then reset to fit the product of A and B.
As a consequence of this, however, it is also important to realize that the sparsity pattern of C is modified and that this would render invalid all other SparseMatrix objects that happen to also use that sparsity pattern object.
@@ -2664,8 +2664,8 @@
-
Return the -norm of the matrix, that is , (max. sum of columns). This is the natural matrix norm that is compatible to the -norm for vectors, i.e. . (cf. Haemmerlin- Hoffmann: Numerische Mathematik)
+
Return the -norm of the matrix, that is , (max. sum of columns). This is the natural matrix norm that is compatible to the -norm for vectors, i.e. . (cf. Haemmerlin- Hoffmann: Numerische Mathematik)
@@ -2693,8 +2693,8 @@
-
Return the -norm of the matrix, that is , (max. sum of rows). This is the natural matrix norm that is compatible to the -norm of vectors, i.e. -norm of the matrix, that is , (max. sum of rows). This is the natural matrix norm that is compatible to the -norm of vectors, i.e. . (cf. Haemmerlin-Hoffmann: Numerische Mathematik)
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classSparseMatrix.html differs (JavaScript source, ASCII text, with very long lines (679))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classSparseMatrix.html 2023-11-25 15:25:58.693247785 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classSparseMatrix.html 2023-11-25 15:25:58.693247785 +0100
@@ -1561,7 +1561,7 @@
-
Symmetrize the matrix by forming the mean value between the existing matrix and its transpose, .
+
Symmetrize the matrix by forming the mean value between the existing matrix and its transpose, .
This operation assumes that the underlying sparsity pattern represents a symmetric object. If this is not the case, then the result of this operation will not be a symmetric matrix, since it only explicitly symmetrizes by looping over the lower left triangular part for efficiency reasons; if there are entries in the upper right triangle, then these elements are missed in the symmetrization. Symmetrization of the sparsity pattern can be obtain by SparsityPattern::symmetrize().
@@ -1997,7 +1997,7 @@
-
Return the square of the norm of the vector with respect to the norm induced by this matrix, i.e. . This is useful, e.g. in the finite element context, where the norm of a function equals the matrix norm with respect to the mass matrix of the vector representing the nodal values of the finite element function.
+
Return the square of the norm of the vector with respect to the norm induced by this matrix, i.e. . This is useful, e.g. in the finite element context, where the norm of a function equals the matrix norm with respect to the mass matrix of the vector representing the nodal values of the finite element function.
Obviously, the matrix needs to be quadratic for this operation, and for the result to actually be a norm it also needs to be either real symmetric or complex hermitian.
The underlying template types of both this matrix and the given vector should either both be real or complex-valued, but not mixed, for this function to make sense.
Note
If deal.II is configured with threads, this operation will run multi-threaded by splitting the work into smaller chunks (assuming there is enough work to make this worthwhile).
@@ -2031,7 +2031,7 @@
-
Compute the matrix scalar product .
+
Compute the matrix scalar product .
Note
If deal.II is configured with threads, this operation will run multi-threaded by splitting the work into smaller chunks (assuming there is enough work to make this worthwhile).
@@ -2110,7 +2110,7 @@
Perform the matrix-matrix multiplication C = A * B, or, if an optional vector argument is given, C = A * diag(V) * B, where diag(V) defines a diagonal matrix with the vector entries.
This function assumes that the calling matrix A and the argument B have compatible sizes. By default, the output matrix C will be resized appropriately.
-
By default, i.e., if the optional argument rebuild_sparsity_pattern is true, the sparsity pattern of the matrix C will be changed to ensure that all entries that result from the product can be stored in . This is an expensive operation, and if there is a way to predict the sparsity pattern up front, you should probably build it yourself before calling this function with false as last argument. In this case, the rebuilding of the sparsity pattern is bypassed.
+
By default, i.e., if the optional argument rebuild_sparsity_pattern is true, the sparsity pattern of the matrix C will be changed to ensure that all entries that result from the product can be stored in . This is an expensive operation, and if there is a way to predict the sparsity pattern up front, you should probably build it yourself before calling this function with false as last argument. In this case, the rebuilding of the sparsity pattern is bypassed.
When setting rebuild_sparsity_pattern to true (i.e., leaving it at the default value), it is important to realize that the matrix C passed as first argument still has to be initialized with a sparsity pattern (either at the time of creation of the SparseMatrix object, or via the SparseMatrix::reinit() function). This is because we could create a sparsity pattern inside the current function, and then associate C with it, but there would be no way to transfer ownership of this sparsity pattern to anyone once the current function finishes. Consequently, the function requires that C be already associated with a sparsity pattern object, and this object is then reset to fit the product of A and B.
As a consequence of this, however, it is also important to realize that the sparsity pattern of C is modified and that this would render invalid all other SparseMatrix objects that happen to also use that sparsity pattern object.
@@ -2174,8 +2174,8 @@
-
Return the -norm of the matrix, that is , (max. sum of columns). This is the natural matrix norm that is compatible to the -norm for vectors, i.e. . (cf. Haemmerlin- Hoffmann: Numerische Mathematik)
+
Return the -norm of the matrix, that is , (max. sum of columns). This is the natural matrix norm that is compatible to the -norm for vectors, i.e. . (cf. Haemmerlin- Hoffmann: Numerische Mathematik)
@@ -2195,8 +2195,8 @@
-
Return the -norm of the matrix, that is , (max. sum of rows). This is the natural matrix norm that is compatible to the -norm of vectors, i.e. -norm of the matrix, that is , (max. sum of rows). This is the natural matrix norm that is compatible to the -norm of vectors, i.e. . (cf. Haemmerlin-Hoffmann: Numerische Mathematik)
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classSparseMatrixEZ.html differs (JavaScript source, ASCII text, with very long lines (792))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classSparseMatrixEZ.html 2023-11-25 15:25:58.716580645 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classSparseMatrixEZ.html 2023-11-25 15:25:58.716580645 +0100
@@ -1345,7 +1345,7 @@
-
Matrix-vector multiplication: let with being this matrix.
+
Matrix-vector multiplication: let with being this matrix.
@@ -1376,7 +1376,7 @@
-
Matrix-vector multiplication: let with being this matrix. This function does the same as vmult but takes the transposed matrix.
+
Matrix-vector multiplication: let with being this matrix. This function does the same as vmult but takes the transposed matrix.
@@ -1407,7 +1407,7 @@
-
Adding Matrix-vector multiplication. Add on with being this matrix.
+
Adding Matrix-vector multiplication. Add on with being this matrix.
@@ -1438,7 +1438,7 @@
-
Adding Matrix-vector multiplication. Add to with being this matrix. This function does the same as vmult_add but takes the transposed matrix.
+
Adding Matrix-vector multiplication. Add to with being this matrix. This function does the same as vmult_add but takes the transposed matrix.
@@ -1575,7 +1575,7 @@
-
Apply SOR preconditioning matrix to src. The result of this method is .
+
Apply SOR preconditioning matrix to src. The result of this method is .
@@ -1612,7 +1612,7 @@
-
Apply transpose SOR preconditioning matrix to src. The result of this method is .
+
Apply transpose SOR preconditioning matrix to src. The result of this method is .
@@ -1657,7 +1657,7 @@
-
Add the matrix A conjugated by B, that is, to this object. If the parameter transpose is true, compute .
+
Add the matrix A conjugated by B, that is, to this object. If the parameter transpose is true, compute .
This function requires that B has a const_iterator traversing all matrix entries and that A has a function el(i,j) for access to a specific entry.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classSparseMatrixIterators_1_1Iterator.html differs (JavaScript source, ASCII text, with very long lines (1282))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classSparseMatrixIterators_1_1Iterator.html 2023-11-25 15:25:58.733246970 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classSparseMatrixIterators_1_1Iterator.html 2023-11-25 15:25:58.733246970 +0100
@@ -141,7 +141,7 @@
The typical use for these iterators is to iterate over the elements of a sparse matrix or over the elements of individual rows. Note that there is no guarantee that the elements of a row are actually traversed in an order in which columns monotonically increase. See the documentation of the SparsityPattern class for more information.
The first template argument denotes the underlying numeric type, the second the constness of the matrix.
Since there is a specialization of this class for Constness=false, this class is for iterators to constant matrices.
-
Note
This class operates directly on the internal data structures of the SparsityPattern and SparseMatrix classes. As a consequence, some operations are cheap and some are not. In particular, it is cheap to access the column index and the value of an entry pointed to. On the other hand, it is expensive to access the row index (this requires operations for a matrix with row). As a consequence, when you design algorithms that use these iterators, it is common practice to not loop over all elements of a sparse matrix at once, but to have an outer loop over all rows and within this loop iterate over the elements of this row. This way, you only ever need to dereference the iterator to obtain the column indices and values whereas the (expensive) lookup of the row index can be avoided by using the loop index instead.
+
Note
This class operates directly on the internal data structures of the SparsityPattern and SparseMatrix classes. As a consequence, some operations are cheap and some are not. In particular, it is cheap to access the column index and the value of an entry pointed to. On the other hand, it is expensive to access the row index (this requires operations for a matrix with row). As a consequence, when you design algorithms that use these iterators, it is common practice to not loop over all elements of a sparse matrix at once, but to have an outer loop over all rows and within this loop iterate over the elements of this row. This way, you only ever need to dereference the iterator to obtain the column indices and values whereas the (expensive) lookup of the row index can be avoided by using the loop index instead.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classSparsityPattern.html differs (JavaScript source, ASCII text, with very long lines (1189))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classSparsityPattern.html 2023-11-25 15:25:58.756579831 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classSparsityPattern.html 2023-11-25 15:25:58.756579831 +0100
@@ -1282,7 +1282,7 @@
-
Compute the bandwidth of the matrix represented by this structure. The bandwidth is the maximum of for which the index pair represents a nonzero entry of the matrix. Consequently, the maximum bandwidth a matrix can have is , a diagonal matrix has bandwidth 0, and there are at most entries per row if the bandwidth is . The returned quantity is sometimes called "half
+
Compute the bandwidth of the matrix represented by this structure. The bandwidth is the maximum of for which the index pair represents a nonzero entry of the matrix. Consequently, the maximum bandwidth a matrix can have is , a diagonal matrix has bandwidth 0, and there are at most entries per row if the bandwidth is . The returned quantity is sometimes called "half
bandwidth" in the literature.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classSparsityPatternIterators_1_1Iterator.html differs (JavaScript source, ASCII text, with very long lines (1211))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classSparsityPatternIterators_1_1Iterator.html 2023-11-25 15:25:58.769912893 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classSparsityPatternIterators_1_1Iterator.html 2023-11-25 15:25:58.769912893 +0100
@@ -158,7 +158,7 @@
Detailed Description
An iterator class for walking over the elements of a sparsity pattern.
The typical use for these iterators is to iterate over the elements of a sparsity pattern (or, since they also serve as the basis for iterating over the elements of an associated matrix, over the elements of a sparse matrix), or over the elements of individual rows. There is no guarantee that the elements of a row are actually traversed in an order in which column numbers monotonically increase. See the documentation of the SparsityPattern class for more information.
-
Note
This class operates directly on the internal data structures of the SparsityPattern class. As a consequence, some operations are cheap and some are not. In particular, it is cheap to access the column index of the sparsity pattern entry pointed to. On the other hand, it is expensive to access the row index (this requires operations for a matrix with row). As a consequence, when you design algorithms that use these iterators, it is common practice to not loop over all elements of a sparsity pattern at once, but to have an outer loop over all rows and within this loop iterate over the elements of this row. This way, you only ever need to dereference the iterator to obtain the column indices whereas the (expensive) lookup of the row index can be avoided by using the loop index instead.
+
Note
This class operates directly on the internal data structures of the SparsityPattern class. As a consequence, some operations are cheap and some are not. In particular, it is cheap to access the column index of the sparsity pattern entry pointed to. On the other hand, it is expensive to access the row index (this requires operations for a matrix with row). As a consequence, when you design algorithms that use these iterators, it is common practice to not loop over all elements of a sparsity pattern at once, but to have an outer loop over all rows and within this loop iterate over the elements of this row. This way, you only ever need to dereference the iterator to obtain the column indices whereas the (expensive) lookup of the row index can be avoided by using the loop index instead.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classSphericalManifold.html differs (JavaScript source, ASCII text, with very long lines (1341))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classSphericalManifold.html 2023-11-25 15:25:58.789912484 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classSphericalManifold.html 2023-11-25 15:25:58.789912484 +0100
@@ -217,20 +217,20 @@
class SphericalManifold< dim, spacedim >
Manifold description for a spherical space coordinate system.
You can use this Manifold object to describe any sphere, circle, hypersphere or hyperdisc in two or three dimensions. This manifold can be used as a co-dimension one manifold descriptor of a spherical surface embedded in a higher dimensional space, or as a co-dimension zero manifold descriptor for a body with positive volume, provided that the center of the spherical space is excluded from the domain. An example for the use of this function would be in the description of a hyper-shell or hyper-ball geometry, for example after creating a coarse mesh using GridGenerator::hyper_ball(). (However, it is worth mentioning that generating a good mesh for a disk or ball is complicated and requires addition steps. See the "Possibilities for extensions" section of step-6 for an extensive discussion of how one would construct such meshes and what one needs to do for it.)
The two template arguments match the meaning of the two template arguments in Triangulation<dim, spacedim>, however this Manifold can be used to describe both thin and thick objects, and the behavior is identical when dim <= spacedim, i.e., the functionality of SphericalManifold<2,3> is identical to SphericalManifold<3,3>.
-
While PolarManifold reflects the usual notion of polar coordinates, it may not be suitable for domains that contain either the north or south poles. Consider for instance the pair of points and in polar coordinates (lying on the surface of a sphere with radius one, on a parallel at height ). In this case connecting the points with a straight line in polar coordinates would take the long road around the globe, without passing through the north pole.
+
While PolarManifold reflects the usual notion of polar coordinates, it may not be suitable for domains that contain either the north or south poles. Consider for instance the pair of points and in polar coordinates (lying on the surface of a sphere with radius one, on a parallel at height ). In this case connecting the points with a straight line in polar coordinates would take the long road around the globe, without passing through the north pole.
These two points would be connected (using a PolarManifold) by the curve
-
+\end{align*}" src="form_1449.png"/>
This curve is not a geodesic on the sphere, and it is not how we would connect those two points. A better curve, would be the one passing through the North pole:
-
+\]" src="form_1450.png"/>
-
where and for . Indeed, this is a geodesic, and it is the natural choice when connecting points on the surface of the sphere. In the examples above, the PolarManifold class implements the first way of connecting two points on the surface of a sphere, while SphericalManifold implements the second way, i.e., this Manifold connects points using geodesics. If more than two points are involved through a SphericalManifold::get_new_points() call, a so-called spherical average is used where the final point minimizes the weighted distance to all other points via geodesics.
+
where and for . Indeed, this is a geodesic, and it is the natural choice when connecting points on the surface of the sphere. In the examples above, the PolarManifold class implements the first way of connecting two points on the surface of a sphere, while SphericalManifold implements the second way, i.e., this Manifold connects points using geodesics. If more than two points are involved through a SphericalManifold::get_new_points() call, a so-called spherical average is used where the final point minimizes the weighted distance to all other points via geodesics.
In particular, this class implements a Manifold that joins any two points in space by first projecting them onto the surface of a sphere with unit radius, then connecting them with a geodesic, and finally rescaling the final radius so that the resulting one is the weighted average of the starting radii. This Manifold is identical to PolarManifold in dimension two, while for dimension three it returns points that are more uniformly distributed on the sphere, and it is invariant with respect to rotations of the coordinate system, therefore avoiding the problems that PolarManifold has at the poles. Notice, in particular, that computing tangent vectors at the poles with a PolarManifold is not well defined, while it is perfectly fine with this class.
For mathematical reasons, it is impossible to construct a unique map of a sphere using only geodesic curves, and therefore, using this class with MappingManifold is discouraged. If you use this Manifold to describe the geometry of a sphere, you should use MappingQ as the underlying mapping, and not MappingManifold.
This Manifold can be used only on geometries where a ball with finite radius is removed from the center. Indeed, the center is a singular point for this manifold, and if you try to connect two points across the center, they would travel on spherical coordinates, avoiding the center.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classSymmetricTensor.html differs (JavaScript source, ASCII text, with very long lines (743))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classSymmetricTensor.html 2023-11-25 15:25:58.823245141 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classSymmetricTensor.html 2023-11-25 15:25:58.823245141 +0100
@@ -299,7 +299,7 @@
template<int rank_, int dim, typename Number>
-class SymmetricTensor< rank_, dim, Number >
Provide a class that stores symmetric tensors of rank 2,4,... efficiently, i.e. only store those off-diagonal elements of the full tensor that are not redundant. For example, for symmetric tensors, this would be the elements 11, 22, and 12, while the element 21 is equal to the 12 element. Within this documentation, second order symmetric tensors are denoted as bold-faced upper-case Latin letters such as or bold-faced Greek letters such as , . The Cartesian coordinates of a second-order tensor such as are represented as where are indices ranging from 0 to dim-1.
+class SymmetricTensor< rank_, dim, Number >
Provide a class that stores symmetric tensors of rank 2,4,... efficiently, i.e. only store those off-diagonal elements of the full tensor that are not redundant. For example, for symmetric tensors, this would be the elements 11, 22, and 12, while the element 21 is equal to the 12 element. Within this documentation, second order symmetric tensors are denoted as bold-faced upper-case Latin letters such as or bold-faced Greek letters such as , . The Cartesian coordinates of a second-order tensor such as are represented as where are indices ranging from 0 to dim-1.
Using this class for symmetric tensors of rank 2 has advantages over matrices in many cases since the dimension is known to the compiler as well as the location of the data. It is therefore possible to produce far more efficient code than for matrices with runtime-dependent dimension. It is also more efficient than using the more general Tensor class, since fewer elements are stored, and the class automatically makes sure that the tensor represents a symmetric object.
For tensors of higher rank, the savings in storage are even higher. For example for the tensors of rank 4, only 36 instead of the full 81 entries have to be stored. These rank 4 tensors are denoted by blackboard-style upper-case Latin letters such as with components .
While the definition of a symmetric rank-2 tensor is obvious, tensors of rank 4 are considered symmetric if they are operators mapping symmetric rank-2 tensors onto symmetric rank-2 tensors. This so-called minor symmetry of the rank 4 tensor requires that for every set of four indices , the identity
-
This operator assigns a scalar to a tensor. To avoid confusion with what exactly it means to assign a scalar value to a tensor, zero is the only value allowed for d, allowing the intuitive notation to reset all elements of the tensor to zero.
+
This operator assigns a scalar to a tensor. To avoid confusion with what exactly it means to assign a scalar value to a tensor, zero is the only value allowed for d, allowing the intuitive notation to reset all elements of the tensor to zero.
@@ -887,8 +887,8 @@
-
Double contraction product between the present symmetric tensor and a tensor of rank 2. For example, if the present object is the symmetric rank-2 tensor and it is multiplied by another symmetric rank-2 tensor , then the result is the scalar-product double contraction . In this case, the return value evaluates to a single scalar. While it is possible to define other scalar products (and associated induced norms), this one seems to be the most appropriate one.
-
If the present object is a rank-4 tensor such as , then the result is a rank-2 tensor , i.e., the operation contracts over the last two indices of the present object and the indices of the argument, and the result is a tensor of rank 2 ( ).
+
Double contraction product between the present symmetric tensor and a tensor of rank 2. For example, if the present object is the symmetric rank-2 tensor and it is multiplied by another symmetric rank-2 tensor , then the result is the scalar-product double contraction . In this case, the return value evaluates to a single scalar. While it is possible to define other scalar products (and associated induced norms), this one seems to be the most appropriate one.
+
If the present object is a rank-4 tensor such as , then the result is a rank-2 tensor , i.e., the operation contracts over the last two indices of the present object and the indices of the argument, and the result is a tensor of rank 2 ( ).
Note that the multiplication operator for symmetric tensors is defined to be a double contraction over two indices, while it is defined as a single contraction over only one index for regular Tensor objects. For symmetric tensors it therefore acts in a way that is commonly denoted by a "colon multiplication" in the mathematical literature (the two dots of the colon suggesting that it is a contraction over two indices), which corresponds to a scalar product between tensors.
It is worth pointing out that this definition of operator* between symmetric tensors is different to how the (in general non-symmetric) Tensor class defines operator*, namely as the single-contraction product over the last index of the first operand and the first index of the second operand. For the double contraction of Tensor objects, you will need to use the double_contract() function.
To maintain at least a modicum of resemblance between the interfaces of Tensor and SymmetricTensor, there are also global functions double_contract() for symmetric tensors that then do the same work as this operator. However, rather than returning the result as a return value, they write it into the first argument to the function in the same way as the corresponding functions for the Tensor class do things.
@@ -1232,7 +1232,7 @@
-
The opposite of the previous function: given an index in the unrolled form of the tensor, return what set of indices (for rank-2 tensors) or (for rank-4 tensors) corresponds to it.
+
The opposite of the previous function: given an index in the unrolled form of the tensor, return what set of indices (for rank-2 tensors) or (for rank-4 tensors) corresponds to it.
@@ -1470,7 +1470,7 @@
-
Return the fourth-order symmetric identity tensor which maps symmetric second-order tensors, such as , to themselves.
+
Return the fourth-order symmetric identity tensor which maps symmetric second-order tensors, such as , to themselves.
@@ -1924,7 +1924,7 @@
-
Compute the second invariant of a tensor of rank 2. The second invariant of a tensor is defined as is defined as .
For the kind of arguments to this function, i.e., a rank-2 tensor of size 1, the result is simply zero.
@@ -1956,11 +1956,11 @@
-
Compute the second invariant of a tensor of rank 2. The second invariant of a tensor is defined as is defined as .
For the kind of arguments to this function, i.e., a symmetric rank-2 tensor of size 2, the result is (counting indices starting at one) . As expected, for the symmetric tensors this function handles, this equals the determinant of the tensor. (This is so because for symmetric tensors, there really are only two invariants, so the second and third invariant are the same; the determinant is the third invariant.)
+ = A_{11} A_{22} - A_{12}^2$" src="form_810.png"/>. As expected, for the symmetric tensors this function handles, this equals the determinant of the tensor. (This is so because for symmetric tensors, there really are only two invariants, so the second and third invariant are the same; the determinant is the third invariant.)
The algorithm employed here determines the eigenvalues by computing the roots of the characteristic polynomial. In the case that there exists a common root (the eigenvalues are equal), the computation is subject to round-off errors of order . As an alternative, the eigenvectors() function provides a more robust, but costly, method to compute the eigenvalues of a symmetric tensor.
@@ -2662,7 +2662,7 @@
-
Compute the scalar product between two tensors of rank 2. In the current case where both arguments are symmetric tensors, this is equivalent to calling the expression A*B which uses SymmetricTensor::operator*().
+
Compute the scalar product between two tensors of rank 2. In the current case where both arguments are symmetric tensors, this is equivalent to calling the expression A*B which uses SymmetricTensor::operator*().
Compute the scalar product between two tensors of rank 2. We don't use operator* for this operation since the product between two tensors is usually assumed to be the contraction over the last index of the first tensor and the first index of the second tensor. For example, if B is a Tensor, calling A*B (instead of scalar_product(A,B)) provides .
+
Compute the scalar product between two tensors of rank 2. We don't use operator* for this operation since the product between two tensors is usually assumed to be the contraction over the last index of the first tensor and the first index of the second tensor. For example, if B is a Tensor, calling A*B (instead of scalar_product(A,B)) provides .
Compute the scalar product between two tensors of rank 2. We don't use operator* for this operation since the product between two tensors is usually assumed to be the contraction over the last index of the first tensor and the first index of the second tensor. For example, if A is a Tensor, calling A*B (instead of scalar_product(A,B)) provides .
+
Compute the scalar product between two tensors of rank 2. We don't use operator* for this operation since the product between two tensors is usually assumed to be the contraction over the last index of the first tensor and the first index of the second tensor. For example, if A is a Tensor, calling A*B (instead of scalar_product(A,B)) provides .
The dot product (single contraction) for tensors: Return a tensor of rank that is the contraction of the last index of a tensor src1 of rank rank_1 with the first index of a tensor src2 of rank rank_2:
- that is the contraction of the last index of a tensor src1 of rank rank_1 with the first index of a tensor src2 of rank rank_2:
+
+\]" src="form_827.png"/>
Note
As one operand is a Tensor, the multiplication operator only performs a contraction over a single pair of indices. This is in contrast to the multiplication operator for SymmetricTensor, which does the double contraction.
@@ -3174,13 +3174,13 @@
-
The dot product (single contraction) for tensors: Return a tensor of rank that is the contraction of the last index of a tensor src1 of rank rank_1 with the first index of a tensor src2 of rank rank_2:
- that is the contraction of the last index of a tensor src1 of rank rank_1 with the first index of a tensor src2 of rank rank_2:
+
+\]" src="form_827.png"/>
Note
As one operand is a Tensor, the multiplication operator only performs a contraction over a single pair of indices. This is in contrast to the multiplication operator for SymmetricTensor, which does the double contraction.
An integer denoting the number of independent components that fully describe a symmetric tensor. In space dimensions, this number equals for symmetric tensors of rank 2.
+
An integer denoting the number of independent components that fully describe a symmetric tensor. In space dimensions, this number equals for symmetric tensors of rank 2.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classTableBase.html differs (JavaScript source, ASCII text, with very long lines (933))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classTableBase.html 2023-11-25 15:25:58.843244734 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classTableBase.html 2023-11-25 15:25:58.843244734 +0100
@@ -231,7 +231,7 @@
In some way, this class is similar to the Tensor class, in that it templatizes on the number of dimensions. However, there are two major differences. The first is that the Tensor class stores only numeric values (as doubles), while the Table class stores arbitrary objects. The second is that the Tensor class has fixed sizes in each dimension, also given as a template argument, while this class can handle arbitrary and different sizes in each dimension.
This has two consequences. First, since the size is not known at compile time, it has to do explicit memory allocation. Second, the layout of individual elements is not known at compile time, so access is slower than for the Tensor class where the number of elements are their location is known at compile time and the compiler can optimize with this knowledge (for example when unrolling loops). On the other hand, this class is of course more flexible, for example when you want a two-dimensional table with the number of rows equal to the number of degrees of freedom on a cell, and the number of columns equal to the number of quadrature points. Both numbers may only be known at run-time, so a flexible table is needed here. Furthermore, you may want to store, say, the gradients of shape functions, so the data type is not a single scalar value, but a tensor itself.
Dealing with large data sets
-
The Table classes (derived from this class) are frequently used to store large data tables. A modest example is given in step-53 where we store a table of geographic elevation data for a region of Africa, and this data requires about 670 kB if memory; however, tables that store three- or more-dimensional data (say, information about the density, pressure, and temperature in the earth interior on a regular grid of (latitude, longitude, depth) points) can easily run into hundreds of megabytes or more. These tables are then often provided to classes such as InterpolatedTensorProductGridData or InterpolatedUniformGridData.
+
The Table classes (derived from this class) are frequently used to store large data tables. A modest example is given in step-53 where we store a table of geographic elevation data for a region of Africa, and this data requires about 670 kB if memory; however, tables that store three- or more-dimensional data (say, information about the density, pressure, and temperature in the earth interior on a regular grid of (latitude, longitude, depth) points) can easily run into hundreds of megabytes or more. These tables are then often provided to classes such as InterpolatedTensorProductGridData or InterpolatedUniformGridData.
If you need to load such tables on single-processor (or multi-threaded) jobs, then there is nothing you can do about the size of these tables: The table just has to fit into memory. But, if your program is parallelized via MPI, then a typical first implementation would create a table object on every process and fill it on every MPI process by reading the data from a file. This is inefficient from two perspectives:
You will have a lot of processes that are all trying to read from the same file at the same time.
In most cases, the data stored on every process is the same, and while every process needs to be able to read from a table, it is not necessary that every process stores its own table: All MPI processes that happen to be located on the same machine might as well store only one copy and make it available to each other via shared memory; in this model, only one MPI process per machine needs to store the data, and all other processes could then access it.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classTableHandler.html differs (JavaScript source, ASCII text, with very long lines (1181))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classTableHandler.html 2023-11-25 15:25:58.859911059 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classTableHandler.html 2023-11-25 15:25:58.859911059 +0100
@@ -199,7 +199,7 @@
Two (or more) columns may be merged into a "supercolumn" by twice (or multiple) calling add_column_to_supercolumn(), see there. Additionally there is a function to set for each column the precision of the output of numbers, and there are several functions to prescribe the format and the captions the columns are written with in tex mode.
A detailed explanation of this class is also given in the step-13 tutorial program.
Example
-
This is a simple example demonstrating the usage of this class. The first column includes the numbers , the second , the third , where the second and third columns are merged into one supercolumn with the superkey squares and roots. Additionally the first column is aligned to the right (the default was centered) and the precision of the square roots are set to be 6 (instead of 4 as default).
+
This is a simple example demonstrating the usage of this class. The first column includes the numbers , the second , the third , where the second and third columns are merged into one supercolumn with the superkey squares and roots. Additionally the first column is aligned to the right (the default was centered) and the precision of the square roots are set to be 6 (instead of 4 as default).
When generating output, TableHandler expects that all columns have the exact same number of elements in it so that the result is in fact a table. This assumes that in each of the iterations (time steps, nonlinear iterations, etc) you fill every single column. On the other hand, this may not always be what you want to do. For example, it could be that the function that computes the nonlinear residual is only called every few time steps; or, a function computing statistics of the mesh is only called whenever the mesh is in fact refined. In these cases, the add_value() function will be called less often for some columns and the column would therefore have fewer elements; furthermore, these elements would not be aligned with the rows that contain the other data elements that were produced during this iteration. An entirely different scenario is that the table is filled and at a later time we use the data in there to compute the elements of other rows; the ConvergenceTable class does something like this.
To support both scenarios, the TableHandler class has a property called auto-fill mode. By default, auto-fill mode is off, but it can be enabled by calling set_auto_fill_mode(). If auto-fill mode is enabled we use the following algorithm:
-
When calling add_value(key, value), we count the number of elements in the column corresponding to key. Let's call this number .
-
We also determine the maximal number of elements in the other columns; call it .
-
If then we add copies of the object T() to this column. Here, T is the data type of the given value. For example, if T is a numeric type, then T() is the number zero; if T is std::string, then T() is the empty string "".
+
When calling add_value(key, value), we count the number of elements in the column corresponding to key. Let's call this number .
+
We also determine the maximal number of elements in the other columns; call it .
+
If then we add copies of the object T() to this column. Here, T is the data type of the given value. For example, if T is a numeric type, then T() is the number zero; if T is std::string, then T() is the empty string "".
Add the given value to this column.
Padding the column with default elements makes sure that after the addition the column has as many entries as the longest other column. In other words, if we have skipped previous invocations of add_value() for a given key, then the padding will enter default values into this column.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classTensor.html differs (JavaScript source, ASCII text, with very long lines (1800))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classTensor.html 2023-11-25 15:25:58.883243920 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classTensor.html 2023-11-25 15:25:58.883243920 +0100
@@ -265,13 +265,13 @@
class Tensor< rank_, dim, Number >
A general tensor class with an arbitrary rank, i.e. with an arbitrary number of indices. The Tensor class provides an indexing operator and a bit of infrastructure, but most functionality is recursively handed down to tensors of rank 1 or put into external templated functions, e.g. the contract family.
The rank of a tensor specifies which types of physical quantities it can represent:
-A rank-0 tensor is a scalar that can store quantities such as temperature or pressure. These scalar quantities are shown in this documentation as simple lower-case Latin letters e.g. .
+A rank-0 tensor is a scalar that can store quantities such as temperature or pressure. These scalar quantities are shown in this documentation as simple lower-case Latin letters e.g. .
-A rank-1 tensor is a vector with dim components and it can represent vector quantities such as velocity, displacement, electric field, etc. They can also describe the gradient of a scalar field. The notation used for rank-1 tensors is bold-faced lower-case Latin letters e.g. . The components of a rank-1 tensor such as are represented as where is an index between 0 and dim-1.
+A rank-1 tensor is a vector with dim components and it can represent vector quantities such as velocity, displacement, electric field, etc. They can also describe the gradient of a scalar field. The notation used for rank-1 tensors is bold-faced lower-case Latin letters e.g. . The components of a rank-1 tensor such as are represented as where is an index between 0 and dim-1.
-A rank-2 tensor is a linear operator that can transform a vector into another vector. These tensors are similar to matrices with components. There is a related class SymmetricTensor<2,dim> for tensors of rank 2 whose elements are symmetric. Rank-2 tensors are usually denoted by bold-faced upper-case Latin letters such as or bold-faced Greek letters for example . The components of a rank 2 tensor such as are shown with two indices as . These tensors usually describe the gradients of vector fields (deformation gradient, velocity gradient, etc.) or Hessians of scalar fields. Additionally, mechanical stress tensors are rank-2 tensors that map the unit normal vectors of internal surfaces into local traction (force per unit area) vectors.
+A rank-2 tensor is a linear operator that can transform a vector into another vector. These tensors are similar to matrices with components. There is a related class SymmetricTensor<2,dim> for tensors of rank 2 whose elements are symmetric. Rank-2 tensors are usually denoted by bold-faced upper-case Latin letters such as or bold-faced Greek letters for example . The components of a rank 2 tensor such as are shown with two indices as . These tensors usually describe the gradients of vector fields (deformation gradient, velocity gradient, etc.) or Hessians of scalar fields. Additionally, mechanical stress tensors are rank-2 tensors that map the unit normal vectors of internal surfaces into local traction (force per unit area) vectors.
-Tensors with ranks higher than 2 are similarly defined in a consistent manner. They have components and the number of indices required to identify a component equals rank. For rank-4 tensors, a symmetric variant called SymmetricTensor<4,dim> exists.
+Tensors with ranks higher than 2 are similarly defined in a consistent manner. They have components and the number of indices required to identify a component equals rank. For rank-4 tensors, a symmetric variant called SymmetricTensor<4,dim> exists.
Using this tensor class for objects of rank 2 has advantages over matrices in many cases since the dimension is known to the compiler as well as the location of the data. It is therefore possible to produce far more efficient code than for matrices with runtime-dependent dimension. It also makes the code easier to read because of the semantic difference between a tensor (an object that relates to a coordinate system and has transformation properties with regard to coordinate rotations and transforms) and matrices (which we consider as operators on arbitrary vector spaces related to linear algebra things).
Template Parameters
@@ -1222,7 +1222,7 @@
-
Return an unrolled index in the range for the element of the tensor indexed by the argument to the function.
+
Return an unrolled index in the range for the element of the tensor indexed by the argument to the function.
@@ -1250,7 +1250,7 @@
-
Opposite of component_to_unrolled_index: For an index in the range , return which set of indices it would correspond to.
+
Opposite of component_to_unrolled_index: For an index in the range , return which set of indices it would correspond to.
@@ -2068,11 +2068,11 @@
Entrywise multiplication of two tensor objects of general rank.
The dot product (single contraction) for tensors. This function return a tensor of rank that is the contraction of the last index of a tensor src1 of rank rank_1 with the first index of a tensor src2 of rank rank_2:
- that is the contraction of the last index of a tensor src1 of rank rank_1 with the first index of a tensor src2 of rank rank_2:
+
+\]" src="form_827.png"/>
Note
For the Tensor class, the multiplication operator only performs a contraction over a single pair of indices. This is in contrast to the multiplication operator for SymmetricTensor, for which the corresponding operator*() performs a double contraction. The origin of the difference in how operator*() is implemented between Tensor and SymmetricTensor is that for the former, the product between two Tensor objects of same rank and dimension results in another Tensor object – that it, operator*() corresponds to the multiplicative group action within the group of tensors. On the other hand, there is no corresponding multiplicative group action with the set of symmetric tensors because, in general, the product of two symmetric tensors is a nonsymmetric tensor. As a consequence, for a mathematician, it is clear that operator*() for symmetric tensors must have a different meaning: namely the dot or scalar product that maps two symmetric tensors of rank 2 to a scalar. This corresponds to the double-dot (colon) operator whose meaning is then extended to the product of any two even-ranked symmetric tensors.
-In case the contraction yields a tensor of rank 0, that is, if rank_1==rank_2==1, then a scalar number is returned as an unwrapped number type. Return the norm of the given rank-2 tensor, where (maximum of the sums over columns).
+In case the contraction yields a tensor of rank 0, that is, if rank_1==rank_2==1, then a scalar number is returned as an unwrapped number type. Return the norm of the given rank-2 tensor, where (maximum of the sums over columns).
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classTensorProductManifold.html differs (JavaScript source, ASCII text, with very long lines (897))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classTensorProductManifold.html 2023-11-25 15:25:58.906576776 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classTensorProductManifold.html 2023-11-25 15:25:58.906576776 +0100
@@ -231,7 +231,7 @@
Detailed Description
template<int dim, int dim_A, int spacedim_A, int chartdim_A, int dim_B, int spacedim_B, int chartdim_B>
class TensorProductManifold< dim, dim_A, spacedim_A, chartdim_A, dim_B, spacedim_B, chartdim_B >
This manifold will combine the ChartManifolds A and B given in the constructor to form a new ChartManifold by building the tensor product . The first spacedim_A dimensions in the real space and the first chartdim_A dimensions of the chart will be given by manifold A, while the remaining coordinates are given by B. The manifold is to be used by a Triangulation<dim, space_dim_A+space_dim_B>.
+
This manifold will combine the ChartManifolds A and B given in the constructor to form a new ChartManifold by building the tensor product . The first spacedim_A dimensions in the real space and the first chartdim_A dimensions of the chart will be given by manifold A, while the remaining coordinates are given by B. The manifold is to be used by a Triangulation<dim, space_dim_A+space_dim_B>.
An example usage would be the combination of a SphericalManifold with space dimension 2 and a FlatManifold with space dimension 1 to form a cylindrical manifold.
pull_back(), push_forward(), and push_forward_gradient() are implemented by splitting the input argument into inputs for A and B according to the given dimensions and applying the corresponding operations before concatenating the result.
Note
The dimension arguments dim_A and dim_B are not used.
@@ -648,24 +648,24 @@
-
Return a vector that, at , is tangential to the geodesic that connects two points . See the documentation of the Manifold class and of Manifold::get_tangent_vector() for a more detailed description.
-
For the current class, we assume that this geodesic is the image under the push_forward() operation of a straight line of the pre-images of x1 and x2 (where pre-images are computed by pulling back the locations x1 and x2). In other words, if these preimages are , then the geodesic in preimage (the chartdim-dimensional Euclidean) space is
-, is tangential to the geodesic that connects two points . See the documentation of the Manifold class and of Manifold::get_tangent_vector() for a more detailed description.
+
For the current class, we assume that this geodesic is the image under the push_forward() operation of a straight line of the pre-images of x1 and x2 (where pre-images are computed by pulling back the locations x1 and x2). In other words, if these preimages are , then the geodesic in preimage (the chartdim-dimensional Euclidean) space is
+
+\end{align*}" src="form_1440.png"/>
In image space, i.e., in the space in which we operate, this leads to the curve
-
+\end{align*}" src="form_1441.png"/>
-
What the current function is supposed to return is . By the chain rule, this is equal to
-. By the chain rule, this is equal to
+
+\end{align*}" src="form_1442.png"/>
This formula may then have to be slightly modified by considering any periodicity that was assumed in the call to the constructor.
-
Thus, the computation of tangent vectors also requires the implementation of derivatives of the push-forward mapping. Here, is a chartdim-dimensional vector, and is a spacedim-times-chartdim-dimensional matrix. Consequently, and as desired, the operation results in a spacedim-dimensional vector.
+
Thus, the computation of tangent vectors also requires the implementation of derivatives of the push-forward mapping. Here, is a chartdim-dimensional vector, and is a spacedim-times-chartdim-dimensional matrix. Consequently, and as desired, the operation results in a spacedim-dimensional vector.
Parameters
x1
The first point that describes the geodesic, and the one at which the "direction" is to be evaluated.
in 3d. The typical application setting is a discretization of the Laplacian on a Cartesian (axis-aligned) geometry, where it can be exactly represented by the Kronecker or tensor product of a 1d mass matrix and a 1d Laplace matrix in each tensor direction (due to symmetry and are the same in each dimension). The dimension of the resulting class is the product of the one-dimensional matrices.
-
This class implements two basic operations, namely the usual multiplication by a vector and the inverse. For both operations, fast tensorial techniques can be applied that implement the operator evaluation in arithmetic operations, considerably less than for the naive forward transformation and for setting up the inverse of .
-
Interestingly, the exact inverse of the matrix can be found through tensor products due to 1964's work by Lynch et al. [Lynch1964],
+
in 3d. The typical application setting is a discretization of the Laplacian on a Cartesian (axis-aligned) geometry, where it can be exactly represented by the Kronecker or tensor product of a 1d mass matrix and a 1d Laplace matrix in each tensor direction (due to symmetry and are the same in each dimension). The dimension of the resulting class is the product of the one-dimensional matrices.
+
This class implements two basic operations, namely the usual multiplication by a vector and the inverse. For both operations, fast tensorial techniques can be applied that implement the operator evaluation in arithmetic operations, considerably less than for the naive forward transformation and for setting up the inverse of .
+
Interestingly, the exact inverse of the matrix can be found through tensor products due to 1964's work by Lynch et al. [Lynch1964],
-
where is the matrix of eigenvectors to the generalized eigenvalue problem in the given tensor direction :
+
where is the matrix of eigenvectors to the generalized eigenvalue problem in the given tensor direction :
-
and is the diagonal matrix representing the generalized eigenvalues . Note that the vectors are such that they simultaneously diagonalize and , i.e. is the diagonal matrix representing the generalized eigenvalues . Note that the vectors are such that they simultaneously diagonalize and , i.e. and . This method of matrix inversion is called fast diagonalization method.
This class requires LAPACK support.
Note
This class allows for two modes of usage. The first is a use case with run time constants for the matrix dimensions that is achieved by setting the optional template parameter n_rows_1d to -1. The second mode of usage that is faster allows to set the template parameter as a compile time constant, giving significantly faster code in particular for small sizes of the matrix.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classTensorProductPolynomialsBubbles.html differs (JavaScript source, ASCII text, with very long lines (820))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classTensorProductPolynomialsBubbles.html 2023-11-25 15:25:58.936576166 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classTensorProductPolynomialsBubbles.html 2023-11-25 15:25:58.936576166 +0100
@@ -156,9 +156,9 @@
Detailed Description
template<int dim>
-class TensorProductPolynomialsBubbles< dim >
A class that represents a space of tensor product polynomials, augmented by (non-normalized) bubble functions of form (non-normalized) bubble functions of form for . If degree is one, then the first factor disappears and one receives the usual bubble function centered at the mid-point of the cell.
+\left[\prod_{i=0}^{dim-1}(x_i(1-x_i))\right]$" src="form_877.png"/> for . If degree is one, then the first factor disappears and one receives the usual bubble function centered at the mid-point of the cell.
This class inherits most of its functionality from TensorProductPolynomials. The bubble enrichments are added for the last index.
Manifold description for the surface of a Torus in three dimensions. The Torus is assumed to be in the x-z plane. The reference coordinate system is given by the angle around the y axis, the angle around the centerline of the torus, and the distance to the centerline (between 0 and 1).
+class TorusManifold< dim >
Manifold description for the surface of a Torus in three dimensions. The Torus is assumed to be in the x-z plane. The reference coordinate system is given by the angle around the y axis, the angle around the centerline of the torus, and the distance to the centerline (between 0 and 1).
Given a point in the chartdim dimensional Euclidean space, this method returns the derivatives of the function that maps from the chartdim-dimensional to the spacedim-dimensional space. In other words, it is a matrix of size .
+
Given a point in the chartdim dimensional Euclidean space, this method returns the derivatives of the function that maps from the chartdim-dimensional to the spacedim-dimensional space. In other words, it is a matrix of size .
This function is used in the computations required by the get_tangent_vector() function. Since not all users of the Manifold class interface will require calling that function, the current function is implemented but will trigger an exception whenever called. This allows derived classes to avoid implementing the push_forward_gradient function if this functionality is not needed in the user program.
Refer to the general documentation of this class for more information.
@@ -709,24 +709,24 @@
-
Return a vector that, at , is tangential to the geodesic that connects two points . See the documentation of the Manifold class and of Manifold::get_tangent_vector() for a more detailed description.
-
For the current class, we assume that this geodesic is the image under the push_forward() operation of a straight line of the pre-images of x1 and x2 (where pre-images are computed by pulling back the locations x1 and x2). In other words, if these preimages are , then the geodesic in preimage (the chartdim-dimensional Euclidean) space is
-, is tangential to the geodesic that connects two points . See the documentation of the Manifold class and of Manifold::get_tangent_vector() for a more detailed description.
+
For the current class, we assume that this geodesic is the image under the push_forward() operation of a straight line of the pre-images of x1 and x2 (where pre-images are computed by pulling back the locations x1 and x2). In other words, if these preimages are , then the geodesic in preimage (the chartdim-dimensional Euclidean) space is
+
+\end{align*}" src="form_1440.png"/>
In image space, i.e., in the space in which we operate, this leads to the curve
-
+\end{align*}" src="form_1441.png"/>
-
What the current function is supposed to return is . By the chain rule, this is equal to
-. By the chain rule, this is equal to
+
+\end{align*}" src="form_1442.png"/>
This formula may then have to be slightly modified by considering any periodicity that was assumed in the call to the constructor.
-
Thus, the computation of tangent vectors also requires the implementation of derivatives of the push-forward mapping. Here, is a chartdim-dimensional vector, and is a spacedim-times-chartdim-dimensional matrix. Consequently, and as desired, the operation results in a spacedim-dimensional vector.
+
Thus, the computation of tangent vectors also requires the implementation of derivatives of the push-forward mapping. Here, is a chartdim-dimensional vector, and is a spacedim-times-chartdim-dimensional matrix. Consequently, and as desired, the operation results in a spacedim-dimensional vector.
Parameters
x1
The first point that describes the geodesic, and the one at which the "direction" is to be evaluated.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classTransfiniteInterpolationManifold.html differs (JavaScript source, ASCII text, with very long lines (1410))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classTransfiniteInterpolationManifold.html 2023-11-25 15:25:58.979908620 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classTransfiniteInterpolationManifold.html 2023-11-25 15:25:58.979908620 +0100
@@ -218,16 +218,16 @@
Detailed Description
template<int dim, int spacedim = dim>
class TransfiniteInterpolationManifold< dim, spacedim >
A mapping class that extends curved boundary descriptions into the interior of the computational domain. The outer curved boundary description is assumed to be given by another manifold (e.g. a polar manifold on a circle). The mechanism to extend the boundary information is a so-called transfinite interpolation. The use of this class is discussed extensively in step-65.
-
The formula for extending such a description in 2d is, for example, described on Wikipedia. Given a point on the chart, the image of this point in real space is given by
-Wikipedia. Given a point on the chart, the image of this point in real space is given by
+
+\end{align*}" src="form_1461.png"/>
-
where denote the four bounding vertices bounding the image space and are the four curves describing the lines of the cell. If a curved manifold is attached to any of these lines, the evaluation is done according to Manifold::get_new_point() with the two end points of the line and appropriate weight. In 3d, the generalization of this formula is implemented, creating a weighted sum of the vertices (positive contribution), the lines (negative), and the faces (positive contribution).
-
This manifold is usually attached to a coarse mesh and then places new points as a combination of the descriptions on the boundaries, weighted appropriately according to the position of the point in the original chart coordinates . This manifold should be preferred over setting only a curved manifold on the boundary of a mesh in most situations as it yields more uniform mesh distributions as the mesh is refined because it switches from a curved description to a straight description over all children of the initial coarse cell this manifold was attached to. This way, the curved nature of the manifold that is originally contained in one coarse mesh layer will be applied to more than one fine mesh layer once the mesh gets refined. Note that the mechanisms of TransfiniteInterpolationManifold are also built into the MappingQ class when only a surface of a cell is subject to a curved description, ensuring that even the default case without this manifold gets optimal convergence rates when applying curved boundary descriptions.
+
where denote the four bounding vertices bounding the image space and are the four curves describing the lines of the cell. If a curved manifold is attached to any of these lines, the evaluation is done according to Manifold::get_new_point() with the two end points of the line and appropriate weight. In 3d, the generalization of this formula is implemented, creating a weighted sum of the vertices (positive contribution), the lines (negative), and the faces (positive contribution).
+
This manifold is usually attached to a coarse mesh and then places new points as a combination of the descriptions on the boundaries, weighted appropriately according to the position of the point in the original chart coordinates . This manifold should be preferred over setting only a curved manifold on the boundary of a mesh in most situations as it yields more uniform mesh distributions as the mesh is refined because it switches from a curved description to a straight description over all children of the initial coarse cell this manifold was attached to. This way, the curved nature of the manifold that is originally contained in one coarse mesh layer will be applied to more than one fine mesh layer once the mesh gets refined. Note that the mechanisms of TransfiniteInterpolationManifold are also built into the MappingQ class when only a surface of a cell is subject to a curved description, ensuring that even the default case without this manifold gets optimal convergence rates when applying curved boundary descriptions.
If no curved boundaries surround a coarse cell, this class reduces to a flat manifold description.
To give an example of using this class, the following code attaches a transfinite manifold to a circle:
Return a vector that, at , is tangential to the geodesic that connects two points . The geodesic is the shortest line between these two points, where "shortest" is defined via a metric specific to a particular implementation of this class in a derived class. For example, in the case of a FlatManifold, the shortest line between two points is just the straight line, and in this case the tangent vector is just the difference . On the other hand, for a manifold that describes a surface embedded in a higher dimensional space (e.g., the surface of a sphere), then the tangent vector is tangential to the surface, and consequently may point in a different direction than the straight line that connects the two points.
-
While tangent vectors are often normalized to unit length, the vectors returned by this function are normalized as described in the introduction of this class. Specifically, if traces out the geodesic between the two points where and , then the returned vector must equal . In other words, the norm of the returned vector also encodes, in some sense, the length of the geodesic because a curve must move "faster" if the two points it connects between arguments and are farther apart.
-
The default implementation of this function approximates for a small value of , and the evaluation of is done by calling get_new_point(). If possible, derived classes should override this function by an implementation of the exact derivative.
+
Return a vector that, at , is tangential to the geodesic that connects two points . The geodesic is the shortest line between these two points, where "shortest" is defined via a metric specific to a particular implementation of this class in a derived class. For example, in the case of a FlatManifold, the shortest line between two points is just the straight line, and in this case the tangent vector is just the difference . On the other hand, for a manifold that describes a surface embedded in a higher dimensional space (e.g., the surface of a sphere), then the tangent vector is tangential to the surface, and consequently may point in a different direction than the straight line that connects the two points.
+
While tangent vectors are often normalized to unit length, the vectors returned by this function are normalized as described in the introduction of this class. Specifically, if traces out the geodesic between the two points where and , then the returned vector must equal . In other words, the norm of the returned vector also encodes, in some sense, the length of the geodesic because a curve must move "faster" if the two points it connects between arguments and are farther apart.
+
The default implementation of this function approximates for a small value of , and the evaluation of is done by calling get_new_point(). If possible, derived classes should override this function by an implementation of the exact derivative.
Parameters
x1
The first point that describes the geodesic, and the one at which the "direction" is to be evaluated.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classTriaAccessor.html differs (JavaScript source, ASCII text, with very long lines (873))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classTriaAccessor.html 2023-11-25 15:25:59.009908009 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classTriaAccessor.html 2023-11-25 15:25:59.013241272 +0100
@@ -325,7 +325,7 @@
Detailed Description
template<int structdim, int dim, int spacedim>
-class TriaAccessor< structdim, dim, spacedim >
A class that provides access to objects in a triangulation such as its vertices, sub-objects, children, geometric information, etc. This class represents objects of dimension structdim (i.e. 1 for lines, 2 for quads, 3 for hexes) in a triangulation of dimensionality dim (i.e. 1 for a triangulation of lines, 2 for a triangulation of quads, and 3 for a triangulation of hexes) that is embedded in a space of dimensionality spacedim (for spacedim==dim the triangulation represents a domain in , for spacedim>dim the triangulation is of a manifold embedded in a higher dimensional space).
+class TriaAccessor< structdim, dim, spacedim >
A class that provides access to objects in a triangulation such as its vertices, sub-objects, children, geometric information, etc. This class represents objects of dimension structdim (i.e. 1 for lines, 2 for quads, 3 for hexes) in a triangulation of dimensionality dim (i.e. 1 for a triangulation of lines, 2 for a triangulation of quads, and 3 for a triangulation of hexes) that is embedded in a space of dimensionality spacedim (for spacedim==dim the triangulation represents a domain in , for spacedim>dim the triangulation is of a manifold embedded in a higher dimensional space).
There is a specialization of this class for the case where structdim equals zero, i.e., for vertices of a triangulation.
This function computes a fast approximate transformation from the real to the unit cell by inversion of an affine approximation of the -linear function from the reference -dimensional cell.
-
The affine approximation of the unit to real cell mapping is found by a least squares fit of an affine function to the vertices of the present object. For any valid mesh cell whose geometry is not degenerate, this operation results in a unique affine mapping. Thus, this function will return a finite result for all given input points, even in cases where the actual transformation by an actual bi-/trilinear or higher order mapping might be singular. Besides only approximating the mapping from the vertex points, this function also ignores the attached manifold descriptions. The result is only exact in case the transformation from the unit to the real cell is indeed affine, such as in one dimension or for Cartesian and affine (parallelogram) meshes in 2d/3d.
+
This function computes a fast approximate transformation from the real to the unit cell by inversion of an affine approximation of the -linear function from the reference -dimensional cell.
+
The affine approximation of the unit to real cell mapping is found by a least squares fit of an affine function to the vertices of the present object. For any valid mesh cell whose geometry is not degenerate, this operation results in a unique affine mapping. Thus, this function will return a finite result for all given input points, even in cases where the actual transformation by an actual bi-/trilinear or higher order mapping might be singular. Besides only approximating the mapping from the vertex points, this function also ignores the attached manifold descriptions. The result is only exact in case the transformation from the unit to the real cell is indeed affine, such as in one dimension or for Cartesian and affine (parallelogram) meshes in 2d/3d.
If dim<spacedim we first project p onto the plane.
@@ -1749,7 +1749,7 @@
-
Center of the object. The center of an object is defined to be the average of the locations of the vertices, which is also where a mapping would map the center of the reference cell. However, you can also ask this function to instead return the average of the vertices as computed by the underlying Manifold object associated with the current object, by setting to true the optional parameter respect_manifold. Manifolds would then typically pull back the coordinates of the vertices to a reference domain (not necessarily the reference cell), compute the average there, and then push forward the coordinates of the averaged point to the physical space again; the resulting point is guaranteed to lie within the manifold, even if the manifold is curved.
+
Center of the object. The center of an object is defined to be the average of the locations of the vertices, which is also where a mapping would map the center of the reference cell. However, you can also ask this function to instead return the average of the vertices as computed by the underlying Manifold object associated with the current object, by setting to true the optional parameter respect_manifold. Manifolds would then typically pull back the coordinates of the vertices to a reference domain (not necessarily the reference cell), compute the average there, and then push forward the coordinates of the averaged point to the physical space again; the resulting point is guaranteed to lie within the manifold, even if the manifold is curved.
When the object uses a different manifold description as its surrounding, like when part of the bounding objects of this TriaAccessor use a non-flat manifold description but the object itself is flat, the result given by the TriaAccessor::center() function may not be accurate enough, even when parameter respect_manifold is set to true. If you find this to be case, than you can further refine the computation of the center by setting to true the second additional parameter interpolate_from_surrounding. This computes the location of the center by a so-called transfinite interpolation from the center of all the bounding objects. For a 2d object, it puts a weight of 1/2 on each of the four surrounding lines and a weight -1/4 on the four vertices. This corresponds to a linear interpolation between the descriptions of the four faces, subtracting the contribution of the vertices that is added twice when coming through both lines adjacent to the vertex. In 3d, the weights for faces are 1/2, the weights for lines are -1/4, and the weights for vertices are 1/8. For further information, also confer to the TransfiniteInterpolationManifold class that is able to not only apply this beneficial description to a single cell but all children of a coarse cell.
Return the barycenter (also called centroid) of the object. The barycenter for an object of dimension in space dimensions is given by the -dimensional vector defined by
+
Return the barycenter (also called centroid) of the object. The barycenter for an object of dimension in space dimensions is given by the -dimensional vector defined by
This function assumes that is mapped by a -linear function from the reference -dimensional cell. Then the integrals above can be pulled back to the reference cell and evaluated exactly (if through lengthy and, compared to the center() function, expensive computations).
+
This function assumes that is mapped by a -linear function from the reference -dimensional cell. Then the integrals above can be pulled back to the reference cell and evaluated exactly (if through lengthy and, compared to the center() function, expensive computations).
This class is a specialization of TriaAccessor<structdim, dim, spacedim> for the case that structdim is zero and dim is one. This class represents vertices in a one-dimensional triangulation that is embedded in a space of dimensionality spacedim (for spacedim==dim==1 the triangulation represents a domain in , for spacedim>dim==1 the triangulation is of a manifold embedded in a higher dimensional space).
+class TriaAccessor< 0, 1, spacedim >
This class is a specialization of TriaAccessor<structdim, dim, spacedim> for the case that structdim is zero and dim is one. This class represents vertices in a one-dimensional triangulation that is embedded in a space of dimensionality spacedim (for spacedim==dim==1 the triangulation represents a domain in , for spacedim>dim==1 the triangulation is of a manifold embedded in a higher dimensional space).
The current specialization of the TriaAccessor<0,dim,spacedim> class for vertices of a one-dimensional triangulation exists since in the dim == 1 case vertices are also faces.
static unsigned int&#href_anchor"memItemRight" valign="bottom">quad_index (const unsigned int i)
&#href_anchor"details" id="details">
Detailed Description
template<int dim, int spacedim>
-class TriaAccessor< 0, dim, spacedim >
This class is a specialization of TriaAccessor<structdim, dim, spacedim> for the case that structdim is zero. This class represents vertices in a triangulation of dimensionality dim (i.e. 1 for a triangulation of lines, 2 for a triangulation of quads, and 3 for a triangulation of hexes) that is embedded in a space of dimensionality spacedim (for spacedim==dim the triangulation represents a domain in , for spacedim>dim the triangulation is of a manifold embedded in a higher dimensional space).
+class TriaAccessor< 0, dim, spacedim >
This class is a specialization of TriaAccessor<structdim, dim, spacedim> for the case that structdim is zero. This class represents vertices in a triangulation of dimensionality dim (i.e. 1 for a triangulation of lines, 2 for a triangulation of quads, and 3 for a triangulation of hexes) that is embedded in a space of dimensionality spacedim (for spacedim==dim the triangulation represents a domain in , for spacedim>dim the triangulation is of a manifold embedded in a higher dimensional space).
There is a further specialization of this class for the case that dim equals one, i.e., for vertices of a one-dimensional triangulation, since in that case vertices are also faces.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classTriangulation.html differs (JavaScript source, ASCII text, with very long lines (729))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classTriangulation.html 2023-11-25 15:25:59.109905972 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classTriangulation.html 2023-11-25 15:25:59.126572301 +0100
@@ -1951,7 +1951,7 @@
-
Refine all cells times times. In other words, in each one of the times iterations, loop over all cells and refine each cell uniformly into children. In practice, this function repeats the following operations times times: call set_all_refine_flags() followed by execute_coarsening_and_refinement(). The end result is that the number of cells increases by a factor of .
+
Refine all cells times times. In other words, in each one of the times iterations, loop over all cells and refine each cell uniformly into children. In practice, this function repeats the following operations times times: call set_all_refine_flags() followed by execute_coarsening_and_refinement(). The end result is that the number of cells increases by a factor of .
The execute_coarsening_and_refinement() function called in this loop may throw an exception if it creates cells that are distorted (see its documentation for an explanation). This exception will be propagated through this function if that happens, and you may not get the actual number of refinement steps in that case.
Note
This function triggers the pre- and post-refinement signals before and after doing each individual refinement cycle (i.e. more than once if times > 1) . See the section on signals in the general documentation of this class.
@@ -4715,7 +4715,7 @@
-
Iterator to the first quad, used or not, on the given level. If a level has no quads, a past-the-end iterator is returned. If quads are no cells, i.e. for no level argument must be given.
+
Iterator to the first quad, used or not, on the given level. If a level has no quads, a past-the-end iterator is returned. If quads are no cells, i.e. for no level argument must be given.
Note
The given level argument needs to correspond to a level of the triangulation, i.e., should be less than the value returned by n_levels(). On the other hand, for parallel computations using a parallel::distributed::Triangulation object, it is often convenient to write loops over the cells of all levels of the global mesh, even if the local portion of the triangulation does not actually have cells at one of the higher levels. In those cases, the level argument is accepted if it is less than what the n_global_levels() function returns. If the given level is between the values returned by n_levels() and n_global_levels(), then no cells exist in the local portion of the triangulation at this level, and the function simply returns what end() would return.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classTrilinosWrappers_1_1BlockSparseMatrix.html differs (JavaScript source, ASCII text, with very long lines (842))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classTrilinosWrappers_1_1BlockSparseMatrix.html 2023-11-25 15:25:59.153238426 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classTrilinosWrappers_1_1BlockSparseMatrix.html 2023-11-25 15:25:59.153238426 +0100
@@ -1042,7 +1042,7 @@
-
Matrix-vector multiplication: let with being this matrix. The vector types can be block vectors or non-block vectors (only if the matrix has only one row or column, respectively), and need to define TrilinosWrappers::SparseMatrix::vmult.
+
Matrix-vector multiplication: let with being this matrix. The vector types can be block vectors or non-block vectors (only if the matrix has only one row or column, respectively), and need to define TrilinosWrappers::SparseMatrix::vmult.
Adding Matrix-vector multiplication. Add on with being this matrix.
+
Adding Matrix-vector multiplication. Add on with being this matrix.
@@ -2309,7 +2309,7 @@
-
Compute the matrix scalar product .
+
Compute the matrix scalar product .
@@ -2740,7 +2740,7 @@
-
Matrix-vector multiplication: let with being this matrix.
+
Matrix-vector multiplication: let with being this matrix.
Due to problems with deriving template arguments between the block and non-block versions of the vmult/Tvmult functions, the actual functions are implemented in derived classes, with implementations forwarding the calls to the implementations provided here under a unique name for which template arguments can be derived by the compiler.
@@ -2888,7 +2888,7 @@
-
Matrix-vector multiplication: let with being this matrix. This function does the same as vmult() but takes the transposed matrix.
+
Matrix-vector multiplication: let with being this matrix. This function does the same as vmult() but takes the transposed matrix.
Due to problems with deriving template arguments between the block and non-block versions of the vmult/Tvmult functions, the actual functions are implemented in derived classes, with implementations forwarding the calls to the implementations provided here under a unique name for which template arguments can be derived by the compiler.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classTrilinosWrappers_1_1MPI_1_1BlockVector.html differs (JavaScript source, ASCII text, with very long lines (1002))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classTrilinosWrappers_1_1MPI_1_1BlockVector.html 2023-11-25 15:25:59.179904547 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classTrilinosWrappers_1_1MPI_1_1BlockVector.html 2023-11-25 15:25:59.183237815 +0100
@@ -1781,7 +1781,7 @@
-
Return the square of the -norm.
+
Return the square of the -norm.
@@ -1833,7 +1833,7 @@
-
Return the -norm of the vector, i.e. the sum of the absolute values.
+
Return the -norm of the vector, i.e. the sum of the absolute values.
@@ -1859,7 +1859,7 @@
-
Return the -norm of the vector, i.e. the square root of the sum of the squares of the elements.
+
Return the -norm of the vector, i.e. the square root of the sum of the squares of the elements.
@@ -1885,7 +1885,7 @@
-
Return the maximum absolute value of the elements of this vector, which is the -norm of a vector.
+
Return the maximum absolute value of the elements of this vector, which is the -norm of a vector.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classTrilinosWrappers_1_1MPI_1_1Vector.html differs (JavaScript source, ASCII text, with very long lines (809))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classTrilinosWrappers_1_1MPI_1_1Vector.html 2023-11-25 15:25:59.209903939 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classTrilinosWrappers_1_1MPI_1_1Vector.html 2023-11-25 15:25:59.209903939 +0100
@@ -1301,8 +1301,8 @@
-
Return a pair of indices indicating which elements of this vector are stored locally. The first number is the index of the first element stored, the second the index of the one past the last one that is stored locally. If this is a sequential vector, then the result will be the pair (0,N), otherwise it will be a pair (i,i+n), where n=local_size() and i is the first element of the vector stored on this processor, corresponding to the half open interval
-
Note
The description above is true most of the time, but not always. In particular, Trilinos vectors need not store contiguous ranges of elements such as . Rather, it can store vectors where the elements are distributed in an arbitrary way across all processors and each processor simply stores a particular subset, not necessarily contiguous. In this case, this function clearly makes no sense since it could, at best, return a range that includes all elements that are stored locally. Thus, the function only succeeds if the locally stored range is indeed contiguous. It will trigger an assertion if the local portion of the vector is not contiguous.
+
Return a pair of indices indicating which elements of this vector are stored locally. The first number is the index of the first element stored, the second the index of the one past the last one that is stored locally. If this is a sequential vector, then the result will be the pair (0,N), otherwise it will be a pair (i,i+n), where n=local_size() and i is the first element of the vector stored on this processor, corresponding to the half open interval
+
Note
The description above is true most of the time, but not always. In particular, Trilinos vectors need not store contiguous ranges of elements such as . Rather, it can store vectors where the elements are distributed in an arbitrary way across all processors and each processor simply stores a particular subset, not necessarily contiguous. In this case, this function clearly makes no sense since it could, at best, return a range that includes all elements that are stored locally. Thus, the function only succeeds if the locally stored range is indeed contiguous. It will trigger an assertion if the local portion of the vector is not contiguous.
@@ -1414,7 +1414,7 @@
-
Return the square of the -norm.
+
Return the square of the -norm.
@@ -1486,7 +1486,7 @@
-
-norm of the vector. The sum of the absolute values.
+
-norm of the vector. The sum of the absolute values.
@@ -1504,7 +1504,7 @@
-
-norm of the vector. The square root of the sum of the squares of the elements.
+
-norm of the vector. The square root of the sum of the squares of the elements.
@@ -1523,7 +1523,7 @@
-
-norm of the vector. The pth root of the sum of the pth powers of the absolute values of the elements.
+
-norm of the vector. The pth root of the sum of the pth powers of the absolute values of the elements.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classTrilinosWrappers_1_1NOXSolver.html differs (JavaScript source, ASCII text, with very long lines (761))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classTrilinosWrappers_1_1NOXSolver.html 2023-11-25 15:25:59.223237001 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classTrilinosWrappers_1_1NOXSolver.html 2023-11-25 15:25:59.223237001 +0100
@@ -376,7 +376,7 @@
-
A user function that applies the Jacobian to x and writes the result in y. The Jacobian to be used (i.e., more precisely: the linearization point above) is the one computed when the setup_jacobian function was last called.
+
A user function that applies the Jacobian to x and writes the result in y. The Jacobian to be used (i.e., more precisely: the linearization point above) is the one computed when the setup_jacobian function was last called.
Note
This function is optional and is used in the case of certain configurations. For instance, this function is required if the polynomial line search (NOX::LineSearch::Polynomial) is chosen, whereas for the full step case (NOX::LineSearch::FullStep) it won't be called.
This variable represents a user provided callback. See there for a description of how to deal with errors and other requirements and conventions. NOX can not deal with "recoverable" errors, so if a callback throws an exception of type RecoverableUserCallbackError, then this exception is treated like any other exception.
@@ -398,7 +398,7 @@
-
A user function that applies the inverse of the Jacobian to y and writes the result in x. The parameter tolerance specifies the error reduction if an iterative solver is used in applying the inverse matrix. The Jacobian to be used (i.e., more precisely: the linearization point above) is the one computed when the setup_jacobian function was last called.
+
A user function that applies the inverse of the Jacobian to y and writes the result in x. The parameter tolerance specifies the error reduction if an iterative solver is used in applying the inverse matrix. The Jacobian to be used (i.e., more precisely: the linearization point above) is the one computed when the setup_jacobian function was last called.
Note
This function is optional and is used in the case of certain configurations.
This variable represents a user provided callback. See there for a description of how to deal with errors and other requirements and conventions. NOX can not deal with "recoverable" errors, so if a callback throws an exception of type RecoverableUserCallbackError, then this exception is treated like any other exception.
@@ -420,7 +420,7 @@
-
A user function that applies the inverse of the Jacobian to y, writes the result in x and returns the number of linear iterations the linear solver needed. The parameter tolerance species the error reduction if an iterative solver is used. The Jacobian to be used (i.e., more precisely: the linearization point above) is the one computed when the setup_jacobian function was last called.
+
A user function that applies the inverse of the Jacobian to y, writes the result in x and returns the number of linear iterations the linear solver needed. The parameter tolerance species the error reduction if an iterative solver is used. The Jacobian to be used (i.e., more precisely: the linearization point above) is the one computed when the setup_jacobian function was last called.
Note
This function is used if solve_with_jacobian is not provided. Its return value is compared again AdditionalFlags::threshold_n_linear_iterations; if it is larger, the preconditioner will be built before the next linear system is solved. The use of this approach is predicated on the idea that one can keep using a preconditioner built earlier as long as it is a good preconditioner for the matrix currently in use – where "good" is defined as leading to a number of iterations to solve linear systems less than the threshold given by the current variable.
This variable represents a user provided callback. See there for a description of how to deal with errors and other requirements and conventions. NOX can not deal with "recoverable" errors, so if a callback throws an exception of type RecoverableUserCallbackError, then this exception is treated like any other exception.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classTrilinosWrappers_1_1SparseMatrix.html differs (JavaScript source, ASCII text, with very long lines (903))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classTrilinosWrappers_1_1SparseMatrix.html 2023-11-25 15:25:59.256569654 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classTrilinosWrappers_1_1SparseMatrix.html 2023-11-25 15:25:59.256569654 +0100
@@ -2401,7 +2401,7 @@
-
Return the square of the norm of the vector with respect to the norm induced by this matrix, i.e., . This is useful, e.g. in the finite element context, where the norm of a function equals the matrix norm with respect to the mass matrix of the vector representing the nodal values of the finite element function.
+
Return the square of the norm of the vector with respect to the norm induced by this matrix, i.e., . This is useful, e.g. in the finite element context, where the norm of a function equals the matrix norm with respect to the mass matrix of the vector representing the nodal values of the finite element function.
Obviously, the matrix needs to be quadratic for this operation.
The implementation of this function is not as efficient as the one in the SparseMatrix class used in deal.II (i.e. the original one, not the Trilinos wrapper class) since Trilinos doesn't support this operation and needs a temporary vector.
The vector has to be initialized with the same IndexSet the matrix was initialized with.
@@ -2434,7 +2434,7 @@
-
Compute the matrix scalar product .
+
Compute the matrix scalar product .
The implementation of this function is not as efficient as the one in the SparseMatrix class used in deal.II (i.e. the original one, not the Trilinos wrapper class) since Trilinos doesn't support this operation and needs a temporary vector.
The vector u has to be initialized with the same IndexSet that was used for the row indices of the matrix and the vector v has to be initialized with the same IndexSet that was used for the column indices of the matrix.
In case of a localized Vector, this function will only work when running on one processor, since the matrix object is inherently distributed. Otherwise, an exception will be thrown.
@@ -2551,10 +2551,10 @@
-
Return the l1-norm of the matrix, that is , (max. sum of columns). This is the natural matrix norm that is compatible to the l1-norm for vectors, i.e. . (cf. Haemmerlin-Hoffmann: Numerische Mathematik)
+|M_{ij}|$" src="form_1959.png"/>, (max. sum of columns). This is the natural matrix norm that is compatible to the l1-norm for vectors, i.e. . (cf. Haemmerlin-Hoffmann: Numerische Mathematik)
Return the linfty-norm of the matrix, that is , (max. sum of rows). This is the natural matrix norm that is compatible to the linfty-norm of vectors, i.e. , (max. sum of rows). This is the natural matrix norm that is compatible to the linfty-norm of vectors, i.e. . (cf. Haemmerlin-Hoffmann: Numerische Mathematik)
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classTrilinosWrappers_1_1SparsityPattern.html differs (JavaScript source, ASCII text, with very long lines (752))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classTrilinosWrappers_1_1SparsityPattern.html 2023-11-25 15:25:59.279902515 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classTrilinosWrappers_1_1SparsityPattern.html 2023-11-25 15:25:59.279902515 +0100
@@ -461,7 +461,7 @@
-
Generate a sparsity pattern that is completely stored locally, having rows and columns. The resulting matrix will be completely stored locally, too.
+
Generate a sparsity pattern that is completely stored locally, having rows and columns. The resulting matrix will be completely stored locally, too.
It is possible to specify the number of columns entries per row using the optional n_entries_per_row argument. However, this value does not need to be accurate or even given at all, since one does usually not have this kind of information before building the sparsity pattern (the usual case when the function DoFTools::make_sparsity_pattern() is called). The entries are allocated dynamically in a similar manner as for the deal.II DynamicSparsityPattern classes. However, a good estimate will reduce the setup time of the sparsity pattern.
Initialize a sparsity pattern that is completely stored locally, having rows and columns. The resulting matrix will be completely stored locally.
+
Initialize a sparsity pattern that is completely stored locally, having rows and columns. The resulting matrix will be completely stored locally.
The number of columns entries per row is specified as the maximum number of entries argument. This does not need to be an accurate number since the entries are allocated dynamically in a similar manner as for the deal.II DynamicSparsityPattern classes, but a good estimate will reduce the setup time of the sparsity pattern.
Compute the bandwidth of the matrix represented by this structure. The bandwidth is the maximum of for which the index pair represents a nonzero entry of the matrix. Consequently, the maximum bandwidth a matrix can have is .
+
Compute the bandwidth of the matrix represented by this structure. The bandwidth is the maximum of for which the index pair represents a nonzero entry of the matrix. Consequently, the maximum bandwidth a matrix can have is .
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classUtilities_1_1MPI_1_1Partitioner.html differs (JavaScript source, ASCII text, with very long lines (1765))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classUtilities_1_1MPI_1_1Partitioner.html 2023-11-25 15:25:59.299902107 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classUtilities_1_1MPI_1_1Partitioner.html 2023-11-25 15:25:59.299902107 +0100
@@ -321,7 +321,7 @@
Constructor that takes the number of locally-owned degrees of freedom local_size and the number of ghost degrees of freedom ghost_size.
-
The local index range is translated to global indices in an ascending and one-to-one fashion, i.e., the indices of process sit exactly between the indices of the processes and , respectively.
+
The local index range is translated to global indices in an ascending and one-to-one fashion, i.e., the indices of process sit exactly between the indices of the processes and , respectively.
Note
Setting the ghost_size variable to an appropriate value provides memory space for the ghost data in a vector's memory allocation as and allows access to it via local_element(). However, the associated global indices must be handled externally in this case.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classUtilities_1_1MPI_1_1ProcessGrid.html differs (JavaScript source, ASCII text, with very long lines (1611))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classUtilities_1_1MPI_1_1ProcessGrid.html 2023-11-25 15:25:59.316568435 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classUtilities_1_1MPI_1_1ProcessGrid.html 2023-11-25 15:25:59.316568435 +0100
@@ -239,8 +239,8 @@
Constructor for a process grid for a given mpi_communicator. In this case the process grid is heuristically chosen based on the dimensions and block-cyclic distribution of a target matrix provided in n_rows_matrix, n_columns_matrix, row_block_size and column_block_size.
-
The maximum number of MPI cores one can utilize is , where are the matrix dimension and are the block sizes and is the number of processes in the mpi_communicator. This function then creates a 2d processor grid assuming the ratio between number of process row and columns to be equal the ratio between matrix dimensions and .
-
For example, a square matrix with the block size and the mpi_communicator with 11 cores will result in the process grid.
+
The maximum number of MPI cores one can utilize is , where are the matrix dimension and are the block sizes and is the number of processes in the mpi_communicator. This function then creates a 2d processor grid assuming the ratio between number of process row and columns to be equal the ratio between matrix dimensions and .
+
For example, a square matrix with the block size and the mpi_communicator with 11 cores will result in the process grid.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classVector.html differs (JavaScript source, ASCII text, with very long lines (532))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classVector.html 2023-11-25 15:25:59.339901293 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classVector.html 2023-11-25 15:25:59.339901293 +0100
@@ -947,7 +947,7 @@
Same as above, but will preserve the values of vector upon resizing. If we new size is bigger, we will have
-
+\]" src="form_1987.png"/>
whereas if the desired size is smaller, then
-
+\]" src="form_1988.png"/>
@@ -1309,7 +1309,7 @@
-
Return the square of the -norm.
+
Return the square of the -norm.
Note
If deal.II is configured with threads, this operation will run multi-threaded by splitting the work into smaller chunks (assuming there is enough work to make this worthwhile). The algorithm uses pairwise summation with the same order of summation in every run, which gives fully repeatable results from one run to another.
@@ -1351,7 +1351,7 @@
-
-norm of the vector. The sum of the absolute values.
+
-norm of the vector. The sum of the absolute values.
Note
If deal.II is configured with threads, this operation will run multi-threaded by splitting the work into smaller chunks (assuming there is enough work to make this worthwhile). The algorithm uses pairwise summation with the same order of summation in every run, which gives fully repeatable results from one run to another.
@@ -1372,7 +1372,7 @@
-
-norm of the vector. The square root of the sum of the squares of the elements.
+
-norm of the vector. The square root of the sum of the squares of the elements.
Note
If deal.II is configured with threads, this operation will run multi-threaded by splitting the work into smaller chunks (assuming there is enough work to make this worthwhile). The algorithm uses pairwise summation with the same order of summation in every run, which gives fully repeatable results from one run to another.
@@ -1394,7 +1394,7 @@
-
-norm of the vector. The pth root of the sum of the pth powers of the absolute values of the elements.
+
-norm of the vector. The pth root of the sum of the pth powers of the absolute values of the elements.
Note
If deal.II is configured with threads, this operation will run multi-threaded by splitting the work into smaller chunks (assuming there is enough work to make this worthwhile). The algorithm uses pairwise summation with the same order of summation in every run, which gives fully repeatable results from one run to another.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classhp_1_1FECollection.html differs (JavaScript source, ASCII text, with very long lines (1153))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classhp_1_1FECollection.html 2023-11-25 15:25:59.366567418 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classhp_1_1FECollection.html 2023-11-25 15:25:59.366567418 +0100
@@ -1348,7 +1348,7 @@
Return a block mask with as many elements as this object has blocks and of which exactly the one component is true that corresponds to the given argument. See the glossary for more information.
-
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
This function is the equivalent of FiniteElement::component_mask() with the same arguments. It verifies that it gets the same result from every one of the elements that are stored in this FECollection. If this is not the case, it throws an exception.
Parameters
@@ -1444,7 +1444,7 @@
Given a component mask (see this glossary entry ), produce a block mask (see this glossary entry ) that represents the blocks that correspond to the components selected in the input argument. This is essentially a conversion operator from ComponentMask to BlockMask.
-
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
+
Note
This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
This function is the equivalent of FiniteElement::component_mask() with the same arguments. It verifies that it gets the same result from every one of the elements that are stored in this FECollection. If this is not the case, it throws an exception.
Parameters
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classhp_1_1FEFaceValues.html differs (JavaScript source, ASCII text, with very long lines (1358))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classhp_1_1FEFaceValues.html 2023-11-25 15:25:59.386567011 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classhp_1_1FEFaceValues.html 2023-11-25 15:25:59.386567011 +0100
@@ -388,7 +388,7 @@
-
Constructor. This constructor is equivalent to the other one except that it makes the object use a mapping (i.e., an object of type MappingQ(1)) implicitly.
+
Constructor. This constructor is equivalent to the other one except that it makes the object use a mapping (i.e., an object of type MappingQ(1)) implicitly.
After the call, you can get an FEFaceValues object using the get_present_fe_values() function that corresponds to the present cell. For this FEFaceValues object, we use the additional arguments described below to determine which finite element, mapping, and quadrature formula to use. They are order in such a way that the arguments one may want to change most frequently come first. The rules for these arguments are as follows:
If the fe_index argument to this function is left at its default value, then we use that finite element within the hp::FECollection passed to the constructor of this class with index given by cell->active_fe_index(). Consequently, the hp::FECollection argument given to this object should really be the same as that used in the construction of the DoFHandler associated with the present cell. On the other hand, if a value is given for this argument, it overrides the choice of cell->active_fe_index(). (This may or may not be very useful: If you are using a specific finite element on the current cell, why would you want to reinit() an object of the current type with a different finite element?)
If the q_index argument is left at its default value, then we use that quadrature formula within the hp::QCollection passed to the constructor of this class with index given by cell->active_fe_index(), i.e. the same index as that of the finite element. In this case, there should be a corresponding quadrature formula for each finite element in the hp::FECollection. As a special case, if the quadrature collection contains only a single element (a frequent case if one wants to use the same quadrature object for all finite elements in an hp-discretization, even if that may not be the most efficient), then this single quadrature is used unless a different value for this argument is specified. On the other hand, if a value is given for this argument, it overrides the choice of cell->active_fe_index() or the choice for the single quadrature.
-
If the mapping_index argument is left at its default value, then we use that mapping object within the hp::MappingCollection passed to the constructor of this class with index given by cell->active_fe_index(), i.e. the same index as that of the finite element. As above, if the mapping collection contains only a single element (a frequent case if one wants to use a mapping for all finite elements in an hp-discretization), then this single mapping is used unless a different value for this argument is specified.
+
If the mapping_index argument is left at its default value, then we use that mapping object within the hp::MappingCollection passed to the constructor of this class with index given by cell->active_fe_index(), i.e. the same index as that of the finite element. As above, if the mapping collection contains only a single element (a frequent case if one wants to use a mapping for all finite elements in an hp-discretization), then this single mapping is used unless a different value for this argument is specified.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classhp_1_1FESubfaceValues.html differs (JavaScript source, ASCII text, with very long lines (1043))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classhp_1_1FESubfaceValues.html 2023-11-25 15:25:59.396566807 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classhp_1_1FESubfaceValues.html 2023-11-25 15:25:59.396566807 +0100
@@ -195,7 +195,7 @@
-
Constructor. This constructor is equivalent to the other one except that it makes the object use a mapping (i.e., an object of type MappingQ(1)) implicitly.
+
Constructor. This constructor is equivalent to the other one except that it makes the object use a mapping (i.e., an object of type MappingQ(1)) implicitly.
Reinitialize the object for the given cell, face, and subface.
After the call, you can get an FESubfaceValues object using the get_present_fe_values() function that corresponds to the present cell. For this FESubfaceValues object, we use the additional arguments described below to determine which finite element, mapping, and quadrature formula to use. They are order in such a way that the arguments one may want to change most frequently come first. The rules for these arguments are as follows:
If the q_index argument is left at its default value, then we use that quadrature formula within the hp::QCollection passed to the constructor of this class with index given by cell->active_fe_index(), i.e. the same index as that of the finite element. In this case, there should be a corresponding quadrature formula for each finite element in the hp::FECollection. As a special case, if the quadrature collection contains only a single element (a frequent case if one wants to use the same quadrature object for all finite elements in an hp-discretization, even if that may not be the most efficient), then this single quadrature is used unless a different value for this argument is specified. On the other hand, if a value is given for this argument, it overrides the choice of cell->active_fe_index() or the choice for the single quadrature.
-
If the mapping_index argument is left at its default value, then we use that mapping object within the hp::MappingCollection passed to the constructor of this class with index given by cell->active_fe_index(), i.e. the same index as that of the finite element. As above, if the mapping collection contains only a single element (a frequent case if one wants to use a mapping for all finite elements in an hp-discretization), then this single mapping is used unless a different value for this argument is specified.
+
If the mapping_index argument is left at its default value, then we use that mapping object within the hp::MappingCollection passed to the constructor of this class with index given by cell->active_fe_index(), i.e. the same index as that of the finite element. As above, if the mapping collection contains only a single element (a frequent case if one wants to use a mapping for all finite elements in an hp-discretization), then this single mapping is used unless a different value for this argument is specified.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classhp_1_1FEValues.html differs (JavaScript source, ASCII text, with very long lines (1352))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classhp_1_1FEValues.html 2023-11-25 15:25:59.416566400 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classhp_1_1FEValues.html 2023-11-25 15:25:59.416566400 +0100
@@ -348,7 +348,7 @@
-
Constructor. This constructor is equivalent to the other one except that it makes the object use a mapping (i.e., an object of type MappingQ(1)) implicitly.
+
Constructor. This constructor is equivalent to the other one except that it makes the object use a mapping (i.e., an object of type MappingQ(1)) implicitly.
After the call, you can get an FEValues object using the get_present_fe_values() function that corresponds to the present cell. For this FEValues object, we use the additional arguments described below to determine which finite element, mapping, and quadrature formula to use. They are order in such a way that the arguments one may want to change most frequently come first. The rules for these arguments are as follows:
If the fe_index argument to this function is left at its default value, then we use that finite element within the hp::FECollection passed to the constructor of this class with index given by cell->active_fe_index(). Consequently, the hp::FECollection argument given to this object should really be the same as that used in the construction of the DoFHandler associated with the present cell. On the other hand, if a value is given for this argument, it overrides the choice of cell->active_fe_index().
If the q_index argument is left at its default value, then we use that quadrature formula within the hp::QCollection passed to the constructor of this class with index given by cell->active_fe_index(), i.e. the same index as that of the finite element. In this case, there should be a corresponding quadrature formula for each finite element in the hp::FECollection. As a special case, if the quadrature collection contains only a single element (a frequent case if one wants to use the same quadrature object for all finite elements in an hp-discretization, even if that may not be the most efficient), then this single quadrature is used unless a different value for this argument is specified. On the other hand, if a value is given for this argument, it overrides the choice of cell->active_fe_index() or the choice for the single quadrature.
-
If the mapping_index argument is left at its default value, then we use that mapping object within the hp::MappingCollection passed to the constructor of this class with index given by cell->active_fe_index(), i.e. the same index as that of the finite element. As above, if the mapping collection contains only a single element (a frequent case if one wants to use a mapping for all finite elements in an hp-discretization), then this single mapping is used unless a different value for this argument is specified.
+
If the mapping_index argument is left at its default value, then we use that mapping object within the hp::MappingCollection passed to the constructor of this class with index given by cell->active_fe_index(), i.e. the same index as that of the finite element. As above, if the mapping collection contains only a single element (a frequent case if one wants to use a mapping for all finite elements in an hp-discretization), then this single mapping is used unless a different value for this argument is specified.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classhp_1_1FEValuesBase.html differs (JavaScript source, ASCII text, with very long lines (1015))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classhp_1_1FEValuesBase.html 2023-11-25 15:25:59.433232728 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classhp_1_1FEValuesBase.html 2023-11-25 15:25:59.436565993 +0100
@@ -380,7 +380,7 @@
-
Constructor. This constructor is equivalent to the other one except that it makes the object use a mapping (i.e., an object of type MappingQ(1)) implicitly.
+
Constructor. This constructor is equivalent to the other one except that it makes the object use a mapping (i.e., an object of type MappingQ(1)) implicitly.
The location of the support points in reference coordinates that map to the mapping support points in real space by a polynomial map.
+
unit_support_points
The location of the support points in reference coordinates that map to the mapping support points in real space by a polynomial map.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classinternal_1_1MatrixFreeFunctions_1_1MappingDataOnTheFly.html differs (JavaScript source, ASCII text, with very long lines (747))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classinternal_1_1MatrixFreeFunctions_1_1MappingDataOnTheFly.html 2023-11-25 15:25:59.459898849 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classinternal_1_1MatrixFreeFunctions_1_1MappingDataOnTheFly.html 2023-11-25 15:25:59.459898849 +0100
@@ -254,7 +254,7 @@
-
Constructor. This constructor is equivalent to the other one except that it makes the object use a mapping (i.e., an object of type MappingQ(1)) implicitly.
+
Constructor. This constructor is equivalent to the other one except that it makes the object use a mapping (i.e., an object of type MappingQ(1)) implicitly.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classparallel_1_1DistributedTriangulationBase.html differs (JavaScript source, ASCII text, with very long lines (994))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classparallel_1_1DistributedTriangulationBase.html 2023-11-25 15:25:59.519897631 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classparallel_1_1DistributedTriangulationBase.html 2023-11-25 15:25:59.519897631 +0100
@@ -2022,7 +2022,7 @@
When vertices have been moved locally, for example using code like
cell->vertex(0) = new_location;
then this function can be used to update the location of vertices between MPI processes.
-
All the vertices that have been moved and might be in the ghost layer of a process have to be reported in the vertex_locally_moved argument. This ensures that that part of the information that has to be send between processes is actually sent. Additionally, it is quite important that vertices on the boundary between processes are reported on exactly one process (e.g. the one with the highest id). Otherwise we could expect undesirable results if multiple processes move a vertex differently. A typical strategy is to let processor move those vertices that are adjacent to cells whose owners include processor but no other processor with ; in other words, for vertices at the boundary of a subdomain, the processor with the lowest subdomain id "owns" a vertex.
+
All the vertices that have been moved and might be in the ghost layer of a process have to be reported in the vertex_locally_moved argument. This ensures that that part of the information that has to be send between processes is actually sent. Additionally, it is quite important that vertices on the boundary between processes are reported on exactly one process (e.g. the one with the highest id). Otherwise we could expect undesirable results if multiple processes move a vertex differently. A typical strategy is to let processor move those vertices that are adjacent to cells whose owners include processor but no other processor with ; in other words, for vertices at the boundary of a subdomain, the processor with the lowest subdomain id "owns" a vertex.
Note
It only makes sense to move vertices that are either located on locally owned cells or on cells in the ghost layer. This is because you can be sure that these vertices indeed exist on the finest mesh aggregated over all processors, whereas vertices on artificial cells but not at least in the ghost layer may or may not exist on the globally finest mesh. Consequently, the vertex_locally_moved argument may not contain vertices that aren't at least on ghost cells.
This function moves vertices in such a way that on every processor, the vertices of every locally owned and ghost cell is consistent with the corresponding location of these cells on other processors. On the other hand, the locations of artificial cells will in general be wrong since artificial cells may or may not exist on other processors and consequently it is not possible to determine their location in any way. This is not usually a problem since one never does anything on artificial cells. However, it may lead to problems if the mesh with moved vertices is refined in a later step. If that's what you want to do, the right way to do it is to save the offset applied to every vertex, call this function, and before refining or coarsening the mesh apply the opposite offset and call this function again.
@@ -2432,7 +2432,7 @@
-
Refine all cells times times. In other words, in each one of the times iterations, loop over all cells and refine each cell uniformly into children. In practice, this function repeats the following operations times times: call set_all_refine_flags() followed by execute_coarsening_and_refinement(). The end result is that the number of cells increases by a factor of .
+
Refine all cells times times. In other words, in each one of the times iterations, loop over all cells and refine each cell uniformly into children. In practice, this function repeats the following operations times times: call set_all_refine_flags() followed by execute_coarsening_and_refinement(). The end result is that the number of cells increases by a factor of .
The execute_coarsening_and_refinement() function called in this loop may throw an exception if it creates cells that are distorted (see its documentation for an explanation). This exception will be propagated through this function if that happens, and you may not get the actual number of refinement steps in that case.
Note
This function triggers the pre- and post-refinement signals before and after doing each individual refinement cycle (i.e. more than once if times > 1) . See the section on signals in the general documentation of this class.
@@ -6701,7 +6701,7 @@
-
Iterator to the first quad, used or not, on the given level. If a level has no quads, a past-the-end iterator is returned. If quads are no cells, i.e. for no level argument must be given.
+
Iterator to the first quad, used or not, on the given level. If a level has no quads, a past-the-end iterator is returned. If quads are no cells, i.e. for no level argument must be given.
Note
The given level argument needs to correspond to a level of the triangulation, i.e., should be less than the value returned by n_levels(). On the other hand, for parallel computations using a parallel::distributed::Triangulation object, it is often convenient to write loops over the cells of all levels of the global mesh, even if the local portion of the triangulation does not actually have cells at one of the higher levels. In those cases, the level argument is accepted if it is less than what the n_global_levels() function returns. If the given level is between the values returned by n_levels() and n_global_levels(), then no cells exist in the local portion of the triangulation at this level, and the function simply returns what end() would return.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classparallel_1_1TriangulationBase.html differs (JavaScript source, ASCII text, with very long lines (972))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classparallel_1_1TriangulationBase.html 2023-11-25 15:25:59.576563142 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classparallel_1_1TriangulationBase.html 2023-11-25 15:25:59.576563142 +0100
@@ -1547,7 +1547,7 @@
When vertices have been moved locally, for example using code like
cell->vertex(0) = new_location;
then this function can be used to update the location of vertices between MPI processes.
-
All the vertices that have been moved and might be in the ghost layer of a process have to be reported in the vertex_locally_moved argument. This ensures that that part of the information that has to be send between processes is actually sent. Additionally, it is quite important that vertices on the boundary between processes are reported on exactly one process (e.g. the one with the highest id). Otherwise we could expect undesirable results if multiple processes move a vertex differently. A typical strategy is to let processor move those vertices that are adjacent to cells whose owners include processor but no other processor with ; in other words, for vertices at the boundary of a subdomain, the processor with the lowest subdomain id "owns" a vertex.
+
All the vertices that have been moved and might be in the ghost layer of a process have to be reported in the vertex_locally_moved argument. This ensures that that part of the information that has to be send between processes is actually sent. Additionally, it is quite important that vertices on the boundary between processes are reported on exactly one process (e.g. the one with the highest id). Otherwise we could expect undesirable results if multiple processes move a vertex differently. A typical strategy is to let processor move those vertices that are adjacent to cells whose owners include processor but no other processor with ; in other words, for vertices at the boundary of a subdomain, the processor with the lowest subdomain id "owns" a vertex.
Note
It only makes sense to move vertices that are either located on locally owned cells or on cells in the ghost layer. This is because you can be sure that these vertices indeed exist on the finest mesh aggregated over all processors, whereas vertices on artificial cells but not at least in the ghost layer may or may not exist on the globally finest mesh. Consequently, the vertex_locally_moved argument may not contain vertices that aren't at least on ghost cells.
This function moves vertices in such a way that on every processor, the vertices of every locally owned and ghost cell is consistent with the corresponding location of these cells on other processors. On the other hand, the locations of artificial cells will in general be wrong since artificial cells may or may not exist on other processors and consequently it is not possible to determine their location in any way. This is not usually a problem since one never does anything on artificial cells. However, it may lead to problems if the mesh with moved vertices is refined in a later step. If that's what you want to do, the right way to do it is to save the offset applied to every vertex, call this function, and before refining or coarsening the mesh apply the opposite offset and call this function again.
@@ -2024,7 +2024,7 @@
-
Refine all cells times times. In other words, in each one of the times iterations, loop over all cells and refine each cell uniformly into children. In practice, this function repeats the following operations times times: call set_all_refine_flags() followed by execute_coarsening_and_refinement(). The end result is that the number of cells increases by a factor of .
+
Refine all cells times times. In other words, in each one of the times iterations, loop over all cells and refine each cell uniformly into children. In practice, this function repeats the following operations times times: call set_all_refine_flags() followed by execute_coarsening_and_refinement(). The end result is that the number of cells increases by a factor of .
The execute_coarsening_and_refinement() function called in this loop may throw an exception if it creates cells that are distorted (see its documentation for an explanation). This exception will be propagated through this function if that happens, and you may not get the actual number of refinement steps in that case.
Note
This function triggers the pre- and post-refinement signals before and after doing each individual refinement cycle (i.e. more than once if times > 1) . See the section on signals in the general documentation of this class.
@@ -6324,7 +6324,7 @@
-
Iterator to the first quad, used or not, on the given level. If a level has no quads, a past-the-end iterator is returned. If quads are no cells, i.e. for no level argument must be given.
+
Iterator to the first quad, used or not, on the given level. If a level has no quads, a past-the-end iterator is returned. If quads are no cells, i.e. for no level argument must be given.
Note
The given level argument needs to correspond to a level of the triangulation, i.e., should be less than the value returned by n_levels(). On the other hand, for parallel computations using a parallel::distributed::Triangulation object, it is often convenient to write loops over the cells of all levels of the global mesh, even if the local portion of the triangulation does not actually have cells at one of the higher levels. In those cases, the level argument is accepted if it is less than what the n_global_levels() function returns. If the given level is between the values returned by n_levels() and n_global_levels(), then no cells exist in the local portion of the triangulation at this level, and the function simply returns what end() would return.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classparallel_1_1distributed_1_1Triangulation.html differs (JavaScript source, ASCII text, with very long lines (1139))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classparallel_1_1distributed_1_1Triangulation.html 2023-11-25 15:25:59.643228452 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classparallel_1_1distributed_1_1Triangulation.html 2023-11-25 15:25:59.643228452 +0100
@@ -1925,7 +1925,7 @@
-
Return a permutation vector for the order the coarse cells are handed off to p4est. For example the value of the th element in this vector is the index of the deal.II coarse cell (counting from begin(0)) that corresponds to the th tree managed by p4est.
+
Return a permutation vector for the order the coarse cells are handed off to p4est. For example the value of the th element in this vector is the index of the deal.II coarse cell (counting from begin(0)) that corresponds to the th tree managed by p4est.
When vertices have been moved locally, for example using code like
cell->vertex(0) = new_location;
then this function can be used to update the location of vertices between MPI processes.
-
All the vertices that have been moved and might be in the ghost layer of a process have to be reported in the vertex_locally_moved argument. This ensures that that part of the information that has to be send between processes is actually sent. Additionally, it is quite important that vertices on the boundary between processes are reported on exactly one process (e.g. the one with the highest id). Otherwise we could expect undesirable results if multiple processes move a vertex differently. A typical strategy is to let processor move those vertices that are adjacent to cells whose owners include processor but no other processor with ; in other words, for vertices at the boundary of a subdomain, the processor with the lowest subdomain id "owns" a vertex.
+
All the vertices that have been moved and might be in the ghost layer of a process have to be reported in the vertex_locally_moved argument. This ensures that that part of the information that has to be send between processes is actually sent. Additionally, it is quite important that vertices on the boundary between processes are reported on exactly one process (e.g. the one with the highest id). Otherwise we could expect undesirable results if multiple processes move a vertex differently. A typical strategy is to let processor move those vertices that are adjacent to cells whose owners include processor but no other processor with ; in other words, for vertices at the boundary of a subdomain, the processor with the lowest subdomain id "owns" a vertex.
Note
It only makes sense to move vertices that are either located on locally owned cells or on cells in the ghost layer. This is because you can be sure that these vertices indeed exist on the finest mesh aggregated over all processors, whereas vertices on artificial cells but not at least in the ghost layer may or may not exist on the globally finest mesh. Consequently, the vertex_locally_moved argument may not contain vertices that aren't at least on ghost cells.
This function moves vertices in such a way that on every processor, the vertices of every locally owned and ghost cell is consistent with the corresponding location of these cells on other processors. On the other hand, the locations of artificial cells will in general be wrong since artificial cells may or may not exist on other processors and consequently it is not possible to determine their location in any way. This is not usually a problem since one never does anything on artificial cells. However, it may lead to problems if the mesh with moved vertices is refined in a later step. If that's what you want to do, the right way to do it is to save the offset applied to every vertex, call this function, and before refining or coarsening the mesh apply the opposite offset and call this function again.
@@ -3344,7 +3344,7 @@
-
Refine all cells times times. In other words, in each one of the times iterations, loop over all cells and refine each cell uniformly into children. In practice, this function repeats the following operations times times: call set_all_refine_flags() followed by execute_coarsening_and_refinement(). The end result is that the number of cells increases by a factor of .
+
Refine all cells times times. In other words, in each one of the times iterations, loop over all cells and refine each cell uniformly into children. In practice, this function repeats the following operations times times: call set_all_refine_flags() followed by execute_coarsening_and_refinement(). The end result is that the number of cells increases by a factor of .
The execute_coarsening_and_refinement() function called in this loop may throw an exception if it creates cells that are distorted (see its documentation for an explanation). This exception will be propagated through this function if that happens, and you may not get the actual number of refinement steps in that case.
Note
This function triggers the pre- and post-refinement signals before and after doing each individual refinement cycle (i.e. more than once if times > 1) . See the section on signals in the general documentation of this class.
@@ -7377,7 +7377,7 @@
-
Iterator to the first quad, used or not, on the given level. If a level has no quads, a past-the-end iterator is returned. If quads are no cells, i.e. for no level argument must be given.
+
Iterator to the first quad, used or not, on the given level. If a level has no quads, a past-the-end iterator is returned. If quads are no cells, i.e. for no level argument must be given.
Note
The given level argument needs to correspond to a level of the triangulation, i.e., should be less than the value returned by n_levels(). On the other hand, for parallel computations using a parallel::distributed::Triangulation object, it is often convenient to write loops over the cells of all levels of the global mesh, even if the local portion of the triangulation does not actually have cells at one of the higher levels. In those cases, the level argument is accepted if it is less than what the n_global_levels() function returns. If the given level is between the values returned by n_levels() and n_global_levels(), then no cells exist in the local portion of the triangulation at this level, and the function simply returns what end() would return.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classparallel_1_1distributed_1_1Triangulation_3_011_00_01spacedim_01_4.html differs (JavaScript source, ASCII text, with very long lines (1186))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classparallel_1_1distributed_1_1Triangulation_3_011_00_01spacedim_01_4.html 2023-11-25 15:25:59.703227230 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classparallel_1_1distributed_1_1Triangulation_3_011_00_01spacedim_01_4.html 2023-11-25 15:25:59.703227230 +0100
@@ -2364,7 +2364,7 @@
When vertices have been moved locally, for example using code like
cell->vertex(0) = new_location;
then this function can be used to update the location of vertices between MPI processes.
-
All the vertices that have been moved and might be in the ghost layer of a process have to be reported in the vertex_locally_moved argument. This ensures that that part of the information that has to be send between processes is actually sent. Additionally, it is quite important that vertices on the boundary between processes are reported on exactly one process (e.g. the one with the highest id). Otherwise we could expect undesirable results if multiple processes move a vertex differently. A typical strategy is to let processor move those vertices that are adjacent to cells whose owners include processor but no other processor with ; in other words, for vertices at the boundary of a subdomain, the processor with the lowest subdomain id "owns" a vertex.
+
All the vertices that have been moved and might be in the ghost layer of a process have to be reported in the vertex_locally_moved argument. This ensures that that part of the information that has to be send between processes is actually sent. Additionally, it is quite important that vertices on the boundary between processes are reported on exactly one process (e.g. the one with the highest id). Otherwise we could expect undesirable results if multiple processes move a vertex differently. A typical strategy is to let processor move those vertices that are adjacent to cells whose owners include processor but no other processor with ; in other words, for vertices at the boundary of a subdomain, the processor with the lowest subdomain id "owns" a vertex.
Note
It only makes sense to move vertices that are either located on locally owned cells or on cells in the ghost layer. This is because you can be sure that these vertices indeed exist on the finest mesh aggregated over all processors, whereas vertices on artificial cells but not at least in the ghost layer may or may not exist on the globally finest mesh. Consequently, the vertex_locally_moved argument may not contain vertices that aren't at least on ghost cells.
This function moves vertices in such a way that on every processor, the vertices of every locally owned and ghost cell is consistent with the corresponding location of these cells on other processors. On the other hand, the locations of artificial cells will in general be wrong since artificial cells may or may not exist on other processors and consequently it is not possible to determine their location in any way. This is not usually a problem since one never does anything on artificial cells. However, it may lead to problems if the mesh with moved vertices is refined in a later step. If that's what you want to do, the right way to do it is to save the offset applied to every vertex, call this function, and before refining or coarsening the mesh apply the opposite offset and call this function again.
@@ -2773,7 +2773,7 @@
-
Refine all cells times times. In other words, in each one of the times iterations, loop over all cells and refine each cell uniformly into children. In practice, this function repeats the following operations times times: call set_all_refine_flags() followed by execute_coarsening_and_refinement(). The end result is that the number of cells increases by a factor of .
+
Refine all cells times times. In other words, in each one of the times iterations, loop over all cells and refine each cell uniformly into children. In practice, this function repeats the following operations times times: call set_all_refine_flags() followed by execute_coarsening_and_refinement(). The end result is that the number of cells increases by a factor of .
The execute_coarsening_and_refinement() function called in this loop may throw an exception if it creates cells that are distorted (see its documentation for an explanation). This exception will be propagated through this function if that happens, and you may not get the actual number of refinement steps in that case.
Note
This function triggers the pre- and post-refinement signals before and after doing each individual refinement cycle (i.e. more than once if times > 1) . See the section on signals in the general documentation of this class.
@@ -6961,7 +6961,7 @@
-
Iterator to the first quad, used or not, on the given level. If a level has no quads, a past-the-end iterator is returned. If quads are no cells, i.e. for no level argument must be given.
+
Iterator to the first quad, used or not, on the given level. If a level has no quads, a past-the-end iterator is returned. If quads are no cells, i.e. for no level argument must be given.
Note
The given level argument needs to correspond to a level of the triangulation, i.e., should be less than the value returned by n_levels(). On the other hand, for parallel computations using a parallel::distributed::Triangulation object, it is often convenient to write loops over the cells of all levels of the global mesh, even if the local portion of the triangulation does not actually have cells at one of the higher levels. In those cases, the level argument is accepted if it is less than what the n_global_levels() function returns. If the given level is between the values returned by n_levels() and n_global_levels(), then no cells exist in the local portion of the triangulation at this level, and the function simply returns what end() would return.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classparallel_1_1fullydistributed_1_1Triangulation.html differs (JavaScript source, ASCII text, with very long lines (899))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classparallel_1_1fullydistributed_1_1Triangulation.html 2023-11-25 15:25:59.769892541 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classparallel_1_1fullydistributed_1_1Triangulation.html 2023-11-25 15:25:59.766559277 +0100
@@ -2539,7 +2539,7 @@
When vertices have been moved locally, for example using code like
cell->vertex(0) = new_location;
then this function can be used to update the location of vertices between MPI processes.
-
All the vertices that have been moved and might be in the ghost layer of a process have to be reported in the vertex_locally_moved argument. This ensures that that part of the information that has to be send between processes is actually sent. Additionally, it is quite important that vertices on the boundary between processes are reported on exactly one process (e.g. the one with the highest id). Otherwise we could expect undesirable results if multiple processes move a vertex differently. A typical strategy is to let processor move those vertices that are adjacent to cells whose owners include processor but no other processor with ; in other words, for vertices at the boundary of a subdomain, the processor with the lowest subdomain id "owns" a vertex.
+
All the vertices that have been moved and might be in the ghost layer of a process have to be reported in the vertex_locally_moved argument. This ensures that that part of the information that has to be send between processes is actually sent. Additionally, it is quite important that vertices on the boundary between processes are reported on exactly one process (e.g. the one with the highest id). Otherwise we could expect undesirable results if multiple processes move a vertex differently. A typical strategy is to let processor move those vertices that are adjacent to cells whose owners include processor but no other processor with ; in other words, for vertices at the boundary of a subdomain, the processor with the lowest subdomain id "owns" a vertex.
Note
It only makes sense to move vertices that are either located on locally owned cells or on cells in the ghost layer. This is because you can be sure that these vertices indeed exist on the finest mesh aggregated over all processors, whereas vertices on artificial cells but not at least in the ghost layer may or may not exist on the globally finest mesh. Consequently, the vertex_locally_moved argument may not contain vertices that aren't at least on ghost cells.
This function moves vertices in such a way that on every processor, the vertices of every locally owned and ghost cell is consistent with the corresponding location of these cells on other processors. On the other hand, the locations of artificial cells will in general be wrong since artificial cells may or may not exist on other processors and consequently it is not possible to determine their location in any way. This is not usually a problem since one never does anything on artificial cells. However, it may lead to problems if the mesh with moved vertices is refined in a later step. If that's what you want to do, the right way to do it is to save the offset applied to every vertex, call this function, and before refining or coarsening the mesh apply the opposite offset and call this function again.
@@ -2880,7 +2880,7 @@
-
Refine all cells times times. In other words, in each one of the times iterations, loop over all cells and refine each cell uniformly into children. In practice, this function repeats the following operations times times: call set_all_refine_flags() followed by execute_coarsening_and_refinement(). The end result is that the number of cells increases by a factor of .
+
Refine all cells times times. In other words, in each one of the times iterations, loop over all cells and refine each cell uniformly into children. In practice, this function repeats the following operations times times: call set_all_refine_flags() followed by execute_coarsening_and_refinement(). The end result is that the number of cells increases by a factor of .
The execute_coarsening_and_refinement() function called in this loop may throw an exception if it creates cells that are distorted (see its documentation for an explanation). This exception will be propagated through this function if that happens, and you may not get the actual number of refinement steps in that case.
Note
This function triggers the pre- and post-refinement signals before and after doing each individual refinement cycle (i.e. more than once if times > 1) . See the section on signals in the general documentation of this class.
@@ -6913,7 +6913,7 @@
-
Iterator to the first quad, used or not, on the given level. If a level has no quads, a past-the-end iterator is returned. If quads are no cells, i.e. for no level argument must be given.
+
Iterator to the first quad, used or not, on the given level. If a level has no quads, a past-the-end iterator is returned. If quads are no cells, i.e. for no level argument must be given.
Note
The given level argument needs to correspond to a level of the triangulation, i.e., should be less than the value returned by n_levels(). On the other hand, for parallel computations using a parallel::distributed::Triangulation object, it is often convenient to write loops over the cells of all levels of the global mesh, even if the local portion of the triangulation does not actually have cells at one of the higher levels. In those cases, the level argument is accepted if it is less than what the n_global_levels() function returns. If the given level is between the values returned by n_levels() and n_global_levels(), then no cells exist in the local portion of the triangulation at this level, and the function simply returns what end() would return.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classparallel_1_1shared_1_1Triangulation.html differs (JavaScript source, ASCII text, with very long lines (1209))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classparallel_1_1shared_1_1Triangulation.html 2023-11-25 15:25:59.826558056 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classparallel_1_1shared_1_1Triangulation.html 2023-11-25 15:25:59.826558056 +0100
@@ -1987,7 +1987,7 @@
When vertices have been moved locally, for example using code like
cell->vertex(0) = new_location;
then this function can be used to update the location of vertices between MPI processes.
-
All the vertices that have been moved and might be in the ghost layer of a process have to be reported in the vertex_locally_moved argument. This ensures that that part of the information that has to be send between processes is actually sent. Additionally, it is quite important that vertices on the boundary between processes are reported on exactly one process (e.g. the one with the highest id). Otherwise we could expect undesirable results if multiple processes move a vertex differently. A typical strategy is to let processor move those vertices that are adjacent to cells whose owners include processor but no other processor with ; in other words, for vertices at the boundary of a subdomain, the processor with the lowest subdomain id "owns" a vertex.
+
All the vertices that have been moved and might be in the ghost layer of a process have to be reported in the vertex_locally_moved argument. This ensures that that part of the information that has to be send between processes is actually sent. Additionally, it is quite important that vertices on the boundary between processes are reported on exactly one process (e.g. the one with the highest id). Otherwise we could expect undesirable results if multiple processes move a vertex differently. A typical strategy is to let processor move those vertices that are adjacent to cells whose owners include processor but no other processor with ; in other words, for vertices at the boundary of a subdomain, the processor with the lowest subdomain id "owns" a vertex.
Note
It only makes sense to move vertices that are either located on locally owned cells or on cells in the ghost layer. This is because you can be sure that these vertices indeed exist on the finest mesh aggregated over all processors, whereas vertices on artificial cells but not at least in the ghost layer may or may not exist on the globally finest mesh. Consequently, the vertex_locally_moved argument may not contain vertices that aren't at least on ghost cells.
This function moves vertices in such a way that on every processor, the vertices of every locally owned and ghost cell is consistent with the corresponding location of these cells on other processors. On the other hand, the locations of artificial cells will in general be wrong since artificial cells may or may not exist on other processors and consequently it is not possible to determine their location in any way. This is not usually a problem since one never does anything on artificial cells. However, it may lead to problems if the mesh with moved vertices is refined in a later step. If that's what you want to do, the right way to do it is to save the offset applied to every vertex, call this function, and before refining or coarsening the mesh apply the opposite offset and call this function again.
@@ -2335,7 +2335,7 @@
-
Refine all cells times times. In other words, in each one of the times iterations, loop over all cells and refine each cell uniformly into children. In practice, this function repeats the following operations times times: call set_all_refine_flags() followed by execute_coarsening_and_refinement(). The end result is that the number of cells increases by a factor of .
+
Refine all cells times times. In other words, in each one of the times iterations, loop over all cells and refine each cell uniformly into children. In practice, this function repeats the following operations times times: call set_all_refine_flags() followed by execute_coarsening_and_refinement(). The end result is that the number of cells increases by a factor of .
The execute_coarsening_and_refinement() function called in this loop may throw an exception if it creates cells that are distorted (see its documentation for an explanation). This exception will be propagated through this function if that happens, and you may not get the actual number of refinement steps in that case.
Note
This function triggers the pre- and post-refinement signals before and after doing each individual refinement cycle (i.e. more than once if times > 1) . See the section on signals in the general documentation of this class.
@@ -6555,7 +6555,7 @@
-
Iterator to the first quad, used or not, on the given level. If a level has no quads, a past-the-end iterator is returned. If quads are no cells, i.e. for no level argument must be given.
+
Iterator to the first quad, used or not, on the given level. If a level has no quads, a past-the-end iterator is returned. If quads are no cells, i.e. for no level argument must be given.
Note
The given level argument needs to correspond to a level of the triangulation, i.e., should be less than the value returned by n_levels(). On the other hand, for parallel computations using a parallel::distributed::Triangulation object, it is often convenient to write loops over the cells of all levels of the global mesh, even if the local portion of the triangulation does not actually have cells at one of the higher levels. In those cases, the level argument is accepted if it is less than what the n_global_levels() function returns. If the given level is between the values returned by n_levels() and n_global_levels(), then no cells exist in the local portion of the triangulation at this level, and the function simply returns what end() would return.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/deprecated.html differs (JavaScript source, ASCII text, with very long lines (896))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/deprecated.html 2023-11-25 15:25:59.846557647 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/deprecated.html 2023-11-25 15:25:59.846557647 +0100
@@ -103,10 +103,10 @@
This function will not work for DoFHandler objects that are built on a parallel::distributed::Triangulation object. The reasons is that the output argument selected_dofs has to have a length equal to all global degrees of freedom. Consequently, this does not scale to very large problems, and this is also why the function is deprecated. If you need the functionality of this function for parallel triangulations, then you need to use the other DoFTools::extract_boundary_dofs() function that returns its information via an IndexSet object.
Member make_array_view (Tensor< rank, dim, Number > &tensor)
+
This function suggests that the elements of a Tensor object are stored as a contiguous array, but this is not in fact true and one should not pretend that this so. As a consequence, this function is deprecated.
Member make_array_view (SymmetricTensor< rank, dim, Number > &tensor)
This function suggests that the elements of a SymmetricTensor object are stored as a contiguous array, but this is not in fact true and one should not pretend that this so. As a consequence, this function is deprecated.
-
Member make_array_view (const Tensor< rank, dim, Number > &tensor)
-
This function suggests that the elements of a Tensor object are stored as a contiguous array, but this is not in fact true and one should not pretend that this so. As a consequence, this function is deprecated.
Member make_array_view (const SymmetricTensor< rank, dim, Number > &tensor)
This function suggests that the elements of a SymmetricTensor object are stored as a contiguous array, but this is not in fact true and one should not pretend that this so. As a consequence, this function is deprecated.
-
Member make_array_view (Tensor< rank, dim, Number > &tensor)
-
This function suggests that the elements of a Tensor object are stored as a contiguous array, but this is not in fact true and one should not pretend that this so. As a consequence, this function is deprecated.
+
Member make_array_view (const Tensor< rank, dim, Number > &tensor)
+
This function suggests that the elements of a Tensor object are stored as a contiguous array, but this is not in fact true and one should not pretend that this so. As a consequence, this function is deprecated.
Versions of SUNDIALS after 4.0 no longer provide all of the information necessary for this callback (see below). Use the solve_with_jacobian callback described below.
This function suggests that the elements of a SymmetricTensor object are stored as a contiguous array, but this is not in fact true and one should not pretend that this so. As a consequence, this function is deprecated.
This function suggests that the elements of a SymmetricTensor object are stored as a contiguous array, but this is not in fact true and one should not pretend that this so. As a consequence, this function is deprecated.
This function suggests that the elements of a SymmetricTensor object are stored as a contiguous array, but this is not in fact true and one should not pretend that this so. As a consequence, this function is deprecated.
This function suggests that the elements of a SymmetricTensor object are stored as a contiguous array, but this is not in fact true and one should not pretend that this so. As a consequence, this function is deprecated.
This function suggests that the elements of a Tensor object are stored as a contiguous array, but this is not in fact true and one should not pretend that this so. As a consequence, this function is deprecated.
This function suggests that the elements of a Tensor object are stored as a contiguous array, but this is not in fact true and one should not pretend that this so. As a consequence, this function is deprecated.
This function suggests that the elements of a Tensor object are stored as a contiguous array, but this is not in fact true and one should not pretend that this so. As a consequence, this function is deprecated.
This function suggests that the elements of a Tensor object are stored as a contiguous array, but this is not in fact true and one should not pretend that this so. As a consequence, this function is deprecated.
This function suggests that the elements of a Tensor object are stored as a contiguous array, but this is not in fact true and one should not pretend that this so. As a consequence, this function is deprecated.
Use the weight signal instead which omits the base weight. You can invoke the old behavior by connecting a function to the signal that returns the base weight as follows. This function should be added in addition to the one that actually computes the weight.
+
Use the weight signal instead which omits the base weight. You can invoke the old behavior by connecting a function to the signal that returns the base weight as follows. This function should be added in addition to the one that actually computes the weight.
Member XDMFEntry::XDMFEntry (const std::string &mesh_filename, const std::string &solution_filename, const double time, const std::uint64_t nodes, const std::uint64_t cells, const unsigned int dim, const unsigned int spacedim)
-
Use the constructor that additionally takes a ReferenceCell.
+
Member XDMFEntry::XDMFEntry (const std::string &filename, const double time, const std::uint64_t nodes, const std::uint64_t cells, const unsigned int dim)
+
Use the constructor that additionally takes a ReferenceCell.
Member XDMFEntry::XDMFEntry (const std::string &mesh_filename, const std::string &solution_filename, const double time, const std::uint64_t nodes, const std::uint64_t cells, const unsigned int dim)
Use the constructor that additionally takes a ReferenceCell.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/derivative__form_8h.html differs (JavaScript source, ASCII text, with very long lines (1196))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/derivative__form_8h.html 2023-11-25 15:25:59.856557444 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/derivative__form_8h.html 2023-11-25 15:25:59.859890712 +0100
@@ -152,21 +152,21 @@
-
One of the uses of DerivativeForm is to apply it as a linear transformation. This function returns , which approximates the change in when is changed by the amount
-DerivativeForm is to apply it as a linear transformation. This function returns , which approximates the change in when is changed by the amount
+
+\]" src="form_396.png"/>
The transformation corresponds to
-
+\]" src="form_397.png"/>
-
in index notation and corresponds to in matrix notation.
+
in index notation and corresponds to in matrix notation.
Similar to the previous apply_transformation(). Each row of the result corresponds to one of the rows of D_X transformed by grad_F, equivalent to in matrix notation.
+
Similar to the previous apply_transformation(). Each row of the result corresponds to one of the rows of D_X transformed by grad_F, equivalent to in matrix notation.
Similar to the previous apply_transformation(), specialized for the case dim == spacedim where we can return a rank-2 tensor instead of the more general DerivativeForm. Each row of the result corresponds to one of the rows of D_X transformed by grad_F, equivalent to in matrix notation.
+
Similar to the previous apply_transformation(), specialized for the case dim == spacedim where we can return a rank-2 tensor instead of the more general DerivativeForm. Each row of the result corresponds to one of the rows of D_X transformed by grad_F, equivalent to in matrix notation.
Similar to the previous apply_transformation(). In matrix notation, it computes . Moreover, the result of this operation can be interpreted as a metric tensor in which corresponds to the Euclidean metric tensor in . For every pair of vectors , we have:
-apply_transformation(). In matrix notation, it computes . Moreover, the result of this operation can be interpreted as a metric tensor in which corresponds to the Euclidean metric tensor in . For every pair of vectors , we have:
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/group__CPP11.html differs (JavaScript source, ASCII text, with very long lines (1210))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/group__CPP11.html 2023-11-25 15:25:59.876557037 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/group__CPP11.html 2023-11-25 15:25:59.876557037 +0100
@@ -175,7 +175,7 @@
The macro DEAL_II_CONSTEXPR expands to constexpr if the compiler supports enough constexpr features (such as loops). If the compiler does not then this macro expands to nothing.
Functions declared as constexpr can be evaluated at compile time. Hence code like
assuming A is declared with the constexpr specifier, will typically result in compile-time constants. This example shows the performance gains of using constexpr because here we performed an operation with complexity during compile time, avoiding any runtime cost.
+
assuming A is declared with the constexpr specifier, will typically result in compile-time constants. This example shows the performance gains of using constexpr because here we performed an operation with complexity during compile time, avoiding any runtime cost.
where these two member functions perform one step (or the transpose of such a step) of the smoothing scheme. In other words, the operations performed by these functions are and .
+
where these two member functions perform one step (or the transpose of such a step) of the smoothing scheme. In other words, the operations performed by these functions are and .
SparsityPatternType
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/group__LAOperators.html differs (JavaScript source, ASCII text, with very long lines (807))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/group__LAOperators.html 2023-11-25 15:26:00.019887455 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/group__LAOperators.html 2023-11-25 15:26:00.023220718 +0100
@@ -323,7 +323,7 @@
std::function<void(Domain &, const Range &)> Tvmult;
std::function<void(Domain &, const Range &)> Tvmult_add;
Thus, such an object can be used as a matrix object in all iterative solver classes, either as a matrix object, or as preconditioner.
-
The big advantage of the LinearOperator class is that it provides syntactic sugar for complex matrix-vector operations. As an example consider the operation , where , and denote (possibly different) SparseMatrix objects. In order to construct a LinearOperatorop that performs above computation when applied on a vector, one can write:
The big advantage of the LinearOperator class is that it provides syntactic sugar for complex matrix-vector operations. As an example consider the operation , where , and denote (possibly different) SparseMatrix objects. In order to construct a LinearOperatorop that performs above computation when applied on a vector, one can write:
Return a LinearOperator that performs the operations associated with the Schur complement. There are two additional helper functions, condense_schur_rhs() and postprocess_schur_solution(), that are likely necessary to be used in order to perform any useful tasks in linear algebra with this operator.
We construct the definition of the Schur complement in the following way:
Consider a general system of linear equations that can be decomposed into two major sets of equations:
-
+\end{eqnarray*}" src="form_1852.png"/>
-
where represent general subblocks of the matrix and, similarly, general subvectors of are given by .
+
where represent general subblocks of the matrix and, similarly, general subvectors of are given by .
This is equivalent to the following two statements:
-
+\end{eqnarray*}" src="form_1857.png"/>
-
Assuming that are both square and invertible, we could then perform one of two possible substitutions,
- are both square and invertible, we could then perform one of two possible substitutions,
+
+\end{eqnarray*}" src="form_1859.png"/>
which amount to performing block Gaussian elimination on this system of equations.
For the purpose of the current implementation, we choose to substitute (3) into (2)
-
+\end{eqnarray*}" src="form_1860.png"/>
This leads to the result
-
+\]" src="form_1861.png"/>
-
with being the Schur complement and the modified right-hand side vector arising from the condensation step. Note that for this choice of , submatrix need not be invertible and may thus be the null matrix. Ideally should be well-conditioned.
-
So for any arbitrary vector , the Schur complement performs the following operation:
- being the Schur complement and the modified right-hand side vector arising from the condensation step. Note that for this choice of , submatrix need not be invertible and may thus be the null matrix. Ideally should be well-conditioned.
+
So for any arbitrary vector , the Schur complement performs the following operation:
+
+\]" src="form_1868.png"/>
A typical set of steps needed the solve a linear system (1),(2) would be:
Define iterative inverse matrix such that (6) holds. It is necessary to use a solver with a preconditioner to compute the approximate inverse operation of since we never compute directly, but rather the result of its operation. To achieve this, one may again use the inverse_operator() in conjunction with the Schur complement that we've just constructed. Observe that the both and its preconditioner operate over the same space as .
Define iterative inverse matrix such that (6) holds. It is necessary to use a solver with a preconditioner to compute the approximate inverse operation of since we never compute directly, but rather the result of its operation. To achieve this, one may again use the inverse_operator() in conjunction with the Schur complement that we've just constructed. Observe that the both and its preconditioner operate over the same space as .
In the above example, the preconditioner for was defined as the preconditioner for , which is valid since they operate on the same space. However, if and are too dissimilar, then this may lead to a large number of solver iterations as is not a good approximation for .
-
A better preconditioner in such a case would be one that provides a more representative approximation for . One approach is shown in step-22, where is the null matrix and the preconditioner for is derived from the mass matrix over this space.
-
From another viewpoint, a similar result can be achieved by first constructing an object that represents an approximation for wherein expensive operation, namely , is approximated. Thereafter we construct the approximate inverse operator which is then used as the preconditioner for computing .
// Construction of approximate inverse of Schur complement
+
In the above example, the preconditioner for was defined as the preconditioner for , which is valid since they operate on the same space. However, if and are too dissimilar, then this may lead to a large number of solver iterations as is not a good approximation for .
+
A better preconditioner in such a case would be one that provides a more representative approximation for . One approach is shown in step-22, where is the null matrix and the preconditioner for is derived from the mass matrix over this space.
+
From another viewpoint, a similar result can be achieved by first constructing an object that represents an approximation for wherein expensive operation, namely , is approximated. Thereafter we construct the approximate inverse operator which is then used as the preconditioner for computing .
// Construction of approximate inverse of Schur complement
Note that due to the construction of S_inv_approx and subsequently S_inv, there are a pair of nested iterative solvers which could collectively consume a lot of resources. Therefore care should be taken in the choices leading to the construction of the iterative inverse_operators. One might consider the use of a IterationNumberControl (or a similar mechanism) to limit the number of inner solver iterations. This controls the accuracy of the approximate inverse operation which acts only as the preconditioner for . Furthermore, the preconditioner to , which in this example is , should ideally be computationally inexpensive.
+
Note that due to the construction of S_inv_approx and subsequently S_inv, there are a pair of nested iterative solvers which could collectively consume a lot of resources. Therefore care should be taken in the choices leading to the construction of the iterative inverse_operators. One might consider the use of a IterationNumberControl (or a similar mechanism) to limit the number of inner solver iterations. This controls the accuracy of the approximate inverse operation which acts only as the preconditioner for . Furthermore, the preconditioner to , which in this example is , should ideally be computationally inexpensive.
However, if an iterative solver based on IterationNumberControl is used as a preconditioner then the preconditioning operation is not a linear operation. Here a flexible solver like SolverFGMRES (flexible GMRES) is best employed as an outer solver in order to deal with the variable behavior of the preconditioner. Otherwise the iterative solver can stagnate somewhere near the tolerance of the preconditioner or generally behave erratically. Alternatively, using a ReductionControl would ensure that the preconditioner always solves to the same tolerance, thereby rendering its behavior constant.
Further examples of this functionality can be found in the test-suite, such as tests/lac/schur_complement_01.cc . The solution of a multi- component problem (namely step-22) using the schur_complement can be found in tests/lac/schur_complement_03.cc .
this operation performs the pre-processing (condensation) step on the RHS subvector g so that the Schur complement can be used to solve this system of equations. More specifically, it produces an object that represents the condensed form of the subvector g, namely
- where indicates the index of the quadrature point, its location on the reference cell, and its weight.
+ where indicates the index of the quadrature point, its location on the reference cell, and its weight.
In order to evaluate such an expression in an application code, we have to access three different kinds of objects: a quadrature object that describes locations and weights of quadrature points on the reference cell; a finite element object that describes the gradients of shape functions on the unit cell; and a mapping object that provides the Jacobian as well as its determinant. Dealing with all these objects would be cumbersome and error prone.
On the other hand, these three kinds of objects almost always appear together, and it is in fact very rare for deal.II application codes to do anything with quadrature, finite element, or mapping objects besides using them together. For this reason, deal.II uses the FEValues abstraction combining information on the shape functions, the geometry of the actual mesh cell and a quadrature rule on a reference cell. Upon construction it takes one object of each of the three mentioned categories. Later, it can be "re-initialized" for a concrete grid cell and then provides mapped quadrature points and weights, mapped shape function values and derivatives as well as some properties of the transformation from the reference cell to the actual mesh cell.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/group__auto__symb__diff.html differs (JavaScript source, ASCII text, with very long lines (4820))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/group__auto__symb__diff.html 2023-11-25 15:26:00.049886843 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/group__auto__symb__diff.html 2023-11-25 15:26:00.049886843 +0100
@@ -101,7 +101,7 @@
A module dedicated to the implementation of functions and classes that relate to automatic and symbolic differentiation.
-
Below we provide a very brief introduction as to what automatic and symbolic differentiation are, what variations of these computational/numerical schemes exist, and how they are integrated within deal.II's framework. The purpose of all of these schemes is to automatically compute the derivative of functions, or approximations of it, in cases where one does not want to compute them by hand. Common examples are situations in the finite element context is where one wants to solve a nonlinear problem that is given by requiring that some residual where is a complicated function that needs to be differentiated to apply Newton's method; and situations where one is given a parameter dependent problem and wants to form derivatives with regards to the parameters , for example to optimize an output functional with regards to , or for a sensitivity analysis with regards to . One should think of as design parameters: say, the width or shape of a wing, the stiffness coefficients of a material chosen to build an object, the power sent to a device, the chemical composition of the gases sent to a burner. In all of these cases, one should think of and as complicated and cumbersome to differentiate – at least when doing it by hand. A relatively simple case of a nonlinear problem that already highlights the tedium of computing derivatives by hand is shown in step-15. However, in reality, one might, for example, think about problems such as chemically reactive flows where the fluid equations have coefficients such as the density and viscosity that depend strongly and nonlinearly on the chemical composition, temperature, and pressure of the fluid at each point; and where the chemical species react with each other based on reaction coefficients that also depend nonlinearly and in complicated ways on the chemical composition, temperature, and pressure. In many cases, the exact formulas for all of these coefficients can take several lines to write out, may include exponentials and (harmonic or geometric) averages of several nonlinear terms, and/or may contain table lookup of and interpolation between data points. Just getting these terms right is difficult enough; computing derivatives of these terms is impractical in most applications and, in reality, impossible to get right. Higher derivatives are even more impossible to do without computer aid. Automatic or symbolic differentiation is a way out of this: One only has to implement the function that computes these coefficients in terms of their inputs only once, and gets the (correct!) derivatives without further coding effort (though at a non-negligible computational cost either at run time, compile time, or both).
+
Below we provide a very brief introduction as to what automatic and symbolic differentiation are, what variations of these computational/numerical schemes exist, and how they are integrated within deal.II's framework. The purpose of all of these schemes is to automatically compute the derivative of functions, or approximations of it, in cases where one does not want to compute them by hand. Common examples are situations in the finite element context is where one wants to solve a nonlinear problem that is given by requiring that some residual where is a complicated function that needs to be differentiated to apply Newton's method; and situations where one is given a parameter dependent problem and wants to form derivatives with regards to the parameters , for example to optimize an output functional with regards to , or for a sensitivity analysis with regards to . One should think of as design parameters: say, the width or shape of a wing, the stiffness coefficients of a material chosen to build an object, the power sent to a device, the chemical composition of the gases sent to a burner. In all of these cases, one should think of and as complicated and cumbersome to differentiate – at least when doing it by hand. A relatively simple case of a nonlinear problem that already highlights the tedium of computing derivatives by hand is shown in step-15. However, in reality, one might, for example, think about problems such as chemically reactive flows where the fluid equations have coefficients such as the density and viscosity that depend strongly and nonlinearly on the chemical composition, temperature, and pressure of the fluid at each point; and where the chemical species react with each other based on reaction coefficients that also depend nonlinearly and in complicated ways on the chemical composition, temperature, and pressure. In many cases, the exact formulas for all of these coefficients can take several lines to write out, may include exponentials and (harmonic or geometric) averages of several nonlinear terms, and/or may contain table lookup of and interpolation between data points. Just getting these terms right is difficult enough; computing derivatives of these terms is impractical in most applications and, in reality, impossible to get right. Higher derivatives are even more impossible to do without computer aid. Automatic or symbolic differentiation is a way out of this: One only has to implement the function that computes these coefficients in terms of their inputs only once, and gets the (correct!) derivatives without further coding effort (though at a non-negligible computational cost either at run time, compile time, or both).
Automatic differentiation
Automatic differentiation (commonly also referred to as algorithmic differentiation), is a numerical method that can be used to "automatically" compute the first, and perhaps higher-order, derivatives of function(s) with respect to one or more input variables. Although this comes at a certain computational cost, the benefits to using such a tool may be significant. When used correctly the derivatives of often complicated functions can be computed to a very high accuracy. Although the exact accuracy achievable by these frameworks largely depends on their underlying mathematical formulation, some implementations compute with a precision on the order of machine accuracy. Note that this is different to classical numerical differentiation (using, for example, a finite difference approximation of a function by evaluating it at different points), which has an accuracy that depends on both the perturbation size as well as the chosen finite-difference scheme; the error of these methods is measurably larger than well-formulated automatic differentiation approaches.
As a point of interest, the optimal Jacobian accumulation, which performs a minimal set of computations, lies somewhere between these two limiting cases. Its computation for a general composite function remains an open problem in graph theory.
-
With the aid of the diagram below (it and some of the listed details courtesy of this Wikipedia article), let us think about the representation of the calculation of the function and its derivatives:
-
Forward mode automatic differentiation
Reverse mode automatic differentiation
Specifically, we will briefly describe what forward and reverse auto-differentiation are. Note that in the diagram, along the edges of the graph in text are the directional derivative of function with respect to the -th variable, represented by the notation . The specific computations used to render the function value and its directional derivatives for this example are tabulated in the source article. For a second illustrative example, we refer the interested reader to this article.
-
Consider first that any composite function , here represented as having two independent variables, can be dissected into a composition of its elementary functions
-Wikipedia article), let us think about the representation of the calculation of the function and its derivatives:
+
Forward mode automatic differentiation
Reverse mode automatic differentiation
Specifically, we will briefly describe what forward and reverse auto-differentiation are. Note that in the diagram, along the edges of the graph in text are the directional derivative of function with respect to the -th variable, represented by the notation . The specific computations used to render the function value and its directional derivatives for this example are tabulated in the source article. For a second illustrative example, we refer the interested reader to this article.
+
Consider first that any composite function , here represented as having two independent variables, can be dissected into a composition of its elementary functions
+
+\]" src="form_10.png"/>
-
As was previously mentioned, if each of the primitive operations is smooth and differentiable, then the chain-rule can be universally employed to compute the total derivative of , namely . What distinguishes the "forward" from the "reverse" mode is how the chain-rule is evaluated, but ultimately both compute the total derivative
- is smooth and differentiable, then the chain-rule can be universally employed to compute the total derivative of , namely . What distinguishes the "forward" from the "reverse" mode is how the chain-rule is evaluated, but ultimately both compute the total derivative
+
+\]" src="form_14.png"/>
-
In forward-mode, the chain-rule is computed naturally from the "inside out". The independent variables are therefore fixed, and each sub-function is computed recursively and its result returned as inputs to the parent function. Encapsulating and fixing the order of operations using parentheses, this means that we compute
- is computed recursively and its result returned as inputs to the parent function. Encapsulating and fixing the order of operations using parentheses, this means that we compute
+
+\]" src="form_16.png"/>
The computational complexity of a forward-sweep is proportional to that of the input function. However, for each directional derivative that is to be computed one sweep of the computational graph is required.
In reverse-mode, the chain-rule is computed somewhat unnaturally from the "outside in". The values of the dependent variables first get computed and fixed, and then the preceding differential operations are evaluated and multiplied in succession with the previous results from left to right. Again, if we encapsulate and fix the order of operations using parentheses, this implies that the reverse calculation is performed by
-
+\]" src="form_17.png"/>
-
The intermediate values are known as adjoints, which must be computed and stored as the computational graph is traversed. However, for each dependent scalar function one sweep of the computational graph renders all directional derivatives at once.
+
The intermediate values are known as adjoints, which must be computed and stored as the computational graph is traversed. However, for each dependent scalar function one sweep of the computational graph renders all directional derivatives at once.
Overall, the efficiency of each mode is determined by the number of independent (input) variables and dependent (output) variables. If the outputs greatly exceed the inputs in number, then forward-mode can be shown to be more efficient than reverse-mode. The converse is true when the number of input variables greatly exceeds that of the output variables. This point may be used to help inform which number type is most suitable for which set of operations are to be performed using automatic differentiation. For example, in many applications for which second derivatives are to be computed it is appropriate to combine both reverse- and forward-modes. The former would then typically be used to calculate the first derivatives, and the latter the second derivatives.
Supported automatic differentiation libraries
@@ -328,7 +328,7 @@
Symbolic expressions and differentiation
Symbolic differentiation is, in terms of its design and usage, quite different to automatic differentiation. Underlying any symbolic library is a computer algebra system (CAS) that implements a language and collection of algorithms to manipulate symbolic (or "string-like") expressions. This is most similar, from a philosophical point of view, to how algebraic operations would be performed by hand.
-
To help better distinguish between symbolic differentiation and numerical methods like automatic differentiation, let's consider a very simple example. Suppose that the function , where and are variables that are independent of one another. By applying the chain-rule, the derivatives of this function are simply and . These are exactly the results that you get from a CAS after defining the symbolic variables x and y, defining the symbolic expression f = pow(2x+1, y) and computing the derivatives diff(f, x) and diff(f, y). At this point there is no assumption of what x and y represent; they may later be interpreted as plain (scalar) numbers, complex numbers, or something else for which the power and natural logarithm functions are well defined. Obviously this means that there is also no assumption about which point to evaluate either the expression or its derivatives. One could readily take the expression for and evaluate it at and then later, with no recomputation of the derivative expression itself, evaluate it at . In fact, the interpretation of any symbolic variable or expression, and the inter-dependencies between variables, may be defined or redefined at any point during their manipulation; this leads to a degree of flexibility in computations that cannot be matched by auto-differentiation. For example, one could perform the permanent substitution and then recompute for several different values of . One could also post-factum express an interdependency between x and y, such as . For such a case, this means that the initially computed derivatives and truly represent partial derivatives rather than total derivatives. Of course, if such an inter-dependency was explicitly defined before the derivatives and are computed, then this could correspond to the total derivative (which is the only result that auto-differentiation is able to achieve for this example).
+
To help better distinguish between symbolic differentiation and numerical methods like automatic differentiation, let's consider a very simple example. Suppose that the function , where and are variables that are independent of one another. By applying the chain-rule, the derivatives of this function are simply and . These are exactly the results that you get from a CAS after defining the symbolic variables x and y, defining the symbolic expression f = pow(2x+1, y) and computing the derivatives diff(f, x) and diff(f, y). At this point there is no assumption of what x and y represent; they may later be interpreted as plain (scalar) numbers, complex numbers, or something else for which the power and natural logarithm functions are well defined. Obviously this means that there is also no assumption about which point to evaluate either the expression or its derivatives. One could readily take the expression for and evaluate it at and then later, with no recomputation of the derivative expression itself, evaluate it at . In fact, the interpretation of any symbolic variable or expression, and the inter-dependencies between variables, may be defined or redefined at any point during their manipulation; this leads to a degree of flexibility in computations that cannot be matched by auto-differentiation. For example, one could perform the permanent substitution and then recompute for several different values of . One could also post-factum express an interdependency between x and y, such as . For such a case, this means that the initially computed derivatives and truly represent partial derivatives rather than total derivatives. Of course, if such an inter-dependency was explicitly defined before the derivatives and are computed, then this could correspond to the total derivative (which is the only result that auto-differentiation is able to achieve for this example).
Due to the sophisticated CAS that forms the foundation of symbolic operations, the types of manipulations are not necessarily restricted to differentiation alone, but rather may span a spectrum of manipulations relevant to discrete differential calculus, topics in pure mathematics, and more. The documentation for the SymPy library gives plenty of examples that highlight what a fully-fledged CAS is capable of. Through the Differentiation::SD::Expression class, and the associated functions in the Differentiation::SD namespace, we provide a wrapper to the high-performance SymEngine symbolic manipulation library that has enriched operator overloading and a consistent interface that makes it easy and "natural" to use. In fact, this class can be used as a "drop-in" replacement for arithmetic types in many situations, transforming the operations from being numeric to symbolic in nature; this is made especially easy when classes are templated on the underlying number type. Being focused on numerical simulation of PDEs, the functionality of the CAS that is exposed within deal.II focuses on symbolic expression creation, manipulation, and differentiation.
The convenience wrappers to SymEngine functionality are primarily focused on manipulations that solely involve dictionary-based (i.e., something reminiscent of "string-based") operations. Although SymEngine performs these operations in an efficient manner, they are still known to be computationally expensive, especially when the operations are performed on large expressions. It should therefore be expected that the performance of the parts of code that perform differentiation, symbolic substitution, etc., may be a limiting factor when using this in production code. deal.II therefore provides an interface to accelerate the evaluation of lengthy symbolic expression through the BatchOptimizer class (itself often leveraging functionality provided by SymEngine). In particular, the BatchOptimizer simultaneously optimizes a collection of symbolic expressions using methods such as common subexpression elimination (CSE), as well as by generating high performance code-paths to evaluate these expressions through the use of a custom-generated std::function or by compiling the expression using the LLVM JIT compiler. The usage of the Differentiation::SD::BatchOptimizer class is exemplified in step-71.
As a final note, it is important to recognize the remaining major deficiencies in deal.II's current implementation of the interface to the supported symbolic library. The level of functionality currently implemented effectively limits the use of symbolic algebra to the traditional use case (i.e. scalar and tensor algebra, as might be useful to define constitutive relations or complex functions for application as boundary conditions or source terms). In fact, step-71 demonstrates how it can be used to implement challenging constitutive models. In the future we will also implement classes to assist in performing assembly operations in the same spirit as that which has been done in the Differentiation::AD namespace.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/group__constraints.html differs (JavaScript source, ASCII text, with very long lines (1590))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/group__constraints.html 2023-11-25 15:26:00.083219500 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/group__constraints.html 2023-11-25 15:26:00.083219500 +0100
@@ -209,18 +209,18 @@
If you have boundary conditions that set a certain part of the solution's value, for example no normal flux, (as happens in flow problems and is handled by the VectorTools::compute_no_normal_flux_constraints function) or prescribed tangential components, (as happens in electromagnetic problems and is handled by the VectorTools::project_boundary_values_curl_conforming function). For the former case, imagine for example that we are at at vertex where the normal vector has the form and that the -, - and -components of the flow field at this vertex are associated with degrees of freedom 12, 28, and 40. Then the no-normal-flux condition means that we need to have the condition . The prescribed tangential component leads to similar constraints though there is often something on the right hand side.
+ (1,2,3)^T$" src="form_43.png"/> and that the -, - and -components of the flow field at this vertex are associated with degrees of freedom 12, 28, and 40. Then the no-normal-flux condition means that we need to have the condition . The prescribed tangential component leads to similar constraints though there is often something on the right hand side.
If you have hanging node constraints, for example in a mesh like this:
- Let's assume the bottom right one of the two red degrees of freedom is and that the two yellow neighbors on its left and right are and . Then, requiring that the finite element function be continuous is equivalent to requiring that . A similar situation occurs in the context of hp-adaptive finite element methods. For example, when using Q1 and Q2 elements (i.e. using FE_Q(1) and FE_Q(2)) on the two marked cells of the mesh
+ Let's assume the bottom right one of the two red degrees of freedom is and that the two yellow neighbors on its left and right are and . Then, requiring that the finite element function be continuous is equivalent to requiring that . A similar situation occurs in the context of hp-adaptive finite element methods. For example, when using Q1 and Q2 elements (i.e. using FE_Q(1) and FE_Q(2)) on the two marked cells of the mesh
- there are three constraints: first , then , and finally the identity . Similar constraints occur as hanging nodes even if all cells used the same finite elements. In all of these cases, you would use the DoFTools::make_hanging_node_constraints function to compute such constraints.
+ there are three constraints: first , then , and finally the identity . Similar constraints occur as hanging nodes even if all cells used the same finite elements. In all of these cases, you would use the DoFTools::make_hanging_node_constraints function to compute such constraints.
Other linear constraints, for example when you try to impose a certain average value for a problem that would otherwise not have a unique solution. An example of this is given in the step-11 tutorial program.
-
In all of these examples, constraints on degrees of freedom are linear and possibly inhomogeneous. In other words, they always have the form . The deal.II class that deals with storing and using these constraints is AffineConstraints.
+
In all of these examples, constraints on degrees of freedom are linear and possibly inhomogeneous. In other words, they always have the form . The deal.II class that deals with storing and using these constraints is AffineConstraints.
Eliminating constraints
When building the global system matrix and the right hand sides, one can build them without taking care of the constraints, i.e. by simply looping over cells and adding the local contributions to the global matrix and right hand side objects. In order to do actual calculations, you have to 'condense' the linear system: eliminate constrained degrees of freedom and distribute the appropriate values to the unconstrained dofs. This changes the sparsity pattern of the sparse matrices used in finite element calculations and is thus a quite expensive operation. The general scheme of things is then that you build your system, you eliminate (condense) away constrained nodes using the AffineConstraints::condense() functions, then you solve the remaining system, and finally you compute the values of constrained nodes from the values of the unconstrained ones using the AffineConstraints::distribute() function. Note that the AffineConstraints::condense() function is applied to matrix and right hand side of the linear system, while the AffineConstraints::distribute() function is applied to the solution vector.
This scheme of first building a linear system and then eliminating constrained degrees of freedom is inefficient, and a bottleneck if there are many constraints and matrices are full, i.e. especially for 3d and/or higher order or hp-finite elements. Furthermore, it is impossible to implement for parallel computations where a process may not have access to elements of the matrix. We therefore offer a second way of building linear systems, using the AffineConstraints::add_entries_local_to_global() and AffineConstraints::distribute_local_to_global() functions discussed below. The resulting linear systems are equivalent to those one gets after calling the AffineConstraints::condense() functions.
@@ -271,23 +271,23 @@
Depending on the solver now you have to apply the AffineConstraints::distribute() function to the solution, because the solver could change the constrained values in the solution. For a Krylov based solver this should not be strictly necessary, but it is still possible that there is a difference between the inhomogeneous value and the solution value in the order of machine precision, and you may want to call AffineConstraints::distribute() anyway if you have additional constraints such as from hanging nodes.
Of course, both approaches lead to the same final answer but in different ways. Using the first approach (i.e., when using use_inhomogeneities_for_rhs = false in AffineConstraints::distribute_local_to_global()), the linear system we build has zero entries in the right hand side in all those places where a degree of freedom is constrained, and some positive value on the matrix diagonal of these lines. Consequently, the solution vector of the linear system will have a zero value for inhomogeneously constrained degrees of freedom and we need to call AffineConstraints::distribute() to give these degrees of freedom their correct nonzero values.
-
On the other hand, in the second approach, the matrix diagonal element and corresponding right hand side entry for inhomogeneously constrained degrees of freedom are so that the solution of the linear system already has the correct value (e.g., if the constraint is that then row if the matrix is empty with the exception of the diagonal entry, and so that the solution of must satisfy as desired). As a consequence, we do not need to call AffineConstraints::distribute() after solving to fix up inhomogeneously constrained components of the solution, though there is also no harm in doing so.
+
On the other hand, in the second approach, the matrix diagonal element and corresponding right hand side entry for inhomogeneously constrained degrees of freedom are so that the solution of the linear system already has the correct value (e.g., if the constraint is that then row if the matrix is empty with the exception of the diagonal entry, and so that the solution of must satisfy as desired). As a consequence, we do not need to call AffineConstraints::distribute() after solving to fix up inhomogeneously constrained components of the solution, though there is also no harm in doing so.
There remains the question of which of the approaches to take and why we need to set to zero the values of the solution vector in the first approach. The answer to both questions has to do with how iterative solvers solve the linear system. To this end, consider that we typically stop iterations when the residual has dropped below a certain fraction of the norm of the right hand side, or, alternatively, a certain fraction of the norm of the initial residual. Now consider this:
In the first approach, the right hand side entries for constrained degrees of freedom are zero, i.e., the norm of the right hand side really only consists of those parts that we care about. On the other hand, if we start with a solution vector that is not zero in constrained entries, then the initial residual is very large because the value that is currently in the solution vector does not match the solution of the linear system (which is zero in these components). Thus, if we stop iterations once we have reduced the initial residual by a certain factor, we may reach the threshold after a single iteration because constrained degrees of freedom are resolved by iterative solvers in just one iteration. If the initial residual was dominated by these degrees of freedom, then we see a steep reduction in the first step although we did not really make much progress on the remainder of the linear system in this just one iteration. We can avoid this problem by either stopping iterations once the norm of the residual reaches a certain fraction of the norm of the right hand side, or we can set the solution components to zero (thus reducing the initial residual) and iterating until we hit a certain fraction of the norm of the initial residual.
In the second approach, we get the same problem if the starting vector in the iteration is zero, since then the residual may be dominated by constrained degrees of freedom having values that do not match the values we want for them at the solution. We can again circumvent this problem by setting the corresponding elements of the solution vector to their correct values, by calling AffineConstraints::distribute()before solving the linear system (and then, as necessary, a second time after solving).
-
In addition to these considerations, consider the case where we have inhomogeneous constraints of the kind , e.g., from a hanging node constraint of the form where is itself constrained by boundary values to . In this case, the AffineConstraints container can of course not figure out what the final value of should be and, consequently, can not set the solution vector's third component correctly. Thus, the second approach will not work and you should take the first.
+
In addition to these considerations, consider the case where we have inhomogeneous constraints of the kind , e.g., from a hanging node constraint of the form where is itself constrained by boundary values to . In this case, the AffineConstraints container can of course not figure out what the final value of should be and, consequently, can not set the solution vector's third component correctly. Thus, the second approach will not work and you should take the first.
Dealing with conflicting constraints
There are situations where degrees of freedom are constrained in more than one way, and sometimes in conflicting ways. Consider, for example the following situation:
-
Here, degree of freedom marked in blue is a hanging node. If we used trilinear finite elements, i.e. FE_Q(1), then it would carry the constraint . On the other hand, it is at the boundary, and if we have imposed boundary conditions then we will have the constraint where is the value of the boundary function at the location of this degree of freedom.
+
Here, degree of freedom marked in blue is a hanging node. If we used trilinear finite elements, i.e. FE_Q(1), then it would carry the constraint . On the other hand, it is at the boundary, and if we have imposed boundary conditions then we will have the constraint where is the value of the boundary function at the location of this degree of freedom.
So, which one will win? Or maybe: which one should win? There is no good answer to this question:
-
If the hanging node constraint is the one that is ultimately enforced, then the resulting solution does not satisfy boundary conditions any more for general boundary functions .
-
If it had been done the other way around, the solution would not satisfy hanging node constraints at this point and consequently would not satisfy the regularity properties of the element chosen (e.g. would not be continuous despite using a element).
-
The situation becomes completely hopeless if you consider curved boundaries since then the edge midpoint (i.e. the hanging node) does in general not lie on the mother edge. Consequently, the solution will not be conforming anyway, regardless of the priority of the two competing constraints. If the hanging node constraint wins, then the solution will be neither conforming, nor have the right boundary values. In other words, it is not entirely clear what the "correct" solution would be. In most cases, it will not matter much: in either case, the error introduced either by the non-conformity or the incorrect boundary values will be at worst at the same order as the discretization's overall error.
+
If the hanging node constraint is the one that is ultimately enforced, then the resulting solution does not satisfy boundary conditions any more for general boundary functions .
+
If it had been done the other way around, the solution would not satisfy hanging node constraints at this point and consequently would not satisfy the regularity properties of the element chosen (e.g. would not be continuous despite using a element).
+
The situation becomes completely hopeless if you consider curved boundaries since then the edge midpoint (i.e. the hanging node) does in general not lie on the mother edge. Consequently, the solution will not be conforming anyway, regardless of the priority of the two competing constraints. If the hanging node constraint wins, then the solution will be neither conforming, nor have the right boundary values. In other words, it is not entirely clear what the "correct" solution would be. In most cases, it will not matter much: in either case, the error introduced either by the non-conformity or the incorrect boundary values will be at worst at the same order as the discretization's overall error.
That said, what should you do if you know what you want is this:
If you want the hanging node constraints to win, then first build these through the DoFTools::make_hanging_node_constraints() function. Then interpolate the boundary values using VectorTools::interpolate_boundary_values() into the same AffineConstraints object. If the latter function encounters a boundary node that already is constrained, it will simply ignore the boundary values at this node and leave the constraint untouched.
Sometimes it is either not desirable, or not possible to directly condense, or eliminate constraints from a system of linear equations. In particular if there is no underlying matrix object that could be condensed (or taken care of constraints during assembly). This is usually the case if the system is described by a LinearOperator.
In this case we can solve the modified system
-
+\]" src="form_70.png"/>
instead [1] (M. S. Shephard. Linear multipoint constraints applied via transformation as part of a direct stiffness assembly process. International Journal for Numerical Methods in Engineering 20(11):2107-2112, 1985).
-
Here, is a given (unconstrained) system matrix for which we only assume that we can apply it to a vector but can not necessarily access individual matrix entries. is the corresponding right hand side of a system of linear equations . The matrix describes the homogeneous part of the linear constraints stored in an AffineConstraints object and the vector is the vector of corresponding inhomogeneities. More precisely, the AffineConstraints::distribute() operation applied on a vector is the operation
- is a given (unconstrained) system matrix for which we only assume that we can apply it to a vector but can not necessarily access individual matrix entries. is the corresponding right hand side of a system of linear equations . The matrix describes the homogeneous part of the linear constraints stored in an AffineConstraints object and the vector is the vector of corresponding inhomogeneities. More precisely, the AffineConstraints::distribute() operation applied on a vector is the operation
+
+\]" src="form_76.png"/>
-
And finally, denotes the identity on the subspace of constrained degrees of freedom.
-
The corresponding solution of that obeys these constraints is then recovered by distributing constraints: .
+
And finally, denotes the identity on the subspace of constrained degrees of freedom.
+
The corresponding solution of that obeys these constraints is then recovered by distributing constraints: .
The whole system can be set up and solved with the following snippet of code:
Compute which entries of a matrix built on the given dof_handler may possibly be nonzero, and create a sparsity pattern object that represents these nonzero locations.
-
This function computes the possible positions of non-zero entries in the global system matrix by simulating which entries one would write to during the actual assembly of a matrix. For this, the function assumes that each finite element basis function is non-zero on a cell only if its degree of freedom is associated with the interior, a face, an edge or a vertex of this cell. As a result, a matrix entry that is computed from two basis functions and with (global) indices and (for example, using a bilinear form ) can be non-zero only if these shape functions correspond to degrees of freedom that are defined on at least one common cell. Therefore, this function just loops over all cells, figures out the global indices of all degrees of freedom, and presumes that all matrix entries that couple any of these indices will result in a nonzero matrix entry. These will then be added to the sparsity pattern. As this process of generating the sparsity pattern does not take into account the equation to be solved later on, the resulting sparsity pattern is symmetric.
+
This function computes the possible positions of non-zero entries in the global system matrix by simulating which entries one would write to during the actual assembly of a matrix. For this, the function assumes that each finite element basis function is non-zero on a cell only if its degree of freedom is associated with the interior, a face, an edge or a vertex of this cell. As a result, a matrix entry that is computed from two basis functions and with (global) indices and (for example, using a bilinear form ) can be non-zero only if these shape functions correspond to degrees of freedom that are defined on at least one common cell. Therefore, this function just loops over all cells, figures out the global indices of all degrees of freedom, and presumes that all matrix entries that couple any of these indices will result in a nonzero matrix entry. These will then be added to the sparsity pattern. As this process of generating the sparsity pattern does not take into account the equation to be solved later on, the resulting sparsity pattern is symmetric.
This algorithm makes no distinction between shape functions on each cell, i.e., it simply couples all degrees of freedom on a cell with all other degrees of freedom on a cell. This is often the case, and always a safe assumption. However, if you know something about the structure of your operator and that it does not couple certain shape functions with certain test functions, then you can get a sparser sparsity pattern by calling a variant of the current function described below that allows to specify which vector components couple with which other vector components.
The method described above lives on the assumption that coupling between degrees of freedom only happens if shape functions overlap on at least one cell. This is the case with most usual finite element formulations involving conforming elements. However, for formulations such as the Discontinuous Galerkin finite element method, the bilinear form contains terms on interfaces between cells that couple shape functions that live on one cell with shape functions that live on a neighboring cell. The current function would not see these couplings, and would consequently not allocate entries in the sparsity pattern. You would then get into trouble during matrix assembly because you try to write into matrix entries for which no space has been allocated in the sparsity pattern. This can be avoided by calling the DoFTools::make_flux_sparsity_pattern() function instead, which takes into account coupling between degrees of freedom on neighboring cells.
There are other situations where bilinear forms contain non-local terms, for example in treating integral equations. These require different methods for building the sparsity patterns that depend on the exact formulation of the problem. You will have to do this yourself then.
@@ -448,13 +448,13 @@
This function is a simple variation on the previous make_sparsity_pattern() function (see there for a description of all of the common arguments), but it provides functionality for vector finite elements that allows to be more specific about which variables couple in which equation.
For example, if you wanted to solve the Stokes equations,
-
+\end{align*}" src="form_973.png"/>
-
in two space dimensions, using stable Q2/Q1 mixed elements (using the FESystem class), then you don't want all degrees of freedom to couple in each equation. More specifically, in the first equation, only and appear; in the second equation, only and appear; and in the third equation, only and appear. (Note that this discussion only talks about vector components of the solution variable and the different equation, and has nothing to do with degrees of freedom, or in fact with any kind of discretization.) We can describe this by the following pattern of "couplings":
+
in two space dimensions, using stable Q2/Q1 mixed elements (using the FESystem class), then you don't want all degrees of freedom to couple in each equation. More specifically, in the first equation, only and appear; in the second equation, only and appear; and in the third equation, only and appear. (Note that this discussion only talks about vector components of the solution variable and the different equation, and has nothing to do with degrees of freedom, or in fact with any kind of discretization.) We can describe this by the following pattern of "couplings":
-
+\]" src="form_976.png"/>
where "1" indicates that two variables (i.e., vector components of the FESystem) couple in the respective equation, and a "0" means no coupling. These zeros imply that upon discretization via a standard finite element formulation, we will not write entries into the matrix that, for example, couple pressure test functions with pressure shape functions (and similar for the other zeros above). It is then a waste to allocate memory for these entries in the matrix and the sparsity pattern, and you can avoid this by creating a mask such as the one above that describes this to the (current) function that computes the sparsity pattern. As stated above, the mask shown above refers to components of the composed FESystem, rather than to degrees of freedom or shape functions.
This function is designed to accept a coupling pattern, like the one shown above, through the couplings parameter, which contains values of type Coupling. It builds the matrix structure just like the previous function, but does not create matrix elements if not specified by the coupling pattern. If the couplings are symmetric, then so will be the resulting sparsity pattern.
Currently, this function may not work correctly for distributed data structures.
@@ -1259,27 +1259,27 @@
This function is an updated version of the project_boundary_values_curl_conforming function. The intention is to fix a problem when using the previous function in conjunction with non- rectangular geometries (i.e. elements with non-rectangular faces). The L2-projection method used has been taken from the paper "Electromagnetic
scattering simulation using an H (curl) conforming hp-finite element
method in three dimensions" by PD Ledger, K Morgan and O Hassan ( Int. J. Num. Meth. Fluids, Volume 53, Issue 8, pages 1267-1296).
-
This function will compute constraints that correspond to Dirichlet boundary conditions of the form i.e. the tangential components of and shall coincide.
+
This function will compute constraints that correspond to Dirichlet boundary conditions of the form i.e. the tangential components of and shall coincide.
Computing constraints
To compute the constraints we use a projection method based upon the paper mentioned above. In 2d this is done in a single stage for the edge- based shape functions, regardless of the order of the finite element. In 3d this is done in two stages, edges first and then faces.
-
For each cell, each edge, , is projected by solving the linear system where is the vector of constraints on degrees of freedom on the edge and
-
-
-
with the shape function and the tangent vector.
-
Once all edge constraints, , have been computed, we may compute the face constraints in a similar fashion, taking into account the residuals from the edges.
-
For each face on the cell, , we solve the linear system where is the vector of constraints on degrees of freedom on the face and
-
-
-
and , the edge residual.
-
The resulting constraints are then given in the solutions and .
+
For each cell, each edge, , is projected by solving the linear system where is the vector of constraints on degrees of freedom on the edge and
+
+
+
with the shape function and the tangent vector.
+
Once all edge constraints, , have been computed, we may compute the face constraints in a similar fashion, taking into account the residuals from the edges.
+
For each face on the cell, , we solve the linear system where is the vector of constraints on degrees of freedom on the face and
+
+
+
and , the edge residual.
+
The resulting constraints are then given in the solutions and .
If the AffineConstraintsconstraints contained values or other constraints before, the new ones are added or the old ones overwritten, if a node of the boundary part to be used was already in the list of constraints. This is handled by using inhomogeneous constraints. Please note that when combining adaptive meshes and this kind of constraints, the Dirichlet conditions should be set first, and then completed by hanging node constraints, in order to make sure that the discretization remains consistent. See the discussion on conflicting constraints in the module on Constraints on degrees of freedom.
Arguments to this function
This function is explicitly for use with FE_Nedelec elements, or with FESystem elements which contain FE_Nedelec elements. It will throw an exception if called with any other finite element. The user must ensure that FESystem elements are correctly setup when using this function as this check not possible in this case.
-
The second argument of this function denotes the first vector component of the finite element which corresponds to the vector function that you wish to constrain. For example, if we are solving Maxwell's equations in 3d and have components and we want the boundary conditions , then first_vector_component would be 3. The boundary_function must return 6 components in this example, with the first 3 corresponding to and the second 3 corresponding to . Vectors are implicitly assumed to have exactly dim components that are ordered in the same way as we usually order the coordinate directions, i.e. -, -, and finally -component.
+
The second argument of this function denotes the first vector component of the finite element which corresponds to the vector function that you wish to constrain. For example, if we are solving Maxwell's equations in 3d and have components and we want the boundary conditions , then first_vector_component would be 3. The boundary_function must return 6 components in this example, with the first 3 corresponding to and the second 3 corresponding to . Vectors are implicitly assumed to have exactly dim components that are ordered in the same way as we usually order the coordinate directions, i.e. -, -, and finally -component.
The parameter boundary_component corresponds to the number boundary_id of the face. numbers::internal_face_boundary_id is an illegal value, since it is reserved for interior faces.
-
The last argument is denoted to compute the normal vector at the boundary points.
+
The last argument is denoted to compute the normal vector at the boundary points.
Compute constraints that correspond to boundary conditions of the form , i.e. the normal components of the solution and a given shall coincide. The function is given by boundary_function and the resulting constraints are added to constraints for faces with boundary indicator boundary_component.
+
Compute constraints that correspond to boundary conditions of the form , i.e. the normal components of the solution and a given shall coincide. The function is given by boundary_function and the resulting constraints are added to constraints for faces with boundary indicator boundary_component.
This function is explicitly written to use with the FE_RaviartThomas elements. Thus it throws an exception, if it is called with other finite elements.
If the AffineConstraints object constraints contained values or other constraints before, the new ones are added or the old ones overwritten, if a node of the boundary part to be used was already in the list of constraints. This is handled by using inhomogeneous constraints. Please note that when combining adaptive meshes and this kind of constraints, the Dirichlet conditions should be set first, and then completed by hanging node constraints, in order to make sure that the discretization remains consistent. See the discussion on conflicting constraints in the module on Constraints on degrees of freedom.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/group__distributed.html differs (JavaScript source, ASCII text, with very long lines (1957))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/group__distributed.html 2023-11-25 15:26:00.096552561 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/group__distributed.html 2023-11-25 15:26:00.096552561 +0100
@@ -169,7 +169,7 @@
The only thing to pay attention to is for which degrees of freedom the sparsity needs to store entries. These are, in essence, the ones we could possibly store values to in the matrix upon assembly. It is clear that these are certainly the locally active degrees of freedom (which live on the cells we locally own) but through constraints, it may also be possible to write to entries that are located on ghost cells. Consequently, you need to pass the index set that results from DoFTools::extract_locally_relevant_dofs() upon initializing the sparsity pattern.
Constraints on degrees of freedom
When creating the sparsity pattern as well as when assembling the linear system, we need to know about constraints on degrees of freedom, for example resulting from hanging nodes or boundary conditions. Like the DynamicSparsityPattern class, the AffineConstraints container can also take an IndexSet upon construction that indicates for which of the possibly very large number of degrees of freedom it should actually store constraints. Unlike for the sparsity pattern, these are now only those degrees of freedom which we work on locally when assembling, namely those returned by DoFTools::extract_locally_active_dofs() (a superset of the locally owned ones).
-
There are, however, situations where more complicated constraints appear in finite element programs. An example is in adaptive computations where degrees of freedom can be constrained against other degrees of freedom that are themselves constrained. In a case like this, in order to fully resolve this chain of constraints, it may not be sufficient to only store constraints on locally active degrees of freedom but one may also need to have constraints available on locally relevant ones. In that case, the AffineConstraints object needs to be initialized with the IndexSet produced by DoFTools::extract_locally_relevant_dofs() .
+
There are, however, situations where more complicated constraints appear in finite element programs. An example is in adaptive computations where degrees of freedom can be constrained against other degrees of freedom that are themselves constrained. In a case like this, in order to fully resolve this chain of constraints, it may not be sufficient to only store constraints on locally active degrees of freedom but one may also need to have constraints available on locally relevant ones. In that case, the AffineConstraints object needs to be initialized with the IndexSet produced by DoFTools::extract_locally_relevant_dofs() .
In general, your program will continue to do something if you happen to not store all necessary constraints on each processor: you will just generate wrong matrix entries, but the program will not abort. This is opposed to the situation of the sparsity pattern: there, if the IndexSet passed to the DynamicSparsityPattern indicates that it should store too few rows of the matrix, the program will either abort when you attempt to write into matrix entries that do not exist or the matrix class will silently allocate more memory to accommodate them. As a consequence, it is useful to err on the side of caution when indicating which constraints to store and use the result of DoFTools::extract_locally_relevant_dofs() rather than DoFTools::extract_locally_active_dofs() . This is also affordable since the set of locally relevant degrees of freedom is only marginally larger than the set of locally active degrees of freedom. We choose this strategy in step-32, step-40, and step-55.
Postprocessing
Like everything else, you can only do postprocessing on cells a local processor owns. The DataOut and KellyErrorEstimator classes do this automatically: they only operate on locally owned cells without the need to do anything in particular. At least for large computations, there is also no way to merge the results of all these local computations on a single machine, i.e. each processor has to be self-sufficient. For example, each processor has to generate its own parallel output files that have to be visualized by a program that can deal with multiple input files rather than merging the results of calling DataOut to a single processor before generating a single output file. The latter can be achieved, for example, using the DataOutBase::write_vtu() and DataOutBase::write_pvtu_record() functions.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/group__hpcollection.html differs (JavaScript source, ASCII text, with very long lines (1032))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/group__hpcollection.html 2023-11-25 15:26:00.109885621 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/group__hpcollection.html 2023-11-25 15:26:00.109885621 +0100
@@ -116,7 +116,7 @@
* fe_collection.push_back (FE_Q<dim>(degree));
*
This way, one can add elements of polynomial degree 1 through 4 to the collection. It is not necessary to retain the added object: the collection makes a copy of it, it does not only store a pointer to the given finite element object. This same observation also holds for the other collection classes.
It is customary that within an hp-finite element program, one keeps collections of finite elements and quadrature formulas with the same number of elements, each element of the one collection matching the element in the other. This is not necessary, but it often makes coding a lot simpler. If a collection of mappings is used, the same holds for hp::MappingCollection objects as well.
-
Whenever p-adaptivity is considered in an hp-finite element program, a hierarchy of finite elements needs to be established to determine succeeding finite elements for refinement and preceding ones for coarsening. Typically, this hierarchy considers how finite element spaces are nested: for example, a element describes a sub-space of a element, and so doing refinement usually means using a larger (more accurate) finite element space. In other words, the hierarchy of finite elements is built by considering whether some elements of the collection are sub- or super-spaces of others.
+
Whenever p-adaptivity is considered in an hp-finite element program, a hierarchy of finite elements needs to be established to determine succeeding finite elements for refinement and preceding ones for coarsening. Typically, this hierarchy considers how finite element spaces are nested: for example, a element describes a sub-space of a element, and so doing refinement usually means using a larger (more accurate) finite element space. In other words, the hierarchy of finite elements is built by considering whether some elements of the collection are sub- or super-spaces of others.
By default, we assume that finite elements are stored in an ascending order based on their polynomial degree. If the order of elements differs, a corresponding hierarchy needs to be supplied to the collection via the hp::FECollection::set_hierarchy() member function.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/group__manifold.html differs (JavaScript source, ASCII text, with very long lines (1866))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/group__manifold.html 2023-11-25 15:26:00.126551951 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/group__manifold.html 2023-11-25 15:26:00.126551951 +0100
@@ -238,7 +238,7 @@
So why does this matter? After all, the last two meshes describe the exact same domain and we know that upon mesh refinement we obtain the correct solution regardless of the choice of cells, as long as the diameter of the largest cell goes to zero.
-
There are two answers to this question. First, the numerical effort of solving a partial differential equation to a certain accuracy typically depends on the quality of cells since the constant in error estimates of the form depends on factors such as the maximal ratio of radii of the smallest circumscribed to largest inscribed circle over all cells (for triangles; or a suitable generalization for other types of cells). Thus, it is worthwhile creating meshes with cells that are as well-formed as possible. This is arguably not so much of an issue for the meshes shown above, but is sometimes an issue. Consider, for example, the following code and mesh:
There are two answers to this question. First, the numerical effort of solving a partial differential equation to a certain accuracy typically depends on the quality of cells since the constant in error estimates of the form depends on factors such as the maximal ratio of radii of the smallest circumscribed to largest inscribed circle over all cells (for triangles; or a suitable generalization for other types of cells). Thus, it is worthwhile creating meshes with cells that are as well-formed as possible. This is arguably not so much of an issue for the meshes shown above, but is sometimes an issue. Consider, for example, the following code and mesh:
Computing the weights for combining different manifold descriptions
In a realistic application, it happens regularly that different manifold descriptions need to be combined. The simplest case is when a curved description is only available for the boundary but not for the interior of the computational domain. The manifold description for a ball also falls into this category, as it needs to combine a spherical manifold at the circular part with a straight-sided description in the center of the domain where the spherical manifold is not valid.
-
In general, the process of blending different manifold descriptions in deal.II is achieved by the so-called transfinite interpolation. Its formula in 2D is, for example, described on Wikipedia. Given a point on a chart, the image of this point in real space is given by
-Wikipedia. Given a point on a chart, the image of this point in real space is given by
+
+ \end{align*}" src="form_206.png"/>
-
where denote the four vertices bounding the image space and are the four curves describing the lines of the cell.
-
If we want to find the center of the cell according to the manifold (that is also used when the grid is refined), the chart is the unit cell and we want to evaluate this formula in the point . In that case, is the position of the midpoint of the lower face (indexed by 2 in deal.II's ordering) that is derived from its own manifold, is the position of the midpoint of the upper face (indexed by 3 in deal.II), is the midpoint of the face on the left (indexed by 0), and is the midpoint of the right face. In this formula, the weights equate to for the four midpoints in the faces and to for the four vertices. These weights look weird at first sight because the vertices enter with negative weight but the mechanism does what we want: In case of a cell with curved description on two opposite faces but straight lines on the other two faces, the negative weights of in the vertices balance with the center of the two straight lines in radial direction that get weight . Thus, the average is taken over the two center points in curved direction, exactly placing the new point in the middle.
-
In three spatial dimensions, the weights are for the face midpoints, for the line mid points, and for the vertices, again balancing the different entities. In case all the surrounding of a cell is straight, the formula reduces to the obvious weight on each of the eight vertices.
-
In the MappingQGeneric class, a generalization of this concept to the support points of a polynomial representation of curved cells, the nodes of the Gauss-Lobatto quadrature, is implemented by evaluating the boundary curves in the respective Gauss-Lobatto points and combining them with the above formula. The weights have been verified to yield optimal convergence rates also for very high polynomial degrees, say .
+
where denote the four vertices bounding the image space and are the four curves describing the lines of the cell.
+
If we want to find the center of the cell according to the manifold (that is also used when the grid is refined), the chart is the unit cell and we want to evaluate this formula in the point . In that case, is the position of the midpoint of the lower face (indexed by 2 in deal.II's ordering) that is derived from its own manifold, is the position of the midpoint of the upper face (indexed by 3 in deal.II), is the midpoint of the face on the left (indexed by 0), and is the midpoint of the right face. In this formula, the weights equate to for the four midpoints in the faces and to for the four vertices. These weights look weird at first sight because the vertices enter with negative weight but the mechanism does what we want: In case of a cell with curved description on two opposite faces but straight lines on the other two faces, the negative weights of in the vertices balance with the center of the two straight lines in radial direction that get weight . Thus, the average is taken over the two center points in curved direction, exactly placing the new point in the middle.
+
In three spatial dimensions, the weights are for the face midpoints, for the line mid points, and for the vertices, again balancing the different entities. In case all the surrounding of a cell is straight, the formula reduces to the obvious weight on each of the eight vertices.
+
In the MappingQGeneric class, a generalization of this concept to the support points of a polynomial representation of curved cells, the nodes of the Gauss-Lobatto quadrature, is implemented by evaluating the boundary curves in the respective Gauss-Lobatto points and combining them with the above formula. The weights have been verified to yield optimal convergence rates also for very high polynomial degrees, say .
In the literature, other boundary descriptions are also used. Before version 9.0 deal.II used something called Laplace smoothing where the weights that are applied to the nodes on the circumference to get the position of the interior nodes are determined by solving a Laplace equation on the unit element. However, this led to boundary layers close to the curved description, i.e., singularities in the higher derivatives of the mapping from unit to real cell.
If the transition from a curved boundary description to a straight description in the interior is done wrong, it is typically impossible to achieve high order convergence rates. For example, the Laplace smoothing inside a single cell leads to a singularity in the fourth derivative of the mapping from the reference to the real cell, limiting the convergence rate to 3 in the cells at the boundary (and 3.5 if global L2 errors were measured in 2D). Other more crude strategies, like completely ignoring the presence of two different manifolds and simply computing the additional points of a high-order mapping in a straight coordinate system, could lead to even worse convergence rates. The current implementation in deal.II, on the other hand, has been extensively verified in this respect and should behave optimally.
A bad strategy for blending a curved boundary representation with flat interior representations obviously also reflects mesh quality. For example, the above case with only 3 circumferential cells leads to the following mesh with Laplace manifold smoothing rather than the interpolation from the boundary as is implemented in deal.II:
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/group__mapping.html differs (JavaScript source, ASCII text, with very long lines (569))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/group__mapping.html 2023-11-25 15:26:00.139885011 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/group__mapping.html 2023-11-25 15:26:00.139885011 +0100
@@ -165,7 +165,7 @@
-
A class that implements a polynomial mapping of degree on all cells. This class is completely equivalent to the MappingQ class and there for backward compatibility.
+
A class that implements a polynomial mapping of degree on all cells. This class is completely equivalent to the MappingQ class and there for backward compatibility.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/group__matrixfree.html differs (JavaScript source, ASCII text, with very long lines (2603))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/group__matrixfree.html 2023-11-25 15:26:00.153218075 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/group__matrixfree.html 2023-11-25 15:26:00.153218075 +0100
@@ -140,7 +140,7 @@
Matrix-free methods skip the storage of big global sparse matrices and compute the underlying weak forms on the fly. Since the memory transfer, i.e., the speed at which the data can be read from RAM memory, is the bottleneck for matrix-based computations rather than the actual arithmetic done using this data, a matrix-free evaluation that reads less data can be advantageous even if it does more computations. This concept is building upon a trend in computer architecture which is best described by the term memory wall, saying that compute performance has increased more rapidly than the memory performance. Thus, a certain degree of arithmetic operations is essentially for free, and this share has become larger during the last twenty years. It has enabled this radical algorithm switch going from a matrix-based to a matrix-free implementation of matrix-vector products for iterative solvers, besides their classical use in explicit time integration. Of course, the implementation must be efficient and there cannot be an excess in computations to make it a win in total. The deal.II library uses SIMD vectorization and highly optimized kernels based on templates of the polynomial degree to achieve this goal. To give a perspective, a sparse matrix-vector product for quadratic elements FE_Q used to be equally fast as the matrix-free implementation on processors designed around 2005-2007 (e.g. Pentium 4 or AMD Opteron Barcelona with 2-4 cores per chip). By 2018, the matrix-free evaluation is around eight times as fast (measured on Intel Skylake Server, 14 cores).
-Matrix-free methods have a better complexity per degree of freedom as the degree is increased, due to sum factorization. The work per degree of freedom increases as in the degree for matrix-free schemes, whereas it increases as for matrix-based methods. This gives higher order schemes an edge. A particularly nice feature in matrix-free evaluation is that the terms often dominate, so it appears that higher order methods are as fast in terms of evaluation time as low order ones, when they have the same number of degrees of freedom. For the implementation in deal.II, best throughput is typically achieved for polynomial degrees between three and six.
+Matrix-free methods have a better complexity per degree of freedom as the degree is increased, due to sum factorization. The work per degree of freedom increases as in the degree for matrix-free schemes, whereas it increases as for matrix-based methods. This gives higher order schemes an edge. A particularly nice feature in matrix-free evaluation is that the terms often dominate, so it appears that higher order methods are as fast in terms of evaluation time as low order ones, when they have the same number of degrees of freedom. For the implementation in deal.II, best throughput is typically achieved for polynomial degrees between three and six.
To summarize, matrix-free computations are the way to go for higher order elements (where higher order means everything except linear shape functions) and use in explicit time stepping (step-48) or iterative solvers where also preconditioning can be done in a matrix-free way, as demonstrated in the step-37 and step-59 tutorial programs.
The matrix-free evaluation infrastructure
@@ -150,7 +150,7 @@
The motivation for the FEEvaluationAccess classes is to allow for specializations of the value and gradient access of interpolated solution fields depending on the number of components. Whereas the base class FEEvaluationBase returns the gradient as a Tensor<1,n_components,Tensor<1,dim,VectorizedArray<Number>>>, with the outer tensor going over the components and the inner tensor going through the dim components of the gradient. For a scalar field, i.e., n_components=1, we can skip the outer tensor and simply use Tensor<1,dim,VectorizedArray<Number>> as the gradient type. Likewise, for a system with n_components=dim, the appropriate format for the gradient is Tensor<2,dim,VectorizedArray<Number>>.
Face integrals, like for inhomogeneous Neumann conditions in continuous FEM or for the large class of discontinuous Galerkin schemes, require the evaluation of quantities on the quadrature point of a face, besides the cell integrals. The facilities for face evaluation are mostly shared with FEEvaluation, in the sense that FEFaceEvaluation also inherits from FEEvaluationAccess. All data fields regarding the degrees of freedom and shape functions can be reused, the latter because all information consists of 1D shape data anyway. With respect to the mapping data, however, a specialization is used because the data is of structdim=dim-1. As a consequence, the FEEvaluationAccess and FEEvaluationBase are given a template argument is_face to hold pointers to the cell and face mapping information, respectively. Besides access to the function values with FEEvaluationAccess::get_value() or gradients with FEEvaluationAccess::get_gradient(), the face evaluator also enables the access to the normal vector by FEEvaluationAccess::normal_vector() and a specialized field FEEvaluationAccess::get_normal_derivative(), which returns the derivative of the solution field normal to the face. This quantity is computed as the gradient (in real space) multiplied by the normal vector. The combination of the gradient and normal vector is typical of many (simple) second-order elliptic equations, such as the discretization of the Laplacian with the interior penalty method. If the gradient alone is not needed, the combined operation significantly reduces the data access, because only dim data entries for normal * Jacobian per quadrature point are necessary, as opposed to dim^2 fields for the Jacobian and dim fields for the normal when accessing them individually.
-
An important optimization for the computation of face integrals is to think about the amount of vector data that must be accessed to evaluate the integrals on a face. Think for example of the case of FE_DGQ, i.e., Lagrange polynomials that have some of their nodes on the element boundary. For evaluation of the function values, only degrees of freedom contribute via a non-zero basis function, whereas the rest of the basis functions evaluate to zero on that boundary. Since vector access is one of the bottlenecks in matrix-free computations, the access to the vector should be restricted to the interesting entries. To enable this setup, the method FEFaceEvaluation::gather_evaluate() (and FEFaceEvaluation::integrate_scatter() for the integration equivalent) combines the vector access with the interpolation to the quadrature points. There exist two specializations, including the aforementioned "non-zero" value case, which is stored as the field internal::MatrixFreeFunctions::ShapeInfo::nodal_at_cell_boundaries. A similar property is also possible for the case where only the value and the first derivative of a selected number of basis functions evaluate to nonzero on a face. The associated element type is FE_DGQHermite and the decision is stored on the property internal::MatrixFreeFunctions::tensor_symmetric_hermite. The decision on whether such an optimized kernel can be used is made automatically inside FEFaceEvaluation::gather_evaluate() and FEFaceEvaluation::integrate_scatter(). It might seem inefficient to do this decision for every integration task, but in the end this is a single if statement (conditional jump) that is easily predictable for a modern CPU as the decision is always the same inside an integration loop. (One only pays by somewhat increased compile times because the compiler needs to generate code for all paths, though).
+
An important optimization for the computation of face integrals is to think about the amount of vector data that must be accessed to evaluate the integrals on a face. Think for example of the case of FE_DGQ, i.e., Lagrange polynomials that have some of their nodes on the element boundary. For evaluation of the function values, only degrees of freedom contribute via a non-zero basis function, whereas the rest of the basis functions evaluate to zero on that boundary. Since vector access is one of the bottlenecks in matrix-free computations, the access to the vector should be restricted to the interesting entries. To enable this setup, the method FEFaceEvaluation::gather_evaluate() (and FEFaceEvaluation::integrate_scatter() for the integration equivalent) combines the vector access with the interpolation to the quadrature points. There exist two specializations, including the aforementioned "non-zero" value case, which is stored as the field internal::MatrixFreeFunctions::ShapeInfo::nodal_at_cell_boundaries. A similar property is also possible for the case where only the value and the first derivative of a selected number of basis functions evaluate to nonzero on a face. The associated element type is FE_DGQHermite and the decision is stored on the property internal::MatrixFreeFunctions::tensor_symmetric_hermite. The decision on whether such an optimized kernel can be used is made automatically inside FEFaceEvaluation::gather_evaluate() and FEFaceEvaluation::integrate_scatter(). It might seem inefficient to do this decision for every integration task, but in the end this is a single if statement (conditional jump) that is easily predictable for a modern CPU as the decision is always the same inside an integration loop. (One only pays by somewhat increased compile times because the compiler needs to generate code for all paths, though).
The main interface all these data structure adhere to is that integration tasks are broken down into a range of cells or faces that one can index into by a single integer index. The information about an integer range for the cell integrals, inner face integrals, and boundary integrals is provided by the class internal::MatrixFreeFunctions::TaskInfo, using the data fields cell_partition_data, face_partition_data, and boundary_partition_data. This class also contains information about subranges of indices for scheduling tasks in parallel using threads, and a grouping of the index range within {cell,face,boundary}_partition_data for interleaving cell and face integrals such that the access to vector entries for cell and face integrals re-uses data already in caches.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/group__reordering.html differs (JavaScript source, ASCII text, with very long lines (1334))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/group__reordering.html 2023-11-25 15:26:00.166551135 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/group__reordering.html 2023-11-25 15:26:00.166551135 +0100
@@ -168,7 +168,7 @@
From the examples above, it is obvious that if we encounter a cell that cannot be added to the cells which have already been entered, we can not usually point to a cell that is the culprit and that must be entered in a different orientation. Furthermore, even if we knew which cell, there might be large number of cells that would then cease to fit into the grid and which we would have to find a different orientation as well (in the second example above, if we rotated cell 1, then we would have to rotate the cells 1 through N-1 as well).
A brute force approach to this problem is the following: if cell N can't be added, then try to rotate cell N-1. If we can't rotate cell N-1 any more, then try to rotate cell N-2 and try to add cell N with all orientations of cell N-1. And so on. Algorithmically, we can visualize this by a tree structure, where node N has as many children as there are possible orientations of node N+1 (in two space dimensions, there are four orientations in which each cell can be constructed from its four vertices; for example, if the vertex indices are (0 1 3 2), then the four possibilities would be (0 1 3 2), (1 3 2 0), (3 2 0 1), and (2 0 1 3)). When adding one cell after the other, we traverse this tree in a depth-first (pre-order) fashion. When we encounter that one path from the root (cell 0) to a leaf (the last cell) is not allowed (i.e. that the orientations of the cells which are encoded in the path through the tree does not lead to a valid triangulation), we have to track back and try another path through the tree.
In practice, of course, we do not follow each path to a final node and then find out whether a path leads to a valid triangulation, but rather use an inductive argument: if for all previously added cells the triangulation is a valid one, then we can find out whether a path through the tree can yield a valid triangulation by checking whether entering the present cell would introduce any faces that have a nonunique direction; if that is so, then we can stop following all paths below this point and track back immediately.
-
Nevertheless, it is already obvious that the tree has leaves in two space dimensions, since each of the cells can be added in four orientations. Most of these nodes can be discarded rapidly, since firstly the orientation of the first cell is irrelevant, and secondly if we add one cell that has a neighbor that has already been added, then there are already only two possible orientations left, so the total number of checks we have to make until we find a valid way is significantly smaller than . However, the algorithm is still exponential in time and linear in memory (we only have to store the information for the present path in form of a stack of orientations of cells that have already been added).
+
Nevertheless, it is already obvious that the tree has leaves in two space dimensions, since each of the cells can be added in four orientations. Most of these nodes can be discarded rapidly, since firstly the orientation of the first cell is irrelevant, and secondly if we add one cell that has a neighbor that has already been added, then there are already only two possible orientations left, so the total number of checks we have to make until we find a valid way is significantly smaller than . However, the algorithm is still exponential in time and linear in memory (we only have to store the information for the present path in form of a stack of orientations of cells that have already been added).
In fact, the two examples above show that the exponential estimate is not a pessimistic one: we indeed have to track back to one of the very first cells there to find a way to add all cells in a consistent fashion.
This discouraging situation is greatly improved by the fact that we have an alternative algorithm for 2d that is always linear in runtime (discovered and implemented by Michael Anderson of TICAM, University of Texas, in 2003), and that for 3d we can find an algorithm that in practice is usually only roughly linear in time and memory. We will describe these algorithms in the following. A full description and theoretical analysis is given in [AABB17] .
The 2d linear complexity algorithm
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/group__threads.html differs (JavaScript source, ASCII text, with very long lines (1232))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/group__threads.html 2023-11-25 15:26:00.186550728 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/group__threads.html 2023-11-25 15:26:00.186550728 +0100
@@ -302,7 +302,7 @@
*out = function(*in_1, *in_2);
}
In many cases, function has no state, and so we can split this loop into several sub-ranges as explained above. Consequently, deal.II has a set of functions parallel::transform that look like the one above but that do their work in parallel (there are several versions with one, two, and more input iterators for function objects that take one, two, or more arguments). The only difference in calling these functions is that they take an additional last argument that denotes the minimum size of sub-ranges of [begin_in_1,end_in_1); it should be big enough so that we don't spend more time on scheduling sub-ranges to processors but small enough that processors can be efficiently load balanced. A rule of thumb appears to be that a sub-range is too small if it takes less than 2000 instructions to execute it.
-
An example of how to use these functions are vector operations like the addition in where all three objects are of type Vector<Number>:
In this example, we used a lambda expression to construct, on the fly, a function object that takes two arguments and returns the sum of the two. This is exactly what we needed when we want to add the individual elements of vectors and and write the sum of the two into the elements of . The function object that we get here is completely known to the compiler and when it expands the loop that results from parallel::transform will be as if we had written the loop in its obvious form:
InputIterator1 in_1 = x.begin();
+
In this example, we used a lambda expression to construct, on the fly, a function object that takes two arguments and returns the sum of the two. This is exactly what we needed when we want to add the individual elements of vectors and and write the sum of the two into the elements of . The function object that we get here is completely known to the compiler and when it expands the loop that results from parallel::transform will be as if we had written the loop in its obvious form:
Here, we call the vmult_on_subrange function on sub-ranges of at least 200 elements each, so that the initial setup cost can amortize.
-
A related operation is when the loops over elements each produce a result that must then be accumulated (other reduction operations than addition of numbers would work as well). An example is to form the matrix norm (it really is only a norm if is positive definite, but let's assume for a moment that it is). A sequential implementation would look like this for sparse matrices:
A related operation is when the loops over elements each produce a result that must then be accumulated (other reduction operations than addition of numbers would work as well). An example is to form the matrix norm (it really is only a norm if is positive definite, but let's assume for a moment that it is). A sequential implementation would look like this for sparse matrices:
The last issue that is worth addressing is that the way we wrote the MyClass::assemble_on_one_cell function above, we create and destroy an FEValues object every time the function is called, i.e. once for each cell in the triangulation. That's an immensely expensive operation because the FEValues class tries to do a lot of work in its constructor in an attempt to reduce the number of operations we have to do on each cell (i.e. it increases the constant in the effort to initialize such an object in order to reduce the constant in the operations to call FEValues::reinit on the cells of a triangulation). Creating and destroying an FEValues object on each cell invalidates this effort.
+
The last issue that is worth addressing is that the way we wrote the MyClass::assemble_on_one_cell function above, we create and destroy an FEValues object every time the function is called, i.e. once for each cell in the triangulation. That's an immensely expensive operation because the FEValues class tries to do a lot of work in its constructor in an attempt to reduce the number of operations we have to do on each cell (i.e. it increases the constant in the effort to initialize such an object in order to reduce the constant in the operations to call FEValues::reinit on the cells of a triangulation). Creating and destroying an FEValues object on each cell invalidates this effort.
The way to avoid this is to put the FEValues object into a second structure that will hold scratch data, and initialize it in the constructor:
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/group__vector__valued.html differs (JavaScript source, ASCII text, with very long lines (1296))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/group__vector__valued.html 2023-11-25 15:26:00.206550321 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/group__vector__valued.html 2023-11-25 15:26:00.206550321 +0100
@@ -280,8 +280,8 @@
\right)
\end{eqnarray*}" src="form_302.png"/>
-
indeed has four components. We note that we could change the ordering of the solution components and inside if we also change columns of the matrix operator.
-
Next, we need to think about test functions . We want to multiply both sides of the equation with them, then integrate over . The result should be a scalar equality. We can achieve this by choosing also vector valued as
+
indeed has four components. We note that we could change the ordering of the solution components and inside if we also change columns of the matrix operator.
+
Next, we need to think about test functions . We want to multiply both sides of the equation with them, then integrate over . The result should be a scalar equality. We can achieve this by choosing also vector valued as
-
These views can then be asked for information about these individual components. For example, when you write fe_values[pressure].value(i,q) you get the value of the pressure component of the th shape function at the th quadrature point. Because the extractor pressure represents a scalar component, the results of the operator fe_values[pressure].value(i,q) is a scalar number. On the other hand, the call fe_values[velocities].value(i,q) would produce the value of a whole set of dim components, which would be of type Tensor<1,dim>.
+
These views can then be asked for information about these individual components. For example, when you write fe_values[pressure].value(i,q) you get the value of the pressure component of the th shape function at the th quadrature point. Because the extractor pressure represents a scalar component, the results of the operator fe_values[pressure].value(i,q) is a scalar number. On the other hand, the call fe_values[velocities].value(i,q) would produce the value of a whole set of dim components, which would be of type Tensor<1,dim>.
So if, again, this is not the code we use in step-8, what do we do there? The answer rests on the finite element we use. In step-8, we use the following element:
In other words, the finite element we use consists of dim copies of the same scalar element. This is what we call a primitive element: an element that may be vector-valued but where each shape function has exactly one non-zero component. In other words: if the -component of a displacement shape function is nonzero, then the - and -components must be zero and similarly for the other components. What this means is that also derived quantities based on shape functions inherit this sparsity property. For example: the divergence primitive element: an element that may be vector-valued but where each shape function has exactly one non-zero component. In other words: if the -component of a displacement shape function is nonzero, then the - and -components must be zero and similarly for the other components. What this means is that also derived quantities based on shape functions inherit this sparsity property. For example: the divergence of a vector-valued shape function is, in the present case, either , , or , because exactly one of the is nonzero. Knowing this means that we can save a number of computations that, if we were to do them, would only yield zeros to add up.
In a similar vein, if only one component of a shape function is nonzero, then only one row of its gradient is nonzero. What this means for terms like , where the scalar product between two tensors is defined as , is that the term is only nonzero if both tensors have their nonzero entries in the same row, which means that the two shape functions have to have their single nonzero component in the same location.
-
If we use this sort of knowledge, then we can in a first step avoid computing gradient tensors if we can determine up front that their scalar product will be nonzero, in a second step avoid building the entire tensors and only get its nonzero components, and in a final step simplify the scalar product by only considering that index for the one nonzero row, rather than multiplying and adding up zeros.
+
If we use this sort of knowledge, then we can in a first step avoid computing gradient tensors if we can determine up front that their scalar product will be nonzero, in a second step avoid building the entire tensors and only get its nonzero components, and in a final step simplify the scalar product by only considering that index for the one nonzero row, rather than multiplying and adding up zeros.
The vehicle for all this is the ability to determine which vector component is going to be nonzero. This information is provided by the FiniteElement::system_to_component_index function. What can be done with it, using the example above, is explained in detail in step-8.
Block solvers
Using techniques as shown above, it isn't particularly complicated to assemble the linear system, i.e. matrix and right hand side, for a vector-valued problem. However, then it also has to be solved. This is more complicated. Naively, one could just consider the matrix as a whole. For most problems, this matrix is not going to be definite (except for special cases like the elasticity equations covered in step-8 and step-17). It will, often, also not be symmetric. This rather general class of matrices presents problems for iterative solvers: the lack of structural properties prevents the use of most efficient methods and preconditioners. While it can be done, the solution process will therefore most often be slower than necessary.
where represents the mass matrix that results from discretizing the identity operator and the equivalent of the gradient operator.
+
where represents the mass matrix that results from discretizing the identity operator and the equivalent of the gradient operator.
By default, this is not what happens, however. Rather, deal.II assigns numbers to degrees of freedom in a rather random manner. Consequently, if you form a vector out of the values of degrees of freedom will not be neatly ordered in a vector like
-
This has the advantage that the matrices and that we have to solve with are both symmetric and positive definite, as opposed to the large whole matrix we had before.
-
How a solver like this is implemented is explained in more detail in step-20, step-31, and a few other tutorial programs. What we would like to point out here is that we now need a way to extract certain parts of a matrix or vector: if we are to multiply, say, the part of the solution vector by the part of the global matrix, then we need to have a way to access these parts of the whole.
+
This has the advantage that the matrices and that we have to solve with are both symmetric and positive definite, as opposed to the large whole matrix we had before.
+
How a solver like this is implemented is explained in more detail in step-20, step-31, and a few other tutorial programs. What we would like to point out here is that we now need a way to extract certain parts of a matrix or vector: if we are to multiply, say, the part of the solution vector by the part of the global matrix, then we need to have a way to access these parts of the whole.
This is where the BlockVector, BlockSparseMatrix, and similar classes come in. For all practical purposes, then can be used as regular vectors or sparse matrices, i.e. they offer element access, provide the usual vector operations and implement, for example, matrix-vector multiplications. In other words, assembling matrices and right hand sides works in exactly the same way as for the non-block versions. That said, internally they store the elements of vectors and matrices in "blocks"; for example, instead of using one large array, the BlockVector class stores it as a set of arrays each of which we call a block. The advantage is that, while the whole thing can be used as a vector, one can also access an individual block which then, again, is a vector with all the vector operations.
To show how to do this, let us consider the second equation to be solved above. This can be achieved using the following sequence similar to what we have in step-20:
What's happening here is that we allocate a temporary vector with as many elements as the first block of the solution vector, i.e. the velocity component , has. We then set this temporary vector equal to the block of the matrix, i.e. , times component 1 of the solution which is the previously computed pressure . The result is multiplied by , and component 0 of the right hand side, is added to it. The temporary vector now contains . The rest of the code snippet simply solves a linear system with as right hand side and the block of the global matrix, i.e. . Using block vectors and matrices in this way therefore allows us to quite easily write rather complicated solvers making use of the block structure of a linear system.
+
What's happening here is that we allocate a temporary vector with as many elements as the first block of the solution vector, i.e. the velocity component , has. We then set this temporary vector equal to the block of the matrix, i.e. , times component 1 of the solution which is the previously computed pressure . The result is multiplied by , and component 0 of the right hand side, is added to it. The temporary vector now contains . The rest of the code snippet simply solves a linear system with as right hand side and the block of the global matrix, i.e. . Using block vectors and matrices in this way therefore allows us to quite easily write rather complicated solvers making use of the block structure of a linear system.
Extracting data from solutions
Once one has computed a solution, it is often necessary to evaluate it at quadrature points, for example to evaluate nonlinear residuals for the next Newton iteration, to evaluate the finite element residual for error estimators, or to compute the right hand side for the next time step in a time dependent problem.
The way this is done us to again use an FEValues object to evaluate the shape functions at quadrature points, and with those also the values of a finite element function. For the example of the mixed Laplace problem above, consider the following code after solving:
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/index.html differs (JavaScript source, ASCII text, with very long lines (886))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/index.html 2023-11-25 15:26:00.216550117 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/index.html 2023-11-25 15:26:00.216550117 +0100
@@ -117,7 +117,7 @@
DoFHandler: DoFHandler objects are the confluence of triangulations and finite elements: the finite element class describes how many degrees of freedom it needs per vertex, line, or cell, and the DoFHandler class allocates this space so that each vertex, line, or cell of the triangulation has the correct number of them. It also gives them a global numbering.
-
A different viewpoint is this: While the mesh and finite element describe abstract properties of the finite dimensional space in which we seek the discrete solution, the DoFHandler classes enumerate a concrete basis of this space so that we can represent the discrete solution as by an ordered set of coefficients .
+
A different viewpoint is this: While the mesh and finite element describe abstract properties of the finite dimensional space in which we seek the discrete solution, the DoFHandler classes enumerate a concrete basis of this space so that we can represent the discrete solution as by an ordered set of coefficients .
Just as with triangulation objects, most operations on DoFHandlers are done by looping over all cells and doing something on each or a subset of them. The interfaces of the two classes are therefore rather similar: they allow to get iterators to the first and last cell (or face, or line, etc) and offer information through these iterators. The information that can be gotten from these iterators is the geometric and topological information that can already be gotten from the triangulation iterators (they are in fact derived classes) as well as things like the global numbers of the degrees of freedom on the present cell. On can also ask an iterator to extract the values corresponding to the degrees of freedom on the present cell from a data vector that stores values for all degrees of freedom associated with a triangulation.
It is worth noting that, just as triangulations, DoFHandler classes do not know anything about the mapping from the unit cell to its individual cells. It is also ignorant of the shape functions that correspond to the degrees of freedom it manages: all it knows is that there are, for example, 2 degrees of freedom for each vertex and 4 per cell interior. Nothing about their specifics is relevant to the DoFHandler class with the exception of the fact that they exist.
The DoFHandler class and its associates are described in the Degrees of Freedom module. In addition, there are specialized versions that can handle multilevel and hp-discretizations. These are described in the Multilevel support and hp-finite element support modules. Finite element methods frequently imply constraints on degrees of freedom, such as for hanging nodes or nodes at which boundary conditions apply; dealing with such constraints is described in the Constraints on degrees of freedom module.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/index__set_8h.html differs (JavaScript source, ASCII text, with very long lines (420))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/index__set_8h.html 2023-11-25 15:26:00.229883182 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/index__set_8h.html 2023-11-25 15:26:00.229883182 +0100
@@ -145,7 +145,7 @@
-
Create and return an index set of size that contains every single index within this range. In essence, this function returns an index set created by
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/namespaceAdaptationStrategies_1_1Coarsening.html differs (JavaScript source, ASCII text, with very long lines (471))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/namespaceAdaptationStrategies_1_1Coarsening.html 2023-11-25 15:26:00.239882978 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/namespaceAdaptationStrategies_1_1Coarsening.html 2023-11-25 15:26:00.239882978 +0100
@@ -139,11 +139,11 @@
Check if data on all children match, and return value of the first child.
-
+\]" src="form_2146.png"/>
@@ -176,13 +176,13 @@
Return sum of data on all children.
-
+\]" src="form_2147.png"/>
-
This strategy preserves the -norm of the corresponding global data vector before and after adaptation.
+
This strategy preserves the -norm of the corresponding global data vector before and after adaptation.
@@ -212,15 +212,15 @@
-
Return -norm of data on all children.
+
Return -norm of data on all children.
-
+\]" src="form_2149.png"/>
-
This strategy preserves the -norm of the corresponding global data vector before and after adaptation.
+
This strategy preserves the -norm of the corresponding global data vector before and after adaptation.
@@ -252,11 +252,11 @@
Return mean value of data on all children.
-
+\]" src="form_2150.png"/>
@@ -289,11 +289,11 @@
Return maximum value of data on all children.
-
+\]" src="form_2151.png"/>
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/namespaceAdaptationStrategies_1_1Refinement.html differs (JavaScript source, ASCII text, with very long lines (457))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/namespaceAdaptationStrategies_1_1Refinement.html 2023-11-25 15:26:00.253216038 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/namespaceAdaptationStrategies_1_1Refinement.html 2023-11-25 15:26:00.249882775 +0100
@@ -135,11 +135,11 @@
Return a vector containing copies of data of the parent cell for each child.
-
+\]" src="form_2143.png"/>
@@ -172,13 +172,13 @@
Return a vector which contains data of the parent cell being equally divided among all children.
-
+\]" src="form_2144.png"/>
-
This strategy preserves the -norm of the corresponding global data Vector before and after adaptation.
+
This strategy preserves the -norm of the corresponding global data Vector before and after adaptation.
@@ -210,13 +210,13 @@
Return a vector which contains squared data of the parent cell being equally divided among the squares of all children.
-
+\]" src="form_2145.png"/>
-
This strategy preserves the -norm of the corresponding global data Vector before and after adaptation.
+
This strategy preserves the -norm of the corresponding global data Vector before and after adaptation.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/namespaceDataComponentInterpretation.html differs (JavaScript source, ASCII text, with very long lines (991))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/namespaceDataComponentInterpretation.html 2023-11-25 15:26:00.263215835 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/namespaceDataComponentInterpretation.html 2023-11-25 15:26:00.263215835 +0100
@@ -113,7 +113,7 @@
-
The members of this enum are used to describe the logical interpretation of what the various components of a vector-valued data set mean. For example, if one has a finite element for the Stokes equations in 2d, representing components , one would like to indicate that the first two, and , represent a logical vector so that later on when we generate graphical output we can hand them off to a visualization program that will automatically know to render them as a vector field, rather than as two separate and independent scalar fields.
+
The members of this enum are used to describe the logical interpretation of what the various components of a vector-valued data set mean. For example, if one has a finite element for the Stokes equations in 2d, representing components , one would like to indicate that the first two, and , represent a logical vector so that later on when we generate graphical output we can hand them off to a visualization program that will automatically know to render them as a vector field, rather than as two separate and independent scalar fields.
See the step-22 tutorial program for an example on how this information can be used in practice.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/namespaceDataOutBase.html differs (JavaScript source, ASCII text, with very long lines (1173))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/namespaceDataOutBase.html 2023-11-25 15:26:00.286548695 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/namespaceDataOutBase.html 2023-11-25 15:26:00.286548695 +0100
@@ -593,7 +593,7 @@
While this discussion applies to two spatial dimensions, it is more complicated in 3d. The reason is that we could still use patches, but it is difficult when trying to visualize them, since if we use a cut through the data (by, for example, using x- and z-coordinates, a fixed y-value and plot function values in z-direction, then the patched data is not a patch in the sense GNUPLOT wants it any more. Therefore, we use another approach, namely writing the data on the 3d grid as a sequence of lines, i.e. two points each associated with one or more data sets. There are therefore 12 lines for each subcells of a patch.
Given the lines as described above, a cut through this data in Gnuplot can then be achieved like this:
* set data style lines
* splot [:][:][0:] "T" using 1:2:(\$3==.5 ? \$4 : -1)
-*
This command plots data in - and -direction unbounded, but in -direction only those data points which are above the - -plane (we assume here a positive solution, if it has negative values, you might want to decrease the lower bound). Furthermore, it only takes the data points with z-values (&3) equal to 0.5, i.e. a cut through the domain at z=0.5. For the data points on this plane, the data values of the first data set (&4) are raised in z-direction above the x-y-plane; all other points are denoted the value -1 instead of the value of the data vector and are not plotted due to the lower bound in z plotting direction, given in the third pair of brackets.
+*
This command plots data in - and -direction unbounded, but in -direction only those data points which are above the - -plane (we assume here a positive solution, if it has negative values, you might want to decrease the lower bound). Furthermore, it only takes the data points with z-values (&3) equal to 0.5, i.e. a cut through the domain at z=0.5. For the data points on this plane, the data values of the first data set (&4) are raised in z-direction above the x-y-plane; all other points are denoted the value -1 instead of the value of the data vector and are not plotted due to the lower bound in z plotting direction, given in the third pair of brackets.
More complex cuts are possible, including nonlinear ones. Note however, that only those points which are actually on the cut-surface are plotted.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/namespaceDerivativeApproximation.html differs (JavaScript source, ASCII text, with very long lines (1600))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/namespaceDerivativeApproximation.html 2023-11-25 15:26:00.299881757 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/namespaceDerivativeApproximation.html 2023-11-25 15:26:00.299881757 +0100
@@ -118,17 +118,17 @@
Detailed Description
This namespace provides functions that compute a cell-wise approximation of the norm of a derivative of a finite element field by taking difference quotients between neighboring cells. This is a rather simple but efficient form to get an error indicator, since it can be computed with relatively little numerical effort and yet gives a reasonable approximation.
-
The way the difference quotients are computed on cell is the following (here described for the approximation of the gradient of a finite element field, but see below for higher derivatives): let be a neighboring cell, and let be the distance vector between the centers of the two cells, then is an approximation of the directional derivative By multiplying both terms by from the left and summing over all neighbors , we obtain is the following (here described for the approximation of the gradient of a finite element field, but see below for higher derivatives): let be a neighboring cell, and let be the distance vector between the centers of the two cells, then is an approximation of the directional derivative By multiplying both terms by from the left and summing over all neighbors , we obtain
-
Thus, if the matrix is regular (which is the case when the vectors to all neighbors span the whole space), we can obtain an approximation to the true gradient by
+
Thus, if the matrix is regular (which is the case when the vectors to all neighbors span the whole space), we can obtain an approximation to the true gradient by This is a quantity that is easily computed. The value returned for each cell when calling the approximate_gradient function of this class is the norm of this approximation to the gradient. To make this a useful quantity, you may want to scale each element by the correct power of the respective cell size.
-
The computation of this quantity must fail if a cell has only neighbors for which the direction vectors do not span the whole space, since then the matrix is no longer invertible. If this happens, you will get an error similar to this one:
+\|y_{K'}\| } \right).$" src="form_2171.png"/> This is a quantity that is easily computed. The value returned for each cell when calling the approximate_gradient function of this class is the norm of this approximation to the gradient. To make this a useful quantity, you may want to scale each element by the correct power of the respective cell size.
+
The computation of this quantity must fail if a cell has only neighbors for which the direction vectors do not span the whole space, since then the matrix is no longer invertible. If this happens, you will get an error similar to this one:
As can easily be verified, this can only happen on very coarse grids, when some cells and all their neighbors have not been refined even once. You should therefore only call the functions of this class if all cells are at least once refined. In practice this is not much of a restriction.
Approximation of higher derivatives
-
Similar to the reasoning above, approximations to higher derivatives can be computed in a similar fashion. For example, the tensor of second derivatives is approximated by the formula where denotes the outer product of two vectors. Note that unlike the true tensor of second derivatives, its approximation is not necessarily symmetric. This is due to the fact that in the derivation, it is not clear whether we shall consider as projected second derivative the term or . Depending on which choice we take, we obtain one approximation of the tensor of second derivatives or its transpose. To avoid this ambiguity, as result we take the symmetrized form, which is the mean value of the approximation and its transpose.
-
The returned value on each cell is the spectral norm of the approximated tensor of second derivatives, i.e. the largest eigenvalue by absolute value. This equals the largest curvature of the finite element field at each cell, and the spectral norm is the matrix norm associated to the vector norm.
+- \nabla u_h(x_K)}{ \|y_{K'}\| } \right), $" src="form_2173.png"/> where denotes the outer product of two vectors. Note that unlike the true tensor of second derivatives, its approximation is not necessarily symmetric. This is due to the fact that in the derivation, it is not clear whether we shall consider as projected second derivative the term or . Depending on which choice we take, we obtain one approximation of the tensor of second derivatives or its transpose. To avoid this ambiguity, as result we take the symmetrized form, which is the mean value of the approximation and its transpose.
+
The returned value on each cell is the spectral norm of the approximated tensor of second derivatives, i.e. the largest eigenvalue by absolute value. This equals the largest curvature of the finite element field at each cell, and the spectral norm is the matrix norm associated to the vector norm.
Even higher than the second derivative can be obtained along the same lines as exposed above.
Refinement indicators based on the derivatives
-
If you would like to base a refinement criterion upon these approximation of the derivatives, you will have to scale the results of this class by an appropriate power of the mesh width. For example, since , it might be the right thing to scale the indicators as , i.e. , i.e. the right power is .
+
If you would like to base a refinement criterion upon these approximation of the derivatives, you will have to scale the results of this class by an appropriate power of the mesh width. For example, since , it might be the right thing to scale the indicators as , i.e. , i.e. the right power is .
Likewise, for the second derivative, one should choose a power of the mesh size one higher than for the gradient.
Implementation
-
The formulae for the computation of approximations to the gradient and to the tensor of second derivatives shown above are very much alike. The basic difference is that in one case the finite difference quotient is a scalar, while in the other case it is a vector. For higher derivatives, this would be a tensor of even higher rank. We then have to form the outer product of this difference quotient with the distance vector , symmetrize it, contract it with the matrix and compute its norm. To make the implementation simpler and to allow for code reuse, all these operations that are dependent on the actual order of the derivatives to be approximated, as well as the computation of the quantities entering the difference quotient, have been separated into auxiliary nested classes (names Gradient and SecondDerivative) and the main algorithm is simply passed one or the other data types and asks them to perform the order dependent operations. The main framework that is independent of this, such as finding all active neighbors, or setting up the matrix is done in the main function approximate.
+
The formulae for the computation of approximations to the gradient and to the tensor of second derivatives shown above are very much alike. The basic difference is that in one case the finite difference quotient is a scalar, while in the other case it is a vector. For higher derivatives, this would be a tensor of even higher rank. We then have to form the outer product of this difference quotient with the distance vector , symmetrize it, contract it with the matrix and compute its norm. To make the implementation simpler and to allow for code reuse, all these operations that are dependent on the actual order of the derivatives to be approximated, as well as the computation of the quantities entering the difference quotient, have been separated into auxiliary nested classes (names Gradient and SecondDerivative) and the main algorithm is simply passed one or the other data types and asks them to perform the order dependent operations. The main framework that is independent of this, such as finding all active neighbors, or setting up the matrix is done in the main function approximate.
Due to this way of operation, the class may be easily extended for higher order derivatives than are presently implemented. Basically, only an additional class along the lines of the derivative descriptor classes Gradient and SecondDerivative has to be implemented, with the respective alias and functions replaced by the appropriate analogues for the derivative that is to be approximated.
Function Documentation
@@ -293,7 +293,7 @@
-
This function is the analogue to the one above, computing finite difference approximations of the tensor of second derivatives. Pass it the DoF handler object that describes the finite element field, a nodal value vector, and receive the cell-wise spectral norm of the approximated tensor of second derivatives. The spectral norm is the matrix norm associated to the vector norm.
+
This function is the analogue to the one above, computing finite difference approximations of the tensor of second derivatives. Pass it the DoF handler object that describes the finite element field, a nodal value vector, and receive the cell-wise spectral norm of the approximated tensor of second derivatives. The spectral norm is the matrix norm associated to the vector norm.
The last parameter denotes the solution component, for which the gradient is to be computed. It defaults to the first component. For scalar elements, this is the only valid choice; for vector-valued ones, any component between zero and the number of vector components can be given here.
In a parallel computation the solution vector needs to contain the locally relevant unknowns.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/namespaceDifferentiation_1_1SD.html differs (JavaScript source, ASCII text, with very long lines (690))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/namespaceDifferentiation_1_1SD.html 2023-11-25 15:26:00.346547474 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/namespaceDifferentiation_1_1SD.html 2023-11-25 15:26:00.346547474 +0100
@@ -666,7 +666,7 @@
-
Return a symbolic number that represents the Euler constant raised to the given exponent.
+
Return a symbolic number that represents the Euler constant raised to the given exponent.
Mimics the function std::exp(exponent) using the standard math library.
Return an Expression representing a scalar symbolic variable with the identifier specified by symbol.
-
For example, if the symbol is the string "x" then the scalar symbolic variable that is returned represents the scalar .
+
For example, if the symbol is the string "x" then the scalar symbolic variable that is returned represents the scalar .
Parameters
[in]
symbol
An identifier (or name) for the returned symbolic variable.
@@ -2933,7 +2933,7 @@
Return an Expression representing a scalar symbolic function with the identifier specified by symbol. The function's symbolic dependencies are specified by the input arguments.
-
For example, if the symbol is the string "f", and the arguments to the function that is generated are the symbolic variable x and the symbolic expression y+z, then the generic symbolic function that is returned represents .
+
For example, if the symbol is the string "f", and the arguments to the function that is generated are the symbolic variable x and the symbolic expression y+z, then the generic symbolic function that is returned represents .
Parameters
[in]
symbol
An identifier (or name) for the returned symbolic function.
@@ -2971,7 +2971,7 @@
Return an Expression representing a scalar symbolic function with the identifier specified by symbol. The function's symbolic dependencies are specified by the keys to the input arguments map; the values stored in the map are ignored.
-
For example, if the symbol is the string "f", and the arguments to the function that is generated are the symbolic variable x and the symbolic expression y+z, then the generic symbolic function that is returned represents .
+
For example, if the symbol is the string "f", and the arguments to the function that is generated are the symbolic variable x and the symbolic expression y+z, then the generic symbolic function that is returned represents .
Parameters
[in]
symbol
An identifier (or name) for the returned symbolic function.
@@ -3015,7 +3015,7 @@
-
Returns
The symbolic function or expression representing the result .
+
Returns
The symbolic function or expression representing the result .
Return a substitution map that has any explicit interdependencies between the entries of the input substitution_map resolved.
The force_cyclic_dependency_resolution flag exists to ensure, if desired, that no cyclic dependencies can exist in the returned map. If a cyclic dependency exists in the input substitution map, substitution_map, then with this flag set to true the dependency cycle is broken by a dictionary-ordered substitution. For example, if the substitution map contains two entries map["a"] -> "b" and map["b"] -> "a", then the result of calling this function would be a map with the elements map["a"] -> "a" and map["b"] -> "a".
If one symbol is an explicit function of another, and it is desired that all their values are completely resolved, then it may be necessary to perform substitution a number of times before the result is finalized. This function performs substitution sweeps for a set of symbolic variables until all explicit relationships between the symbols in the map have been resolved. Whether each entry returns a symbolic or real value depends on the nature of the values stored in the substitution map. If the values associated with a key are also symbolic then the returned result may still be symbolic in nature. The terminal result of using the input substitution map, symbol_values, is then guaranteed to be rendered by a single substitution of the returned dependency-resolved map.
-
Example: If map["a"] -> 1 and map["b"] -> "a"+ 2, then the function will be evaluated and the result is determined upon the completion of the first sweep. A second sweep is therefore necessary to resolve the final symbol, and the returned value is ultimately . By resolving the explicit relationships between all symbols in the map, we determine that map["a"] -> 1 and map["b"] -> 1 + 2 = 3 and thus, using only one substitution, that .
+
Example: If map["a"] -> 1 and map["b"] -> "a"+ 2, then the function will be evaluated and the result is determined upon the completion of the first sweep. A second sweep is therefore necessary to resolve the final symbol, and the returned value is ultimately . By resolving the explicit relationships between all symbols in the map, we determine that map["a"] -> 1 and map["b"] -> 1 + 2 = 3 and thus, using only one substitution, that .
@@ -4345,11 +4345,11 @@
If the symbols stored in the map are explicitly dependent on one another, then the returned result depends on the order in which the map is traversed. It is recommended to first resolve all interdependencies in the map using the resolve_explicit_dependencies() function.
Examples:
-
If map["a"] == 1 and map["b"] == "a" + 2, then the function will be evaluated and the result is returned. This return is because the symbol "a" is substituted throughout the function first, and only then is the symbol "b(a)" substituted, by which time its explicit dependency on "a" cannot be resolved.
+
If map["a"] == 1 and map["b"] == "a" + 2, then the function will be evaluated and the result is returned. This return is because the symbol "a" is substituted throughout the function first, and only then is the symbol "b(a)" substituted, by which time its explicit dependency on "a" cannot be resolved.
-If map["a"] == "b"+2 and map["b"] == 1, then the function will be evaluated and the result is returned. This is because the explicitly dependent symbol "a(b)" is substituted first followed by the symbol "b".
+If map["a"] == "b"+2 and map["b"] == 1, then the function will be evaluated and the result is returned. This is because the explicitly dependent symbol "a(b)" is substituted first followed by the symbol "b".
@@ -4531,7 +4531,7 @@
Return a vector of Expressions representing a vectorial symbolic variable with the identifier specified by symbol.
-
For example, if the symbol is the string "v" then the vectorial symbolic variable that is returned represents the vector . Each component of is prefixed by the given symbol, and has a suffix that indicates its component index.
+
For example, if the symbol is the string "v" then the vectorial symbolic variable that is returned represents the vector . Each component of is prefixed by the given symbol, and has a suffix that indicates its component index.
Template Parameters
dim
The dimension of the returned tensor.
@@ -4568,7 +4568,7 @@
Return a tensor of Expressions representing a tensorial symbolic variable with the identifier specified by symbol.
-
For example, if the symbol is the string "T" then the tensorial symbolic variable that is returned represents the vector . Each component of is prefixed by the given symbol, and has a suffix that indicates its component indices.
+
For example, if the symbol is the string "T" then the tensorial symbolic variable that is returned represents the vector . Each component of is prefixed by the given symbol, and has a suffix that indicates its component indices.
Template Parameters
rank
The rank of the returned tensor.
@@ -4797,7 +4797,7 @@
-
Returns
The tensor of symbolic functions or expressions representing the result .
+
Returns
The tensor of symbolic functions or expressions representing the result .
@@ -4834,7 +4834,7 @@
-
Returns
The symmetric tensor of symbolic functions or expressions representing the result .
+
Returns
The symmetric tensor of symbolic functions or expressions representing the result .
@@ -4871,7 +4871,7 @@
-
Returns
The tensor of symbolic functions or expressions representing the result .
+
Returns
The tensor of symbolic functions or expressions representing the result .
@@ -4908,7 +4908,7 @@
-
Returns
The symmetric tensor of symbolic functions or expressions representing the result .
+
Returns
The symmetric tensor of symbolic functions or expressions representing the result .
@@ -4945,7 +4945,7 @@
-
Returns
The tensor of symbolic functions or expressions representing the result .
+
Returns
The tensor of symbolic functions or expressions representing the result .
@@ -4982,7 +4982,7 @@
-
Returns
The symmetric tensor of symbolic functions or expressions representing the result .
+
Returns
The symmetric tensor of symbolic functions or expressions representing the result .
@@ -5019,7 +5019,7 @@
-
Returns
The tensor of symbolic functions or expressions representing the result .
+
Returns
The tensor of symbolic functions or expressions representing the result .
@@ -5056,7 +5056,7 @@
-
Returns
The symmetric tensor of symbolic functions or expressions representing the result .
+
Returns
The symmetric tensor of symbolic functions or expressions representing the result .
@@ -5093,8 +5093,8 @@
-
Returns
The tensor of symbolic functions or variables representing the result .
+
Returns
The tensor of symbolic functions or variables representing the result .
@@ -5131,8 +5131,8 @@
-
Returns
The symmetric tensor of symbolic functions or variables representing the result .
+
Returns
The symmetric tensor of symbolic functions or variables representing the result .
@@ -5169,7 +5169,7 @@
-
Returns
The tensor of symbolic functions or variables representing the result .
+
Returns
The tensor of symbolic functions or variables representing the result .
@@ -5206,7 +5206,7 @@
-
Returns
The tensor of symbolic functions or variables representing the result .
+
Returns
The tensor of symbolic functions or variables representing the result .
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/namespaceDoFRenumbering.html differs (JavaScript source, ASCII text, with very long lines (1206))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/namespaceDoFRenumbering.html 2023-11-25 15:26:00.373213599 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/namespaceDoFRenumbering.html 2023-11-25 15:26:00.373213599 +0100
@@ -226,13 +226,13 @@
Using the constraint information usually leads to reductions in bandwidth of 10 or 20 per cent, but may for some very unstructured grids also lead to an increase. You have to weigh the decrease in your case with the time spent to use the constraint information, which usually is several times longer than the ‘pure’ renumbering algorithm.
In almost all cases, the renumbering scheme finds a corner to start with. Since there is more than one corner in most grids and since even an interior degree of freedom may be a better starting point, giving the starting point by the user may be a viable way if you have a simple scheme to derive a suitable point (e.g. by successively taking the third child of the cell top left of the coarsest level, taking its third vertex and the dof index thereof, if you want the top left corner vertex). If you do not know beforehand what your grid will look like (e.g. when using adaptive algorithms), searching a best starting point may be difficult, however, and in many cases will not justify the effort.
Component-wise and block-wise numberings
-
For finite elements composed of several base elements using the FESystem class, or for elements which provide several components themselves, it may be of interest to sort the DoF indices by component. This will then bring out the block matrix structure, since otherwise the degrees of freedom are numbered cell-wise without taking into account that they may belong to different components. For example, one may want to sort degree of freedom for a Stokes discretization so that we first get all velocities and then all the pressures so that the resulting matrix naturally decomposes into a system.
+
For finite elements composed of several base elements using the FESystem class, or for elements which provide several components themselves, it may be of interest to sort the DoF indices by component. This will then bring out the block matrix structure, since otherwise the degrees of freedom are numbered cell-wise without taking into account that they may belong to different components. For example, one may want to sort degree of freedom for a Stokes discretization so that we first get all velocities and then all the pressures so that the resulting matrix naturally decomposes into a system.
This kind of numbering may be obtained by calling the component_wise() function of this class. Since it does not touch the order of indices within each component, it may be worthwhile to first renumber using the Cuthill- McKee or a similar algorithm and afterwards renumbering component-wise. This will bring out the matrix structure and additionally have a good numbering within each block.
The component_wise() function allows not only to honor enumeration based on vector components, but also allows to group together vector components into "blocks" using a defaulted argument to the various DoFRenumbering::component_wise() functions (see GlossComponent vs GlossBlock for a description of the difference). The blocks designated through this argument may, but do not have to be, equal to the blocks that the finite element reports. For example, a typical Stokes element would be
This element has dim+1 vector components and equally many blocks. However, one may want to consider the velocities as one logical block so that all velocity degrees of freedom are enumerated the same way, independent of whether they are - or -velocities. This is done, for example, in step-20 and step-22 as well as several other tutorial programs.
+
This element has dim+1 vector components and equally many blocks. However, one may want to consider the velocities as one logical block so that all velocity degrees of freedom are enumerated the same way, independent of whether they are - or -velocities. This is done, for example, in step-20 and step-22 as well as several other tutorial programs.
On the other hand, if you really want to use block structure reported by the finite element itself (a case that is often the case if you have finite elements that have multiple vector components, e.g. the FE_RaviartThomas or FE_Nedelec elements) then you can use the DoFRenumbering::block_wise instead of the DoFRenumbering::component_wise functions.
Cell-wise numbering
Given an ordered vector of cells, the function cell_wise() sorts the degrees of freedom such that degrees on earlier cells of this vector will occur before degrees on later cells.
@@ -245,7 +245,7 @@
The MatrixFree class provides optimized algorithms for interleaving operations on vectors before and after the access of the vector data in the respective loops. The algorithm matrix_free_data_locality() makes sure that all unknowns with a short distance between the first and last access are grouped together, in order to increase the spatial data locality.
A comparison of reordering strategies
As a benchmark of comparison, let us consider what the different sparsity patterns produced by the various algorithms when using the element combination typically employed in the discretization of Stokes equations, when used on the mesh obtained in step-22 after one adaptive mesh refinement in 3d. The space dimension together with the coupled finite element leads to a rather dense system matrix with, on average around 180 nonzero entries per row. After applying each of the reordering strategies shown below, the degrees of freedom are also sorted using DoFRenumbering::component_wise into velocity and pressure groups; this produces the block structure seen below with the large velocity-velocity block at top left, small pressure-pressure block at bottom right, and coupling blocks at top right and bottom left.
+Q_1$" src="form_951.png"/> element combination typically employed in the discretization of Stokes equations, when used on the mesh obtained in step-22 after one adaptive mesh refinement in 3d. The space dimension together with the coupled finite element leads to a rather dense system matrix with, on average around 180 nonzero entries per row. After applying each of the reordering strategies shown below, the degrees of freedom are also sorted using DoFRenumbering::component_wise into velocity and pressure groups; this produces the block structure seen below with the large velocity-velocity block at top left, small pressure-pressure block at bottom right, and coupling blocks at top right and bottom left.
The goal of reordering strategies is to improve the preconditioner. In step-22 we use a SparseILU to preconditioner for the velocity-velocity block at the top left. The quality of the preconditioner can then be measured by the number of CG iterations required to solve a linear system with this block. For some of the reordering strategies below we record this number for adaptive refinement cycle 3, with 93176 degrees of freedom; because we solve several linear systems with the same matrix in the Schur complement, the average number of iterations is reported. The lower the number the better the preconditioner and consequently the better the renumbering of degrees of freedom is suited for this task. We also state the run-time of the program, in part determined by the number of iterations needed, for the first 4 cycles on one of our machines. Note that the reported times correspond to the run time of the entire program, not just the affected solver; if a program runs twice as fast with one particular ordering than with another one, then this means that the actual solver is actually several times faster.
@@ -473,7 +473,7 @@
const std::vector< unsigned int > &&#href_anchor"paramname">target_component = std::vector<unsigned int>()&#href_anchor"memdoc">
-
Sort the degrees of freedom by vector component. The numbering within each component is not touched, so a degree of freedom with index , belonging to some component, and another degree of freedom with index belonging to the same component will be assigned new indices and with if and if .
+
Sort the degrees of freedom by vector component. The numbering within each component is not touched, so a degree of freedom with index , belonging to some component, and another degree of freedom with index belonging to the same component will be assigned new indices and with if and if .
You can specify that the components are ordered in a different way than suggested by the FESystem object you use. To this end, set up the vector target_component such that the entry at index i denotes the number of the target component for dofs with component i in the FESystem. Naming the same target component more than once is possible and results in a blocking of several components into one. This is discussed in step-22. If you omit this argument, the same order as given by the finite element is used.
If one of the base finite elements from which the global finite element under consideration here, is a non-primitive one, i.e. its shape functions have more than one non-zero component, then it is not possible to associate these degrees of freedom with a single vector component. In this case, they are associated with the first vector component to which they belong.
For finite elements with only one component, or a single non-primitive base element, this function is the identity operation.
@@ -575,7 +575,7 @@
-
Sort the degrees of freedom by vector block. The numbering within each block is not touched, so a degree of freedom with index , belonging to some block, and another degree of freedom with index belonging to the same block will be assigned new indices and with if and if .
+
Sort the degrees of freedom by vector block. The numbering within each block is not touched, so a degree of freedom with index , belonging to some block, and another degree of freedom with index belonging to the same block will be assigned new indices and with if and if .
Note
This function only succeeds if each of the elements in the hp::FECollection attached to the DoFHandler argument has exactly the same number of blocks (see the glossary for more information). Note that this is not always given: while the hp::FECollection class ensures that all of its elements have the same number of vector components, they need not have the same number of blocks. At the same time, this function here needs to match individual blocks across elements and therefore requires that elements have the same number of blocks and that subsequent blocks in one element have the same meaning as in another element.
For meshes based on parallel::distributed::Triangulation, the locally owned cells of each MPI process are contiguous in Z order. That means that numbering degrees of freedom by visiting cells in Z order yields locally owned DoF indices that consist of contiguous ranges for each process. This is also true for the default ordering of DoFs on such triangulations, but the default ordering creates an enumeration that also depends on how many processors participate in the mesh, whereas the one generated by this function enumerates the degrees of freedom on a particular cell with indices that will be the same regardless of how many processes the mesh is split up between.
For meshes based on parallel::shared::Triangulation, the situation is more complex. Here, the set of locally owned cells is determined by a partitioning algorithm (selected by passing an object of type parallel::shared::Triangulation::Settings to the constructor of the triangulation), and in general these partitioning algorithms may assign cells to subdomains based on decisions that may have nothing to do with the Z order. (Though it is possible to select these flags in a way so that partitioning uses the Z order.) As a consequence, the cells of one subdomain are not contiguous in Z order, and if one renumbered degrees of freedom based on the Z order of cells, one would generally end up with DoF indices that on each processor do not form a contiguous range. This is often inconvenient (for example, because PETSc cannot store vectors and matrices for which the locally owned set of indices is not contiguous), and consequently this function uses the following algorithm for parallel::shared::Triangulation objects:
-
It determines how many degrees of freedom each processor owns. This is an invariant under renumbering, and consequently we can use how many DoFs each processor owns at the beginning of the current function. Let us call this number for processor .
+
It determines how many degrees of freedom each processor owns. This is an invariant under renumbering, and consequently we can use how many DoFs each processor owns at the beginning of the current function. Let us call this number for processor .
It determines for each processor a contiguous range of new DoF indices so that , , and .
It traverses the locally owned cells in Z order and renumbers the locally owned degrees of freedom on these cells so that the new numbers fit within the interval . In other words, the locally owned degrees of freedom on each processor are sorted according to the Z order of the locally owned cells they are on, but this property may not hold globally, across cells. This is because the partitioning algorithm may have decided that, for example, processor 0 owns a cell that comes later in Z order than one of the cells assigned to processor 1. On the other hand, the algorithm described above assigns the degrees of freedom on this cell earlier indices than all of the indices owned by processor 1.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/namespaceDoFTools.html differs (JavaScript source, ASCII text, with very long lines (1381))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/namespaceDoFTools.html 2023-11-25 15:26:00.409879516 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/namespaceDoFTools.html 2023-11-25 15:26:00.406546253 +0100
@@ -306,7 +306,7 @@
(As a side note, for corner cases: The question what a degree of freedom on the boundary is, is not so easy. It should really be a degree of freedom of which the respective basis function has nonzero values on the boundary. At least for Lagrange elements this definition is equal to the statement that the off-point, or what deal.II calls support_point, of the shape function, i.e. the point where the function assumes its nominal value (for Lagrange elements this is the point where it has the function value 1), is located on the boundary. We do not check this directly, the criterion is rather defined through the information the finite element class gives: the FiniteElement class defines the numbers of basis functions per vertex, per line, and so on and the basis functions are numbered after this information; a basis function is to be considered to be on the face of a cell (and thus on the boundary if the cell is at the boundary) according to it belonging to a vertex, line, etc but not to the interior of the cell. The finite element uses the same cell-wise numbering so that we can say that if a degree of freedom was numbered as one of the dofs on lines, we assume that it is located on the line. Where the off-point actually is, is a secret of the finite element (well, you can ask it, but we don't do it here) and not relevant in this context.)
Setting up sparsity patterns for boundary matrices
In some cases, one wants to only work with DoFs that sit on the boundary. One application is, for example, if rather than interpolating non- homogeneous boundary values, one would like to project them. For this, we need two things: a way to identify nodes that are located on (parts of) the boundary, and a way to build matrices out of only degrees of freedom that are on the boundary (i.e. much smaller matrices, in which we do not even build the large zero block that stems from the fact that most degrees of freedom have no support on the boundary of the domain). The first of these tasks is done by the map_dof_to_boundary_indices() function (described above).
-
The second part requires us first to build a sparsity pattern for the couplings between boundary nodes, and then to actually build the components of this matrix. While actually computing the entries of these small boundary matrices is discussed in the MatrixCreator namespace, the creation of the sparsity pattern is done by the create_boundary_sparsity_pattern() function. For its work, it needs to have a numbering of all those degrees of freedom that are on those parts of the boundary that we are interested in. You can get this from the map_dof_to_boundary_indices() function. It then builds the sparsity pattern corresponding to integrals like , where and are indices into the matrix, and is the global DoF number of a degree of freedom sitting on a boundary (i.e., is the inverse of the mapping returned by map_dof_to_boundary_indices() function).
+
The second part requires us first to build a sparsity pattern for the couplings between boundary nodes, and then to actually build the components of this matrix. While actually computing the entries of these small boundary matrices is discussed in the MatrixCreator namespace, the creation of the sparsity pattern is done by the create_boundary_sparsity_pattern() function. For its work, it needs to have a numbering of all those degrees of freedom that are on those parts of the boundary that we are interested in. You can get this from the map_dof_to_boundary_indices() function. It then builds the sparsity pattern corresponding to integrals like , where and are indices into the matrix, and is the global DoF number of a degree of freedom sitting on a boundary (i.e., is the inverse of the mapping returned by map_dof_to_boundary_indices() function).
Otherwise, if face_1 and face_2 are not active faces, this function loops recursively over the children of face_1 and face_2. If only one of the two faces is active, then we recursively iterate over the children of the non-active ones and make sure that the solution function on the refined side equals that on the non-refined face in much the same way as we enforce hanging node constraints at places where differently refined cells come together. (However, unlike hanging nodes, we do not enforce the requirement that there be only a difference of one refinement level between the two sides of the domain you would like to be periodic).
This routine only constrains DoFs that are not already constrained. If this routine encounters a DoF that already is constrained (for instance by Dirichlet boundary conditions), the old setting of the constraint (dofs the entry is constrained to, inhomogeneities) is kept and nothing happens.
The flags in the component_mask (see GlossComponentMask) denote which components of the finite element space shall be constrained with periodic boundary conditions. If it is left as specified by the default value all components are constrained. If it is different from the default value, it is assumed that the number of entries equals the number of components of the finite element. This can be used to enforce periodicity in only one variable in a system of equations.
-
face_orientation, face_flip and face_rotation describe an orientation that should be applied to face_1 prior to matching and constraining DoFs. This has nothing to do with the actual orientation of the given faces in their respective cells (which for boundary faces is always the default) but instead how you want to see periodicity to be enforced. For example, by using these flags, you can enforce a condition of the kind (i.e., a Moebius band) or in 3d a twisted torus. More precisely, these flags match local face DoF indices in the following manner:
+
face_orientation, face_flip and face_rotation describe an orientation that should be applied to face_1 prior to matching and constraining DoFs. This has nothing to do with the actual orientation of the given faces in their respective cells (which for boundary faces is always the default) but instead how you want to see periodicity to be enforced. For example, by using these flags, you can enforce a condition of the kind (i.e., a Moebius band) or in 3d a twisted torus. More precisely, these flags match local face DoF indices in the following manner:
In 2d: face_orientation must always be true, face_rotation is always false, and face_flip has the meaning of line_flip; this implies e.g. for Q1:
Optionally a matrix matrix along with a std::vector first_vector_components can be specified that describes how DoFs on face_1 should be modified prior to constraining to the DoFs of face_2. Here, two declarations are possible: If the std::vector first_vector_components is non empty the matrix is interpreted as a dimdim rotation matrix that is applied to all vector valued blocks listed in first_vector_components of the FESystem. If first_vector_components is empty the matrix is interpreted as an interpolation matrix with size no_face_dofs no_face_dofs.
This function makes sure that identity constraints don't create cycles in constraints.
-
periodicity_factor can be used to implement Bloch periodic conditions (a.k.a. phase shift periodic conditions) of the form where is periodic with the same periodicity as the crystal lattice and is the wavevector, see https://en.wikipedia.org/wiki/Bloch_wave. The solution at face_2 is equal to the solution at face_1 times periodicity_factor. For example, if the solution at face_1 is and is the corresponding point on face_2, then the solution at face_2 should be . This condition can be implemented using .
+
periodicity_factor can be used to implement Bloch periodic conditions (a.k.a. phase shift periodic conditions) of the form where is periodic with the same periodicity as the crystal lattice and is the wavevector, see https://en.wikipedia.org/wiki/Bloch_wave. The solution at face_2 is equal to the solution at face_1 times periodicity_factor. For example, if the solution at face_1 is and is the corresponding point on face_2, then the solution at face_2 should be . This condition can be implemented using .
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/namespaceFESeries.html differs (JavaScript source, ASCII text, with very long lines (867))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/namespaceFESeries.html 2023-11-25 15:26:00.419879313 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/namespaceFESeries.html 2023-11-25 15:26:00.419879313 +0100
@@ -177,7 +177,7 @@
-
Linear regression least-square fit of . The size of the input vectors should be equal and more than 1. The returned pair will contain (first) and (second).
+
Linear regression least-square fit of . The size of the input vectors should be equal and more than 1. The returned pair will contain (first) and (second).
This namespace offers interpolations and extrapolations of discrete functions of one FiniteElementfe1 to another FiniteElementfe2.
-
It also provides the local interpolation matrices that interpolate on each cell. Furthermore it provides the difference matrix that is needed for evaluating for e.g. the dual solution .
+
It also provides the local interpolation matrices that interpolate on each cell. Furthermore it provides the difference matrix that is needed for evaluating for e.g. the dual solution .
For more information about the spacedim template parameter check the documentation of FiniteElement or the one of Triangulation.
Function Documentation
@@ -370,7 +370,7 @@
Compute the identity matrix minus the back interpolation matrix. The difference_matrix will be of size (fe1.n_dofs_per_cell(), fe1.n_dofs_per_cell()) after this function. Previous content of the argument will be overwritten.
-
This function computes the matrix that transforms a fe1 function to where denotes the interpolation operator from the fe1 space to the fe2 space. This matrix hence is useful to evaluate error-representations where denotes the dual solution.
+
This function computes the matrix that transforms a fe1 function to where denotes the interpolation operator from the fe1 space to the fe2 space. This matrix hence is useful to evaluate error-representations where denotes the dual solution.
@@ -404,7 +404,7 @@
-
Compute the local -projection matrix from fe1 to fe2.
+
Compute the local -projection matrix from fe1 to fe2.
@@ -425,22 +425,22 @@
This is a rather specialized function used during the construction of finite element objects. It is used to build the basis of shape functions for an element, given a set of polynomials and interpolation points. The function is only implemented for finite elements with exactly dim vector components. In particular, this applies to classes derived from the FE_PolyTensor class.
-
Specifically, the purpose of this function is as follows: FE_PolyTensor receives, from its derived classes, an argument that describes a polynomial space. This space may be parameterized in terms of monomials, or in some other way, but is in general not in the form that we use for finite elements where we typically want to use a basis that is derived from some kind of node functional (e.g., the interpolation at specific points). Concretely, assume that the basis used by the polynomial space is , and that the node functionals of the finite element are . We then want to compute a basis for the finite element space so that . To do this, we can set where we need to determine the expansion coefficients . We do this by applying to both sides of the equation, to obtain
-FE_PolyTensor receives, from its derived classes, an argument that describes a polynomial space. This space may be parameterized in terms of monomials, or in some other way, but is in general not in the form that we use for finite elements where we typically want to use a basis that is derived from some kind of node functional (e.g., the interpolation at specific points). Concretely, assume that the basis used by the polynomial space is , and that the node functionals of the finite element are . We then want to compute a basis for the finite element space so that . To do this, we can set where we need to determine the expansion coefficients . We do this by applying to both sides of the equation, to obtain
+
+\end{align*}" src="form_1215.png"/>
-
and we know that the left hand side equals . If you think of this as a system of equations for the elements of a matrix on the left and on the right, then this can be written as
-. If you think of this as a system of equations for the elements of a matrix on the left and on the right, then this can be written as
+
+\end{align*}" src="form_1217.png"/>
-
where is the matrix of coefficients and . Consequently, in order to compute the expansion coefficients , we need to apply the node functionals to all functions of the "raw" basis of the polynomial space.
-
Until the finite element receives this matrix back, it describes its shape functions (e.g., in FiniteElement::shape_value()) in the form . After it calls this function, it has the expansion coefficients and can describe its shape functions as .
-
This function therefore computes this matrix , for the following specific circumstances:
-
That the node functionals are point evaluations at points that the finite element in question describes via its "generalized" support points (through FiniteElement::get_generalized_support_points(), see also this glossary entry). These point evaluations need to necessarily evaluate the value of a shape function at that point (the shape function may be vector-valued, and so the functional may be a linear combination of the individual components of the values); but, in particular, the nodal functions may not be integrals over entire edges or faces, or other non-local functionals. In other words, we assume that where is a function of the (possibly vector-valued) argument that returns a scalar.
+
where is the matrix of coefficients and . Consequently, in order to compute the expansion coefficients , we need to apply the node functionals to all functions of the "raw" basis of the polynomial space.
+
Until the finite element receives this matrix back, it describes its shape functions (e.g., in FiniteElement::shape_value()) in the form . After it calls this function, it has the expansion coefficients and can describe its shape functions as .
+
This function therefore computes this matrix , for the following specific circumstances:
+
That the node functionals are point evaluations at points that the finite element in question describes via its "generalized" support points (through FiniteElement::get_generalized_support_points(), see also this glossary entry). These point evaluations need to necessarily evaluate the value of a shape function at that point (the shape function may be vector-valued, and so the functional may be a linear combination of the individual components of the values); but, in particular, the nodal functions may not be integrals over entire edges or faces, or other non-local functionals. In other words, we assume that where is a function of the (possibly vector-valued) argument that returns a scalar.
That the finite element has exactly dim vector components.
Compute for a given dof1-function, where is the interpolation from fe1 to fe2. The result is written into z1_difference.
+
Compute for a given dof1-function, where is the interpolation from fe1 to fe2. The result is written into z1_difference.
Note, that this function does not work for continuous elements at hanging nodes. For that case use the interpolation_difference function, below, that takes an additional AffineConstraints object.
@@ -1123,7 +1123,7 @@
-
Compute for a given dof1-function, where is the interpolation from fe1 to fe2. The result is written into z1_difference. constraints1 and constraints2 are the hanging node constraints corresponding to dof1 and dof2, respectively. These objects are particular important when continuous elements on grids with hanging nodes (locally refined grids) are involved.
+
Compute for a given dof1-function, where is the interpolation from fe1 to fe2. The result is written into z1_difference. constraints1 and constraints2 are the hanging node constraints corresponding to dof1 and dof2, respectively. These objects are particular important when continuous elements on grids with hanging nodes (locally refined grids) are involved.
For parallel computations, supply z1 with ghost elements and z1_difference without ghost elements.
@@ -1165,7 +1165,7 @@
-
projection for discontinuous elements. Operates the same direction as interpolate.
+
projection for discontinuous elements. Operates the same direction as interpolate.
The global projection can be computed by local matrices if the finite element spaces are discontinuous. With continuous elements, this is impossible, since a global mass matrix must be inverted.
@@ -1214,7 +1214,7 @@
It then performs a loop over all non-active cells of dof2. If such a non-active cell has at least one active child, then we call the children of this cell a "patch". We then interpolate from the children of this patch to the patch, using the finite element space associated with dof2 and immediately interpolate back to the children. In essence, this information throws away all information in the solution vector that lives on a scale smaller than the patch cell.
Since we traverse non-active cells from the coarsest to the finest levels, we may find patches that correspond to child cells of previously treated patches if the mesh had been refined adaptively (this cannot happen if the mesh has been refined globally because there the children of a patch are all active). We also perform the operation described above on these patches, but it is easy to see that on patches that are children of previously treated patches, the operation is now the identity operation (since it interpolates from the children of the current patch a function that had previously been interpolated to these children from an even coarser patch). Consequently, this does not alter the solution vector any more.
-
The name of the function originates from the fact that it can be used to construct a representation of a function of higher polynomial degree on a once coarser mesh. For example, if you imagine that you start with a function on a globally refined mesh, and that dof2 is associated with a element, then this function computes the equivalent of the operator interpolating the original piecewise linear function onto a quadratic function on a once coarser mesh with mesh size (but representing this function on the original mesh with size ). If the exact solution is sufficiently smooth, then is typically a better approximation to the exact solution of the PDE than is. In other words, this function provides a postprocessing step that improves the solution in a similar way one often obtains by extrapolating a sequence of solutions, explaining the origin of the function's name.
+
The name of the function originates from the fact that it can be used to construct a representation of a function of higher polynomial degree on a once coarser mesh. For example, if you imagine that you start with a function on a globally refined mesh, and that dof2 is associated with a element, then this function computes the equivalent of the operator interpolating the original piecewise linear function onto a quadratic function on a once coarser mesh with mesh size (but representing this function on the original mesh with size ). If the exact solution is sufficiently smooth, then is typically a better approximation to the exact solution of the PDE than is. In other words, this function provides a postprocessing step that improves the solution in a similar way one often obtains by extrapolating a sequence of solutions, explaining the origin of the function's name.
Note
The resulting field does not satisfy continuity requirements of the given finite elements if the algorithm outlined above is used. When you use continuous elements on grids with hanging nodes, please use the extrapolate function with an additional AffineConstraints argument, see below.
Since this function operates on patches of cells, it requires that the underlying grid is refined at least once for every coarse grid cell. If this is not the case, an exception will be raised.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/namespaceFunctionTools.html differs (JavaScript source, ASCII text, with very long lines (650))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/namespaceFunctionTools.html 2023-11-25 15:26:00.453211970 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/namespaceFunctionTools.html 2023-11-25 15:26:00.453211970 +0100
@@ -138,13 +138,13 @@
-
Estimate bounds on the value and bounds on each gradient component of a Function, , over a BoundingBox, by approximating it by a 2nd order Taylor polynomial starting from the box center.
-
Each lower and upper bound is returned as a std::pair<double, double>, such that the first entry is the lower bound, , and the second is the upper bound, , i.e. .
+
Estimate bounds on the value and bounds on each gradient component of a Function, , over a BoundingBox, by approximating it by a 2nd order Taylor polynomial starting from the box center.
+
Each lower and upper bound is returned as a std::pair<double, double>, such that the first entry is the lower bound, , and the second is the upper bound, , i.e. .
The function value, gradient, and Hessian are computed at the box center. The bounds on the value of the function are then estimated as
-
, where .
-
Here, is half the side length of the box in the th coordinate direction, which is the distance we extrapolate. The bounds on the gradient components are estimated similarly as
-
, where .
+
, where .
+
Here, is half the side length of the box in the th coordinate direction, which is the distance we extrapolate. The bounds on the gradient components are estimated similarly as
+
, where .
If the function has more than 1 component the component parameter can be used to specify which function component the bounds should be computed for.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/namespaceGeometricUtilities_1_1Coordinates.html differs (JavaScript source, ASCII text, with very long lines (669))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/namespaceGeometricUtilities_1_1Coordinates.html 2023-11-25 15:26:00.463211767 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/namespaceGeometricUtilities_1_1Coordinates.html 2023-11-25 15:26:00.463211767 +0100
@@ -128,13 +128,13 @@
-
Return spherical coordinates of a Cartesian point point. The returned array is filled with radius, azimuth angle and polar/inclination angle (omitted in 2d).
+
Return spherical coordinates of a Cartesian point point. The returned array is filled with radius, azimuth angle and polar/inclination angle (omitted in 2d).
In 3d the transformation is given by
-
+\end{align*}" src="form_546.png"/>
The use of this function is demonstrated in step-75.
@@ -158,13 +158,13 @@
-
Return the Cartesian coordinates of a spherical point defined by scoord which is filled with radius , azimuth angle and polar/inclination angle (omitted in 2d).
+
Return the Cartesian coordinates of a spherical point defined by scoord which is filled with radius , azimuth angle and polar/inclination angle (omitted in 2d).
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/namespaceGraphColoring.html differs (JavaScript source, ASCII text, with very long lines (1206))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/namespaceGraphColoring.html 2023-11-25 15:26:00.473211563 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/namespaceGraphColoring.html 2023-11-25 15:26:00.473211563 +0100
@@ -141,9 +141,9 @@
Create a partitioning of the given range of iterators so that iterators that point to conflicting objects will be placed into different partitions, where the question whether two objects conflict is determined by a user-provided function.
This function can also be considered as a graph coloring: each object pointed to by an iterator is considered to be a node and there is an edge between each two nodes that conflict. The graph coloring algorithm then assigns a color to each node in such a way that two nodes connected by an edge do not have the same color.
A typical use case for this function is in assembling a matrix in parallel. There, one would like to assemble local contributions on different cells at the same time (an operation that is purely local and so requires no synchronization) but then we need to add these local contributions to the global matrix. In general, the contributions from different cells may be to the same matrix entries if the cells share degrees of freedom and, consequently, can not happen at the same time unless we want to risk a race condition (see http://en.wikipedia.org/wiki/Race_condition). Thus, we call these two cells in conflict, and we can only allow operations in parallel from cells that do not conflict. In other words, two cells are in conflict if the set of matrix entries (for example characterized by the rows) have a nonempty intersection.
-
In this generality, computing the graph of conflicts would require calling a function that determines whether two iterators (or the two objects they represent) conflict, and calling it for every pair of iterators, i.e., times. This is too expensive in general. A better approach is to require a user-defined function that returns for every iterator it is called for a set of indicators of some kind that characterize a conflict; two iterators are in conflict if their conflict indicator sets have a nonempty intersection. In the example of assembling a matrix, the conflict indicator set would contain the indices of all degrees of freedom on the cell pointed to (in the case of continuous Galerkin methods) or the union of indices of degree of freedom on the current cell and all cells adjacent to the faces of the current cell (in the case of discontinuous Galerkin methods, because there one computes face integrals coupling the degrees of freedom connected by a common face – see step-12).
+
In this generality, computing the graph of conflicts would require calling a function that determines whether two iterators (or the two objects they represent) conflict, and calling it for every pair of iterators, i.e., times. This is too expensive in general. A better approach is to require a user-defined function that returns for every iterator it is called for a set of indicators of some kind that characterize a conflict; two iterators are in conflict if their conflict indicator sets have a nonempty intersection. In the example of assembling a matrix, the conflict indicator set would contain the indices of all degrees of freedom on the cell pointed to (in the case of continuous Galerkin methods) or the union of indices of degree of freedom on the current cell and all cells adjacent to the faces of the current cell (in the case of discontinuous Galerkin methods, because there one computes face integrals coupling the degrees of freedom connected by a common face – see step-12).
Note
The conflict set returned by the user defined function passed as third argument needs to accurately describe all degrees of freedom for which anything is written into the matrix or right hand side. In other words, if the writing happens through a function like AffineConstraints::copy_local_to_global(), then the set of conflict indices must actually contain not only the degrees of freedom on the current cell, but also those they are linked to by constraints such as hanging nodes.
-
In other situations, the conflict indicator sets may represent something different altogether – it is up to the caller of this function to describe what it means for two iterators to conflict. Given this, computing conflict graph edges can be done significantly more cheaply than with operations.
+
In other situations, the conflict indicator sets may represent something different altogether – it is up to the caller of this function to describe what it means for two iterators to conflict. Given this, computing conflict graph edges can be done significantly more cheaply than with operations.
In any case, the result of the function will be so that iterators whose conflict indicator sets have overlap will not be assigned to the same color.
Note
The algorithm used in this function is described in a paper by Turcksin, Kronbichler and Bangerth, see workstream_paper.
Parameters
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/namespaceGridGenerator.html differs (JavaScript source, ASCII text, with very long lines (1193))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/namespaceGridGenerator.html 2023-11-25 15:26:00.509877484 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/namespaceGridGenerator.html 2023-11-25 15:26:00.509877484 +0100
@@ -303,7 +303,7 @@
-
Initialize the given triangulation with a hypercube (line in 1d, square in 2d, etc) consisting of exactly one cell. The hypercube volume is the tensor product interval in the present number of dimensions, where the limits are given as arguments. They default to zero and unity, then producing the unit hypercube.
+
Initialize the given triangulation with a hypercube (line in 1d, square in 2d, etc) consisting of exactly one cell. The hypercube volume is the tensor product interval in the present number of dimensions, where the limits are given as arguments. They default to zero and unity, then producing the unit hypercube.
If the argument colorize is false, then all boundary indicators are set to zero (the default boundary indicator) for 2d and 3d. If it is true, the boundary is colorized as in hyper_rectangle(). In 1d the indicators are always colorized, see hyper_rectangle().
@@ -339,7 +339,7 @@
-
Create a -simplex (i.e., a triangle in 2d, or a tetrahedron in 3d) with corners. Since deal.II does not support triangular and tetrahedral cells, the simplex described by the input arguments is subdivided into quadrilaterals and hexahedra by adding edge, face, and simplex midpoints, resulting in a mesh that consists of quadrilateral or hexahedral cells.
+
Create a -simplex (i.e., a triangle in 2d, or a tetrahedron in 3d) with corners. Since deal.II does not support triangular and tetrahedral cells, the simplex described by the input arguments is subdivided into quadrilaterals and hexahedra by adding edge, face, and simplex midpoints, resulting in a mesh that consists of quadrilateral or hexahedral cells.
The vertices argument contains a vector with all d+1 vertices defining the corners of the simplex. They must be given in an order such that the vectors from the first vertex to each of the others form a right-handed system.
The meshes generated in two and three dimensions are:
@@ -832,7 +832,7 @@
-
Generate a grid consisting of a channel with a cylinder. This is a common benchmark for Navier-Stokes solvers. The geometry consists of a channel of size (where the dimension is omitted in 2d) with a cylinder, parallel to the axis with diameter , centered at . The channel has three distinct regions:
+
Generate a grid consisting of a channel with a cylinder. This is a common benchmark for Navier-Stokes solvers. The geometry consists of a channel of size (where the dimension is omitted in 2d) with a cylinder, parallel to the axis with diameter , centered at . The channel has three distinct regions:
If n_shells is greater than zero, then there are that many shells centered around the cylinder,
The picture below shows part of the 2d grid (using all default arguments to this function) after two global refinements. The cells with manifold id are orange (the polar manifold id), cells with manifold id are yellow (the transfinite interpolation manifold id), and the ones with manifold id numbers::flat_manifold_id are cyan:
The picture below shows part of the 2d grid (using all default arguments to this function) after two global refinements. The cells with manifold id are orange (the polar manifold id), cells with manifold id are yellow (the transfinite interpolation manifold id), and the ones with manifold id numbers::flat_manifold_id are cyan:
Parameters
tria
Triangulation to be created. Must be empty upon calling this function.
-
shell_region_width
Width of the layer of shells around the cylinder. This value should be between and ; the default value is .
+
shell_region_width
Width of the layer of shells around the cylinder. This value should be between and ; the default value is .
If true, then assign different boundary ids to different parts of the boundary. For more information on boundary indicators see this glossary entry. The left boundary (at ) is assigned an id of , the right boundary (at ) is assigned an id of ; the boundary of the obstacle in the middle (i.e., the circle in 2d or the cylinder walls in 3d) is assigned an id of , and the channel walls are assigned an id of .
+
colorize
If true, then assign different boundary ids to different parts of the boundary. For more information on boundary indicators see this glossary entry. The left boundary (at ) is assigned an id of , the right boundary (at ) is assigned an id of ; the boundary of the obstacle in the middle (i.e., the circle in 2d or the cylinder walls in 3d) is assigned an id of , and the channel walls are assigned an id of .
@@ -1227,7 +1227,7 @@
This function is declared to exist for triangulations of all space dimensions, but throws an error if called in 1d.
By default, the manifold_id is set to 0 on the boundary faces, 1 on the boundary cells, and numbers::flat_manifold_id on the central cell and on internal faces.
A SphericalManifold is attached by default to the boundary faces for correct placement of boundary vertices upon refinement and to be able to use higher order mappings. However, it turns out that this strategy may not be the optimal one to create a good a mesh for a hyperball. The "Possibilities for extensions" section of step-6 has an extensive discussion of how one would construct better meshes and what one needs to do for it. Setting the argument attach_spherical_manifold_on_boundary_cells to true attaches a SphericalManifold manifold also to the cells adjacent to the boundary, and not only to the boundary faces.
-
Note
Since this is likely one of the earliest functions users typically consider to create meshes with curved boundaries, let us also comment on one aspect that is often confusing: Namely, that what one sees is not always what is actually happening. Specifically, if you output the coarse mesh with a function such as GridOut::write_vtk() using default options, then one doesn't generally get to see curved faces at the boundary. That's because most file formats by default only store vertex locations, with the implicit understanding that cells are composed from these vertices and bounded by straight edges. At the same time, the fact that this function attaches a SphericalManifold object to the boundary faces means that at least internally, edges really are curved. If you want to see them that way, you need to make sure that the function you use to output the mesh actually plots boundary faces as curved lines rather than straight lines characterized by only the locations of the two end points. For example, GridOut::write_gnuplot() can do that if you set the corresponding flag in the GridOutFlags::Gnuplot structure. It is, however, an entirely separate consideration whether you are actually computing on curved cells. In typical finite element computations, one has to compute integrals and these are computed by transforming back actual cells using a mapping to the reference cell. What mapping is used determines what shape the cells have for these internal computations: For example, with the widely used mapping (implicitly used in step-6), integration always happens on cells that are assumed to have straight boundaries described by only the vertex locations. In other words, if such a mapping is used, then the cells of the domain really do have straight edges, regardless of the manifold description attached to these edges and regardless of the flags given when generating output. As a consequence of all of this, it is important to distinguish three things: (i) the manifold description attached to an object in the mesh; (ii) the mapping used in integration; and (iii) the style used in outputting graphical information about the mesh. All of these can be chosen more or less independently of each other, and what you see visualized is not necessarily exactly what is happening.
+
Note
Since this is likely one of the earliest functions users typically consider to create meshes with curved boundaries, let us also comment on one aspect that is often confusing: Namely, that what one sees is not always what is actually happening. Specifically, if you output the coarse mesh with a function such as GridOut::write_vtk() using default options, then one doesn't generally get to see curved faces at the boundary. That's because most file formats by default only store vertex locations, with the implicit understanding that cells are composed from these vertices and bounded by straight edges. At the same time, the fact that this function attaches a SphericalManifold object to the boundary faces means that at least internally, edges really are curved. If you want to see them that way, you need to make sure that the function you use to output the mesh actually plots boundary faces as curved lines rather than straight lines characterized by only the locations of the two end points. For example, GridOut::write_gnuplot() can do that if you set the corresponding flag in the GridOutFlags::Gnuplot structure. It is, however, an entirely separate consideration whether you are actually computing on curved cells. In typical finite element computations, one has to compute integrals and these are computed by transforming back actual cells using a mapping to the reference cell. What mapping is used determines what shape the cells have for these internal computations: For example, with the widely used mapping (implicitly used in step-6), integration always happens on cells that are assumed to have straight boundaries described by only the vertex locations. In other words, if such a mapping is used, then the cells of the domain really do have straight edges, regardless of the manifold description attached to these edges and regardless of the flags given when generating output. As a consequence of all of this, it is important to distinguish three things: (i) the manifold description attached to an object in the mesh; (ii) the mapping used in integration; and (iii) the style used in outputting graphical information about the mesh. All of these can be chosen more or less independently of each other, and what you see visualized is not necessarily exactly what is happening.
Precondition
The triangulation passed as argument needs to be empty when calling this function.
@@ -1529,7 +1529,7 @@
-
Create a dim dimensional cylinder where the -axis serves as the axis of the cylinder. For the purposes of this function, a cylinder is defined as a (dim - 1) dimensional disk of given radius, extruded along the axis of the cylinder (which is the first coordinate direction). Consequently, in three dimensions, the cylinder extends from x=-half_length to x=+half_length and its projection into the yz-plane is a circle of radius radius. In two dimensions, the cylinder is a rectangle from x=-half_length to x=+half_length and from y=-radius to y=radius.
+
Create a dim dimensional cylinder where the -axis serves as the axis of the cylinder. For the purposes of this function, a cylinder is defined as a (dim - 1) dimensional disk of given radius, extruded along the axis of the cylinder (which is the first coordinate direction). Consequently, in three dimensions, the cylinder extends from x=-half_length to x=+half_length and its projection into the yz-plane is a circle of radius radius. In two dimensions, the cylinder is a rectangle from x=-half_length to x=+half_length and from y=-radius to y=radius.
The boundaries are colored according to the following scheme: 0 for the hull of the cylinder, 1 for the left hand face and 2 for the right hand face (see the glossary entry on colorization).
The manifold id for the hull of the cylinder is set to zero, and a CylindricalManifold is attached to it.
Precondition
The triangulation passed as argument needs to be empty when calling this function.
@@ -1573,7 +1573,7 @@
-
Create a dim dimensional cylinder where the -axis serves as the axis of the cylinder. For the purposes of this function, a cylinder is defined as a (dim - 1) dimensional disk of given radius, extruded along the axis of the cylinder (which is the first coordinate direction). Consequently, in three dimensions, the cylinder extends from x=-half_length to x=+half_length and its projection into the yz-plane is a circle of radius radius. In two dimensions, the cylinder is a rectangle from x=-half_length to x=+half_length and from y=-radius to y=radius. This function is only implemented for dim==3.
+
Create a dim dimensional cylinder where the -axis serves as the axis of the cylinder. For the purposes of this function, a cylinder is defined as a (dim - 1) dimensional disk of given radius, extruded along the axis of the cylinder (which is the first coordinate direction). Consequently, in three dimensions, the cylinder extends from x=-half_length to x=+half_length and its projection into the yz-plane is a circle of radius radius. In two dimensions, the cylinder is a rectangle from x=-half_length to x=+half_length and from y=-radius to y=radius. This function is only implemented for dim==3.
The boundaries are colored according to the following scheme: 0 for the hull of the cylinder, 1 for the left hand face and 2 for the right hand face (see the glossary entry on colorization).
The manifold id for the hull of the cylinder is set to zero, and a CylindricalManifold is attached to it.
A vector of integers of dimension GeometryInfo<dim>::faces_per_cell with the following meaning: the legs of the cross are stacked on the faces of the center cell, in the usual order of deal.II cells, namely first , then , then and so on. The corresponding entries in sizes name the number of cells stacked on this face. All numbers may be zero, thus L- and T-shaped domains are specializations of this domain.
+
sizes
A vector of integers of dimension GeometryInfo<dim>::faces_per_cell with the following meaning: the legs of the cross are stacked on the faces of the center cell, in the usual order of deal.II cells, namely first , then , then and so on. The corresponding entries in sizes name the number of cells stacked on this face. All numbers may be zero, thus L- and T-shaped domains are specializations of this domain.
colorize_cells
If colorization is enabled, then the material id of a cells corresponds to the leg it is in. The id of the center cell is zero, and then the legs are numbered starting at one (see the glossary entry on colorization).
@@ -2024,7 +2024,7 @@
96 for the rhombic dodecahedron refined once. This choice dates from an older version of deal.II before the Manifold classes were implemented: today this choce is equivalent to the rhombic dodecahedron after performing one global refinement.
-Numbers of the kind with integer. This choice is similar to the 24 and 48 cell cases, but provides additional refinements in azimuthal direction combined with a single layer in radial direction. The base mesh is either the 6 or 12 cell version, depending on whether in the power is odd or even, respectively.
+Numbers of the kind with integer. This choice is similar to the 24 and 48 cell cases, but provides additional refinements in azimuthal direction combined with a single layer in radial direction. The base mesh is either the 6 or 12 cell version, depending on whether in the power is odd or even, respectively.
The versions with 24, 48, and cells are useful if the shell is thin and the radial lengths should be made more similar to the circumferential lengths.
The 3d grids with 12 and 96 cells are plotted below:
@@ -2260,7 +2260,7 @@
-
Produce a domain that is the space between two cylinders in 3d, with given length, inner and outer radius and a given number of elements. The cylinder shell is built around the -axis with the two faces located at and length.
+
Produce a domain that is the space between two cylinders in 3d, with given length, inner and outer radius and a given number of elements. The cylinder shell is built around the -axis with the two faces located at and length.
If n_radial_cells is zero (as is the default), then it is computed adaptively such that the resulting elements have the least aspect ratio. The same holds for n_axial_cells.
Note
Although this function is declared as a template, it does not make sense in 1d and 2d. Also keep in mind that this object is rotated and positioned differently than the one created by cylinder().
All manifold ids are set to zero, and a CylindricalManifold is attached to the triangulation.
@@ -2315,9 +2315,9 @@
-
Produce the volume or surface mesh of a torus. The axis of the torus is the -axis while the plane of the torus is the - plane.
+
Produce the volume or surface mesh of a torus. The axis of the torus is the -axis while the plane of the torus is the - plane.
If dim is 3, the mesh will be the volume of the torus, using a mesh equivalent to the circle in the poloidal coordinates with 5 cells on the cross section. This function attaches a TorusManifold to all boundary faces which are marked with a manifold id of 1, a CylindricalManifold to the interior cells and all their faces which are marked with a manifold id of 2 (representing a flat state within the poloidal coordinates), and a TransfiniteInterpolationManifold to the cells between the TorusManifold on the surface and the ToroidalManifold in the center, with cells marked with manifold id 0.
-
An example for the case if dim is 3 with a cut through the domain at , 6 toroidal cells, and without any global refinement is given here:
+
An example for the case if dim is 3 with a cut through the domain at , 6 toroidal cells, and without any global refinement is given here:
@@ -2329,7 +2329,7 @@
R
The radius of the circle, which forms the middle line of the torus containing the loop of cells. Must be greater than r.
r
The inner radius of the torus.
n_cells_toroidal
Optional argument to set the number of cell layers in toroidal direction. The default is 6 cell layers.
-
phi
Optional argument to generate an open torus with angle . The default value is , in which case a closed torus is generated. If the torus is open, the torus is cut at two planes perpendicular to the torus centerline. The center of these two planes are located at and .
+
phi
Optional argument to generate an open torus with angle . The default value is , in which case a closed torus is generated. If the torus is open, the torus is cut at two planes perpendicular to the torus centerline. The center of these two planes are located at and .
@@ -2385,8 +2385,8 @@
-
This function produces a square in the xy-plane with a cylindrical hole in the middle. The square and the circle are centered at the origin. In 3d, this geometry is extruded in direction to the interval .
-
The inner boundary has a manifold id of and a boundary id of . This function attaches a PolarManifold or CylindricalManifold to the interior boundary in 2d and 3d respectively. The other faces have boundary ids of , or given in the standard order of faces in 2d or 3d.
+
This function produces a square in the xy-plane with a cylindrical hole in the middle. The square and the circle are centered at the origin. In 3d, this geometry is extruded in direction to the interval .
+
The inner boundary has a manifold id of and a boundary id of . This function attaches a PolarManifold or CylindricalManifold to the interior boundary in 2d and 3d respectively. The other faces have boundary ids of , or given in the standard order of faces in 2d or 3d.
@@ -2464,17 +2464,17 @@
Produce a grid consisting of concentric shells. The primary difference between this function and GridGenerator::hyper_shell() is that this function permits unevenly spaced (in the radial direction) coarse level cells.
-
The parameters center, inner_radius, and outer_radius behave in the same way as the first three arguments to GridGenerator::hyper_shell. n_shells gives the total number of shells to use (i.e., the number of cells in the radial direction). The outer radius of the th shell is given by
+
The parameters center, inner_radius, and outer_radius behave in the same way as the first three arguments to GridGenerator::hyper_shell. n_shells gives the total number of shells to use (i.e., the number of cells in the radial direction). The outer radius of the th shell is given by
-
-
As an example, with no coarsening, setting top_fraction_of_cells to 1/3 will result in approximately doubling the number of cells in two dimensions. That is because each of these 1/3 of cells will be replaced by its four children, resulting in cells, whereas the remaining 2/3 of cells remains untouched – thus yielding a total of cells. The same effect in three dimensions is achieved by refining 1/7th of the cells. These values are therefore frequently used because they ensure that the cost of computations on subsequent meshes become expensive sufficiently quickly that the fraction of time spent on the coarse meshes is not too large. On the other hand, the fractions are small enough that mesh adaptation does not refine too many cells in each step.
+
As an example, with no coarsening, setting top_fraction_of_cells to 1/3 will result in approximately doubling the number of cells in two dimensions. That is because each of these 1/3 of cells will be replaced by its four children, resulting in cells, whereas the remaining 2/3 of cells remains untouched – thus yielding a total of cells. The same effect in three dimensions is achieved by refining 1/7th of the cells. These values are therefore frequently used because they ensure that the cost of computations on subsequent meshes become expensive sufficiently quickly that the fraction of time spent on the coarse meshes is not too large. On the other hand, the fractions are small enough that mesh adaptation does not refine too many cells in each step.
This function provides a strategy to mark cells for refinement and coarsening with the goal of controlling the reduction of the error estimate.
Also known as the bulk criterion or Dörfler marking, this function computes the thresholds for refinement and coarsening such that the criteria of cells getting flagged for refinement make up for a certain fraction of the total error. We explain its operation for refinement, coarsening works analogously.
Let cK be the criterion of cell K. Then the total error estimate is computed by the formula
-
+\]" src="form_1368.png"/>
-
If 0 < a < 1 is top_fraction, then we refine the smallest subset of the Triangulation such that
The often used formula with squares on the left and right is recovered by actually storing the square of cK in the vector criteria.
@@ -348,32 +348,32 @@
-
This function flags cells of a triangulation for refinement with the aim to reach a grid that is optimal with respect to an objective function that tries to balance reducing the error and increasing the numerical cost when the mesh is refined. Specifically, this function makes the assumption that if you refine a cell with error indicator provided by the second argument to this function, then the error on the children (for all children together) will only be where order is the third argument of this function. This makes the assumption that the error is only a local property on a mesh and can be reduced by local refinement – an assumption that is true for the interpolation operator, but not for the usual Galerkin projection, although it is approximately true for elliptic problems where the Greens function decays quickly and the error here is not too much affected by a too coarse mesh somewhere else.
-
With this, we can define the objective function this function tries to optimize. Let us assume that the mesh currently has cells. Then, if we refine the cells with the largest errors, we expect to get (in space dimensions)
- with error indicator provided by the second argument to this function, then the error on the children (for all children together) will only be where order is the third argument of this function. This makes the assumption that the error is only a local property on a mesh and can be reduced by local refinement – an assumption that is true for the interpolation operator, but not for the usual Galerkin projection, although it is approximately true for elliptic problems where the Greens function decays quickly and the error here is not too much affected by a too coarse mesh somewhere else.
+
With this, we can define the objective function this function tries to optimize. Let us assume that the mesh currently has cells. Then, if we refine the cells with the largest errors, we expect to get (in space dimensions)
+
+\]" src="form_1375.png"/>
-
cells ( are not refined, and each of the cells we refine yield child cells. On the other hand, with refining cells, and using the assumptions above, we expect that the error will be
- are not refined, and each of the cells we refine yield child cells. On the other hand, with refining cells, and using the assumptions above, we expect that the error will be
+
+\]" src="form_1378.png"/>
-
where the first sum extends over cells and the second over the cells that will be refined. Note that is an increasing function of whereas is a decreasing function.
-
This function then tries to find that number of cells to mark for refinement for which the objective function
- cells and the second over the cells that will be refined. Note that is an increasing function of whereas is a decreasing function.
+
This function then tries to find that number of cells to mark for refinement for which the objective function
+
+\]" src="form_1381.png"/>
is minimal.
The rationale for this function is two-fold. First, compared to the refine_and_coarsen_fixed_fraction() and refine_and_coarsen_fixed_number() functions, this function has the property that if all refinement indicators are the same (i.e., we have achieved a mesh where the error per cell is equilibrated), then the entire mesh is refined. This is based on the observation that a mesh with equilibrated error indicators is the optimal mesh (i.e., has the least overall error) among all meshes with the same number of cells. (For proofs of this, see R. Becker, M. Braack, R. Rannacher: "Numerical simulation of laminar flames at low Mach number
with adaptive finite elements", Combustion Theory and Modelling, Vol. 3, Nr. 3, p. 503-534 1999; and W. Bangerth, R. Rannacher: "Adaptive Finite
Element Methods for Differential Equations", Birkhauser, 2003.)
-
Second, the function uses the observation that ideally, the error behaves like with some constant that depends on the dimension and the finite element degree. It should - given optimal mesh refinement - not depend so much on the regularity of the solution, as it is based on the idea, that all singularities can be resolved by refinement. Mesh refinement is then based on the idea that we want to make small. This corresponds to the functional above.
+
Second, the function uses the observation that ideally, the error behaves like with some constant that depends on the dimension and the finite element degree. It should - given optimal mesh refinement - not depend so much on the regularity of the solution, as it is based on the idea, that all singularities can be resolved by refinement. Mesh refinement is then based on the idea that we want to make small. This corresponds to the functional above.
Note
This function was originally implemented by Thomas Richter. It follows a strategy described in [Richter2005]. See in particular Section 4.3, pp. 42-43.
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/namespaceGridTools.html differs (JavaScript source, ASCII text, with very long lines (1031))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/namespaceGridTools.html 2023-11-25 15:26:00.573209526 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/namespaceGridTools.html 2023-11-25 15:26:00.573209526 +0100
@@ -508,8 +508,8 @@
-
Compute the volume (i.e. the dim-dimensional measure) of the triangulation. We compute the measure using the integral where are the cells of the given triangulation. The integral is approximated via quadrature. This version of the function uses a linear mapping to compute the JxW values on each cell.
+
Compute the volume (i.e. the dim-dimensional measure) of the triangulation. We compute the measure using the integral where are the cells of the given triangulation. The integral is approximated via quadrature. This version of the function uses a linear mapping to compute the JxW values on each cell.
If the triangulation is a dim-dimensional one embedded in a higher dimensional space of dimension spacedim, then the value returned is the dim-dimensional measure. For example, for a two-dimensional triangulation in three-dimensional space, the value returned is the area of the surface so described. (This obviously makes sense since the spacedim-dimensional measure of a dim-dimensional triangulation would always be zero if dim < spacedim).
Compute the volume (i.e. the dim-dimensional measure) of the triangulation. We compute the measure using the integral where are the cells of the given triangulation. The integral is approximated via quadrature for which we use the mapping argument.
+
Compute the volume (i.e. the dim-dimensional measure) of the triangulation. We compute the measure using the integral where are the cells of the given triangulation. The integral is approximated via quadrature for which we use the mapping argument.
If the triangulation is a dim-dimensional one embedded in a higher dimensional space of dimension spacedim, then the value returned is the dim-dimensional measure. For example, for a two-dimensional triangulation in three-dimensional space, the value returned is the area of the surface so described. (This obviously makes sense since the spacedim-dimensional measure of a dim-dimensional triangulation would always be zero if dim < spacedim.
This function computes an affine approximation of the map from the unit coordinates to the real coordinates of the form by a least squares fit of this affine function to the vertices representing a quadrilateral or hexahedral cell in spacedim dimensions. The result is returned as a pair with the matrix A as the first argument and the vector b describing distance of the plane to the origin.
+
This function computes an affine approximation of the map from the unit coordinates to the real coordinates of the form by a least squares fit of this affine function to the vertices representing a quadrilateral or hexahedral cell in spacedim dimensions. The result is returned as a pair with the matrix A as the first argument and the vector b describing distance of the plane to the origin.
For any valid mesh cell whose geometry is not degenerate, this operation results in a unique affine mapping, even in cases where the actual transformation by a bi-/trilinear or higher order mapping might be singular. The result is exact in case the transformation from the unit to the real cell is indeed affine, such as in one dimension or for Cartesian and affine (parallelogram) meshes in 2d/3d.
Computes an aspect ratio measure for all locally-owned active cells and fills a vector with one entry per cell, given a triangulation and mapping. The size of the vector that is returned equals the number of active cells. The vector contains zero for non locally-owned cells. The aspect ratio of a cell is defined as the ratio of the maximum to minimum singular value of the Jacobian, taking the maximum over all quadrature points of a quadrature rule specified via quadrature. For example, for the special case of rectangular elements in 2d with dimensions and ( ), this function returns the usual aspect ratio definition . The above definition using singular values is a generalization to arbitrarily deformed elements. This function is intended to be used for space dimensions, but it can also be used for returning a value of 1.
+
Computes an aspect ratio measure for all locally-owned active cells and fills a vector with one entry per cell, given a triangulation and mapping. The size of the vector that is returned equals the number of active cells. The vector contains zero for non locally-owned cells. The aspect ratio of a cell is defined as the ratio of the maximum to minimum singular value of the Jacobian, taking the maximum over all quadrature points of a quadrature rule specified via quadrature. For example, for the special case of rectangular elements in 2d with dimensions and ( ), this function returns the usual aspect ratio definition . The above definition using singular values is a generalization to arbitrarily deformed elements. This function is intended to be used for space dimensions, but it can also be used for returning a value of 1.
Note
Inverted elements do not throw an exception. Instead, a value of inf is written into the vector in case of inverted elements.
Make sure to use enough quadrature points for a precise calculation of the aspect ratio in case of deformed elements.
@@ -954,7 +954,7 @@
Remove vertices that are duplicated, due to the input of a structured grid, for example. If these vertices are not removed, the faces bounded by these vertices become part of the boundary, even if they are in the interior of the mesh.
-
This function is called by some GridIn::read_* functions. Only the vertices with indices in considered_vertices are tested for equality. This speeds up the algorithm, which is, for worst-case hyper cube geometries in 2d and in 3d: quite slow. However, if you wish to consider all vertices, simply pass an empty vector. In that case, the function fills considered_vertices with all vertices.
+
This function is called by some GridIn::read_* functions. Only the vertices with indices in considered_vertices are tested for equality. This speeds up the algorithm, which is, for worst-case hyper cube geometries in 2d and in 3d: quite slow. However, if you wish to consider all vertices, simply pass an empty vector. In that case, the function fills considered_vertices with all vertices.
Two vertices are considered equal if their difference in each coordinate direction is less than tol. This implies that nothing happens if the tolerance is set to zero.
Transform the vertices of the given triangulation by applying the function object provided as first argument to all its vertices.
-
The transformation given as argument is used to transform each vertex. Its respective type has to offer a function-like syntax, i.e. the predicate is either an object of a type that has an operator(), or it is a pointer to a non-member function, or it is a lambda function object. In either case, argument and return value have to be of type Point<spacedim>. An example – a simple transformation that moves the object two units to the right in the direction – could look like as follows:
The transformation given as argument is used to transform each vertex. Its respective type has to offer a function-like syntax, i.e. the predicate is either an object of a type that has an operator(), or it is a pointer to a non-member function, or it is a lambda function object. In either case, argument and return value have to be of type Point<spacedim>. An example – a simple transformation that moves the object two units to the right in the direction – could look like as follows:
Transform the given triangulation smoothly to a different domain where, typically, each of the vertices at the boundary of the triangulation is mapped to the corresponding points in the new_points map.
-
The unknown displacement field in direction is obtained from the minimization problem
- in direction is obtained from the minimization problem
+
+\]" src="form_1395.png"/>
subject to prescribed constraints. The minimizer is obtained by solving the Laplace equation of the dim components of a displacement field that maps the current domain into one described by new_points . Linear finite elements with four Gaussian quadrature points in each direction are used. The difference between the vertex positions specified in new_points and their current value in tria therefore represents the prescribed values of this displacement field at the boundary of the domain, or more precisely at all of those locations for which new_points provides values (which may be at part of the boundary, or even in the interior of the domain). The function then evaluates this displacement field at each unconstrained vertex and uses it to place the mapped vertex where the displacement field locates it. Because the solution of the Laplace equation is smooth, this guarantees a smooth mapping from the old domain to the new one.
Parameters
@@ -3410,7 +3410,7 @@
This function does the same as the previous one, i.e. it partitions a triangulation using a partitioning algorithm into a number of subdomains identified by the cell->subdomain_id() flag.
The difference to the previous function is the second argument, a sparsity pattern that represents the connectivity pattern between cells.
-
While the function above builds it directly from the triangulation by considering which cells neighbor each other, this function can take a more refined connectivity graph. The sparsity pattern needs to be of size , where is the number of active cells in the triangulation. If the sparsity pattern contains an entry at position , then this means that cells and (in the order in which they are traversed by active cell iterators) are to be considered connected; partitioning algorithm will then try to partition the domain in such a way that (i) the subdomains are of roughly equal size, and (ii) a minimal number of connections are broken.
+
While the function above builds it directly from the triangulation by considering which cells neighbor each other, this function can take a more refined connectivity graph. The sparsity pattern needs to be of size , where is the number of active cells in the triangulation. If the sparsity pattern contains an entry at position , then this means that cells and (in the order in which they are traversed by active cell iterators) are to be considered connected; partitioning algorithm will then try to partition the domain in such a way that (i) the subdomains are of roughly equal size, and (ii) a minimal number of connections are broken.
This function is mainly useful in cases where connections between cells exist that are not present in the triangulation alone (otherwise the previous function would be the simpler one to use). Such connections may include that certain parts of the boundary of a domain are coupled through symmetric boundary conditions or integrals (e.g. friction contact between the two sides of a crack in the domain), or if a numerical scheme is used that not only connects immediate neighbors but a larger neighborhood of cells (e.g. when solving integral equations).
In addition, this function may be useful in cases where the default sparsity pattern is not entirely sufficient. This can happen because the default is to just consider face neighbors, not neighboring cells that are connected by edges or vertices. While the latter couple when using continuous finite elements, they are typically still closely connected in the neighborship graph, and partitioning algorithm will not usually cut important connections in this case. However, if there are vertices in the mesh where many cells (many more than the common 4 or 6 in 2d and 3d, respectively) come together, then there will be a significant number of cells that are connected across a vertex, but several degrees removed in the connectivity graph built only using face neighbors. In a case like this, partitioning algorithm may sometimes make bad decisions and you may want to build your own connectivity graph.
Note
If the weight signal has been attached to the triangulation, then this will be used and passed to the partitioner.
@@ -4016,7 +4016,7 @@
An orthogonal equality test for faces.
face1 and face2 are considered equal, if a one to one matching between its vertices can be achieved via an orthogonal equality relation.
-
Here, two vertices v_1 and v_2 are considered equal, if is parallel to the unit vector in unit direction direction. If the parameter matrix is a reference to a spacedim x spacedim matrix, is set to matrix, otherwise is the identity matrix.
+
Here, two vertices v_1 and v_2 are considered equal, if is parallel to the unit vector in unit direction direction. If the parameter matrix is a reference to a spacedim x spacedim matrix, is set to matrix, otherwise is the identity matrix.
If the matching was successful, the relative orientation of face1 with respect to face2 is returned in the bitset orientation, where
orientation[0] -> face_orientation
orientation[1] -> face_flip
orientation[2] -> face_rotation
@@ -4135,8 +4135,8 @@
This function tries to match all faces belonging to the first boundary with faces belonging to the second boundary with the help of orthogonal_equality().
The bitset that is returned inside of PeriodicFacePair encodes the relative orientation of the first face with respect to the second face, see the documentation of orthogonal_equality() for further details.
The direction refers to the space direction in which periodicity is enforced. When matching periodic faces this vector component is ignored.
-
The offset is a vector tangential to the faces that is added to the location of vertices of the 'first' boundary when attempting to match them to the corresponding vertices of the 'second' boundary. This can be used to implement conditions such as .
-
Optionally, a rotation matrix can be specified that describes how vector valued DoFs of the first face should be modified prior to constraining to the DoFs of the second face. The matrix is used in two places. First, matrix will be supplied to orthogonal_equality() and used for matching faces: Two vertices and match if is parallel to the unit vector in unit direction direction. (For more details see DoFTools::make_periodicity_constraints(), the glossary glossary entry on periodic conditions and step-45). Second, matrix will be stored in the PeriodicFacePair collection matched_pairs for further use.
+
The offset is a vector tangential to the faces that is added to the location of vertices of the 'first' boundary when attempting to match them to the corresponding vertices of the 'second' boundary. This can be used to implement conditions such as .
+
Optionally, a rotation matrix can be specified that describes how vector valued DoFs of the first face should be modified prior to constraining to the DoFs of the second face. The matrix is used in two places. First, matrix will be supplied to orthogonal_equality() and used for matching faces: Two vertices and match if is parallel to the unit vector in unit direction direction. (For more details see DoFTools::make_periodicity_constraints(), the glossary glossary entry on periodic conditions and step-45). Second, matrix will be stored in the PeriodicFacePair collection matched_pairs for further use.
@@ -363,19 +363,19 @@
![$\Psi_i[\cdot]$](form_146_dark.png)
![$\Psi_i[\varphi]=\varphi(\hat{\mathbf{x}}_i)$](form_147_dark.png)
![$\Psi_i[\varphi_j]=\delta_{ij}$](form_148_dark.png)
![$\Psi_i[\varphi]=\varphi(\hat{\mathbf{x}}_i)_{c(i)}$](form_151_dark.png)
![$\Psi_i[\varphi]
+<dd><p class=](form_152_dark.png)
"Generalized support points" are, as the name suggests, a generalization of 
![$\Psi_i[\cdot]$](form_115_dark.png)
![$\Psi_i[\varphi]=\varphi(\hat{\mathbf{x}}_i)$](form_116_dark.png)
![$\Psi_i[\varphi_j]=\delta_{ij}$](form_117_dark.png)
![$\Psi_i[\varphi]=\varphi(\hat{\mathbf{x}}_i)_{c(i)}$](form_120_dark.png)
![$\Psi_i[\varphi]
=
\varphi(\hat{\mathbf{x}}_i) \cdot \mathbf{n}_i
- $](form_121_dark.png)
![$\Psi_i[\varphi]
+ $](form_155_dark.png)
![$\Psi_i[\varphi]
=
\int_{\hat{K}} \varphi(\hat{\mathbf{x}})
{\hat{x}_1}^{p_1(i)}
{\hat{x}_2}^{p_2(i)}
- $](form_124_dark.png)
![\[ m = I - \Delta t M. \]](form_368_dark.png)
![\[ m = I - \Delta t M. \]](form_353_dark.png)
![$[-1,1]$](form_582_dark.png)
![$[0,1]$](form_581_dark.png)
![$[-1,1]^d$](form_464_dark.png)
![$[0,1]^d$](form_872_dark.png)
![\[
(6) \quad Sa = (D - C \: A^{-1} \: B)a
-\]](form_1868_dark.png)
![\[
y = S^{-1} g'
- \]](form_1872_dark.png)
![$\in [0, 2^{\text{dim}} - 1]$](form_362_dark.png)
![\[
\mathbf x_K = \frac{1}{|K|} \int_K \mathbf x \; \textrm{d}x
\]](form_1482_dark.png)
![\[ F: \mathcal{B} \subset
-R^{\text{chartdim}} \mapsto \mathcal{M} \subset R^{\text{spacedim}} \]](form_1416_dark.png)
![\[ F: \mathcal{B} \subset
+R^{\text{chartdim}} \mapsto \mathcal{M} \subset R^{\text{spacedim}} \]](form_1419_dark.png)
![\[ F^{-1}: \mathcal{M} \subset R^{\text{spacedim}} \mapsto \mathcal{B}
-\subset R^{\text{chartdim}} \]](form_1417_dark.png)
![\[ F^{-1}: \mathcal{M} \subset R^{\text{spacedim}} \mapsto \mathcal{B}
+\subset R^{\text{chartdim}} \]](form_1420_dark.png)
![\[
+\mathbf x^{\text{new}} = F(\sum_i w_i F^{-1}(\mathbf x_i)). \]](form_1421_dark.png)
![$[0,1]\times \{0\}\times \{0\}$](form_1426_dark.png)
![$[0,1]\times \{0\}\times \{0\}$](form_1428_dark.png)
![\begin{align*}
\zeta(t) &= \xi_1 + t (\xi_2-\xi_1)
\\ &= F^{-1}(\mathbf x_1) + t\left[F^{-1}(\mathbf x_2)
-F^{-1}(\mathbf x_1)\right]
-\end{align*}](form_1440_dark.png)
![$ C (1/\sqrt[dim]{k})^r $](form_404_dark.png)
![$ C (1/\sqrt[dim]{k})^r $](form_379_dark.png)
![\[
\nabla \mathbf F(\mathbf x) \; \Delta \mathbf x
\approx
\mathbf F(\mathbf x + \Delta \mathbf x) - \mathbf F(\mathbf x).
-\]](form_396_dark.png)
![$[\Delta \mathbf x] [\nabla \mathbf F(\mathbf x)]^T$](form_398_dark.png)
![\[
\left\lbrace\begin{aligned}
x &= x_0 + c \cosh(u) \cos(v) \\
y &= y_0 + c \sinh(u) \sin(v)
\end{aligned}\right.
-\]](form_1454_dark.png)
![$e\in\left]0,1\right[$](form_1412_dark.png)
@@ -352,7 +352,7 @@
![$[\mathbf{u}]=\mathbf{u_1} - \mathbf{u_2}$](form_1183_dark.png)
![$[\mathbf{u}]=\mathbf{u_1} - \mathbf{u_2}$](form_1095_dark.png)
Fourier series on a reference element. The exponential form of the 
![$ [-1;1] $](form_1160_dark.png)
![$ [-1;1] $](form_1188_dark.png)
![\[
\int_{-1}^1 P_m(x) P_n(x) = \frac{2}{2n + 1} \delta_{mn}
-\]](form_1189_dark.png)
![$ [0;1] $](form_1162_dark.png)
![$ [0;1] $](form_1190_dark.png)
![\[
\widetilde P_m = \sqrt{2} P_m(2x-1).
-\]](form_1191_dark.png)
![\[
u(x)
= \sum_{m} c_m \widetilde P_{m}(x).
-\]](form_1192_dark.png)
![$\frac 12 [(\nabla \phi_i(x_q)) +
-(\nabla \phi_i(x_q))^T]$](form_1300_dark.png)
![$\frac 12 [(\nabla \phi_i(x_q)) +
+(\nabla \phi_i(x_q))^T]$](form_1245_dark.png)
![$\Psi_i[f]$](form_1036_dark.png)
![$ f_h(\mathbf x) = \sum_i \Psi_i[f] \varphi_i(\mathbf x)
-$](form_1038_dark.png)
![$\Psi_i[\varphi] = f_i(\varphi(\hat{\mathbf x}_i))$](form_1040_dark.png)
![$\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)$](form_1042_dark.png)
![$\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)_{c(i)}$](form_1043_dark.png)
![$\{\Psi[\varphi]\}_{i=0}^{N-1}$](form_1047_dark.png)
![$\Psi_i[f]$](form_1031_dark.png)
![$ f_h(\mathbf x) = \sum_i \Psi_i[f] \varphi_i(\mathbf x)
+$](form_1033_dark.png)
![\[
\frac{d^2 \phi_i}{d x_j d x_k} = D_{ijk} - H_{mjk} \frac{d \phi_i}{d x_m},
-\]](form_1142_dark.png)
![\[
\frac{d^3\phi_i}{d x_j d x_k d x_l} = D_{ijkl} - H_{mjl} \frac{d^2
\phi_i}{d x_k d x_m}
- H_{mkl} \frac{d^2 \phi_i}{d x_j d x_m} - H_{mjk} \frac{d^2 \phi_i}{d x_l
d x_m}
- K_{mjkl} \frac{d \phi_i}{d x_m},
-\]](form_1145_dark.png)
@@ -509,7 +509,7 @@
![\[
R_0 = \left(\begin{matrix}1 & 0 \\ 0 & 0\end{matrix}\right),
\qquad\qquad
R_1 = \left(\begin{matrix}0 & 0 \\ 0 & 1\end{matrix}\right).
- \]](form_1018_dark.png)
![\[
R_0 = \left(\begin{matrix}1 & 0 & 0 \\ 0 & 0 & 0 \\ 0 & 1 & 0
\end{matrix}\right), \qquad\qquad R_1 = \left(\begin{matrix}0 & 0 & 0 \\ 0 &
1 & 0 \\ 1 & 0 & 0 \end{matrix}\right),
- \]](form_1023_dark.png)
![\[ f = \chi(B_r(c)). \]](form_487_dark.png)
![\[ f = \chi(B_r(c)). \]](form_477_dark.png)
![$[x_0,x_1]$](form_494_dark.png)
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFunctions_1_1SignedDistance_1_1Sphere.html differs (JavaScript source, ASCII text, with very long lines (2228))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFunctions_1_1SignedDistance_1_1Sphere.html 2023-11-25 15:25:56.009969058 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFunctions_1_1SignedDistance_1_1Sphere.html 2023-11-25 15:25:56.009969058 +0100
@@ -213,9 +213,9 @@
/usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFunctions_1_1Spherical.html differs (JavaScript source, ASCII text, with very long lines (1010))
--- old//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFunctions_1_1Spherical.html 2023-11-25 15:25:56.049968243 +0100
+++ new//usr/share/doc/packages/dealii-openmpi4/doxygen/deal.II/classFunctions_1_1Spherical.html 2023-11-25 15:25:56.049968243 +0100
@@ -216,7 +216,7 @@
![$QR= A = [a_1\,\dots a_n], \quad a_i \in R^m$](form_1777_dark.png)
![$\tilde Q \tilde R= \tilde A = [a_2\,\dots a_n], \quad a_i \in R^m$](form_1778_dark.png)
![\[ n_F\int_F
\left|g-a\frac{\partial u_h}{\partial n}\right|^2 ds \]](form_2200_dark.png)
![$(\rm{lower\_bound}, \rm{upper\_bound}]$](form_1695_dark.png)
![$[a,b]$](form_1697_dark.png)
![$[0,1]^\text{dim}$](form_82_dark.png)
![\[
J(\hat{\mathbf x}) = \left(\begin{matrix}
\frac{\partial x}{\partial \hat x} & \frac{\partial x}{\partial \hat y}
\\
\frac{\partial y}{\partial \hat x} & \frac{\partial y}{\partial \hat y}
\end{matrix}\right)
-\]](form_1265_dark.png)
![\[
\int_K u(\mathbf x)\,dx = \int_{\hat K} \hat
u(\hat{\mathbf x}) \left|\text{det}J(\hat{\mathbf x})\right|
\,d\hat x.
-\]](form_1268_dark.png)
![$\mathbf\in [0,1]^d$](form_1260_dark.png)
![$\mathbf\in [0,1]^d$](form_1282_dark.png)
![\[
\mathbf T(\mathbf x) =
\frac{1}{\text{det}\;J(\hat{\mathbf x})}
J(\hat{\mathbf x}) \hat{\mathbf T}(\hat{\mathbf x})
J(\hat{\mathbf x})^{-1}.
-\]](form_1298_dark.png)
![\[J^{\dagger} = J^{-1}\]](form_1279_dark.png)
NonMatching::FEValues. The domain is assumed to be described by a level set function, 
![\[
N = \{x \in F : \psi(x) < 0 \}, \\
P = \{x \in F : \psi(x) > 0 \},
-\]](form_2029_dark.png)
![$[0, 1]^{dim-1}$](form_2063_dark.png)
![$[0, 1]^{dim-1}$](form_2030_dark.png)
![\[
N = \{x \in K : \psi(x) < 0 \}, \\
P = \{x \in K : \psi(x) > 0 \}, \\
S = \{x \in K : \psi(x) = 0 \}.
-\]](form_2026_dark.png)
![$[0, 1]^{dim}$](form_2057_dark.png)
![$[0, 1]^{dim}$](form_2028_dark.png)
![\[
N = \{x \in F : \psi(x) < 0 \}, \\
P = \{x \in F : \psi(x) > 0 \}, \\
S = \{x \in F : \psi(x) = 0 \},
-\]](form_2069_dark.png)
![\[
\int_{S\cap K} f dS =
\int_{S\cap K} f |d\bar{S}| =
\int_{\hat{S}\cap\hat{K}} f \circ F_{K} \det(J) |\left( J^{-1} \right
)^T d\hat{S}|,
-\]](form_2043_dark.png)
![\[
\Delta \hat{S}_q \dealcoloneq w_q \hat{n}_q \approx d\hat{S}(\hat{x}_q),
-\]](form_2046_dark.png)
![$t \in [0,T]$](form_2049_dark.png)
![\[
\Omega = \{ x \in \mathbb{R}^{dim} : \psi(x) < 0 \}.
-\]](form_2064_dark.png)
![$[x_0, x_1, ..., x_n]$](form_2130_dark.png)
![$[L, R]$](form_2101_dark.png)
![$[x_i, x_{i+1}]$](form_2133_dark.png)
![$[x_1, x_{n-1}]$](form_2134_dark.png)
![$[x_0, x_1, ..., x_n]$](form_2120_dark.png)
![$[L, R]$](form_2092_dark.png)
![$[a, b]$](form_2081_dark.png)
![$[l, (r + l) / 2]$](form_2082_dark.png)
![$[(r + l) / 2, r]$](form_2083_dark.png)
![$I \times [L, R] \subset \mathbb{R}^{dim}$](form_2103_dark.png)
![$[y_0, y_1, ..., y_n]$](form_2108_dark.png)
![$[y_i, y_{i+1}]$](form_2112_dark.png)
![$[A-\sigma B]^{-1}$](form_1723_dark.png)
![\[
\frac{\partial J}{\partial \mathbf{C}}
= \frac{1}{2} J \mathbf{C}^{-1}
-\]](form_2461_dark.png)
![\[
\mathcal{S} : \{ \hat{\bullet} \}
\dealcoloneq \dfrac{1}{2}
\left[ \{ \hat{\bullet} \} + \{ \hat{\bullet} \}^T \right] \, .
-\]](form_2445_dark.png)
![\[
\mathcal{S} : \{ \bullet \}
= \{ \bullet \} : \mathcal{S} = \{ \bullet \} \, .
-\]](form_2447_dark.png)
![$[0,\text{dim}^{\text{rank}}-1]$](form_865_dark.png)
![$[0,\text{dim}^{\text{rank}}-1]$](form_862_dark.png)
![$[0, \text{dim}^{\text{rank}}-1]$](form_866_dark.png)
![\[
\text{result}_{i_1,\ldots,i_{r1},j_1,\ldots,j_{r2}}
= \sum_{k}
\text{left}_{i_1,\ldots,i_{r1}, k}
\text{right}_{k, j_1,\ldots,j_{r2}}
-\]](form_827_dark.png)
![$x \in [0,1]$](form_667_dark.png)
![$[0,x_0]$](form_728_dark.png)
![$[x_0,1]$](form_729_dark.png)
![\[ \int_0^1 g(x) dx = \int_0^1 f(x)
\ln\left(\frac{|x-x_0|}{\alpha}\right) dx = \sum_{i=0}^N w_i g(q_i) =
\sum_{i=0}^N \bar{w}_i f(q_i) \]](form_730_dark.png)
![$[0,1]^2$](form_735_dark.png)
![$QR= A = [a_1\,\dots a_n], \quad a_i \in {\mathbb R}^m$](form_1770_dark.png)
![$\tilde Q \tilde R= \tilde A = [a_2\,\dots a_n], \quad a_i \in {\mathbb
-R}^m$](form_1771_dark.png)
QR decomposition 
![\[
a_i \dealcoloneq
M y_{n-1} + h_n \sum_{j=1}^{i-1} [ A^E_{i,j} f_E(t^E_{n,j}, z_j)
+ A^I_{i,j} f_I (t^I_{n,j}, z_j)]
- \]](form_2574_dark.png)
![\[
N(z_i^m) \delta^{m+1} = -G(z_i^m),
- \]](form_2581_dark.png)
ARKode may solve for each stage 
![\[
z_i^{m+1} = g(z_i^{m}), m=0,1,\ldots.
- \]](form_2584_dark.png)
![\[
A \dealcoloneq
\begin{pmatrix}
0 & 1 \\
-k^2 &0
\end{pmatrix}
- \]](form_2595_dark.png)
![$t\in[0,1]$](form_1392_dark.png)
![$t\in[0,1]$](form_1453_dark.png)
-
![\[
\mathbb S : \mathbf A = \mathbf A
\]](form_777_dark.png)
![$I_2(\mathbf A) = II(\mathbf A) = \frac 12
\left[ (A_{11} + A_{22})^2 - (A_{11}^2+2 A_{12}^2+ A_{22}^2) \right]
- = A_{11} A_{22} - A_{12}^2$](form_810_dark.png)
![$\lambda_1, \lambda_2 = \frac{1}{2} \left[ \text{tr} \mathbf{T} \pm
\sqrt{(\text{tr} \mathbf{T})^2 - 4 \det \mathbf{T}} \right]$](form_813_dark.png)
![$[\nabla_u F(u)]^{-1}$](form_2682_dark.png)
![$[0, 1]^d$](form_1318_dark.png)
Wikipedia article), let us think about the representation of the calculation of the function 
![$f(x,y) = [2x+1]^{y}$](form_22_dark.png)
![$\dfrac{d f(x,y)}{d x} = 2y[2x+1]^{y-1}$](form_25_dark.png)
![$\dfrac{d f(x,y)}{d y} = [2x+1]^{y} \ln(2x+1)$](form_26_dark.png)
![$\dfrac{d f(x, y)}{d x} \rightarrow \dfrac{\partial f(x, y(x))}{\partial x} = 2y(x) [2x+1]^{y(x)-1} = 4x[2x+1]^{2x-1}$](form_33_dark.png)
![\begin{align*}
\mathbf S(u,v) &= (1-v)\mathbf c_0(u)+v \mathbf c_1(u) + (1-u)\mathbf c_2(v) + u \mathbf c_3(v) \\
&\quad - \left[(1-u)(1-v) \mathbf x_0 + u(1-v) \mathbf x_1 + (1-u)v \mathbf x_2 + uv \mathbf x_3 \right]
- \end{align*}](form_206_dark.png)
primitive element: an element that may be vector-valued but where each shape function has exactly one non-zero component. In other words: if the 
![$f = [3+a]_{a=1} = 4$](form_938_dark.png)
![$f = [3+a]_{a=1} = 4$](form_929_dark.png)
![$f\vert_{a=b+2, b} = [b+2+b]_{b=1} = 4$](form_942_dark.png)
![$f\vert_{a=b+2, b} = [b+2+b]_{b=1} = 4$](form_933_dark.png)
![$\Psi_i[\varphi_j] = \delta_{ij}$](form_1213_dark.png)
![\begin{align*}
\Psi_i [\varphi_j] = \sum_{k=1}^N c_{jk} \Psi_i[\tilde\varphi_k],
-\end{align*}](form_1215_dark.png)
![$f(x) \in [L, U]$](form_538_dark.png)
![$\partial_i f \in [\partial_i f(x_c) - G_i, \partial_i f(x_c) + G_i]$](form_540_dark.png)
![$\partial_i f \in [\partial_i f(x_c) - G_i, \partial_i f(x_c) + G_i]$](form_542_dark.png)
![$ \in [0,\pi]$](form_545_dark.png)
![$\phi \in [0,\pi]$](form_547_dark.png)
@@ -339,7 +339,7 @@
![$[0, 2.2] \times [0, 0.41] \times [0, 0.41] $](form_1321_dark.png)
![$[0,L]$](form_1361_dark.png)
![\[
a E \le \sum_{K\in \cal M} c_K
-\]](form_1371_dark.png)
![\[
N(m) = (N_0-m) + 2^d m = N_0 + (2^d-1)m
-\]](form_1375_dark.png)
![\[
J(m) = N(m)^{\text{order}/d} \eta^\text{exp}(m)
-\]](form_1381_dark.png)
