Reference documentation for deal.II version Git bef661081b 20190923 12:55:27 0400

Classes  
struct  QuadComparator 
Static Public Member Functions  
template<int dim, int spacedim>  
static void  compute_number_cache (const Triangulation< dim, spacedim > &triangulation, const unsigned int level_objects, internal::TriangulationImplementation::NumberCache< 1 > &number_cache) 
template<int dim, int spacedim>  
static void  compute_number_cache (const Triangulation< dim, spacedim > &triangulation, const unsigned int level_objects, internal::TriangulationImplementation::NumberCache< 2 > &number_cache) 
template<int dim, int spacedim>  
static void  compute_number_cache (const Triangulation< dim, spacedim > &triangulation, const unsigned int level_objects, internal::TriangulationImplementation::NumberCache< 3 > &number_cache) 
template<int spacedim>  
static void  create_triangulation (const std::vector< Point< spacedim >> &v, const std::vector< CellData< 1 >> &cells, const SubCellData &, Triangulation< 1, spacedim > &triangulation) 
template<int spacedim>  
static void  create_triangulation (const std::vector< Point< spacedim >> &v, const std::vector< CellData< 2 >> &cells, const SubCellData &subcelldata, Triangulation< 2, spacedim > &triangulation) 
template<int spacedim>  
static void  create_triangulation (const std::vector< Point< spacedim >> &v, const std::vector< CellData< 3 >> &cells, const SubCellData &subcelldata, Triangulation< 3, spacedim > &triangulation) 
template<int spacedim>  
static void  delete_children (Triangulation< 1, spacedim > &triangulation, typename Triangulation< 1, spacedim >::cell_iterator &cell, std::vector< unsigned int > &, std::vector< unsigned int > &) 
template<int spacedim>  
static void  create_children (Triangulation< 2, spacedim > &triangulation, unsigned int &next_unused_vertex, typename Triangulation< 2, spacedim >::raw_line_iterator &next_unused_line, typename Triangulation< 2, spacedim >::raw_cell_iterator &next_unused_cell, typename Triangulation< 2, spacedim >::cell_iterator &cell) 
template<int spacedim>  
static Triangulation< 1, spacedim >::DistortedCellList  execute_refinement (Triangulation< 1, spacedim > &triangulation, const bool) 
template<int spacedim>  
static Triangulation< 2, spacedim >::DistortedCellList  execute_refinement (Triangulation< 2, spacedim > &triangulation, const bool check_for_distorted_cells) 
template<int spacedim>  
static Triangulation< 3, spacedim >::DistortedCellList  execute_refinement (Triangulation< 3, spacedim > &triangulation, const bool check_for_distorted_cells) 
template<int spacedim>  
static void  prevent_distorted_boundary_cells (const Triangulation< 1, spacedim > &) 
template<int dim, int spacedim>  
static void  prepare_refinement_dim_dependent (const Triangulation< dim, spacedim > &) 
template<int dim, int spacedim>  
static bool  coarsening_allowed (const typename Triangulation< dim, spacedim >::cell_iterator &cell) 
A class into which we put many of the functions that implement functionality of the Triangulation class. The main reason for this class is as follows: the majority of the functions in Triangulation need to be implemented differently for dim==1, dim==2, and dim==3. However, their implementation is largly independent of the spacedim template parameter. So we would like to write things like
Unfortunately, C++ doesn't allow this: member functions of class templates have to be either not specialized at all, or fully specialized. No partial specialization is allowed. One possible solution would be to just duplicate the bodies of the functions and have equally implemented functions
but that is clearly an unsatisfactory solution. Rather, what we do is introduce the current Implementation class in which we can write these functions as member templates over spacedim, i.e. we can have
The outer template parameters are here unused, only the inner ones are of real interest.
One may ask why we put these functions into an class rather than an anonymous namespace, for example?
First, these implementation functions need to be friends of the Triangulation class. It is simpler to make the entire class a friend rather than listing all members of an implementation namespace as friends of the Triangulation class (there is no such thing as a "friend namespace XXX" directive).
Ideally, we would make this class a member class of the Triangulation<dim,spacedim> class, since then our implementation functions have immediate access to the alias and static functions of the surrounding Triangulation class. I.e., we do not have to write "typename Triangulation<dim,spacedim>::active_cell_iterator" but can write "active_cell_iterator" right away. This is, in fact, the way it was implemented first, but we ran into a bug in gcc4.0:
Here, friendship (per C++ standard) is supposed to extend to all members of the befriended class, including its 'Implementation' member class. But gcc4.0 gets this wrong: the members of Triangulation::Implementation are not friends of TriaAccessor and the other way around. Ideally, one would fix this by saying
but that's not legal because in ** we don't know yet that TriaAccessor has a member class Implementation and so we can't make it a friend. The only way forward at this point was to make Implementation a class in the internal namespace so that we can forward declare it and make it a friend of the respective other outer class – not quite what we wanted but the only way I could see to make it work...

inlinestatic 
For a given Triangulation, update that part of the number cache that relates to lines. For 1d, we have to deal with the fact that lines have levels, whereas for higher dimensions they do not.
The second argument indicates for how many levels the Triangulation has objects, though the highest levels need not contain active cells if they have previously all been coarsened away.

inlinestatic 
For a given Triangulation, update that part of the number cache that relates to quads. For 2d, we have to deal with the fact that quads have levels, whereas for higher dimensions they do not.
The second argument indicates for how many levels the Triangulation has objects, though the highest levels need not contain active cells if they have previously all been coarsened away.
At the beginning of the function, we call the respective function to update the number cache for lines.

inlinestatic 
For a given Triangulation, update that part of the number cache that relates to hexes. For 3d, we have to deal with the fact that hexes have levels, whereas for higher dimensions they do not.
The second argument indicates for how many levels the Triangulation has objects, though the highest levels need not contain active cells if they have previously all been coarsened away.
At the end of the function, we call the respective function to update the number cache for quads, which will in turn call the respective function for lines.

inlinestatic 

inlinestatic 

inlinestatic 

inlinestatic 
Actually delete a cell, or rather all its children, which is the main step for the coarsening process. This is the dimension dependent part of execute_coarsening
. The second argument is a vector which gives for each line index the number of cells containing this line. This information is needed to decide whether a refined line may be coarsened or not in 3D. In 1D and 2D this argument is not needed and thus ignored. The same applies for the last argument and quads instead of lines.

inlinestatic 
Create the children of a 2d cell. The arguments indicate the next free spots in the vertices, lines, and cells arrays.
The faces of the cell have to be refined already, whereas the inner lines in 2D will be created in this function. Therefore iterator pointers into the vectors of lines, quads and cells have to be passed, which point at (or "before") the reserved space.

inlinestatic 

inlinestatic 

inlinestatic 

static 
At the boundary of the domain, the new point on the face may be far inside the current cell, if the boundary has a strong curvature. If we allow anisotropic refinement here, the resulting cell may be strongly distorted. To prevent this, this function flags such cells for isotropic refinement. It is called automatically from prepare_coarsening_and_refinement().
This function does nothing in 1d (therefore the specialization).

inlinestatic 
Some dimension dependent stuff for mesh smoothing.
At present, this function does nothing in 1d and 2D, but makes sure no two cells with a level difference greater than one share one line in 3D. This is a requirement needed for the interpolation of hanging nodes, since otherwise to steps of interpolation would be necessary. This would make the processes implemented in the AffineConstraints
class much more complex, since these two steps of interpolation do not commute.

inlinestatic 