]> https://gitweb.dealii.org/ - dealii-svn.git/commitdiff
Patch by Felix Gruber: Consistently use @code...@endcode.
authorbangerth <bangerth@0785d39b-7218-0410-832d-ea1e28bc413d>
Fri, 15 Feb 2013 14:19:01 +0000 (14:19 +0000)
committerbangerth <bangerth@0785d39b-7218-0410-832d-ea1e28bc413d>
Fri, 15 Feb 2013 14:19:01 +0000 (14:19 +0000)
git-svn-id: https://svn.dealii.org/trunk@28405 0785d39b-7218-0410-832d-ea1e28bc413d

33 files changed:
deal.II/doc/news/changes.h
deal.II/include/deal.II/base/function_parser.h
deal.II/include/deal.II/base/template_constraints.h
deal.II/include/deal.II/distributed/solution_transfer.h
deal.II/include/deal.II/fe/fe.h
deal.II/include/deal.II/fe/fe_poly_tensor.h
deal.II/include/deal.II/fe/mapping_q1_eulerian.h
deal.II/include/deal.II/fe/mapping_q_eulerian.h
deal.II/include/deal.II/grid/grid_out.h
deal.II/include/deal.II/grid/persistent_tria.h
deal.II/include/deal.II/grid/tria.h
deal.II/include/deal.II/grid/tria_boundary.h
deal.II/include/deal.II/grid/tria_iterator.h
deal.II/include/deal.II/grid/tria_iterator_selector.h
deal.II/include/deal.II/lac/arpack_solver.h
deal.II/include/deal.II/lac/compressed_set_sparsity_pattern.h
deal.II/include/deal.II/lac/compressed_simple_sparsity_pattern.h
deal.II/include/deal.II/lac/compressed_sparsity_pattern.h
deal.II/include/deal.II/lac/filtered_matrix.h
deal.II/include/deal.II/lac/full_matrix.h
deal.II/include/deal.II/lac/identity_matrix.h
deal.II/include/deal.II/lac/matrix_out.h
deal.II/include/deal.II/lac/petsc_parallel_vector.h
deal.II/include/deal.II/lac/precondition.h
deal.II/include/deal.II/lac/precondition_selector.h
deal.II/include/deal.II/lac/schur_matrix.h
deal.II/include/deal.II/lac/slepc_solver.h
deal.II/include/deal.II/lac/solver_selector.h
deal.II/include/deal.II/lac/sparse_vanka.h
deal.II/include/deal.II/lac/trilinos_vector.h
deal.II/include/deal.II/numerics/data_out_stack.h
deal.II/include/deal.II/numerics/solution_transfer.h
deal.II/include/deal.II/numerics/time_dependent.h

index f863bdf26baba8bb15e09dbdb37e23ce25589f4d..d61fc7ebc0f25fc2a81687f6f93ba4cd5f9ca9b6 100644 (file)
@@ -153,6 +153,13 @@ never working correctly and it is not used.
 
 
 <ol>
+<li> 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.
+<br>
+(Felix Gruber, 2013/02/15)
+
 <li> Fixed: Starting in release 7.1, we first built the deal.II shared libraries
 in the local <code>/tmp</code> or similar directory rather than the final location
 because linking becomes very slow over remotely mounted file systems. Unfortunately,
index 6e0654f798d8142a53f2b5eb9a17b173c2050c6c..7002002685e72ab4b1d9bec856b3d14f551a08ad 100644 (file)
@@ -52,7 +52,7 @@ template <typename> 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<std::string,double> constants;
   constants["pi"] = numbers::PI;
@@ -73,11 +73,11 @@ template <typename> class Vector;
   vector_function.initialize(variables,
                              expressions,
                              constants);
-  @endverbatim
+  @endcode
 
  * FunctionParser also provides an option to use <b>units</b> 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<std::string> constants;
   std::map<std::string> units;
@@ -110,7 +110,7 @@ template <typename> class Vector;
     " @point " << "[" << point << "]" << " is " <<
     "[" <<  vector_function.value(point) << "]" << std::endl;
 
- * @endverbatim
+ * @endcode
  *
  * Units are similar to <b>constants</b> in the way they are passed to the
  * parser, i.e. via std::map<std::string,double>.  But units are slightly different
@@ -259,7 +259,7 @@ template <typename> 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<std::string> constants;
@@ -282,11 +282,11 @@ template <typename> 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<std::string> constants;
@@ -305,7 +305,7 @@ template <typename> class Vector;
                           expression,
                           constants);
 
-     @endverbatim
+     @endcode
  *
  *
  * @ingroup functions
index 19deafc271d6adb1723570576c0cf79d5dfb58e6..368251b61edc67e40fe655be206d669d68e17114 100644 (file)
@@ -32,12 +32,12 @@ template <bool, typename> 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>
  *   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 <bool, typename> 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 <bool, typename> struct constraint_and_return_value;
  *   template <typename T> struct constraint_and_return_value<true,T> {
  *     typedef T type;
  *   };
- * @endverbatim
+ * @endcode
  * constraint_and_return_value<false,T> is not defined. Given something like
- * @verbatim
+ * @code
  *   template <typename>
  *   struct int_or_double         { static const bool value = false;};
  *   template <>
  *   struct int_or_double<int>    { static const bool value = true; };
  *   template <>
  *   struct int_or_double<double> { static const bool value = true; };
- * @endverbatim
+ * @endcode
  * we can write a template
- * @verbatim
+ * @code
  *   template <typename T>
  *   typename constraint_and_return_value<int_or_double<T>::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 <int dim>
    *   class X {
    *     // do something on subdim-dimensional sub-objects of the big
@@ -207,13 +207,13 @@ namespace internal
    *   template <int dim, int subdim> void f(X<dim> &x) {
    *     x.f<subdim> ();
    *   }
-   * @endverbatim
+   * @endcode
    *
    * The problem is: the language doesn't allow us to specialize
    * <code>X::f()</code> without specializing the outer class first. One
    * of the common tricks is therefore to use something like this:
    *
-   * @verbatim
+   * @code
    *   template <int N> struct int2type {};
    *
    *   template <int dim>
@@ -236,7 +236,7 @@ namespace internal
    *   template <int dim, int subdim> void f(X<dim> &x) {
    *     x.f (int2type<subdim>());
    *   }
-   * @endverbatim
+   * @endcode
    *
    * Note that we have replaced specialization of <code>X::f()</code> by
    * overloading, but that from inside the function <code>g()</code>, we
index 8c444d7b0605fc3b72e64ed4990b31696a39f65e..55b0c930f7ff8f70c60f4103a2fbd09fee7681f5 100644 (file)
@@ -48,7 +48,7 @@ namespace parallel
      * <h3>Transfering a solution</h3>
      * Here VECTOR is your favorite vector type, e.g. PETScWrappers::MPI::Vector,
      * TrilinosWrappers::MPI::Vector, or corresponding blockvectors.
-     * @verbatim
+     * @code
      SolutionTransfer<dim, VECTOR> 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
      *
      * <h3>Use for Serialization</h3>
      *
@@ -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<dim,VECTOR> 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<dim,VECTOR> sol_trans(dof_handler);
     sol_trans.deserialize (distributed_vector);
-    @endverbatim
+    @endcode
      *
      * @ingroup distributed
      * @author Timo Heister, 2009-2011
index 0e8633a755af499fa144e72e6ce0aba387b6357c..3059dbcc02e9f7a1469ac788284bd90e22266362 100644 (file)
@@ -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
index 4a8c3c235f858eb4fdb5a9d77d5906234fb94c01..2a8c4e3afca13c18df238ee4ef717713ee845b2f 100644 (file)
@@ -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
index 661abf6d2b01e3bf0a5c809cf19aabc6acad842d..8db4e8bd2eb1968f7f033e57bc76b3fef5517e56 100644 (file)
@@ -57,13 +57,13 @@ DEAL_II_NAMESPACE_OPEN
  * to it.
  *
  * An example is shown below:
- * @verbatim
+ * @code
  *    FESystem<dim> fe(FE_Q<dim>(1), dim);
  *    DoFHandler<dim> flowfield_dof_handler(triangulation);
  *    flowfield_dof_handler.distribute_dofs(fe);
  *    Vector<double> map_points(flowfield_dof_handler.n_dofs());
  *    MappingQ1Eulerian<dim> 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
index e887c0c5e30ddc7b74098dc877ec299f1914f2ce..d2547ff956e0510d6a77fd301fa9ea9b6c81d0f8 100644 (file)
@@ -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<dim> fe(FE_Q<dim>(2), dim, FE_Q<dim>(1), 1);
  *    DoFHandler<dim> dof_handler(triangulation);
  *    dof_handler.distribute_dofs(fe);
  *    Vector<double> soln_vector(dof_handler.n_dofs());
  *    MappingQEulerian<dim> q2_mapping(2,soln_vector,dof_handler);
- * @endverbatim
+ * @endcode
  *
  * In this example, our element consists of <tt>(dim+1)</tt> components.
  * Only the first <tt>dim</tt> components will be used, however, to define
index bb95e4c6ca45239c0f62dc25bafffa77783b6ea1..9955caa0037baa057102d23df2f2e03b1aff9b59 100644 (file)
@@ -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 <tt>get_output_format_names()</tt> 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
index 4fcce22365f24f16977793270b936c1ab009ca97..64dd0f12056f76600cbae18e9978409ad33b2bca 100644 (file)
@@ -56,7 +56,7 @@ DEAL_II_NAMESPACE_OPEN
  * object of this class.
  *
  * Basically, usage looks like this:
- * @verbatim
+ * @code
  *   Triangulation<dim> 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
index 22afa6548c25999a95097d862a00a15b43706614..1560b4af2726bcff077f3f8451f7c152921a6fff 100644 (file)
@@ -457,18 +457,18 @@ namespace internal
  *  </ul>
  *
  *  For <tt>dim==1</tt>, 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 <code>dim</code>).
  *  <ul>
  *  <li> <em>Counting the number of cells on a specific level</em>
- *    @verbatim
+ *    @code
  *     template <int dim, int spacedim>
  *     int Triangulation<dim, spacedim>::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 dim>
  *      int Triangulation<dim>::n_cells (const int level) const {
  *        int n=0;
@@ -509,10 +509,10 @@ namespace internal
  *                  n);
  *        return n;
  *      };
- *    @endverbatim
+ *    @endcode
  *
  *  <li> <em>Refining all cells of a triangulation</em>
- *    @verbatim
+ *    @code
  *      template <int dim>
  *      void Triangulation<dim>::refine_global () {
  *        active_cell_iterator cell = begin_active(),
@@ -522,7 +522,7 @@ namespace internal
  *          cell->set_refine_flag ();
  *        execute_coarsening_and_refinement ();
  *      };
- *    @endverbatim
+ *    @endcode
  *  </ul>
  *
  *
@@ -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
  *
  *
  *  <h3>Creating a triangulation</h3>
@@ -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<tt><2></tt>):
  *
- *   @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
index f093c5eb76684f20aae7a27e1029187bae7231ec..d1d64cadbc7f833a39650b9a6ad3cf540b76f9de 100644 (file)
@@ -31,17 +31,17 @@ template <int dim, int space_dim> 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 <int dim, int space_dim> 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
index 7b31da09600384ba2e6a7a310c2436bb223c9209..dc75dd12420371c92612ef9bfdda1dcbf2219d37 100644 (file)
@@ -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);
 
index ad39a43a54e149bcf3bbbdc375deafd941be3997..21e45ecd114dbca111e67b015fe0fad0066d06a2 100644 (file)
@@ -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
      *  <tt>Triangulation<1></tt>, 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 <tt>Iterators<[12]></tt>). 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
      */
index b569834e21825f1885bf5f8b424ef56ee9ab4319..7211dcb544fe86b82d314341417ff6f20405935f 100644 (file)
@@ -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 <code>const unsigned int size_of_spectrum</code>
  * tells ARPACK the number of eigenvector/eigenvalue pairs to
index 5f23cb011cd8d3ba5d3539e32851e675b594789c..3235b5b181ea7863dccb4ca7b8bb7a8b8396d899 100644 (file)
@@ -65,7 +65,7 @@ template <typename number> class SparseMatrix;
  * <h3>Usage</h3>
  *
  * 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 <typename number> 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
index 09a9bffa7abbabf6b2b66d532a33f5de1633417b..a7b9daed20ecbd1a836d276a720a571551fbf7db 100644 (file)
@@ -66,7 +66,7 @@ template <typename number> class SparseMatrix;
  * <h3>Usage</h3>
  *
  * 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 <typename number> class SparseMatrix;
  *
  * SparsityPattern sp;
  * sp.copy_from (compressed_pattern);
- * @endverbatim
+ * @endcode
  *
  *
  * <h3>Notes</h3>
index ffb6333054893c9fa9eba539230affe26e4d53b7..94ade6925157a8aa90bd142423a5d8d4f0a8a750 100644 (file)
@@ -65,7 +65,7 @@ template <typename number> class SparseMatrix;
  * <h3>Usage</h3>
  *
  * 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 <typename number> class SparseMatrix;
  *
  * SparsityPattern sp;
  * sp.copy_from (compressed_pattern);
- * @endverbatim
+ * @endcode
  *
  * See also step-11 and step-18 for usage
  * patterns.
index 8a1ee43bf7859c1b6752b07ecee78454f2b6e594..939b77e72ea97e674eef6da211cd8d4e94b19892 100644 (file)
@@ -67,7 +67,7 @@ template <class VECTOR> 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 VECTOR> class FilteredMatrixBlock;
  *
  *                     // solve for solution vector x
  *   solver.solve (filtered_A, x, b, filtered_prec);
- * @endverbatim
+ * @endcode
  *
  *
  * <h3>Connection to other classes</h3>
index c2a22dd377b54e493bb9c9c82d6e5aa273703ecf..a8db6a6ea27c64b15e141223b99a7cb281e916a2 100644 (file)
@@ -286,9 +286,9 @@ public:
    * constructor, one can easily
    * create an identity matrix of
    * size <code>n</code> by saying
-   * @verbatim
+   * @code
    * FullMatrix<double> 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 <code>n</code> by saying
-   * @verbatim
+   * @code
    *   M = IdentityMatrix(n);
-   * @endverbatim
+   * @endcode
    */
   FullMatrix<number> &
   operator = (const IdentityMatrix &id);
index 9f3a1a65779bac9f6e4a2db82911f89036d71202..a29e08c486c9b4cf9476e989e596c41eaf8a5e9e 100644 (file)
@@ -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<double> 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
index ad215034d5927fe153915e83db9e6e5a845971b7..7284f9b0f1b46bff19a2ad639b43985938eb1c5d 100644 (file)
@@ -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<double> 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 <typename T> class V {};
  *
  *    struct B1 {
@@ -80,7 +80,7 @@ DEAL_II_NAMESPACE_OPEN
  *    };
  *
  *    D d;
- * @endverbatim
+ * @endcode
  *
  * @ingroup output
  * @author Wolfgang Bangerth, 2001
index 7fe5a5633a2727fb2175fa27198d72caeec0614d..e1fab26b3dc248962ff03baaa43b641310e6ec20 100644 (file)
@@ -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
index a56e5554435a019cffc9ce93ea313f8887673734..a2603c8498d75302781be79a1901fd2fe08dfe19 100644 (file)
@@ -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.
index 12d6c4ce056cb6a46a64cc52a8eb34d29328f5bf..d4451c3fe8b0bcfd603942781715b3513083dcc8 100644 (file)
@@ -43,7 +43,7 @@ template <class number> class SparseMatrix;
  *
  * <h3>Usage</h3>
  * 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 number> 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 number> 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
index 8b59d1576510e767d888d8cc2600b33fbeda1f12..8f6d671f826eb8957fabfcc2e5db84b7a9533600 100644 (file)
@@ -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
index 8277f35b0f3a3c90191c76dfd4de9f9ec8ed4882..7c7a38f923f562dc79624e50e5d1116f093c1148 100644 (file)
@@ -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 <code>const unsigned int size_of_spectrum</code> tells
  * SLEPc the number of eigenvector/eigenvalue pairs to solve for: See
  * also <code>step-36</code> 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 <typename OutputVector>
   void
   SolverBase::solve (const PETScWrappers::MatrixBase &A,
@@ -72,7 +75,7 @@ DEAL_II_NAMESPACE_OPEN
                      std::vector<OutputVector>       &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
index cb9149e6c296326adf3bf1faa203ca86fb5a0f13..a5a4c9ebd04b2c8872682b95415bb998d354f4ef 100644 (file)
@@ -41,7 +41,7 @@ DEAL_II_NAMESPACE_OPEN
  *
  * <h3>Usage</h3>
  * 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<SparseMatrix<double>, Vector<double> >
  *   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
index 88f2367b4be59b88330cac17a14c891869272163..0989a77bc71c046af8363f0673aa34b86eb29519 100644 (file)
@@ -89,7 +89,7 @@ template <typename number> 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<bool> signature(3);
  *    signature[0] = signature[1] = false;
@@ -109,7 +109,7 @@ template <typename number> class SparseBlockVanka;
  *                        // solve
  *    gmres.solve (global_matrix, solution, right_hand_side,
  *                 vanka);
- * @endverbatim
+ * @endcode
  *
  *
  * <h4>Implementor's remark</h4>
index 40be55fe07f426135b7051f7afea0e3ced9444c2..b1f53d34de6c817d08de43fd411fa0603485a5d2 100644 (file)
@@ -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; i<vector->size(); ++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
index 1b90b3f1956dc6e882df5aae8066399715fb1969..bfbe7ac39e15fe53bdd342431cfbc5718194d9ae 100644 (file)
@@ -69,7 +69,7 @@ template <int dim, int spacedim> class DoFHandler;
  * which is suitable for quadratic finite elements in space, for
  * example.
  *
- * @verbatim
+ * @code
  *   DataOutStack<dim> data_out_stack;
  *
  *                                  // first declare the vectors
@@ -97,7 +97,7 @@ template <int dim, int spacedim> class DoFHandler;
  *       data_out_stack.build_patches (2);
  *       data_out_stack.finish_parameter_value ();
  *     };
- * @endverbatim
+ * @endcode
  *
  * @ingroup output
  * @author Wolfgang Bangerth, 1999
index 46bce989f9fd153bb2a0c7ed3e6b5fdbbaa610b1..443d140306301a0188b559a840a8104ddefeb5e6 100644 (file)
@@ -41,7 +41,7 @@ DEAL_II_NAMESPACE_OPEN
  * <ul>
  * <li> If the grid will only be refined
  * (i.e. no cells are coarsened) then use @p SolutionTransfer as follows:
- * @verbatim
+ * @code
  * SolutionTransfer<dim, double> 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<double> 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<Vector<double> > solutions_old(n_vectors, Vector<double> (n));
  * ...
  * vector<Vector<double> > solutions(n_vectors, Vector<double> (n));
  * soltrans.refine_interpolate(solutions_old, solutions);
- * @endverbatim
+ * @endcode
  * This is used in several of the tutorial programs, for example
  * step-31.
  *
  * <li> If the grid has cells that will be coarsened,
  * then use @p SolutionTransfer as follows:
- * @verbatim
+ * @code
  * SolutionTransfer<dim, Vector<double> > 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<double> interpolate_solution(dof_handler->n_dofs());
  * soltrans.interpolate(solution, interpolated_solution);
- * @endverbatim
+ * @endcode
  *
  * Multiple calls to the function
  * <tt>interpolate (const Vector<number> &in, Vector<number> &out)</tt>
index d9257fd47094d738da7e3ff8b10172f1765a71cf..cf7a73cec9a3c5719bff1068bc30c14dc4d31534 100644 (file)
@@ -186,7 +186,7 @@ template <int dim, int spacedim> 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 <int dim>
  *   void TimeDependent_Wave<dim>::run_sweep (const unsigned int sweep_no)
  *   {
@@ -215,7 +215,7 @@ template <int dim, int spacedim> class Triangulation;
  *     for (unsigned int sweep=0; sweep<number_of_sweeps; ++sweep)
  *       timestep_manager.run_sweep (sweep);
  *   };
- * @endverbatim
+ * @endcode
  * Here, @p timestep_manager is an object of type TimeDependent_Wave(), which
  * is a class derived from TimeDependent. @p start_sweep,
  * @p solve_primal_problem, @p solve_dual_problem, @p postprocess and @p end_sweep
@@ -223,7 +223,7 @@ template <int dim, int spacedim> 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 <int dim, int spacedim> 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 <int dim, int spacedim> class Triangulation;
  * the <tt>C++</tt> 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 <int dim, int spacedim> 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 <int dim, int spacedim> 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 <tt>0..n_timesteps-1</tt>.
- * @verbatim
+ * @code
  *   template <typename InitFunctionObject, typename LoopFunctionObject>
  *   void TimeDependent::do_loop (InitFunctionObject      init_function,
  *                           LoopFunctionObject      loop_function,
@@ -341,7 +341,7 @@ template <int dim, int spacedim> 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<N; ++i)
    *   manager.add_timestep(new MyTimeStep());
-   * @endverbatim
+   * @endcode
    */
   void add_timestep (TimeStepBase *new_timestep);
 

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

Douglas Adams


Typeset in Trocchi and Trocchi Bold Sans Serif.