* error checking. It asserts that a certain condition is fulfilled, otherwise
* issues an error and aborts the program.
*
- * A more detailed description can be found in the @ref Exceptions documentation
+ * A more detailed description can be found in the
+ * @ref Exceptions
* module. It is first used in step-5 and step-6.
* See also the <tt>ExceptionBase</tt> class for more information.
*
* the exception that would be thrown to deallog and continues normally
* without throwing an exception.
*
- * A more detailed description can be found in the @ref Exceptions documentation
+ * A more detailed description can be found in the
+ * @ref Exceptions
* module, in the discussion about the corner case at the bottom of the page.
*
* @note Active in DEBUG mode only
* be caught via a @p catch clause, as is shown in step-6 and all following
* tutorial programs.
*
- * A more detailed description can be found in the @ref Exceptions documentation
+ * A more detailed description can be found in the
+ * @ref Exceptions
* module. It is first used in step-9 and step-13.
* See also the <tt>ExceptionBase</tt> class for more information.
*
* A data structure to store the result of the min_max_avg() function.
* The structure stores the minimum, maximum, and average of one
* value contributed by each processor that participates in an
- * @ref GlossMPICommunicator "MPI communicator". The structure also stores
- * the indices (or, more precisely, the @ref GlossMPIRank "MPI rank")
+ * @ref GlossMPICommunicator "MPI communicator".
+ * The structure also stores
+ * the indices (or, more precisely, the
+ * @ref GlossMPIRank "MPI rank")
* of the processors that hold the minimum and maximum values,
* as well as the sum over all values.
*
double max;
/**
- * One of the ranks (i.e., @ref GlossMPIRank "MPI rank" within an
- * @ref GlossMPICommunicator "MPI communicator") of the
+ * One of the ranks (i.e.,
+ * @ref GlossMPIRank "MPI rank"
+ * within an
+ * @ref GlossMPICommunicator "MPI communicator")
+ * of the
* processors that hold the minimal value.
*/
unsigned int min_index;
/**
- * One of the ranks (i.e., @ref GlossMPIRank "MPI rank" within an
- * @ref GlossMPICommunicator "MPI communicator") of the
+ * One of the ranks (i.e.,
+ * @ref GlossMPIRank "MPI rank"
+ * within an
+ * @ref GlossMPICommunicator "MPI communicator")
+ * of the
* processors that hold the maximal value.
*/
unsigned int max_index;
* "Z-order" is also sometimes called "Morton ordering", see
* https://en.wikipedia.org/wiki/Z-order_curve .
*
- * @see This @ref GlossZOrder "glossary entry".
+ * @see
+ * @ref GlossZOrder "Z order glossary entry".
*/
partition_zorder = 0x2,
* @note When using parallel meshes, either through the
* parallel::shared::Triangulation or parallel::distributed::Triangulation
* classes, it is only allowed to call this function on locally
- * owned cells (see @ref GlossLocallyOwnedCell "this glossary entry"). This
+ * owned cells (see
+ * @ref GlossLocallyOwnedCell "this glossary entry").
+ * This
* is because otherwise a common source of errors would be if one
* processor sets a different @p active_fe_index on a ghost cell than
* the processor that actually owns the cell does. To avoid this mistake,
* of cells is independent of the mesh's history, and so yields a
* predictable DoF numbering.
* - For meshes based on parallel::distributed::Triangulation,
- * the @ref GlossLocallyOwnedCell "locally owned cells" of
+ * the
+ * @ref GlossLocallyOwnedCell "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
- * @ref GlossLocallyOwnedDof "locally owned DoF indices" that consist
+ * @ref GlossLocallyOwnedDof "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
* 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 @ref GlossSubdomainId "subdomains" based on
+ * assign cells to
+ * @ref GlossSubdomainId "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
* support points of the reference cell, this function then computes what
* the nodal values of the element are, i.e., $\Psi_i[f]$, where $\Psi_i$
* are the node functionals of the element
- * (see also @ref GlossNodes "Node values or node functionals").
+ * (see also
+ * @ref GlossNodes "Node values or node functionals").
* The values $\Psi_i[f]$ are then the expansion coefficients
* for the shape functions of the finite element function that
* <i>interpolates</i> the given function $f(x)$, i.e.,
* of information.
*
* The exact form of $f_i$ depends on the element. For example, for scalar
- * @ref GlossLagrange "Lagrange elements", we have that in fact
+ * @ref GlossLagrange "Lagrange elements",
+ * we have that in fact
* $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)$. If you combine multiple
* scalar Lagrange elements via an FESystem object, then
* $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)_{c(i)}$ where $c(i)$
* triangulations for some basic geometries.
*
* Some of these functions receive a flag @p colorize. If this is set, parts of
- * the boundary receive different @ref GlossBoundaryIndicator "boundary
- * indicators" allowing them to be distinguished for the purpose of evaluating
+ * the boundary receive different
+ * @ref GlossBoundaryIndicator "boundary indicators"
+ * allowing them to be distinguished for the purpose of evaluating
* different boundary conditions.
*
* If the domain is curved, each of the domain parts that should be
* refined by following an appropriate Manifold description will
- * receive a different @ref GlossManifoldIndicator "manifold
- * indicator", and the correct Manifold descriptor will be attached to
+ * receive a different
+ * @ref GlossManifoldIndicator "manifold indicator",
+ * and the correct Manifold descriptor will be attached to
* the Triangulation. Notice that if you later tranform the
* triangulation, you have to make sure you attach the correct new Manifold
* to the triangulation.
* boundary ids to cells or faces (see
* @ref GlossMaterialId "this"
* and
- * @ref
- * GlossBoundaryIndicator "this"
+ * @ref GlossBoundaryIndicator "this"
* glossary entry for more information).
*
* @note Since deal.II only supports line, quadrilateral and hexahedral
* material id associated with a cell during assembly of the bilinear form,
* and use it to determine (e.g., by table lookup, or a sequence of if-else
* statements) what the correct material coefficients would be for that cell.
- * See also @ref GlossMaterialId "this glossary entry".
+ * See also
+ * @ref GlossMaterialId "this glossary entry".
*
* This material_id may be set upon construction of a triangulation (through
* the CellData data structure), or later through use of cell iterators. For a
* cell, new face midpoints, and (in 3D) new line midpoints. Therefore if your
* new boundary vertex is too near the center of the old quadrilateral or
* hexahedron, the distance to the midpoint vertex will become too small, thus
- * generating distorted cells. This issue is discussed extensively in @ref
- * GlossDistorted "distorted cells".
+ * generating distorted cells. This issue is discussed extensively in
+ * @ref GlossDistorted "distorted cells".
*
* <h3>Getting notice when a triangulation changes</h3>
*
* @p 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 @ref GlossArtificialCell "the glossary entry on artificial cells"
+ * See
+ * @ref GlossArtificialCell "the glossary entry on artificial cells"
* for more information.
*
*
* ones.
*
* @ingroup data
- * @see @ref GlossBlockLA "Block (linear algebra)"
+ * @see
+ * @ref GlossBlockLA "Block (linear algebra)"
* @author Wolfgang Bangerth, Guido Kanschat, 2000, 2007, 2011
*/
class BlockIndices : public Subscriptor
/**
* Implementation of the multigrid method. The implementation supports both
* continuous and discontinuous elements and follows the procedure described in
- * the @ref mg_paper "multigrid paper by Janssen and Kanschat".
+ * the
+ * @ref mg_paper "multigrid paper by Janssen and Kanschat".
*
* The function which starts a multigrid cycle on the finest level is cycle().
* Depending on the cycle type chosen with the constructor (see enum Cycle),
projects / dealii.git / commitdiff