 |
deal.II version 9.7.1
|
|
deal.II version 9.7.1
|
Topics | |
| Accessor classes of the mesh iterators | |
Namespaces | |
| namespace | IteratorFilters |
| namespace | IteratorState |
Typedefs | |
| using | parallel::distributed::Triangulation< dim, spacedim >::cell_iterator |
| using | parallel::distributed::Triangulation< dim, spacedim >::active_cell_iterator |
| using | cell_accessor = typename ActiveSelector::CellAccessor |
| using | face_accessor = typename ActiveSelector::FaceAccessor |
| using | line_iterator = typename ActiveSelector::line_iterator |
| using | active_line_iterator = typename ActiveSelector::active_line_iterator |
| using | quad_iterator = typename ActiveSelector::quad_iterator |
| using | active_quad_iterator = typename ActiveSelector::active_quad_iterator |
| using | hex_iterator = typename ActiveSelector::hex_iterator |
| using | active_hex_iterator = typename ActiveSelector::active_hex_iterator |
| using | active_cell_iterator = typename ActiveSelector::active_cell_iterator |
| using | cell_iterator = typename ActiveSelector::cell_iterator |
| using | face_iterator = typename ActiveSelector::face_iterator |
| using | active_face_iterator = typename ActiveSelector::active_face_iterator |
| using | Triangulation< dim, spacedim >::cell_iterator = TriaIterator<CellAccessor<dim, spacedim>> |
| using | Triangulation< dim, spacedim >::active_cell_iterator = TriaActiveIterator<CellAccessor<dim, spacedim>> |
| using | Triangulation< dim, spacedim >::face_iterator = TriaIterator<TriaAccessor<dim - 1, dim, spacedim>> |
| using | Triangulation< dim, spacedim >::active_face_iterator |
| using | Triangulation< dim, spacedim >::vertex_iterator = TriaIterator<::TriaAccessor<0, dim, spacedim>> |
| using | Triangulation< dim, spacedim >::active_vertex_iterator |
| using | Triangulation< dim, spacedim >::line_iterator = typename IteratorSelector::line_iterator |
| using | Triangulation< dim, spacedim >::active_line_iterator = typename IteratorSelector::active_line_iterator |
| using | Triangulation< dim, spacedim >::quad_iterator = typename IteratorSelector::quad_iterator |
| using | Triangulation< dim, spacedim >::active_quad_iterator = typename IteratorSelector::active_quad_iterator |
| using | Triangulation< dim, spacedim >::hex_iterator = typename IteratorSelector::hex_iterator |
| using | Triangulation< dim, spacedim >::active_hex_iterator = typename IteratorSelector::active_hex_iterator |
deal.II has several classes which are understood conceptually as meshes. Apart from the obvious Triangulation, there is, for example, the DoFHandler. All of those define a set of iterators, allowing the user to traverse the whole mesh, i.e. the set of cells, faces, edges, etc that comprise the mesh, or portions of it. These iterators are all in a sense derived from the TriaIterator class.
Basically, the template signature of TriaIterator is
Conceptually, this type represents something like a pointer to an object represented by the Accessor class. Usually, you will not use the actual class names spelled out directly, but employ one of the typedefs provided by the mesh classes, such as typename
Triangulation::cell_iterator. Before going into this, let us first discuss the concept of iterators, before delving into what the accessors do.
As usual in C++, iterators, just as pointers, are incremented to the next element using operator ++, and decremented to the previous element using operator –. One can also jump n elements ahead using the addition operator, it=it+n, and correspondingly to move a number of elements back. In addition, and keeping with the tradition of the standard template library, meshes provide member functions begin() and end() that provide the first element of a collection and a one-past-the-end iterator, respectively. Since there are a number of different iterators available, there is actually a whole family of such functions, such as begin_active(), begin_face(), etc.
In terms of the concepts for iterators defined in the C++ standard, the deal.II mesh iterators are bi-directional iterators: they can be incremented and decremented, but an operation like it=it+n takes a compute time proportional to n, since it is implemented as a sequence of n individual unit increments. Note that this is in contrast to the next more specialized iterator concept, random access iterators, for which access to an arbitrary object requires only constant time, rather than linear.
As mentioned above, iterators in deal.II can be considered as iterating over all the objects that constitute a mesh. (These objects are lines, quads, and hexes, and are represented by the type of Accessor class given as template argument to the iterator.) This suggests to view a triangulation as a collection of cells and other objects that are held together by a certain data structure that links all these objects, in the same was as a linked list is the data structure that connects objects in a linear fashion.
Triangulations in deal.II can indeed be considered in this way. In particular, they use the computational notion of a forest of regular trees to store their data. This can be understood as follows: Consider the cells of the coarse mesh as roots; then, if one of these coarse mesh cells is refined, it will have 2dim children, which in turn can, but do not have to have 2dim children of their own, and so on. This means, that each cell of the coarse mesh can be considered the root of a binary tree (in 1d), a quadtree (in 2d), or an octree (in 3d). The collection of these trees emanating from the cells of the coarse mesh then constitutes the forest that completely describes the triangulation, including all of its active and inactive cells. In particular, the active cells are those terminal nodes in the tree that have no descendants, i.e. cells which are not further refined. Correspondingly, inactive cells correspond to nodes in the tree with descendants, i.e. cells that are further refined.
A triangulation contains forests for lines (each of which may have 2 children), quads (each with possibly four children), and hexes (each with no or 8 children). Depending on the dimension, these objects are also termed cells or faces.
Iterators loop over the elements of such forests. While the usual iterators loop over all nodes of a forest, active iterators iterate over the elements in the same order, but skip all non-active entries and therefore only visit terminal nodes (i.e. active cells, faces, etc). There are many ways to traverse the elements of a forest, for example breadth first or depth first. Depending on the type of data structure used to store the forest, some ways are more efficient than others. At present, the way iterators traverse forests in deal.II is breadth first. I.e., iterators first visit all the elements (cells, faces, etc) of the coarse mesh before moving on to all the elements of the immediate level, i.e. the immediate children of the coarse mesh objects; after this come the grandchildren of the coarse mesh, and so on. However, it must be noted that programs should not rely on this particular order of traversing a tree: this is considered an implementation detail that can change between versions, even if we consider this an unlikely option at the present time.
Iterators have two properties: what they point to (i.e. the type of the Accessor template argument), and the exact definition of the set they iterate over. In general, iterators are always declared as
Here, Kind determines what property an accessor needs to have to be reached by this iterator (or omitted, for that matter). For example,
iterates over all objects of kind Accessor that make up the mesh (for example all cells, whether they are further refined and have children, or not), whereas
skips all objects that have children, i.e. objects that are not active. Active iterators therefore operate on a subset of the objects that normal iterators act on, namely those that possess the property that they are active. Note that this is independent of the kind of object we are operating on: all valid accessor classes have to provide the iterator classes a method to find out whether they are active or not.
(For completeness, let us mention that there is a third kind of iterators: "raw iterators" also traverse objects that are unused in the triangulation, but allocated anyway for efficiency reasons. User code should never use raw iterators, they are only for internal purposes of the library.)
Whether an object is active can be considered a "predicate": a property that is either true or false. Filtered iterators can be used to restrict the scope of existing iterators even more. For instance, you could imagine to iterate over the subset of those active cells having their user flag set or belonging to a certain subdomain (both properties are either true or false for a given object).
This is achieved by using an object of type FilteredIterator <BaseIterator>, where BaseIterator usually is one of the standard iterators discussed above.
The FilteredIterator gets an additional Predicate in its constructor and will skip all objects where this Predicate evaluates to false. A collection of predicates already implemented can be found in the namespace IteratorFilters.
All iterators of the same kind and iterating over the same kind of geometrical objects traverse the mesh in the same order. Take this code example:
Here, all iterators will always point to the same mesh cell, even though DoFHandler and Triangulation are very different classes, and even if the DoFHandlers are handling different finite elements: they all access cells in the same order, the difference is only in the Accessor. As mentioned above, the order in which iterators traverse the forest of objects is actually well-defined, but application programs should not assume any such order, but rather consider this an implementation detail of the library.
Corresponding to above example, the order in which iterators traverse active objects is the same for all iterators in the following snippet, the difference to the previous example being that here we only consider active cells:
Iterators are like pointers: they can be incremented and decremented, but they are really rather dumb. Their magic only lies in the fact that they point to some useful object, in this case the Accessor. For pointers, they point to an actual object that stores some data. On the other hand, the deal.II iterators, when dereferenced, do not return a reference to an actual object, but return an object that knows how to get at the data that represents cells. In general, this object doesn't store itself where the vertices of a cell are or what its neighbors are. However, it knows how to tease this sort of information from out of the arrays and tables and lists that the Triangulation class sets up to describe a mesh.
Accessing data that characterizes a cell is always done through the Accessor, i.e. the expression i->xxx() grants access to all attributes of this Accessor. Examples of properties you can query from an iterator are
Since dereferencing iterators yields accessor objects, these calls are to member functions Accessor::vertex(), Accessor::child() etc. These in turn figure out the relevant data from the various data structures that store this data. How this is actually done and what data structures are used is not really of concern to authors of applications in deal.II. In particular, by hiding the actual data structures we are able to store data in an efficient way, not necessarily in a way that makes it easily accessible or understandable to application writers.
Depending on what sort of data you want to access, there are different kinds of accessor classes:
Except to look up member documentation, you will not usually have to deal with the actual class names listed above. Rather, one uses the typedefs provided by the mesh classes Triangulation and DoFHandler, as well as the function that generate such objects:
| Class | cell_iterator type | function call |
|---|---|---|
| Triangulation | typename Triangulation::cell_iterator | Triangulation::begin() |
| DoFHandler | typename DoFHandler::cell_iterator | DoFHandler::begin() |
The Triangulation class supports iterating across cell faces with typename Triangulation::face_iterator, which is the type returned by Triangulation::begin_face().
Active iterators have the following properties:
| Class | cell_iterator type | function call |
|---|---|---|
| Triangulation | typename Triangulation::active_cell_iterator | Triangulation::begin_active() |
| DoFHandler | typename DoFHandler::active_cell_iterator | DoFHandler::begin_active() |
The Triangulation class also supports iterating across active cell faces with typename Triangulation::active_face_iterator, which is the type returned by Triangulation::begin_active_face().
In addition to these types and calls that act on cells and faces (logical concepts that depend on the dimension: a cell is a quadrilateral in 2d, but a hexahedron in 3d), there are corresponding types and calls like begin_active_quad() or end_quad() that act on the dimension independent geometric objects line, quad, and hex. These calls, just as the ones above, exist in active and non-active forms.
The actual definition of all the typedefs local to the mesh classes are stated in the
Iterators, being like pointers, act as if they pointed to an actual object, but in reality all they do is to return an accessor when dereferenced. The accessor object contains the state, i.e. it knows which object it represents, by storing for example which Triangulation it belongs to, and the level and index within this level of a cell. It is therefore able to access the data that corresponds to the cell (or face, or edge) it represents
There is a representation of past-the-end-pointers, denoted by special values of the member variables present_level and present_index in the TriaAccessor class: If present_level > =0 and present_index > =0, then the object is valid; if present_level==-1 and present_index==-1, then the iterator points past the end; in all other cases, the iterator is considered invalid. You can check this by calling the TriaAccessorBase::state() function.
Past-the-end iterators may also be used to compare an iterator with the before-the-start value, when running backwards. There is no distinction between the iterators pointing past the two ends of a vector.
Cells are stored based on a hierarchical structure of levels, therefore the above mentioned structure is useful. Faces however are not organized in levels, and accessors for objects of lower dimensionality do not have a present_level member variable.
| using parallel::distributed::Triangulation< dim, spacedim >::cell_iterator |
An alias that is used to identify cell iterators. The concept of iterators is discussed at length in the iterators documentation topic.
The current alias identifies cells in a triangulation. You can find the exact type it refers to in the base class's own alias, but it should be TriaIterator<CellAccessor<dim,spacedim> >. The TriaIterator class works like a pointer that when you dereference it yields an object of type CellAccessor. CellAccessor is a class that identifies properties that are specific to cells in a triangulation, but it is derived (and consequently inherits) from TriaAccessor that describes what you can ask of more general objects (lines, faces, as well as cells) in a triangulation.
| using parallel::distributed::Triangulation< dim, spacedim >::active_cell_iterator |
An alias that is used to identify active cell iterators. The concept of iterators is discussed at length in the iterators documentation topic.
The current alias identifies active cells in a triangulation. You can find the exact type it refers to in the base class's own alias, but it should be TriaActiveIterator<CellAccessor<dim,spacedim> >. The TriaActiveIterator class works like a pointer to active objects that when you dereference it yields an object of type CellAccessor. CellAccessor is a class that identifies properties that are specific to cells in a triangulation, but it is derived (and consequently inherits) from TriaAccessor that describes what you can ask of more general objects (lines, faces, as well as cells) in a triangulation.
| using cell_accessor = typename ActiveSelector::CellAccessor |
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 
It is first used in the step-2 tutorial program.
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.
The spacedim parameter has to be used if one wants to solve problems on surfaces. If not specified, this parameter takes the default value =dim implying that we want to solve problems in a domain whose dimension equals the dimension of the space in which it is embedded.
The degrees of freedom (`dofs') are distributed on the given triangulation by the function distribute_dofs(). It gets passed a finite element object describing how many degrees of freedom are located on vertices, lines, etc. It traverses the triangulation cell by cell and numbers the dofs of that cell if not yet numbered. For non-multigrid algorithms, only active cells are considered. Active cells are defined to be those cells which have no children, i.e. they are the most refined ones.
Since the triangulation is traversed starting with the cells of the coarsest active level and going to more refined levels, the lowest numbers for dofs are given to the largest cells as well as their bounding lines and vertices, with the dofs of more refined cells getting higher numbers.
This numbering implies very large bandwidths of the resulting matrices and is thus vastly suboptimal for some solution algorithms. For this reason, the DoFRenumbering class offers several algorithms to reorder the dof numbering according. See there for a discussion of the implemented algorithms.
Upon construction, this class takes a reference to a triangulation object. In most cases, this will be a reference to an object of type Triangulation, i.e. the class that represents triangulations that entirely reside on a single processor. However, it can also be of type parallel::distributed::Triangulation (see, for example, step-32, step-40 and in particular the Parallel computing with multiple processors using distributed memory topic) in which case the DoFHandler object will proceed to only manage degrees of freedom on locally owned and ghost cells. This process is entirely transparent to the used.
The DoFRenumbering class offers a number of renumbering schemes like the Cuthill-McKee scheme. Basically, the function sets up an array in which for each degree of freedom we store the new index this DoF should have after renumbering. Using this array, the renumber_dofs() function of the present class is called, which actually performs the change from old DoF indices to the ones given in the array. In some cases, however, a user may want to compute their own renumbering order; in this case, one can allocate an array with one element per degree of freedom and fill it with the number that the respective degree of freedom shall be assigned. This number may, for example, be obtained by sorting the support points of the degrees of freedom in downwind direction. Then call the renumber_dofs(vector<types::global_dof_index>) function with the array, which converts old into new degree of freedom indices.
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.
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 
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.
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.
Active FE indices will be automatically transferred during mesh adaptation from the old to the new mesh. Future FE indices are meant to determine the active FE index after mesh adaptation, and are used to prepare data on the old mesh for the new one. If no future FE index is specified, the finite element prevails.
In particular, the following rules apply during adaptation:
Strategies for automatic hp-adaptation which will set future FE indices based on criteria are available in the hp::Refinement namespace.
When this class is used with either a parallel::shared::Triangulation or a parallel::distributed::Triangulation, you can only set active FE indices on cells that are locally owned, using a call such as cell->set_active_fe_index(...). On the other hand, setting the active FE index on ghost or artificial cells is not allowed.
Ghost cells do acquire the information what element is active on them, however: whenever you call 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.
During refinement and coarsening, information about the active_fe_index of each cell will be automatically transferred.
However, using a parallel::distributed::Triangulation with a DoFHandler in hp-mode requires additional attention during serialization, since no information on active FE indices will be automatically transferred. This has to be done manually using the prepare_for_serialization_of_active_fe_indices() and deserialize_active_fe_indices() functions. The former has to be called before parallel::distributed::Triangulation::save() is invoked, and the latter needs to be run after parallel::distributed::Triangulation::load(). If further data will be attached to the triangulation via the parallel::distributed::CellDataTransfer, parallel::distributed::SolutionTransfer, or Particles::ParticleHandler classes, all corresponding preparation and deserialization function calls need to happen in the same order. Consult the documentation of parallel::distributed::SolutionTransfer for more information.
@dealiiConceptRequires{(concepts::is_valid_dim_spacedim<dim, spacedim>)} */ template <int dim, int spacedim = dim>
class DoFHandler : public EnableObserverPointer { using ActiveSelector = internal::DoFHandlerImplementation::Iterators<dim, spacedim, false>; using LevelSelector = internal::DoFHandlerImplementation::Iterators<dim, spacedim, true>;
public: /** An alias that is used to identify cell iterators in DoFHandler objects. The concept of iterators is discussed at length in the iterators documentation topic.
The current alias works, in essence, like the corresponding Triangulation::cell_accessor alias. However, it also makes available the member functions of DoFCellAccessor, in addition to the ones already available through the CellAccessor class.
Definition at line 344 of file dof_handler.h.
| using face_accessor = typename ActiveSelector::FaceAccessor |
An alias that is used to identify iterators that point to faces. The concept of iterators is discussed at length in the iterators documentation topic.
The current alias works, in essence, like the corresponding Triangulation::face_accessor alias. However, it also makes available the member functions of DoFAccessor, in addition to the ones already available through the TriaAccessor class.
Definition at line 358 of file dof_handler.h.
| using line_iterator = typename ActiveSelector::line_iterator |
An alias that defines an iterator over the (one-dimensional) lines of a mesh. In one-dimensional meshes, these are the cells of the mesh, whereas in two-dimensional meshes the lines are the faces of cells.
Definition at line 367 of file dof_handler.h.
| using active_line_iterator = typename ActiveSelector::active_line_iterator |
An alias that allows iterating over the active lines, i.e., that subset of lines that have no children. In one-dimensional meshes, these are the cells of the mesh, whereas in two-dimensional meshes the lines are the faces of cells.
In two- or three-dimensional meshes, lines without children (i.e., the active lines) are part of at least one active cell. Each such line may additionally be a child of a line of a coarser cell adjacent to a cell that is active. (This coarser neighbor would then also be active.)
Definition at line 382 of file dof_handler.h.
| using quad_iterator = typename ActiveSelector::quad_iterator |
An alias that defines an iterator over the (two-dimensional) quads of a mesh. In two-dimensional meshes, these are the cells of the mesh, whereas in three-dimensional meshes the quads are the faces of cells.
Definition at line 391 of file dof_handler.h.
| using active_quad_iterator = typename ActiveSelector::active_quad_iterator |
An alias that allows iterating over the active quads, i.e., that subset of quads that have no children. In two-dimensional meshes, these are the cells of the mesh, whereas in three-dimensional meshes the quads are the faces of cells.
In three-dimensional meshes, quads without children (i.e., the active quads) are faces of at least one active cell. Each such quad may additionally be a child of a quad face of a coarser cell adjacent to a cell that is active. (This coarser neighbor would then also be active.)
Definition at line 406 of file dof_handler.h.
| using hex_iterator = typename ActiveSelector::hex_iterator |
An alias that defines an iterator over the (three-dimensional) hexes of a mesh. This iterator only makes sense in three-dimensional meshes, where hexes are the cells of the mesh.
Definition at line 415 of file dof_handler.h.
| using active_hex_iterator = typename ActiveSelector::active_hex_iterator |
An alias that allows iterating over the active hexes of a mesh. This iterator only makes sense in three-dimensional meshes, where hexes are the cells of the mesh. Consequently, in these three-dimensional meshes, this iterator is equivalent to the active_cell_iterator alias.
Definition at line 426 of file dof_handler.h.
| using active_cell_iterator = typename ActiveSelector::active_cell_iterator |
An alias that is used to identify active cell iterators. The concept of iterators is discussed at length in the iterators documentation topic.
The current alias identifies active cells in a DoFHandler object. While the actual data type of the alias is hidden behind a few layers of (unfortunately necessary) indirections, it is in essence TriaActiveIterator<DoFCellAccessor>. The TriaActiveIterator class works like a pointer to active objects that when you dereference it yields an object of type DoFCellAccessor. DoFCellAccessor is a class that identifies properties that are specific to cells in a DoFHandler, but it is derived (and consequently inherits) from both DoFAccessor, TriaCellAccessor and TriaAccessor that describe what you can ask of more general objects (lines, faces, as well as cells) in a triangulation and DoFHandler objects.
Definition at line 448 of file dof_handler.h.
| using cell_iterator = typename ActiveSelector::cell_iterator |
An alias that is used to identify cell iterators. The concept of iterators is discussed at length in the iterators documentation topic.
The current alias identifies cells in a DoFHandler object. Some of these cells may in fact be active (see active cell iterators) in which case they can in fact be asked for the degrees of freedom that live on them. On the other hand, if the cell is not active, any such query will result in an error. Note that this is what distinguishes this alias from the level_cell_iterator alias.
While the actual data type of the alias is hidden behind a few layers of (unfortunately necessary) indirections, it is in essence TriaIterator<DoFCellAccessor>. The TriaIterator class works like a pointer to objects that when you dereference it yields an object of type DoFCellAccessor. DoFCellAccessor is a class that identifies properties that are specific to cells in a DoFHandler, but it is derived (and consequently inherits) from both DoFAccessor, TriaCellAccessor and TriaAccessor that describe what you can ask of more general objects (lines, faces, as well as cells) in a triangulation and DoFHandler objects.
Definition at line 476 of file dof_handler.h.
| using face_iterator = typename ActiveSelector::face_iterator |
An alias that is used to identify iterators that point to faces. The concept of iterators is discussed at length in the iterators documentation topic.
While the actual data type of the alias is hidden behind a few layers of (unfortunately necessary) indirections, it is in essence TriaIterator<DoFAccessor>. The TriaIterator class works like a pointer to objects that when you dereference it yields an object of type DoFAccessor. DoFAccessor, in turn, is a class that can be used to query DoF indices on faces, but it is also derived from TriaAccessor and consequently can be used to query geometric properties such as vertices of faces, their area, etc.
Definition at line 494 of file dof_handler.h.
| using active_face_iterator = typename ActiveSelector::active_face_iterator |
An alias that is used to identify iterators that point to active faces, i.e., to faces that have no children. Active faces must be faces of at least one active cell.
Other than the "active" qualification, this alias is identical to the face_iterator alias. In particular, dereferencing either yields the same kind of object.
Definition at line 507 of file dof_handler.h.
| using Triangulation< dim, spacedim >::cell_iterator = TriaIterator<CellAccessor<dim, spacedim>> |
An alias that is used to identify cell iterators. The concept of iterators is discussed at length in the iterators documentation topic.
The current alias identifies cells in a triangulation. The TriaIterator class works like a pointer that when you dereference it yields an object of type CellAccessor. CellAccessor is a class that identifies properties that are specific to cells in a triangulation, but it is derived (and consequently inherits) from TriaAccessor that describes what you can ask of more general objects (lines, faces, as well as cells) in a triangulation.
| using Triangulation< dim, spacedim >::active_cell_iterator = TriaActiveIterator<CellAccessor<dim, spacedim>> |
An alias that is used to identify active cell iterators. The concept of iterators is discussed at length in the iterators documentation topic.
The current alias identifies active cells in a triangulation. The TriaActiveIterator class works like a pointer to active objects that when you dereference it yields an object of type CellAccessor. CellAccessor is a class that identifies properties that are specific to cells in a triangulation, but it is derived (and consequently inherits) from TriaAccessor that describes what you can ask of more general objects (lines, faces, as well as cells) in a triangulation.
| using Triangulation< dim, spacedim >::face_iterator = TriaIterator<TriaAccessor<dim - 1, dim, spacedim>> |
An alias that is used to identify iterators that point to faces. The concept of iterators is discussed at length in the iterators documentation topic.
The current alias identifies faces in a triangulation. The TriaIterator class works like a pointer to objects that when you dereference it yields an object of type TriaAccessor, i.e., class that can be used to query geometric properties of faces such as their vertices, their area, etc.
| using Triangulation< dim, spacedim >::active_face_iterator |
An alias that is used to identify iterators that point to active faces, i.e., to faces that have no children. Active faces must be faces of at least one active cell.
Other than the "active" qualification, this alias is identical to the face_iterator alias. In particular, dereferencing either yields the same kind of object.
| using Triangulation< dim, spacedim >::vertex_iterator = TriaIterator<::TriaAccessor<0, dim, spacedim>> |
An alias that defines an iterator type to iterate over vertices of a mesh. The concept of iterators is discussed at length in the iterators documentation topic.
| using Triangulation< dim, spacedim >::active_vertex_iterator |
An alias that defines an iterator type to iterate over vertices of a mesh. The concept of iterators is discussed at length in the iterators documentation topic.
This alias is in fact identical to the vertex_iterator alias above since all vertices in a mesh are active (i.e., are a vertex of an active cell).
| using Triangulation< dim, spacedim >::line_iterator = typename IteratorSelector::line_iterator |
| using Triangulation< dim, spacedim >::active_line_iterator = typename IteratorSelector::active_line_iterator |
An alias that allows iterating over the active lines, i.e., that subset of lines that have no children. In one-dimensional meshes, these are the cells of the mesh, whereas in two-dimensional meshes the lines are the faces of cells.
In two- or three-dimensional meshes, lines without children (i.e., the active lines) are part of at least one active cell. Each such line may additionally be a child of a line of a coarser cell adjacent to a cell that is active. (This coarser neighbor would then also be active.)
| using Triangulation< dim, spacedim >::quad_iterator = typename IteratorSelector::quad_iterator |
| using Triangulation< dim, spacedim >::active_quad_iterator = typename IteratorSelector::active_quad_iterator |
An alias that allows iterating over the active quads, i.e., that subset of quads that have no children. In two-dimensional meshes, these are the cells of the mesh, whereas in three-dimensional meshes the quads are the faces of cells.
In three-dimensional meshes, quads without children (i.e., the active quads) are faces of at least one active cell. Each such quad may additionally be a child of a quad face of a coarser cell adjacent to a cell that is active. (This coarser neighbor would then also be active.)
| using Triangulation< dim, spacedim >::hex_iterator = typename IteratorSelector::hex_iterator |
| using Triangulation< dim, spacedim >::active_hex_iterator = typename IteratorSelector::active_hex_iterator |
An alias that allows iterating over the active hexes of a mesh. This iterator only makes sense in three-dimensional meshes, where hexes are the cells of the mesh. Consequently, in these three-dimensional meshes, this iterator is equivalent to the active_cell_iterator alias.
1.15.0