Detailed Description

Manage the distribution and numbering of the degrees of freedom for hp- FEM algorithms. This class satisfies the MeshType concept requirements.

The purpose of this class is to allow for an enumeration of degrees of freedom in the same way as the DoFHandler class, but it allows to use a different finite element on every cell. 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 \(Q_2\) and \(Q_3\) 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, calls hp::DoFHandler::distribute_dofs(), and then assemble a linear system and solve a problem on this finite element space. However, one can skip assigning active FE indices upon mesh refinement in certain circumstances. In particular, the following rules apply:

Upon mesh refinement, child cells inherit the active FE index of the parent.

On the other hand, when coarsening cells, the (now active) parent cell will not have an active FE index set and you will have to set it explicitly before calling hp::DoFHandler::distribute_dofs(). In particular, to avoid stale information to be used by accident, this class deletes the active FE index of cells that are refined after inheriting this index to the children; this implies that if the children are coarsened away, the old value is no longer available on the parent cell.

Ghost cells do acquire the information what element is active on them, however: whenever you call hp::DoFHandler::distribute_dofs(), all processors that participate in the parallel mesh exchange information in such a way that the active FE index on ghost cells equals the active FE index that was set on that processor that owned that particular ghost cell. Consequently, one can query the active_fe_index on ghost cells, just not set it by hand.

On artificial cells, no information is available about the active_fe_index used there. That's because we don't even know whether these cells exist at all, and even if they did, the current processor does not know anything specific about them. See the glossary entry on artificial cells for more information.

Copy constructor. DoFHandler objects are large and expensive. They should not be copied, in particular not by accident, but rather deliberately constructed. As a consequence, this constructor is explicitly removed from the interface of this class.

Member Function Documentation

Copy operator. DoFHandler objects are large and expensive. They should not be copied, in particular not by accident, but rather deliberately constructed. As a consequence, this operator is explicitly removed from the interface of this class.

Go through the triangulation and "distribute" the degrees of freedoms 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 \(V_h\), 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.

Renumber degrees of freedom based on a list of new DoF indices for each of the degrees of freedom.

This function is called by the functions in DoFRenumbering function after computing a new ordering of the degree of freedom indices. However, it can of course also be called from user code.

new_number This array must have a size equal to the number of degrees of freedom owned by the current processor, i.e. the size must be equal to what n_locally_owned_dofs() returns. If only one processor participates in storing the current mesh, then this equals the total number of degrees of freedom, i.e. the result of n_dofs(). The contents of this array are the new global indices for each freedom listed in the IndexSet returned by locally_owned_dofs(). In the case of a sequential mesh this means that the array is a list of new indices for each of the degrees of freedom on the current mesh. In the case that we have a parallel::shared::Triangulation or parallel::distributed::Triangulation underlying this DoFHandler object, the array is a list of new indices for all the locally owned degrees of freedom, enumerated in the same order as the currently locally owned DoFs. In other words, assume that degree of freedom i is currently locally owned, then new_numbers[locally_owned_dofs().index_within_set(i)] returns the new global DoF index of i. Since the IndexSet of locally_owned_dofs() is complete in the sequential case, the latter convention for the content of the array reduces to the former in the case that only one processor participates in the mesh.

Note

While it follows from the above, it may be surprising to know that the number of locally owned degrees of freedom in a parallel computation is an invariant under renumbering, even if the indices associated with these locally owned degrees of freedom are not. At a fundamental level, this invariant exists because the decision whether a degree of freedom is locally owned or not has nothing to do with that degree of freedom's (old or new) index. Indeed, degrees of freedom are locally owned if they are on a locally owned cell and not on an interface between cells where the neighboring cell has a lower subdomain id. Since both of these conditions are independent of the index associated with the DoF, a locally owned degree of freedom will also be locally owned after renumbering. On the other hand, properties such as whether the set of indices of locally owned DoFs forms a contiguous range or not (i.e., whether the locally_owned_dofs() returns an IndexSet object for which IndexSet::is_contiguous() returns true) are of course affected by the exact renumbering performed here. For example, while the initial numbering of DoF indices done in distribute_dofs() yields a contiguous numbering, the renumbering performed by DoFRenumbering::component_wise() will, in general, not yield contiguous locally owned DoF indices.

Return the maximum number of degrees of freedom a degree of freedom in the given triangulation with the given finite element may couple with. This is the maximum number of entries per line in the system matrix; this information can therefore be used upon construction of the SparsityPattern object.

The returned number is not really the maximum number but an estimate based on the finite element and the maximum number of cells meeting at a vertex. The number holds for the constrained matrix also.

Iterator to the first active cell on level level. If the given level does not contain any active cells (i.e., all cells on this level are further refined, then this function returns end_active(level) so that loops of the kind

Return the global number of degrees of freedom. If the current object handles all degrees of freedom itself (even if you may intend to solve your linear system in parallel, such as in step-17 or step-18), then this number equals the number of locally owned degrees of freedom since this object doesn't know anything about what you want to do with it and believes that it owns every degree of freedom it knows about.

On the other hand, if this object operates on a parallel::distributed::Triangulation object, then this function returns the global number of degrees of freedom, accumulated over all processors.

Mathematically speaking, the number returned by this function equals the dimension of the finite element space (without taking into account constraints) that corresponds to (i) the mesh on which it is defined, and (ii) the finite element that is used by the current object. It also, of course, equals the number of shape functions that span this space.

Return the number of degrees of freedom located on those parts of the boundary which have a boundary indicator listed in the given set. The reason that a map rather than a set is used is the same as described in the documentation of that variant of DoFTools::make_boundary_sparsity_pattern() that takes a map. To this end, the type of the boundary_ids argument is the same as typename FunctionMap<spacedim,number>::type.

There is, however, another overload of this function that takes a set argument (see below).

If this is a sequential DoFHandler, then the result equals that produced by n_dofs(). (Here, "sequential" means that either the whole program does not use MPI, or that it uses MPI but only uses a single MPI process, or that there are multiple MPI processes but the Triangulation on which this DoFHandler builds works only on one MPI process.) On the other hand, if we are operating on a parallel::distributed::Triangulation or parallel::shared::Triangulation, then it includes only the degrees of freedom that the current processor owns. Note that in this case this does not include all degrees of freedom that have been distributed on the current processor's image of the mesh: in particular, some of the degrees of freedom on the interface between the cells owned by this processor and cells owned by other processors may be theirs, and degrees of freedom on ghost cells are also not necessarily included.

Return a vector that stores the locally owned DoFs of each processor. If you are only interested in the number of elements each processor owns then n_dofs_per_processor() is a better choice.

If this is a sequential DoFHandler, then the vector has a single element that equals the IndexSet representing the entire range [0,n_dofs()]. (Here, "sequential" means that either the whole program does not use MPI, or that it uses MPI but only uses a single MPI process, or that there are multiple MPI processes but the Triangulation on which this DoFHandler builds works only on one MPI process.)

Return a vector that stores the number of degrees of freedom each processor that participates in this triangulation owns locally. The sum of all these numbers equals the number of degrees of freedom that exist globally, i.e. what n_dofs() returns.

Each element of the vector returned by this function equals the number of elements of the corresponding sets returned by global_dof_indices().

If this is a sequential DoFHandler, then the vector has a single element equal to n_dofs(). (Here, "sequential" means that either the whole program does not use MPI, or that it uses MPI but only uses a single MPI process, or that there are multiple MPI processes but the Triangulation on which this DoFHandler builds works only on one MPI process.)

Return an IndexSet describing the set of locally owned DoFs used for the given multigrid level. Since hp::DoFHandler does not support multilevel methods yet, this function throws an exception ExcNotImplemented() independent of its argument.

Return a vector that stores the locally owned level DoFs of each processor on the given level level. Since hp::DoFHandler does not support multilevel methods yet, this function throws an exception ExcNotImplemented() independent of its argument.

Create default tables for the active_fe_indices in the internal::hp::DoFLevel. They are initialized with a zero indicator, meaning that fe[0] is going to be used by default. This method is called before refinement and before distribute_dofs is called. It ensures each cell has a valid active_fe_index.

When the arrays holding the DoF indices are set up, but before they are filled with actual values, they are set to an invalid value, in order to monitor possible problems. This invalid value is the constant defined here.

Please note that you should not rely on it having a certain value, but rather take its symbolic name.

The default index of the finite element to be used on a given cell. For the usual, non-hp DoFHandler class that only supports the same finite element to be used on all cells, the index of the finite element needs to be the same on all cells anyway, and by convention we pick zero for this value. The situation here is different, since the hp classes support the case where different finite element indices may be used on different cells. The default index consequently corresponds to an invalid value.

Store a pointer to the finite element set given latest for the distribution of dofs. In order to avoid destruction of the object before the lifetime of the DoF handler, we subscribe to the finite element object. To unlock the FE before the end of the lifetime of this DoF handler, use the clear() function (this clears all data of this object as well, though).

Array to store the indices for degrees of freedom located at vertices.

The format used here, in the form of a linked list, is the same as used for the arrays used in the internal::hp::DoFLevel hierarchy. Starting indices into this array are provided by the vertex_dof_offsets field.

Access to this field is generally through the DoFAccessor::get_vertex_dof_index() and DoFAccessor::set_vertex_dof_index() functions, encapsulating the actual data format used to the present class.

Array to store the information if a cell on some level has children or not. It is used by the signal slots as a persistent buffer during the refinement, i.e. from between when pre_refinement_action is called and when post_refinement_action runs.