From: bangerth Date: Fri, 15 Feb 2013 14:19:01 +0000 (+0000) Subject: Patch by Felix Gruber: Consistently use @code...@endcode. X-Git-Url: https://gitweb.dealii.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=10eecd0fb77cf024f214cdaf26417188bbe83b24;p=dealii-svn.git Patch by Felix Gruber: Consistently use @code...@endcode. git-svn-id: https://svn.dealii.org/trunk@28405 0785d39b-7218-0410-832d-ea1e28bc413d --- diff --git a/deal.II/doc/news/changes.h b/deal.II/doc/news/changes.h index f863bdf26b..d61fc7ebc0 100644 --- a/deal.II/doc/news/changes.h +++ b/deal.II/doc/news/changes.h @@ -153,6 +153,13 @@ never working correctly and it is not used.
    +
  1. Fixed: Many places in the documentation have been made to consistently +use doxygen markup that indicates that this is code, so that doxygen will +cross-link the piece of code to class and function names. Many typos have also +been fixed. +
    +(Felix Gruber, 2013/02/15) +
  2. Fixed: Starting in release 7.1, we first built the deal.II shared libraries in the local /tmp or similar directory rather than the final location because linking becomes very slow over remotely mounted file systems. Unfortunately, diff --git a/deal.II/include/deal.II/base/function_parser.h b/deal.II/include/deal.II/base/function_parser.h index 6e0654f798..7002002685 100644 --- a/deal.II/include/deal.II/base/function_parser.h +++ b/deal.II/include/deal.II/base/function_parser.h @@ -52,7 +52,7 @@ template class Vector; * function parser (see the ReadMe file of deal.II on instructions for this). * * The following example shows how to use this class: - * @verbatim + * @code // Define some constants that will be used by the function parser std::map constants; constants["pi"] = numbers::PI; @@ -73,11 +73,11 @@ template class Vector; vector_function.initialize(variables, expressions, constants); - @endverbatim + @endcode * FunctionParser also provides an option to use units in expressions. * We illustrate the use of this functionality with the following example: - * @verbatim + * @code // Define some constants that will be used by the function parser std::map constants; std::map units; @@ -110,7 +110,7 @@ template class Vector; " @point " << "[" << point << "]" << " is " << "[" << vector_function.value(point) << "]" << std::endl; - * @endverbatim + * @endcode * * Units are similar to constants in the way they are passed to the * parser, i.e. via std::map. But units are slightly different @@ -259,7 +259,7 @@ template class Vector; * strings each defining one vector component. * * An example of time dependent scalar function is the following: - @verbatim + @code // Empty constants object std::map constants; @@ -282,11 +282,11 @@ template class Vector; // and there is another variable // to be taken into account (t). - @endverbatim + @endcode * The following is another example of how to instantiate a * vector valued function by using a single string: - @verbatim + @code // Empty constants object std::map constants; @@ -305,7 +305,7 @@ template class Vector; expression, constants); - @endverbatim + @endcode * * * @ingroup functions diff --git a/deal.II/include/deal.II/base/template_constraints.h b/deal.II/include/deal.II/base/template_constraints.h index 19deafc271..368251b61e 100644 --- a/deal.II/include/deal.II/base/template_constraints.h +++ b/deal.II/include/deal.II/base/template_constraints.h @@ -32,12 +32,12 @@ template struct constraint_and_return_value; * is only considered in a call, if all parts of its signature can be * instantiated with the template parameter replaced by the respective * types/values in this particular call. Example: - * @verbatim + * @code * template * typename T::type foo(T) {...}; * ... * foo(1); - * @endverbatim + * @endcode * The compiler should detect that in this call, the template * parameter T must be identified with the type "int". However, * the return type T::type does not exist. The trick now is @@ -47,27 +47,27 @@ template struct constraint_and_return_value; * * The idea is then to make the return type un-instantiatable if * certain constraints on the template types are not satisfied: - * @verbatim + * @code * template struct constraint_and_return_value; * template struct constraint_and_return_value { * typedef T type; * }; - * @endverbatim + * @endcode * constraint_and_return_value is not defined. Given something like - * @verbatim + * @code * template * struct int_or_double { static const bool value = false;}; * template <> * struct int_or_double { static const bool value = true; }; * template <> * struct int_or_double { static const bool value = true; }; - * @endverbatim + * @endcode * we can write a template - * @verbatim + * @code * template * typename constraint_and_return_value::value,void>::type * f (T); - * @endverbatim + * @endcode * which can only be instantiated if T=int or T=double. A call to * f('c') will just fail with a compiler error: "no instance of * f(char) found". On the other hand, if the predicate in the first @@ -191,7 +191,7 @@ namespace internal * A type that is sometimes used for template tricks. For example, in * some situations one would like to do this: * - * @verbatim + * @code * template * class X { * // do something on subdim-dimensional sub-objects of the big @@ -207,13 +207,13 @@ namespace internal * template void f(X &x) { * x.f (); * } - * @endverbatim + * @endcode * * The problem is: the language doesn't allow us to specialize * X::f() without specializing the outer class first. One * of the common tricks is therefore to use something like this: * - * @verbatim + * @code * template struct int2type {}; * * template @@ -236,7 +236,7 @@ namespace internal * template void f(X &x) { * x.f (int2type()); * } - * @endverbatim + * @endcode * * Note that we have replaced specialization of X::f() by * overloading, but that from inside the function g(), we diff --git a/deal.II/include/deal.II/distributed/solution_transfer.h b/deal.II/include/deal.II/distributed/solution_transfer.h index 8c444d7b06..55b0c930f7 100644 --- a/deal.II/include/deal.II/distributed/solution_transfer.h +++ b/deal.II/include/deal.II/distributed/solution_transfer.h @@ -48,7 +48,7 @@ namespace parallel *

    Transfering a solution

    * Here VECTOR is your favorite vector type, e.g. PETScWrappers::MPI::Vector, * TrilinosWrappers::MPI::Vector, or corresponding blockvectors. - * @verbatim + * @code SolutionTransfer soltrans(dof_handler); // flag some cells for refinement // and coarsening, e.g. @@ -69,7 +69,7 @@ namespace parallel VECTOR interpolated_solution; //create VECTOR in the right size here soltrans.interpolate(interpolated_solution); - @endverbatim + @endcode * *

    Use for Serialization

    * @@ -77,21 +77,21 @@ namespace parallel * to a file. If you use more than one DoFHandler and therefore more than one SolutionTransfer object, they need to be serialized and deserialized in the same order. * * If vector has the locally relevant DoFs, serialization works as follows: - *@verbatim + *@code parallel::distributed::SolutionTransfer sol_trans(dof_handler); sol_trans.prepare_serialization (vector); triangulation.save(filename); - @endverbatim + @endcode * For deserialization the vector needs to be a distributed vector (without ghost elements): - * @verbatim + * @code //[create coarse mesh...] triangulation.load(filename); parallel::distributed::SolutionTransfer sol_trans(dof_handler); sol_trans.deserialize (distributed_vector); - @endverbatim + @endcode * * @ingroup distributed * @author Timo Heister, 2009-2011 diff --git a/deal.II/include/deal.II/fe/fe.h b/deal.II/include/deal.II/fe/fe.h index 0e8633a755..3059dbcc02 100644 --- a/deal.II/include/deal.II/fe/fe.h +++ b/deal.II/include/deal.II/fe/fe.h @@ -438,10 +438,10 @@ public: * version hp::DoFHandler, since * one can then write code like * this: - * @verbatim + * @code * dofs_per_cell * = dof_handler->get_fe()[cell->active_fe_index()].dofs_per_cell; - * @endverbatim + * @endcode * * This code doesn't work in both * situations without the present diff --git a/deal.II/include/deal.II/fe/fe_poly_tensor.h b/deal.II/include/deal.II/fe/fe_poly_tensor.h index 4a8c3c235f..2a8c4e3afc 100644 --- a/deal.II/include/deal.II/fe/fe_poly_tensor.h +++ b/deal.II/include/deal.II/fe/fe_poly_tensor.h @@ -70,7 +70,7 @@ DEAL_II_NAMESPACE_OPEN * Therefore, the constructor of a derived class should have a * structure like this (example for interpolation in support points): * - * @verbatim + * @code * fill_support_points(); * * const unsigned int n_dofs = this->dofs_per_cell; @@ -88,7 +88,7 @@ DEAL_II_NAMESPACE_OPEN * * this->inverse_node_matrix.reinit(n_dofs, n_dofs); * this->inverse_node_matrix.invert(N); - * @endverbatim + * @endcode * * @note The matrix #inverse_node_matrix should have dimensions zero * before this piece of code is executed. Only then, @@ -102,9 +102,9 @@ DEAL_II_NAMESPACE_OPEN * transformations can be selected from the set MappingType and stored * in #mapping_type. Therefore, each constructor should contain a line * like: - * @verbatim + * @code * this->mapping_type = this->mapping_none; - * @endverbatim + * @endcode * * @see PolynomialsBDM, PolynomialsRaviartThomas * @ingroup febase diff --git a/deal.II/include/deal.II/fe/mapping_q1_eulerian.h b/deal.II/include/deal.II/fe/mapping_q1_eulerian.h index 661abf6d2b..8db4e8bd2e 100644 --- a/deal.II/include/deal.II/fe/mapping_q1_eulerian.h +++ b/deal.II/include/deal.II/fe/mapping_q1_eulerian.h @@ -57,13 +57,13 @@ DEAL_II_NAMESPACE_OPEN * to it. * * An example is shown below: - * @verbatim + * @code * FESystem fe(FE_Q(1), dim); * DoFHandler flowfield_dof_handler(triangulation); * flowfield_dof_handler.distribute_dofs(fe); * Vector map_points(flowfield_dof_handler.n_dofs()); * MappingQ1Eulerian mymapping(map_points, flowfield_dof_handler); - * @endverbatim + * @endcode * * Note that since the vector of shift values and the dof handler are * only associated to this object at construction time, you have to diff --git a/deal.II/include/deal.II/fe/mapping_q_eulerian.h b/deal.II/include/deal.II/fe/mapping_q_eulerian.h index e887c0c5e3..d2547ff956 100644 --- a/deal.II/include/deal.II/fe/mapping_q_eulerian.h +++ b/deal.II/include/deal.II/fe/mapping_q_eulerian.h @@ -56,13 +56,13 @@ DEAL_II_NAMESPACE_OPEN * Typically, the DoFHandler operates on a finite element that * is constructed as a system element (FESystem) from continuous FE_Q() * objects. An example is shown below: - * @verbatim + * @code * FESystem fe(FE_Q(2), dim, FE_Q(1), 1); * DoFHandler dof_handler(triangulation); * dof_handler.distribute_dofs(fe); * Vector soln_vector(dof_handler.n_dofs()); * MappingQEulerian q2_mapping(2,soln_vector,dof_handler); - * @endverbatim + * @endcode * * In this example, our element consists of (dim+1) components. * Only the first dim components will be used, however, to define diff --git a/deal.II/include/deal.II/grid/grid_out.h b/deal.II/include/deal.II/grid/grid_out.h index bb95e4c6ca..9955caa003 100644 --- a/deal.II/include/deal.II/grid/grid_out.h +++ b/deal.II/include/deal.II/grid/grid_out.h @@ -739,18 +739,18 @@ namespace GridOutFlags * and the corresponding output function names. * * Usage is simple: either you use the direct form - * @verbatim + * @code * ofstream output_file("some_filename"); * GridOut().write_gnuplot (tria, output_file); - * @endverbatim + * @endcode * if you know which format you want to have, or if you want the format to be * a runtime parameter, you can write - * @verbatim + * @code * GridOut::OutputFormat grid_format = * GridOut::parse_output_format(get_format_name_from_somewhere()); * ofstream output_file("some_filename" + GridOut::default_suffix(output_format)); * GridOut().write (tria, output_file, output_format); - * @endverbatim + * @endcode * The function get_output_format_names() provides a list of possible names of * output formats in a string that is understandable by the ParameterHandler class. * @@ -775,14 +775,14 @@ namespace GridOutFlags * format. These are collected in structures GridOutFlags::Eps(), * GridOutFlags::Gnuplot(), etc declared in the GridOutFlags * namespace, and you can set your preferred flags like this: - * @verbatim + * @code * GridOut grid_out; * GridOutFlags::Ucd ucd_flags; * ... // set some fields in ucd_flags * grid_out.set_flags (ucd_flags); * ... * ... // write some file with data_out - * @endverbatim + * @endcode * The respective output function then use the so-set flags. By default, they * are set to reasonable values as described above and in the documentation * of the different flags structures. Resetting the flags can diff --git a/deal.II/include/deal.II/grid/persistent_tria.h b/deal.II/include/deal.II/grid/persistent_tria.h index 4fcce22365..64dd0f1205 100644 --- a/deal.II/include/deal.II/grid/persistent_tria.h +++ b/deal.II/include/deal.II/grid/persistent_tria.h @@ -56,7 +56,7 @@ DEAL_II_NAMESPACE_OPEN * object of this class. * * Basically, usage looks like this: - * @verbatim + * @code * Triangulation coarse_grid; * ... // initialize coarse grid * @@ -85,7 +85,7 @@ DEAL_II_NAMESPACE_OPEN * // is not needed anymore, e.g. * // working with another grid * }; - * @endverbatim + * @endcode * * Note that initially, the PersistentTriangulation object does not * constitute a triangulation; it only becomes one after @p restore is first diff --git a/deal.II/include/deal.II/grid/tria.h b/deal.II/include/deal.II/grid/tria.h index 22afa6548c..1560b4af27 100644 --- a/deal.II/include/deal.II/grid/tria.h +++ b/deal.II/include/deal.II/grid/tria.h @@ -457,18 +457,18 @@ namespace internal * * * For dim==1, these iterators are mapped as follows: - * @verbatim + * @code * typedef line_iterator cell_iterator; * typedef active_line_iterator active_cell_iterator; - * @endverbatim + * @endcode * while for @p dim==2 we have the additional face iterator: - * @verbatim + * @code * typedef quad_iterator cell_iterator; * typedef active_quad_iterator active_cell_iterator; * * typedef line_iterator face_iterator; * typedef active_line_iterator active_face_iterator; - * @endverbatim + * @endcode * * By using the cell iterators, you can write code independent of * the spatial dimension. The same applies for substructure iterators, @@ -486,7 +486,7 @@ namespace internal * the default value dim). *
      *
    • Counting the number of cells on a specific level - * @verbatim + * @code * template * int Triangulation::n_cells (const int level) const { * cell_iterator cell = begin (level), @@ -496,9 +496,9 @@ namespace internal * ++n; * return n; * }; - * @endverbatim + * @endcode * Another way which uses the STL @p distance function would be to write - * @verbatim + * @code * template * int Triangulation::n_cells (const int level) const { * int n=0; @@ -509,10 +509,10 @@ namespace internal * n); * return n; * }; - * @endverbatim + * @endcode * *
    • Refining all cells of a triangulation - * @verbatim + * @code * template * void Triangulation::refine_global () { * active_cell_iterator cell = begin_active(), @@ -522,7 +522,7 @@ namespace internal * cell->set_refine_flag (); * execute_coarsening_and_refinement (); * }; - * @endverbatim + * @endcode *
    * * @@ -530,7 +530,7 @@ namespace internal * * Usage of a Triangulation is mainly done through the use of iterators. * An example probably shows best how to use it: - * @verbatim + * @code * void main () { * Triangulation<2> tria; * @@ -567,7 +567,7 @@ namespace internal * ofstream out("grid.1"); * GridOut::write_gnuplot (tria, out); * }; - * @endverbatim + * @endcode * * *

    Creating a triangulation

    @@ -814,7 +814,7 @@ namespace internal * It is possible to reconstruct a grid from its refinement history, which * can be stored and loaded through the @p save_refine_flags and * @p load_refine_flags functions. Normally, the code will look like this: - * @verbatim + * @code * // open output file * ofstream history("mesh.history"); * // do 10 refinement steps @@ -825,10 +825,10 @@ namespace internal * tria.save_refine_flags (history); * tria.execute_coarsening_and_refinement (); * }; - * @endverbatim + * @endcode * * If you want to re-create the grid from the stored information, you write: - * @verbatim + * @code * // open input file * ifstream history("mesh.history"); * // do 10 refinement steps @@ -836,7 +836,7 @@ namespace internal * tria.load_refine_flags (history); * tria.execute_coarsening_and_refinement (); * }; - * @endverbatim + * @endcode * * The same scheme is employed for coarsening and the coarsening flags. * @@ -898,7 +898,7 @@ namespace internal * details. Usage with the Triangulation object is then like this * (let @p Ball be a class derived from Boundary<2>): * - * @verbatim + * @code * void main () { * Triangulation<2> tria; * // set the boundary function @@ -925,7 +925,7 @@ namespace internal * tria.execute_coarsening_and_refinement(); * }; * }; - * @endverbatim + * @endcode * * You should take note of one caveat: if you have concave * boundaries, you must make sure that a new boundary vertex does diff --git a/deal.II/include/deal.II/grid/tria_boundary.h b/deal.II/include/deal.II/grid/tria_boundary.h index f093c5eb76..d1d64cadbc 100644 --- a/deal.II/include/deal.II/grid/tria_boundary.h +++ b/deal.II/include/deal.II/grid/tria_boundary.h @@ -31,17 +31,17 @@ template class Triangulation; * When a triangulation creates a new vertex on the boundary of the * domain, it determines the new vertex' coordinates through the * following code (here in two dimensions): - * @verbatim + * @code * ... * Point<2> new_vertex = boundary.get_new_point_on_line (line); * ... - * @endverbatim + * @endcode * @p line denotes the line at the boundary that shall be refined * and for which we seek the common point of the two child lines. * * In 3D, a new vertex may be placed on the middle of a line or on * the middle of a side. Respectively, the library calls - * @verbatim + * @code * ... * Point<3> new_line_vertices[4] * = { boundary.get_new_point_on_line (face->line(0)), @@ -49,14 +49,14 @@ template class Triangulation; * boundary.get_new_point_on_line (face->line(2)), * boundary.get_new_point_on_line (face->line(3)) }; * ... - * @endverbatim + * @endcode * to get the four midpoints of the lines bounding the quad at the * boundary, and after that - * @verbatim + * @code * ... * Point<3> new_quad_vertex = boundary.get_new_point_on_quad (face); * ... - * @endverbatim + * @endcode * to get the midpoint of the face. It is guaranteed that this order * (first lines, then faces) holds, so you can use information from * the children of the four lines of a face, since these already exist diff --git a/deal.II/include/deal.II/grid/tria_iterator.h b/deal.II/include/deal.II/grid/tria_iterator.h index 7b31da0960..dc75dd1242 100644 --- a/deal.II/include/deal.II/grid/tria_iterator.h +++ b/deal.II/include/deal.II/grid/tria_iterator.h @@ -258,11 +258,11 @@ public: * Through this constructor, it is also * possible to construct objects for * derived iterators: - * @verbatim + * @code * DoFCellAccessor dof_accessor; * Triangulation::active_cell_iterator cell * = accessor; - * @endverbatim + * @endcode */ TriaRawIterator (const Accessor &a); diff --git a/deal.II/include/deal.II/grid/tria_iterator_selector.h b/deal.II/include/deal.II/grid/tria_iterator_selector.h index ad39a43a54..21e45ecd11 100644 --- a/deal.II/include/deal.II/grid/tria_iterator_selector.h +++ b/deal.II/include/deal.II/grid/tria_iterator_selector.h @@ -44,11 +44,11 @@ namespace internal * @p raw_line_iterator objects operate on all lines, used or not. * * Since we are in one dimension, the following identities are declared: - * @verbatim + * @code * typedef raw_line_iterator raw_cell_iterator; * typedef line_iterator cell_iterator; * typedef active_line_iterator active_cell_iterator; - * @endverbatim + * @endcode * * To enable the declaration of @p begin_quad and the like in * Triangulation<1>, the @p quad_iterators are declared as @@ -105,7 +105,7 @@ namespace internal * are useless and will certainly make any involuntary use visible. * * Since we are in two dimension, the following identities are declared: - * @verbatim + * @code * typedef raw_quad_iterator raw_cell_iterator; * typedef quad_iterator cell_iterator; * typedef active_quad_iterator active_cell_iterator; @@ -113,7 +113,7 @@ namespace internal * typedef raw_line_iterator raw_face_iterator; * typedef line_iterator face_iterator; * typedef active_line_iterator active_face_iterator; - * @endverbatim + * @endcode * * @author Wolfgang Bangerth, 1998 */ @@ -144,7 +144,7 @@ namespace internal * For the declarations of the data types, more or less the same holds * as for lower dimensions (see Iterators<[12]>). The * dimension specific data types are here, since we are in three dimensions: - * @verbatim + * @code * typedef raw_hex_iterator raw_cell_iterator; * typedef hex_iterator cell_iterator; * typedef active_hex_iterator active_cell_iterator; @@ -152,7 +152,7 @@ namespace internal * typedef raw_quad_iterator raw_face_iterator; * typedef quad_iterator face_iterator; * typedef active_quad_iterator active_face_iterator; - * @endverbatim + * @endcode * * @author Wolfgang Bangerth, 1998 */ diff --git a/deal.II/include/deal.II/lac/arpack_solver.h b/deal.II/include/deal.II/lac/arpack_solver.h index b569834e21..7211dcb544 100644 --- a/deal.II/include/deal.II/lac/arpack_solver.h +++ b/deal.II/include/deal.II/lac/arpack_solver.h @@ -36,11 +36,11 @@ DEAL_II_NAMESPACE_OPEN * * The ArpackSolver can be used in application codes in the * following way: - @verbatim + @code SolverControl solver_control (1000, 1e-9); ArpackSolver (solver_control); system.solve (A, B, lambda, x, size_of_spectrum); - @endverbatim + @endcode * for the generalized eigenvalue problem $Ax=B\lambda x$, where * the variable const unsigned int size_of_spectrum * tells ARPACK the number of eigenvector/eigenvalue pairs to diff --git a/deal.II/include/deal.II/lac/compressed_set_sparsity_pattern.h b/deal.II/include/deal.II/lac/compressed_set_sparsity_pattern.h index 5f23cb011c..3235b5b181 100644 --- a/deal.II/include/deal.II/lac/compressed_set_sparsity_pattern.h +++ b/deal.II/include/deal.II/lac/compressed_set_sparsity_pattern.h @@ -65,7 +65,7 @@ template class SparseMatrix; *

    Usage

    * * Use this class as follows: - * @verbatim + * @code * CompressedSetSparsityPattern compressed_pattern (dof_handler.n_dofs()); * DoFTools::make_sparsity_pattern (dof_handler, * compressed_pattern); @@ -73,7 +73,7 @@ template class SparseMatrix; * * SparsityPattern sp; * sp.copy_from (compressed_pattern); - * @endverbatim + * @endcode * * See also step-11 and step-18 for usage * patterns of the related CompressedSparsityPattern class, and diff --git a/deal.II/include/deal.II/lac/compressed_simple_sparsity_pattern.h b/deal.II/include/deal.II/lac/compressed_simple_sparsity_pattern.h index 09a9bffa7a..a7b9daed20 100644 --- a/deal.II/include/deal.II/lac/compressed_simple_sparsity_pattern.h +++ b/deal.II/include/deal.II/lac/compressed_simple_sparsity_pattern.h @@ -66,7 +66,7 @@ template class SparseMatrix; *

    Usage

    * * Use this class as follows: - * @verbatim + * @code * CompressedSimpleSparsityPattern compressed_pattern (dof_handler.n_dofs()); * DoFTools::make_sparsity_pattern (dof_handler, * compressed_pattern); @@ -74,7 +74,7 @@ template class SparseMatrix; * * SparsityPattern sp; * sp.copy_from (compressed_pattern); - * @endverbatim + * @endcode * * *

    Notes

    diff --git a/deal.II/include/deal.II/lac/compressed_sparsity_pattern.h b/deal.II/include/deal.II/lac/compressed_sparsity_pattern.h index ffb6333054..94ade69251 100644 --- a/deal.II/include/deal.II/lac/compressed_sparsity_pattern.h +++ b/deal.II/include/deal.II/lac/compressed_sparsity_pattern.h @@ -65,7 +65,7 @@ template class SparseMatrix; *

    Usage

    * * Use this class as follows: - * @verbatim + * @code * CompressedSparsityPattern compressed_pattern (dof_handler.n_dofs()); * DoFTools::make_sparsity_pattern (dof_handler, * compressed_pattern); @@ -73,7 +73,7 @@ template class SparseMatrix; * * SparsityPattern sp; * sp.copy_from (compressed_pattern); - * @endverbatim + * @endcode * * See also step-11 and step-18 for usage * patterns. diff --git a/deal.II/include/deal.II/lac/filtered_matrix.h b/deal.II/include/deal.II/lac/filtered_matrix.h index 8a1ee43bf7..939b77e72e 100644 --- a/deal.II/include/deal.II/lac/filtered_matrix.h +++ b/deal.II/include/deal.II/lac/filtered_matrix.h @@ -67,7 +67,7 @@ template class FilteredMatrixBlock; * available. * * A typical code snippet showing the above steps is as follows: - * @verbatim + * @code * ... // set up sparse matrix A and right hand side b somehow * * // initialize filtered matrix with @@ -91,7 +91,7 @@ template class FilteredMatrixBlock; * * // solve for solution vector x * solver.solve (filtered_A, x, b, filtered_prec); - * @endverbatim + * @endcode * * *

    Connection to other classes

    diff --git a/deal.II/include/deal.II/lac/full_matrix.h b/deal.II/include/deal.II/lac/full_matrix.h index c2a22dd377..a8db6a6ea2 100644 --- a/deal.II/include/deal.II/lac/full_matrix.h +++ b/deal.II/include/deal.II/lac/full_matrix.h @@ -286,9 +286,9 @@ public: * constructor, one can easily * create an identity matrix of * size n by saying - * @verbatim + * @code * FullMatrix M(IdentityMatrix(n)); - * @endverbatim + * @endcode */ FullMatrix (const IdentityMatrix &id); /** @@ -335,9 +335,9 @@ public: * the argument. This way, one can easily * create an identity matrix of * size n by saying - * @verbatim + * @code * M = IdentityMatrix(n); - * @endverbatim + * @endcode */ FullMatrix & operator = (const IdentityMatrix &id); diff --git a/deal.II/include/deal.II/lac/identity_matrix.h b/deal.II/include/deal.II/lac/identity_matrix.h index 9f3a1a6577..a29e08c486 100644 --- a/deal.II/include/deal.II/lac/identity_matrix.h +++ b/deal.II/include/deal.II/lac/identity_matrix.h @@ -37,9 +37,9 @@ DEAL_II_NAMESPACE_OPEN * * The main usefulness of this class lies in its ability to initialize * other matrix, like this: - @verbatim + @code FullMatrix identity (IdentityMatrix(10)); - @endverbatim + @endcode * * This creates a $10\times 10$ matrix with ones on the diagonal and * zeros everywhere else. Most matrix types, in particular FullMatrix @@ -56,12 +56,12 @@ DEAL_II_NAMESPACE_OPEN * context as shown in the documentation of that class. The present * class can be used in much the same way, although without any * additional benefit: - @verbatim + @code SolverControl solver_control (1000, 1e-12); SolverCG<> cg (solver_control); cg.solve (system_matrix, solution, system_rhs, IdentityMatrix(solution.size())); - @endverbatim + @endcode * * * @author Wolfgang Bangerth, 2006 diff --git a/deal.II/include/deal.II/lac/matrix_out.h b/deal.II/include/deal.II/lac/matrix_out.h index ad215034d5..7284f9b0f1 100644 --- a/deal.II/include/deal.II/lac/matrix_out.h +++ b/deal.II/include/deal.II/lac/matrix_out.h @@ -34,7 +34,7 @@ DEAL_II_NAMESPACE_OPEN * of the base class. * * A typical usage of this class would be as follows: - * @verbatim + * @code * FullMatrix M; * ... // fill matrix M with some values * @@ -43,7 +43,7 @@ DEAL_II_NAMESPACE_OPEN * std::ofstream out ("M.gnuplot"); * matrix_out.build_patches (M, "M"); * matrix_out.write_gnuplot (out); - * @endverbatim + * @endcode * Of course, you can as well choose a different graphical output * format. Also, this class supports any matrix, not only of type * FullMatrix, as long as it satisfies a number of requirements, @@ -62,7 +62,7 @@ DEAL_II_NAMESPACE_OPEN * DataOutInterface does so as well, this does no harm, but * calms the compiler which is suspecting an access control conflict * otherwise. Testcase here: - * @verbatim + * @code * template class V {}; * * struct B1 { @@ -80,7 +80,7 @@ DEAL_II_NAMESPACE_OPEN * }; * * D d; - * @endverbatim + * @endcode * * @ingroup output * @author Wolfgang Bangerth, 2001 diff --git a/deal.II/include/deal.II/lac/petsc_parallel_vector.h b/deal.II/include/deal.II/lac/petsc_parallel_vector.h index 7fe5a5633a..e1fab26b3d 100644 --- a/deal.II/include/deal.II/lac/petsc_parallel_vector.h +++ b/deal.II/include/deal.II/lac/petsc_parallel_vector.h @@ -111,7 +111,7 @@ namespace PETScWrappers * operation of the opposite kind, it calls compress() and flips the * state. This can sometimes lead to very confusing behavior, in code that may * for example look like this: - * @verbatim + * @code * PETScWrappers::MPI::Vector vector; * ... * // do some write operations on the vector @@ -126,7 +126,7 @@ namespace PETScWrappers * * // do another collective operation * const double norm = vector.l2_norm(); - * @endverbatim + * @endcode * * This code can run into trouble: by the time we see the first addition * operation, we need to flush the overwrite buffers for the vector, and the diff --git a/deal.II/include/deal.II/lac/precondition.h b/deal.II/include/deal.II/lac/precondition.h index a56e555443..a2603c8498 100644 --- a/deal.II/include/deal.II/lac/precondition.h +++ b/deal.II/include/deal.II/lac/precondition.h @@ -45,12 +45,12 @@ namespace parallel * preconditioner. Therefore, you must use the identity provided here * to avoid preconditioning. It can be used in the following way: * - @verbatim + @code SolverControl solver_control (1000, 1e-12); SolverCG<> cg (solver_control); cg.solve (system_matrix, solution, system_rhs, PreconditionIdentity()); - @endverbatim + @endcode * * See the step-3 tutorial program for an example and * additional explanations. diff --git a/deal.II/include/deal.II/lac/precondition_selector.h b/deal.II/include/deal.II/lac/precondition_selector.h index 12d6c4ce05..d4451c3fe8 100644 --- a/deal.II/include/deal.II/lac/precondition_selector.h +++ b/deal.II/include/deal.II/lac/precondition_selector.h @@ -43,7 +43,7 @@ template class SparseMatrix; * *

    Usage

    * The simplest use of this class is the following: - * @verbatim + * @code * // generate a @p SolverControl and * // a @p VectorMemory * SolverControl control; @@ -61,9 +61,9 @@ template class SparseMatrix; * // call the @p solve function with this * // preconditioning as last argument * solver.solve(A,x,b,preconditioning); - * @endverbatim + * @endcode * The same example where also the @p SolverSelector class is used reads - * @verbatim + * @code * // generate a @p SolverControl and * // a @p VectorMemory * SolverControl control; @@ -79,7 +79,7 @@ template class SparseMatrix; * preconditioning.use_matrix(A); * * solver_selector.solve(A,x,b,preconditioning); - * @endverbatim + * @endcode * Now the use of the @p SolverSelector in combination with the @p PreconditionSelector * allows the user to select both, the solver and the preconditioner, at the * beginning of his program and each time the diff --git a/deal.II/include/deal.II/lac/schur_matrix.h b/deal.II/include/deal.II/lac/schur_matrix.h index 8b59d15765..8f6d671f82 100644 --- a/deal.II/include/deal.II/lac/schur_matrix.h +++ b/deal.II/include/deal.II/lac/schur_matrix.h @@ -80,11 +80,11 @@ DEAL_II_NAMESPACE_OPEN * Applying these transformations, the solution of the system above by a * @p SchurMatrix @p schur is coded as follows: * - * @verbatim + * @code * schur.prepare_rhs (g, f); * solver.solve (schur, p, g, precondition); * schur.postprocess (u, p); - * @endverbatim + * @endcode * * @see @ref GlossBlockLA "Block (linear algebra)" * @author Guido Kanschat, 2000, 2001, 2002 diff --git a/deal.II/include/deal.II/lac/slepc_solver.h b/deal.II/include/deal.II/lac/slepc_solver.h index 8277f35b0f..7c7a38f923 100644 --- a/deal.II/include/deal.II/lac/slepc_solver.h +++ b/deal.II/include/deal.II/lac/slepc_solver.h @@ -49,10 +49,13 @@ DEAL_II_NAMESPACE_OPEN * interface to SLEPc solvers that handle both of these problem sets. * * SLEPcWrappers can be implemented in application codes in the - * following way: @verbatim SolverControl solver_control (1000, 1e-9); - * SolverArnoldi system (solver_control, mpi_communicator); - * system.solve (A, B, lambda, x, size_of_spectrum); @endverbatim for - * the generalized eigenvalue problem $Ax=B\lambda x$, where the + * following way: + * @code + * SolverControl solver_control (1000, 1e-9); + * SolverArnoldi system (solver_control, mpi_communicator); + * system.solve (A, B, lambda, x, size_of_spectrum); + * @endcode + * 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 step-36 for a hands-on example. @@ -63,7 +66,7 @@ DEAL_II_NAMESPACE_OPEN * rather than just one. This freedom is intended for use of the * SLEPcWrappers that require a greater handle on the eigenvalue * problem solver context. See also the API of: - @verbatim + @code template void SolverBase::solve (const PETScWrappers::MatrixBase &A, @@ -72,7 +75,7 @@ DEAL_II_NAMESPACE_OPEN std::vector &vr, const unsigned int n_eigenvectors) { ... } - @endverbatim + @endcode * as an example on how to do this. * * For further information and explanations on handling the @ref diff --git a/deal.II/include/deal.II/lac/solver_selector.h b/deal.II/include/deal.II/lac/solver_selector.h index cb9149e6c2..a5a4c9ebd0 100644 --- a/deal.II/include/deal.II/lac/solver_selector.h +++ b/deal.II/include/deal.II/lac/solver_selector.h @@ -41,7 +41,7 @@ DEAL_II_NAMESPACE_OPEN * *

    Usage

    * The simplest use of this class is the following: - * @verbatim + * @code * // generate a @p SolverControl and * // a @p VectorMemory * SolverControl control; @@ -59,26 +59,26 @@ DEAL_II_NAMESPACE_OPEN * // call the @p solve function with this * // preconditioning as last argument * solver_selector.solve(A,x,b,preconditioning); - * @endverbatim + * @endcode * But the full usefulness of the @p SolverSelector class is not * clear until the presentation of the following example that assumes * the user using the @p ParameterHandler class and having declared a * "solver" entry, e.g. with - * @verbatim + * @code * Parameter_Handler prm; * prm.declare_entry ("solver", "none", * Patterns::Selection(SolverSelector<>::get_solver_names())); * ... - * @endverbatim + * @endcode * Assuming that in the users parameter file there exists the line - * @verbatim - * set solver = cg - * @endverbatim + @verbatim + set solver = cg + @endverbatim * then `Line 3' of the above example reads - * @verbatim + * @code * SolverSelector, Vector > * solver_selector(prm.get("solver"), control, memory); - * @endverbatim + * @endcode * * * If at some time there exists a new solver "xyz" then the user does not need diff --git a/deal.II/include/deal.II/lac/sparse_vanka.h b/deal.II/include/deal.II/lac/sparse_vanka.h index 88f2367b4b..0989a77bc7 100644 --- a/deal.II/include/deal.II/lac/sparse_vanka.h +++ b/deal.II/include/deal.II/lac/sparse_vanka.h @@ -89,7 +89,7 @@ template class SparseBlockVanka; * This little example is taken from a program doing parameter optimization. * The Lagrange multiplier is the third component of the finite element * used. The system is solved by the GMRES method. - * @verbatim + * @code * // tag the Lagrange multiplier variable * vector signature(3); * signature[0] = signature[1] = false; @@ -109,7 +109,7 @@ template class SparseBlockVanka; * // solve * gmres.solve (global_matrix, solution, right_hand_side, * vanka); - * @endverbatim + * @endcode * * *

    Implementor's remark

    diff --git a/deal.II/include/deal.II/lac/trilinos_vector.h b/deal.II/include/deal.II/lac/trilinos_vector.h index 40be55fe07..b1f53d34de 100644 --- a/deal.II/include/deal.II/lac/trilinos_vector.h +++ b/deal.II/include/deal.II/lac/trilinos_vector.h @@ -124,7 +124,7 @@ namespace TrilinosWrappers * compress() and flips the state. This can sometimes lead to very * confusing behavior, in code that may for example look like this: * - * @verbatim + * @code * TrilinosWrappers::Vector vector; * // do some write operations on the vector * for (unsigned int i=0; isize(); ++i) @@ -138,7 +138,7 @@ namespace TrilinosWrappers * * // do another collective operation * const double norm = vector->l2_norm(); - * @endverbatim + * @endcode * * This code can run into trouble: by the time we see the first addition * operation, we need to flush the overwrite buffers for the vector, and diff --git a/deal.II/include/deal.II/numerics/data_out_stack.h b/deal.II/include/deal.II/numerics/data_out_stack.h index 1b90b3f195..bfbe7ac39e 100644 --- a/deal.II/include/deal.II/numerics/data_out_stack.h +++ b/deal.II/include/deal.II/numerics/data_out_stack.h @@ -69,7 +69,7 @@ template class DoFHandler; * which is suitable for quadratic finite elements in space, for * example. * - * @verbatim + * @code * DataOutStack data_out_stack; * * // first declare the vectors @@ -97,7 +97,7 @@ template class DoFHandler; * data_out_stack.build_patches (2); * data_out_stack.finish_parameter_value (); * }; - * @endverbatim + * @endcode * * @ingroup output * @author Wolfgang Bangerth, 1999 diff --git a/deal.II/include/deal.II/numerics/solution_transfer.h b/deal.II/include/deal.II/numerics/solution_transfer.h index 46bce989f9..443d140306 100644 --- a/deal.II/include/deal.II/numerics/solution_transfer.h +++ b/deal.II/include/deal.II/numerics/solution_transfer.h @@ -41,7 +41,7 @@ DEAL_II_NAMESPACE_OPEN *
      *
    • If the grid will only be refined * (i.e. no cells are coarsened) then use @p SolutionTransfer as follows: - * @verbatim + * @code * SolutionTransfer soltrans(*dof_handler); * // flag some cells for refinement, e.g. * GridRefinement::refine_and_coarsen_fixed_fraction( @@ -56,10 +56,10 @@ DEAL_II_NAMESPACE_OPEN * tria->execute_coarsening_and_refinement(); * // and redistribute dofs. * dof_handler->distribute_dofs (fe); - * @endverbatim + * @endcode * * Then to proceed do - * @verbatim + * @code * // take a copy of the solution vector * Vector solution_old(solution); * // resize solution vector to the correct @@ -69,24 +69,24 @@ DEAL_II_NAMESPACE_OPEN * solution.reinit(dof_handler->n_dofs()); * // and finally interpolate * soltrans.refine_interpolate(solution_old, solution); - * @endverbatim + * @endcode * * Although the @p refine_interpolate functions are allowed to be * called multiple times, e.g. for interpolating several solution * vectors, there is following possibility of interpolating several * functions simultaneously. - * @verbatim + * @code * vector > solutions_old(n_vectors, Vector (n)); * ... * vector > solutions(n_vectors, Vector (n)); * soltrans.refine_interpolate(solutions_old, solutions); - * @endverbatim + * @endcode * This is used in several of the tutorial programs, for example * step-31. * *
    • If the grid has cells that will be coarsened, * then use @p SolutionTransfer as follows: - * @verbatim + * @code * SolutionTransfer > soltrans(*dof_handler); * // flag some cells for refinement * // and coarsening, e.g. @@ -106,7 +106,7 @@ DEAL_II_NAMESPACE_OPEN * // and interpolate the solution * Vector interpolate_solution(dof_handler->n_dofs()); * soltrans.interpolate(solution, interpolated_solution); - * @endverbatim + * @endcode * * Multiple calls to the function * interpolate (const Vector &in, Vector &out) diff --git a/deal.II/include/deal.II/numerics/time_dependent.h b/deal.II/include/deal.II/numerics/time_dependent.h index d9257fd470..cf7a73cec9 100644 --- a/deal.II/include/deal.II/numerics/time_dependent.h +++ b/deal.II/include/deal.II/numerics/time_dependent.h @@ -186,7 +186,7 @@ template class Triangulation; * The main loop of a program using this class will usually look like * the following one, taken modified from an application program that * isn't distributed as part of the library: - * @verbatim + * @code * template * void TimeDependent_Wave::run_sweep (const unsigned int sweep_no) * { @@ -215,7 +215,7 @@ template class Triangulation; * for (unsigned int sweep=0; sweep class Triangulation; * timesteps within this object and call the respective function on each of * these objects. For example, here are two of the functions as they are * implemented by the library: - * @verbatim + * @code * void TimeDependent::start_sweep (const unsigned int s) * { * sweep_no = s; @@ -254,7 +254,7 @@ template class Triangulation; * timestepping_data_primal, * forward); * }; - * @endverbatim + * @endcode * The latter function shows rather clear how most of the loops are * invoked (@p solve_primal_problem, @p solve_dual_problem, @p postprocess, * @p refine_grids and @p write_statistics all have this form, where the @@ -275,7 +275,7 @@ template class Triangulation; * the C++ standard library, it is possible to do neat tricks, like * the following, also taken from the wave program, in this case from * the function @p refine_grids: - * @verbatim + * @code * ... * compute the thresholds for refinement * ... @@ -286,7 +286,7 @@ template class Triangulation; * bottom_threshold)), * TimeDependent::TimeSteppingData (0,1), * TimeDependent::forward); - * @endverbatim + * @endcode * TimeStepBase_Wave::refine_grid is a function taking an argument, unlike * all the other functions used above within the loops. However, in this special * case the parameter was the same for all timesteps and known before the loop @@ -299,7 +299,7 @@ template class Triangulation; * brevity we have omitted the parts that deal with backward running loops * as well as the checks whether wake-up and sleep operations act on timesteps * outside 0..n_timesteps-1. - * @verbatim + * @code * template * void TimeDependent::do_loop (InitFunctionObject init_function, * LoopFunctionObject loop_function, @@ -341,7 +341,7 @@ template class Triangulation; * for (int look_back=0; look_back<=timestepping_data.look_back; ++look_back) * timesteps[step-look_back]->sleep(look_back); * }; - * @endverbatim + * @endcode * * * @author Wolfgang Bangerth, 1999 @@ -492,10 +492,10 @@ public: * * This mechanism usually will result * in a set-up loop like this - * @verbatim + * @code * for (i=0; i