From 3d63140266468846e08ba2f01001cad2bf14768e Mon Sep 17 00:00:00 2001 From: Wolfgang Bangerth Date: Wed, 17 Jul 2024 10:40:10 -0600 Subject: [PATCH] Use 'topic' instead of 'module' in the documentation. --- .../automatic_and_symbolic_differentiation.h | 2 +- doc/doxygen/headers/concepts.h | 2 +- doc/doxygen/headers/constraints.h | 2 +- doc/doxygen/headers/cuda.h | 2 +- doc/doxygen/headers/distributed.h | 11 +++--- doc/doxygen/headers/dofs.h | 10 ++--- doc/doxygen/headers/exceptions.h | 4 +- doc/doxygen/headers/fe.h | 20 +++++----- doc/doxygen/headers/geodynamics.h | 2 +- doc/doxygen/headers/glossary.h | 26 ++++++------- doc/doxygen/headers/grid.h | 8 ++-- doc/doxygen/headers/integrators.h | 2 +- doc/doxygen/headers/io.h | 10 ++--- doc/doxygen/headers/lac.h | 4 +- doc/doxygen/headers/main.h | 38 +++++++++---------- doc/doxygen/headers/manifold.h | 6 +-- doc/doxygen/headers/matrices.h | 2 +- doc/doxygen/headers/matrixfree.h | 2 +- doc/doxygen/headers/mesh_worker.h | 2 +- doc/doxygen/headers/multithreading.h | 4 +- doc/doxygen/headers/numerical_algorithms.h | 2 +- doc/doxygen/headers/parallel.h | 4 +- doc/doxygen/headers/petsc.h | 2 +- doc/doxygen/headers/physics.h | 2 +- doc/doxygen/headers/polynomials.h | 2 +- doc/doxygen/headers/preconditioners.h | 4 +- doc/doxygen/headers/quadrature.h | 6 +-- doc/doxygen/headers/reordering.h | 4 +- doc/doxygen/headers/simplex.h | 2 +- doc/doxygen/headers/slepc.h | 2 +- doc/doxygen/headers/solvers.h | 2 +- doc/doxygen/headers/trilinos.h | 2 +- doc/doxygen/headers/utilities.h | 2 +- doc/doxygen/headers/vector_memory.h | 2 +- examples/step-1/doc/intro.dox | 16 ++++---- examples/step-1/doc/results.dox | 4 +- examples/step-13/doc/intro.dox | 2 +- examples/step-13/step-13.cc | 4 +- examples/step-16/step-16.cc | 2 +- examples/step-17/doc/intro.dox | 4 +- examples/step-17/doc/results.dox | 2 +- examples/step-19/step-19.cc | 2 +- examples/step-2/step-2.cc | 2 +- examples/step-20/doc/intro.dox | 4 +- examples/step-20/step-20.cc | 2 +- examples/step-21/doc/intro.dox | 2 +- examples/step-22/doc/intro.dox | 6 +-- examples/step-23/step-23.cc | 2 +- examples/step-27/doc/intro.dox | 2 +- examples/step-28/step-28.cc | 2 +- examples/step-29/doc/intro.dox | 2 +- examples/step-29/step-29.cc | 2 +- examples/step-3/doc/intro.dox | 4 +- examples/step-31/doc/intro.dox | 2 +- examples/step-32/doc/intro.dox | 10 ++--- examples/step-32/step-32.cc | 4 +- examples/step-33/doc/intro.dox | 2 +- examples/step-33/step-33.cc | 2 +- examples/step-35/step-35.cc | 2 +- examples/step-36/doc/intro.dox | 2 +- examples/step-37/doc/results.dox | 4 +- examples/step-37/step-37.cc | 2 +- examples/step-40/doc/intro.dox | 6 +-- examples/step-40/step-40.cc | 4 +- examples/step-42/step-42.cc | 2 +- examples/step-44/step-44.cc | 4 +- examples/step-46/doc/intro.dox | 4 +- examples/step-46/step-46.cc | 2 +- examples/step-47/step-47.cc | 2 +- examples/step-5/step-5.cc | 2 +- examples/step-53/doc/intro.dox | 2 +- examples/step-6/doc/intro.dox | 2 +- examples/step-6/doc/results.dox | 2 +- examples/step-61/doc/intro.dox | 2 +- examples/step-65/doc/intro.dox | 6 +-- examples/step-69/doc/intro.dox | 2 +- examples/step-71/doc/intro.dox | 4 +- examples/step-71/step-71.cc | 2 +- examples/step-72/doc/results.dox | 2 +- examples/step-8/doc/intro.dox | 6 +-- examples/step-9/doc/intro.dox | 2 +- examples/step-9/step-9.cc | 10 ++--- include/deal.II/base/exceptions.h | 8 ++-- include/deal.II/base/parallel.h | 10 ++--- include/deal.II/base/types.h | 2 +- include/deal.II/base/work_stream.h | 2 +- .../deal.II/differentiation/ad/ad_helpers.h | 2 +- include/deal.II/distributed/tria.h | 6 +-- include/deal.II/dofs/dof_handler.h | 14 +++---- include/deal.II/dofs/dof_iterator_selector.h | 6 +-- include/deal.II/dofs/dof_tools.h | 2 +- include/deal.II/fe/fe.h | 10 ++--- include/deal.II/fe/fe_abf.h | 2 +- include/deal.II/fe/fe_system.h | 4 +- include/deal.II/fe/fe_tools.h | 2 +- include/deal.II/fe/fe_update_flags.h | 2 +- include/deal.II/fe/fe_values_base.h | 8 ++-- include/deal.II/fe/fe_values_extractors.h | 10 ++--- include/deal.II/fe/fe_values_views.h | 10 ++--- include/deal.II/fe/mapping.h | 6 +-- include/deal.II/grid/filtered_iterator.h | 2 +- include/deal.II/grid/grid_generator.h | 2 +- include/deal.II/grid/grid_tools_topology.h | 2 +- include/deal.II/grid/tria.h | 12 +++--- include/deal.II/grid/tria_accessor.h | 8 ++-- include/deal.II/grid/tria_iterator_selector.h | 6 +-- include/deal.II/hp/collection.h | 2 +- include/deal.II/hp/fe_collection.h | 2 +- include/deal.II/hp/mapping_collection.h | 2 +- include/deal.II/hp/q_collection.h | 2 +- include/deal.II/lac/affine_constraints.h | 6 +-- .../deal.II/lac/constrained_linear_operator.h | 6 +-- .../deal.II/lac/dynamic_sparsity_pattern.h | 2 +- include/deal.II/lac/sparsity_pattern.h | 2 +- .../deal.II/matrix_free/fe_point_evaluation.h | 2 +- include/deal.II/matrix_free/matrix_free.h | 2 +- .../deal.II/numerics/vector_tools_boundary.h | 8 ++-- .../numerics/vector_tools_constraints.h | 2 +- include/deal.II/sundials/kinsol.h | 2 +- 119 files changed, 268 insertions(+), 271 deletions(-) diff --git a/doc/doxygen/headers/automatic_and_symbolic_differentiation.h b/doc/doxygen/headers/automatic_and_symbolic_differentiation.h index 615cfadd8e..1da7e293de 100644 --- a/doc/doxygen/headers/automatic_and_symbolic_differentiation.h +++ b/doc/doxygen/headers/automatic_and_symbolic_differentiation.h @@ -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, diff --git a/doc/doxygen/headers/concepts.h b/doc/doxygen/headers/concepts.h index c065a6d991..72cdb699a7 100644 --- a/doc/doxygen/headers/concepts.h +++ b/doc/doxygen/headers/concepts.h @@ -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 concepts in the C++ community. This module + * usually referred to as concepts 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 typename in a diff --git a/doc/doxygen/headers/constraints.h b/doc/doxygen/headers/constraints.h index e20b83cfd5..692552e17f 100644 --- a/doc/doxygen/headers/constraints.h +++ b/doc/doxygen/headers/constraints.h @@ -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. * diff --git a/doc/doxygen/headers/cuda.h b/doc/doxygen/headers/cuda.h index 59aab0e0a2..0457b9be51 100644 --- a/doc/doxygen/headers/cuda.h +++ b/doc/doxygen/headers/cuda.h @@ -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. */ diff --git a/doc/doxygen/headers/distributed.h b/doc/doxygen/headers/distributed.h index 0b461f744e..96c16d85e8 100644 --- a/doc/doxygen/headers/distributed.h +++ b/doc/doxygen/headers/distributed.h @@ -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. * diff --git a/doc/doxygen/headers/dofs.h b/doc/doxygen/headers/dofs.h index 2cc5afa5e0..47cb8a9e6f 100644 --- a/doc/doxygen/headers/dofs.h +++ b/doc/doxygen/headers/dofs.h @@ -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 diff --git a/doc/doxygen/headers/exceptions.h b/doc/doxygen/headers/exceptions.h index 08a251c61b..755a6da89c 100644 --- a/doc/doxygen/headers/exceptions.h +++ b/doc/doxygen/headers/exceptions.h @@ -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. * *

Brief overview

@@ -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++ throw mechanism. Since these + * group, using the C++ throw 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. diff --git a/doc/doxygen/headers/fe.h b/doc/doxygen/headers/fe.h index b7c4eab367..6e7fb81903 100644 --- a/doc/doxygen/headers/fe.h +++ b/doc/doxygen/headers/fe.h @@ -18,15 +18,15 @@ * * 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 @@ -113,7 +113,7 @@ /** * @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 [0,1]^d), the @@ -132,7 +132,7 @@ * 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 @@ -150,7 +150,7 @@ * @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 @@ -275,7 +275,7 @@ /** * @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 @@ -294,7 +294,7 @@ * 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 diff --git a/doc/doxygen/headers/geodynamics.h b/doc/doxygen/headers/geodynamics.h index 58b575fb8f..8fc5fbfb74 100644 --- a/doc/doxygen/headers/geodynamics.h +++ b/doc/doxygen/headers/geodynamics.h @@ -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 diff --git a/doc/doxygen/headers/glossary.h b/doc/doxygen/headers/glossary.h index c5f887924a..aa1750a8d1 100644 --- a/doc/doxygen/headers/glossary.h +++ b/doc/doxygen/headers/glossary.h @@ -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 @@ -150,7 +150,7 @@ * Implementation: * 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 @@ -202,7 +202,7 @@ * 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. * * Selecting blocks: @@ -576,12 +576,12 @@ * call the elements of the vector-valued solution components 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 components is the natural @@ -1247,7 +1247,7 @@ * 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. * @@ -1474,7 +1474,7 @@ * *
@anchor GlossLocallyOwnedCell Locally owned cell
*
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. * @@ -1487,7 +1487,7 @@ * *
@anchor GlossLocallyOwnedDof Locally owned degrees of freedom
*
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 @@ -1501,7 +1501,7 @@ * *
@anchor GlossLocallyActiveDof Locally active degrees of freedom
*
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. @@ -1514,7 +1514,7 @@ * *
@anchor GlossLocallyRelevantDof Locally relevant degrees of freedom
*
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. * @@ -1630,11 +1630,11 @@ * 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. *
* - * @see @ref manifold "The module on Manifolds" + * @see @ref manifold "The topic on Manifolds" * * *
@anchor GlossMassMatrix Mass matrix
diff --git a/doc/doxygen/headers/grid.h b/doc/doxygen/headers/grid.h index 7a0f3bd4fb..47b2804a10 100644 --- a/doc/doxygen/headers/grid.h +++ b/doc/doxygen/headers/grid.h @@ -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. @@ -152,7 +152,7 @@ * 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. * * @@ -170,7 +170,7 @@ *

Internal classes

* * 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. */ diff --git a/doc/doxygen/headers/integrators.h b/doc/doxygen/headers/integrators.h index c4ab9d1406..bb001a6479 100644 --- a/doc/doxygen/headers/integrators.h +++ b/doc/doxygen/headers/integrators.h @@ -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. * *

Integration on finite element meshes

* diff --git a/doc/doxygen/headers/io.h b/doc/doxygen/headers/io.h index 4bf8982fe6..a61855ebf3 100644 --- a/doc/doxygen/headers/io.h +++ b/doc/doxygen/headers/io.h @@ -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. * @@ -125,8 +125,8 @@ * @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 diff --git a/doc/doxygen/headers/lac.h b/doc/doxygen/headers/lac.h index 9ceb088a30..c30bf1eae2 100644 --- a/doc/doxygen/headers/lac.h +++ b/doc/doxygen/headers/lac.h @@ -17,11 +17,11 @@ /** * @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 * lac subdirectory, an abbreviation for Linear diff --git a/doc/doxygen/headers/main.h b/doc/doxygen/headers/main.h index ded5f74cb0..1d561e86e2 100644 --- a/doc/doxygen/headers/main.h +++ b/doc/doxygen/headers/main.h @@ -21,9 +21,8 @@ * system, can be found elsewhere. In addition, there are * Tutorial programs on the use of the library. * - * Many of the classes in the deal.II library can be grouped into modules (see - * the Modules page 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 @@ -113,7 +112,7 @@ *
  • %Triangulation: Triangulations are collections of * cells and their lower-dimensional boundary objects. Cells are * images of the reference hypercube [0,1]dim 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 @@ -134,8 +133,8 @@ * 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. * *
  • %Manifold: Manifolds describe the shape of cells and, * more generally, the geometry of the domain on which one wants @@ -150,7 +149,7 @@ * 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. * *
  • %Quadrature: As with finite elements, quadrature * objects are defined on the unit cell. They only describe the @@ -158,7 +157,7 @@ * 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. * *
  • %DoFHandler: %DoFHandler objects are the confluence * of triangulations and finite elements: the finite element class @@ -198,13 +197,13 @@ * 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. * *
  • %Mapping: The next step in a finite element program * is that one would want to compute matrix and right hand side @@ -218,7 +217,7 @@ * 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. * *
  • %FEValues: The next step is to actually take a finite * element and evaluate its shape functions and their gradients at @@ -246,7 +245,7 @@ * 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. * *
  • Linear Systems: If one knows how to evaluate the * values and gradients of shape functions on individual cells using @@ -261,14 +260,14 @@ * 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. * *
  • Linear Solvers: 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. * *
  • Output: Finally, once one has obtained a solution of * a finite element problem on a given triangulation, one will often @@ -277,8 +276,8 @@ * 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. * * * In addition, deal.II has a number of groups of classes that go @@ -288,8 +287,7 @@ * 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 Modules link - * 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 diff --git a/doc/doxygen/headers/manifold.h b/doc/doxygen/headers/manifold.h index 5a3e37e477..3a932e4591 100644 --- a/doc/doxygen/headers/manifold.h +++ b/doc/doxygen/headers/manifold.h @@ -18,7 +18,7 @@ * *

    Overview

    * - * 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 diff --git a/doc/doxygen/headers/matrices.h b/doc/doxygen/headers/matrices.h index f2ab43f8f0..8c43ff9ea1 100644 --- a/doc/doxygen/headers/matrices.h +++ b/doc/doxygen/headers/matrices.h @@ -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 diff --git a/doc/doxygen/headers/matrixfree.h b/doc/doxygen/headers/matrixfree.h index 225713eb61..fbf71a97c0 100644 --- a/doc/doxygen/headers/matrixfree.h +++ b/doc/doxygen/headers/matrixfree.h @@ -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: diff --git a/doc/doxygen/headers/mesh_worker.h b/doc/doxygen/headers/mesh_worker.h index 270fb86fe2..bda5c87b0f 100644 --- a/doc/doxygen/headers/mesh_worker.h +++ b/doc/doxygen/headers/mesh_worker.h @@ -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 diff --git a/doc/doxygen/headers/multithreading.h b/doc/doxygen/headers/multithreading.h index c15bad9ff7..94d90b052a 100644 --- a/doc/doxygen/headers/multithreading.h +++ b/doc/doxygen/headers/multithreading.h @@ -17,10 +17,10 @@ * @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} * diff --git a/doc/doxygen/headers/numerical_algorithms.h b/doc/doxygen/headers/numerical_algorithms.h index a126325ac4..25664ecddd 100644 --- a/doc/doxygen/headers/numerical_algorithms.h +++ b/doc/doxygen/headers/numerical_algorithms.h @@ -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. diff --git a/doc/doxygen/headers/parallel.h b/doc/doxygen/headers/parallel.h index e9aee2de9e..26f997f17e 100644 --- a/doc/doxygen/headers/parallel.h +++ b/doc/doxygen/headers/parallel.h @@ -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. */ diff --git a/doc/doxygen/headers/petsc.h b/doc/doxygen/headers/petsc.h index 1aed3932c0..1efc711ba5 100644 --- a/doc/doxygen/headers/petsc.h +++ b/doc/doxygen/headers/petsc.h @@ -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 diff --git a/doc/doxygen/headers/physics.h b/doc/doxygen/headers/physics.h index cb7f5e05cd..48d6958eb2 100644 --- a/doc/doxygen/headers/physics.h +++ b/doc/doxygen/headers/physics.h @@ -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. */ diff --git a/doc/doxygen/headers/polynomials.h b/doc/doxygen/headers/polynomials.h index ef8bcdcd12..1879892e1a 100644 --- a/doc/doxygen/headers/polynomials.h +++ b/doc/doxygen/headers/polynomials.h @@ -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 diff --git a/doc/doxygen/headers/preconditioners.h b/doc/doxygen/headers/preconditioners.h index 2f90859d13..650f10a7d3 100644 --- a/doc/doxygen/headers/preconditioners.h +++ b/doc/doxygen/headers/preconditioners.h @@ -48,7 +48,7 @@ * @ref ConceptPreconditionerType "the PreconditionerType concept". In * practice, one can usually treat any matrix-like object which defines * vmult() and Tvmult() 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 xk 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 Relaxation in this module + * The classes with names starting with Relaxation in this group * implement this interface, as well as the preconditioners * PreconditionJacobi, PreconditionSOR, PreconditionBlockJacobi, * PreconditionBlockSOR, and PreconditionBlockSSOR. diff --git a/doc/doxygen/headers/quadrature.h b/doc/doxygen/headers/quadrature.h index 28dc91fd0b..55bd82d51c 100644 --- a/doc/doxygen/headers/quadrature.h +++ b/doc/doxygen/headers/quadrature.h @@ -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 @@ -132,7 +132,7 @@ * 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. * * diff --git a/doc/doxygen/headers/reordering.h b/doc/doxygen/headers/reordering.h index f2e1559706..50c538183a 100644 --- a/doc/doxygen/headers/reordering.h +++ b/doc/doxygen/headers/reordering.h @@ -15,12 +15,12 @@ /** * @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. * *

    Orientation of Lines

    diff --git a/doc/doxygen/headers/simplex.h b/doc/doxygen/headers/simplex.h index 2e27b57e2b..452ab22863 100644 --- a/doc/doxygen/headers/simplex.h +++ b/doc/doxygen/headers/simplex.h @@ -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 diff --git a/doc/doxygen/headers/slepc.h b/doc/doxygen/headers/slepc.h index 7cd8b49456..cc4e495f48 100644 --- a/doc/doxygen/headers/slepc.h +++ b/doc/doxygen/headers/slepc.h @@ -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. * diff --git a/doc/doxygen/headers/solvers.h b/doc/doxygen/headers/solvers.h index 86a7a01371..664b432cb8 100644 --- a/doc/doxygen/headers/solvers.h +++ b/doc/doxygen/headers/solvers.h @@ -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. * diff --git a/doc/doxygen/headers/trilinos.h b/doc/doxygen/headers/trilinos.h index 9dc5571f8f..c2ade1d47a 100644 --- a/doc/doxygen/headers/trilinos.h +++ b/doc/doxygen/headers/trilinos.h @@ -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 diff --git a/doc/doxygen/headers/utilities.h b/doc/doxygen/headers/utilities.h index 977e92d32e..4641bfc9fe 100644 --- a/doc/doxygen/headers/utilities.h +++ b/doc/doxygen/headers/utilities.h @@ -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. diff --git a/doc/doxygen/headers/vector_memory.h b/doc/doxygen/headers/vector_memory.h index afb433885d..257c643570 100644 --- a/doc/doxygen/headers/vector_memory.h +++ b/doc/doxygen/headers/vector_memory.h @@ -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. diff --git a/examples/step-1/doc/intro.dox b/examples/step-1/doc/intro.dox index d164a9cac6..22ef7bd9ef 100644 --- a/examples/step-1/doc/intro.dox +++ b/examples/step-1/doc/intro.dox @@ -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 diff --git a/examples/step-1/doc/results.dox b/examples/step-1/doc/results.dox index 50db141743..52bdaac18a 100644 --- a/examples/step-1/doc/results.dox +++ b/examples/step-1/doc/results.dox @@ -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.

    Different geometries

    @@ -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. diff --git a/examples/step-13/doc/intro.dox b/examples/step-13/doc/intro.dox index 787564a69e..e109fc046d 100644 --- a/examples/step-13/doc/intro.dox +++ b/examples/step-13/doc/intro.dox @@ -110,7 +110,7 @@ number of differences compared to previous example programs:
  • 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. diff --git a/examples/step-13/step-13.cc b/examples/step-13/step-13.cc index d806364ca8..b20b827c6a 100644 --- a/examples/step-13/step-13.cc +++ b/examples/step-13/step-13.cc @@ -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 diff --git a/examples/step-16/step-16.cc b/examples/step-16/step-16.cc index 3eef6cd2ef..b3580afcab 100644 --- a/examples/step-16/step-16.cc +++ b/examples/step-16/step-16.cc @@ -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. diff --git a/examples/step-17/doc/intro.dox b/examples/step-17/doc/intro.dox index 4d63ee96ee..d69038fece 100644 --- a/examples/step-17/doc/intro.dox +++ b/examples/step-17/doc/intro.dox @@ -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 every data structure diff --git a/examples/step-17/doc/results.dox b/examples/step-17/doc/results.dox index 03152718c5..75146b4e55 100644 --- a/examples/step-17/doc/results.dox +++ b/examples/step-17/doc/results.dox @@ -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. diff --git a/examples/step-19/step-19.cc b/examples/step-19/step-19.cc index 419439ec91..fe492099ba 100644 --- a/examples/step-19/step-19.cc +++ b/examples/step-19/step-19.cc @@ -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); diff --git a/examples/step-2/step-2.cc b/examples/step-2/step-2.cc index 6a542aeed7..5a24c7f518 100644 --- a/examples/step-2/step-2.cc +++ b/examples/step-2/step-2.cc @@ -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: diff --git a/examples/step-20/doc/intro.dox b/examples/step-20/doc/intro.dox index 1a70670953..fea025dac1 100644 --- a/examples/step-20/doc/intro.dox +++ b/examples/step-20/doc/intro.dox @@ -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.

    The equations

    @@ -335,7 +335,7 @@ tuple. Note that the velocity is of course a dim-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 diff --git a/examples/step-20/step-20.cc b/examples/step-20/step-20.cc index 3e56c528de..abff99b187 100644 --- a/examples/step-20/step-20.cc +++ b/examples/step-20/step-20.cc @@ -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 diff --git a/examples/step-21/doc/intro.dox b/examples/step-21/doc/intro.dox index 283bcea995..c1f66e8557 100644 --- a/examples/step-21/doc/intro.dox +++ b/examples/step-21/doc/intro.dox @@ -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.

    The two phase flow problem

    diff --git a/examples/step-22/doc/intro.dox b/examples/step-22/doc/intro.dox index 7fb69e0eac..3ecc4567ce 100644 --- a/examples/step-22/doc/intro.dox +++ b/examples/step-22/doc/intro.dox @@ -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.

    Weak form

    @@ -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 diff --git a/examples/step-23/step-23.cc b/examples/step-23/step-23.cc index 50839a5866..e94e0d5f7c 100644 --- a/examples/step-23/step-23.cc +++ b/examples/step-23/step-23.cc @@ -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); diff --git a/examples/step-27/doc/intro.dox b/examples/step-27/doc/intro.dox index 5799fde792..dcc8a340ef 100644 --- a/examples/step-27/doc/intro.dox +++ b/examples/step-27/doc/intro.dox @@ -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 diff --git a/examples/step-28/step-28.cc b/examples/step-28/step-28.cc index 9494df4624..ad664acc22 100644 --- a/examples/step-28/step-28.cc +++ b/examples/step-28/step-28.cc @@ -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 diff --git a/examples/step-29/doc/intro.dox b/examples/step-29/doc/intro.dox index 7a0ca531d2..49b6594bc7 100644 --- a/examples/step-29/doc/intro.dox +++ b/examples/step-29/doc/intro.dox @@ -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 diff --git a/examples/step-29/step-29.cc b/examples/step-29/step-29.cc index 536a7eef4b..527197bf6c 100644 --- a/examples/step-29/step-29.cc +++ b/examples/step-29/step-29.cc @@ -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) diff --git a/examples/step-3/doc/intro.dox b/examples/step-3/doc/intro.dox index 6bd2e222ad..92ec8e834d 100644 --- a/examples/step-3/doc/intro.dox +++ b/examples/step-3/doc/intro.dox @@ -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 front page of the deal.II manual. diff --git a/examples/step-31/doc/intro.dox b/examples/step-31/doc/intro.dox index 0babcef744..19ccfbd2bd 100644 --- a/examples/step-31/doc/intro.dox +++ b/examples/step-31/doc/intro.dox @@ -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 diff --git a/examples/step-32/doc/intro.dox b/examples/step-32/doc/intro.dox index 4e5f8e4882..de41fcc20d 100644 --- a/examples/step-32/doc/intro.dox +++ b/examples/step-32/doc/intro.dox @@ -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. 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. 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 diff --git a/examples/step-32/step-32.cc b/examples/step-32/step-32.cc index 327c3818f9..9a2da2758a 100644 --- a/examples/step-32/step-32.cc +++ b/examples/step-32/step-32.cc @@ -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: // //