/**
* @defgroup auto_symb_diff Automatic and symbolic differentiation
*
- * @brief A module dedicated to the implementation of functions and classes that relate
+ * @brief A group dedicated to the implementation of functions and classes that relate
* to automatic and symbolic differentiation.
*
* Below we provide a very brief introduction as to what automatic and symbolic differentiation are,
*
* Sometimes imposing constraints on the type of an object without requiring
* it to belong to a specific inheritance hierarchy is useful. These are
- * usually referred to as <em>concepts</em> in the C++ community. This module
+ * usually referred to as <em>concepts</em> in the C++ community. This documentation group
* lists the concepts commonly used in deal.II with brief descriptions of
* their intent. The convention in deal.II for listing constraints on a type
* is to provide the name of the concept as a <code>typename</code> in a
* @defgroup constraints Constraints on degrees of freedom
* @ingroup dofs
*
- * This module deals with constraints on degrees of
+ * This documentation group deals with constraints on degrees of
* freedom. The central class to deal with constraints is the
* AffineConstraints class.
*
/**
* @defgroup CUDAWrappers CUDA Wrappers
*
- * The classes in this module are concerned with the description of features
+ * The classes in this group are concerned with the description of features
* to be run on GPUs using CUDA.
*/
* @defgroup distributed Parallel computing with multiple processors using distributed memory
* @ingroup Parallel
*
- * @brief A module discussing the use of parallelism on distributed memory
+ * @brief A group discussing the use of parallelism on distributed memory
* clusters.
*
* @dealiiVideoLecture{39,41,41.25,41.5}
*
* deal.II can use multiple machines connected via MPI to parallelize
* computations, in addition to the parallelization within a shared
- * memory machine discussed in the @ref threads module. There are
+ * memory machine discussed in the @ref threads topic. There are
* essentially two ways to utilize multiple machines:
*
* - Each machine keeps the entire mesh and DoF handler locally, but
*
* The use of truly distributed meshes is somewhat more complex because it
* changes or makes impossible some of the things that can otherwise be done
- * with deal.II triangulations, DoF handlers, etc. This module documents these
+ * with deal.II triangulations, DoF handlers, etc. This topic documents these
* issues with a vantage point at 50,000 ft above ground without going into
* too many details. All the algorithms described below are implement in
* classes and functions in namespace parallel::distributed.
* A complete discussion of the algorithms used in this namespace, as well as
* a thorough description of many of the terms used here, can be found in the
* @ref distributed_paper "Distributed Computing paper". In particular, the
- * paper shows that the methods discussed in this module scale to thousands of
+ * paper shows that the methods discussed in this group scale to thousands of
* processors and well over a billion degrees of freedom. The paper also gives a
* concise definition of many of the terms that are used here and in other
* places of the library related to distributed computing. The step-40
* A namespace for class and
* functions that support %parallel
* computing on %distributed memory
- * machines. See the @ref
- * distributed module for an
+ * machines. See the @ref distributed topic for an
* overview of the facilities this
* namespace offers.
*
/**
* @defgroup dofs Degrees of Freedom
*
- * This module groups classes and namespaces that have to do with
+ * This topic groups classes and namespaces that have to do with
* handling degrees of freedom. The central class of this group is the
* DoFHandler class: it is built on top of a triangulation and a
* finite element class and allocated degrees of freedom on each cell
* we can describe functions in this finite dimensional space by vectors
* of coefficients.
*
- * DoFHandlers extend Triangulation objects (and the other classes in the @ref
- * grid module) in that they, too, offer iterators that run over all cells,
+ * DoFHandlers extend Triangulation objects (and the other classes in the
+ * @ref grid topic) in that they, too, offer iterators that run over all cells,
* faces, or other geometric objects that make up a triangulation. These
* iterators are derived from the triangulation iterators and therefore offer
* the same functionality, but they also offer additional functions. For
* the reason is that there can be more than one DoFHandler object that works
* on the same Triangulation object.
*
- * In addition to the DoF handler classes, this module holds a number of
+ * In addition to the DoF handler classes, this group holds a number of
* auxiliary classes not commonly used in application programs, as well as
* three classes that are not directly associated with the data structures of
* the DoFHandler class. The first of these is the AffineConstraints class that
* the DoFTools namespace offers a variety of algorithms around handling
* degrees of freedom.
*
- * In the grand scheme of things, the pieces of this module interact
+ * In the grand scheme of things, the pieces of this group interact
* with a variety of other parts of the library:
* @dot
digraph G
/**
* @defgroup Exceptions Exceptions and assertions
*
- * This module contains classes that are used in the exception mechanism of
+ * This group contains classes that are used in the exception mechanism of
* deal.II.
*
* <h2>Brief overview</h2>
* introduced in step-9, step-13, and
* following tutorial programs. The macro checks a condition, and if
* violated throws an exception of one of the types declared in this
- * module, using the C++ <code>throw</code> mechanism. Since these
+ * group, using the C++ <code>throw</code> mechanism. Since these
* are run-time exceptions, this gives the program the chance to
* catch the exception and, for example, write the output to a
* writable file instead.
*
* All classes related to shape functions and to access to shape
* functions. This concerns the actual values of finite elements. For
- * the numbering of degrees of freedom refer to the module on
+ * the numbering of degrees of freedom refer to the topic on
* @ref dofs.
*
- * The classes and functions of this module fall into several sub-groups that
- * are discussed in their respective sub-modules listed above. In addition,
+ * The classes and functions of this topic fall into several sub-groups that
+ * are discussed in their respective sub-topics listed above. In addition,
* the FETools class provides functions that provide information on finite
* elements, transformations between elements, etc.
*
- * In the grand scheme of things, the pieces of this module interact
+ * In the grand scheme of things, the pieces of this topic interact
* with a variety of other parts of the library:
* @dot
digraph G
/**
* @defgroup febase Base classes
*
- * The members of this sub-module describe the implementation mechanics of
+ * The members of this sub-topic describe the implementation mechanics of
* finite element classes, without actually implementing a concrete
* element. For example, the FiniteElement base class declares the virtual
* functions a derived class has to implement if it wants to describe a finite
/**
* @defgroup feaccess Finite element access/FEValues classes
*
- * The classes in this module are used when one wants to assemble matrices or
+ * The classes in this topic are used when one wants to assemble matrices or
* vectors. They link finite elements, quadrature objects, and mappings: the
* finite element classes describe a finite element space on a unit cell
* (i.e. the unit line segment, square, or cube <tt>[0,1]^d</tt>), the
* the FEValues and related classes allow access to all vector components; if
* one wants to pick individual components, there are extractor classes that
* make this task simpler, as described in the
- * @ref vector_valued module.
+ * @ref vector_valued topic.
*
* The last member of this group, the UpdateFlags enumeration, is used as an
* optimization: instead of letting the FEValues class compute every possible
* @ref UpdateFlags
* attempts to give an overview of how this works.
*
- * In the grand scheme of things, the pieces of this module interact
+ * In the grand scheme of things, the pieces of this topic interact
* with a variety of other parts of the library:
* @dot
digraph G
/**
* @defgroup mapping Mappings between reference and real cell
*
- * The classes in this module are used to map from unit coordinates to the
+ * The classes in this group are used to map from unit coordinates to the
* coordinates of a cell in real cell. Most commonly, one uses the MappingQ1
* class that provides a Q1 (bi-/trilinear) mapping (i.e. a mapping that is
* isoparametric for the usual Q1 elements). However, there are other classes
* Finally, the MappingCartesian class is an optimization for elements that
* are brick-shaped and with edges parallel to the coordinate axes.
*
- * In the grand scheme of things, the pieces of this module interact
+ * In the grand scheme of things, the pieces of this group interact
* with a variety of other parts of the library:
* @dot
digraph G
applications both regarding computing times to solve as well as concerning
the accuracy of numerical solutions.
- The applications in this module will already have been benchmarked for
+ The applications in this group will already have been benchmarked for
correctness. Existing tutorial programs typically employ simpler rather than
more complicated solver schemes for exposition but frequently suggest more
complicated schemes including hints on how they might be implemented in an
*
* Splitting matrices and vectors into blocks is supported by the
* BlockSparseMatrix, BlockVector, and related classes. See the
- * overview of the various linear algebra classes in the @ref LAC
- * module. The objects present two interfaces: one that makes the
+ * overview of the various linear algebra classes in the
+ * @ref LAC topic. The objects present two interfaces: one that makes the
* object look like a matrix or vector with global indexing
* operations, and one that makes the object look like a collection of
* sub-blocks that can be individually addressed. Depending on
* <i>Implementation:</i>
* deal.II has a number of different finite element classes, all of which are
* derived from the FiniteElement base class
- * (see the @ref feall "module on finite element classes").
+ * (see the @ref feall "topic on finite element classes").
* With one exception, whether they are scalar or
* vector valued, they all define a single block: all vector components the
* finite element defines through its FiniteElement::n_components() function
* of creating the Stokes element with two blocks right away.
*
* More information on this topic can be found in the documentation of
- * FESystem, the @ref vector_valued module and the tutorial programs
+ * FESystem, the @ref vector_valued topic and the tutorial programs
* referenced therein.
*
* <i>Selecting blocks:</i>
* call the elements of the vector-valued solution <i>components</i> in
* deal.II. To be well-posed, for the solution to have $n$ components, there
* need to be $n$ partial differential equations to describe them. This
- * concept is discussed in great detail in the @ref vector_valued module.
+ * concept is discussed in great detail in the @ref vector_valued topic.
*
* In finite element programs, one frequently wants to address individual
* elements (components) of this vector-valued solution, or sets of
* components. For example, we do this extensively in step-8, and a lot
- * of documentation is also provided in the module on
+ * of documentation is also provided in the topic on
* @ref vector_valued "Handling vector valued problems". If you are thinking
* only in terms of the partial differential equation (not in terms of
* its discretization), then the concept of <i>components</i> is the natural
* not possible to ensure that each entry of the vector is counted exactly
* once.
*
- * @note The @ref distributed documentation module provides a brief
+ * @note The @ref distributed documentation topic provides a brief
* overview of where the different kinds of vectors are typically
* used.
* </dd>
*
* <dt class="glossary">@anchor GlossLocallyOwnedCell <b>Locally owned cell</b></dt>
* <dd>This concept identifies a subset of all cells when using
- * distributed meshes, see the @ref distributed module. In such meshes, each
+ * distributed meshes, see the @ref distributed topic. In such meshes, each
* cell is owned by exactly one processor. The locally owned ones are those
* owned by the current processor.
*
*
* <dt class="glossary">@anchor GlossLocallyOwnedDof <b>Locally owned degrees of freedom</b></dt>
* <dd>This concept identifies a subset of all degrees of freedom when using
- * distributed meshes, see the @ref distributed module. Locally owned degrees
+ * distributed meshes, see the @ref distributed topic. Locally owned degrees
* of freedom live on locally owned cells. Since degrees of freedom are owned
* by only one processor, degrees of freedom on interfaces between cells owned
* by different processors may be owned by one or the other, so not all
*
* <dt class="glossary">@anchor GlossLocallyActiveDof <b>Locally active degrees of freedom</b></dt>
* <dd>This concept identifies a subset of all degrees of freedom when using
- * distributed meshes, see the @ref distributed module. Locally active degrees
+ * distributed meshes, see the @ref distributed topic. Locally active degrees
* of freedom are those that live on locally owned cells. Degrees of freedom
* on interfaces between cells owned by different processors therefore belong
* to the set of locally active degrees of freedom for more than one processor.
*
* <dt class="glossary">@anchor GlossLocallyRelevantDof <b>Locally relevant degrees of freedom</b></dt>
* <dd>This concept identifies a subset of all degrees of freedom when using
- * distributed meshes, see the @ref distributed module. Locally relevant
+ * distributed meshes, see the @ref distributed topic. Locally relevant
* degrees of freedom are those that live on locally owned or ghost cells.
* Consequently, they may be owned by different processors.
*
* children upon mesh refinement. Some more information about manifold
* indicators is also presented in a section of the documentation of
* the Triangulation class as well as in the
- * @ref manifold "Manifold documentation module". Manifold indicators
+ * @ref manifold "Manifold documentation topic". Manifold indicators
* are used in step-53 and step-54.
* </dd>
*
- * @see @ref manifold "The module on Manifolds"
+ * @see @ref manifold "The topic on Manifolds"
*
*
* <dt class="glossary">@anchor GlossMassMatrix <b>Mass matrix</b></dt>
/**
* @defgroup grid Grids and Triangulations
*
- * This module groups functions and classes that have to do with the topology
+ * This topic groups functions and classes that have to do with the topology
* and geometry of meshes. A mesh can be thought of as a collection of cells;
* if the mesh has been refined (possibly in an adaptive way), then
* this collection is grouped into a hierarchy of refinement
* (i.e. which cells are neighbors of which other cells, etc). It has nothing
* to do with finite elements or degrees of freedom that might be defined on a
* mesh. These functions are performed by the DoFHandler class (see the
- * @ref dofs module) that gets a description of the finite element space and the
+ * @ref dofs topic) that gets a description of the finite element space and the
* allocates and manages degrees of freedom on vertices, faces, or cells, as
* described by the finite element class. This separation makes it possible to
* have multiple DoFHandler classes work on the same mesh at the same time.
* Meshes can be written to output files in a number of different formats. If
* this involves simulation results obtained on this mesh, then this is done
* using the DataOut class (described in more detail in the @ref output
- * module). On the other hand, if only the geometry and topology of the mesh
+ * topic). On the other hand, if only the geometry and topology of the mesh
* is to be written to a file, the GridOut class can do this for you.
*
*
* <h3>Internal classes</h3>
*
* In addition to the above, there are a significant number of classes in this
- * module that are only used in the internal data structures of mesh
+ * group that are only used in the internal data structures of mesh
* handling. They are generally in the internal namespace, and not meant for
* use in application code.
*/
*
* @note Documentation on coding conventions, relations between
* classes, and details of the implementation is found in the
- * documentation of namespaces in this module.
+ * documentation of namespaces in this group.
*
* <h3>Integration on finite element meshes</h3>
*
/**
* @defgroup IO Input/Output
*
- * This module collects the classes used for reading and writing meshes and
- * data. There are two sub-modules for each of these operations.
+ * This topic collects the classes used for reading and writing meshes and
+ * data. There are two sub-topics for each of these operations.
*/
/**
* In addition, deal.II can read an intermediate graphics format using the
* DataOutReader. This format is used as an intermediate step between data
* associated with a simulation and is written by the DataOutBase class (or
- * through the more derived classes described in the \ref output module). The
+ * through the more derived classes described in the \ref output topic). The
* DataOutReader class reads this data back in, and it can then be converted
* to any of a number of data formats supported by visualization programs.
*
* @defgroup textoutput Textual output
*
* In addition to classes that provide graphical output formats (see the @ref
- * output module), deal.II has a number of classes that facilitate textual
- * output in a number of ways. They are collected in this module. See the
+ * output topic), deal.II has a number of classes that facilitate textual
+ * output in a number of ways. They are collected in this topic. See the
* documentation of these classes for more details.
*
* @ingroup IO
/**
* @defgroup LAC Linear algebra classes
*
- * This module contains classes that involve linear algebra, i.e., those
+ * This group contains classes that involve linear algebra, i.e., those
* associated with matrices, vectors, and the solution of linear systems.
*
* The description of individual groups of classes can be found in
- * sub-modules.
+ * sub-topics.
*
* The files implementing linear algebra functionality are in the
* <code>lac</code> subdirectory, an abbreviation for <em>L</em>inear
* system, can be found elsewhere. In addition, there are
* <a href="Tutorial.html">Tutorial programs on the use of the library</a>.
*
- * Many of the classes in the deal.II library can be grouped into modules (see
- * the <a href="modules.html">Modules page</a> or the corresponding entry in
- * the menu at the top of this page). These modules form around the building
+ * Many of the classes in the deal.II library can be grouped into topics (see
+ * the "Topics" tab at the top of this page). These topics form around the building
* blocks of any finite element program. An outline of how the primary groups
* of classes in deal.II interact is given by the following clickable graph,
* with a more detailed description below (gray boxes denote a subset of the
* <li> <b>%Triangulation</b>: Triangulations are collections of
* cells and their lower-dimensional boundary objects. Cells are
* images of the reference hypercube [0,1]<sup>dim</sup> under a
- * suitable mapping in the module on @ref mapping.
+ * suitable mapping in the topic on @ref mapping.
*
* The triangulation stores geometric and topological
* properties of a mesh: how are the cells connected and where are
* information about the cell it presently points to.
*
* The classes that describe triangulations and cells are located
- * and documented in the @ref grid module. Iterators are described
- * in the @ref Iterators module.
+ * and documented in the @ref grid topic. Iterators are described
+ * in the @ref Iterators topic.
*
* <li> <b>%Manifold</b>: Manifolds describe the shape of cells and,
* more generally, the geometry of the domain on which one wants
* provide values and gradients of individual shape functions at
* points on the unit cell.
*
- * The finite element classes are described in the @ref feall module.
+ * The finite element classes are described in the @ref feall topic.
*
* <li> <b>%Quadrature</b>: As with finite elements, quadrature
* objects are defined on the unit cell. They only describe the
* of quadrature points thereon.
*
* The documentation of the classes describing particular quadrature
- * formulas is found in the @ref Quadrature module.
+ * formulas is found in the @ref Quadrature topic.
*
* <li> <b>%DoFHandler</b>: %DoFHandler objects are the confluence
* of triangulations and finite elements: the finite element class
* specifics is relevant to the DoFHandler class with the exception of
* the fact that they exist.
*
- * The DoFHandler class and its associates are described in the @ref
- * dofs module. In addition, there are specialized versions that can
+ * The DoFHandler class and its associates are described in the
+ * @ref dofs topic. In addition, there are specialized versions that can
* handle multilevel and hp-discretizations. These are described in
- * the @ref mg and @ref hp modules. Finite element methods frequently
+ * the @ref mg and @ref hp topics. Finite element methods frequently
* imply constraints on degrees of freedom, such as for hanging nodes
* or nodes at which boundary conditions apply; dealing with such
- * constraints is described in the @ref constraints module.
+ * constraints is described in the @ref constraints topic.
*
* <li> <b>%Mapping</b>: The next step in a finite element program
* is that one would want to compute matrix and right hand side
* real space and back, as well as provide gradients of this
* derivative and Jacobian determinants.
*
- * These classes are all described in the @ref mapping module.
+ * These classes are all described in the @ref mapping topic.
*
* <li> <b>%FEValues</b>: The next step is to actually take a finite
* element and evaluate its shape functions and their gradients at
* evaluation on cells, FEFaceValues for evaluation on faces of
* cells, and FESubfaceValues for evaluation on parts of faces of
* cells. All these classes are described in the @ref feaccess
- * module.
+ * topic.
*
* <li> <b>Linear Systems</b>: If one knows how to evaluate the
* values and gradients of shape functions on individual cells using
* entries of matrices and vectors. deal.II comes with a whole set
* of classes for this purpose, as well as with interfaces to other
* software packages that offer similar functionality. Documentation
- * to this end can be found in the @ref LAC module.
+ * to this end can be found in the @ref LAC topic.
*
* <li> <b>Linear Solvers</b>: In order to determine the solution of
* a finite-dimensional, linear system of equations, one needs
* linear solvers. In finite element applications, they are
* frequently iterative, but sometimes one may also want to use
* direct or sparse direct solvers. deal.II has quite a number of
- * these. They are documented in the @ref Solvers module.
+ * these. They are documented in the @ref Solvers topic.
*
* <li> <b>Output</b>: Finally, once one has obtained a solution of
* a finite element problem on a given triangulation, one will often
* files in a variety of graphics formats understood by widely
* available visualization tools.
*
- * A description of the classes that do so is given in the @ref
- * output module.
+ * A description of the classes that do so is given in the
+ * @ref output topic.
* </ol>
*
* In addition, deal.II has a number of groups of classes that go
* finite element programs, but appear there as well. These classes
* are all listed in the Classes and Namespaces views reachable from
* the menu bar at the top of this page, and are also grouped into
- * modules of their own (see the <a href="modules.html">Modules link</a>
- * at the top of this page).
+ * topics of their own (see the "Topics" tab at the top of this page).
*
* We provide the Doxygen tag file for those of you who would like to directly link the
* documentation of application programs to the deal.II online documentation. The tag file
*
* <h3>Overview</h3>
*
- * The classes in this module are concerned with the description of the
+ * The classes in this group are concerned with the description of the
* manifold in which the domain that a Triangulation describes lives. This
* manifold description is necessary in several contexts:
*
* matrix and right hand side of the linear system) using curved
* approximations of the boundary, rather than the straight line
* approximation. The actual implementation of such curved elements happens
- * in the Mapping class (see the @ref mapping module), which however obtains
+ * in the Mapping class (see the @ref mapping topic), which however obtains
* its information about the boundary of the domain from the classes
* described here. The same is, of course, true when integrating boundary
* terms (e.g., inhomogeneous Neumann boundary conditions).
* reasonable implementations. More complicated examples can be described
* using the techniques shown in step-53 and step-54.
*
- * In the grand scheme of things, the classes of this module interact
+ * In the grand scheme of things, the classes of this group interact
* with a variety of other parts of the library:
* @dot
digraph G
* write iterative linear solvers (see @ref Solvers), but also element-wise
* access to read from and write to a matrix.
*
- * This module is split into different parts. @ref Matrix1 "Basic matrices"
+ * This documentation topic is split into different parts. @ref Matrix1 "Basic matrices"
* contains all the matrix classes actually storing entries. @ref Matrix2
* "Derived matrices", on the other hand, only use basic matrices, but
* implement certain operations on them. For example, TransposeMatrix provides
/**
* @defgroup matrixfree Matrix-free infrastructure
*
- * This module describes the matrix-free infrastructure in deal.II.
+ * This group describes the matrix-free infrastructure in deal.II.
* An outline of how the primary groups of classes in deal.II interact with the
* matrix-free infrastructure is given by the following clickable graph,
* with a more detailed description below:
*
* A collection of classes and functions simplifying the coding of
* loops over all cells and faces.
- * All classes and functions of this module are in the MeshWorker
+ * All classes and functions of this group are in the MeshWorker
* namespace, which also contains documentation on the usage.
*
* @ingroup Integrators
* @defgroup threads Parallel computing with multiple processors accessing shared memory
* @ingroup Parallel
*
- * @brief A module discussing the use of parallelism on shared memory
+ * @brief A group discussing the use of parallelism on shared memory
* machines. See the detailed documentation and
* @ref MTToC "Table of Contents" below the lengthy list of members
- * of this module.
+ * of this group.
*
* @dealiiVideoLecture{39,40}
*
/**
* @defgroup numerics Numerical algorithms
*
- * This module groups a diverse set of classes that generally implement some
+ * This topic groups a diverse set of classes that generally implement some
* sort of numerical algorithm on top all the basic triangulation, DoFHandler,
* and finite element classes in the library. They are generally unconnected
* to each other.
/**
* @defgroup Parallel Parallel computing
*
- * @brief A module discussing the use of multiple processors.
+ * @brief A group discussing the use of multiple processors.
*
- * This module contains information on %parallel computing. It is
+ * This group contains information on %parallel computing. It is
* subdivided into parts on @ref threads and on @ref distributed.
*/
/**
* @defgroup PETScWrappers PETScWrappers
*
- * The classes in this module are
+ * The classes in this group are
* wrappers around functionality provided by the PETSc library. They provide a
* modern object-oriented interface that is compatible with the interfaces of
* the other linear algebra classes in deal.II. All classes and functions in
/**
* @defgroup physics Physics
*
- * @brief A module dedicated to the implementation of functions and
+ * @brief A group dedicated to the implementation of functions and
* classes that relate to continuum physics, physical fields and materials.
*/
/**
* @defgroup Polynomials Polynomials and polynomial spaces
*
- * This module groups classes that define certain families of polynomial
+ * This topic groups classes that define certain families of polynomial
* functions. In particular, this includes Lagrangian interpolation
* polynomials for equidistant support points and their tensor products in
* higher dimensions, but also more exotic ones like Brezzi-Douglas-Marini or
* @ref ConceptPreconditionerType "the PreconditionerType concept". In
* practice, one can usually treat any matrix-like object which defines
* <code>vmult()</code> and <code>Tvmult()</code> as a preconditioner. All
- * preconditioner classes in this module implement this interface.
+ * preconditioner classes in this group implement this interface.
*
* When used
* in Krylov space methods, it is up to the method, whether it simply
* operators mapping the previous iterate <i>x<sup>k</sup></i> to the
* next iterate in this way relaxation operators. Their generic
* interface is given by @ref ConceptRelaxationType "the RelaxationType concept".
- * The classes with names starting with <tt>Relaxation</tt> in this module
+ * The classes with names starting with <tt>Relaxation</tt> in this group
* implement this interface, as well as the preconditioners
* PreconditionJacobi, PreconditionSOR, PreconditionBlockJacobi,
* PreconditionBlockSOR, and PreconditionBlockSSOR.
/**
* @defgroup Quadrature Quadrature formulas
*
- * This module contains the base class Quadrature as well as the quadrature
+ * This group contains the base class Quadrature as well as the quadrature
* formulas provided by deal.II. Quadrature formulas provide two essential
* pieces of data: the locations of quadrature points on the unit cell
* [0,1]^d, and the weight of each quadrature point.
* coordinate direction than in another) through the QAnisotropic class, as
* well as the definition of quadrature formulas that are not tensor products.
*
- * In the grand scheme of things, the classes of this module interact
+ * In the grand scheme of things, the classes of this group interact
* with a variety of other parts of the library:
* @dot
digraph G
* but it provides functions for computing quadrature formulas on the
* surfaces of higher dimensional cells.
*
- * All other classes in this module actually implement quadrature
+ * All other classes in this group actually implement quadrature
* rules of different order and other characteristics.
*
*
/**
* @defgroup reordering Grid reordering and cell orientation
*
- * @brief A module describing how deal.II consistently orients Triangulation
+ * @brief A group describing how deal.II consistently orients Triangulation
* objects.
*
* @warning The implementation of orientation should be considered an internal
* detail of the library. Normal users should not need to use the features
- * describd in this module: instead, classes like QProjector use orientation
+ * describd in this group: instead, classes like QProjector use orientation
* information to consistently compute values on faces and lines.
*
* <h2>Orientation of Lines</h2>
/**
* @defgroup simplex Simplex support (experimental)
*
- * This module describes the experimental simplex support in deal.II.
+ * This group describes the experimental simplex support in deal.II.
*
* Simplex and mixed meshes in deal.II are still experimental, i.e., work
* in progress. Large parts of the library have been ported to be able to
/**
* @defgroup SLEPcWrappers SLEPcWrappers
*
- * The classes in this module are wrappers around functionality
+ * The classes in this group are wrappers around functionality
* provided by the SLEPc library. All classes and functions in this
* group reside in a namespace @p PETScWrappers.
*
/**
* @defgroup Solvers Linear solver classes
*
- * This module groups iterative and direct solvers, eigenvalue solvers, and
+ * This page groups iterative and direct solvers, eigenvalue solvers, and
* some control classes. All these classes operate on objects of the
* @ref Matrices "matrix" and @ref Vectors "vector classes" defined in deal.II.
*
/**
* @defgroup TrilinosWrappers TrilinosWrappers
*
- * The classes in this module are wrappers around functionality
+ * The classes in this group are wrappers around functionality
* provided by the Trilinos library. They provide a modern
* object-oriented interface that is compatible with the interfaces of
* the other linear algebra classes in deal.II. All classes and
/**
* @defgroup utilities Utility functions and classes
*
- * This module simply collects a number of functions and classes that provide
+ * This page simply collects a number of functions and classes that provide
* general tools for tasks that do not usually have much to do with finite
* element programs in particular, but happen to be required there just as
* well.
/**
* @defgroup VMemory Vector memory management
*
- * This module groups a few classes that are used to avoid allocating and
+ * This page groups a few classes that are used to avoid allocating and
* deallocating vectors over and over in iterative procedures. These methods
* all use an object of the base class VectorMemory to get their auxiliary
* vectors.
class. On the other hand, the manual is not a good place to learn
deal.II since it gives you a microscopic view of things without
telling you how a function might fit into the bigger picture.
-- Modules: These are groups of classes and functions that work
+- Topics: These are groups of classes and functions that work
together or have related functionality. If you click on the
- "Modules" tab at the top of this page, you end up on a page that
- lists a number of such groups. Each module discusses the underlying
- principles of these classes; for example, the @ref Sparsity module
+ "Topics" tab at the top of this page, you end up on a page that
+ lists a number of such groups. Each topic discusses the underlying
+ principles of these classes; for example, the @ref Sparsity topic
talks about all sorts of different issues related to storing
sparsity patterns of matrices. This is documentation at an
intermediate level: they give you an overview of what's there in a
particular area. For example when you wonder what finite element
- classes exist, you would take a look at the @ref fe module. The
- modules are, of course, also cross-linked to the manual (and, at
+ classes exist, you would take a look at the @ref fe topic. The
+ topics are, of course, also cross-linked to the manual (and, at
times, to the tutorial); if you click on a class name, say on
Triangulation, you will also at the very top right under the class
- name get a link to the modules this class is a member of if you want
+ name get a link to the topics this class is a member of if you want
to learn more about its context.
Let's come back to the tutorial, since you are looking at the first program
loop) over the elements of the triangulation (i.e., the cells of the
mesh). You will see many more such loops throughout the remainder
of the tutorial. (Since there are so many loops over cells in finite
-element programs, the @ref Iterators module talks about them in more
+element programs, the @ref Iterators topic talks about them in more
detail.)
The program is otherwise small enough that it doesn't need a whole lot
functions that are specific to *cells*).
A more thorough description of the whole iterator concept can be found
-in the @ref Iterators documentation module.
+in the @ref Iterators documentation topic.
<h4> Different geometries </h4>
object to the part of the triangulation that should be curved (SphericalManifold
and CylindricalManifold, respectively) and use another manifold on the parts that
should be flat (FlatManifold). See the documentation
-of Manifold or the @ref manifold "manifold module" for descriptions of the design
+of Manifold or the @ref manifold "manifold topic" for descriptions of the design
philosophy and interfaces of these classes. Take a look at what they provide and
see how they could be used in a program like this.
<li>Parallelize the assembly of linear systems using the WorkStream
facilities. This follows the extensive description that can be
found in the @ref threads "Parallel computing with multiple processors accessing shared memory"
- documentation module. The implementation essentially follows what
+ documentation topic. The implementation essentially follows what
has already been described in step-9.
</ol>
// old one). On a related note, you can reuse the evaluation classes for
// other projects, solving different equations.
//
- // In order to improve separation of code into different modules, we put the
+ // In order to improve separation of code into different groups, we put the
// evaluation classes into a namespace of their own. This makes it easier to
// actually solve different equations in the same program, by assembling it
// from existing building blocks. The reason for this is that classes for
// assemble both the matrix and the right hand side. These are
// independent operations, and we should do this in parallel. To
// this end, we use the concept of "tasks" that is discussed in
- // the @ref threads documentation module. In essence, what we want
+ // the @ref threads documentation topic. In essence, what we want
// to say "here is something that needs to be worked on, go do it
// whenever a CPU core is available", then do something else, and
// when we need the result of the first operation wait for its
// Now, we have to provide a matrix on each level. To this end, we first use
// the MGTools::make_sparsity_pattern function to generate a preliminary
- // compressed sparsity pattern on each level (see the @ref Sparsity module
+ // compressed sparsity pattern on each level (see the @ref Sparsity topic
// for more information on this topic) and then copy it over to the one we
// really want. The next step is to initialize the interface matrices with
// the fitting sparsity pattern.
on a common task). Some of the fundamentals of distributed memory
computing are discussed in the
@ref distributed "Parallel computing with multiple processors using distributed memory"
-documentation module, which is itself a sub-module of the
-@ref Parallel "Parallel computing" module.
+documentation topic, which is itself a sub-topic of the
+@ref Parallel "Parallel computing" topic.
In general, to be truly able to scale to large numbers of processors, one
needs to split between the available processors <i>every</i> data structure
Internally, within deal.II, parallelizing the data
structures used in hierarchic and unstructured triangulations is a hard
problem, and it took us a few more years to make this happen. The step-40
-tutorial program and the @ref distributed documentation module talk about how
+tutorial program and the @ref distributed documentation topic talk about how
to do these steps and what it takes from an application perspective. An
obvious extension of the current program would be to use this functionality to
completely distribute computations to many more processors than used here.
// "quadrature" point, and extract the electric field vector from
// the gradient in the form of a Tensor variable through the methods
// discussed in the
- // @ref vector_valued "vector-valued problems" documentation module.
+ // @ref vector_valued "vector-valued problems" documentation topic.
const FEValuesExtractors::Scalar electric_potential(0);
fe_face_values[electric_potential].get_function_gradients(
solution, solution_gradients);
// intermediate object of type DynamicSparsityPattern that uses a
// different %internal data structure and that we can later copy into the
// SparsityPattern object without much overhead. (Some more information on
- // these data structures can be found in the @ref Sparsity module.) In order
+ // these data structures can be found in the @ref Sparsity topic.) In order
// to initialize this intermediate data structure, we have to give it the
// size of the matrix, which in our case will be square with as many rows
// and columns as there are degrees of freedom on the grid:
describes the transport of a mixture of two fluids.
The equations covered here fall into the class of vector-valued problems. A
-toplevel overview of this topic can be found in the @ref vector_valued module.
+toplevel overview of this topic can be found in the @ref vector_valued topic.
<h3>The equations</h3>
that the function returns a corresponding object. Similarly, where we
subscript with the pressure extractor, we extract the scalar pressure
component. The whole mechanism is described in more detail in the
-@ref vector_valued module.
+@ref vector_valued topic.
In practice, it turns out that we can do a bit better if we evaluate the shape
functions, their gradients and divergences only once per outermost loop, and
// @ref VVOutput "Generating graphical output"
// section of the
// @ref vector_valued
- // module for more information. Finally, it seems inappropriate for higher
+ // topic for more information. Finally, it seems inappropriate for higher
// order elements to only show a single bilinear quadrilateral per cell in
// the graphical output. We therefore generate patches of size
// (degree+1)x(degree+1) to capture the full information content of the
The equations covered here are an extension of the material already covered in
step-20. In particular, they fall into the class of
vector-valued problems. A toplevel overview of this topic can be found in the
-@ref vector_valued module.
+@ref vector_valued topic.
<h3>The two phase flow problem</h3>
become clear once we discuss the weak form of the equations.
The equations covered here fall into the class of vector-valued problems. A
-toplevel overview of this topic can be found in the @ref vector_valued module.
+toplevel overview of this topic can be found in the @ref vector_valued topic.
<h3>Weak form</h3>
for all test functions $\textbf{v}_h, q_h$. Assembling the linear system
associated with this problem follows the same lines used in @ref step_20
"step-20", step-21, and explained in detail in the @ref
-vector_valued module.
+vector_valued topic.
Think of what would happen if there are constraints on some
pressure variables (see the
@ref constraints "Constraints on degrees of freedom" documentation
-module), for example because we use adaptively
+topic), for example because we use adaptively
refined meshes and continuous pressure finite elements so that there
are hanging nodes. Another cause for such constraints are Dirichlet
boundary conditions on the pressure. Then the AffineConstraints
// processors are available in a machine: for more information see the
// documentation of WorkStream or the
// @ref threads "Parallel computing with multiple processors"
- // module. The matrices for solving linear systems will be filled in the
+ // topic. The matrices for solving linear systems will be filled in the
// run() method because we need to re-apply boundary conditions every time
// step.
mass_matrix.reinit(sparsity_pattern);
addition, most of the functions in the DoFTools, and VectorTools
namespaces accept $hp$-objects in addition to the non-$hp$-ones. Much of
the $hp$-implementation is also discussed in the @ref hp documentation
-module and the links found there.
+topic and the links found there.
It may be worth giving a slightly larger perspective at the end of
this first part of the introduction. $hp$-functionality has been
// several places, we have to do something for all energy groups, in which
// case we will start tasks for each group to let these things run in
// parallel if deal.II was configured for multithreading. For strategies of
- // parallelization, take a look at the @ref threads module.
+ // parallelization, take a look at the @ref threads topic.
//
// The biggest difference to previous example programs is that we also
// declare a nested class that has member variables for all the run-time
tutorial program: see step-58 for this.)
When split into real and imaginary parts, the equations covered here
fall into the class of vector-valued problems. A toplevel overview of
-this topic can be found in the @ref vector_valued module.
+this topic can be found in the @ref vector_valued topic.
In addition to this discussion, we also discuss the ParameterHandler
class, which provides a convenient way for reading parameters from a
// but this information is not relevant here. If you want to
// know more about this function and the underlying scheme
// behind primitive vector valued elements, take a look at
- // step-8 or the @ref vector_valued module, where these topics
+ // step-8 or the @ref vector_valued topic, where these topics
// are explained in depth.
if (fe.system_to_component_index(i).first ==
fe.system_to_component_index(j).first)
@note The preceding overview of all the important steps of any finite element
implementation has its counterpart in deal.II: The library can naturally be
-grouped into a number of "modules" that cover the basic concepts just
-outlined. You can access these modules through the tab at the top of this
+grouped into a number of "topics" that cover the basic concepts just
+outlined. You can access these topics through the "Topics" tab at the top of this
page. An overview of the most fundamental groups of concepts is also available
on the <a href="index.html">front page of the deal.II manual</a>.
\nabla \cdot \kappa \nabla T &=& \gamma.
@f}
These equations fall into the class of vector-valued problems (a
-toplevel overview of this topic can be found in the @ref vector_valued module).
+toplevel overview of this topic can be found in the @ref vector_valued topic).
Here, $\mathbf u$ is the velocity field, $p$ the pressure, and $T$
the temperature of the fluid. $\varepsilon ({\mathbf u}) = \frac 12
[(\nabla{\mathbf u}) + (\nabla {\mathbf u})^T]$ is the symmetric
possible. Furthermore, the elements of these partitionings do not
necessarily be mutually exclusive. This is important because when
postprocessing solutions, we need access to all locally relevant or at least
- the locally active degrees of freedom (see the module on @ref distributed
+ the locally active degrees of freedom (see the topic on @ref distributed
for a definition, as well as the discussion in step-40). Which elements the
Trilinos vector considers as locally owned is not important to us then. All
we care about is that it stores those elements locally that we need.
</ul>
There are a number of other concepts relevant to distributing the mesh
-to a number of processors; you may want to take a look at the @ref
-distributed module and step-40 or step-55 before trying to understand this
+to a number of processors; you may want to take a look at the
+@ref distributed topic and step-40 or step-55 before trying to understand this
program. The rest of the program is almost completely agnostic about
the fact that we don't store all objects completely locally. There
will be a few points where we have to limit loops over all cells to
deal.II has a class that is made for exactly this workflow: WorkStream, first
discussed in step-9 and step-13. Its
-use is also extensively documented in the module on @ref threads (in the section
+use is also extensively documented in the topic on @ref threads (in the section
on @ref MTWorkStream "the WorkStream class") and we won't repeat here the
rationale and detailed instructions laid out there, though you will want to
-read through this module to understand the distinction between scratch space
+read through this topic to understand the distinction between scratch space
and per-cell data. Suffice it to mention that we need the following:
- An iterator range for those cells on which we are supposed to work. This is
// @sect3{Definition of assembly data structures}
//
// As described in the introduction, we will use the WorkStream mechanism
- // discussed in the @ref threads module to parallelize operations among the
+ // discussed in the @ref threads topic to parallelize operations among the
// processors of a single machine. The WorkStream class requires that data
// is passed around in two kinds of data structures, one for scratch data
// and one to pass data from the assembly function to the function that
// @sect4{The BoussinesqFlowProblem assembly functions}
//
// Following the discussion in the introduction and in the @ref threads
- // module, we split the assembly functions into different parts:
+ // topic, we split the assembly functions into different parts:
//
// <ul> <li> The local calculations of matrices and right hand sides, given
// a certain cell as input (these functions are named
This problem obviously falls into the class of vector-valued
problems. A general overview of how to deal with these problems in
-deal.II can be found in the @ref vector_valued module.
+deal.II can be found in the @ref vector_valued topic.
<h3>Discretization</h3>
// however, simplify it a bit taking into account that the $i$th
// (vector-valued) test function $\mathbf{z}_i$ has in reality only a
// single nonzero component (more on this topic can be found in the @ref
- // vector_valued module). It will be represented by the variable
+ // vector_valued topic). It will be represented by the variable
// <code>component_i</code> below. With this, the residual term can be
// re-written as
// @f{eqnarray*}{
// is the part of the system matrix for the diffusion step that changes at
// every time step. As mentioned above, we will run the assembly loop over all
// cells in %parallel, using the WorkStream class and other
- // facilities as described in the documentation module on @ref threads.
+ // facilities as described in the documentation topic on @ref threads.
template <int dim>
void NavierStokesProjection<dim>::assemble_advection_term()
{
of doing this (either using MatrixTools::apply_boundary_values()
<i>after</i> assembling the linear system, or using
AffineConstraints::distribute_local_to_global() <i>during</i> assembly;
-see the @ref constraints "constraints module" for more information),
+see the @ref constraints "constraints topic" for more information),
but both result in the same: a linear system that has a total
number of rows equal to the number of <i>all</i> degrees of freedom,
including those that lie on the boundary. However, degrees of
inhomogeneous constraints <i>j</i> by multiplying the columns <i>j</i> and
rows <i>i</i> of the local matrix according to the integrals $(\varphi_i,
\varphi_j)_\Omega$ by the inhomogeneities and subtracting the resulting from
-the position <i>i</i> in the global right-hand-side vector, see also the @ref
-constraints module. In essence, we use some of the integrals that get
+the position <i>i</i> in the global right-hand-side vector, see also the
+@ref constraints topic. In essence, we use some of the integrals that get
eliminated from the left hand side of the equation to finalize the right hand
side contribution. Similar mathematics are also involved when first writing
all entries into a left hand side matrix and then eliminating matrix rows and
// making sure that only cells are worked on that do not share any degree of
// freedom (this makes the loop thread-safe when writing into destination
// vectors). This is a more advanced strategy compared to the WorkStream
- // class described in the @ref threads module. Of course, to not destroy
+ // class described in the @ref threads topic. Of course, to not destroy
// thread-safety, we have to be careful when writing into class-global
// structures.
//
for sequential operations.
A general overview of how this parallelization happens is described in
-the @ref distributed documentation module. You should read it for a
+the @ref distributed documentation topic. You should read it for a
top-level overview before reading through the source code of this
program. A concise discussion of many terms we will use in the program
is also provided in the @ref distributed_paper "Distributed Computing paper".
Rather than continuing here and giving a long introduction, let us go
straight to the program code. If you have read through step-6 and the
-@ref distributed documentation module, most of things that are going
+@ref distributed documentation topic, most of things that are going
to happen should be familiar to you already. In fact, comparing the two
programs you will notice that the additional effort necessary to make things
work in %parallel is almost insignificant: the two programs have about the
same number of lines of code (though step-6 spends more space on dealing with
coefficients and output). In either case, the comments below will only be on
the things that set step-40 apart from step-6 and that aren't already covered
-in the @ref distributed documentation module.
+in the @ref distributed documentation topic.
@note This program will be able to compute on as many processors as you want
// generate output itself.
#include <deal.II/base/conditional_ostream.h>
// After these preliminaries, here is where it becomes more interesting. As
-// mentioned in the @ref distributed module, one of the fundamental truths of
+// mentioned in the @ref distributed topic, one of the fundamental truths of
// solving problems on large numbers of processors is that there is no way for
// any processor to store everything (e.g. information about all cells in the
// mesh, all degrees of freedom, or the values of all elements of the solution
// consequence, we need to tell the AffineConstraints object for which
// degrees of freedom it can store constraints and for which it may not
// expect any information to store. In our case, as explained in the
- // @ref distributed module, the degrees of freedom we need to care about on
+ // @ref distributed topic, the degrees of freedom we need to care about on
// each processor are the locally relevant ones, so we pass this to the
// AffineConstraints::reinit() function as a second argument. A further
// optimization, AffineConstraint can avoid certain operations if you also
// In particular, for this parallel program, the finite element
// space has associated with it variables that indicate which degrees
// of freedom live on the current processor (the index sets, see
- // also step-40 and the @ref distributed documentation module) as
+ // also step-40 and the @ref distributed documentation topic) as
// well as a variety of constraints: those imposed by hanging nodes,
// by Dirichlet boundary conditions, and by the active set of
// contact nodes. Of the three AffineConstraints variables defined
private:
// In the private section of this class, we first forward declare a number
// of objects that are used in parallelizing work using the WorkStream
- // object (see the @ref threads module for more information on this).
+ // object (see the @ref threads topic for more information on this).
//
// We declare such structures for the computation of tangent (stiffness)
// matrix and right hand side vector, static condensation, and for updating
// assemble the tangent matrix and right hand side vector, the static
// condensation contributions, and update data stored at the quadrature points
// using TBB. Our main tool for this is the WorkStream class (see the @ref
- // threads module for more information).
+ // threads topic for more information).
// Firstly we deal with the tangent matrix and right-hand side assembly
// structures. The PerTaskData object stores local contributions to the global
Before going into more details let us state the obvious: this is a
problem with multiple solution variables; for this, you will probably
-want to read the @ref vector_valued documentation module first, which
+want to read the @ref vector_valued documentation topic first, which
presents the basic philosophical framework in which we address
problems with more than one solution variable. But back to the problem
at hand:
integrate. Actually integrating these terms is not very difficult; for
the Stokes equations, the relevant steps have been shown in step-22,
whereas for the elasticity equation we take essentially the form shown
-in the @ref vector_valued module (rather than the one from step-8).
+in the @ref vector_valued topic (rather than the one from step-8).
The term that is of more interest is the interface term,
@f[
//
// The actual computation of the local matrix is the same as in
// step-22 as well as that given in the @ref vector_valued
- // documentation module for the elasticity equations:
+ // documentation topic for the elasticity equations:
if (cell_is_in_fluid_domain(cell))
{
const unsigned int dofs_per_cell = cell->get_fe().n_dofs_per_cell();
// that are necessary for this approach. You may look up the WorkStream
// namespace as well as the
// @ref threads "Parallel computing with multiple processors"
- // module for more information on how they typically work.
+ // topic for more information on how they typically work.
template <int dim>
struct ScratchData
{
// throws an exception (its second argument) which will usually terminate
// the program giving information where the error occurred and what the
// reason was. (A longer discussion of what exactly the @p Assert macro
- // does can be found in the @ref Exceptions "exception documentation module".)
+ // does can be found in the @ref Exceptions "exception documentation topic".)
// This generally reduces the time to find programming errors
// dramatically and we have found assertions an invaluable means to program
// fast.
data provided by D. Sarah Stamps.</i>
@note This program elaborates on concepts of geometry and the classes that
-implement it. These classes are grouped into the documentation module on @ref
+implement it. These classes are grouped into the documentation topic on @ref
manifold "Manifold description for triangulations". See there for additional
information.
constraints from deal.II, and how to use them in the solution of the
linear system of equations. Before going over the details of the program
below, you may want to take a look at the @ref constraints documentation
-module that explains how these constraints can be computed and what classes in
+topic that explains how these constraints can be computed and what classes in
deal.II work on them.
the issue. step-65 shows another, less manual way to achieve a mesh
well fit to the problem here.
Information on curved domains can also be found in the
-documentation module on @ref manifold "Manifold descriptions".
+documentation topic on @ref manifold "Manifold descriptions".
Why does it make sense to choose a mesh that tracks the internal
interface? There are a number of reasons, but the most essential one
the same must hold true for the basis functions $\varphi_j(\mathbf x)$, which we
can write as $\varphi_j = (\varphi_j^\circ,\varphi_j^\partial)$. If you've
followed the descriptions in step-8, step-20, and the
-@ref vector_valued "documentation module on vector-valued problems",
+@ref vector_valued "documentation topic on vector-valued problems",
it will be no surprise that for some values of $j$, $\varphi_j^\circ$ will be
zero, whereas for other values of $j$, $\varphi_j^\partial$ will be zero -- i.e.,
shape functions will be of either one or the other kind. That is not important,
Within deal.II, the placement of new points during mesh refinement or for the
definition of higher order mappings is controlled by manifold objects, see the
-@ref manifold "manifold module"
+@ref manifold "manifold topic"
for details.
To give an example, consider the following situation of a two-dimensional
-annulus (with pictures taken from the manifold module). If we start with an
+annulus (with pictures taken from the manifold topic). If we start with an
initial mesh of 10 cells and refine the mesh three times globally without
attaching any manifolds, we would obtain the following mesh:
polar manifold, only mid points along the boundary would be placed along the
curved description, whereas mid points in the interior would be computed by
suitable averages of the surrounding points in the Cartesian coordinate system
-(see the @ref manifold "manifold module" for more details).
+(see the @ref manifold "manifold topic" for more details).
At this point, one might assume that curved volume descriptions are the way to
go. This is generally not wrong, though it is sometimes not so easy to
works on any mesh, in any space dimension, and is theoretically guaranteed
to always work, all the time, no exception. This illustrates that deal.II
can be used far beyond the context of variational schemes in Hilbert spaces
-and that a large number of classes, modules and namespaces from deal.II can
+and that a large number of classes, topics, and namespaces from deal.II can
be adapted for such a purpose.
we're not going to cover that in this introduction, but will rather defer this
until the first introductory example where we lay out the key points as this
example unfolds. To complement this, we should mention that the core theory for
-both frameworks is extensively discussed in the @ref auto_symb_diff module, so
+both frameworks is extensively discussed in the @ref auto_symb_diff topic, so
it bears little repeating here.
Since we have to pick *some* sufficiently interesting topic to investigate
<h3>Suggested literature</h3>
-In addition to the already mentioned @ref auto_symb_diff module, the following are a few
+In addition to the already mentioned @ref auto_symb_diff topic, the following are a few
references that discuss in more detail
- magneto-mechanics, and some aspects of automated differentiation frameworks: @cite Pao1978a, @cite Pelteret2019a, and
- the automation of finite element frameworks using AD and/or SD: @cite Logg2012a, @cite Korelc2016a.
// will be a simplified view as to what they *might* be doing in the
// background. This description will be very much one designed to aid
// understanding, and the reader is encouraged to view the @ref auto_symb_diff
- // module documentation for a far more formal description into how these tools
+ // documentation topic for a far more formal description into how these tools
// actually work.
//
// @sect4{An analytical function}
mode ("FAD-FAD") types employed here. The reason that the RAD-FAD type was not
selected by default is that, at the time of writing, there remain some
bugs in its implementation within the Sacado library that lead to memory leaks.
- This is documented in the @ref auto_symb_diff module.
+ This is documented in the @ref auto_symb_diff topic.
- It might be the case that using reduced precision types (i.e., `float`) as the
scalar types for the AD numbers could render a reduction in computational
expense during assembly. Using `float` as the data type for the
In real life, most partial differential equations are really systems
of equations. Accordingly, the solutions are usually
vector-valued. The deal.II library supports such problems (see the
-extensive documentation in the @ref vector_valued module), and we will show
+extensive documentation in the @ref vector_valued topic), and we will show
that that is mostly rather simple. The only more complicated problems
are in assembling matrix and right hand side, but these are easily
understood as well.
But let's get back to the original problem.
How do we assemble the matrix for such an equation? A very long answer
with a number of different alternatives is given in the documentation of the
-@ref vector_valued module. Historically, the solution shown below was the only
+@ref vector_valued topic. Historically, the solution shown below was the only
one available in the early years of the library. It turns out to also be the
fastest. On the other hand, if a few per cent of compute time do not matter,
there are simpler and probably more intuitive ways to assemble the linear
system than the one discussed below but that weren't available until several
years after this tutorial program was first written; if you are interested in
-them, take a look at the @ref vector_valued module.
+them, take a look at the @ref vector_valued topic.
Let us go back to the question of how to assemble the linear system. The first
thing we need is some knowledge about how the shape functions work in the case
relevant places within the program. We will, however, follow the
general discussion of the WorkStream approach detailed in the
@ref threads "Parallel computing with multiple processors accessing shared memory"
-documentation module.
+documentation topic.
<h3>Discretizing the advection equation</h3>
// matrix.
//
// The strategy for parallelization we choose here is one of the
- // possibilities mentioned in detail in the @ref threads module in
+ // possibilities mentioned in detail in the @ref threads topic in
// the documentation. Specifically, we will use the WorkStream
// approach discussed there. Since there is so much documentation
- // in this module, we will not repeat the rationale for the design
- // choices here (for example, if you read through the module
+ // in this group, we will not repeat the rationale for the design
+ // choices here (for example, if you read through the topic
// mentioned above, you will understand what the purpose of the
// <code>AssemblyScratchData</code> and
// <code>AssemblyCopyData</code> structures is). Rather, we will
// does not do this itself, but rather delegates to the function following
// next, utilizing the WorkStream concept discussed in @ref threads .
//
- // If you have looked through the @ref threads module, you will have
+ // If you have looked through the @ref threads topic, you will have
// seen that assembling in parallel does not take an incredible
// amount of extra code as long as you diligently describe what the
// scratch and copy data objects are, and if you define suitable
// The <code>main</code> function is similar to the previous examples. The
// primary difference is that we use MultithreadInfo to set the maximum
-// number of threads (see the documentation module @ref threads
+// number of threads (see the documentation topic @ref threads
// "Parallel computing with multiple processors accessing shared memory"
// for more information). The number of threads used is the minimum of the
// environment variable DEAL_II_NUM_THREADS and the parameter of
*
* See the
* @ref Exceptions
- * module for more details on this class and what can be done with classes
+ * topic for more details on this class and what can be done with classes
* derived from it.
*
* @ingroup Exceptions
*
* A more detailed description can be found in the
* @ref Exceptions
- * module. It is first used in step-5 and step-6.
+ * topic. It is first used in step-5 and step-6.
* See also the <tt>ExceptionBase</tt> class for more information.
*
* @note Active in DEBUG mode only
*
* 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.
+ * topic, in the discussion about the corner case at the bottom of the page.
*
* @note This and similar macro names are examples of preprocessor definitions
* in the deal.II library that are not prefixed by a string that likely makes
*
* A more detailed description can be found in the
* @ref Exceptions
- * module. It is first used in step-9 and step-13.
+ * topic. It is first used in step-9 and step-13.
* See also the <tt>ExceptionBase</tt> class for more information.
*
* @note This and similar macro names are examples of preprocessor definitions
* For a discussion of the kind of problems to which this function is
* applicable, see the
* @ref threads "Parallel computing with multiple processors"
- * module.
+ * topic.
*
* @dealiiConceptRequires{(std::invocable<Function,
* decltype(*std::declval<InputIterator>())> &&
* For a discussion of the kind of problems to which this function is
* applicable, see the
* @ref threads "Parallel computing with multiple processors"
- * module.
+ * topic.
*
* @dealiiConceptRequires{(std::invocable<Function,
* decltype(*std::declval<InputIterator1>()),
* For a discussion of the kind of problems to which this function is
* applicable, see the
* @ref threads "Parallel computing with multiple processors"
- * module.
+ * topic.
*
* @dealiiConceptRequires{(std::invocable<Function,
* decltype(*std::declval<InputIterator1>()),
* For a discussion of the kind of problems to which this function is
* applicable, see also the
* @ref threads "Parallel computing with multiple processors"
- * module.
+ * topic.
*
* @dealiiConceptRequires{(std::invocable<Function, Iterator, Iterator>)}
*/
* For a discussion of the kind of problems to which this function is
* applicable, see also the
* @ref threads "Parallel computing with multiple processors"
- * module.
+ * topic.
*
* @dealiiConceptRequires{(std::invocable<Function, Iterator, Iterator> &&
* std::convertible_to<std::invoke_result_t<Function, Iterator, Iterator>,
* @ref GlossArtificialCell "artificial cells"
* as well as the
* @ref distributed
- * module for more information.
+ * topic for more information.
*
* This value is an example of an
* @ref GlossInvalidValue "invalid value".
* individual subranges onto the available threads. For a lengthy discussion
* of the rationale of this class, see the
* @ref threads "Parallel computing with multiple processors"
- * module. It is used in the tutorial first in step-9, and again in step-13,
+ * topic. It is used in the tutorial first in step-9, and again in step-13,
* step-14, step-32 and others.
*
* The class is built on the following premise: One frequently has some work
* indicating the @p ADNumberTypeCode . The @p ADNumberTypeCode dictates
* which auto-differentiation library is to be used, and what the nature of
* the underlying auto-differentiable number is. Refer to the
- * @ref auto_symb_diff module for more details in this regard.
+ * @ref auto_symb_diff topic for more details in this regard.
*
* For all of the classes derived from this base class, there are two
* possible ways that the code in which they are used can be structured.
* fully distributed mesh. Use of this class is explained in step-40,
* step-32, the
* @ref distributed
- * documentation module, as well as the
+ * documentation topic, as well as the
* @ref distributed_paper.
* See there for more information. This class satisfies the
* @ref ConceptMeshType "MeshType concept".
/**
* An alias that is used to identify cell iterators. The concept of
* iterators is discussed at length in the
- * @ref Iterators "iterators documentation module".
+ * @ref Iterators "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
* An alias that is used to identify
* @ref GlossActive "active cell iterators".
* The concept of iterators is discussed at length in the
- * @ref Iterators "iterators documentation module".
+ * @ref Iterators "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,
* parallel::distributed::Triangulation (see, for example, step-32, step-40
* and in particular the
* @ref distributed
- * module) in which case the DoFHandler object will proceed to only manage
+ * 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.
*
/**
* An alias that is used to identify cell iterators in DoFHandler objects.
* The concept of iterators is discussed at length in the
- * @ref Iterators "iterators documentation module".
+ * @ref Iterators "iterators documentation topic".
*
* The current alias works, in essence, like the corresponding
* Triangulation::cell_accessor alias. However, it also makes available
/**
* An alias that is used to identify iterators that point to faces.
* The concept of iterators is discussed at length in the
- * @ref Iterators "iterators documentation module".
+ * @ref Iterators "iterators documentation topic".
*
* The current alias works, in essence, like the corresponding
* Triangulation::face_accessor alias. However, it also makes available
* An alias that is used to identify
* @ref GlossActive "active cell iterators".
* The concept of iterators is discussed at length in the
- * @ref Iterators "iterators documentation module".
+ * @ref Iterators "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
/**
* An alias that is used to identify cell iterators. The concept of
* iterators is discussed at length in the
- * @ref Iterators "iterators documentation module".
+ * @ref Iterators "iterators documentation topic".
*
* The current alias identifies cells in a DoFHandler object. Some of
* these cells may in fact be active (see
/**
* An alias that is used to identify iterators that point to faces.
* The concept of iterators is discussed at length in the
- * @ref Iterators "iterators documentation module".
+ * @ref Iterators "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
* use an intermediate compressed sparsity pattern that only allocates
* memory on demand. Refer to the step-2 and step-11 example programs on how
* to do this. The problem is also discussed in the documentation of the
- * module on
+ * topic on
* @ref Sparsity.
*/
unsigned int
* internal::TriangulationImplementation::Iterators<1,spacedim>, only the
* treatment of templates is a little more complicated. See the
* @ref Iterators
- * module for more information.
+ * topic for more information.
*/
template <int spacedim, bool lda>
struct Iterators<1, spacedim, lda>
* internal::TriangulationImplementation::Iterators<2,spacedim>, only the
* treatment of templates is a little more complicated. See the
* @ref Iterators
- * module for more information.
+ * topic for more information.
*/
template <int spacedim, bool lda>
struct Iterators<2, spacedim, lda>
* internal::TriangulationImplementation::Iterators<3,spacedim>, only the
* treatment of templates is a little more complicated. See the
* @ref Iterators
- * module for more information.
+ * topic for more information.
*/
template <int spacedim, bool lda>
struct Iterators<3, spacedim, lda>
* constraints for degrees of freedom located on the boundary, then this
* would constitute a conflict. See the
* @ref constraints
- * module for handling the case where there are conflicting constraints on
+ * topic for handling the case where there are conflicting constraints on
* individual degrees of freedom.
* @param component_mask An optional component mask that restricts the
* functionality of this function to a subset of an FESystem. For
* do with how they interact with mappings, quadrature, and the FEValues
* class, you will also want to read through the
* @ref FE_vs_Mapping_vs_FEValues
- * documentation module.
+ * documentation topic.
*
*
* <h4>Interpolation matrices in one dimension</h4>
* @ref step_20 "step-20"
* tutorial programs as well as in the
* @ref vector_valued
- * module.
+ * topic.
*/
std::pair<unsigned int, unsigned int>
system_to_component_index(const unsigned int index) const;
* An extensive discussion of the interaction between this function and
* FEValues can be found in the
* @ref FE_vs_Mapping_vs_FEValues
- * documentation module.
+ * documentation topic.
*
* @see UpdateFlags
*/
* An extensive discussion of the interaction between this function and
* FEValues can be found in the
* @ref FE_vs_Mapping_vs_FEValues
- * documentation module. See also the documentation of the InternalDataBase
+ * documentation topic. See also the documentation of the InternalDataBase
* class.
*
* @param[in] update_flags A set of UpdateFlags values that describe what
* An extensive discussion of the interaction between this function and
* FEValues can be found in the
* @ref FE_vs_Mapping_vs_FEValues
- * documentation module.
+ * documentation topic.
*
* @param[in] cell The cell of the triangulation for which this function is
* to compute a mapping from the reference cell to.
* also BDM and other proposed finite dimensional subspaces of H(div) do not
* work properly on arbitrary FE grids. I.e. the convergence rates deteriorate
* on these meshes. As a solution the authors propose the ABF elements, which
- * are implemented in this module.
+ * are implemented in this class.
*
* This class is not implemented for the codimension one case (<tt>spacedim !=
* dim</tt>).
* tutorial programs, for example step-8, step-20, step-21, step-22, and in
* particular in the
* @ref vector_valued
- * module.
+ * topic.
*
* @dealiiVideoLecture{19,20}
*
*
* This constructor (or its variants below) is used in essentially all
* tutorial programs that deal with vector valued problems. See step-8,
- * step-20, step-22 and others for use cases. Also see the module on
+ * step-20, step-22 and others for use cases. Also see the topic on
* @ref vector_valued "Handling vector valued problems".
*
* @dealiiVideoLecture{19,20}
* <li> Tensor product construction (<code>do_tensor_product=true</code>):
* The tensor product construction, in the simplest case, builds a
* vector-valued element from scalar elements (see
- * @ref vector_valued "this documentation module"
+ * @ref vector_valued "this documentation topic"
* and
* @ref GlossComponent "this glossary entry"
* for more information).
* <h3>Use of these flags flags</h3>
*
* More information on the use of this type both in user code as well as
- * internally can be found in the documentation modules on
+ * internally can be found in the documentation topics pages on
* @ref UpdateFlags "The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues"
* and
* @ref FE_vs_Mapping_vs_FEValues "How Mapping, FiniteElement, and FEValues work together".
* concept of views is explained in the documentation of the namespace
* FEValuesViews and in particular in the
* @ref vector_valued
- * module.
+ * topic.
*/
const FEValuesViews::Scalar<dim, spacedim> &
operator[](const FEValuesExtractors::Scalar &scalar) const;
* finite element. The concept of views is explained in the documentation of
* the namespace FEValuesViews and in particular in the
* @ref vector_valued
- * module.
+ * topic.
*/
const FEValuesViews::Vector<dim, spacedim> &
operator[](const FEValuesExtractors::Vector &vector) const;
* is explained in the documentation of the namespace FEValuesViews and in
* particular in the
* @ref vector_valued
- * module.
+ * topic.
*/
const FEValuesViews::SymmetricTensor<2, dim, spacedim> &
operator[](const FEValuesExtractors::SymmetricTensor<2> &tensor) const;
* vector-valued finite element. The concept of views is explained in the
* documentation of the namespace FEValuesViews and in particular in the
* @ref vector_valued
- * module.
+ * topic.
*/
const FEValuesViews::Tensor<2, dim, spacedim> &
operator[](const FEValuesExtractors::Tensor<2> &tensor) const;
*
* See the description of the
* @ref vector_valued
- * module for examples how to use the features of this namespace.
+ * topic for examples how to use the features of this namespace.
*
* @ingroup feaccess vector_valued
*/
* extractors is defined in the documentation of the namespace
* FEValuesExtractors and in the
* @ref vector_valued
- * module.
+ * topic.
*
* @ingroup feaccess vector_valued
*/
* The concept of extractors is defined in the documentation of the
* namespace FEValuesExtractors and in the
* @ref vector_valued
- * module.
+ * topic.
*
* Note that in the current context, a vector is meant in the sense physics
* uses it: it has <code>spacedim</code> components that behave in specific
* The concept of extractors is defined in the documentation of the
* namespace FEValuesExtractors and in the
* @ref vector_valued
- * module.
+ * topic.
*
* @ingroup feaccess vector_valued
*/
* The concept of extractors is defined in the documentation of the
* namespace FEValuesExtractors and in the
* @ref vector_valued
- * module.
+ * topic.
*
* @ingroup feaccess vector_valued
*/
*
* See the description of the
* @ref vector_valued
- * module for examples how to use the features of this namespace.
+ * topic for examples how to use the features of this namespace.
*
* @ingroup feaccess vector_valued
*/
* A class representing a view to a single scalar component of a possibly
* vector-valued finite element. Views are discussed in the
* @ref vector_valued
- * module.
+ * topic.
*
* You get an object of this type if you apply a FEValuesExtractors::Scalar
* to an FEValues, FEFaceValues or FESubfaceValues object.
* forming a vector part of a vector-valued finite element. Views are
* discussed in the
* @ref vector_valued
- * module.
+ * topic.
*
* Note that in the current context, a vector is meant in the sense physics
* uses it: it has <code>spacedim</code> components that behave in specific
* components forming a symmetric second-order tensor from a vector-valued
* finite element. Views are discussed in the
* @ref vector_valued
- * module.
+ * topic.
*
* This class allows to query the value and divergence of (components of)
* shape functions and solutions representing symmetric tensors. The
* forming a second-order tensor from a vector-valued finite element. Views
* are discussed in the
* @ref vector_valued
- * module.
+ * topic.
*
* This class allows to query the value, gradient and divergence of
* (components of) shape functions and solutions representing tensors. The
* An extensive discussion of the interaction between this function and
* FEValues can be found in the
* @ref FE_vs_Mapping_vs_FEValues
- * documentation module.
+ * documentation topic.
*
* @see UpdateFlags
*/
* An extensive discussion of the interaction between this function and
* FEValues can be found in the
* @ref FE_vs_Mapping_vs_FEValues
- * documentation module.
+ * documentation topic.
*
* @param update_flags A set of flags that define what is expected of the
* mapping class in future calls to transform() or the fill_fe_values()
* An extensive discussion of the interaction between this function and
* FEValues can be found in the
* @ref FE_vs_Mapping_vs_FEValues
- * documentation module.
+ * documentation topic.
*
* @param[in] cell The cell of the triangulation for which this function is
* to compute a mapping from the reference cell to.
*
* This class is used in step-32, in connection with the methods of the
* @ref distributed
- * module.
+ * topic.
*
* @ingroup Iterators
*/
* @endcode
*
* See the
- * @ref manifold "documentation module on manifolds"
+ * @ref manifold "documentation topic on manifolds"
* for more details.
*
* @image html sphere.png
*
* The expectations on orientation and a discussion of this function are
* available in the
- * @ref reordering "reordering module".
+ * @ref reordering "reordering topic".
*
* @param cells The array of CellData objects that describe the mesh's topology.
* @ingroup reordering
* inheriting from Manifold; see the documentation of Manifold, step-49, or
* the
* @ref manifold
- * module for examples and a complete description of the algorithms. By
+ * topic for examples and a complete description of the algorithms. By
* default, all cells in a Triangulation have a flat geometry, meaning that
* all lines in the Triangulation are assumed to be straight. If a cell has a
* manifold_id that is not equal to numbers::flat_manifold_id then the
/**
* An alias that is used to identify cell iterators. The concept of
* iterators is discussed at length in the
- * @ref Iterators "iterators documentation module".
+ * @ref Iterators "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
* An alias that is used to identify
* @ref GlossActive "active cell iterators".
* The concept of iterators is discussed at length in the
- * @ref Iterators "iterators documentation module".
+ * @ref Iterators "iterators documentation topic".
*
* The current alias identifies active cells in a triangulation. The
* TriaActiveIterator class works like a pointer to active objects that when
/**
* An alias that is used to identify iterators that point to faces.
* The concept of iterators is discussed at length in the
- * @ref Iterators "iterators documentation module".
+ * @ref Iterators "iterators documentation topic".
*
* The current alias identifies faces in a triangulation. The
* TriaIterator class works like a pointer to objects that when
* An alias that defines an iterator type to iterate over
* vertices of a mesh. The concept of iterators is discussed at
* length in the
- * @ref Iterators "iterators documentation module".
+ * @ref Iterators "iterators documentation topic".
*
* @ingroup Iterators
*/
* An alias that defines an iterator type to iterate over
* vertices of a mesh. The concept of iterators is discussed at
* length in the
- * @ref Iterators "iterators documentation module".
+ * @ref Iterators "iterators documentation topic".
*
* This alias is in fact identical to the @p vertex_iterator alias
* above since all vertices in a mesh are active (i.e., are a vertex of
*
* As explained in the
* @ref manifold
- * module, the process involved in finding the appropriate manifold
+ * topic, the process involved in finding the appropriate manifold
* description involves querying both the manifold or boundary
* indicators. See there for more information.
*/
* @ref GlossGhostCell "glossary"
* and the
* @ref distributed
- * module for more information.
+ * topic for more information.
*
* @post The returned value is equal to <code>!is_ghost() &&
* !is_artificial()</code>.
* @ref GlossGhostCell "glossary"
* and the
* @ref distributed
- * module for more information.
+ * topic for more information.
*
* @post The returned value is equal to <code>!is_locally_owned() &&
* !is_artificial()</code>.
* @ref GlossArtificialCell "glossary"
* and the
* @ref distributed
- * module for more information.
+ * topic for more information.
*
* @post The returned value is equal to <code>!is_ghost() &&
* !is_locally_owned()</code>.
* This class implements some types which differ between the dimensions.
* These are the declarations for the 1d case only. See the
* @ref Iterators
- * module for more information.
+ * topic for more information.
*
* A @p line_iterator is aliased to an iterator operating on the @p
* lines member variable of a <tt>Triangulation<1></tt> object. An @p
* This class implements some types which differ between the dimensions.
* These are the declarations for the 2d case only. See the
* @ref Iterators
- * module for more information.
+ * topic for more information.
*
* A @p line_iterator is aliased to an iterator operating on the @p
* lines member variable of a <tt>Triangulation<2></tt> object. An @p
* This class implements some types which differ between the dimensions.
* These are the declarations for the 3d case only. See the
* @ref Iterators
- * module for more information.
+ * topic for more information.
*
* For the declarations of the data types, more or less the same holds as
* for lower dimensions (see <tt>Iterators<[12]></tt>). The dimension
*
* It implements the concepts stated in the
* @ref hpcollection
- * module described in the doxygen documentation.
+ * topic described in the doxygen documentation.
*
* @ingroup hp hpcollection
*/
*
* It implements the concepts stated in the
* @ref hpcollection
- * module described in the doxygen documentation.
+ * topic described in the doxygen documentation.
*
* In addition to offering access to the elements of the collection, this
* class provides access to the maximal number of degrees of freedom per
*
* It implements the concepts stated in the
* @ref hpcollection
- * module described in the doxygen documentation.
+ * topic described in the doxygen documentation.
*
* Although it is recommended to supply an appropriate mapping for each
* finite element kind used in a hp-computation, the MappingCollection class
*
* It implements the concepts stated in the
* @ref hpcollection
- * module described in the doxygen documentation.
+ * topic described in the doxygen documentation.
*
* @ingroup hp hpcollection
*/
* constraints on degrees of freedom. The concept and origin of such
* constraints is extensively described in the
* @ref constraints
- * module. The class is meant to deal with a limited number of constraints
+ * topic. The class is meant to deal with a limited number of constraints
* relative to the total number of degrees of freedom, for example a few per
* cent up to maybe 30 per cent; and with a linear combination of <i>M</i>
* other degrees of freedom where <i>M</i> is also relatively small (no larger
* There is also a significant amount of documentation on how to use this
* class in the
* @ref constraints
- * module.
+ * topic.
*
*
* <h3>Description of constraints</h3>
* This function can correctly handle inhomogeneous constraints as well. For
* the parameter use_inhomogeneities_for_rhs see the documentation in
* @ref constraints
- * module.
+ * topic.
*
* @note This function in itself is thread-safe, i.e., it works properly
* also when several threads call it simultaneously. However, the function
* of linear equations. How to solve a linear system of equations with this
* approach is explained in detail in the
* @ref constraints
- * module.
+ * topic.
*
*
* @note Currently, this function may not work correctly for distributed data
*
* A detailed explanation of this approach is given in the
* @ref constraints
- * module.
+ * topic.
*
*
* @note Currently, this function may not work correctly for distributed data
*
* A detailed explanation of this approach is given in the
* @ref constraints
- * module.
+ * topic.
*
*
* @note Currently, this function may not work correctly for distributed data
* certain amount of memory, but grows as necessary. An extensive description
* of sparsity patterns can be found in the documentation of the
* @ref Sparsity
- * module.
+ * topic.
*
* This class is an example of the "dynamic" type of
* @ref Sparsity.
* systems, it is rarely set up directly due to the way it stores its
* information. Rather, one typically goes through an intermediate format
* first, see for example the step-2 tutorial program as well as the
- * documentation module
+ * documentation topic
* @ref Sparsity.
*
* You can iterate over entries in the pattern using begin(), end(),
* from MappingQ and MappingCartesian and for finite elements with tensor
* product structure that work with the
* @ref matrixfree
- * module. In those cases, the cost implied
+ * topic. In those cases, the cost implied
* by this class is similar (or sometimes even somewhat lower) than using
* `FEValues::reinit(cell)` followed by `FEValues::get_function_gradients`.
*/
*
* For details on usage of this class, see the description of FEEvaluation or
* the
- * @ref matrixfree "matrix-free module".
+ * @ref matrixfree "matrix-free topic".
*
* @ingroup matrixfree
*/
* are not set in the second operation on degrees of freedom that are
* already constrained. This makes sure that the discretization remains
* conforming as is needed. See the discussion on conflicting constraints in
- * the module on @ref constraints.
+ * the topic on @ref constraints.
*
* For further information and details on the other function arguments, see
* the interpolate_boundary_values() function with `std::map` arguments and
* are not set in the second operation on degrees of freedom that are
* already constrained. This makes sure that the discretization remains
* conforming as is needed. See the discussion on conflicting constraints in
- * the module on
+ * the topic on
* @ref constraints.
*
* If @p component_mapping is empty, it is assumed that the number of
* the Dirichlet conditions should be set first, and then completed by
* hanging node constraints, in order to make sure that the discretization
* remains consistent. See the discussion on conflicting constraints in the
- * module on
+ * topic on
* @ref constraints.
*
* <h4>Arguments to this function</h4>
* the Dirichlet conditions should be set first, and then completed by
* hanging node constraints, in order to make sure that the discretization
* remains consistent. See the discussion on conflicting constraints in the
- * module on
+ * topic on
* @ref constraints.
*
* The argument @p first_vector_component denotes the first vector component
* are not set in the second operation on degrees of freedom that are
* already constrained. This makes sure that the discretization remains
* conforming as is needed. See the discussion on conflicting constraints in
- * the module on
+ * the topic on
* @ref constraints.
*
*
* function is never called.
*
* The setup_jacobian() function may call a user-supplied function, or a
- * function within the linear solver module, to compute Jacobian-related
+ * function within the linear solver group, to compute Jacobian-related
* data that is required by the linear solver. It may also preprocess that
* data as needed for solve_with_jacobian(), which may involve calling a
* generic function (such as for LU factorization) or, more generally,
projects / dealii.git / commitdiff