From: Wolfgang Bangerth Date: Sat, 13 Feb 2010 17:44:17 +0000 (+0000) Subject: See to it that we don't have to write '@ref step_12 "step-12"' all the time. Rather... X-Git-Tag: v8.0.0~6459 X-Git-Url: https://gitweb.dealii.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=15a9a508367719f0ce749973779e45684951f3a8;p=dealii.git See to it that we don't have to write '@ref step_12 "step-12"' all the time. Rather, we should be able to just write 'step-12'. git-svn-id: https://svn.dealii.org/trunk@20602 0785d39b-7218-0410-832d-ea1e28bc413d --- diff --git a/deal.II/base/include/base/conditional_ostream.h b/deal.II/base/include/base/conditional_ostream.h index 6262138126..bc7dafbd56 100644 --- a/deal.II/base/include/base/conditional_ostream.h +++ b/deal.II/base/include/base/conditional_ostream.h @@ -29,8 +29,8 @@ DEAL_II_NAMESPACE_OPEN * depending on the ConditionalOStream object being active (default) * or not. The condition of this object can be changed by * set_condition() and in the constructor. This class is used in the - * @ref step_17 "step-17", @ref step_18 "step-18", @ref step_32 "step-32", - * @ref step_33 "step-33", and @ref step_35 "step-35" + * step-17, step-18, step-32, + * step-33, and step-35 * tutorial programs. * * This class is mostly useful in parallel computations. Ordinarily, you would diff --git a/deal.II/base/include/base/convergence_table.h b/deal.II/base/include/base/convergence_table.h index 3b6225f011..20c389891f 100644 --- a/deal.II/base/include/base/convergence_table.h +++ b/deal.II/base/include/base/convergence_table.h @@ -50,8 +50,8 @@ DEAL_II_NAMESPACE_OPEN * that are not signed to be omitted. * * - * A detailed discussion of this class can also be found in the @ref step_7 "step-7" and - * @ref step_13 "step-13" example programs. + * A detailed discussion of this class can also be found in the step-7 and + * step-13 example programs. * * @ingroup textoutput * @author Ralf Hartmann, 1999 diff --git a/deal.II/base/include/base/data_out_base.h b/deal.II/base/include/base/data_out_base.h index d864614305..2e3ccfdff4 100644 --- a/deal.II/base/include/base/data_out_base.h +++ b/deal.II/base/include/base/data_out_base.h @@ -1712,7 +1712,7 @@ class DataOutBase * generate a single output file from it, which may be again in * intermediate format or any of the final formats. This latter option * is most helpful for parallel programs: as demonstrated in the - * @ref step_17 "step-17" example program, it is possible to let only one processor + * step-17 example program, it is possible to let only one processor * generate the graphical output for the entire parallel program, but * this can become vastly inefficient if many processors are involved, * because the load is no longer balanced. The way out is to let each @@ -2556,10 +2556,10 @@ class DataOutInterface : private DataOutBase * be merged, while this is almost impossible once the data has been * written out in any of the supported established graphics formats. * - * This second use scenario is explained in some detail in the @ref step_18 "step-18" + * This second use scenario is explained in some detail in the step-18 * example program. * - * Both these applications are implemented in the @ref step_19 "step-19" example program. + * Both these applications are implemented in the step-19 example program. * There, a slight complication is also explained: in order to read data back * into this object, you have to know the template parameters for the space * dimension which were used when writing the data. If this knowledge is @@ -2567,7 +2567,7 @@ class DataOutInterface : private DataOutBase * (such as in a simple format converter), then it needs to be figured out at * run time, even though the compiler already needs it at compile time. A way * around using the DataOutBase::determine_intermediate_format_dimensions() - * function is explained in @ref step_19 "step-19". + * function is explained in step-19. * * Note that the intermediate format is what its name suggests: a * direct representation of internal data. It isn't standardized and @@ -2636,7 +2636,7 @@ class DataOutReader : public DataOutInterface * patches. * * The use of this function is - * demonstrated in @ref step_19 "step-19". + * demonstrated in step-19. */ void merge (const DataOutReader &other); diff --git a/deal.II/base/include/base/function.h b/deal.II/base/include/base/function.h index aef1afca0a..b5c151a6a8 100644 --- a/deal.II/base/include/base/function.h +++ b/deal.II/base/include/base/function.h @@ -577,7 +577,7 @@ class ConstantFunction : public ZeroFunction * components are zero. It is especially useful as a weight function * for VectorTools::integrate_difference, where it allows to * integrate only one or a few vector components, rather than the - * entire vector-valued solution. See the @ref step_20 "step-20" + * entire vector-valued solution. See the step-20 * tutorial program for a detailed explanation. * * @ingroup functions diff --git a/deal.II/base/include/base/function_parser.h b/deal.II/base/include/base/function_parser.h index 007f44ea80..05bfc484cb 100644 --- a/deal.II/base/include/base/function_parser.h +++ b/deal.II/base/include/base/function_parser.h @@ -47,7 +47,7 @@ template class Vector; * from the fparser.txt file that comes with the fparser library. Please refer * also to that file both for clarifications on how this wrapper works, as * well as for any issue regarding the licence that applies to this class. - * This class is used in the @ref step_33 "step-33" and @ref step_36 "step-36" + * This class is used in the step-33 and step-36 * tutorial programs (the latter being much simpler to understand). * * By using this class you indicate that you accept the terms of the licence diff --git a/deal.II/base/include/base/parameter_handler.h b/deal.II/base/include/base/parameter_handler.h index 9a8d1f3d09..dead3c9534 100644 --- a/deal.II/base/include/base/parameter_handler.h +++ b/deal.II/base/include/base/parameter_handler.h @@ -772,8 +772,8 @@ namespace Patterns * * The ParameterHandler class is discussed in detail in the @ref * step_19 "step-19" example program, and is used in more realistic - * situations in @ref step_29 "step-29", @ref step_33 "step-33" - * and @ref step_34 "step-34". + * situations in step-29, step-33 + * and step-34. * *

Declaring entries

* diff --git a/deal.II/base/include/base/parsed_function.h b/deal.II/base/include/base/parsed_function.h index 376fc87ea0..654ce13dde 100644 --- a/deal.II/base/include/base/parsed_function.h +++ b/deal.II/base/include/base/parsed_function.h @@ -25,7 +25,7 @@ namespace Functions /** * Friendly interface to the FunctionParser class. This class is * meant as a wrapper for the FunctionParser class. It is used in the - * @ref step_34 "step-34" tutorial program. + * step-34 tutorial program. * * It provides two * methods to declare and parse a ParameterHandler object and creates diff --git a/deal.II/base/include/base/table_handler.h b/deal.II/base/include/base/table_handler.h index acacf9279f..72e0192358 100644 --- a/deal.II/base/include/base/table_handler.h +++ b/deal.II/base/include/base/table_handler.h @@ -140,7 +140,7 @@ class TableEntry : public TableEntryBase * to prescribe the format and the captions the columns are written * with in tex mode. * - * A detailed explanation of this class is also given in the @ref step_13 "step-13" tutorial + * A detailed explanation of this class is also given in the step-13 tutorial * program. * * diff --git a/deal.II/base/include/base/timer.h b/deal.II/base/include/base/timer.h index b80691fc18..43462a7ee7 100644 --- a/deal.II/base/include/base/timer.h +++ b/deal.II/base/include/base/timer.h @@ -59,7 +59,7 @@ DEAL_II_NAMESPACE_OPEN * Alternatively, you can also restart the timer instead of resetting * it. The times between successive calls to start()/ stop() will then be * accumulated. The usage of this class is also explained in the - * @ref step_12 "step-12" and @ref step_29 "step-29" tutorial programs. + * step-12 and step-29 tutorial programs. * * @note Implementation of this class is system * dependent. Unfortunately, it does not work with multithreading @@ -262,7 +262,7 @@ class Timer * object. In this case, we did a lot of other stuff, so that the time * proportions of the functions we measured are far away from 100 precent. * - * See the @ref step_32 "step-32" tutorial program for usage of this class. + * See the step-32 tutorial program for usage of this class. * * @ingroup utilities * @author M. Kronbichler, 2009. diff --git a/deal.II/base/include/base/utilities.h b/deal.II/base/include/base/utilities.h index e97cad96e1..a0c69f54f4 100644 --- a/deal.II/base/include/base/utilities.h +++ b/deal.II/base/include/base/utilities.h @@ -367,7 +367,7 @@ namespace Utilities * implementations of Trilinos, sets up the MPI communicator in case the * programs are run in %parallel, and correctly terminates all processes * when the destructor is called. An example usage of this class is shown - * in the tutorial program @ref step_32 "step-32". + * in the tutorial program step-32. */ #ifdef DEAL_II_USE_TRILINOS namespace Trilinos diff --git a/deal.II/deal.II/include/dofs/dof_handler.h b/deal.II/deal.II/include/dofs/dof_handler.h index 728e0e0e61..21d0199550 100644 --- a/deal.II/deal.II/include/dofs/dof_handler.h +++ b/deal.II/deal.II/include/dofs/dof_handler.h @@ -332,7 +332,7 @@ class DoFHandler : public Subscriptor * problem is to use an intermediate * compressed sparsity pattern that only * allocates memory on demand. Refer to - * the @ref step_11 "step-11" example + * the step-11 example * program on how to do this. The problem * is also discussed in the documentation * of the module on @ref Sparsity. diff --git a/deal.II/deal.II/include/dofs/dof_renumbering.h b/deal.II/deal.II/include/dofs/dof_renumbering.h index 9c91a358b4..c88d012540 100644 --- a/deal.II/deal.II/include/dofs/dof_renumbering.h +++ b/deal.II/deal.II/include/dofs/dof_renumbering.h @@ -204,7 +204,7 @@ DEAL_II_NAMESPACE_OPEN * sparsity patterns produced by the various algorithms when using the * $Q_2^d\times Q_1$ element combination typically employed in the * discretization of Stokes equations, when used on the mesh obtained - * in @ref step_22 "step-22" after one adaptive mesh refinement in + * in step-22 after one adaptive mesh refinement in * 3d. The space dimension together with the coupled finite element * leads to a rather dense system matrix with, on average around 180 * nonzero entries per row. After applying each of the reordering @@ -216,7 +216,7 @@ DEAL_II_NAMESPACE_OPEN * right and bottom left. * * The goal of reordering strategies is to improve the - * preconditioner. In @ref step_22 "step-22" we use a SparseILU to + * preconditioner. In step-22 we use a SparseILU to * preconditioner for the velocity-velocity block at the top left. The * quality of the preconditioner can then be measured by the number of * CG iterations required to solve a linear system with this @@ -312,7 +312,7 @@ DEAL_II_NAMESPACE_OPEN * of iterations is only slightly less than with BOOST's Cuthill-McKee * implementation, runtime is significantly less. This, again, may be due * to cache effects. As a consequence, this is the algorithm best suited - * to the testcase, and is in fact used in @ref step_22 "step-22". + * to the testcase, and is in fact used in step-22. * * * Minimum degree enumeration as produced by calling the BOOST implementation @@ -491,7 +491,7 @@ namespace DoFRenumbering * DoFRenumbering namespace. * * This algorithm is used in - * @ref step_22 "step-22". + * step-22. */ template void @@ -662,7 +662,7 @@ namespace DoFRenumbering * possible and results in a * blocking of several components * into one. This is discussed in - * @ref step_22 "step-22". If you + * step-22. If you * omit this argument, the same * order as given by the finite * element is used. diff --git a/deal.II/deal.II/include/dofs/dof_tools.h b/deal.II/deal.II/include/dofs/dof_tools.h index 4752f92904..297c42b169 100644 --- a/deal.II/deal.II/include/dofs/dof_tools.h +++ b/deal.II/deal.II/include/dofs/dof_tools.h @@ -409,7 +409,7 @@ class DoFTools * function. No call to * ConstraintMatrix::condense() is then * necessary. This process is explained - * in @ref step_27 "step-27". + * in step-27. * * In case the constraints are * already taken care of in this @@ -446,7 +446,7 @@ class DoFTools * pattern that corresponds to the * subdomain_id for which it is * responsible. This feature is - * @ref step_32 "step-32". + * step-32. */ template static @@ -602,7 +602,7 @@ class DoFTools * pattern that corresponds to the * subdomain_id for which it is * responsible. This feature is - * @ref step_32 "step-32". + * step-32. */ template static @@ -1383,9 +1383,9 @@ class DoFTools * case, an assertion is thrown. * * This function is used in the - * @ref step_22 "step-22", - * @ref step_31 "step-31", and - * @ref step_32 "step-32" tutorial + * step-22, + * step-31, and + * step-32 tutorial * programs. */ template @@ -1795,7 +1795,7 @@ class DoFTools * Make a constraint matrix for the * constraints that result from zero * boundary values. This function is used - * in @ref step_36 "step-36", for + * in step-36, for * example. */ template class DH> diff --git a/deal.II/deal.II/include/fe/fe.h b/deal.II/deal.II/include/fe/fe.h index ac61e81062..39fdc9b2b4 100644 --- a/deal.II/deal.II/include/fe/fe.h +++ b/deal.II/deal.II/include/fe/fe.h @@ -1240,7 +1240,7 @@ class FiniteElement : public Subscriptor, * * The use of this function is * explained extensively in the - * @ref step_8 "step-8" and @ref + * step-8 and @ref * step_20 "step-20" tutorial * programs as well as in the * @ref vector_valued module. diff --git a/deal.II/deal.II/include/fe/fe_system.h b/deal.II/deal.II/include/fe/fe_system.h index 4e12dc02ba..295c9d93b2 100644 --- a/deal.II/deal.II/include/fe/fe_system.h +++ b/deal.II/deal.II/include/fe/fe_system.h @@ -30,8 +30,8 @@ DEAL_II_NAMESPACE_OPEN * finite element object, which is composed of several other finite elements * that are possibly of different type. The result is then a vector-valued * finite element. Vector valued elements are discussed in a number of - * tutorial programs, for example @ref step_8 "step-8", @ref step_20 - * "step-20", @ref step_21 "step-21", and in particular in the @ref vector_valued + * tutorial programs, for example step-8, @ref step_20 + * "step-20", step-21, and in particular in the @ref vector_valued * module. * * The overall numbering of degrees of freedom is as follows: for each diff --git a/deal.II/deal.II/include/fe/fe_tools.h b/deal.II/deal.II/include/fe/fe_tools.h index dccdc7c1dc..9d4c141ac9 100644 --- a/deal.II/deal.II/include/fe/fe_tools.h +++ b/deal.II/deal.II/include/fe/fe_tools.h @@ -565,7 +565,7 @@ class FETools * quadrature points. * * A use for this function is described - * in the introduction to the @ref step_18 "step-18" + * in the introduction to the step-18 * example program. * * The opposite of this function, diff --git a/deal.II/deal.II/include/grid/filtered_iterator.h b/deal.II/deal.II/include/grid/filtered_iterator.h index b11fa3dc9d..0a7fb90297 100644 --- a/deal.II/deal.II/include/grid/filtered_iterator.h +++ b/deal.II/deal.II/include/grid/filtered_iterator.h @@ -208,8 +208,8 @@ namespace IteratorFilters * called with a pair of iterators denoting a range on which they * shall act, by choosing a filtered iterator instead of usual ones. * - * This class is used in @ref step_18 "step-18" and - * @ref step_32 "step-32". + * This class is used in step-18 and + * step-32. * * *

Predicates

diff --git a/deal.II/deal.II/include/grid/grid_generator.h b/deal.II/deal.II/include/grid/grid_generator.h index 311ab03e5d..1f6051681d 100644 --- a/deal.II/deal.II/include/grid/grid_generator.h +++ b/deal.II/deal.II/include/grid/grid_generator.h @@ -206,7 +206,7 @@ class GridGenerator * * @note For an example of the * use of this function see the - * @ref step_28 "step-28" + * step-28 * tutorial program. */ template diff --git a/deal.II/deal.II/include/grid/grid_tools.h b/deal.II/deal.II/include/grid/grid_tools.h index d34e920e9c..c4ef0cc767 100644 --- a/deal.II/deal.II/include/grid/grid_tools.h +++ b/deal.II/deal.II/include/grid/grid_tools.h @@ -719,7 +719,7 @@ class GridTools /** * Return the diamater of the smallest * active cell of a triangulation. See - * @ref step_24 "step-24" for an example + * step-24 for an example * of use of this function. */ template diff --git a/deal.II/deal.II/include/grid/tria.h b/deal.II/deal.II/include/grid/tria.h index 34714110dc..2d371d03c6 100644 --- a/deal.II/deal.II/include/grid/tria.h +++ b/deal.II/deal.II/include/grid/tria.h @@ -899,7 +899,7 @@ namespace internal * surprising fact may lead to programs that do the wrong thing * since they are not written for the additional cases that can * happen with anisotropic meshes, see the discussion in the - * introduction to @ref step_30 "step-30". + * introduction to step-30. * *
  • @p none: * Select no smoothing at all. @@ -918,7 +918,7 @@ namespace internal * This material_id may be set upon construction of a * triangulation (through the CellData data structure), or later * through use of cell iterators. For a typical use of this - * functionality, see the @ref step_28 "step-28" tutorial + * functionality, see the step-28 tutorial * program. The functions of the GridGenerator namespace typically * set the material ID of all cells to zero. When reading a * triangulation, the material id must be specified in the input diff --git a/deal.II/deal.II/include/grid/tria_accessor.h b/deal.II/deal.II/include/grid/tria_accessor.h index 47c97d1127..e7b0e8d096 100644 --- a/deal.II/deal.II/include/grid/tria_accessor.h +++ b/deal.II/deal.II/include/grid/tria_accessor.h @@ -2038,7 +2038,7 @@ class CellAccessor : public TriaAccessor * cell->neighbor(neighbor)->face(face_no)->child(subface_no)==cell->face(neighbor). * This case in 3d and how it can happen * is discussed in the introduction of the - * @ref step_30 "step-30" tutorial program. + * step-30 tutorial program. * * This function is impossible * for dim==1. diff --git a/deal.II/deal.II/include/hp/fe_values.h b/deal.II/deal.II/include/hp/fe_values.h index 3486441199..aaf18849b2 100644 --- a/deal.II/deal.II/include/hp/fe_values.h +++ b/deal.II/deal.II/include/hp/fe_values.h @@ -200,7 +200,7 @@ namespace hp { /** - * An hp equivalent of the ::FEValues class. See the @ref step_27 "step-27" + * An hp equivalent of the ::FEValues class. See the step-27 * tutorial program for examples of use. * * The idea of this class is as follows: when one assembled matrices in the hp diff --git a/deal.II/deal.II/include/numerics/data_component_interpretation.h b/deal.II/deal.II/include/numerics/data_component_interpretation.h index 73f0c64979..e505fd7cb9 100644 --- a/deal.II/deal.II/include/numerics/data_component_interpretation.h +++ b/deal.II/deal.II/include/numerics/data_component_interpretation.h @@ -48,7 +48,7 @@ namespace DataComponentInterpretation * DataOut_DoFData::add_data_vector * functions, this can be achieved. * - * See the @ref step_22 "step-22" tutorial + * See the step-22 tutorial * program for an example on how this * information can be used in practice. * diff --git a/deal.II/deal.II/include/numerics/data_out.h b/deal.II/deal.II/include/numerics/data_out.h index 8e0d7e4774..2fe312fdbe 100644 --- a/deal.II/deal.II/include/numerics/data_out.h +++ b/deal.II/deal.II/include/numerics/data_out.h @@ -190,7 +190,7 @@ namespace internal * it allows to attach DataPostprocessor arguments to compute derived * information from a data vector at each quadrature point (for example, the * Mach number in hypersonic flow can be computed from density and velocities; - * @ref step_29 "step-29" also shows an example); another piece of information + * step-29 also shows an example); another piece of information * specified through arguments with default values is how certain output * components should be interpreted, i.e. whether each component of the data * is logically an independent scalar field, or whether some of them together @@ -1176,7 +1176,7 @@ class DataOut_DoFData : public DataOutInterface * By default, this class produces patches for all active cells. Sometimes, * this is not what you want, maybe because they are simply too many (and too * small to be seen individually) or because you only want to see a certain - * region of the domain (for example in parallel programs such as the @ref step_18 "step-18" + * region of the domain (for example in parallel programs such as the step-18 * example program), or for some other reason. * * For this, internally build_patches() does not generate diff --git a/deal.II/deal.II/include/numerics/data_postprocessor.h b/deal.II/deal.II/include/numerics/data_postprocessor.h index 08578d241a..8fd4567a9c 100644 --- a/deal.II/deal.II/include/numerics/data_postprocessor.h +++ b/deal.II/deal.II/include/numerics/data_postprocessor.h @@ -33,8 +33,8 @@ DEAL_II_NAMESPACE_OPEN * and possibly the first and second derivates of the solution. Examples are * the calculation Mach numbers from velocity and density in supersonic flow * computations, or the computation of the magnitude of a complex-valued - * solution as demonstrated in @ref step_29 "step-29". Other uses are shown in - * @ref step_33 "step-33". This class offers the interface to perform such + * solution as demonstrated in step-29. Other uses are shown in + * step-33. This class offers the interface to perform such * postprocessing. Given the values and derivatives of the solution at those * points where we want to generated output, the functions of this class can * be overloaded to compute new quantities. diff --git a/deal.II/deal.II/include/numerics/matrices.h b/deal.II/deal.II/include/numerics/matrices.h index 4374632304..07ff818112 100644 --- a/deal.II/deal.II/include/numerics/matrices.h +++ b/deal.II/deal.II/include/numerics/matrices.h @@ -943,8 +943,8 @@ class MatrixTools : public MatrixCreator * an MPI system. * * This function is used in - * @ref step_17 "step-17" and - * @ref step_18 "step-18". + * step-17 and + * step-18. */ static void apply_boundary_values (const std::map &boundary_values, diff --git a/deal.II/deal.II/include/numerics/mesh_worker.h b/deal.II/deal.II/include/numerics/mesh_worker.h index d7a482ba0a..4dc8718f46 100644 --- a/deal.II/deal.II/include/numerics/mesh_worker.h +++ b/deal.II/deal.II/include/numerics/mesh_worker.h @@ -58,7 +58,7 @@ template class MGDoFHandler; * * The integration_loop() function loop takes most of the information * that it needs to pass to loop() from an IntegrationInfoBox - * object. Its use is explained in @ref step_38 "step-38", but in + * object. Its use is explained in step-38, but in * short it requires functions that do the local integration on a * cell, interior or boundary face, and it needs an object (called * "assembler") that copies these local contributions into the global diff --git a/deal.II/deal.II/include/numerics/solution_transfer.h b/deal.II/deal.II/include/numerics/solution_transfer.h index 249d86a61b..bd49a045e4 100644 --- a/deal.II/deal.II/include/numerics/solution_transfer.h +++ b/deal.II/deal.II/include/numerics/solution_transfer.h @@ -31,8 +31,8 @@ DEAL_II_NAMESPACE_OPEN * Transfers a discrete FE function (like a solution vector) by interpolation * while refining and/or coarsening a grid. During interpolation the * vector is reinitialized to the new size and filled with the interpolated - * values. This class is used in the @ref step_15 "step-15", - * @ref step_31 "step-31", and @ref step_33 "step-33" tutorial programs. + * values. This class is used in the step-15, + * step-31, and step-33 tutorial programs. * *

    Usage

    * @@ -84,7 +84,7 @@ DEAL_II_NAMESPACE_OPEN * soltrans.refine_interpolate(solutions_old, solutions); * @endverbatim * This is used in several of the tutorial programs, for example - * @ref step_31 "step-31". + * step-31. * *
  • If the grid will be refined AND coarsened * then use @p SolutionTransfer as follows diff --git a/deal.II/deal.II/include/numerics/vectors.h b/deal.II/deal.II/include/numerics/vectors.h index 8b6f7947e0..0acec10fbb 100644 --- a/deal.II/deal.II/include/numerics/vectors.h +++ b/deal.II/deal.II/include/numerics/vectors.h @@ -107,7 +107,7 @@ class ConstraintMatrix; * \phi_i(x) \phi_j(x) dx$ and $f_i = \int_\Omega f(x) \phi_i(x) * dx$. The solution vector $v$ then is the nodal representation of * the projection fh. The project() functions are - * used in the @ref step_21 "step-21" and @ref step_23 "step-23" + * used in the step-21 and step-23 * tutorial programs. * * In order to get proper results, it be may necessary to treat @@ -970,7 +970,7 @@ class VectorTools * * The use of this function is * explained in more detail in - * @ref step_31 "step-31". It + * step-31. It * doesn't make much sense in 1d, * so the function throws an * exception in that case. diff --git a/deal.II/doc/doxygen/filter b/deal.II/doc/doxygen/filter index cf140166a6..5a0434f787 100755 --- a/deal.II/doc/doxygen/filter +++ b/deal.II/doc/doxygen/filter @@ -6,7 +6,7 @@ s/\$/\@f\$/g; # however, undo that change if the dollar sign was escaped with a backslash s/\\\@f\$/\$/g; -# we don't let doxygen put everything into a namespace +# We don't let doxygen put everything into a namespace # dealii. consequently, doxygen can't link references that contain an # explicit dealii:: qualification. remove it and replace it by the # global scope @@ -15,3 +15,12 @@ s/\\\@f\$/\$/g; # that's not our fault. This is reported here: # http://bugzilla.gnome.org/show_bug.cgi?id=365053 s/dealii::/::/g; + +# Replace all occurrences of something like step-xx by +# @ref step_xx "step-xx" +# so that doxygen properly cross references them. Before we had +# this rule, we actually had to write this sequence out in our +# documentation. Unfortunately, as a consequence, there are vestiges +# of this style, so we can't substitute things that look like +# "step-xx". +s/(?throw mechanism. Since these @@ -201,7 +201,7 @@ * @code * Assert (false, ExcInternalError()); * @endcode - * See the @ref step_7 "step-7" and several other of the tutorial programs for + * See the step-7 and several other of the tutorial programs for * a use of this construct. * * As mentioned above, the program is terminated once a call to diff --git a/deal.II/doc/doxygen/headers/geodynamics.h b/deal.II/doc/doxygen/headers/geodynamics.h index 97206f0970..47afee7243 100644 --- a/deal.II/doc/doxygen/headers/geodynamics.h +++ b/deal.II/doc/doxygen/headers/geodynamics.h @@ -27,13 +27,13 @@ follows below. Currently, the geodynamics testsuite contains the following programs: -- @ref step_8 "step-8": Elasticity -- @ref step_16 "step-16": A %parallel elasticity solver -- @ref step_20 "step-20": Porous media flow -- @ref step_21 "step-21": Multiphase flow through porous media -- @ref step_22 "step-22": Stokes flow -- @ref step_31 "step-31": Thermal convection (Boussinesq flow) -- @ref step_32 "step-32": A %parallel Boussinesq solver for mantle convection +- step-8: Elasticity +- step-16: A %parallel elasticity solver +- step-20: Porous media flow +- step-21: Multiphase flow through porous media +- step-22: Stokes flow +- step-31: Thermal convection (Boussinesq flow) +- step-32: A %parallel Boussinesq solver for mantle convection Some of these programs were developed under contract from the California Institute of Technology with support by the National Science Foundation @@ -131,7 +131,7 @@ problems. In particular, they are aimed at the following goals: run on larger scale machines. For example, a small mantle convection code built on deal.II may be used to determine whether second order elements are useful for this purpose (see, for example, the results shown in - @ref step_31 "step-31"). If so, then one may use this result to implement + step-31). If so, then one may use this result to implement second, rather than first, order elements in dedicated, large-scale mantle convection codes such as that which Ghattas and Zhong are building and that may run on 10,000s of processors, a diff --git a/deal.II/doc/doxygen/headers/glossary.h b/deal.II/doc/doxygen/headers/glossary.h index 6d0829db53..1102010d6c 100644 --- a/deal.II/doc/doxygen/headers/glossary.h +++ b/deal.II/doc/doxygen/headers/glossary.h @@ -48,8 +48,8 @@ * by creating one block for each vector component. However, this is not * always so, and the DoFRenumbering::component_wise function allows to group * several vector components into the same block (see, for example, the @ref - * step_22 "step-22" or @ref step_31 "step-31" tutorial programs, as opposed - * to @ref step_20 "step-20"). + * step_22 "step-22" or step-31 tutorial programs, as opposed + * to step-20). * *
    @anchor GlossComponent Component
    * @@ -160,7 +160,7 @@ * * The function Triangulation::create_triangulation, which is called * by the various functions in GridGenerator and GridIn (but can also - * be called from user code, see @ref step_14 "step-14" will signal + * be called from user code, see step-14 will signal * the creation of coarse meshes with distorted cells by throwing an * exception of type Triangulation::DistortedCellList. There are * legitimate cases for creating meshes with distorted cells (in @@ -315,7 +315,7 @@ Article{BK07, * from http://www.math.tamu.edu/~bangerth/publications.html . * * The numerical examples shown in that paper are generated with a slightly - * modified version of @ref step_27 "step-27". The main difference to that + * modified version of step-27. The main difference to that * tutorial program is that various operations in the program were timed for * the paper to compare different options and show that $hp$ methods are * really not all that expensive. @@ -343,7 +343,7 @@ Article{BK07, * "Adaptive multilevel methods with local smoothing", that * describes many of the algorithms and data structures used in the implementation * of the multigrid framework of deal.II. It underlies the implementation of - * the classes that are used in @ref step_16 "step-16" for multigrid + * the classes that are used in step-16 for multigrid * methods. * * The full reference for this paper is as follows: @@ -406,10 +406,10 @@ Article{JK10, * element is primitive. This includes, in particular, all scalar * elements as well as vector-valued elements assembled via the * FESystem class from other primitive (for example scalar) elements - * as shown in @ref step_8 "step-8", @ref step_29 "step_29", @ref + * as shown in step-8, @ref step_29 "step_29", @ref * step_22 "step-22" and several others. On the other hand, * the FE_RaviartThomas class used - * in @ref step_20 "step-20" and @ref step_21 "step-21", or the + * in step-20 and step-21, or the * FE_Nedelec class provide non-primitive finite elements because * there, each vector-value shape function may have several non-zero * components. @@ -434,8 +434,8 @@ Article{JK10, * cell is associated with. * * For programs that are parallelized based on MPI but where each processor - * stores the entire triangulation (as in, for example, @ref step_18 "step-18" - * or @ref step_32 "step-32", subdomain ids are assigned to cells by + * stores the entire triangulation (as in, for example, step-18 + * or step-32, subdomain ids are assigned to cells by * partitioning a mesh, and each MPI process then only works on those cells it * "owns", i.e. that belong to a subdomain that it is associated with * (traditionally, this is the case for the subdomain id whose numerical value diff --git a/deal.II/doc/doxygen/headers/hp.h b/deal.II/doc/doxygen/headers/hp.h index 2796bbb495..493ad0164e 100644 --- a/deal.II/doc/doxygen/headers/hp.h +++ b/deal.II/doc/doxygen/headers/hp.h @@ -15,7 +15,7 @@ * @defgroup hp hp finite element support * * Classes and functions that have to do with hp finite elements. The - * @ref step_27 "step-27" tutorial program gives an overview of how to + * step-27 tutorial program gives an overview of how to * use the classes in this namespace. * * The hp namespace implements the algorithms and data structures used for diff --git a/deal.II/doc/doxygen/headers/matrices.h b/deal.II/doc/doxygen/headers/matrices.h index ca9f3ae8f5..d6ca6152e6 100644 --- a/deal.II/doc/doxygen/headers/matrices.h +++ b/deal.II/doc/doxygen/headers/matrices.h @@ -123,7 +123,7 @@ * a common strategy is to first build and intermediate sparsity pattern that * uses a less efficient storage scheme during construction of the sparsity * pattern and later copy it directly into the static, compressed form (see, - * for example the @ref step_11 "step-11", @ref step_18 "step-18", and @ref + * for example the step-11, step-18, and @ref * step_27 "step-27" tutorial programs). * * @@ -158,8 +158,8 @@ * up to twice the memory in the worst case) for additional speed which is * noticeable in cases with many nonzero entries. CompressedSetSparsityPattern * on the other hand uses a lot more memory but may perform better in cases with - * many nonzero entries per row. See for example the @ref step_27 "step-27" - * and @ref step_22 "step-22" tutorial programs. + * many nonzero entries per row. See for example the step-27 + * and step-22 tutorial programs. * * As a guideline you should start using CompressedSparsityPattern and try the * other variants if you run into problems. Switching between them should be as @@ -189,7 +189,7 @@ * * These classes inherit the same tradeoffs regarding their efficiency from * their non-block classes (see above). See their documentation and - * @ref step_22 "step-22" for more information. + * step-22 for more information. * * @ingroup Matrices */ diff --git a/deal.II/doc/doxygen/headers/mg.h b/deal.II/doc/doxygen/headers/mg.h index db67d35c5f..071ad2eaa6 100644 --- a/deal.II/doc/doxygen/headers/mg.h +++ b/deal.II/doc/doxygen/headers/mg.h @@ -39,7 +39,7 @@ * Finally, we have several auxiliary classes, namely MGLevelObject, * which stores an object on each level * - * See the @ref step_16 "step-16" example program on how to use this + * See the step-16 example program on how to use this * functionality. */ diff --git a/deal.II/doc/doxygen/headers/software.h b/deal.II/doc/doxygen/headers/software.h index 84e47032d8..47822900b1 100644 --- a/deal.II/doc/doxygen/headers/software.h +++ b/deal.II/doc/doxygen/headers/software.h @@ -117,7 +117,7 @@ * Interfaces to Trilinos exist in the TrilinosWrappers namespace, * making matrices, vectors, and solvers look like the corresponding * deal.II classes. Their use is explained in the @ref step_31 - * "step-31", @ref step_32 "step-32", and @ref step_33 "step-33" + * "step-31", step-32, and step-33 * tutorial programs. The PETSc and Trilinos * ReadMe file explains how to configure deal.II to use this diff --git a/deal.II/doc/doxygen/headers/vector_memory.h b/deal.II/doc/doxygen/headers/vector_memory.h index 8d0021df46..0c65f902b1 100644 --- a/deal.II/doc/doxygen/headers/vector_memory.h +++ b/deal.II/doc/doxygen/headers/vector_memory.h @@ -21,7 +21,7 @@ * vectors. * * Some discussion on this topic can be found in the discussion of the - * InverseMatrix class in @ref step_20 "step-20". + * InverseMatrix class in step-20. * * @ingroup LAC */ diff --git a/deal.II/doc/doxygen/headers/vector_valued.h b/deal.II/doc/doxygen/headers/vector_valued.h index 3df7e70db0..744b069e12 100644 --- a/deal.II/doc/doxygen/headers/vector_valued.h +++ b/deal.II/doc/doxygen/headers/vector_valued.h @@ -20,19 +20,19 @@ * solution variable is not a scalar function, but a vector-valued function or * a set of functions. This includes, for example: *
      - *
    • The elasticity equation discussed in @ref step_8 "step-8", - * @ref step_17 "step-17", and @ref step_18 "step-18" in which the + *
    • The elasticity equation discussed in step-8, + * step-17, and step-18 in which the * solution is the vector-valued displacement at each point. *
    • The mixed Laplace equation and its extensions discussed in - * @ref step_20 "step-20", and @ref step_21 "step-21" in which the + * step-20, and step-21 in which the * solution is the scalar pressure and the vector-valued velocity * at each point. *
    • The Stokes equation and its extensions discussed in - * @ref step_22 "step-22", and @ref step_31 "step-31" in which again + * step-22, and step-31 in which again * the solution is the scalar pressure and the vector-valued velocity * at each point. *
    • Complex-valued solutions consisting of real and imaginary parts, as - * discussed for example in @ref step_29 "step-29". + * discussed for example in step-29. *
    * * This page gives an overview of how to implement such vector-valued problems @@ -60,7 +60,7 @@ * first with a weak (variational) formulation of the problem that takes into * account all the solution variables. To understand how to do that, let us * consider a simple example, the mixed Laplace equations discussed in - * @ref step_20 "step-20": + * step-20: @f{eqnarray*} \textbf{u} + \nabla p &=& 0, \\ @@ -209,7 +209,7 @@ * component. * * As it turns out these (equivalent) choices do not lead to a stable scheme - * for the mixed Laplace equation. In @ref step_20 "step-20", we therefore use + * for the mixed Laplace equation. In step-20, we therefore use * a Raviart-Thomas element for the velocities. What exactly this means may be * of less concern for now except that the FE_RaviartThomas class describes * elements that already have dim components. For the pressure, @@ -248,7 +248,7 @@ * * The next step is to assemble the linear system. How to do this for the * simple case of a scalar problem has been shown in many tutorial programs, - * starting with @ref step_3 "step-3". Here we will show how to do it for + * starting with step-3. Here we will show how to do it for * vector problems. * * How to do this is possibly best explained by showing an example @@ -369,9 +369,9 @@ * divergence $\sum_{d=0}^{dim-1} \frac{\partial\phi_d}{\partial x_d}$. * * Other examples of using extractors and views are shown in tutorial programs - * @ref step_21 "step-21", - * @ref step_22 "step-22", - * @ref step_31 "step-31" and a few other programs. + * step-21, + * step-22, + * step-31 and a few other programs. * * * @anchor VVAlternative @@ -380,7 +380,7 @@ * There are situations in which one can optimize the assembly of a matrix or * right hand side vector a bit, using knowledge of the finite element in * use. Consider, for example, the bilinear form of the elasticity equations - * which we are concerned with first in @ref step_8 "step-8": + * which we are concerned with first in step-8: * @f[ a({\mathbf u}, {\mathbf v}) = @@ -458,7 +458,7 @@ scalar_product (const Tensor<2,dim> &u, } * @endcode * - * Now, this is not the code used in @ref step_8 "step-8". In fact, + * Now, this is not the code used in step-8. In fact, * if one used the above code over the one implemented in that program, * it would run about 8 per cent slower. It can be improved (bringing * down the penalty to about 4 per cent) by taking a close look at the @@ -551,7 +551,7 @@ scalar_product (const Tensor<2,dim> &u, } * @endcode * - * So if, again, this is not the code we use in @ref step_8 "step-8", what do + * So if, again, this is not the code we use in step-8, what do * we do there? The answer rests on the finite element we use. There, we use the * following element: * @code @@ -598,7 +598,7 @@ scalar_product (const Tensor<2,dim> &u, * component is going to be nonzero. This information is provided by the * FiniteElement::system_to_component_index function. What can be done with * it, using the example above, is explained in detail in - * @ref step_8 "step-8". + * step-8. * * * @anchor VVBlockSolvers @@ -609,8 +609,8 @@ scalar_product (const Tensor<2,dim> &u, * vector-valued problem. However, then it also has to be solved. This is more * complicated. Naively, one could just consider the matrix as a whole. For * most problems, this matrix is not going to be definite (except for special - * cases like the elasticity equations covered in @ref step_8 "step-8" and - * @ref step_17 "step-17"). It will, often, also not be symmetric. This rather + * cases like the elasticity equations covered in step-8 and + * step-17). It will, often, also not be symmetric. This rather * general class of matrices presents problems for iterative solvers: the lack * of structural properties prevents the use of most efficient methods and * preconditioners. While it can be done, the solution process will therefore @@ -654,12 +654,12 @@ scalar_product (const Tensor<2,dim> &u, * What is needed is to re-enumerate degrees of freedom so that velocities * come first and pressures last. This can be done using the * DoFRenumbering::component_wise function, as explained in @ref step_20 - * "step-20", @ref step_21 "step-21", @ref step_22 "step-22", and @ref step_31 + * "step-20", step-21, step-22, and @ref step_31 * "step-31". After this, at least the degrees of freedom are partitioned * properly. * * But then we still have to make use of it, i.e. we have to come up with a - * solver that uses the structure. For example, in @ref step_20 "step-20", we + * solver that uses the structure. For example, in step-20, we * do a block elimination of the linear system @f{eqnarray*} \left( @@ -696,7 +696,7 @@ scalar_product (const Tensor<2,dim> &u, * large whole matrix we had before. * * How a solver like this is implemented is explained in more detail in @ref - * step_20 "step-20", @ref step_31 "step-31", and a few other tutorial + * step_20 "step-20", step-31, and a few other tutorial * programs. What we would like to point out here is that we now need a way to * extract certain parts of a matrix or vector: if we are to multiply, say, * the $U$ part of the solution vector by the $M$ part of the global matrix, @@ -716,7 +716,7 @@ scalar_product (const Tensor<2,dim> &u, * * To show how to do this, let us consider the second equation $MU=F-BP$ to be * solved above. This can be achieved using the following sequence similar to - * what we have in @ref step_20 "step-20": + * what we have in step-20: * @code Vector tmp (solution.block(0).size()); system_matrix.block(0,1).vmult (tmp, solution.block(1)); @@ -789,7 +789,7 @@ scalar_product (const Tensor<2,dim> &u, * allocation for the outer vector as well as for all the inner vectors. * Secondly, maybe we are only interested in the velocities, * for example to solve an advection problem in a second stage (as, for - * example, in @ref step_21 "step-21" or @ref step_31 "step-31"). In that + * example, in step-21 or step-31). In that * case, one would have to hand-extract these values like so: * @code for (unsigned int q=0; q \n * $_"; } - # then replace references to other example programs automatically: - s!step-(\d+)!\@ref step_\1 \"step-\1\"!g; - # finally print this line print " * $_\n"; @@ -86,7 +83,7 @@ do { { # in program mode, output the program line. the only thing we need # to do is to avoid $ signs because that confuses doxygen. since - # we don't want formulas rendered in the program text anyway, + # we don't want formulas rendered in the program text anyway, # simply replace them by spaces (it would be nice to suppress their # meaning somehow, but I don't know how...) s/\$//g; diff --git a/deal.II/doc/doxygen/tutorial/program2html b/deal.II/doc/doxygen/tutorial/program2html index f2e9966ef9..f5894dc8ff 100644 --- a/deal.II/doc/doxygen/tutorial/program2html +++ b/deal.II/doc/doxygen/tutorial/program2html @@ -2,7 +2,7 @@ # $Id$ # Version: $Name$ # -# Copyright (C) 2006, 2007 by the deal.II authors +# Copyright (C) 2006, 2007, 2010 by the deal.II authors # # This file is subject to QPL and may not be distributed # without copyright and license information. Please refer @@ -37,7 +37,7 @@ do { s/\t/ /g; if (($state == $program_mode) && m!^\s*//!) - { + { $state = $comment_mode; print "\n"; print "\n"; @@ -46,14 +46,14 @@ do { # if in comment mode and no comment line: toggle state. # don't do so, if only a blank line elsif (($state == $comment_mode) && !m!^\s*//! && !m!^\s*$!) - { + { $state = $program_mode; print "

    \n"; print "\n"; print "
    \n";
         }
    -    
    -    if ($state == $comment_mode) 
    +
    +    if ($state == $comment_mode)
         {
     	# in comment mode: first skip leading whitespace and
     	# comment // signs
    @@ -79,9 +79,6 @@ do {
             # replace double dashes in comments by —
     	s!--!—!g;
     
    -	# then replace references to other example programs automatically:
    -	s!(step-\d+)!\1!g;
    -
     	# finally print this line
     	print $_, "\n";
     
    diff --git a/deal.II/doc/news/6.0.0-vs-6.1.0.h b/deal.II/doc/news/6.0.0-vs-6.1.0.h
    index dabec0e622..d827564b7c 100644
    --- a/deal.II/doc/news/6.0.0-vs-6.1.0.h
    +++ b/deal.II/doc/news/6.0.0-vs-6.1.0.h
    @@ -101,7 +101,7 @@ inconvenience this causes.
     

    General

      -
    1. New: @ref step_33 "step-33", written mainly by David Neckels, +

    2. New: step-33, written mainly by David Neckels, illustrates how the Euler equations of compressible inviscid gas dynamics can be solved. More generally, the program also provides a framework for the solution of arbitrary hyperbolic, nonlinear @@ -110,13 +110,13 @@ inconvenience this causes. (WB, 2008/05/23)

      -
    3. Improved: @ref step_16 "step-16" has been updated to show the +

    4. Improved: step-16 has been updated to show the use of Multigrid with Dirichlet boundary conditions.
      (GK, 2007/05/13)

      -
    5. New: @ref step_22 "step-22", written by Martin Kronbichler and Wolfgang +

    6. New: step-22, written by Martin Kronbichler and Wolfgang Bangerth, shows how to solve, and in particular how to solve efficiently, the Stokes equations that describe viscous incompressible fluid flow. @@ -124,7 +124,7 @@ inconvenience this causes. (WB, 2008/03/28)

      -
    7. New: @ref step_29 "step-29" demonstrates how problems involving +

    8. New: step-29 demonstrates how problems involving complex %numbers can be implemented by viewing real and imaginary parts of a complex-valued solution as the two components of a vector-valued function. @@ -135,7 +135,7 @@ inconvenience this causes.

    9. New: A significantly simpler way to code the assembly of linear systems for problems with more than one solution variable has been implemented. This is explained in detail in the report on @ref vector_valued - and tutorial programs @ref step_20 "step-20" and @ref step_21 "step-21" + and tutorial programs step-20 and step-21 have been converted as well.
      (WB, 2008/02/23) @@ -240,8 +240,8 @@ an integer id of the current thread. only the VTK reader in DataOutBase::write_vtk as well as the deal.II intermediate format writer make use of it.

      - The use of this ability is explained in the @ref step_22 "step-22" and - @ref step_33 "step-33" tutorial programs. + The use of this ability is explained in the step-22 and + step-33 tutorial programs.
      (WB 2007/10/11)

    10. @@ -488,8 +488,8 @@ constraints individually. that may be used to indicate that certain components of the data logically form a vector field. The output formats for which this is presently implemented then indicate this fact in the output file. The - mechanism is shown in action in @ref step_22 "step-22" and - @ref step_33 "step-33". + mechanism is shown in action in step-22 and + step-33.
      (WB 2007/10/14)

      diff --git a/deal.II/doc/news/6.1.0-vs-6.2.0.h b/deal.II/doc/news/6.1.0-vs-6.2.0.h index 8bcfb3aeef..64a215ea3e 100644 --- a/deal.II/doc/news/6.1.0-vs-6.2.0.h +++ b/deal.II/doc/news/6.1.0-vs-6.2.0.h @@ -170,7 +170,7 @@ inconvenience this causes.
      1. - Updated: The @ref step_22 "step-22" tutorial program now uses some + Updated: The step-22 tutorial program now uses some advanced features of the ConstraintMatrix such as imhomogeneities for implementing Dirichlet boundary condition and condensation of constraints on the fly. @@ -200,7 +200,7 @@ inconvenience this causes.

      2. - New: A new tutorial program @ref step_34 "step-34" was added to the + New: A new tutorial program step-34 was added to the library that shows the usage of the new codimension one functionality recently added to the library. In this tutorial we show the use of bondary element methods on piecewise constant functions defined over @@ -248,7 +248,7 @@ inconvenience this causes.

      3. - Updated: The @ref step_33 "step-33" tutorial program now uses the + Updated: The step-33 tutorial program now uses the Trilinos wrapper classes for accessing Trilinos linear algebra routines instead of implementing that by hand. @@ -293,7 +293,7 @@ inconvenience this causes. if you intend two-dimensional triangulations of two-dimensional domains.
        - The new functionality is described in the @ref step_34 "step-34" + The new functionality is described in the step-34 tutorial program.
        (Cataldo Manigrasso, Luca Heltai 2008/12/05) @@ -332,7 +332,7 @@ inconvenience this causes.

      4. - New: A new tutorial program, @ref step_31 "step-31", is contributed by + New: A new tutorial program, step-31, is contributed by Martin Kronbichler and Wolfgang Bangerth and shows the solution of the Boussinesq approximation to thermally driven convection in an incompressible fluid. @@ -343,7 +343,7 @@ inconvenience this causes.

      5. - Updated: In the @ref step_22 "step-22" tutorial program the generation of + Updated: In the step-22 tutorial program the generation of the sparsity pattern using the class BlockCompressedSetSparsityPattern has been replaced by a pattern of the class BlockCompressedSimpleSparsityPattern, which uses far less memory and is slightly faster. @@ -374,7 +374,7 @@ inconvenience this causes.

      6. - Fixed: In the @ref step_23 "step-23" tutorial program the terms corresponding + Fixed: In the step-23 tutorial program the terms corresponding to the external force were computed incorrectly. The error wasn't visible right away since in the program the right hand side is assumed to be zero. This has now been fixed. @@ -385,7 +385,7 @@ inconvenience this causes.

      7. - New: A new tutorial program, @ref step_28 "step-28", is contributed by + New: A new tutorial program, step-28, is contributed by Yaqi Wang. It illustrates the solution of a coupled system of diffusion equations relevant to nuclear reactor physics where we use different meshes for @@ -399,7 +399,7 @@ inconvenience this causes.

        New: Contributed by Tobias Leicht as well as Ralf Hartmann, deal.II now supports anisotropic refinement of meshes. This functionality - is explained in the @ref step_30 "step-30" tutorial program. + is explained in the step-30 tutorial program.
        (Tobias Leicht, RH 2008/07/08)

        @@ -407,7 +407,7 @@ inconvenience this causes.
      8. - Fixed: In the new @ref step_33 "step-33" tutorial program there was + Fixed: In the new step-33 tutorial program there was a place where we incorrectly passed the diameter of a cell, rather than a face, to a function. This is now fixed.
        @@ -417,7 +417,7 @@ inconvenience this causes.

      9. - Fixed: The new @ref step_33 "step-33" tutorial program had a place where + Fixed: The new step-33 tutorial program had a place where we didn't release some memory. This is now fixed.
        (Chih-Che Chueh, WB 2008/06/02) @@ -933,7 +933,7 @@ inconvenience this causes. New: FEValues objects can now directly calculate the Laplacians of solution functions at quadrature points. This is equivalent to the trace of the Hessians, but faster and more convenient in user code. - @ref step_31 "step-31" program has also been updated to use this. + step-31 program has also been updated to use this.
        (Martin Kronbichler 2008/12/15)

        @@ -947,7 +947,7 @@ inconvenience this causes. fe_values[velocities].get_function_values (global_solution, local_velocity_values). See the new section at the end of the @ref vector_valued module for an overview of this facility. The - @ref step_31 "step-31" program has also been updated to use this. + step-31 program has also been updated to use this.
        (WB 2008/12/13)

        diff --git a/deal.II/doc/news/6.2.0-vs-6.2.1.h b/deal.II/doc/news/6.2.0-vs-6.2.1.h index aabd3a6a27..cf2a70ca33 100644 --- a/deal.II/doc/news/6.2.0-vs-6.2.1.h +++ b/deal.II/doc/news/6.2.0-vs-6.2.1.h @@ -17,7 +17,7 @@ deal.II version 6.2.0 and version 6.2.1:
      10. - When running in parallel, the @ref step_18 "step-18" tutorial program + When running in parallel, the step-18 tutorial program produced an error indicating that resetting user pointers was not possible. This is now fixed.

        diff --git a/deal.II/doc/news/changes.h b/deal.II/doc/news/changes.h index 585c84b6c8..b8154b5239 100644 --- a/deal.II/doc/news/changes.h +++ b/deal.II/doc/news/changes.h @@ -101,9 +101,9 @@ inconvenience this causes. support multigrid also for continuous finite elements on adaptively refined meshes (uniformly refined meshes and discontinuous elements have worked for a long time). As part of this process, - @ref step_16 "step-16" has + step-16 has been rewritten and now solves the same problem - @ref step_6 "step-6" solves, just + step-6 solves, just with a multigrid solver.
        (Bärbel Janssen, WB 2010/02/13) @@ -123,7 +123,7 @@ inconvenience this causes.
      11. - New: There is now a new tutorial program, @ref step_35 "step-35", + New: There is now a new tutorial program, step-35, contributed by Abner Salgado-Gonzalez, that implements a solver for the Navier-Stokes equations using a decoupled projection scheme. @@ -160,7 +160,7 @@ inconvenience this causes.

      12. - Fixed: @ref step_31 "step-31" had a bug in the computation of the + Fixed: step-31 had a bug in the computation of the global scaling parameter in the function that evaluates the artificial viscosity: we computed $c(\mathbf{u},T) = @@ -172,7 +172,7 @@ inconvenience this causes. \ |\mathrm{diam}(\Omega)|^{\alpha-2}$. This didn't matter much in this program because $\mathrm{diam}(\Omega)=2^{1/\textrm{dim}}$ and so is close to one. It would matter, however, if the domain had been different, as - it is, for example, in @ref step_32 "step-32". + it is, for example, in step-32.
        (WB 2009/08/19)

        @@ -192,7 +192,7 @@ inconvenience this causes.
      13. - New: There is now a new tutorial program, @ref step_36 "step-36", + New: There is now a new tutorial program, step-36, contributed by Toby D. Young and Wolfgang Bangerth, that demonstrates solving eigenvalue problems.
        diff --git a/deal.II/examples/step-14/doc/intro.dox b/deal.II/examples/step-14/doc/intro.dox index e2c00b33c7..43187115fb 100644 --- a/deal.II/examples/step-14/doc/intro.dox +++ b/deal.II/examples/step-14/doc/intro.dox @@ -177,7 +177,7 @@ turn to the actual implementation.

        The software

        The step-14 example program builds heavily on the techniques already used in -the @ref step_13 "step-13" program. Its implementation of the dual weighted residual error +the step-13 program. Its implementation of the dual weighted residual error estimator explained above is done by deriving a second class, properly called DualSolver, from the Solver base class, and having a class (WeightedResidual) that joins the two again and controls the solution diff --git a/deal.II/examples/step-16/doc/intro.dox b/deal.II/examples/step-16/doc/intro.dox index 5be8845f81..99666726d3 100644 --- a/deal.II/examples/step-16/doc/intro.dox +++ b/deal.II/examples/step-16/doc/intro.dox @@ -12,7 +12,7 @@ multigrid algorithms on adaptively refined meshes. This example shows the basic usage of the multilevel functions in -deal.II. It solves the same problem as used in @ref step_6 "step-6", +deal.II. It solves the same problem as used in step-6, but demonstrating the things one has to provide when using multigrid as a preconditioner. In particular, this requires that we define a hierarchy of levels, provide transfer operators from one level to the @@ -72,7 +72,7 @@ the implementation in deal.II.

        The testcase

        The problem we solve here is exactly the same as in -@ref step_6 "step-6", the only difference being the solver we use +step-6, the only difference being the solver we use here. You may want to look there for a definition of what we solve, right hand side and boundary conditions. Obviously, the program would also work if we changed the geometry and other pieces of data that diff --git a/deal.II/examples/step-16/doc/results.dox b/deal.II/examples/step-16/doc/results.dox index 856035ccdc..521fef3334 100644 --- a/deal.II/examples/step-16/doc/results.dox +++ b/deal.II/examples/step-16/doc/results.dox @@ -1,7 +1,7 @@

        Results

        The output that this program generates is, of course, the same as that -of @ref step_6 "step-6", so you may see there for more results. On the +of step-6, so you may see there for more results. On the other hand, since no tutorial program is a good one unless it has at least one colorful picture, here is, again, the solution: @@ -74,7 +74,7 @@ compare: 5120 94 11 2048018013 -This isn't only fewer iterations than in @ref step_5 "step-5" (each of which +This isn't only fewer iterations than in step-5 (each of which is, however, much more expensive) but more importantly, the number of iterations also grows much more slowly under mesh refinement (again, it would be almost constant if the coefficient was constant rather @@ -86,7 +86,7 @@ for second order problems.

        Possible extensions

        A close inspection of this program's performance shows that it is mostly -dominated by matrix-vector operations. @ref step_37 "step-37" shows one way +dominated by matrix-vector operations. step-37 shows one way how this can be avoided by working with matrix-free methods. Another avenue would be to use algebraic multigrid methods. The @@ -98,4 +98,4 @@ simpler if one could use a black-box preconditioner that uses some sort of multigrid hierarchy for good performance but can figure out level matrices and similar things out by itself. Algebraic multigrid methods do exactly this, and we will use them in -@ref step_31 "step-31" for the solution of a Stokes problem. +step-31 for the solution of a Stokes problem. diff --git a/deal.II/examples/step-17/doc/intro.dox b/deal.II/examples/step-17/doc/intro.dox index 481f56731f..36cf175f38 100644 --- a/deal.II/examples/step-17/doc/intro.dox +++ b/deal.II/examples/step-17/doc/intro.dox @@ -3,7 +3,7 @@ This program does not introduce any new mathematical ideas; in fact, all it -does is to do the exact same computations that @ref step_8 "step-8" +does is to do the exact same computations that step-8 already does, but it does so in a different manner: instead of using deal.II's own linear algebra classes, we build everything on top of classes deal.II provides that wrap around the linear algebra implementation of the main @@ -306,7 +306,7 @@ Both stress update and rotation are implemented in the function

        Parallel graphical output

        -In the @ref step_17 "step-17" example program, the main bottleneck for %parallel computations +In the step-17 example program, the main bottleneck for %parallel computations was that only the first processor generated output for the entire domain. Since generating graphical output is expensive, this did not scale well when large numbers of processors were involved. However, no viable ways around this @@ -357,14 +357,14 @@ job. Here, TTTT.TTTT denotes the time for which this output has been generated, and NNN the number of the MPI process that did this. The next step is to convert this file or these files into whatever -format you like. The program that does this is the @ref step_19 "step-19" tutorial program: +format you like. The program that does this is the step-19 tutorial program: for example, for the first time step, call it through @code ../step-19/step-19 solution-0001.0000.*.d2 solution-0001.0000.gmv @endcode to merge all the intermediate format files into a single file in GMV format. More details on the parameters of this program and what it can do for -you can be found in the documentation of the @ref step_19 "step-19" tutorial program. +you can be found in the documentation of the step-19 tutorial program. @@ -397,7 +397,7 @@ sequence of operations on the present mesh: \varepsilon(\varphi_j(\mathbf{x}_q))], @f] with quadrature points $\mathbf{x}_q$ and weights $w_q$. We have built these - contributions before, in @ref step_8 "step-8" and @ref step_17 "step-17", but in both of these cases we + contributions before, in step-8 and step-17, but in both of these cases we have done so rather clumsily by using knowledge of how the rank-4 tensor $C$ is composed, and considering individual elements of the strain tensors $\varepsilon(\varphi_i),\varepsilon(\varphi_j)$. This is not really @@ -511,7 +511,7 @@ for (unsigned int i=0; i update_quadrature_point_history () [via solve_timestep ()]: Based on the displacement field $\Delta \mathbf{u}^n$ computed before, we update the stress values in all quadrature points @@ -636,7 +636,7 @@ data for the cells it owned on the old mesh, and it may need to know the values of the quadrature point data on other cells if the corresponding cells on the new mesh are assigned to this process after subdividing the new mesh. A global communication of these data elements is therefore necessary, making the -entire process a little more unpleasant. The @ref step_28 "step-28" tutorial +entire process a little more unpleasant. The step-28 tutorial program shows how to work with different meshes at the same time, albeit for a different kind of problem, giving indications on how to approach the problem for time-dependent adaptivity as well. diff --git a/deal.II/examples/step-18/doc/results.dox b/deal.II/examples/step-18/doc/results.dox index 18294e814c..c4e1f4c8a8 100644 --- a/deal.II/examples/step-18/doc/results.dox +++ b/deal.II/examples/step-18/doc/results.dox @@ -105,7 +105,7 @@ examples/step-18> ls -l *.d2 Let us convert these files in deal.II intermediate format to gmv format (this assumes that you have already compiled the -@ref step_19 "step-19" example program): +step-19 example program): @code examples/step-18> ../step-19/step-19 diff --git a/deal.II/examples/step-19/doc/intro.dox b/deal.II/examples/step-19/doc/intro.dox index 9770ba1df4..8ec8880570 100644 --- a/deal.II/examples/step-19/doc/intro.dox +++ b/deal.II/examples/step-19/doc/intro.dox @@ -2,7 +2,7 @@

        Introduction

        -In @ref step_18 "step-18", we saw a need to write +In step-18, we saw a need to write output files in an intermediate format: in a parallel program, it doesn't scale well if all processors participate in computing a result, and then only a single processor generates the graphical output. Rather, each of them should diff --git a/deal.II/examples/step-19/doc/results.dox b/deal.II/examples/step-19/doc/results.dox index 2e77778953..dedc4b17ac 100644 --- a/deal.II/examples/step-19/doc/results.dox +++ b/deal.II/examples/step-19/doc/results.dox @@ -125,7 +125,7 @@ with their default values and documentations. Let us try to run this program on a set of input files generated by a modified -@ref step_18 "step-18" run on 32 nodes of a +step-18 run on 32 nodes of a cluster. The computation was rather big, with more than 350,000 cells and some 1.2M unknowns. That makes for 32 rather big intermediate files that we will try to merge using the present program. Here is @@ -183,7 +183,7 @@ writing, that averages a throughput of 3.8MB per second, not so bad. If visualized, the output looks very much like that shown for -@ref step_18 "step-18". But that's not quite as +step-18. But that's not quite as important for the moment, rather we are interested in showing how to use the parameter file. To this end, remember that if no parameter file is given, or if it is empty, all the default values listed above are used. However, whatever we diff --git a/deal.II/examples/step-20/doc/intro.dox b/deal.II/examples/step-20/doc/intro.dox index a35e1d24f2..f96eae3f87 100644 --- a/deal.II/examples/step-20/doc/intro.dox +++ b/deal.II/examples/step-20/doc/intro.dox @@ -20,7 +20,7 @@ it, this introduction will cover the use of block matrices and vectors, the definition of solvers and preconditioners, and finally the actual test case we are going to solve. -We are going to extend this tutorial program in @ref step_21 "step-21" to +We are going to extend this tutorial program in step-21 to solve not only the mixed Laplace equation, but add another equation that describes the transport of a mixture of two fluids. @@ -117,14 +117,14 @@ functions to accommodate for the fact that the flow velocity is vector-valued. The necessary question then is: how do we do this in a program? Vector-valued elements have already been discussed in previous tutorial -programs, the first time and in detail in @ref step_8 "step-8". The main difference there +programs, the first time and in detail in step-8. The main difference there was that the vector-valued space $V_h$ is uniform in all its components: the $dim$ components of the displacement vector are all equal and from the same function space. What we could therefore do was to build $V_h$ as the outer product of the $dim$ times the usual $Q(1)$ finite element space, and by this make sure that all our shape functions have only a single non-zero vector component. Instead of dealing with vector-valued shape functions, all we did -in @ref step_8 "step-8" was therefore to look at the (scalar) only non-zero component and +in step-8 was therefore to look at the (scalar) only non-zero component and use the fe.system_to_component_index(i).first call to figure out which component this actually is. @@ -146,7 +146,7 @@ learned that we use the FEValues class to determine the values and gradients of shape functions at quadrature points. For example, we would call fe_values.shape_value(i,q_point) to obtain the value of the ith shape function on the quadrature point with number -q_point. Later, in @ref step_8 "step-8" and other tutorial programs, we learned +q_point. Later, in step-8 and other tutorial programs, we learned that this function call also works for vector-valued shape functions (of primitive finite elements), and that it returned the value of the only non-zero component of shape function i at quadrature point @@ -249,7 +249,7 @@ functions, their gradients and divergences only once per outermost loop, and store the result, as this saves us a few otherwise repeated computations (it is possible to save even more repeated operations by calculating all relevant quantities in advance and then only inserting the results in the actual loop, -see @ref step_22 "step-22" for a realization of that approach). +see step-22 for a realization of that approach). The final result then looks like this, working in every space dimension: @code @@ -298,7 +298,7 @@ the bilinear form and right hand side. There is one final term that we have to take care of: the right hand side contained the term $(g,{\mathbf v}\cdot {\mathbf n})_{\partial\Omega}$, constituting the weak enforcement of pressure boundary conditions. We have already seen in -@ref step_7 "step-7" how to deal with face integrals: essentially exactly the same as with +step-7 how to deal with face integrals: essentially exactly the same as with domain integrals, except that we have to use the FEFaceValues class instead of FEValues. To compute the boundary term we then simply have to loop over all boundary faces and integrate there. The mechanism works in @@ -464,7 +464,7 @@ void SchurComplement::vmult (Vector &dst, In this code, the constructor takes a reference to a block sparse matrix for the entire system, and a reference to an object representing the inverse of the mass matrix. It stores these using SmartPointer objects (see -@ref step_7 "step-7"), and additionally allocates two temporary vectors tmp1 and +step-7), and additionally allocates two temporary vectors tmp1 and tmp2 for the vectors labeled $w,y$ in the list above. In the matrix-vector multiplication function, the product $Sv$ is performed in diff --git a/deal.II/examples/step-20/doc/results.dox b/deal.II/examples/step-20/doc/results.dox index 94d37d19e0..e25dcb6cdf 100644 --- a/deal.II/examples/step-20/doc/results.dox +++ b/deal.II/examples/step-20/doc/results.dox @@ -290,4 +290,4 @@ follows: @image html step-20.u-random.png @image html step-20.p-random.png -We will use these permeability fields again in @ref step_21 "step-21". +We will use these permeability fields again in step-21. diff --git a/deal.II/examples/step-21/doc/intro.dox b/deal.II/examples/step-21/doc/intro.dox index 3d5d70a181..936827ea0b 100644 --- a/deal.II/examples/step-21/doc/intro.dox +++ b/deal.II/examples/step-21/doc/intro.dox @@ -11,7 +11,7 @@ program (besides the somewhat strange time-dependence of @ref step_18 "step-18"). The equations covered here are an extension of the material already covered in -@ref step_20 "step-20". In particular, they fall into the class of +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. @@ -72,7 +72,7 @@ is the total mobility. So far, this looks like an ordinary stationary, Poisson-like equation that we can solve right away with the techniques of the first few tutorial programs -(take a look at @ref step_6 "step-6", for example, for something very +(take a look at step-6, for example, for something very similar). However, we have not said anything yet about the saturation, which of course is going to change as the fluids move around. @@ -133,7 +133,7 @@ as well as the time dependent Maxwell equations (here, the algebraic constraint is that the divergence of the electric displacement field equals the charge density, $\textrm{div}\ \mathbf D = \rho$ and that the divergence of the magnetic flux density is zero: $\textrm{div}\ \mathbf -B = 0$); even the quasistatic model of @ref step_18 "step-18" falls into this +B = 0$); even the quasistatic model of step-18 falls into this category. We will see that the different character of the two equations will inform our discretization strategy for the two equations. @@ -153,7 +153,7 @@ This formulation has the additional benefit that we do not have to express the total velocity $\mathbf u$ appearing in the transport equation as a function of the pressure, but can rather take the primary variable for it. Given the saddle point structure of the first two equations and their similarity to the -mixed Laplace formulation we have introduced in @ref step_20 "step-20", it +mixed Laplace formulation we have introduced in step-20, it will come as no surprise that we will use a mixed discretization again. But let's postpone this for a moment. The first business we have with these @@ -256,13 +256,13 @@ The quantities $S_+,\mathbf{u}_+$ then correspond to the values of these variables on the present cell, whereas $S_-,\mathbf{u}_-$ (needed on the inflow part of the boundary of $K$) are quantities taken from the neighboring cell. Some more context on discontinuous element techniques and evaluation of -fluxes can also be found in @ref step_12 "step-12". +fluxes can also be found in step-12.

        Linear solvers

        The linear solvers used in this program are a straightforward extension of the -ones used in @ref step_20 "step-20". Essentially, we simply have to extend +ones used in step-20. Essentially, we simply have to extend everything from two to three solution components. If we use the discrete spaces mentioned above and put shape functions into the bilinear forms, we @@ -328,10 +328,10 @@ have solved for the velocities. The solution scheme then involves the following steps:
        1. Solve for the pressure $p^{n+1}$ using the Schur complement - technique introduced in @ref step_20 "step-20". + technique introduced in step-20.
        2. Solve for the velocity $\mathbf u^{n+1}$ as also discussed in - @ref step_20 "step-20". + step-20.
        3. Compute the term $F_3-\triangle t\; H \mathbf u^{n+1}$, using the just computed velocities. @@ -384,7 +384,7 @@ physical outside this range, and we should not expect the program to do anything useful once we have negative saturations or ones larger than one. Note that we will have similar restrictions on the time step also in @ref -step_23 "step-23" and @ref step_24 "step-24" where we solve the time dependent +step_23 "step-23" and step-24 where we solve the time dependent wave equation, another hyperbolic problem. We will also come back to the issue of time step choice below in the section on possible extensions to this program. @@ -459,7 +459,7 @@ functions introduced at the end of the results section of @ref step_20 "step-20":
        -This approach is similar to the one we have used in @ref step_27 "step-27" +This approach is similar to the one we have used in step-27 for hp refinement and has the great advantage of flexibility: Any error indicator can be used in the anisotropic process, i.e. if you have quite involved a posteriori @@ -470,12 +470,12 @@ the vector-valued jump.

        The problem

        -We solve the linear transport equation presented in @ref step_12 "step-12". The domain is +We solve the linear transport equation presented in step-12. The domain is extended to cover $[-1,1]\times[0,1]$ in 2D, where the flow field $\beta$ describes a counterclockwise quarter circle around the origin in the right half of the domain and is parallel to the x-axis in the left part of the domain. The inflow boundary is again located at $x=1$ and along the positive part of the x-axis, -and the boundary conditions are chosen as in @ref step_12 "step-12". Compared to @ref step_12 "step-12" we +and the boundary conditions are chosen as in step-12. Compared to step-12 we only use the more effective second assembling technique. In order to make comparisons more effective, we decided to keep function names like @p assemble_system2 even if there is only one of these routines in this tutorial diff --git a/deal.II/examples/step-31/doc/intro.dox b/deal.II/examples/step-31/doc/intro.dox index ef205ce010..792ff9cc60 100644 --- a/deal.II/examples/step-31/doc/intro.dox +++ b/deal.II/examples/step-31/doc/intro.dox @@ -46,7 +46,7 @@ the temperature of the fluid. $\varepsilon ({\mathbf u}) = \frac 12 [(\nabla{\mathbf u}) + (\nabla {\mathbf u})^T]$ is the symmetric gradient of the velocity. As can be seen, velocity and pressure solve a Stokes equation describing the motion of an incompressible -fluid, an equation we have previously considered in @ref step_22 "step-22"; we +fluid, an equation we have previously considered in step-22; we will draw extensively on the experience we have gained in that program, in particular with regard to efficient linear Stokes solvers. @@ -55,7 +55,7 @@ fluid, expressed as the product of the density $\rho$, the thermal expansion coefficient $\beta$, the temperature T and the gravity vector g pointing downward. (A derivation of why the right hand side looks like it looks -is given in the introduction of @ref step_32 "step-32".) +is given in the introduction of step-32.) While the first two equations describe how the fluid reacts to temperature differences by moving around, the third equation states how the fluid motion affects the temperature field: it is an advection @@ -148,13 +148,13 @@ use no normal flux conditions.

        Solution approach

        -Like the equations solved in @ref step_21 "step-21", we here have a +Like the equations solved in step-21, we here have a system of differential-algebraic equations (DAE): with respect to the time variable, only the temperature equation is a differential equation whereas the Stokes system for u and p has no time-derivatives and is therefore of the sort of an algebraic constraint that has to hold at each time instant. The main difference -to @ref step_21 "step-21" is that the algebraic constraint there was a +to step-21 is that the algebraic constraint there was a mixed Laplace system of the form @f{eqnarray*} \mathbf u + {\mathbf K}\lambda \nabla p &=& 0, \\ @@ -168,7 +168,7 @@ where now we have a Stokes system where $\nabla \cdot \eta \varepsilon (\cdot)$ is an operator similar to the Laplacian $\Delta$ applied to a vector field. -Given the similarity to what we have done in @ref step_21 "step-21", +Given the similarity to what we have done in step-21, it may not come as a surprise that we choose a similar approach, although we will have to make adjustments for the change in operator in the top-left corner of the differential operator. @@ -177,7 +177,7 @@ in the top-left corner of the differential operator.

        Time stepping

        The structure of the problem as a DAE allows us to use the same strategy as -we have already used in @ref step_21 "step-21", i.e. we use a time lag +we have already used in step-21, i.e. we use a time lag scheme: we first solve the temperature equation (using an extrapolated velocity field), and then insert the new temperature solution into the right hand side of the velocity equation. The way we implement this in our code @@ -195,7 +195,7 @@ time step n-1 as and then the temperature equation with an extrapolated velocity field to time n. -In contrast to @ref step_21 "step-21", we'll use a higher order time +In contrast to step-21, we'll use a higher order time stepping scheme here, namely the
        Backward Differentiation Formula scheme of order 2 (BDF-2 in short) that replaces @@ -297,7 +297,7 @@ the opportunity to use a higher order scheme. Like solving the mixed Laplace equations, solving the Stokes equations requires us to choose particular pairs of finite elements for velocities and pressure variables. Because this has already been discussed in -@ref step_22 "step-22", we only cover this topic briefly: +step-22, we only cover this topic briefly: Here, we use the stable pair $Q_{p+1}^d \times Q_p, p\ge 1$. These are continuous elements, so we can form the weak form of the Stokes equation without @@ -333,7 +333,7 @@ that we implement is @f} This is exactly the same as what we already discussed in -@ref step_22 "step-22" and there is not much more to say about this here. +step-22 and there is not much more to say about this here.

        Stabilization, weak form and space discretization for the temperature equation

        @@ -344,8 +344,8 @@ this equation are equally stable unless we either do something like upwinding, stabilization, or all of this. One way to achieve this is to use discontinuous elements (i.e. the FE_DGQ class that we used, for example, in the discretization of the transport equation in -@ref step_12 "step-12", or in discretizing the pressure in -@ref step_20 "step-20" and @ref step_21 "step-21") and to define a +step-12, or in discretizing the pressure in +step-20 and step-21) and to define a flux at the interface between cells that takes into account upwinding. If we had a pure advection problem this would probably be the simplest way to go. However, here we have some diffusion as well, @@ -654,7 +654,7 @@ temperature field using the just computed velocity field.
        Linear solvers for the Stokes problem
        Solving the linear equations coming from the Stokes system has been -discussed in great detail in @ref step_22 "step-22". In particular, in +discussed in great detail in step-22. In particular, in the results section of that program, we have discussed a number of alternative linear solver strategies that turned out to be more efficient than the original approach. The best alternative @@ -697,7 +697,7 @@ where $\tilde A^{-1},\tilde S^{-1}$ are approximations to the inverse matrices. In particular, it turned out that S is spectrally equivalent to the mass matrix and consequently replacing $\tilde S^{-1}$ by a CG solver applied to the mass matrix on the pressure -space was a good choice. In a small deviation from @ref step_22 "step-22", we +space was a good choice. In a small deviation from step-22, we here have a coefficient $\eta$ in the momentum equation, and by the same derivation as there we should arrive at the conclusion that it is the weighted mass matrix with entries $\tilde S_{ij}=(\eta^{-1}\varphi_i,\varphi_j)$ that @@ -708,7 +708,7 @@ A^{-1}$, which corresponds to the discretized symmetric Laplacian of the vector-valued velocity field, i.e. $A_{ij} = (\varepsilon {\mathbf v}_i, 2\eta \varepsilon ({\mathbf v}_j))$. -In @ref step_22 "step-22" we used a sparse LU decomposition (using the +In step-22 we used a sparse LU decomposition (using the SparseDirectUMFPACK class) of A for $\tilde A^{-1}$ — the perfect preconditioner — in 2d, but for 3d memory and compute time is not usually sufficient to actually compute this decomposition; @@ -783,7 +783,7 @@ almost all the benefits of what we hoped to get. To sum this whole story up, we can observe:
        • Compared to building a preconditioner from the original matrix A - resulting from the symmetric gradient as we did in @ref step_22 "step-22", + resulting from the symmetric gradient as we did in step-22, we have to expect that the preconditioner based on the Laplace bilinear form performs worse since it does not take into account the coupling between vector components. @@ -840,7 +840,7 @@ vector_valued "vector-valued problems" we have always only used a single finite element with several vector components, and a single DoFHandler object. Sometimes, we have substructured the resulting matrix into blocks to facilitate particular solver schemes; this was, for example, the case in the -@ref step_22 "step-22" program for the Stokes equations upon which the current +step-22 program for the Stokes equations upon which the current program is based. We could of course do the same here. The linear system that we would get would @@ -947,7 +947,7 @@ multigrid have been removed.

          Using Trilinos

          In much the same way as we used PETSc to support our linear algebra needs in -@ref step_17 "step-17" and @ref step_18 "step-18", we use interfaces to the Trilinos library (see @ref SoftwareTrilinos) in this program. Trilinos is a very large collection of everything that has to do with linear and nonlinear algebra, as well as all @@ -962,7 +962,7 @@ the latter class, one of the most interesting capabilities is the existence of the Trilinos ML package that implements an Algebraic Multigrid (AMG) method. We will use this preconditioner to precondition the second order operator part of the momentum equation. The ability to solve problems in -%parallel will be explored in @ref step_32 "step-32", using the same problem as +%parallel will be explored in step-32, using the same problem as discussed here. @@ -976,7 +976,7 @@ conductivity and transports heat mainly through convection. On the boundary, we will require no-normal flux for the velocity ($\mathrm{n}\cdot\mathrm{u}=0$) and for the temperature ($\mathrm{n}\cdot\nabla T=0$). This is one of the cases discussed in the -introduction of @ref step_22 "step-22" and fixes one component of the velocity +introduction of step-22 and fixes one component of the velocity while allowing flow to be %parallel to the boundary. There remain dim-1 components to be fixed, namely the tangential components of the normal stress; for these, we choose homogenous conditions which means that diff --git a/deal.II/examples/step-31/doc/results.dox b/deal.II/examples/step-31/doc/results.dox index ea7bbfabc4..5f44a5db92 100644 --- a/deal.II/examples/step-31/doc/results.dox +++ b/deal.II/examples/step-31/doc/results.dox @@ -344,7 +344,7 @@ $c_R=\left(2^{1/d}\right)^{4-2\alpha}=2^{\frac{4-2\alpha}{d}}$. Since this value for $c_R$ appears to work just fine for the current program, we corrected the formula in the program and set $c_R$ to a value that reproduces exactly the results we had before. We will, -however, revisit this issue again in @ref step_32 "step-32". +however, revisit this issue again in step-32. Now, however, back to the discussion of what values of $c_k$ and $\beta$ to choose: @@ -587,7 +587,7 @@ despite the penalty we pay in terms of smaller time steps. There are various ways to extend the current program. Of particular interest is, of course, to make it faster and/or increase the resolution of the -program, in particular in 3d. This is the topic of the @ref step_32 "step-32" +program, in particular in 3d. This is the topic of the step-32 tutorial program which will implement strategies to solve this problem in %parallel on a cluster. diff --git a/deal.II/examples/step-32/doc/intro.dox b/deal.II/examples/step-32/doc/intro.dox index 8a519d0808..1b29e5342e 100644 --- a/deal.II/examples/step-32/doc/intro.dox +++ b/deal.II/examples/step-32/doc/intro.dox @@ -15,16 +15,16 @@ California Institute of Technology.

          Introduction

          -This program does pretty much exactly what @ref step_31 "step-31" already +This program does pretty much exactly what step-31 already does: it solves the Boussinesq equations that describe the motion of a fluid whose temperature is not in equilibrium. As such, all the equations we have -described in @ref step_31 "step-31" still hold: we solve the same partial +described in step-31 still hold: we solve the same partial differential equation, using the same finite element scheme, the same time stepping algorithm, and the same stabilization method for the temperature advection-diffusion equation. As a consequence, you may first want to understand that program before you work on the current one. -The difference between @ref step_31 "step-31" and the current program is that +The difference between step-31 and the current program is that here we want to do things in %parallel, using both the availability of many machines in a cluster (with parallelization based on MPI) as well as many processor cores within a single machine (with parallelization based on @@ -44,7 +44,7 @@ parallelize things, and finally the actual testcase we will consider.

          Using the "right" pressure

          -In @ref step_31 "step-31", we used the following Stokes model for the +In step-31, we used the following Stokes model for the velocity and pressure field: @f{eqnarray*} -\nabla \cdot (2 \eta \varepsilon ({\mathbf u})) + \nabla p &=& @@ -88,7 +88,7 @@ with which the Stokes equations would read: \\ \nabla \cdot {\mathbf u} &=& 0. @f} -This is exactly the form we used in @ref step_31 "step-31", and it was +This is exactly the form we used in step-31, and it was appropriate to do so because all changes in the fluid flow are only driven by the dynamic pressure that results from temperature differences. @@ -138,7 +138,7 @@ Remember that we want to solve the following set of equations: \nabla \cdot \kappa \nabla T &=& \gamma, @f} augmented by appropriate boundary and initial conditions. As discussed -in @ref step_31 "step-31", we will solve this set of equations by +in step-31, we will solve this set of equations by solving for a Stokes problem first in each time step, and then moving the temperature equation forward by one time interval. @@ -188,7 +188,7 @@ $\text{m}^{\text{dim}-1} \sqrt{\left(\text{Pa}\right)^2 + quite obviously, does not make sense, and we should not be surprised that doing so is eventually going to come back hurting us. -So why is this an issue here, but not in @ref step_31 "step-31"? The +So why is this an issue here, but not in step-31? The reason back there is that everything was nicely balanced: velocities were on the order of one, the pressure likewise, the viscosity was one, and the domain had a diameter of $\sqrt{2}$. As a result, while @@ -251,7 +251,7 @@ matrix and preconditioner. We will recover the unscaled pressure in the

          Changes to the Stokes preconditioner

          In this tutorial program, we apply a variant of the preconditioner used in -@ref step_31 "step-31". That preconditioner was built to operate on the +step-31. That preconditioner was built to operate on the system matrix M in block form such that the product matrix @f{eqnarray*} P^{-1} M @@ -300,11 +300,11 @@ possible option for a saddle point system like the Stokes equations. BiCGStab harmonizes nicely with the ILU preconditioner on a pressure mass matrix as approximation for $S^{-1}$, so it is at least as good as GMRES in this example. Keep in mind the discussion in the results -section of the @ref step_22 "step-22" tutorial program, where we observed +section of the step-22 tutorial program, where we observed that BiCGStab does not like inner solves with CG, which made us prefer GMRES in step-31. -As a final note, let us remark that in @ref step_31 "step-31" we computed the +As a final note, let us remark that in step-31 we computed the Schur complement $S=B A^{-1} B^T$ by approximating $-\text{div}(-\eta\Delta)^{-1}\nabla \approx \frac 1{\eta} \mathbf{1}$. Now, however, we have re-scaled the $B$ and $B^T$ operators. So $S$ should now @@ -317,7 +317,7 @@ This is exactly the operator we use to approximate $S$.

          Changes to the artificial viscosity stabilization

          -As in @ref step_31 "step-31", we will use an artificial viscosity of +As in step-31, we will use an artificial viscosity of the form @f{eqnarray*} \nu_\alpha(T)|_K @@ -334,7 +334,7 @@ in this problem, where $c(\mathbf{u},T) = c_R\ \|\mathbf{u}\|_{L^\infty(\Omega)} \ \mathrm{var}(T) \ |\mathrm{diam}(\Omega)|^{\alpha-2}$ (for the meaning of the various -terms in these formulas, see @ref step_31 "step-31". In the results +terms in these formulas, see step-31. In the results section of that program, we have discussed our choice for $c_R$ and how we arrived at the value used there mostly by accident, and in more detail how $\beta$ was chosen. For the @@ -406,7 +406,7 @@ Consequently, $c_R=0.1$ would appear to be the right value. Parallelization of scientific codes across multiple machines in a cluster of computers is almost always done using the Message Passing Interface (MPI). This program is no exception to that, and it follows the -@ref step_17 "step-17" and @ref step_18 "step-18" programs in this. +step-17 and step-18 programs in this. MPI is a rather awkward interface to program with, and so we usually try to not use it directly but through an interface layer that abstracts most of the @@ -422,7 +422,7 @@ interfaces to Trilinos, a library similar to PETSc in its aims and with a lot of the same functionality. It is, however, a project that is several years younger, is written in C++ and by people who generally have put a significant emphasis on software design. We have already used Trilinos in -@ref step_31 "step-31", and will do so again here, with the difference that we +step-31, and will do so again here, with the difference that we will use its %parallel capabilities. deal.II's Trilinos interfaces encapsulate pretty much everything Trilinos @@ -636,7 +636,7 @@ point and is, in fact, deallocated again immediately.

          The testcase

          The setup for this program is mildly reminiscent of the problem we wanted to -solve in the first place (see the introduction of @ref step_31 "step-31"): +solve in the first place (see the introduction of step-31): convection in the earth mantle. As a consequence, we choose the following data, all of which appears in the program in units of meters and seconds (the SI system) even if we list them here in other units. diff --git a/deal.II/examples/step-32/doc/results.dox b/deal.II/examples/step-32/doc/results.dox index a3d308bc65..53536d0df8 100644 --- a/deal.II/examples/step-32/doc/results.dox +++ b/deal.II/examples/step-32/doc/results.dox @@ -1,7 +1,7 @@

          Results

          When run, the program simulates convection in 3d in much the same way -as @ref step_31 "step-31" did, though with an entirely different testcase. +as step-31 did, though with an entirely different testcase.

          Comparison of results with step-31

          @@ -295,7 +295,7 @@ quite within the physically expected region.

          Possibilities for extensions

          Apart from the various possibilities for extensions already outlined -in the @ref step_31 "step-31", here are a few more ideas: +in the step-31, here are a few more ideas:
          • The temperature field we get in our simulations after a while diff --git a/deal.II/examples/step-33/doc/intro.dox b/deal.II/examples/step-33/doc/intro.dox index 1ac9e1084c..5f56cad9ff 100644 --- a/deal.II/examples/step-33/doc/intro.dox +++ b/deal.II/examples/step-33/doc/intro.dox @@ -98,7 +98,7 @@ deal.II can be found in the @ref vector_valued module. Discretization happens in the usual way, taking into account that this is a hyperbolic problem in the same style as the simple one discussed -in @ref step_12 "step-12": +in step-12: We choose a finite element space $V_h$, and integrate our conservation law against our (vector-valued) test function $\mathbf{z} \in V_h$. We then integrate by parts and approximate the boundary flux with a numerical flux $\mathbf{H}$, diff --git a/deal.II/examples/step-34/doc/intro.dox b/deal.II/examples/step-34/doc/intro.dox index d09e079ec3..4d4812dd1b 100644 --- a/deal.II/examples/step-34/doc/intro.dox +++ b/deal.II/examples/step-34/doc/intro.dox @@ -39,7 +39,7 @@ The above equations can be derived from Navier-Stokes equations assuming that the effects due to viscosity are negligible compared to those due to the pressure gradient, inertial forces and the external forces. This is the opposite case of the Stokes equations discussed in -@ref step_22 "step-22" which are the limit case of dominant viscosity, +step-22 which are the limit case of dominant viscosity, i.e. where the velocity is so small that inertia forces can be neglected. On the other hand, owing to the assumed incompressibility, the equations are not suited for very high speed gas flows where diff --git a/deal.II/examples/step-35/doc/intro.dox b/deal.II/examples/step-35/doc/intro.dox index 8161f74b44..c85b26da4a 100644 --- a/deal.II/examples/step-35/doc/intro.dox +++ b/deal.II/examples/step-35/doc/intro.dox @@ -38,8 +38,8 @@ and where $n$ is the outer unit normal. The boundary conditions on $\Gamma_2$ are often used to model outflow conditions. -In previous tutorial programs (see for instance @ref step_20 "step-20" and -@ref step_22 "step-22") we have seen +In previous tutorial programs (see for instance step-20 and +step-22) we have seen how to solve the time-independent Stokes equations using a Schur complement approach. For the time-dependent case, after time discretization, we would arrive at a system like @f{align*} diff --git a/deal.II/examples/step-36/doc/intro.dox b/deal.II/examples/step-36/doc/intro.dox index 5394c8e9cc..6f7eb8fc6b 100644 --- a/deal.II/examples/step-36/doc/intro.dox +++ b/deal.II/examples/step-36/doc/intro.dox @@ -96,7 +96,7 @@ pairs.

            Implementation details

            The program below is essentially just a slightly modified version of -@ref step_4 "step-4". The things that are different are the following: +step-4. The things that are different are the following:
              @@ -104,8 +104,8 @@ The program below is essentially just a slightly modified version of longer has a single solution vector, but a whole set of vectors for the various eigenfunctions we want to compute. -
            • We use PETSc matrices and vectors as in @ref step_17 "step-17" and -@ref step_18 "step-18" since that is what the SLEPc eigenvalue solvers +
            • We use PETSc matrices and vectors as in step-17 and +step-18 since that is what the SLEPc eigenvalue solvers require.
            • The function EigenvalueProblem::solve is entirely @@ -121,7 +121,7 @@ or the number of eigenvalues we want to solve for. We could go much further with this but stop at making only a few of the things that one could select at run time actual input file parameters. In order to see what could be done in this regard, take a look at @ref step_29 -"step-29", @ref step_33 "step-33", and in particular @ref step_19 +"step-29", step-33, and in particular @ref step_19 "step-19".
            • We use the FunctionParser class to make the potential $V(\mathbf @@ -131,4 +131,4 @@ formula.
            The rest of the program follows in a pretty straightforward way from -@ref step_4 "step-4". +step-4. diff --git a/deal.II/examples/step-36/doc/results.dox b/deal.II/examples/step-36/doc/results.dox index ccbae7a787..765ca4ebcd 100644 --- a/deal.II/examples/step-36/doc/results.dox +++ b/deal.II/examples/step-36/doc/results.dox @@ -176,8 +176,8 @@ Some visualization programs can compute derived quantities from the data in an input file, but we can also do so right away when creating the output file. The facility to do that is the DataPostprocessor class that can be used in conjunction with the DataOut class. Examples of how this -can be done can be found in @ref step_29 "step-29" and -@ref step_33 "step-33". +can be done can be found in step-29 and +step-33.
          • What happens if the particle in the box has %internal degrees of freedom? For example, if the particle were a spin-$1/2$ particle? In diff --git a/deal.II/examples/step-37/doc/intro.dox b/deal.II/examples/step-37/doc/intro.dox index 5e4eb4ef7b..e7d043e10f 100644 --- a/deal.II/examples/step-37/doc/intro.dox +++ b/deal.II/examples/step-37/doc/intro.dox @@ -512,7 +512,7 @@ be parallelized by working on diagonal sub-blocks of the matrix, which decreases efficiency. The implementation into the multigrid framework is then straightforward. We -will only need some minor modifications compared to @ref step_16 "step-16". +will only need some minor modifications compared to step-16.

            The test case

            diff --git a/deal.II/examples/step-37/doc/results.dox b/deal.II/examples/step-37/doc/results.dox index 9fbc96da2b..6e00f0b1a1 100644 --- a/deal.II/examples/step-37/doc/results.dox +++ b/deal.II/examples/step-37/doc/results.dox @@ -2,7 +2,7 @@

            Program output

            -Since this example solves the same problem as @ref step_5 "step-5" (except for +Since this example solves the same problem as step-5 (except for a different coefficient), we refer to the graphical output there. Here, we evaluate some aspects of the multigrid solver. diff --git a/deal.II/examples/step-38/doc/intro.dox b/deal.II/examples/step-38/doc/intro.dox index e845fcfcc8..fdc0289c75 100644 --- a/deal.II/examples/step-38/doc/intro.dox +++ b/deal.II/examples/step-38/doc/intro.dox @@ -42,7 +42,7 @@ function, $g$ a boundary value function, the inflow part of the boundary of the domain and ${\bf n}$ denotes the unit outward normal to the boundary $\Gamma$. This equation is the conservative version of the advection equation already considered in -@ref step_9 "step-9" of this tutorial. +step-9 of this tutorial. In particular, we solve the advection equation on $\Omega=[0,1]^2$ with ${\mathbf \beta}=\frac{1}{|x|}(-x_2, x_1)$ representing a circular counterclockwise flow field, and $g=1$ diff --git a/deal.II/examples/step-6/doc/results.dox b/deal.II/examples/step-6/doc/results.dox index e6356b520c..64a04e2b40 100644 --- a/deal.II/examples/step-6/doc/results.dox +++ b/deal.II/examples/step-6/doc/results.dox @@ -204,7 +204,7 @@ Using these various different preconditioners, we can compare the number of CG iterations needed (available through the solver_control.last_step() call, see @ref step_4 "step-4") as well as CPU time needed (using the Timer class, -discussed, for example, in @ref step_12 "step-12") and get the +discussed, for example, in step-12) and get the following results (left: iterations; right: CPU time): @@ -251,8 +251,8 @@ operations it has to perform. The message to take away from this is not that simplicity in preconditioners is always best. While this may be true for the current problem, it definitely is not once we move to more complicated -problems (elasticity or Stokes, for examples @ref step_8 "step-8" or -@ref step_22 "step-22"). Secondly, all of these preconditioners still +problems (elasticity or Stokes, for examples step-8 or +step-22). Secondly, all of these preconditioners still lead to an increase in the number of iterations as the number $N$ of degrees of freedom grows, for example ${\cal O}(N^\alpha)$; this, in turn, leads to a total growth in effort as ${\cal O}(N^{1+\alpha})$ @@ -260,7 +260,7 @@ since each iteration takes ${\cal O}(N)$ work. This behavior is undesirable, we would really like to solve linear systems with $N$ unknowns in a total of ${\cal O}(N)$ work; there is a class of preconditioners that can achieve this, namely geometric (@ref -step_16 "step-16") or algebraic (@ref step_31 "step-31") multigrid +step_16 "step-16") or algebraic (step-31) multigrid preconditioners. They are, however, significantly more complex than the preconditioners outlined above. Finally, the last message to take home is that today (in 2008), linear systems with 100,000 unknowns are diff --git a/deal.II/examples/step-8/doc/intro.dox b/deal.II/examples/step-8/doc/intro.dox index cc8be6ae06..87d8a0c0cf 100644 --- a/deal.II/examples/step-8/doc/intro.dox +++ b/deal.II/examples/step-8/doc/intro.dox @@ -322,11 +322,11 @@ Likewise, the contribution of cell $K$ to the right hand side vector is This is the form in which we will implement the local stiffness matrix and right hand side vectors. -As a final note: in the @ref step_17 "step-17" example program, we will +As a final note: in the step-17 example program, we will revisit the elastic problem laid out here, and will show how to solve it in %parallel on a cluster of computers. The resulting program will thus be able to solve this problem to significantly higher accuracy, and more efficiently if -this is required. In addition, in @ref step_20 "step-20", @ref step_21 +this is required. In addition, in step-20, @ref step_21 "step-21", as well as a few other of the later tutorial programs, we will revisit some vector-valued problems and show a few techniques that may make it simpler to actually go through all the stuff shown above, with diff --git a/deal.II/examples/step-8/doc/results.dox b/deal.II/examples/step-8/doc/results.dox index 7e0e06e31e..5052393a21 100644 --- a/deal.II/examples/step-8/doc/results.dox +++ b/deal.II/examples/step-8/doc/results.dox @@ -18,7 +18,7 @@ two solution components, $x$-displacement and $y$-displacement, are in fact not two independent scalar fields, but the components of a vector field. Depending on what graphical file format we use, we could as well have specified this in the program already and then written into -the output file. The @ref step_22 "step-22" shows how to do this in +the output file. The step-22 shows how to do this in the output_results() function. The next image shows the final grid after eight steps of refinement: diff --git a/deal.II/lac/include/lac/block_sparsity_pattern.h b/deal.II/lac/include/lac/block_sparsity_pattern.h index ba0b48e7c7..d6fc3eb329 100644 --- a/deal.II/lac/include/lac/block_sparsity_pattern.h +++ b/deal.II/lac/include/lac/block_sparsity_pattern.h @@ -861,7 +861,7 @@ class BlockCompressedSetSparsityPattern : public BlockSparsityPatternBase class SparseMatrix; * module. * * This class is an example of the "dynamic" type of @ref Sparsity. It - * is discussed in the @ref step_27 "step-27" and @ref step_22 + * is discussed in the step-27 and @ref step_22 * "step-22" tutorial programs. * *

            Interface

            @@ -76,9 +76,9 @@ template class SparseMatrix; * sp.copy_from (compressed_pattern); * @endverbatim * - * See also @ref step_11 "step-11" and @ref step_18 "step-18" for usage + * See also step-11 and step-18 for usage * patterns of the related CompressedSparsityPattern class, and - * @ref step_27 "step-27" of the current class. + * step-27 of the current class. * *

            Notes

            * @@ -91,7 +91,7 @@ template class SparseMatrix; * container is used. This solution might not be the fastest in all * situations, but seems to work much better than the * CompressedSparsityPattern in the context of hp-adaptivity (see for - * example @ref step_27 "step-27"), or generally when there are many + * example step-27), or generally when there are many * nonzero entries in each row of a matrix (see @ref step_22 * "step-22"). On the other hand, a benchmark where nonzero entries * were randomly inserted into the sparsity pattern revealed that this diff --git a/deal.II/lac/include/lac/compressed_sparsity_pattern.h b/deal.II/lac/include/lac/compressed_sparsity_pattern.h index d910a8352f..28b3664ae8 100644 --- a/deal.II/lac/include/lac/compressed_sparsity_pattern.h +++ b/deal.II/lac/include/lac/compressed_sparsity_pattern.h @@ -76,7 +76,7 @@ template class SparseMatrix; * sp.copy_from (compressed_pattern); * @endverbatim * - * See also @ref step_11 "step-11" and @ref step_18 "step-18" for usage + * See also step-11 and step-18 for usage * patterns. * *

            Notes

            @@ -382,7 +382,7 @@ class CompressedSparsityPattern : public Subscriptor * CompressedSetSparsityPattern class, as * this turned out to be more efficient * for hp finite element programs such as - * @ref step_27 "step-27"). Using the + * step-27). Using the * present scheme, we only need to * allocate memory once for every 8 added * entries, and we waste a lot less diff --git a/deal.II/lac/include/lac/constraint_matrix.h b/deal.II/lac/include/lac/constraint_matrix.h index 26ad0c8d03..c4c21c4727 100644 --- a/deal.II/lac/include/lac/constraint_matrix.h +++ b/deal.II/lac/include/lac/constraint_matrix.h @@ -85,7 +85,7 @@ namespace internals * constraints occur as hanging nodes even if all used finite elements are * identical. While they are most frequent for hanging nodes, constraints of * the given form appear also in other contexts, see for example the - * application the @ref step_11 "step-11" tutorial program. + * application the step-11 tutorial program. * * Homogenous constraints of this form also arise in the context of vector-valued * fields, for example if one wants to enforce boundary conditions of the form @@ -113,7 +113,7 @@ namespace internals * the constraint. This is exactly the form we need for hanging node * constraints, where we need to constrain one degree of freedom in terms of * others. There are other conditions of this form possible, for example for - * implementing mean value conditions as is done in the @ref step_11 "step-11" + * implementing mean value conditions as is done in the step-11 * tutorial program. The name of the class stems from the fact that these * constraints can be represented in matrix form as $X x = b$, and this object * then describes the matrix $X$ (as well as, incidentally, the vector $b$ -- @@ -121,7 +121,7 @@ namespace internals * constraints where $b=0$, thus the name). The most frequent way to * create/fill objects of this type is using the * DoFTools::make_hanging_node_constraints() function. The use of these - * objects is first explained in @ref step_6 "step-6". + * objects is first explained in step-6. * * Matrices of the present type are organized in lines (rows), but only those * lines are stored where constraints are present. New constraints are added @@ -265,7 +265,7 @@ namespace internals * before). * * The use of ConstraintMatrix for implementing Dirichlet boundary conditions - * is discussed in the @ref step_22 "step-22" tutorial program. + * is discussed in the step-22 tutorial program. * * *

            Avoiding explicit condensation

            @@ -281,7 +281,7 @@ namespace internals * is typically the case for 3d, or high polynomial degree computations, as * well as for hp finite element methods, see for example the @ref hp_paper * "hp paper". This is the case discussed in the hp tutorial program, @ref - * step_27 "step-27", as well as in @ref step_22 "step-22" and @ref step_31 + * step_27 "step-27", as well as in step-22 and @ref step_31 * "step-31". * *
          • @@ -289,8 +289,8 @@ namespace internals * is, for example, the case for the PETSc and Trilinos wrapper classes, * where we have no access to the underlying representation of the matrix, * and therefore cannot efficiently implement the condense() - * operation). This is the case discussed in @ref step_17 "step-17", @ref - * step_18 "step-18", @ref step_31 "step-31", and @ref step_32 "step-32". + * operation). This is the case discussed in step-17, @ref + * step_18 "step-18", step-31, and step-32. * * * In this case, one possibility is to distribute local entries to the final @@ -1340,7 +1340,7 @@ class ConstraintMatrix : public Subscriptor * * As explained in the * @ref hp_paper "hp paper" - * and in @ref step_27 "step-27", + * and in step-27, * first allocating a sparsity pattern * and later coming back and allocating * additional entries for those matrix diff --git a/deal.II/lac/include/lac/precondition.h b/deal.II/lac/include/lac/precondition.h index 5672c547a6..42c942ab80 100644 --- a/deal.II/lac/include/lac/precondition.h +++ b/deal.II/lac/include/lac/precondition.h @@ -44,7 +44,7 @@ template class SparseMatrix; PreconditionIdentity()); @endverbatim * - * See the @ref step_3 "step-3" tutorial program for an example and + * See the step-3 tutorial program for an example and * additional explanations. * * Alternatively, the IdentityMatrix class can be used to precondition diff --git a/deal.II/lac/include/lac/slepc_solver.h b/deal.II/lac/include/lac/slepc_solver.h index fc9f847f7f..95457f2f75 100644 --- a/deal.II/lac/include/lac/slepc_solver.h +++ b/deal.II/lac/include/lac/slepc_solver.h @@ -52,7 +52,7 @@ DEAL_II_NAMESPACE_OPEN * for the generalized eigenvalue problem $Ax=B\lambda x$, where the * variable const unsigned int size_of_spectrum tells * SLEPc the number of eigenvector/eigenvalue pairs to solve for: See - * also @ref step_36 "step-36" for a hands-on example. + * also step-36 for a hands-on example. * * An alternative implementation to the one above is to use the API * internals directly within the application code. In this way the diff --git a/deal.II/lac/include/lac/trilinos_precondition.h b/deal.II/lac/include/lac/trilinos_precondition.h index 8e6df15845..5790267d60 100644 --- a/deal.II/lac/include/lac/trilinos_precondition.h +++ b/deal.II/lac/include/lac/trilinos_precondition.h @@ -1262,7 +1262,7 @@ namespace TrilinosWrappers * preconditioner to be based on. A call of the respective * vmult function does call the respective operation in the * Trilinos package, where it is called ApplyInverse. Use of - * this class is explained in the @ref step_31 "step-31" tutorial program. + * this class is explained in the step-31 tutorial program. * * Since the Trilinos objects we want to use are heavily dependent on Epetra * objects, we recommend using this class in conjunction with Trilinos