/**
* This field stores which child cells are adjacent to a certain face of the
- * mother cell.
+ * parent cell.
*
* For example, in 2d the layout of a cell is as follows:
* @verbatim
/**
* The reverse function to the one above: take a point in the coordinate
* system of the child, and transform it to the coordinate system of the
- * mother cell.
+ * parent cell.
*/
static Point<dim>
child_to_cell_coordinates(const Point<dim> &p,
* objects around. The only way to create such objects is via the
* <tt>Table</tt> class, which only generates them as temporary objects.
* This guarantees that the accessor objects go out of scope earlier
- * than the mother object, avoid problems with data consistency.
+ * than the parent object, avoid problems with data consistency.
*/
DEAL_II_HOST
constexpr Accessor(tensor_type &tensor,
* objects around. The only way to create such objects is via the
* <tt>Table</tt> class, which only generates them as temporary objects.
* This guarantees that the accessor objects go out of scope earlier
- * than the mother object, avoid problems with data consistency.
+ * than the parent object, avoid problems with data consistency.
*/
DEAL_II_HOST
constexpr Accessor(tensor_type &tensor,
* objects around. The only way to create such objects is via the
* <tt>Table</tt> class, which only generates them as temporary objects.
* This guarantees that the accessor objects go out of scope earlier
- * than the mother object, avoid problems with data consistency.
+ * than the parent object, avoid problems with data consistency.
*/
Accessor(const TableType &table, const iterator data);
* detail in the
* @ref distributed_paper.
* Unfortunately, in this process, some information can get lost relating
- * to flags that are set by user code and that are inherited from mother
+ * to flags that are set by user code and that are inherited from parent
* to child cell but that are not moved along with a cell if that cell is
* migrated from one processor to another.
*
* The way to avoid this dilemma is to make sure that things like setting
* boundary indicators or material ids is done immediately every time a
* parallel triangulation is refined. This is not necessary for sequential
- * triangulations because, there, these flags are inherited from mother to
+ * triangulations because, there, these flags are inherited from parent to
* child cell and remain with a cell even if it is refined and the
* children are later coarsened again, but this does not hold for
* distributed triangulations. It is made even more difficult by the fact
* <h4>Interpolation matrices in three dimensions</h4>
*
* For the interface constraints, the 3d case is similar to the 2d case. The
- * numbering for the indices $n$ on the mother face is obvious and keeps to
+ * numbering for the indices $n$ on the parent 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
* $m=d_v...5d_v-1$ for the dofs on the vertices at the center of the bounding
* lines of the quadrilateral, $m=5d_v..5d_v+4*d_l-1$ are for the degrees of
* freedom on the four lines connecting the center vertex to the outer
- * boundary of the mother face, $m=5d_v+4*d_l...5d_v+4*d_l+8*d_l-1$ for the
+ * boundary of the parent face, $m=5d_v+4*d_l...5d_v+4*d_l+8*d_l-1$ for the
* degrees of freedom on the small lines surrounding the quad, and
* $m=5d_v+12*d_l...5d_v+12*d_l+4*d_q-1$ for the dofs on the four child faces.
* Note the direction of the lines at the boundary of the quads, as shown
/**
* Initialize the interpolation from functions on refined mesh cells onto
- * the father cell. According to the philosophy of the Raviart-Thomas
+ * the parent cell. According to the philosophy of the Raviart-Thomas
* element, this restriction operator preserves the divergence of a function
* weakly.
*/
/**
* Initialize the interpolation from functions on refined mesh cells onto
- * the father cell. According to the philosophy of the Nédélec element,
+ * the parent cell. According to the philosophy of the Nédélec element,
* this restriction operator preserves the curl of a function weakly.
*/
void
/**
* Initialize the interpolation from functions on refined mesh cells onto
- * the father cell. According to the philosophy of the Raviart-Thomas
+ * the parent cell. According to the philosophy of the Raviart-Thomas
* element, this restriction operator preserves the divergence of a function
* weakly.
*/
if (found_child)
{
- // interpolate these to the mother cell
+ // interpolate these to the parent cell
fe.get_restriction_matrix(c, dealii_cell->refinement_case())
.vmult(tmp2, tmp1);
* 1 ------------------> 1
* 2 ------------------> 1
* 3 ------------------> 2
- * 4 ------------------> mother cell of cells 3 and 4
+ * 4 ------------------> parent cell of cells 3 and 4
* (a non-active cell, not shown here)
* @endverbatim
* Besides the mappings shown here, the non-active cells on grid 1 are also
- * valid keys. For example, the mapping for the mother cell of cells 1 and 2
+ * valid keys. For example, the mapping for the parent cell of cells 1 and 2
* on the first grid will point to cell 1 on the second grid.
*
* @tparam MeshType This class may be used with any class that satisfies the
/**
* Return which child cells are adjacent to a certain face of the
- * mother cell.
+ * parent cell.
*
* For example, in 2d the layout of a quadrilateral cell is as follows:
* @verbatim
* @ref GlossDistorted "this glossary entry").
*
* @note When a cell is refined, its children inherit the position of the
- * vertex positions of those vertices they share with the mother cell (plus
+ * vertex positions of those vertices they share with the parent cell (plus
* the locations of the new vertices on edges, faces, and cell interiors
* that are created for the new child cells). If the vertex of a cell is
* moved, this implies that its children will also use these new locations.
* On the other hand, imagine a 2d situation where you have one cell that is
* refined (with four children) and then you move the central vertex
* connecting all four children. If you coarsen these four children again to
- * the mother cell, then the location of the moved vertex is lost and if, in
- * a later step, you refine the mother cell again, the then again new vertex
+ * the parent cell, then the location of the moved vertex is lost and if, in
+ * a later step, you refine the parent cell again, the then again new vertex
* will be placed again at the same position as the first time around --
* i.e., not at the location you had previously moved it to.
*
*
* Here, if you are on cell `1.3` and ask for its left neighbor (which is,
* according to the conventions spelled out in the GeometryInfo class, its
- * <i>zeroth</i> neighbor), then you will get the mother cell of `3.5`, since
+ * <i>zeroth</i> neighbor), then you will get the parent cell of `3.5`, since
* this is the smallest cell for which we have `(1.3)->face(0) ==
- * (3.5)->parent()->face(1)`. Note, that you will not obtain the mother cell
+ * (3.5)->parent()->face(1)`. Note, that you will not obtain the parent cell
* of `2.8`.
*
* Further, if you ask for the right (i.e. the <i>first</i>) neighbor of cell
/**
* Return a unique ID for the current cell. This ID is constructed from the
- * path in the hierarchy from the coarse father cell and works correctly in
+ * path in the hierarchy from the coarse parent cell and works correctly in
* parallel computations using objects of type
* parallel::distributed::Triangulation. This function is therefore useful
* in providing a unique identifier for cells (active or not) that also
struct Implementation
{
/**
- * Implementation of the function of some name in the mother class.
+ * Implementation of the function of some name in the parent class.
*/
template <int dim, int spacedim>
inline static unsigned int
/**
- * Implementation of the function of some name in the mother class.
+ * Implementation of the function of some name in the parent class.
*/
template <int structdim, int dim, int spacedim>
inline static unsigned int
/**
- * Implementation of the function of some name in the mother class.
+ * Implementation of the function of some name in the parent class.
*/
template <int structdim, int dim, int spacedim>
inline static void
}
/**
- * Implementation of the function of some name in the mother class.
+ * Implementation of the function of some name in the parent class.
*/
template <int dim, int spacedim>
inline static void
* In two and more dimensions, the neighbor is either on the same level
* and refined (in which case its children have neighbor pointers to
* this cell or its direct children), unrefined on the same level or one
- * level down (in which case its neighbor pointer points to the mother
+ * level down (in which case its neighbor pointer points to the parent
* cell of this cell).
*/
std::vector<std::pair<int, int>> neighbors;
/**
* The actual prolongation matrix. column indices belong to the dof indices
- * of the mother cell, i.e. the coarse level. while row indices belong to
+ * of the parent cell, i.e. the coarse level. while row indices belong to
* the child cell, i.e. the fine level.
*/
std::vector<
protected:
/**
* The actual prolongation matrix. column indices belong to the dof indices
- * of the mother cell, i.e. the coarse level. while row indices belong to
+ * of the parent cell, i.e. the coarse level. while row indices belong to
* the child cell, i.e. the fine level.
*/
std::vector<std::shared_ptr<BlockSparseMatrix<double>>> prolongation_matrices;
protected:
/**
* The actual prolongation matrix. column indices belong to the dof indices
- * of the mother cell, i.e. the coarse level. while row indices belong to
+ * of the parent cell, i.e. the coarse level. while row indices belong to
* the child cell, i.e. the fine level.
*/
std::vector<std::shared_ptr<BlockSparseMatrix<double>>> prolongation_matrices;
/**
* This variable holds the one-dimensional embedding (prolongation) matrix
- * from mother element to all the children.
+ * from parent element to all the children.
*/
std::vector<Number> prolongation_matrix_1d;
};
/**
* This variable holds the one-dimensional embedding (prolongation) matrix
- * from mother element to all the children.
+ * from parent element to all the children.
*/
AlignedVector<VectorizedArray<Number>> prolongation_matrix_1d;
* reason is that finding neighborship information is a bit easier then, but
* that's all practical reasoning, nothing fundamental.
*
- * Since we integrate from the coarse side of the face, we have the mother
+ * Since we integrate from the coarse side of the face, we have the parent
* face readily at hand and store the result of the integration over that
- * mother face (being the sum of the integrals along the subfaces) in the
+ * parent face (being the sum of the integrals along the subfaces) in the
* abovementioned map of integrals as well. This consumes some memory more
* than needed, but makes the summing up of the face contributions to the
* cells easier, since then we have the information from all faces of all
}
// finally loop over all subfaces to collect the contributions of the
- // subfaces and store them with the mother face
+ // subfaces and store them with the parent face
std::vector<double> sum(n_solution_vectors, 0);
for (unsigned int subface_no = 0; subface_no < face->n_children();
++subface_no)
* values are then distributed on the finite element spaces of the children
* post-refinement. This may lose information if, for example, the old cell
* used a Q2 space and the children use Q1 spaces, or the information may be
- * prolonged if the mother cell used a Q1 space and the children are Q2s.
+ * prolonged if the parent cell used a Q1 space and the children are Q2s.
* - If cells are to be coarsened, then the values from the child cells are
- * interpolated to the mother cell using the largest of the child cell
+ * interpolated to the parent cell using the largest of the child cell
* future finite element spaces, which will be identified as the least
* dominant element following the FiniteElementDomination logic (consult
* hp::FECollection::find_dominated_fe_extended() for more information). For
* example, if the children of a cell use Q1, Q2 and Q3 spaces, then the
- * values from the children are interpolated into a Q3 space on the mother
- * cell. After refinement, this Q3 function on the mother cell is then
+ * values from the children are interpolated into a Q3 space on the parent
+ * cell. After refinement, this Q3 function on the parent cell is then
* interpolated into the space the user has selected for this cell (which
* may be different from Q3, in this example, if the user has set the active
* FE index for a different space post-refinement and before calling
*
* <li> Solution transfer with coarsening and refinement. After calling
* Triangulation::prepare_coarsening_and_refinement the coarsen flags of
- * either all or none of the children of a (father-)cell are set. While
+ * either all or none of the children of a (parent-)cell are set. While
* coarsening (Triangulation::execute_coarsening_and_refinement) the cells
* that are not needed any more will be deleted from the Triangulation.
*
- * For the interpolation from the (to be coarsenend) children to their father
+ * For the interpolation from the (to be coarsenend) children to their parent
* the children cells are needed. Hence this interpolation and the storing of
* the interpolated values of each of the discrete functions that we want to
* interpolate needs to take place before these children cells are coarsened
*
* In <tt>interpolate(all_in, all_out)</tt> the refined cells are treated
* according to the solution transfer while pure refinement. Additionally, on
- * each cell that is coarsened (hence previously was a father cell), the
+ * each cell that is coarsened (hence previously was a parent cell), the
* values of the discrete functions in @p all_out are set to the stored local
* interpolated values that are accessible due to the 'vector<VectorType>
* *' pointer in @p Pointerstruct that is pointed to by the pointer of that
* values are then distributed on the finite element spaces of the children
* post-refinement. This may lose information if, for example, the old cell
* used a Q2 space and the children use Q1 spaces, or the information may be
- * prolonged if the mother cell used a Q1 space and the children are Q2s.
+ * prolonged if the parent cell used a Q1 space and the children are Q2s.
* - If cells are to be coarsened, then the values from the child cells are
- * interpolated to the mother cell using the largest of the child cell
+ * interpolated to the parent cell using the largest of the child cell
* future finite element spaces, which will be identified as the least
* dominant element following the FiniteElementDomination logic (consult
* hp::FECollection::find_dominated_fe_extended() for more information). For
* example, if the children of a cell use Q1, Q2 and Q3 spaces, then the
- * values from the children are interpolated into a Q3 space on the mother
- * cell. After refinement, this Q3 function on the mother cell is then
+ * values from the children are interpolated into a Q3 space on the parent
+ * cell. After refinement, this Q3 function on the parent cell is then
* interpolated into the space the user has selected for this cell (which
* may be different from Q3, in this example, if the user has set the active
* FE index for a different space post-refinement and before calling
projects / dealii.git / commitdiff