]> https://gitweb.dealii.org/ - dealii.git/commitdiff
Use 'topic' instead of 'module' in the documentation. 17284/head
authorWolfgang Bangerth <bangerth@colostate.edu>
Wed, 17 Jul 2024 16:40:10 +0000 (10:40 -0600)
committerWolfgang Bangerth <bangerth@colostate.edu>
Thu, 18 Jul 2024 21:04:55 +0000 (15:04 -0600)
119 files changed:
doc/doxygen/headers/automatic_and_symbolic_differentiation.h
doc/doxygen/headers/concepts.h
doc/doxygen/headers/constraints.h
doc/doxygen/headers/cuda.h
doc/doxygen/headers/distributed.h
doc/doxygen/headers/dofs.h
doc/doxygen/headers/exceptions.h
doc/doxygen/headers/fe.h
doc/doxygen/headers/geodynamics.h
doc/doxygen/headers/glossary.h
doc/doxygen/headers/grid.h
doc/doxygen/headers/integrators.h
doc/doxygen/headers/io.h
doc/doxygen/headers/lac.h
doc/doxygen/headers/main.h
doc/doxygen/headers/manifold.h
doc/doxygen/headers/matrices.h
doc/doxygen/headers/matrixfree.h
doc/doxygen/headers/mesh_worker.h
doc/doxygen/headers/multithreading.h
doc/doxygen/headers/numerical_algorithms.h
doc/doxygen/headers/parallel.h
doc/doxygen/headers/petsc.h
doc/doxygen/headers/physics.h
doc/doxygen/headers/polynomials.h
doc/doxygen/headers/preconditioners.h
doc/doxygen/headers/quadrature.h
doc/doxygen/headers/reordering.h
doc/doxygen/headers/simplex.h
doc/doxygen/headers/slepc.h
doc/doxygen/headers/solvers.h
doc/doxygen/headers/trilinos.h
doc/doxygen/headers/utilities.h
doc/doxygen/headers/vector_memory.h
examples/step-1/doc/intro.dox
examples/step-1/doc/results.dox
examples/step-13/doc/intro.dox
examples/step-13/step-13.cc
examples/step-16/step-16.cc
examples/step-17/doc/intro.dox
examples/step-17/doc/results.dox
examples/step-19/step-19.cc
examples/step-2/step-2.cc
examples/step-20/doc/intro.dox
examples/step-20/step-20.cc
examples/step-21/doc/intro.dox
examples/step-22/doc/intro.dox
examples/step-23/step-23.cc
examples/step-27/doc/intro.dox
examples/step-28/step-28.cc
examples/step-29/doc/intro.dox
examples/step-29/step-29.cc
examples/step-3/doc/intro.dox
examples/step-31/doc/intro.dox
examples/step-32/doc/intro.dox
examples/step-32/step-32.cc
examples/step-33/doc/intro.dox
examples/step-33/step-33.cc
examples/step-35/step-35.cc
examples/step-36/doc/intro.dox
examples/step-37/doc/results.dox
examples/step-37/step-37.cc
examples/step-40/doc/intro.dox
examples/step-40/step-40.cc
examples/step-42/step-42.cc
examples/step-44/step-44.cc
examples/step-46/doc/intro.dox
examples/step-46/step-46.cc
examples/step-47/step-47.cc
examples/step-5/step-5.cc
examples/step-53/doc/intro.dox
examples/step-6/doc/intro.dox
examples/step-6/doc/results.dox
examples/step-61/doc/intro.dox
examples/step-65/doc/intro.dox
examples/step-69/doc/intro.dox
examples/step-71/doc/intro.dox
examples/step-71/step-71.cc
examples/step-72/doc/results.dox
examples/step-8/doc/intro.dox
examples/step-9/doc/intro.dox
examples/step-9/step-9.cc
include/deal.II/base/exceptions.h
include/deal.II/base/parallel.h
include/deal.II/base/types.h
include/deal.II/base/work_stream.h
include/deal.II/differentiation/ad/ad_helpers.h
include/deal.II/distributed/tria.h
include/deal.II/dofs/dof_handler.h
include/deal.II/dofs/dof_iterator_selector.h
include/deal.II/dofs/dof_tools.h
include/deal.II/fe/fe.h
include/deal.II/fe/fe_abf.h
include/deal.II/fe/fe_system.h
include/deal.II/fe/fe_tools.h
include/deal.II/fe/fe_update_flags.h
include/deal.II/fe/fe_values_base.h
include/deal.II/fe/fe_values_extractors.h
include/deal.II/fe/fe_values_views.h
include/deal.II/fe/mapping.h
include/deal.II/grid/filtered_iterator.h
include/deal.II/grid/grid_generator.h
include/deal.II/grid/grid_tools_topology.h
include/deal.II/grid/tria.h
include/deal.II/grid/tria_accessor.h
include/deal.II/grid/tria_iterator_selector.h
include/deal.II/hp/collection.h
include/deal.II/hp/fe_collection.h
include/deal.II/hp/mapping_collection.h
include/deal.II/hp/q_collection.h
include/deal.II/lac/affine_constraints.h
include/deal.II/lac/constrained_linear_operator.h
include/deal.II/lac/dynamic_sparsity_pattern.h
include/deal.II/lac/sparsity_pattern.h
include/deal.II/matrix_free/fe_point_evaluation.h
include/deal.II/matrix_free/matrix_free.h
include/deal.II/numerics/vector_tools_boundary.h
include/deal.II/numerics/vector_tools_constraints.h
include/deal.II/sundials/kinsol.h

index 615cfadd8e737add8b9391480ef13bbbb7de5ed4..1da7e293de337fdbdfbe32c5826dac5d221f68bd 100644 (file)
@@ -15,7 +15,7 @@
 /**
  * @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,
index c065a6d9918388372c1768acd30b9cffc20d807d..72cdb699a7faedd1fa1c748625bd39d7b291410b 100644 (file)
@@ -18,7 +18,7 @@
  *
  * 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
index e20b83cfd5983579ab5edfb4cbf26f546b329ca2..692552e17fd51950e3d7634ebf932c79c3e63092 100644 (file)
@@ -17,7 +17,7 @@
  * @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.
  *
index 59aab0e0a252a2c2d7af038848a2c48d1edf283e..0457b9be512ee588f9e352e8b899a3cbe0c559fc 100644 (file)
@@ -16,6 +16,6 @@
 /**
  * @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.
  */
index 0b461f744e72719c1f3c019c1249cd80ca8452bc..96c16d85e8c028e2f44b46691f66584862bb9e29 100644 (file)
@@ -17,7 +17,7 @@
  * @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}
@@ -26,7 +26,7 @@
  *
  * 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
@@ -51,7 +51,7 @@
  *
  * 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.
@@ -66,7 +66,7 @@
  * 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
@@ -426,8 +426,7 @@ namespace parallel
    * 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.
    *
index 2cc5afa5e075da168ec6e415c49be2839f110e5c..47cb8a9e6f63559a005059cd38d527bf8a7edf3a 100644 (file)
@@ -16,7 +16,7 @@
 /**
  * @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
@@ -35,8 +35,8 @@
  * 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
@@ -46,7 +46,7 @@
  * 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
@@ -58,7 +58,7 @@
  * 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
index 08a251c61bd2c481530fdb504d2a92b2aca1861b..755a6da89cf7887f450f9e8ea33fc1781b1d4305 100644 (file)
@@ -16,7 +16,7 @@
 /**
  * @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>
@@ -72,7 +72,7 @@
  *   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.
index b7c4eab3673e7c64509d235837fa8b30c9c0c0ea..6e7fb81903b09c755de0ecfd8f578d6ff3f08d78 100644 (file)
  *
  * 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
@@ -76,7 +76,7 @@
 /**
  * @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
index 58b575fb8f725bafebbe4c6963149bd457aff433..8fc5fbfb748aef0406de1b1260b97e52d6f53044 100644 (file)
@@ -125,7 +125,7 @@ problems. In particular, they are aimed at the following goals:
   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
index c5f887924a9896a8cfbbec1b465938f70fcc83ce..aa1750a8d17edbef40199f4d71b9cce1fc098e95 100644 (file)
@@ -96,8 +96,8 @@
  *
  * 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>
index 7a0f3bd4fb7a5569b7d37b3df7651951e79297dc..47b2804a10aa28c051dbfb8833e80c9c55027f6b 100644 (file)
@@ -16,7 +16,7 @@
 /**
  * @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
@@ -43,7 +43,7 @@
  * (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.
  */
index c4ab9d1406abee9bb2f2297895fd7b830210c308..bb001a6479f4887209a8285a21defbd2525fd60a 100644 (file)
@@ -25,7 +25,7 @@
  *
  * @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>
  *
index 4bf8982fe6d4d130b401788e857dfeded534e3bf..a61855ebf37d8e7e8a7c99a922e2bb90257416c1 100644 (file)
@@ -16,8 +16,8 @@
 /**
  * @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.
  */
 
 /**
@@ -31,7 +31,7 @@
  * 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
index 9ceb088a30be00801294185996d553a8d20ea9ca..c30bf1eae2e83fc828eb15ce76b5e178b95889e4 100644 (file)
 /**
  * @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
index ded5f74cb07412c784a501c1edbdabfb5fc01aef..1d561e86e205c1d1207957584e5ab90646a2b5af 100644 (file)
@@ -21,9 +21,8 @@
  * 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
index 5a3e37e477d703f45a333acba1f41be1a0c7b5f8..3a932e4591f9bf34db76755eff6d41fd6af55476 100644 (file)
@@ -18,7 +18,7 @@
  *
  * <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:
  *
@@ -56,7 +56,7 @@
  *   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).
@@ -94,7 +94,7 @@
  * 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
index f2ab43f8f07d450141c3d4f976b19f4ad0c3451a..8c43ff9ea13d66fa13b494ba5e10f7a12e78193e 100644 (file)
@@ -26,7 +26,7 @@
  * 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
index 225713eb6154c3ca5018b5579589cb82a7ca8b59..fbf71a97c09555abb66d83eccbdcd8fdafa46b93 100644 (file)
@@ -16,7 +16,7 @@
 /**
  * @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:
index 270fb86fe2c9592df28780c9ad73bea248cc337b..bda5c87b0f61977dbd2888c70f4ecadd3253f632 100644 (file)
@@ -19,7 +19,7 @@
  *
  * 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
index c15bad9ff7578c091795cdc8723eb72c2d8e6fd9..94d90b052a7ccac058a29933b7afac1f19881906 100644 (file)
  * @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}
  *
index a126325ac4d133e97a0c97b79d8b839830917528..25664ecddd82022c9987081075872a315ce6079a 100644 (file)
@@ -16,7 +16,7 @@
 /**
  * @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.
index e9aee2de9ef09f8f31b3a67420f09f18545e1024..26f997f17e302c4844498566040479efbbcf2d4d 100644 (file)
@@ -16,9 +16,9 @@
 /**
  * @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.
  */
 
index 1aed3932c0a338eff86ae8ec8ae98b5b6b0fa14b..1efc711ba5089e52d5fbd683410293de810f606d 100644 (file)
@@ -17,7 +17,7 @@
 /**
  * @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
index cb7f5e05cd5183a3ee317b955933935e7c73d416..48d6958eb23c25e8bdf125e6b8a06bf281f0feaf 100644 (file)
@@ -15,7 +15,7 @@
 /**
  * @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.
  */
 
index ef8bcdcd1269682d318212c79c5406b1d124bbd2..1879892e1af6386b844cfaeaf7036db200a4e538 100644 (file)
@@ -16,7 +16,7 @@
 /**
  * @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
index 2f90859d130617fbae7ba545392812923ae25a4b..650f10a7d35ffe5aecfdcdcbbe75fa0158cfc856 100644 (file)
@@ -48,7 +48,7 @@
  * @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
@@ -70,7 +70,7 @@
  * 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.
index 28dc91fd0b07691c9c70b7398eed968f32ebe089..55bd82d51c4172f625ea71830cc29219665684ca 100644 (file)
@@ -16,7 +16,7 @@
 /**
  * @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.
@@ -29,7 +29,7 @@
  * 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.
  *
  *
index f2e1559706b74742b213e6a603aacf6ac16a7dbd..50c538183a82ee9cb0fadd93ab4adbad5ba518f3 100644 (file)
 /**
  * @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>
index 2e27b57e2b96f059d08de0386f7241018a39a6ce..452ab228631386a18d33ae73a4a7ed4cc0c11524 100644 (file)
@@ -16,7 +16,7 @@
 /**
  * @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
index 7cd8b49456a6201d42c94bb189162a4cb9870c98..cc4e495f4858497ddbf61a181da5d7d1c7307527 100644 (file)
@@ -17,7 +17,7 @@
 /**
  * @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.
  *
index 86a7a01371d1770e29605ff99d3c43bc7f7612d5..664b432cb8cdbe6d7d078cf05f0ad372072a273c 100644 (file)
@@ -15,7 +15,7 @@
 /**
  * @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.
  *
index 9dc5571f8f29ec6a6fa2533777c76411ee02289a..c2ade1d47a5d9567084d92544bb94d4e1422dde8 100644 (file)
@@ -17,7 +17,7 @@
 /**
  * @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
index 977e92d32efe820ab2d1f32dc14360eac01b8847..4641bfc9fe0d2961ca93e2f17cbd233f3d20bc10 100644 (file)
@@ -16,7 +16,7 @@
 /**
  * @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.
index afb433885dcdf00f83ab1b4b7907ab49e72ba386..257c6435708f320988d3f478871768ea81428ea7 100644 (file)
@@ -17,7 +17,7 @@
 /**
  * @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.
index d164a9cac655e233000cbc30c98ebbbd00193f1b..22ef7bd9ef048f862692681f7fc4f62cc8b9e426 100644 (file)
@@ -28,20 +28,20 @@ different levels:
   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
@@ -181,7 +181,7 @@ of refining the mesh in this way will illustrate how we iterate (i.e.,
 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
index 50db141743f7f86ef6307ae7430f5048fa475309..52bdaac18a770ca70eaffc9a11ead44131325e64 100644 (file)
@@ -138,7 +138,7 @@ appear in a triangulation), and `CellAccessor` (which adds a few
 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>
@@ -156,7 +156,7 @@ GridGenerator::hyper_shell or GridGenerator::truncated_cone) attach a Manifold
 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.
 
index 787564a69ec4100941d39726224d81166f5c8fda..e109fc046d84ca1d2ca59f46846568b3a941844a 100644 (file)
@@ -110,7 +110,7 @@ number of differences compared to previous example programs:
 <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>
 
index d806364ca825c7106f02abae93c81ae3952f8913..b20b827c6a691fcf98028a508ef7598f36180c0e 100644 (file)
@@ -90,7 +90,7 @@ namespace Step13
   // 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
@@ -708,7 +708,7 @@ namespace Step13
     // 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
index 3eef6cd2efa78d9c54be2cb034d7f5e3c40417aa..b3580afcab7123a31272c654f7c14e9b2ba9f500 100644 (file)
@@ -281,7 +281,7 @@ namespace Step16
 
     // 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.
index 4d63ee96eefcb0f5aa9d190f4a9180c28d1c3428..d69038fecea0418f5d7c0d0240fb0c465ecd1a43 100644 (file)
@@ -64,8 +64,8 @@ space, for example whenever multiple cores in a single machine work
 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
index 03152718c5ac72c041c41a6bf10439c7300a6437..75146b4e552c6eb0afa0a5f327836ca47d81e57d 100644 (file)
@@ -242,7 +242,7 @@ the bottleneck as far as parallelization is concerned.
 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.
index 419439ec91dec299644bb4cd004ec9dcd42ce8f6..fe492099bad1ccd9afb2cd1a41e253cb6ca6af58 100644 (file)
@@ -582,7 +582,7 @@ namespace Step19
             // "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);
index 6a542aeed72928769cd8216bf23c1f625606b0fc..5a24c7f51828b98157b877fd2cb3a3d58674a0a0 100644 (file)
@@ -214,7 +214,7 @@ void distribute_dofs(DoFHandler<2> &dof_handler)
   // 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:
index 1a7067095364158ff57b156c674429cea4b01996..fea025dac10c668bc62cb4a9d70a21ec9a449049 100644 (file)
@@ -27,7 +27,7 @@ solve not only the mixed Laplace equation, but add another equation that
 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>
@@ -335,7 +335,7 @@ tuple. Note that the velocity is of course a <code>dim</code>-dimensional tensor
 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
index 3e56c528de26eaa46e15c5d555c9798bf8f05beb..abff99b187ae282687bb5c4e832168e9582271dc 100644 (file)
@@ -742,7 +742,7 @@ namespace Step20
   // @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
index 283bcea9957a920dc5fe6aea81ac51a4d43ffcf5..c1f66e8557b43bdb94a66351995f41c5f3d86c8d 100644 (file)
@@ -13,7 +13,7 @@ program (besides the somewhat strange time-dependence of @ref step_18
 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>
index 7fb69e0eac7b09b10b76e9c755e371defe6da4f0..3ecc4567cea5f8c937d47e8ec29c17657eccce4f 100644 (file)
@@ -85,7 +85,7 @@ equations. What boundary conditions are readily possible here will
 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>
@@ -400,7 +400,7 @@ that
 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.
 
 
 
@@ -630,7 +630,7 @@ $S=B A^{-1} B^T$. But this is not quite correct.
 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
index 50839a58666823f0eabdc6ecc4215b0f27cb5c0a..e94e0d5f7c52d5ce7b0497d5ca14d68231ef15a1 100644 (file)
@@ -312,7 +312,7 @@ namespace Step23
     // 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);
index 5799fde7927130200770cd7103dba8fd92976208..dcc8a340effe8efc7fcdc0af7f68fb35f8c0f034 100644 (file)
@@ -66,7 +66,7 @@ tasks. We will get to know many of them further down below. In
 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
index 9494df46246b2cd9a18fd904a743d57fc72f0a8d..ad664acc22ae334317bc941c8e0931907b484996 100644 (file)
@@ -1131,7 +1131,7 @@ namespace Step28
   // 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
index 7a0ca531d22a49cc675696418e65b4ad5cfc4c98..49b6594bc7111decbc70b3c491469fb8a6b74ba7 100644 (file)
@@ -28,7 +28,7 @@ keeping everything complex-valued, is demonstrated in a different
 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
index 536a7eef4b0ed57eb7723765801217c953e76b5b..527197bf6ca6cf0f0995272aa4baee937eed61f4 100644 (file)
@@ -598,7 +598,7 @@ namespace Step29
                 // 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)
index 6bd2e222ad8c2948e46f4380985b1e7aef3ec89d..92ec8e834d447c75750169c8a156abae0e60d143 100644 (file)
@@ -232,8 +232,8 @@ be visualized using one of the common visualization programs.
 
 @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>.
 
index 0babcef74481d29d3174a88ad50e23818b984d7e..19ccfbd2bdf0531bd0a90c91eb2262e874c1a5b6 100644 (file)
@@ -40,7 +40,7 @@ Boussinesq equations that read as follows:
   \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
index 4e5f8e4882b7d522a2c22d196b229030445ec9e5..de41fcc20deccaa4e1835adad97ef7d5648b6593 100644 (file)
@@ -721,15 +721,15 @@ are part of Trilinos' Epetra library of basic linear algebra and tool classes:
   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
@@ -779,10 +779,10 @@ href="http://en.wikipedia.org/wiki/Race_condition">race condition</a>.
 
 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
index 327c3818f93991bec61aa88488dd62b2b590bb29..9a2da2758a2c69a743fea92b2d0be8f7efc82751 100644 (file)
@@ -292,7 +292,7 @@ namespace Step32
   // @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
@@ -1975,7 +1975,7 @@ namespace Step32
   // @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
index 4ac461521353a59cdcc7f8c7e4e056b1b421b94f..f8210f9220632d4cf07faba0ebb490b0e5277e93 100644 (file)
@@ -98,7 +98,7 @@ specific heats is $\gamma=1.4$.
 
 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>
 
index aa34727548806ee95b1b1e96c2cd85dd32f8cb1b..526e5782061392be5c82dec2bb2a84c6594003ac 100644 (file)
@@ -1804,7 +1804,7 @@ namespace Step33
     // 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*}{
index 5214ad4fb31ebc4a658f6e49574221a82c07e9b2..689c6f0aa68163568085a54768c1f6eaa880ab9b 100644 (file)
@@ -1122,7 +1122,7 @@ namespace Step35
   // 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()
   {
index 2278da818a5750aa899494edb55232451262552f..d9ce7498441d03088229d43a8d1fa574e73e4109 100644 (file)
@@ -110,7 +110,7 @@ later time when we apply boundary values. There are two basic ways
 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
index 3dfc7770cbb1cef36755944ae3be63253c3ff7d0..3a5194382aa9f8ce15d2cdc969c927f99bfa46fd 100644 (file)
@@ -488,8 +488,8 @@ step-6 and step-7 tutorial programs, we can account for the contribution 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
index 43d7843d9446f6797a90be0966e082befcaabfcc..14d0a5ebcde2636ab44d441a58fd259e9827d742 100644 (file)
@@ -170,7 +170,7 @@ namespace Step37
   // 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.
   //
index 83915dc4b8eb27ce592884f2294a25cd32f25f5d..ba3fa9d9eb25d60bd4c24271725f972aeef5a9b3 100644 (file)
@@ -86,7 +86,7 @@ parallelized because no processor has all the information necessary
 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".
@@ -197,14 +197,14 @@ picture shown below in the results section.
 
 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
index 6f5be975c451dbb0a541358c48ec48c1527b7c70..ba2e09c29260c33f156f278817fefed52ce37c38 100644 (file)
@@ -92,7 +92,7 @@ namespace LA
 // 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
@@ -285,7 +285,7 @@ namespace Step40
     // 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
index e592e738665cd4509c2e3d445b51ea1ade16e871..f50bad68f2b74cafd68df60cfdb9fedf8d2b071b 100644 (file)
@@ -635,7 +635,7 @@ namespace Step42
     // 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
index 8013c822cba9c94aa9a7d1bbf900f70ba55d9b50..53f8ff84033a7e538e9c56a7854e2adf05d443a2 100644 (file)
@@ -816,7 +816,7 @@ namespace Step44
   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
@@ -1139,7 +1139,7 @@ namespace Step44
   // 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
index b76913b1df5c2f63c5643889cdf639527b2de432..ba52a519752bcf4089653b22c09934d7097f4417 100644 (file)
@@ -116,7 +116,7 @@ the subdomains is aligned with coarse mesh cell faces.
 
 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:
@@ -321,7 +321,7 @@ part of the elastic or fluid region before deciding which terms to
 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[
index 621a83425144bbb7ad55988450d53e96fb4ec327..8eb1e529aabe42bfe04e01a78eb7e9444dda5e8e 100644 (file)
@@ -546,7 +546,7 @@ namespace Step46
         //
         // 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();
index 970db603b2a65e74cebbec77b4efd0805552c969..0326a653361e0aa5d33216878061ba5169866e0d 100644 (file)
@@ -268,7 +268,7 @@ namespace Step47
   // 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
   {
index e7ceeb01d390be5e8b4daf8cdc0b73b166ee4f7f..ce954830550a63d25dbeb4668399558cfe789f99 100644 (file)
@@ -338,7 +338,7 @@ void Step5<dim>::run()
   // 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.
index 3456a9e2c984ff3322caeec194e16897500d4d11..16b9aaaebbb5c4626b873f272ee883d7bb4467b6 100644 (file)
@@ -4,7 +4,7 @@
 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.
 
index 408ac007278aadcf98216c87cd59af888a14b953..6df422d41520f4ec81380d169c7d4996bfe50bc5 100644 (file)
@@ -233,7 +233,7 @@ In the program below, we will show how we can get these
 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.
 
 
index dd55215632fc3ad415260eaeeacddba87e1201f3..7f8c7efb23668dde38b77dc6f64f0e955bf4f4ba 100644 (file)
@@ -442,7 +442,7 @@ step-49, step-53, and step-54, among other tutorial programs that cover
 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
index bdf1b35f3c5d818751b37e913f9379a90ecd43c0..914d84fc666c48536278ff12942efa27bc6ecd80 100644 (file)
@@ -238,7 +238,7 @@ Here, since $p_h$ has two components (the interior and the interface components)
 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,
index 14ab612ee8471fad48f52d73f33fb61b96d9963f..4536b6cacb71cdc0789fac7e36e21831a870ba45 100644 (file)
@@ -38,10 +38,10 @@ programmatically from within the source code.
 
 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:
 
@@ -75,7 +75,7 @@ system. By contrast, the case above where only the boundary was subject to the
 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
index 3c6f958f6d94b01b6b91cfe120751c1612f39c25..6e15cd32956a0515d8c859485380b6ac19c155c4 100644 (file)
@@ -220,7 +220,7 @@ this step maximizes the use of finite element software infrastructure,
 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.
 
 
index 49a8a7a64ac6f8354938f70f303463677948fa20..22cc9d27c22f8bae09b856e748430e6cfbf82c63 100644 (file)
@@ -40,7 +40,7 @@ that question is easy to answer but without context is not very insightful. So
 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
@@ -670,7 +670,7 @@ the assisted differentiation frameworks.
 
 <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.
index 352ed3cad184f49b07afaa73c983e25aa293bdfc..ef9699af3856dc7052c1d78f9d6392a0410641f8 100644 (file)
@@ -79,7 +79,7 @@ namespace Step71
   // 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}
index 6896f222dd4b1292e3269057fdfc25e7d7a0504d..61ce7bc0b81adc8b626b441f8416fcbba2270e58 100644 (file)
@@ -122,7 +122,7 @@ be evaluated further:
   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
index 091b9e48fd37fac55020e191d14d0c6201237d2f..58db61ccbec0974651818cb5c50d7133aba66fbb 100644 (file)
@@ -5,7 +5,7 @@
 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.
@@ -156,13 +156,13 @@ href="http://en.wikipedia.org/wiki/Plane_stress#Plane_stress">plan stress</a>.
 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
index 61ebd8480c7031c389e36d16d8a1aa7c67938a4a..17821f1b6a164dc0b6073853c9f5bf15fc0eb743 100644 (file)
@@ -15,7 +15,7 @@ following. The use of multiple threads will then be detailed at the
 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>
index a7f6b6d59f8636b64d9c7567c8ab297633b07cd6..ed85245b13aecd3f6802a8aab4d841e661037908 100644 (file)
@@ -201,11 +201,11 @@ namespace Step9
     // 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
@@ -484,7 +484,7 @@ namespace Step9
   // 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
@@ -1192,7 +1192,7 @@ namespace Step9
 
 // 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
index 17aad0346a26782a2ef7f14adc5c5c7d02aee958..d66451766cedc255c7dfcdd578d398b19510f9a9 100644 (file)
@@ -47,7 +47,7 @@ DEAL_II_NAMESPACE_OPEN
  *
  * 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
@@ -1534,7 +1534,7 @@ namespace deal_II_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
@@ -1664,7 +1664,7 @@ namespace deal_II_exceptions
  *
  * 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
@@ -1718,7 +1718,7 @@ namespace deal_II_exceptions
  *
  * 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
index c94e261badf36bc9542b91d2158d193b6a26659b..d22c8ad696eec4470cf2295acda1feeea7920f20 100644 (file)
@@ -147,7 +147,7 @@ namespace parallel
    * 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>())> &&
@@ -214,7 +214,7 @@ namespace parallel
    * 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>()),
@@ -291,7 +291,7 @@ namespace parallel
    * 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>()),
@@ -443,7 +443,7 @@ namespace parallel
    * 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>)}
    */
@@ -593,7 +593,7 @@ namespace parallel
    * 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>,
index bf2ca9f857395416afa904b2f44ac9eb297ffd97..86fb8e3ccdea1c7454596742ed862e18807048f0 100644 (file)
@@ -353,7 +353,7 @@ namespace numbers
    * @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".
index 03cc2d4e65ab1a3c88698be153d9251ea95f9ad9..a8b0b2bb1c0214293cbbdeb2519f26373cb30931 100644 (file)
@@ -51,7 +51,7 @@ DEAL_II_NAMESPACE_OPEN
  * 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
index a37eaa1ef5503891d7da179eb20d2a45a72f1a3a..4fd48e5c9645c1db3179af1f60c967f97b49e356 100644 (file)
@@ -57,7 +57,7 @@ namespace Differentiation
      * 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.
index f9640b3b98325f25d4933a1379f92061757c142c..33c792537b3d8141d1f7c639b3ea728ccc27b948 100644 (file)
@@ -111,7 +111,7 @@ namespace parallel
      * 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".
@@ -270,7 +270,7 @@ namespace parallel
       /**
        * 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
@@ -291,7 +291,7 @@ namespace parallel
        * 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,
index 5e4efec832dccf013bdeb5279148ba5c93913124..d2f17c369ebe13fa96d4dd622fe80aa174d8e81a 100644 (file)
@@ -166,7 +166,7 @@ namespace parallel
  * 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.
  *
@@ -324,7 +324,7 @@ public:
   /**
    * 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
@@ -338,7 +338,7 @@ public:
   /**
    * 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
@@ -421,7 +421,7 @@ public:
    * 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
@@ -442,7 +442,7 @@ public:
   /**
    * 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
@@ -470,7 +470,7 @@ public:
   /**
    * 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
@@ -863,7 +863,7 @@ public:
    * 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
index 349bbbc29a9c9461262c22d58193baa80b69ba1b..5fffee771a656afabff70099757343fc53957bdc 100644 (file)
@@ -57,7 +57,7 @@ namespace internal
      * 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>
@@ -99,7 +99,7 @@ namespace internal
      * 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>
@@ -139,7 +139,7 @@ namespace internal
      * 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>
index 9789827c615d6dbd5baa326cf07f6791c3db9dc6..49fbe1dfec298c44db1ea0380006034f959ea658 100644 (file)
@@ -2501,7 +2501,7 @@ namespace DoFTools
    * 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
index db4e3b8782f492eb1687ac6a6c0e2a173acad913..744bfa0147b6a08ae4938db531c8818adaf990f7 100644 (file)
@@ -296,7 +296,7 @@ class FESystem;
  * 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>
@@ -1442,7 +1442,7 @@ public:
    * @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;
@@ -2643,7 +2643,7 @@ protected:
    * 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
    */
@@ -2694,7 +2694,7 @@ protected:
    * 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
@@ -2875,7 +2875,7 @@ protected:
    * 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.
index a53409de029111e7cf27efe79dd726958bf89923..4adea08b615261bfd4951d8b90fcb5e17875c5a1 100644 (file)
@@ -49,7 +49,7 @@ DEAL_II_NAMESPACE_OPEN
  * 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>).
index 963404558249ab4304548fc0e7267a93584f7d8a..c5485b86dbcdf6d9a91645518eb972c8f1db7ea9 100644 (file)
@@ -79,7 +79,7 @@ class FE_Enriched;
  * 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}
  *
@@ -233,7 +233,7 @@ public:
    *
    * 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}
index e1c9b2c752daa6193ef0c7926bf017d3cab789a0..0ca89c96aa35b7ae6760b6462ac1598f6f73abfe 100644 (file)
@@ -949,7 +949,7 @@ namespace FETools
    * <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).
index 8fd53b334e5dfa0c85c4f942ef725da6b2a62d47..ecd0aa9d3f10dc34ad15bbaf9dc1ae4c8bbcb40a 100644 (file)
@@ -55,7 +55,7 @@ class FiniteElement;
  * <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".
index 1ff6a2236f7311f664ebd1a9b17d2f551e7d1ff0..f9d6a7d16ead3ba18f5f0effd33cbe71b74371e5 100644 (file)
@@ -1406,7 +1406,7 @@ public:
    * 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;
@@ -1417,7 +1417,7 @@ public:
    * 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;
@@ -1429,7 +1429,7 @@ public:
    * 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;
@@ -1441,7 +1441,7 @@ public:
    * 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;
index 6b2bda6c363f5bf1c4ca1a72ce5e11893b6cb099..55093d9c493141e1e56657494e237f1dddd00b3a 100644 (file)
@@ -74,7 +74,7 @@ DEAL_II_NAMESPACE_OPEN
  *
  * 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
  */
@@ -87,7 +87,7 @@ namespace FEValuesExtractors
    * extractors is defined in the documentation of the namespace
    * FEValuesExtractors and in the
    * @ref vector_valued
-   * module.
+   * topic.
    *
    * @ingroup feaccess vector_valued
    */
@@ -130,7 +130,7 @@ namespace FEValuesExtractors
    * 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
@@ -188,7 +188,7 @@ namespace FEValuesExtractors
    * 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
    */
@@ -235,7 +235,7 @@ namespace FEValuesExtractors
    * 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
    */
index 97f2d93c57c9ae1ce6271ee4153ee248ebe958d4..6a84365e5f05ec3c0d4c81c257e20884fb56f190 100644 (file)
@@ -104,7 +104,7 @@ namespace internal
  *
  * 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
  */
@@ -114,7 +114,7 @@ namespace FEValuesViews
    * 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.
@@ -569,7 +569,7 @@ namespace FEValuesViews
    * 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
@@ -1294,7 +1294,7 @@ namespace FEValuesViews
    * 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
@@ -1607,7 +1607,7 @@ namespace FEValuesViews
    * 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
index f8522b7c2851d536b20980d4534f86fa65eb78c5..0681682686ef66effe11bdc467ef3d8b75f015ce 100644 (file)
@@ -717,7 +717,7 @@ protected:
    * 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
    */
@@ -748,7 +748,7 @@ protected:
    * 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()
@@ -880,7 +880,7 @@ protected:
    * 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.
index e4025eb1acd1591bd8640b7e5b737ed488c603c1..16f113518afcac543ffc1e5d917a66b4d8b52210 100644 (file)
@@ -187,7 +187,7 @@ namespace IteratorFilters
    *
    * This class is used in step-32, in connection with the methods of the
    * @ref distributed
-   * module.
+   * topic.
    *
    * @ingroup Iterators
    */
index 29d8fe4928a2854fff4735aa7f9a7398f3d6037b..5c199efdc3d3ade4482f8d261c0e08854cc1bda4 100644 (file)
@@ -921,7 +921,7 @@ namespace GridGenerator
    * @endcode
    *
    * See the
-   * @ref manifold "documentation module on manifolds"
+   * @ref manifold "documentation topic on manifolds"
    * for more details.
    *
    * @image html sphere.png
index 39d0b2846515b4258095fae894490621166e8196..01995a8d9a041e89a810a2e83822fe5521e4140b 100644 (file)
@@ -166,7 +166,7 @@ namespace GridTools
    *
    * 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
index 86f3f2946d27426396646c083d8f1dc55ddc99a8..9b22b896bc078405bcb182232b752af12c09e765 100644 (file)
@@ -994,7 +994,7 @@ namespace internal
  * 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
@@ -1535,7 +1535,7 @@ public:
   /**
    * 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
@@ -1559,7 +1559,7 @@ public:
    * 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
@@ -1576,7 +1576,7 @@ public:
   /**
    * 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
@@ -1606,7 +1606,7 @@ public:
    * 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
    */
@@ -1616,7 +1616,7 @@ public:
    * 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
index e56691aee54bfa01fda4fd560450d56fd6314dfd..d81e961d8dc84a6bc73774e0efebed555aa189ba 100644 (file)
@@ -1212,7 +1212,7 @@ public:
    *
    * 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.
    */
@@ -3959,7 +3959,7 @@ public:
    * @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>.
@@ -3996,7 +3996,7 @@ public:
    * @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>.
@@ -4039,7 +4039,7 @@ public:
    * @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>.
index 452dea5ec1914effbbfb735a9cb7f5ac103a16cb..6c31bf891b21c9627d06c237116bac3f58276ec5 100644 (file)
@@ -49,7 +49,7 @@ namespace internal
      * 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
@@ -103,7 +103,7 @@ namespace internal
      * 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
@@ -161,7 +161,7 @@ namespace internal
      * 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
index a97b5f02315283c06d819879d23d793580191115..8c35f854417ed9ed360fc35b8c6ff3fed656b597 100644 (file)
@@ -172,7 +172,7 @@ namespace hp
    *
    * It implements the concepts stated in the
    * @ref hpcollection
-   * module described in the doxygen documentation.
+   * topic described in the doxygen documentation.
    *
    * @ingroup hp hpcollection
    */
index 0b5548958287ad5763b60801c8b4e0baf569ca85..c5f0162cff8290dea15ff22402b3e82e76dd0bc3 100644 (file)
@@ -43,7 +43,7 @@ namespace hp
    *
    * 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
index af6f919b070d37f799fab9046e05357c9605d709..c62852a589c4f31d90eb43ef63b16b87db8d60ed 100644 (file)
@@ -38,7 +38,7 @@ namespace hp
    *
    * 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
index 7fc9fe15a7855a8765cc862d0070f501f1774c6a..5f0fa855c36d75dc3d0334f20204332b7c8a99c7 100644 (file)
@@ -37,7 +37,7 @@ namespace hp
    *
    * It implements the concepts stated in the
    * @ref hpcollection
-   * module described in the doxygen documentation.
+   * topic described in the doxygen documentation.
    *
    * @ingroup hp hpcollection
    */
index 7194ba6509a38af0c24d7f35d323c8746ca8d7c6..282ebda8fc52636e9f3db8f9d1c3658cdd39c88f 100644 (file)
@@ -435,7 +435,7 @@ namespace internal
  * 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
@@ -448,7 +448,7 @@ namespace internal
  * 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>
@@ -1681,7 +1681,7 @@ public:
    * 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
index 3aa0159f2021e01583ff5e99d4a3ef2374520d76..459d2ca0d09c9adc8036a01b11b64035da65d5e8 100644 (file)
@@ -50,7 +50,7 @@ DEAL_II_NAMESPACE_OPEN
  * 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
@@ -231,7 +231,7 @@ project_to_constrained_linear_operator(
  *
  * 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
@@ -277,7 +277,7 @@ constrained_linear_operator(
  *
  * 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
index b191f974757b0a6fec66c12f5bd580055ab2f6dd..5222b2954c55f0da770ea7ef3641b67912143a91 100644 (file)
@@ -291,7 +291,7 @@ namespace DynamicSparsityPatternIterators
  * 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.
index 017b5724214a79d02f6ff921f6443e6a491b0c7b..778647e13fd3da432e08bb653a31ae9f05375e5b 100644 (file)
@@ -329,7 +329,7 @@ namespace SparsityPatternIterators
  * 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(),
index ef56931f7e4b1d41494b72c7b2a54f1fcc017793..1b9c3d4ce29588b7c948040ffcf30d44d85f3deb 100644 (file)
@@ -1085,7 +1085,7 @@ protected:
  * 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`.
  */
index 69704c564c7a894b80b6f6b1754a892dce38de03..6a7dfa02ca879d5f2a1e94c36b96b605a8362e23 100644 (file)
@@ -101,7 +101,7 @@ DEAL_II_NAMESPACE_OPEN
  *
  * 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
  */
index d34a9f8cfe7b82a2c307782e6153f8f09af3c51d..da356f8517a1379bd0bc573112b5fb60c74fbb14 100644 (file)
@@ -276,7 +276,7 @@ namespace VectorTools
    * 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
@@ -527,7 +527,7 @@ namespace VectorTools
    * 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
@@ -632,7 +632,7 @@ namespace VectorTools
    * 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>
@@ -716,7 +716,7 @@ namespace VectorTools
    * 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
index e86d6283da36795372004915438c1299343583e1..eba29ac3bfc3a08e5c835dab53bbf72f104e9325 100644 (file)
@@ -122,7 +122,7 @@ namespace VectorTools
    * 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.
    *
    *
index f797dfc2546c58e6a5ac81251dc87e38ebf7713c..2b2a0e6d905886ee685a4d885db4d54ae76cd9da 100644 (file)
@@ -529,7 +529,7 @@ namespace SUNDIALS
      * 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,

In the beginning the Universe was created. This has made a lot of people very angry and has been widely regarded as a bad move.

Douglas Adams


Typeset in Trocchi and Trocchi Bold Sans Serif.