]> https://gitweb.dealii.org/ - dealii-svn.git/commitdiff
More doc changes for the conversion to kdoc2.
authorwolf <wolf@0785d39b-7218-0410-832d-ea1e28bc413d>
Mon, 26 Jun 2000 14:33:11 +0000 (14:33 +0000)
committerwolf <wolf@0785d39b-7218-0410-832d-ea1e28bc413d>
Mon, 26 Jun 2000 14:33:11 +0000 (14:33 +0000)
git-svn-id: https://svn.dealii.org/trunk@3075 0785d39b-7218-0410-832d-ea1e28bc413d

60 files changed:
deal.II/base/include/base/convergence_table.h
deal.II/base/include/base/data_out_base.h
deal.II/base/include/base/exceptions.h
deal.II/base/include/base/function.h
deal.II/base/include/base/function_time.h
deal.II/base/include/base/logstream.h
deal.II/base/include/base/parameter_handler.h
deal.II/base/include/base/smartpointer.h
deal.II/base/include/base/table_handler.h
deal.II/base/include/base/timer.h
deal.II/base/source/parameter_handler.cc
deal.II/contrib/kdoc/src/kdocHTMLutil.pm
deal.II/deal.II/include/dofs/dof_accessor.h
deal.II/deal.II/include/dofs/dof_constraints.h
deal.II/deal.II/include/dofs/dof_handler.h
deal.II/deal.II/include/dofs/dof_levels.h
deal.II/deal.II/include/dofs/dof_tools.h
deal.II/deal.II/include/fe/fe.h
deal.II/deal.II/include/fe/fe_lib.criss_cross.h
deal.II/deal.II/include/fe/fe_lib.lagrange.h
deal.II/deal.II/include/fe/fe_system.h
deal.II/deal.II/include/fe/fe_values.h
deal.II/deal.II/include/grid/geometry_info.h
deal.II/deal.II/include/grid/grid_generator.h
deal.II/deal.II/include/grid/grid_in.h
deal.II/deal.II/include/grid/grid_out.h
deal.II/deal.II/include/grid/intergrid_map.h
deal.II/deal.II/include/grid/persistent_tria.h
deal.II/deal.II/include/grid/tria.h
deal.II/deal.II/include/grid/tria_accessor.h
deal.II/deal.II/include/grid/tria_boundary.h
deal.II/deal.II/include/grid/tria_boundary_lib.h
deal.II/deal.II/include/grid/tria_iterator.h
deal.II/deal.II/include/grid/tria_levels.h
deal.II/deal.II/include/multigrid/mg_base.h
deal.II/deal.II/include/multigrid/mg_dof_accessor.h
deal.II/deal.II/include/multigrid/mg_dof_handler.h
deal.II/deal.II/include/numerics/assembler.h
deal.II/deal.II/include/numerics/base.h
deal.II/deal.II/include/numerics/data_io.h
deal.II/deal.II/include/numerics/data_out.h
deal.II/deal.II/include/numerics/data_out_stack.h
deal.II/deal.II/include/numerics/error_estimator.h
deal.II/deal.II/include/numerics/histogram.h
deal.II/deal.II/include/numerics/matrices.h
deal.II/deal.II/include/numerics/solution_transfer.h
deal.II/deal.II/include/numerics/time_dependent.h
deal.II/deal.II/include/numerics/vectors.h
deal.II/doc/development/writing-documentation.html
deal.II/lac/include/lac/full_matrix.h
deal.II/lac/include/lac/precondition.h
deal.II/lac/include/lac/precondition_selector.h
deal.II/lac/include/lac/solver.h
deal.II/lac/include/lac/solver_control.h
deal.II/lac/include/lac/solver_selector.h
deal.II/lac/include/lac/sparse_ilu.h
deal.II/lac/include/lac/sparse_matrix.h
deal.II/lac/include/lac/sparse_vanka.h
deal.II/lac/include/lac/sparsity_pattern.h
tests/deal.II/wave-test-3.cc

index 6682431b27dab40dbe1eb802dc8db96b08e0e3e0..e345b938c5af62e4ea28466ed787f1ece0ea16df 100644 (file)
  *
  * There are two possibilities of how to evaluate the convergence rates of multiple 
  * columns in the same @p{RateMode}.
- * \begin{enumerate}
- * \item call @p{evaluate_convergence_rates(data_column_key, ...)} for all wanted columns
- * \item call @p{omit_column_from_convergence_rate_evaluation(data_column_key)} for all
+ * @begin{enumerate}
+ * @item call @p{evaluate_convergence_rates(data_column_key, ...)} for all wanted columns
+ * @item call @p{omit_column_from_convergence_rate_evaluation(data_column_key)} for all
  * NOT wanted columns and then 
  * @p{evaluate_all_convergence_rates(...)} to evaluate the convergence rates of all columns
  * that are not signed to be omitted.
- * \end{enumerate}
+ * @end{enumerate}
  *
  *
  * @author Ralf Hartmann, 1999
index 90908defdca1812555c20dff2ea66ff3a4e63e90..01d7b382f04320571caf987bab6581bda15e45bd 100644 (file)
@@ -128,10 +128,10 @@ class ParameterHandler;
  *
  * Given the lines as described above, a cut through this data in Gnuplot
  * can then be achieved like this:
- * \begin{verbatim}
+ * @begin{verbatim}
  *   set data style lines
  *   splot [:][:][0:] "T" using 1:2:($3==.5 ? $4 : -1)
- * \end{verbatim}
+ * @end{verbatim}
  * This command plots data in x- and y-direction unbounded, but in z-direction
  * only those data points which are above the x-y-plane (we assume here a
  * positive solution, if it has negative values, you might want to decrease the
@@ -156,9 +156,9 @@ class ParameterHandler;
  *
  * The output uses two different povray-objects:
 
- * \begin{itemize}
+ * @begin{itemize}
  *
- * \item @p{BICUBIC_PATCH}
+ * @item @p{BICUBIC_PATCH}
  * A @p{bicubic_patch} is a 3-dimensional Bezier patch. It consists of 16 Points
  * describing the surface. The 4 corner points are touched by the object,
  * while the other 12 points pull and stretch the patch into shape.
@@ -166,7 +166,7 @@ class ParameterHandler;
  * subdivisions has to be 3 to provide the patch with 16 points.
  * A bicubic patch is not exact but generates very smooth images.
  *
- * \item @p{MESH}
+ * @item @p{MESH}
  * The mesh object is used to store large number of triangles.
  * Every square of the patch data is split into one upper-left and one 
  * lower-right triangle. If the number of subdivisions is three, 32 triangle
@@ -174,7 +174,7 @@ class ParameterHandler;
  * 
  * Using the smooth flag povray interpolates the normals on the triangles,
  * imitating a curved surface
- * \end{itemize}
+ * @end{itemize}
  *
  * All objects get one texture definition called Tex. This texture has to be
  * declared somewhere before the object data. This may be in an external 
@@ -186,9 +186,9 @@ class ParameterHandler;
  *
  * You need povray (>=3.0) to render the scene. The minimum options for povray
  * are:
- * \begin{verbatim}
+ * @begin{verbatim}
  *   povray +I<inputfile> +W<horiz. size> +H<ver. size> +L<include path>
- * \end{verbatim}
+ * @end{verbatim}
  * If the external file "data.inc" is used, the path to this file has to be
  * included in the povray options.
  *
@@ -285,7 +285,7 @@ class DataOutBase
                                      * @p{n_subdivision} = 4 because
                                      * the number of cells is
                                      * equal to @p{2^dim}.
-                                     * \begin{verbatim}
+                                     * @begin{verbatim}
                                      *  __ __ __ __
                                      * |  |  |  |  |
                                      * |__|__|__|__| 
@@ -295,7 +295,7 @@ class DataOutBase
                                      * |__|__|__|__| 
                                      * |  |  |  |  |
                                      * |__|__|__|__|
-                                     * \end{verbatim}
+                                     * @end{verbatim}
                                      * @author Wolfgang Bangerth
                                      */
     template <int dim>
@@ -361,7 +361,7 @@ class DataOutBase
                                          * @p{(0, 3, 1,2)} in 2d, and 
                                          * @p{(0, 4, 3, 7, 1, 5, 2, 6)}
                                          * in 3d as following:
-                                         * \begin{verbatim}
+                                         * @begin{verbatim}
                                          *  
                                          *      7________6
                                          *      /       /|
@@ -372,7 +372,7 @@ class DataOutBase
                                          *   |  /    |  /
                                          *   | /     | /
                                          *  0|/______1/
-                                         * \end{verbatim}
+                                         * @end{verbatim}
                                          * 
                                          * For exemple in 2d: If
                                          * @p{subdivisions==2} the
@@ -380,7 +380,7 @@ class DataOutBase
                                          * given by the following
                                          * numeration:
                                          *
-                                         * \begin{verbatim}
+                                         * @begin{verbatim}
                                          *  2 ____5 ____8
                                          *   |     |     |
                                          *   |     |     | 
@@ -390,7 +390,7 @@ class DataOutBase
                                          *   |     |     | 
                                          *   |     |     | 
                                          *  0|____3|____6|
-                                         * \end{verbatim}
+                                         * @end{verbatim}
                                          *
                                          * Since the number of data vectors
                                          * is usually the same for all
@@ -642,7 +642,7 @@ class DataOutBase
                                          * Gnuplot-default of 0 is
                                          * the following:
                                          *
-                                         * \begin{verbatim}
+                                         * @begin{verbatim}
                                          *  
                                          *          3________7
                                          *          /       /|
@@ -654,7 +654,7 @@ class DataOutBase
                                          *       | /     | /
                                          *      1|/______5/
                                          *
-                                         * \end{verbatim}
+                                         * @end{verbatim}
                                          */
        double turn_angle;
 
@@ -1080,7 +1080,7 @@ class DataOutBase
  * presently implemented.
  *
  * Usage is as follows:
- * \begin{verbatim}
+ * @begin{verbatim}
  *                               // within function declaring parameters:
  *   ...
  *   prm.enter_subsection ("Output format options");
@@ -1096,7 +1096,7 @@ class DataOutBase
  *   out.parse_parameters (prm);
  *   prm.leave_subsection ();
  *   ...
- * \end{verbatim}
+ * @end{verbatim}
  * Note that in the present example, the class @p{DataOut} was used. However, any
  * other class derived from @p{DataOut_Interface} would work alike.
  *
@@ -1228,13 +1228,13 @@ class DataOutInterface : private DataOutBase
                                      * suffix with a given output format
                                      * usually has. At present the following
                                      * formats are defined:
-                                     * \begin{itemize}
-                                     * \item @p{ucd}: @p{.inp}
-                                     * \item @p{gnuplot}: @p{.gnuplot}
-                                     * \item @p{povray}: @p{.pov}
-                                     * \item @p{eps}: @p{.eps}
-                                     * \item @p{gmv}: @p{.gmv}.
-                                     * \end{itemize}
+                                     * @begin{itemize}
+                                     * @item @p{ucd}: @p{.inp}
+                                     * @item @p{gnuplot}: @p{.gnuplot}
+                                     * @item @p{povray}: @p{.pov}
+                                     * @item @p{eps}: @p{.eps}
+                                     * @item @p{gmv}: @p{.gmv}.
+                                     * @end{itemize}
                                      *
                                      * If this function is called
                                      * with no argument or @p{default_format}, the
index 86518c706433a6eec10a986e6810c5125a855600..3ebde4735f20a152d5215f9d88b6f4a3e09ad0d5 100644 (file)
@@ -32,7 +32,7 @@
  *  @p{DeclException} macro family.
  *
  *
- *  @sect2{General overview of the exception handling mechanism in @p{deal.II}}
+ *  @sect2{General overview of the exception handling mechanism in deal.II}
  *
  *  The error handling mechanism in @p{deal.II} is generally used in two ways.
  *  The first uses error checking in debug mode only and is useful for programs
  *  Both modes use exception classes, which need to have special features
  *  additionally to the @p{C++} standard's @p{exception} class. Such a class
  *  is declared by the following lines of code:
- *   \begin{verbatim}
+ *   @begin{verbatim}
  *     DeclException2 (ExcDomain, int, int,
  *                     << "Index= " << arg1 << "Upper Bound= " << arg2);
- *  \end{verbatim}
+ *  @end{verbatim}
  *  This declares an exception class named @p{ExcDomain}, which
  *  has two variables as additional information (named
  *  @p{arg1} and @p{arg2} by default) and which outputs the
  *
  *  To use the exception mechanism for debug mode error checking, write lines
  *  like the following in your source code:
- *  \begin{verbatim}
+ *  @begin{verbatim}
  *    Assert (n<dim, ExcDomain(n,dim));
- *  \end{verbatim}
+ *  @end{verbatim}
  *  which by macro expansion does the following:
- *  \begin{verbatim}
+ *  @begin{verbatim}
  *    #ifdef DEBUG
  *        if (!cond)
  *              issue error of class ExcDomain(n,dim)
  *    #else
  *        do nothing
  *    #endif
- *  \end{verbatim}
+ *  @end{verbatim}
  *  i.e. it issues an error only if the preprocessor variable
  *  @p{DEBUG} is set and if the given condition (in this case
  *  @p{n<dim} is violated.
  *  @sect3{How it works internally}
  *  If the @p{DEBUG} preprocessor directive is set, the call @p{Assert (cond, exc);}
  *  is converted by the preprocessor into the sequence
- *  \begin{verbatim}
+ *  @begin{verbatim}
  *    if (!(cond))
  *      __IssueError_Assert (__FILE__,
  *                           __LINE__,
  *                           #cond,
  *                           #exc,
  *                           &exc);
- *  \end{verbatim}
+ *  @end{verbatim}
  *  i.e. if the given condition is violated, then the file and
  *  line in which the exception occured as well as
  *  the condition itself and the call sequence of the
  *  than that the program flow should not have reached a certain point,
  *  e.g. a @p{default} section of a @p{switch} statement. In this case,
  *  raise the exception by the following construct:
- *  \begin{verbatim}
+ *  @begin{verbatim}
  *    Assert (false, ExcInternalError());
- *  \end{verbatim}
+ *  @end{verbatim}
  *
  *
  *  @sect2{Use of run-time exceptions}
  *  For this mode, the standard @p{C++} @p{throw} and @p{catch} concept exists. We
  *  want to keep to this, but want to extend it a bit. In general, the
  *  structure is the same, i.e. you normally raise and exception by
- *  \begin{verbatim}
+ *  @begin{verbatim}
  *    if (!cond)
  *      throw ExcSomething();
- *  \end{verbatim}
+ *  @end{verbatim}
  *  and catch it using the statement
- *  \begin{verbatim}
+ *  @begin{verbatim}
  *    try {
  *      do_something ();
  *    }
  *           << endl;
  *      do_something_to_reciver ();
  *    };
- *  \end{verbatim}
+ *  @end{verbatim}
  *  @p{exception} is a standard @p{C++} class providing basic functionality for
  *  exceptions, such as the virtual function @p{what()} which returns some
  *  information on the exception itself. This information is useful if an
  *  done using the @p{DeclExceptionN} macros, but putting the right information,
  *  which is the same as explained above for the @p{Assert} expansion, requires
  *  some work if one would want to write it down each time:
- *  \begin{verbatim}
+ *  @begin{verbatim}
  *    if (!cond)
  *      {
  *        ExcSomething e(additional information);
  *                     "name of condition as a string");
  *        throw e;
  *      };
- *  \end{verbatim}
+ *  @end{verbatim}
  *
  *  For this purpose, the macro @p{AssertThrow} was invented. It does mainly
  *  the same job as does the @p{Assert} macro, but it does not kill the
  *  program, it rather throws an exception as shown above. The mode of usage
  *  is
- *  \begin{verbatim}
+ *  @begin{verbatim}
  *    AssertThrow (cond, ExcSomething(additional information));
- *  \end{verbatim}
+ *  @end{verbatim}
  *  The condition to be checked is incorporated into the macro in order to
  *  allow passing the violated condition as a string. The expansion of the
  *  @p{AssertThrow} macro is not affected by the @p{DEBUG} preprocessor variable.
  *
  *
- *  @sect2{Description of the @p{DeclExceptionN} macro family}
+ *  @sect2{Description of the DeclExceptionN macro family}
  *
  *  Declare an exception class without any additional parameters.
  *  There is a whole family of @p{DeclException?} macros
  *  parameters (0 to 5 presently).
  *  
  *  The syntax is as follows:
- *  \begin{verbatim}
+ *  @begin{verbatim}
  *    DeclException2 (ExcDomain,
  *                    int,
  *                    int,
  *                    << " i=" << arg1 << ", m=" << arg2);
- *  \end{verbatim}
+ *  @end{verbatim}
  *  The first is the name of the exception class to be created.
  *  The next arguments are the types of the parameters (in this
  *  case there are two type names needed) and finally the output
  *  
  *  The syntax of the output sequence is a bit weird but gets
  *  clear once you see how this macro is defined:
- *  \begin{verbatim}
+ *  @begin{verbatim}
  *  class name : public ExceptionBase {
  *    public:
  *      name (const type1 a1, const type2 a2) :
  *      type1 arg1;
  *      type2 arg2;
  *  };
- *  \end{verbatim}
+ *  @end{verbatim}
  *   
  *  If declared as specified, you can later use this exception class
  *  in the following manner:
- *  \begin{verbatim}
+ *  @begin{verbatim}
  *    int i=5;
  *    int m=3;
  *    Assert (i<m, MyExc2(i,m));
- *  \end{verbatim}
+ *  @end{verbatim}
  *  and the output if the condition fails will be
- *  \begin{verbatim}
+ *  @begin{verbatim}
  *    --------------------------------------------------------
  *    An error occurred in line <301> of file <exc-test.cc>.
  *    The violated condition was: 
  *    Additional Information: 
  *      i=5, m=3
  *    --------------------------------------------------------
- *  \end{verbatim}
+ *  @end{verbatim}
  *  
  *  Obviously for the @p{DeclException0(name)} macro, no types and
  *  also no output sequence is allowed.
@@ -414,14 +414,14 @@ void __IssueError_Throw (const char *file,
 #ifdef DEBUG  ////////////////////////////////////////
 
 /**
- *  This is the main routine in the exception mechanism for debug mode
- *  error checking. See the
- *  @p{ExceptionBase} class for more information.
+ * This is the main routine in the exception mechanism for debug mode
+ * error checking. It assert that a certain condition is fulfilled,
+ * otherwise issues an error and aborts the program.
  *
- *  @memo Assert that a certain condition is fulfilled, otherwise
- *   issue an error and abort the program.
- *  @see ExceptionBase
- *  @author Wolfgang Bangerth, November 1997, extensions 1998
+ * See the @p{ExceptionBase} class for more information.
+ *
+ * @see ExceptionBase
+ * @author Wolfgang Bangerth, November 1997, extensions 1998
  */
 #define Assert(cond, exc)                                         \
   {                                                               \
@@ -440,18 +440,18 @@ void __IssueError_Throw (const char *file,
 
 
 /**
- *  This is the main routine in the exception mechanism for run-time mode
- *  error checking. See the
- *  @p{ExceptionBase} class for more information.
+ * This is the main routine in the exception mechanism for run-time
+ * mode error checking. It assert that a certain condition is
+ * fulfilled, otherwise issues an error and aborts the program.
  *
- *  @memo Assert that a certain condition is fulfilled, otherwise
- *   throw an exception
- *  @see ExceptionBase
- *  @author Wolfgang Bangerth, November 1997, extensions 1998
+ * The configuration parameter NO_THROW can be used to disable this
+ * feature.  This should not be done on a regular basis, but gcc
+ * 2.95.2 on DEC Alpha stops compiling here.
  *
- *  The configuration parameter NO_THROW can be used to disable this feature.
- *  This should not be done on a regular basis, but gcc 2.95.2 on DEC Alpha
- *  stops compiling here.
+ * See the @p{ExceptionBase} class for more information.
+ *
+ * @see ExceptionBase
+ * @author Wolfgang Bangerth, November 1997, extensions 1998
  */
 #ifndef NO_THROW
 #define AssertThrow(cond, exc)                                   \
index 6f801d2709069fa917c13ca6e5901bcedfab06f0..3b5404ec91145d3a0d18aa272083dd051c36334f 100644 (file)
@@ -35,7 +35,7 @@ template<typename number> class Vector;
  *
  * Access to function objects therefore is through the following
  * methods:
- * \begin{verbatim}
+ * @begin{verbatim}
  *                 // access to one component at one point
  *   double value        (const Point<dim>   &p,
  *                        const unsigned int  component = 0) const;
@@ -43,11 +43,11 @@ template<typename number> class Vector;
  *                 // return all components at one point
  *   void   vector_value (const Point<dim>   &p,
  *                        Vector<double>     &value) const;
- * \end{verbatim}
+ * @end{verbatim}
  *
  * For more efficiency, there are other functions returning one or all
  * components at a list of points at once:
- * \begin{verbatim}
+ * @begin{verbatim}
  *                 // access to one component at several points
  *   void   value_list (const vector<Point<dim> >  &point_list,
  *                      vector<double>             &value_list,
@@ -56,7 +56,7 @@ template<typename number> class Vector;
  *                 // return all components at several points
  *   void   vector_value_list (const vector<Point<dim> >    &point_list,
  *                             vector<Vector<double> >      &value_list) const;
- * \end{verbatim}
+ * @end{verbatim}
  *
  * Furthermore, there are functions returning the gradient of the
  * function at one or several points.
@@ -87,7 +87,7 @@ template<typename number> class Vector;
  * Support for time dependant functions can be found in the base
  * class @p{FunctionTime}.
  *
- * {\bf Note}: if the functions you are dealing with have sizes which
+ * @em{Note}: if the functions you are dealing with have sizes which
  * are a priori known (for example, @p{dim} elements), you might
  * consider using the @p{TensorFunction} class instead.
  *
index 0e1254c9a1b58c9ff83ca39e12d86e7f41d8f1c8..e126e909029303260b4a28c27543de355cc710e8 100644 (file)
  *  for time dependent problems.
  *
  *  Access to the time goes through the following functions:
- *  \begin{verbatim}
- *  \item @p{get_time}: return the present value of the time variable.
- *  \item @p{set_time}: set the time value to a specific value.
- *  \item @p{advance_time}: increase the time by a certain time step.
- *  \end{verbatim}
+ *  @begin{verbatim}
+ *  @item @p{get_time}: return the present value of the time variable.
+ *  @item @p{set_time}: set the time value to a specific value.
+ *  @item @p{advance_time}: increase the time by a certain time step.
+ *  @end{verbatim}
  *  The latter two functions are virtual, so that derived classes can
  *  perform computations which need only be done once for every new time.
  *  For example, if a time dependent function had a factor @p{sin(t)}, then
index 31dd87ca0ab1b9136e0eff6b24e5a2b55d8a243c..370d3df0a711515f443445a1af0b6fc395a36db3 100644 (file)
 /**
  * A class that simplifies the process of execution logging. It does so by
  * providing
- * \begin{itemize}
- * \item a push and pop mechanism for prefixes, and
- * \item the possibility of distributing information to files and the
+ * @begin{itemize}
+ * @item a push and pop mechanism for prefixes, and
+ * @item the possibility of distributing information to files and the
  *   console.
- * \end{itemize}
+ * @end{itemize}
  *
  * The usual usage of this class is through the pregenerated object
  * @p{deallog}. Typical steps are
index f4ae625853d386fbb46aea0186a21ffb9761d0ef..7b3fd040d1d5c6d815436c285d04100d0eac49a9 100644 (file)
@@ -40,19 +40,21 @@ enum OutputStyle {
  * Declare some regexps which
  * may be used to define patterns.
  */ 
-struct Patterns {
+struct Patterns
+{
   public:
                                     /**
                                      * Base class to declare common
                                      * interface.
                                      */
-    class PatternBase {
+    class PatternBase
+    {
       public:
                                         /**
                                          * Make destructor of this and all
                                          * derived classes virtual.
                                          */
-       virtual ~PatternBase () {};
+       virtual ~PatternBase ();
        
                                         /**
                                          * Return true if the given string
@@ -80,7 +82,8 @@ struct Patterns {
                                      * Test for the string being an
                                      * integer.
                                      */
-    class Integer : public PatternBase {
+    class Integer : public PatternBase
+    {
       public:
        virtual bool match (const string &test_string) const;
        virtual string description () const;
@@ -90,7 +93,8 @@ struct Patterns {
                                     /**
                                      * Test for the string being a double.
                                      */
-    class Double : public PatternBase {
+    class Double : public PatternBase
+    {
       public:
        virtual bool match (const string &test_string) const;
        virtual string description () const;
@@ -109,7 +113,8 @@ struct Patterns {
                                      * signs do not matter and are
                                      * eliminated.
                                      */
-    class Selection : public PatternBase {
+    class Selection : public PatternBase
+    {
       public:
        Selection (const string &seq);
        virtual bool match (const string &test_string) const;
@@ -134,7 +139,8 @@ struct Patterns {
                                      * However, commas are not allowed inside
                                      * the values given to the constructor.
                                      */
-    class MultipleSelection : public PatternBase {
+    class MultipleSelection : public PatternBase
+    {
       public:
        MultipleSelection (const string &seq);
        virtual bool match (const string &test_string) const;
@@ -155,7 +161,8 @@ struct Patterns {
                                      * "true" or "false". This is mapped
                                      * to the @p{Selection} class.
                                      */
-    class Bool : public Selection {
+    class Bool : public Selection
+    {
       public:
        Bool ();
        virtual PatternBase * clone () const;
@@ -165,7 +172,8 @@ struct Patterns {
                                      * Always returns true when testing a
                                      * string.
                                      */
-    class Anything : public PatternBase {
+    class Anything : public PatternBase
+    {
       public:
                                         /**
                                          * Allow for at least one non-virtual
@@ -186,10 +194,10 @@ struct Patterns {
  *   which provides at run-time for program parameters such as time step sizes,
  *   geometries, right hand sides etc. The input for the program is given in files,
  *   streams or strings in memory using text like
- *   \begin{verbatim}
+ *   @begin{verbatim}
  *     set Time step size = 0.3
  *     set Geometry       = [0,1]x[0,3]
- *   \end{verbatim}
+ *   @end{verbatim}
  *   Input may be sorted into subsection trees in order to give the input a logical
  *   structure.
  *
@@ -199,7 +207,7 @@ struct Patterns {
  *   In order to use the facilities of a @p{ParameterHandler} object, one first has
  *   to make known the different entries the input file may or may not contain. This
  *   is done in the following way:
- *   \begin{verbatim}
+ *   @begin{verbatim}
  *     ...
  *     ParameterHandler prm;
  *     prm.declare_entry ("Time step size",
@@ -209,7 +217,7 @@ struct Patterns {
  *                       "[0,1]x[0,1]",
  *                       Patterns::Anything());
  *     ...
- *   \end{verbatim}
+ *   @end{verbatim}
  *   Each entry is declared using the function @p{declare_entry}. The first parameter is
  *   the name of the entry (in short: the entry). The second is the default answer to
  *   be taken in case the entry is not specified in the input file. The third parameter
@@ -220,7 +228,7 @@ struct Patterns {
  *   input parameters for linear solver routines should be classified in a subsection
  *   named @p{Linear solver} or any other suitable name. This is accomplished in the
  *   following way:
- *   \begin{verbatim}
+ *   @begin{verbatim}
  *     ...
  *       LinEq eq;
  *       eq.declare_parameters (prm);
@@ -237,12 +245,12 @@ struct Patterns {
  *       ...
  *       prm.leave_subsection ();
  *     };
- *   \end{verbatim}
+ *   @end{verbatim}
  *
  *   Subsections may be nested. For example a nonlinear solver may have a linear solver
  *   as member object. Then the function call tree would be something like (if the class
  *   @p{NonLinEq} has a member variables @p{eq} of type @p{LinEq}):
- *   \begin{verbatim}
+ *   @begin{verbatim}
  *     void NonLinEq::declare_parameters (ParameterHandler &prm) {
  *       prm.enter_subsection ("Nonlinear solver");
  *       prm.declare_entry ("Nonlinear method",
@@ -251,7 +259,7 @@ struct Patterns {
  *       eq.declare_parameters (prm);
  *       prm.leave_subsection ();
  *     };
- *   \end{verbatim}
+ *   @end{verbatim}
  *
  *   For class member functions which declare the different entries we propose to use the
  *   common name @p{declare_parameters}. In normal cases this method can be @p{static} since the
@@ -260,7 +268,7 @@ struct Patterns {
  *   a class has two or more member variables of the same type both of which should have
  *   their own parameters, this parent class' method @p{declare_parameters} is responsible to
  *   group them into different subsections:
- *   \begin{verbatim}
+ *   @begin{verbatim}
  *     void NonLinEq::declare_parameters (ParameterHandler &prm) {
  *       prm.enter_subsection ("Nonlinear solver");
  *       prm.enter_subsection ("Linear solver 1");
@@ -272,13 +280,13 @@ struct Patterns {
  *       prm.leave_subsection ();
  *       prm.leave_subsection ();
  *     };      
- *   \end{verbatim}
+ *   @end{verbatim}
  *
  *
  *   @sect3{Input files and special characters}
  *
  *   For the first example above the input file would look like the following:
- *   \begin{verbatim}
+ *   @begin{verbatim}
  *     ...
  *     subsection Nonlinear solver
  *       set Nonlinear method = Gradient
@@ -288,14 +296,14 @@ struct Patterns {
  *       end
  *     end
  *     ...                       # other stuff
- *   \end{verbatim}
+ *   @end{verbatim}
  *   The words @p{subsection}, @p{set} and @p{end} may be either written in lowercase or uppercase
  *   letters. Leading and trailing whitespace is removed, multiple whitespace is condensed into
  *   only one. Since the latter applies also to the name of an entry, an entry name will not
  *   be recognised if in the declaration multiple whitespace is used.
  *
  *   In entry names and values the following characters are not allowed: @p{#}, @p{\{}, 
- *   @p{\}}, @p{|}. Their use is reserved for the \ref{MultipleParameterLoop} class.
+ *   @p{\}}, @p{|}. Their use is reserved for the @ref{MultipleParameterLoop} class.
  *   
  *   Comments starting with \# are skipped.
  *   
@@ -310,7 +318,7 @@ struct Patterns {
  *   In order to read input you can use three possibilities: reading from an @p{istream} object,
  *   reading from a file of which the name is given and reading from a string in memory in
  *   which the lines are separated by @p{\n} characters. These possibilites are used as follows:
- *   \begin{verbatim}
+ *   @begin{verbatim}
  *     ParameterHandler prm;
  *     ...
  *     // declaration of entries
@@ -322,7 +330,7 @@ struct Patterns {
  *     char *in = "set Time step size = 0.3 \n ...";
  *     prm.read_input (in);
  *     ...
- *   \end{verbatim}
+ *   @end{verbatim}
  *   You can use several sources of input successively. Entries which are changed more than
  *   once will be overwritten everytime they are used. It is suggested to let the name of
  *   parameter input end in @p{.prm}.
@@ -338,14 +346,14 @@ struct Patterns {
  *   
  *   Each class gets its data out of a @p{ParameterHandler} object by calling the @p{get (...)}
  *   member functions like this:
- *   \begin{verbatim}
+ *   @begin{verbatim}
  *      void NonLinEq::get_parameters (ParameterHandler &prm) {
  *       prm.enter_subsection ("Nonlinear solver");
  *       string method = prm.get ("Nonlinear method");
  *       eq.get_parameters (prm);
  *       prm.leave_subsection ();
  *     };
- *   \end{verbatim}
+ *   @end{verbatim}
  *   @p{get()} returns the value of the given entry. If the entry was not specified in the input
  *   source(s), the default value is returned. You have to enter and leave subsections
  *   exactly as you did when declaring subsection. You may chose the order in which to
@@ -396,19 +404,19 @@ struct Patterns {
  *
  *   @sect3{Possible future extensions}
  *   
- *   \begin{itemize}
- *   \item Allow long input lines to be broken by appending a backslash character
+ *   @begin{itemize}
+ *   @item Allow long input lines to be broken by appending a backslash character
  *     (just like C macros and shell input).
- *   \item Provide an @p{input filename} command for the input file to enable users to put the
+ *   @item Provide an @p{input filename} command for the input file to enable users to put the
  *     most common parameters into separate files.
- *   \end{itemize}  
+ *   @end{itemize}  
  *
  *
  *   
  *   @sect3{Worked Example}
  *
  *   This is the code:
- *   \begin{verbatim}
+ *   @begin{verbatim}
  *     #include <iostream>
  *     #include "../include/parameter_handler.h"
  *     
@@ -539,11 +547,11 @@ struct Patterns {
  *            << "Getting parameters:" << endl;
  *       p.get_parameters (prm);
  *     };
- *   \end{verbatim}
+ *   @end{verbatim}
  *
  *   
  *   This is the input file (named "prmtest.prm"):
- *   \begin{verbatim}
+ *   @begin{verbatim}
  *                                 # first declare the types of equations
  *     set Equation 1 = Poisson
  *     set Equation 2 = Navier-Stokes
@@ -563,10 +571,10 @@ struct Patterns {
  *         set Maximum number of iterations = 100
  *       end
  *     end
- *   \end{verbatim}
+ *   @end{verbatim}
  *
  *   And here is the ouput of the program:
- *   \begin{verbatim}
+ *   @begin{verbatim}
  *     Line 8:
  *         The entry value
  *             Gauss-Seidel
@@ -603,17 +611,13 @@ struct Patterns {
  *       Problem: outfile=out
  *                eq1=Poisson, eq2=Navier-Stokes
  *                Matrix1=Sparse, Matrix2=Full
- *   \end{verbatim}
+ *   @end{verbatim}
  *
  *   
  *   @sect3{References}
  *
  *   This class is inspired by the @p{MenuSystem} class of @p{DiffPack}.
  *
- *   @memo  This class provides a standard interface to an input file
- *   which provides at run-time for program parameters such as time step sizes,
- *   geometries, right hand sides etc.
- *   
  *   @author Wolfgang Bangerth, October 1997, revised February 1998
  *   @see MultipleParameterLoop
  */
@@ -892,24 +896,24 @@ class ParameterHandler
  *   variant entry values and performs a loop over all combinations of parameters.
  *
  *   Variant entry values are given like this:
- *   \begin{verbatim}
+ *   @begin{verbatim}
  *     set Time step size = { 0.1 | 0.2 | 0.3 }
- *   \end{verbatim}
+ *   @end{verbatim}
  *   The loop will then perform three runs of the program, one for each value
  *   of @p{Time step size}, while all other parameters are as specified or with their
  *   default value. If there are several variant entry values in the input a loop is
  *   performed for each combination of variant values:
- *   \begin{verbatim}
+ *   @begin{verbatim}
  *     set Time step size = { 0.1 | 0.2 }
  *     set Solver         = { CG  | GMRES }
- *   \end{verbatim}
+ *   @end{verbatim}
  *   will result in four runs of the programs, with time step 0.1 and 0.2 for each
  *   of the two solvers.
  *
  *   Opposite to a variant entry, an array entry looks like this:
- *   \begin{verbatim}
+ *   @begin{verbatim}
  *     set Output file = ofile.{{ 1 | 2 | 3 | 4 }}
- *   \end{verbatim}
+ *   @end{verbatim}
  *   This indicates that if there are variant entries producing a total of four
  *   different runs will write their results to the files @p{ofile.1}, @p{ofile.2},
  *   @p{ofile.3} and @p{ofile.4}, respectively. Array entries do not generate multiple
@@ -937,7 +941,7 @@ class ParameterHandler
  *   the different parameter sets are set, a new instance of a user class is created
  *   which is then called. Taking the classes of the example for the
  *   @p{ParameterHandler} class, the extended program would look like this:
- *   \begin{verbatim}
+ *   @begin{verbatim}
  *     class HelperClass : public MultipleParameterLoop::UserClass {
  *       public:
  *         HelperClass ();
@@ -983,7 +987,7 @@ class ParameterHandler
  *       prm.read_input ("prmtest.prm");
  *       prm.loop (h);
  *     };    
- *   \end{verbatim}
+ *   @end{verbatim}
  *         
  *   As can be seen, first a new helper class has to be set up. This must contain
  *   a virtual constructor for a problem class. You can also derive your problem
@@ -1005,7 +1009,7 @@ class ParameterHandler
  *   @p{MultipleParameterLoop} class, the entries have to be declared in the same way
  *   as for the @p{ParameterHandler} class. Then the input has to be read. Finally
  *   the loop is called. This executes the following steps:
- *   \begin{verbatim}
+ *   @begin{verbatim}
  *     for each combination
  *       {
  *         UserObject.create_new (runNo);
@@ -1014,7 +1018,7 @@ class ParameterHandler
  *  
  *         UserObject.run (*this);
  *       };
- *   \end{verbatim}
+ *   @end{verbatim}
  *   @p{UserObject} is the parameter to the @p{loop} function. @p{create_new} is given the number
  *   of the run (starting from one) to enable naming output files differently for each
  *   run.
@@ -1037,7 +1041,7 @@ class ParameterHandler
  *   
  *   Given the above extensions to the example program for the @p{ParameterHandler} and the
  *   following input file
- *   \begin{verbatim}
+ *   @begin{verbatim}
  *     set Equation 1 = Poisson
  *     set Equation 2 = Navier-Stokes
  *     set Output file= results.{{ 1 | 2 | 3 | 4 | 5 | 6 }}
@@ -1057,9 +1061,9 @@ class ParameterHandler
  *         set Maximum number of iterations = 100
  *       end
  *     end
- *   \end{verbatim}
+ *   @end{verbatim}
  *   this is the output:
- *   \begin{verbatim}
+ *   @begin{verbatim}
  *     LinEq: Method=CG, MaxIterations=10
  *     LinEq: Method=BiCGStab, MaxIterations=100
  *     Problem: outfile=results.1
@@ -1090,7 +1094,7 @@ class ParameterHandler
  *     Problem: outfile=results.6
  *              eq1=Poisson, eq2=Navier-Stokes
  *              Matrix1=Sparse, Matrix2=Full
- *   \end{verbatim}
+ *   @end{verbatim}
  *   Since @p{create_new} gets the number of the run it would also be possible to output
  *   the number of the run.
  *   
@@ -1098,15 +1102,12 @@ class ParameterHandler
  *   @sect3{References}
  *   This class is inspired by the @p{Multipleloop} class of @p{DiffPack}.
  *
- *   @memo  This class provides an interface to an input file which provides at
- *   run-time for multiple program parameters sets. The class performs a loop over
- *   all combinations of parameter sets.
- *   
  *   @author Wolfgang Bangerth, October 1997
  *   @version 1.0
  *   @see ParameterHandler
  */
-class MultipleParameterLoop : public ParameterHandler {
+class MultipleParameterLoop : public ParameterHandler
+{
   public:
                                     /**
                                      * This is the class the helper class or the
index 4f2a5d68e5b16673c3b3ea84c9720042eee0cdb5..59b1da370e0d433050903d6109ef00021979b459 100644 (file)
  *
  * @p{SmartPointer} does NOT implement any memory handling! Especially,
  * deleting a @p{SmartPointer} does not delete the object. Writing
- * \begin{verbatim}
+ * @begin{verbatim}
  * SmartPointer<T> t = new T;
- * \end{verbatim}
+ * @end{verbatim}
  * is a sure way to program a memory leak! The secure version is
- * \begin{verbatim}
+ * @begin{verbatim}
  * T* p = new T;
  * {
  *   SmartPointer<T> t = p;
  *   ...
  * }
  * delete p;
- * \end{verbatim}
+ * @end{verbatim}
  *
  * Note that a smart pointer can handle @p{const}ness of an object, i.e.
  * a @p{SmartPointer<const ABC>} really behaves as if it were a pointer to
index 481e3c4ee85c10bdb746847c148577fac215b86b..9552beae6674e778ee842d41d5b0b469b71b4a32 100644 (file)
@@ -133,7 +133,7 @@ class TableEntry : public TableEntryBase
  * aligned to the right (the default was @p{centered}) and the precision of
  * the square roots are set to be 6 (instead of 4 as default).
  *
- * \begin{verbatim}
+ * @begin{verbatim}
  * TableHandler table();
  *
  * for (unsigned int i=1; i<=n; ++i)
@@ -154,7 +154,7 @@ class TableEntry : public TableEntryBase
  * ofstream out_file("number_table.tex");
  * table.write_tex(out_file);
  * out_file.close();
- * \end{verbatim}
+ * @end{verbatim}
  *
  * @author Ralf Hartmann, 1999
  */
index a160d1c5767509b20e854507a715edb05f6a1ffb..2e9691d37fb0c49613452e69c6bf3152fa2fb630 100644 (file)
@@ -26,7 +26,7 @@
  *
  * Use of this class is as you might expect by looking at the member
  * functions:
- * \begin{verbatim}
+ * @begin{verbatim}
  *   Time timer;
  *   timer.start ();
  *
@@ -39,7 +39,7 @@
  *
  *   // reset timer for the next thing it shall do
  *   timer.reset();
- * \end{verbatim}
+ * @end{verbatim}
  *
  * Alternatively, you can also restart the timer instead of resetting
  * it. The times between successive calls to @p{start/stop} will then be
index a7daf6b6fc702c58a9cc702b17cb2b01b5a9f02c..9c307444dabd3c8bf43c2b48be5eaf994047899a 100644 (file)
 #include <list>
 
 
-bool Patterns::Integer::match (const string &test_string) const {
+
+Patterns::PatternBase::~PatternBase ()
+{};
+
+
+
+bool Patterns::Integer::match (const string &test_string) const
+{
   istrstream str(test_string.c_str());
   int i;
   if (str >> i) return true;
@@ -29,18 +36,24 @@ bool Patterns::Integer::match (const string &test_string) const {
 };
 
 
-string Patterns::Integer::description () const {
+
+string Patterns::Integer::description () const
+{
   return "[Integer]";
 };
 
 
+
 Patterns::PatternBase *
-Patterns::Integer::clone () const {
+Patterns::Integer::clone () const
+{
   return new Patterns::Integer();
 };
 
 
-bool Patterns::Double::match (const string &test_string) const {
+
+bool Patterns::Double::match (const string &test_string) const
+{
   istrstream str(test_string.c_str());
   double d;
   if (str >> d) return true;
@@ -48,7 +61,9 @@ bool Patterns::Double::match (const string &test_string) const {
 };
 
 
-string Patterns::Double::description () const {
+
+string Patterns::Double::description () const
+{
   return "[Integer]";
 };
 
@@ -59,7 +74,9 @@ Patterns::Double::clone () const {
 };
 
 
-Patterns::Selection::Selection (const string &seq) {
+
+Patterns::Selection::Selection (const string &seq)
+{
   sequence = seq;
 
   while (sequence.find(" |") != string::npos)
@@ -69,7 +86,9 @@ Patterns::Selection::Selection (const string &seq) {
 };
 
 
-bool Patterns::Selection::match (const string &test_string) const {
+
+bool Patterns::Selection::match (const string &test_string) const
+{
   vector<string> choices;
   string tmp(sequence);
                                   // check the different possibilities
@@ -89,18 +108,24 @@ bool Patterns::Selection::match (const string &test_string) const {
 };
 
 
-string Patterns::Selection::description () const {
+
+string Patterns::Selection::description () const
+{
   return sequence;
 };
 
 
+
 Patterns::PatternBase *
-Patterns::Selection::clone () const {
+Patterns::Selection::clone () const
+{
   return new Patterns::Selection(sequence);
 };
 
 
-Patterns::MultipleSelection::MultipleSelection (const string &seq) {
+
+Patterns::MultipleSelection::MultipleSelection (const string &seq)
+{
   Assert (seq.find (",") == string::npos, ExcCommasNotAllowed(seq.find(",")));
   
   sequence = seq;
@@ -111,7 +136,9 @@ Patterns::MultipleSelection::MultipleSelection (const string &seq) {
 };
 
 
-bool Patterns::MultipleSelection::match (const string &test_string_list) const {
+
+bool Patterns::MultipleSelection::match (const string &test_string_list) const
+{
   string tmp = test_string_list;
   list<string> split_list;
 
@@ -139,7 +166,7 @@ bool Patterns::MultipleSelection::match (const string &test_string_list) const {
     };
 
 
-// check the different possibilities
+                                  // check the different possibilities
   for (list<string>::const_iterator test_string = split_list.begin();
        test_string != split_list.end(); ++test_string) 
     {
@@ -173,56 +200,75 @@ bool Patterns::MultipleSelection::match (const string &test_string_list) const {
 };
 
 
-string Patterns::MultipleSelection::description () const {
+
+string Patterns::MultipleSelection::description () const
+{
   return sequence;
 };
 
 
+
 Patterns::PatternBase *
-Patterns::MultipleSelection::clone () const {
+Patterns::MultipleSelection::clone () const
+{
   return new Patterns::MultipleSelection(sequence);
 };
 
 
+
 Patterns::Bool::Bool () :
                Selection ("true|false")
 {};
 
 
+
 Patterns::PatternBase *
-Patterns::Bool::clone () const {
+Patterns::Bool::clone () const
+{
   return new Patterns::Bool();
 };
 
 
+
 Patterns::Anything::Anything ()
 {};
 
 
-bool Patterns::Anything::match (const string &) const {
+
+bool Patterns::Anything::match (const string &) const
+{
   return true;
 };
 
 
-string Patterns::Anything::description () const {
+
+string Patterns::Anything::description () const
+{
   return "[Anything]";
 };
 
 
+
 Patterns::PatternBase *
-Patterns::Anything::clone () const {
+Patterns::Anything::clone () const
+{
   return new Patterns::Anything();
 };
 
 
+
 ParameterHandler::ParameterHandler () :
                status(true) {};
 
 
-ParameterHandler::~ParameterHandler () {};
+
+ParameterHandler::~ParameterHandler ()
+{};
+
 
 
-bool ParameterHandler::read_input (istream &input) {
+bool ParameterHandler::read_input (istream &input)
+{
   AssertThrow (input, ExcIO());
 
   string line;
@@ -239,6 +285,7 @@ bool ParameterHandler::read_input (istream &input) {
 };
 
 
+
 bool ParameterHandler::read_input (const string &filename)
 {
   ifstream input (filename.c_str());
@@ -262,7 +309,9 @@ bool ParameterHandler::read_input (const string &filename)
 }
 
 
-bool ParameterHandler::read_input_from_string (const char *s) {
+
+bool ParameterHandler::read_input_from_string (const char *s)
+{
                                   // if empty string then exit
                                   // with success
   if ((s == 0) || ((*s) == 0)) return true;
@@ -293,7 +342,9 @@ bool ParameterHandler::read_input_from_string (const char *s) {
 };
 
 
-void ParameterHandler::clear () {
+
+void ParameterHandler::clear ()
+{
   status = true;
 
   subsection_path.clear ();
@@ -316,9 +367,11 @@ void ParameterHandler::clear () {
 };
 
 
+
 bool ParameterHandler::declare_entry (const string &entry,
                                      const string &default_value,
-                                     const Patterns::PatternBase &pattern) {
+                                     const Patterns::PatternBase &pattern)
+{
   Section* p = get_present_defaults_subsection ();
 
                                   // assertions:
@@ -344,7 +397,9 @@ bool ParameterHandler::declare_entry (const string &entry,
 };
 
 
-void ParameterHandler::enter_subsection (const string &subsection) {
+
+void ParameterHandler::enter_subsection (const string &subsection)
+{
   Section* pd = get_present_defaults_subsection ();
 
                                   // does subsection already exist?
@@ -364,7 +419,9 @@ void ParameterHandler::enter_subsection (const string &subsection) {
 };
 
 
-bool ParameterHandler::leave_subsection () {
+
+bool ParameterHandler::leave_subsection ()
+{
                                   // assert there is a subsection that
                                   // we may leave
                                   // (use assert since this is a logical
@@ -381,7 +438,9 @@ bool ParameterHandler::leave_subsection () {
 };
 
 
-const string & ParameterHandler::get (const string &entry_string) const {
+
+const string & ParameterHandler::get (const string &entry_string) const
+{
   const Section* pd = get_present_defaults_subsection ();
   const Section* pc = get_present_changed_subsection ();
 
@@ -410,7 +469,9 @@ const string & ParameterHandler::get (const string &entry_string) const {
 };
 
 
-long int ParameterHandler::get_integer (const string &entry_string) const {
+
+long int ParameterHandler::get_integer (const string &entry_string) const
+{
   string s = get (entry_string);
   char *endptr;
   long int i = strtol (s.c_str(), &endptr, 10);
@@ -422,7 +483,9 @@ long int ParameterHandler::get_integer (const string &entry_string) const {
 };
 
 
-double ParameterHandler::get_double (const string &entry_string) const {
+
+double ParameterHandler::get_double (const string &entry_string) const
+{
   string s = get (entry_string);
   char *endptr;
   double d = strtod (s.c_str(), &endptr);
@@ -434,7 +497,9 @@ double ParameterHandler::get_double (const string &entry_string) const {
 };
 
 
-bool ParameterHandler::get_bool (const string &entry_string) const {
+
+bool ParameterHandler::get_bool (const string &entry_string) const
+{
   string s = get(entry_string);
 
   AssertThrow ((s=="true") || (s=="false"), ExcConversionError(s));
@@ -445,7 +510,9 @@ bool ParameterHandler::get_bool (const string &entry_string) const {
 };
 
 
-ostream & ParameterHandler::print_parameters (ostream &out, OutputStyle style) {
+
+ostream & ParameterHandler::print_parameters (ostream &out, OutputStyle style)
+{
                                   // assert that only known formats are
                                   // given as "style"
   Assert ((style == Text) || (style == LaTeX), ExcNotImplemented());
@@ -486,9 +553,11 @@ ostream & ParameterHandler::print_parameters (ostream &out, OutputStyle style) {
 };
 
 
+
 void ParameterHandler::print_parameters_section (ostream           &out,
                                                 const OutputStyle  style,
-                                                const unsigned int indent_level) {
+                                                const unsigned int indent_level)
+{
                                   // assert that only known formats are
                                   // given as "style"
   Assert ((style == Text) || (style == LaTeX), ExcNotImplemented());
@@ -560,7 +629,7 @@ void ParameterHandler::print_parameters_section (ostream           &out,
     };
 
 
-// now transverse subsections tree
+                                  // now transverse subsections tree
   map<string, Section*>::const_iterator ptrss;
   for (ptrss = pd->subsections.begin(); ptrss != pd->subsections.end(); ++ptrss)
     {
@@ -611,7 +680,10 @@ void ParameterHandler::print_parameters_section (ostream           &out,
 };
 
 
-bool ParameterHandler::scan_line (string line, const unsigned int lineno) {
+
+bool ParameterHandler::scan_line (string line,
+                                 const unsigned int lineno)
+{
                                   // if there is a comment, delete it
   if (line.find('#') != string::npos)
     line.erase (line.find("#"), string::npos);
@@ -741,7 +813,9 @@ bool ParameterHandler::scan_line (string line, const unsigned int lineno) {
 };
 
 
-ParameterHandler::Section* ParameterHandler::get_present_defaults_subsection () {
+
+ParameterHandler::Section* ParameterHandler::get_present_defaults_subsection ()
+{
   Section* sec = &defaults;
   vector<string>::const_iterator SecName = subsection_path.begin();
     
@@ -755,7 +829,9 @@ ParameterHandler::Section* ParameterHandler::get_present_defaults_subsection ()
 };
 
 
-const ParameterHandler::Section* ParameterHandler::get_present_defaults_subsection () const {
+
+const ParameterHandler::Section* ParameterHandler::get_present_defaults_subsection () const
+{
   Section* sec = const_cast<Section*>(&defaults); // not nice, but needs to be and
                                   // after all: we do not change @p{sec}
   vector<string>::const_iterator SecName = subsection_path.begin();
@@ -770,7 +846,9 @@ const ParameterHandler::Section* ParameterHandler::get_present_defaults_subsecti
 };
 
 
-ParameterHandler::Section* ParameterHandler::get_present_changed_subsection () {
+
+ParameterHandler::Section* ParameterHandler::get_present_changed_subsection ()
+{
   Section* sec = &changed_entries;
   vector<string>::iterator SecName = subsection_path.begin();
     
@@ -784,7 +862,9 @@ ParameterHandler::Section* ParameterHandler::get_present_changed_subsection () {
 };
 
 
-const ParameterHandler::Section* ParameterHandler::get_present_changed_subsection () const {
+
+const ParameterHandler::Section* ParameterHandler::get_present_changed_subsection () const
+{
   Section* sec = const_cast<Section*>(&changed_entries); // same as in get_present_default_s...
   vector<string>::const_iterator SecName = subsection_path.begin();
     
@@ -811,14 +891,20 @@ subsections.clear ();
 };
 
 
+
 MultipleParameterLoop::MultipleParameterLoop() :
-               n_branches(0) {};
+               n_branches(0)
+{};
 
 
-MultipleParameterLoop::~MultipleParameterLoop () {};
 
+MultipleParameterLoop::~MultipleParameterLoop ()
+{};
 
-bool MultipleParameterLoop::read_input (istream &input) {
+
+
+bool MultipleParameterLoop::read_input (istream &input)
+{
   AssertThrow (input, ExcIO());
 
   bool x = ParameterHandler::read_input (input);
@@ -828,6 +914,7 @@ bool MultipleParameterLoop::read_input (istream &input) {
 };
 
 
+
 bool MultipleParameterLoop::read_input (const string &filename)
 {
   return ParameterHandler::read_input (filename);
@@ -838,14 +925,18 @@ bool MultipleParameterLoop::read_input (const string &filename)
 };
 
 
-bool MultipleParameterLoop::read_input_from_string (const char *s) {
+
+bool MultipleParameterLoop::read_input_from_string (const char *s)
+{
   bool x = ParameterHandler::read_input (s);
   init_branches ();
   return x;
 };
 
 
-void MultipleParameterLoop::loop (MultipleParameterLoop::UserClass &uc) {
+
+void MultipleParameterLoop::loop (MultipleParameterLoop::UserClass &uc)
+{
   for (int run_no=0; run_no<n_branches; ++run_no) 
     {
                                       // give create_new one-based numbers
@@ -856,7 +947,9 @@ void MultipleParameterLoop::loop (MultipleParameterLoop::UserClass &uc) {
 };
 
 
-void MultipleParameterLoop::init_branches () {
+
+void MultipleParameterLoop::init_branches ()
+{
   multiple_choices.clear ();
   
   ParameterHandler::Section *sec;
@@ -902,7 +995,7 @@ void MultipleParameterLoop::init_branches () {
             << "        " << n_branches << " variant runs that will be performed." << endl;
 
 
-// do a first run on filling the values to
+                                  // do a first run on filling the values to
                                   // check for the conformance with the regexp
                                   // (afterwards, this will be lost in the whole
                                   // other output)
@@ -911,7 +1004,9 @@ void MultipleParameterLoop::init_branches () {
 };
 
 
-void MultipleParameterLoop::init_branches_section (const ParameterHandler::Section &sec) {
+
+void MultipleParameterLoop::init_branches_section (const ParameterHandler::Section &sec)
+{
                                   // check all entries in the present subsection
                                   // whether it is a multiple entry
   Section::EntryType::const_iterator e;
@@ -922,7 +1017,7 @@ void MultipleParameterLoop::init_branches_section (const ParameterHandler::Secti
                                        e->second.first));
 
 
-// transverse subsections
+                                  // transverse subsections
   map<string, Section*>::const_iterator s;
   for (s = sec.subsections.begin(); s != sec.subsections.end(); ++s) 
     {
@@ -933,7 +1028,9 @@ void MultipleParameterLoop::init_branches_section (const ParameterHandler::Secti
 };
 
 
-void MultipleParameterLoop::fill_entry_values (const unsigned int run_no) {
+
+void MultipleParameterLoop::fill_entry_values (const unsigned int run_no)
+{
   int possibilities = 1;
   
   vector<Entry>::iterator choice;
@@ -1002,13 +1099,17 @@ void MultipleParameterLoop::fill_entry_values (const unsigned int run_no) {
 };
 
 
+
 MultipleParameterLoop::Entry::Entry (const vector<string> &ssp,
                                     const string& Name,
                                     const string& Value) :
-    subsection_path (ssp), entry_name(Name), entry_value(Value) {};
+    subsection_path (ssp), entry_name(Name), entry_value(Value)
+{};
+
 
 
-void MultipleParameterLoop::Entry::split_different_values () {
+void MultipleParameterLoop::Entry::split_different_values ()
+{
                                   // split string into three parts:
                                   // part before the opening "{",
                                   // the selection itself, final
index f9ff6323c8f9315be75280458491562ac697a226..20e7268c2575d2bd8ce4d8171796bc84f9339934 100644 (file)
@@ -602,9 +602,18 @@ sub deref
        my $out = "";
        my $text;
 
-       # escape @x commands
-       foreach $text ( split (/(\@\w+(?:\s+.+?(?=\s)|\{.*?\}))/, $str ) ) {
-
+       # first escape @x directives. these are @x commands that do
+       # not take parameters, i.e. they do not take an argument which
+       # would either be the next word or the string in braces after
+       # the command name
+       $str =~ s/\@item/<li>/g;
+
+       # escape @x commands. by using the `split' command, we get a
+       # list of strings that contain either the matched command or the
+       # string in between. if an element of this list matches a
+       # command, then we process it further, otherwise we simply
+       # copy it over to the output
+        foreach $text ( split (/(\@\w+(?:\s+.+?(?=\s)|\{.*?\}))/, $str ) ) {
                # check whether $text is an @command or the text between
                # @commands
                if (  $text =~ /\@(\w+)(?:\s+(.+?)(?:\s|$)|\{(.*?)\})/ )   {
@@ -632,13 +641,47 @@ sub deref
                            $out .= "<h$1>".esc($content)."</h$1>";
                        }
 
+                       # @begin{...} -- start environment
+                       elsif ( $command =~ /^begin$/ ) {
+                           if ( $content eq "itemize" ) {
+                               $out .= "<ul>";
+                           }
+                           elsif ( $content eq "enumerate" ) {
+                               $out .= "<ol>";
+                           }
+                           elsif ( $content eq "verbatim" ) {
+                               $out .= "<pre><code>";
+                           }
+                           else {
+                               print "Unknown command @", "$command($content)\n";
+                               $out .= esc($text);
+                           }
+                       }
+
+                       # @end{...} -- close environment
+                       elsif ( $command =~ /^end$/ ) {
+                           if ( $content eq "itemize") {
+                               $out .= "</ul>";
+                           }
+                           elsif ( $content eq "enumerate") {
+                               $out .= "</ol>";
+                           }
+                           elsif ( $content eq "verbatim") {
+                               $out .= "</code></pre>";
+                           }
+                           else {
+                               print "Unknown command @", "$command($content)\n";
+                               $out .= esc($text);
+                           }
+                       }
+
                        # unknown command. warn and copy command
                        else {
                            print "Unknown command @", $command, "\n";
                            $out .= esc($text);
                        }
                }
-               # no @x command, thus regular text
+               # no @x command, thus regular text. simply forward it
                else {
                        $out .= esc($text);
                }
index 9cff7b36815adc090745d4258421526e8a211732..f0d191b3629a149bf1d902c6618f8b1f4d26f039 100644 (file)
@@ -192,7 +192,7 @@ class DoFObjectAccessor_Inheritance<dim,dim>
  * such as @p{quad} in the accessors for lines and quads, etc.
  *
  * This class follows mainly the route laid out by the accessor library
- * declared in the triangulation library (\Ref{TriaAccessor}). It enables
+ * declared in the triangulation library (@ref{TriaAccessor}). It enables
  * the user to access the degrees of freedom on the lines (there are similar
  * versions for the DoFs on quads, etc), where the dimension of the underlying
  * triangulation does not really matter (i.e. this accessor works with the
@@ -201,7 +201,7 @@ class DoFObjectAccessor_Inheritance<dim,dim>
  *
  * @sect3{Usage}
  *
- * The \Ref{DoFDimensionInfo} classes inherited by the \Ref{DoFHandler} classes
+ * The @ref{DoFDimensionInfo} classes inherited by the @ref{DoFHandler} classes
  * declare typedefs to iterators using the accessors declared in this class
  * hierarchy tree. Usage is best to happen through these typedefs, since they
  * are more secure to changes in the class naming and template interface as well
@@ -444,7 +444,7 @@ class DoFObjectAccessor<0, dim> : public DoFAccessor<dim>,
 /**
  * Access to the degrees of freedom located on lines.
  * This class follows mainly the route laid out by the accessor library
- * declared in the triangulation library (\Ref{TriaAccessor}). It enables
+ * declared in the triangulation library (@ref{TriaAccessor}). It enables
  * the user to access the degrees of freedom on the lines (there are similar
  * versions for the DoFs on quads, etc), where the dimension of the underlying
  * triangulation does not really matter (i.e. this accessor works with the
@@ -453,7 +453,7 @@ class DoFObjectAccessor<0, dim> : public DoFAccessor<dim>,
  *
  * @sect3{Usage}
  *
- * The \Ref{DoFDimensionInfo} classes inherited by the \Ref{DoFHandler} classes
+ * The @ref{DoFDimensionInfo} classes inherited by the @ref{DoFHandler} classes
  * declare typedefs to iterators using the accessors declared in this class
  * hierarchy tree. Usage is best to happens through these typedefs, since they
  * are more secure to changes in the class naming and template interface as well
index 3707e11c22b50dcc9bdd36b0117456439b63d70c..c599e6407e3765e0b092cc7ab8777d53d9921dea 100644 (file)
@@ -48,8 +48,8 @@ template <int n_blocks> class BlockIndices;
  * sparsity pattern of the condensed matrix is made out of the large sparsity
  * pattern and the constraints. After that the global matrix is assembled and
  * finally condensed. To do these steps, you have (at least) two possibilities:
- * \begin{itemize}
- * \item Use two different sparsity patterns and two different matrices: you
+ * @begin{itemize}
+ * @item Use two different sparsity patterns and two different matrices: you
  *   may eliminate the lines and rows connected with a constraint and create
  *   a totally new sparsity pattern and a new system matrix. This has the
  *   advantage that the resulting system of equations is free from artifacts
@@ -61,7 +61,7 @@ template <int n_blocks> class BlockIndices;
  *   @em{all} entries of the matrix have to be copied, not only those which are
  *   subject to constraints.
  *
- * \item Use only one sparsity pattern and one matrix: doing it this way, the
+ * @item Use only one sparsity pattern and one matrix: doing it this way, the
  *   condense functions add nonzero entries to the sparsity pattern of the
  *   large matrix (with constrained nodes in it) where the condensation process
  *   of the matrix will create additional nonzero elements. In the condensation
@@ -84,7 +84,7 @@ template <int n_blocks> class BlockIndices;
  *   consumption for those iterative solution methods using a larger number of
  *   auxiliary vectors (e.g. methods using explicite orthogonalization
  *   procedures).
- * \end{itemize}
+ * @end{itemize}
  *
  * Usually, the second way is chosen since memory consumption upon construction
  * of a second matrix rules out the first possibility.
index b3273c782dc925fe458bc8d605fc9c50463ab20b..a344be7c040c4a6e6e29a1d5b397937b5931b291 100644 (file)
@@ -34,7 +34,7 @@ template <int dim> class Triangulation;
 
 /**
  * Define some types which differ between the dimensions. This class
- * is analogous to the \Ref{TriaDimensionInfo} class hierarchy.
+ * is analogous to the @ref{TriaDimensionInfo} class hierarchy.
  * 
  * @see DoFDimensionInfo<1>
  * @see DoFDimensionInfo<2>
@@ -46,7 +46,7 @@ class DoFDimensionInfo;
 /**
  * Define some types for the DoF handling in one dimension.
  *
- * The types have the same meaning as those declared in \Ref{TriaDimensionInfo<2>}.
+ * The types have the same meaning as those declared in @ref{TriaDimensionInfo<2>}.
  */
 class DoFDimensionInfo<1> {
   public:
@@ -75,7 +75,7 @@ class DoFDimensionInfo<1> {
 /**
  * Define some types for the DoF handling in two dimensions.
  *
- * The types have the same meaning as those declared in \Ref{TriaDimensionInfo<2>}.
+ * The types have the same meaning as those declared in @ref{TriaDimensionInfo<2>}.
  */
 class DoFDimensionInfo<2> {
   public:
@@ -104,7 +104,7 @@ class DoFDimensionInfo<2> {
 /**
  * Define some types for the DoF handling in two dimensions.
  *
- * The types have the same meaning as those declared in \Ref{TriaDimensionInfo<3>}.
+ * The types have the same meaning as those declared in @ref{TriaDimensionInfo<3>}.
  */
 class DoFDimensionInfo<3> {
   public:
@@ -143,7 +143,7 @@ class DoFDimensionInfo<3> {
  * also refer to all degrees of freedom and some kind of condensation
  * is needed to restrict the systems of equations to the unconstrained
  * degrees of freedom only. The actual layout of storage of the indices
- * is described in the \Ref{DoFLevel} class documentation.
+ * is described in the @ref{DoFLevel} class documentation.
  *
  * Finally it offers a starting point for the assemblage of the matrices
  * by offering @p{begin()} and @p{end()} functions which return iterators
@@ -1189,7 +1189,7 @@ class DoFHandler  :  public Subscriptor,
                                     /**
                                      * Space to store the DoF numbers for the
                                      * different levels. Analogous to the
-                                     * @p{levels[]} tree of the \Ref{Triangulation}
+                                     * @p{levels[]} tree of the @ref{Triangulation}
                                      * objects.
                                      */
     vector<DoFLevel<dim>*>    levels;
index 2f6439efe820d0417210dd1f25346aa6f7e559fd..f8e52e8cf98a2a0bbecece46b6050f127f0463c9 100644 (file)
@@ -82,7 +82,7 @@ class DoFLevel<1>
   public:
                                     /**
                                      * Store the global indices of the degrees
-                                     * of freedom. See \Ref{DoFLevel} for
+                                     * of freedom. See @ref{DoFLevel} for
                                      * detailed information.
                                      */
     vector<unsigned int> line_dofs;
@@ -91,13 +91,13 @@ class DoFLevel<1>
 
 /**
  * Store the indices of the degrees of freedom which are located on quads.
- * See \Ref{DoFLevel<1>} for more information.
+ * See @ref{DoFLevel<1>} for more information.
  */
 class DoFLevel<2> : public DoFLevel<1> {
   public:
                                     /**
                                      * Store the global indices of the degrees
-                                     * of freedom. See \Ref{DoFLevel} for
+                                     * of freedom. See @ref{DoFLevel} for
                                      * detailed information.
                                      */
     vector<unsigned int> quad_dofs;
@@ -106,13 +106,13 @@ class DoFLevel<2> : public DoFLevel<1> {
 
 /**
  * Store the indices of the degrees of freedom which are located on hexhedra.
- * See \Ref{DoFLevel<1>} for more information.
+ * See @ref{DoFLevel<1>} for more information.
  */
 class DoFLevel<3> : public DoFLevel<2> {
   public:
                                     /**
                                      * Store the global indices of the degrees
-                                     * of freedom. See \Ref{DoFLevel} for
+                                     * of freedom. See @ref{DoFLevel} for
                                      * detailed information.
                                      */
     vector<unsigned int> hex_dofs;
index 362bdc1dbd1c3385a3b142c2b99d3477f400a9d7..0ed2a26456a2f8fa2e0cebf183b8a7b17bd70bfc 100644 (file)
@@ -131,10 +131,10 @@ class DoFTools
                                      * equations,
                                      *
                                      *
-                                     * \begin{verbatim}
+                                     * @begin{verbatim}
                                      * -\Delta \vec u + \nabla p = 0,
                                      * \div u                    = 0
-                                     * \end{verbatim}
+                                     * @end{verbatim}
                                      *
                                      * in two space dimensions,
                                      * using stable Q2/Q1 mixed
@@ -146,11 +146,11 @@ class DoFTools
                                      * following pattern of
                                      * couplings:
                                      *
-                                     * \begin{verbatim}
+                                     * @begin{verbatim}
                                      *   1 0 1
                                      *   0 1 1
                                      *   1 1 0
-                                     * \end{verbatim}
+                                     * @end{verbatim}
                                      * where "1" indicates that two
                                      * variables (i.e. components of
                                      * the @p{FESystem}) couple in the
index 79a80f779255aec0a90dc0e6238f50fc63eff565..846302a518b82e75043e6b2fbdd5ec98193eacc4 100644 (file)
@@ -811,7 +811,7 @@ class FiniteElementBase : public Subscriptor,
  * The order of the twelve lines and the four child faces can be extracted
  * from the following sketch, where the overall order of the different
  * dof groups is depicted:
- * \begin{verbatim}
+ * @begin{verbatim}
  *    *--13--3--14--*
  *    |      |      |
  *    16 20  7  19  12
@@ -821,13 +821,13 @@ class FiniteElementBase : public Subscriptor,
  *    15 17  5  18  11
  *    |      |      |
  *    *--9---1--10--*
- * \end{verbatim}
+ * @end{verbatim}
  * It should be noted that the face as shown here is in the standard form,
  * i.e. with vertex zero at the bottom left, and the other vertices numbered
  * counter clockwise. This explains the numbering of the lines labeled 13 and
  * 14, as well as those labeled 15 and 16. The dofs on the lines need to
  * be numbered in the direction of the lines, which is as follows:
- * \begin{verbatim}
+ * @begin{verbatim}
  *    *-->---*-->---*
  *    |      |      |
  *    ^      ^      ^ 
@@ -837,7 +837,7 @@ class FiniteElementBase : public Subscriptor,
  *    ^      ^      ^ 
  *    |      |      |
  *    *-->---*-->---*
- * \end{verbatim}
+ * @end{verbatim}
  * The orientation of the quads should be obvious.
  *
  * The faces of a hexahedron are arranged in a way such that
@@ -871,7 +871,7 @@ class FiniteElementBase : public Subscriptor,
  * face of two cells need not match exactly, if one of the cells is
  * refined and the two cells are at the boundary. To understand this,
  * look at the following sketch:
- * \begin{verbatim}
+ * @begin{verbatim}
  *         *---------*---------*
  *        /         /         /|
  *       /         /         / |
@@ -883,7 +883,7 @@ class FiniteElementBase : public Subscriptor,
  *     |         |         | /
  *     |         |         |/
  *     *---------*---------*
- * \end{verbatim}
+ * @end{verbatim}
  *
  * Assume the two top faces represent the boundary of the
  * triangulation; assume further that the boundary of the original
@@ -893,7 +893,7 @@ class FiniteElementBase : public Subscriptor,
  * children of this line will not take the same place as their mother
  * line did (this is not properly drawable using only ASCII characters,
  * use some imagination):
- * \begin{verbatim}
+ * @begin{verbatim}
  *       ..*--.*---..*---------*
  *      *----*----* /         /|
  *      :    :    :/         / |
@@ -905,7 +905,7 @@ class FiniteElementBase : public Subscriptor,
  *     |    |    |         | /
  *     |    |    |         |/
  *     *----*----*---------*
- * \end{verbatim}
+ * @end{verbatim}
  * While this is the case with boundary faces in two spatial
  * dimensions also, it here leads to the fact that the four child
  * faces of the common face of the two cells will not coincide with
@@ -973,8 +973,8 @@ class FiniteElementBase : public Subscriptor,
  * There is no guarantee that this list is complete; in fact, doubts are in
  * place that that be so.
  *
- * \begin{itemize}
- * \item Lagrange elements: at several places in the library, use is made of the
+ * @begin{itemize}
+ * @item Lagrange elements: at several places in the library, use is made of the
  *   assumption that the basis functions of a finite element corresponds to a
  *   function value (as opposed to derivatives or the like, as used in the
  *   Hermitean finite element class or in the quintic Argyris element). It is
@@ -998,7 +998,7 @@ class FiniteElementBase : public Subscriptor,
  *   the degrees of freedom denote function values and not derivatives or
  *   the like.
  *
- * \item Vanishing of basis functions on faces: when projecting a function
+ * @item Vanishing of basis functions on faces: when projecting a function
  *   to the boundary, use if made of the assumption that all basis functions
  *   on a cell adjacent to the boundary vanish on the boundary except for those
  *   on the boundary face itself. For Lagrange elements this is true, but it
@@ -1020,7 +1020,7 @@ class FiniteElementBase : public Subscriptor,
  *   the assumption does not hold, then the distribution has to happen
  *   with all nodes on the small and the large cells. This is not
  *   implemented in the @p{DoFHandler} class as of now.
- * \end{itemize}
+ * @end{itemize}
  *
  * @author Wolfgang Bangerth, 1998
  */
@@ -1122,7 +1122,7 @@ class FiniteElement : public FiniteElementBase<dim>
                                      * of the fields to actually compute.
                                      *
                                      * Refer to the documentation of the
-                                     * \Ref{FEValues} class for a definition
+                                     * @ref{FEValues} class for a definition
                                      * of the Jacobi matrix and of the various
                                      * structures to be filled.
                                      *
index bb50d277712faa7d11aa653e0cf352057d2a12bf..d927390925619abf9d5e8260c9a94eb9f1cf2685 100644 (file)
  * however be noted that the support of basis functions get quite
  * complicated in the presence of hanging nodes, as the following figure
  * depicts:
- * \begin{verbatim}
+ * @begin{verbatim}
  *   *-----------------*--------*----
  *   |                /|\       |
  *   |              /..|.\      |
  *   | /...............|.....\  |
  *   |/................|.......\|
  *   *-----------------o--------*-----
- * \end{verbatim}
+ * @end{verbatim}
  * The dotted area is the support of the basis function associated with the
  * bottom middle vertex (denoted by @p{o}) after the hanging node in the center
  * of the `picture' was eliminated. This strange structure of the support
  * When using one of the usual quadrature formulae, a common problem is
  * that some of the quadrature points lie on the interfaces of the
  * triangles. For this reason, there is a family of quadrature formulae
- * defined below, names \ref{QCrissCross1} and higher order, which
+ * defined below, names @ref{QCrissCross1} and higher order, which
  * resemble the quadrature formulae used on triangular domains, but
  * taken four-fold, i.e. for each of the four subtriangles.
  *
index e07607c30943bbcdd7d5ccc2b7d8c356eb1e6392..2122262833bf5d5eb332243f16b7e2ee9c702503 100644 (file)
@@ -137,23 +137,23 @@ class FEQ1 : public FEQ1Mapping<dim>
  * to the real cell is implemented.
  *
  * The numbering of the degrees of freedom is as follows:
- * \begin{itemize}
- * \item 1D case:
- *   \begin{verbatim}
+ * @begin{itemize}
+ * @item 1D case:
+ *   @begin{verbatim}
  *      0---2---1
- *   \end{verbatim}
+ *   @end{verbatim}
  *
- * \item 2D case:
- *   \begin{verbatim}
+ * @item 2D case:
+ *   @begin{verbatim}
  *      3---6---2
  *      |       |
  *      7   8   5
  *      |       |
  *      0---4---1
- *   \end{verbatim}
+ *   @end{verbatim}
  *
- * \item 3D case:
- *   \begin{verbatim}
+ * @item 3D case:
+ *   @begin{verbatim}
  *         7--14---6        7--14---6
  *        /|       |       /       /|
  *      19 |       13     19      1813
@@ -175,41 +175,41 @@ class FEQ1 : public FEQ1Mapping<dim>
  *     | /  22   /      |       | /
  *     |/       /       |       |/
  *     *-------*        *-------* 
- *   \end{verbatim}
+ *   @end{verbatim}
  *   The center vertex has number 26.
  *
  *   The respective coordinate values of the support points of the degrees
  *   of freedom are as follows:
- *   \begin{itemize}
- *   \item Index 0: @p{[0, 0, 0]};
- *   \item Index 1: @p{[1, 0, 0]};
- *   \item Index 2: @p{[1, 0, 1]};
- *   \item Index 3: @p{[0, 0, 1]};
- *   \item Index 4: @p{[0, 1, 0]};
- *   \item Index 5: @p{[1, 1, 0]};
- *   \item Index 6: @p{[1, 1, 1]};
- *   \item Index 7: @p{[0, 1, 1]};
- *   \item Index 8: @p{[1/2, 0, 0]};
- *   \item Index 9: @p{[1, 0, 1/2]};
- *   \item Index 10: @p{[1/2, 0, 1]};
- *   \item Index 11: @p{[0, 0, 1/2]};
- *   \item Index 12: @p{[1/2, 1, 0]};
- *   \item Index 13: @p{[1, 1, 1/2]};
- *   \item Index 14: @p{[1/2, 1, 1]};
- *   \item Index 15: @p{[0, 1, 1/2]};
- *   \item Index 16: @p{[0, 1/2, 0]};
- *   \item Index 17: @p{[1, 1/2, 0]};
- *   \item Index 18: @p{[1, 1/2, 1]};
- *   \item Index 19: @p{[0, 1/2, 1]};
- *   \item Index 20: @p{[1/2, 0, 1/2]};
- *   \item Index 21: @p{[1/2, 1, 1/2]};
- *   \item Index 22: @p{[1/2, 1/2, 0]};
- *   \item Index 23: @p{[1, 1/2, 1/2]};
- *   \item Index 24: @p{[1/2, 1/2, 1]};
- *   \item Index 25: @p{[0, 1/2, 1/2]};
- *   \item Index 26: @p{[1/2, 1/2, 1/2]}; 
- *   \end{itemize}
- * \end{itemize}
+ *   @begin{itemize}
+ *   @item Index 0: @p{[0, 0, 0]};
+ *   @item Index 1: @p{[1, 0, 0]};
+ *   @item Index 2: @p{[1, 0, 1]};
+ *   @item Index 3: @p{[0, 0, 1]};
+ *   @item Index 4: @p{[0, 1, 0]};
+ *   @item Index 5: @p{[1, 1, 0]};
+ *   @item Index 6: @p{[1, 1, 1]};
+ *   @item Index 7: @p{[0, 1, 1]};
+ *   @item Index 8: @p{[1/2, 0, 0]};
+ *   @item Index 9: @p{[1, 0, 1/2]};
+ *   @item Index 10: @p{[1/2, 0, 1]};
+ *   @item Index 11: @p{[0, 0, 1/2]};
+ *   @item Index 12: @p{[1/2, 1, 0]};
+ *   @item Index 13: @p{[1, 1, 1/2]};
+ *   @item Index 14: @p{[1/2, 1, 1]};
+ *   @item Index 15: @p{[0, 1, 1/2]};
+ *   @item Index 16: @p{[0, 1/2, 0]};
+ *   @item Index 17: @p{[1, 1/2, 0]};
+ *   @item Index 18: @p{[1, 1/2, 1]};
+ *   @item Index 19: @p{[0, 1/2, 1]};
+ *   @item Index 20: @p{[1/2, 0, 1/2]};
+ *   @item Index 21: @p{[1/2, 1, 1/2]};
+ *   @item Index 22: @p{[1/2, 1/2, 0]};
+ *   @item Index 23: @p{[1, 1/2, 1/2]};
+ *   @item Index 24: @p{[1/2, 1/2, 1]};
+ *   @item Index 25: @p{[0, 1/2, 1/2]};
+ *   @item Index 26: @p{[1/2, 1/2, 1/2]}; 
+ *   @end{itemize}
+ * @end{itemize}
  *
  * @author Wolfgang Bangerth, 1998, 1999
  */
@@ -314,12 +314,12 @@ class FEQ2 : public FEQ1Mapping<dim>
  * to the real cell is implemented.
  *
  * The numbering of degrees of freedom in one spatial dimension is as follows:
- * \begin{verbatim}
+ * @begin{verbatim}
  *   0--2--3--1
- * \end{verbatim}
+ * @end{verbatim}
  *
  * The numbering of degrees of freedom in two spatial dimension is as follows:
- * \begin{verbatim}
+ * @begin{verbatim}
  *   3--8--9--2
  *   |        |
  *   11 15 14 7
@@ -327,7 +327,7 @@ class FEQ2 : public FEQ1Mapping<dim>
  *   10 12 13 6
  *   |        |
  *   0--4--5--1
- * \end{verbatim}
+ * @end{verbatim}
  * Note the reverse ordering of degrees of freedom on the left and upper
  * line and the counterclockwise numbering of the interior degrees of
  * freedom.
@@ -435,12 +435,12 @@ class FEQ3 : public FEQ1Mapping<dim>
  * to the real cell is implemented.
  *
  * The numbering of degrees of freedom in one spatial dimension is as follows:
- * \begin{verbatim}
+ * @begin{verbatim}
  *   0--2--3--4--1
- * \end{verbatim}
+ * @end{verbatim}
  *
  * The numbering of degrees of freedom in two spatial dimension is as follows:
- * \begin{verbatim}
+ * @begin{verbatim}
  *   3--10-11-12-2
  *   |           |
  *   15 19 22 18 9
@@ -450,7 +450,7 @@ class FEQ3 : public FEQ1Mapping<dim>
  *   13 16 20 17 7
  *   |           |
  *   0--4--5--6--1
- * \end{verbatim}
+ * @end{verbatim}
  * Note the reverse ordering of degrees of freedom on the left and upper
  * line and the numbering of the interior degrees of
  * freedom.
index c07bdd5093db12fcbb1a46d989005b2be0235d7a..4b9d753ed4721caec475fbb377d5d0940e1edeac 100644 (file)
  * For example, for the bicubic element in one space dimension, and for
  * two subobjects grouped together by this class, the ordering for
  * the system @p{s=(u,v)} is:
- * \begin{itemize}
- * \item First vertex: @p{u0, v0 = s0, s1}
- * \item Second vertex: @p{u1, v1 = s2, s3}
- * \item First degree of freedom on the line (=cell):
+ * @begin{itemize}
+ * @item First vertex: @p{u0, v0 = s0, s1}
+ * @item Second vertex: @p{u1, v1 = s2, s3}
+ * @item First degree of freedom on the line (=cell):
  *   @p{u2, v2 = s3, s4}
- * \item Second degree of freedom on the line:
+ * @item Second degree of freedom on the line:
  *   @p{u3, v3 = s5, s6}.
- * \end{itemize}
+ * @end{itemize}
  *
  * In the most cases, the composed element behaves as if it were a usual element
  * with more degrees of freedom. However the underlying structure is visible in
index d3bc21b1df846a5a9acefc458bf54668e9266ed1..1505ca2441028d0d3bf57c417743326597c6bb31 100644 (file)
@@ -143,17 +143,17 @@ template <int dim> class Quadrature;
  *  @sect3{Member functions}
  *
  *  The functions of this class fall into different cathegories:
- *  \begin{itemize}
- *  \item @p{shape_value}, @p{shape_grad}, etc: return one of the values
+ *  @begin{itemize}
+ *  @item @p{shape_value}, @p{shape_grad}, etc: return one of the values
  *    of this object at a time. In many cases you will want to get
  *    a whole bunch at a time for performance or convenience reasons,
  *    then use the @p{get_*} functions.
  *   
- *  \item @p{get_shape_values}, @p{get_shape_grads}, etc: these return
+ *  @item @p{get_shape_values}, @p{get_shape_grads}, etc: these return
  *    a reference to a whole field. Usually these fields contain
  *    the values of all trial functions at all quadrature points.
  *
- *  \item @p{get_function_values}, @p{get_function_grads}, @p{...}: these
+ *  @item @p{get_function_values}, @p{get_function_grads}, @p{...}: these
  *    functions offer a simple way to avoid the detour of the
  *    trial functions, if you have a finite element solution (resp. the
  *    vector of values associated with the different trial functions.)
@@ -178,11 +178,11 @@ template <int dim> class Quadrature;
  *    other involved instance between the @p{reinit} and the @p{get_function_*}
  *    functions are called.
  *
- *  \item @p{reinit}: initialize the @p{FEValues} object for a certain cell.
+ *  @item @p{reinit}: initialize the @p{FEValues} object for a certain cell.
  *    This function is not in the present class but only in the derived
  *    classes and has a variable call syntax. 
  *    See the docs for the derived classes for more information.
- * \end{itemize}
+ * @end{itemize}
  *
  *
  * @sect3{Implementational issues}
@@ -1133,8 +1133,8 @@ class FEFaceValues : public FEFaceValuesBase<dim>
  * cells is more refined than the other.
  *
  * To this end, there seem to be two ways which may be applicable:
- * \begin{itemize}
- * \item Prolong the coarser cell to the finer refinement level: we could
+ * @begin{itemize}
+ * @item Prolong the coarser cell to the finer refinement level: we could
  *   compute the prolongation of the finite element functions to the
  *   child cells and consider the subface a face of one of the child cells.
  *   This approach seems clear and rather simple to implement, however it
@@ -1151,7 +1151,7 @@ class FEFaceValues : public FEFaceValuesBase<dim>
  *   programming style. Apart from that, we already have iterators, why
  *   shouldn't we use them?
  *   
- * \item Use 'different' quadrature formulae: this second approach is the
+ * @item Use 'different' quadrature formulae: this second approach is the
  *   way we chose here. The idea is to evaluate the finite element trial
  *   functions on the two cells restricted to the face in question separately,
  *   by restricting the trial functions on the less refined cell to its
@@ -1181,7 +1181,7 @@ class FEFaceValues : public FEFaceValuesBase<dim>
  *   quadrature formula projected to the common face, but using the original
  *   quadrature formula. This way, the locations of the quadrature points
  *   on both sides of the common face match each other.
- * \end{itemize}
+ * @end{itemize}
  *
  * For a use of this mechanism, take a look of the code in the error
  * estimation hierarchy, since there often the jump of a finite element
index 7e52eaa1bbcb239e5e32e4ad77c70ec6632a1e4e..b9ed710ac5580b46ab6fa422378fa99f62ce3fa3 100644 (file)
@@ -151,7 +151,7 @@ struct GeometryInfo
                                      *
                                      * For example, in 2D the layout of
                                      * a cell is as follows:
-                                     * \begin{verbatim}
+                                     * @begin{verbatim}
                                      * .      2
                                      * .   3-->--2
                                      * .   |     |
@@ -159,20 +159,20 @@ struct GeometryInfo
                                      * .   |     |
                                      * .   0-->--1
                                      * .      0
-                                     * \end{verbatim}
+                                     * @end{verbatim}
                                      * Vertices and faces are indicated
                                      * with their numbers, faces also with
                                      * their directions.
                                      *
                                      * Now, when refined, the layout is
                                      * like this:
-                                     * \begin{verbatim}
+                                     * @begin{verbatim}
                                      * *--*--*
                                      * | 3|2 |
                                      * *--*--*
                                      * | 0|1 |
                                      * *--*--*
-                                     * \end{verbatim}
+                                     * @end{verbatim}
                                      *
                                      * Thus, the child cells on face zero
                                      * are (ordered in the direction of the
index d33e0e70f9bc1a304e42eaff24de8660ab24adfa..25d2f04827a05580fa2c92afd10863f893ea28f0 100644 (file)
@@ -24,8 +24,8 @@ template <int dim> class Triangulation;
  * This class offers triangulations of some standard domains such as hypercubes,
  * hyperball and the like. Following is a list of domains that can be generated
  * by the functions of this class:
- * \begin{itemize}
- *    \item Hypercube triangulations: a hypercube triangulation is a
+ * @begin{itemize}
+ *    @item Hypercube triangulations: a hypercube triangulation is a
  *       domain which is the tensor product of an interval $[a,b]$ in
  *       the given number of spatial dimensions. If you want to create such
  *       a domain, which is a common test case for model problems, call
@@ -33,7 +33,7 @@ template <int dim> class Triangulation;
  *       hypercube domain triangulated with exactly one element. You can
  *       get tensor product meshes by successive refinement of this cell.
  *
- *    \item Generalized L-shape domain:
+ *    @item Generalized L-shape domain:
  *      using the @p{GridGenerator::hyper_L (tria, a,b)} function produces
  *      the hypercube with the interval $[a,b]$ without the hypercube
  *      made out of the interval $[(a+b)/2,b]$. Let, for example, be $a=-1$
@@ -41,7 +41,7 @@ template <int dim> class Triangulation;
  *      $[-1,1]^2 - [0,1]^2$. To create a hyper-L in one dimension results in
  *      an error. The function is also implemented for three space dimensions.
  *
- *    \item Hyper balls:
+ *    @item Hyper balls:
  *      You get the circle or ball (or generalized: hyperball) around origin
  *      @p{p} and with radius @p{r} by calling
  *      @p{GridGenerator::hyper_ball (tria, p, r)}. The circle is triangulated
@@ -54,7 +54,7 @@ template <int dim> class Triangulation;
  *      to the triangulation object you passed to this function if you later want
  *      the triangulation to be refined at the outer boundaries.
  *
- *    \item Hyper shell: A hyper shell is the region between two hyper
+ *    @item Hyper shell: A hyper shell is the region between two hyper
  *      sphere with the same origin. Therefore, it is a ring in two
  *      spatial dimensions. To triangulation it, call the function
  *      @pGridGenerator::hyper_shell (tria, origin, inner_radius, outer_radius, N)},
@@ -75,14 +75,14 @@ template <int dim> class Triangulation;
  *      suitable boundary class is provided as @p{HyperSphereBoundary}
  *      in the library.
  *
- * \item Slit domain: The slit domain is a variant of the hyper cube
+ * @item Slit domain: The slit domain is a variant of the hyper cube
  *      domain. In two spatial dimensions, it is a square into which a slit
  *      is sawed; if the initial square is though to be composed of four
  *      smaller squares, then two of them are not connected even though
  *      they are neighboring each other. Analogously, into the cube in
  *      three spatial dimensions, a half-plane is sawed, disconnecting four
  *      of the eight child-cubes from one of their neighbors.
- * \end{itemize}
+ * @end{itemize}
  *
  * @author Wolfgang Bangerth, 1998, 1999. Slit domain by Stefan Nauber, 1999
  */
index 4069d214b3e2a5b7c767fc854eb715b0238db413..5aca63e999eedbea38de2a4910022c76a5a40ffb 100644 (file)
@@ -43,7 +43,7 @@ template <int dim> class Triangulation;
  *
  * Material indicators are accepted to denote the material id of cells and
  * to denote boundary part indication for lines in 2D. Read the according
- * sections in the documentation of the \Ref{Triangulation} class for
+ * sections in the documentation of the @ref{Triangulation} class for
  * further details.
  *
  *
@@ -58,20 +58,20 @@ template <int dim> class Triangulation;
  * In two dimensions, another difficulty occurs, which has to do with the sense
  * of a quadrilateral. A quad consists of four lines which have a direction,
  * which is per definitionem as follows:
- * \begin{verbatim}
+ * @begin{verbatim}
  *   3-->--2
  *   |     |
  *   ^     ^
  *   |     |
  *   0-->--1
- * \end{verbatim}
+ * @end{verbatim}
  * Now, two adjacent cells must have a vertex numbering such that the direction
  * of the common side is the same. For example, the following two quads
- * \begin{verbatim}
+ * @begin{verbatim}
  *   3---4---5
  *   |   |   |
  *   0---1---2
- * \end{verbatim}
+ * @end{verbatim}
  * may be characterised by the vertex numbers (0 1 4 3) and (1 2 5 4), since
  * the middle line would get the direction @p{1->4} when viewed from both cells.
  * The numbering (0 1 4 3) and (5 4 1 2) would not be allowed, since the left
@@ -86,7 +86,7 @@ template <int dim> class Triangulation;
  * There are more ambiguous cases, where the triangulation may not know what
  * to do at all without the use of very sophisticated algorithms. On such example
  * is the following:
- * \begin{verbatim}
+ * @begin{verbatim}
  *   9---10-----11
  *   |   |    / |
  *   6---7---8  |
@@ -94,10 +94,10 @@ template <int dim> class Triangulation;
  *   3---4---5  |
  *   |   |    \ |
  *   0---1------2
- * \end{verbatim}
+ * @end{verbatim}
  * Assume that you had numbered the vertices in the cells at the left boundary
  * in a way, that the following line directions are induced:
- * \begin{verbatim}
+ * @begin{verbatim}
  *   9->-10-----11
  *   ^   ^    / |
  *   6->-7---8  |
@@ -105,7 +105,7 @@ template <int dim> class Triangulation;
  *   3->-4---5  |
  *   ^   ^    \ |
  *   0->-1------2
- * \end{verbatim}
+ * @end{verbatim}
  * (This could for example be done by using the indices (0 1 4 3), (3 4 7 6),
  * (6 7 10 9) for the three cells). Now, you will not find a way of giving
  * indices for the right cells, without introducing either ambiguity for
index 1c561f8007eb44a626566af245927c1b052aa0bd..516d5790bb00ae428642af8bd543446f64d3d08b 100644 (file)
@@ -35,18 +35,18 @@ template <int dim> class Triangulation;
  *
  * @sect3{Usage}
  * Usage is simple: either you use the direct form
- * \begin{verbatim}
+ * @begin{verbatim}
  *   ofstream output_file("some_filename");
  *   GridOut().write_gnuplot (tria, output_file);
- * \end{verbatim}
+ * @end{verbatim}
  * if you know which format you want to have, or if you want the format to be
  * a runtime parameter, you can write
- * \begin{verbatim}
+ * @begin{verbatim}
  *   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);
- * \end{verbatim}
+ * @end{verbatim}
  * The function @p{get_output_format_names()} provides a list of possible names of
  * output formats in a string that is understandable by the @p{ParameterHandler} class.
  *
@@ -70,14 +70,14 @@ template <int dim> class Triangulation;
  * set of parameters for each supported output format. These are collected
  * in structures @p{EpsFlags}, @p{GnuplotFlags}, etc and you can set your preferred
  * flags like this:
- * \begin{verbatim}
+ * @begin{verbatim}
  *   GridOut grid_out;
  *   GridOut::UcdFlags ucd_flags;
  *   ...    // set some fields in ucd_flags
  *   grid_out.set_flags (ucd_flags);
  *   ...
  *   ...    // write some file with data_out
- * \end{verbatim}
+ * @end{verbatim}
  * 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
@@ -336,9 +336,9 @@ class GridOut
                                      * this feature is the following:
                                      * if you use the GNUPLOT
                                      * command (for a 2d grid here)
-                                     * \begin{verbatim}
+                                     * @begin{verbatim}
                                      * splot [:][:][2.5:3.5] "grid_file.gnuplot" *
-                                     * \end{verbatim}
+                                     * @end{verbatim}
                                      * then the
                                      * whole x- and y-range will be
                                      * plotted, i.e. the whole grid,
@@ -503,11 +503,11 @@ class GridOut
                                      * suffix with a given output format
                                      * usually has. At present the following
                                      * formats are defined:
-                                     * \begin{itemize}
-                                     * \item @p{gnuplot}: @p{.gnuplot}
-                                     * \item @p{ucd}: @p{.inp}
-                                     * \item @p{eps}: @p{.eps}.
-                                     * \end{itemize}
+                                     * @begin{itemize}
+                                     * @item @p{gnuplot}: @p{.gnuplot}
+                                     * @item @p{ucd}: @p{.inp}
+                                     * @item @p{eps}: @p{.eps}.
+                                     * @end{itemize}
                                      *
                                      * Since this function does not need data
                                      * from this object, it is static and can
index a5b329f60768081f9530d6a4731c19770281c12f..ecad3db4763e4f120c54be1f48458d0cb0afe47b 100644 (file)
@@ -23,18 +23,18 @@ template <class T> class SmartPointer;
  *
  * Usually, the two grids will be refined differently. Then, the value
  * returned for an iterator on the source grid will be either:
- * \begin{itemize}
- *   \item The same cell on the destination grid, if it exists there;
- *   \item The most refined cell of the destination grid from which the
+ * @begin{itemize}
+ *   @item The same cell on the destination grid, if it exists there;
+ *   @item The most refined cell of the destination grid from which the
  *      pendant of the source cell could be obtained by refinement. This
  *      cell is always active and has a refinement level less than that
  *      of the source cell.
- * \end{itemize}
+ * @end{itemize}
  * Keys for this map are all cells on the source grid, whether active or
  * not.
  *
  * For example, consider these two one-dimensional grids:
- * \begin{verbatim}
+ * @begin{verbatim}
  * Grid 1:
  *   x--x--x-----x-----------x
  *    1  2    3        4 
@@ -42,18 +42,18 @@ template <class T> class SmartPointer;
  * Grid 2:
  *   x-----x-----x-----x-----x
  *      1     2     3     4
- * \end{verbatim}
+ * @end{verbatim}
  * (Cell numbers are only given as an example and will not correspond
  * to real cell iterator's indices.) The mapping from grid 1 to grid 2
  * will then be as follows:
- * \begin{verbatim}
+ * @begin{verbatim}
  *    Cell on grid 1         Cell on grid 2
  *          1  ------------------>  1
  *          2  ------------------>  1
  *          3  ------------------>  2
  *          4  ------------------>  mother cell of cells 3 and 4
  *                                  (a non-active cell, not shown here)
- * \end{verbatim}
+ * @end{verbatim}
  * Besides the mappings shown here, the non-active cells on grid 1 are also
  * valid keys. For example, the mapping for the mother cell of cells 1 and 2
  * on the first grid will point to cell 1 on the second grid.
@@ -73,7 +73,7 @@ template <class T> class SmartPointer;
  * @sect2{Usage}
  *
  * In practice, use of this class is as follows:
- * \begin{verbatim}
+ * @begin{verbatim}
  *                   // have two grids, which are derived from the
  *                   // same coarse grid
  *   Triangulation<dim> tria1, tria2;
@@ -95,7 +95,7 @@ template <class T> class SmartPointer;
  *                    // corresponding to @p{cell} (which is one of
  *                    // dof_handler_1
  *     f( grid_1_to_2_map[cell]);
- * \end{verbatim}
+ * @end{verbatim}
  *
  * Note that the template parameters to this class have to be given as
  * @p{InterGridMap<DoFHandler,2>}, i.e. the dimension is given explicitely and
index cb0602e05d1ecba8c7a21adc838968477335c65d..16bc88e00ea8c1122e334e125b1f7d1175ff28b3 100644 (file)
@@ -55,7 +55,7 @@
  * object of this class.
  *
  * Basically, usage looks like this:
- * \begin{verbatim}
+ * @begin{verbatim}
  *   Triangulation<dim> coarse_grid;
  *   ...                     // initialize coarse grid
  *
@@ -84,7 +84,7 @@
  *                           // is not needed anymore, e.g.
  *                           // working with another grid
  *     };
- * \end{verbatim}
+ * @end{verbatim}
  *
  * Note that initially, the @p{PersistentTriangulation} object does not
  * constitute a triangulation; it only becomes one after @p{restore} is first
index fe23a3ae53430df495cb1d0ee50dc1edcbf801c0..fab455c66388b9566f38156aa994cbe43a6a91e7 100644 (file)
@@ -126,11 +126,11 @@ class TriaDimensionInfo;
  *  @p{raw_line_iterator} objects operate on all lines, used or not.
  *
  *  Since we are in one dimension, the following identities are declared:
- *  \begin{verbatim}
+ *  @begin{verbatim}
  *    typedef raw_line_iterator    raw_cell_iterator;
  *    typedef line_iterator        cell_iterator;
  *    typedef active_line_iterator active_cell_iterator;
- *  \end{verbatim}
+ *  @end{verbatim}
  *
  *  To enable the declaration of @p{begin_quad} and the like in
  *  @p{Triangulation<1>}, the @p{quad_iterator}s are declared as
@@ -189,7 +189,7 @@ class TriaDimensionInfo<1> {
  *  certainly make any involuntary use visible.
  *
  *  Since we are in two dimension, the following identities are declared:
- *  \begin{verbatim}
+ *  @begin{verbatim}
  *    typedef raw_quad_iterator    raw_cell_iterator;
  *    typedef quad_iterator        cell_iterator;
  *    typedef active_quad_iterator active_cell_iterator;
@@ -197,7 +197,7 @@ class TriaDimensionInfo<1> {
  *    typedef raw_line_iterator    raw_face_iterator;
  *    typedef line_iterator        face_iterator;
  *    typedef active_line_iterator active_face_iterator;    
- *  \end{verbatim}
+ *  @end{verbatim}
  */
 template <>
 class TriaDimensionInfo<2> {
@@ -231,7 +231,7 @@ class TriaDimensionInfo<2> {
  *  For the declarations of the data types, more or less the same holds
  *  as for lower dimensions (see @p{TriaDimensionInfo<[12]>}). The
  *  dimension specific data types are here, since we are in three dimensions:
- *  \begin{verbatim}
+ *  @begin{verbatim}
  *    typedef raw_hex_iterator    raw_cell_iterator;
  *    typedef hex_iterator        cell_iterator;
  *    typedef active_hex_iterator active_cell_iterator;
@@ -239,7 +239,7 @@ class TriaDimensionInfo<2> {
  *    typedef raw_quad_iterator    raw_face_iterator;
  *    typedef quad_iterator        face_iterator;
  *    typedef active_quad_iterator active_face_iterator;    
- *  \end{verbatim}
+ *  @end{verbatim}
  */
 template <>
 class TriaDimensionInfo<3> {
@@ -466,7 +466,7 @@ struct TriaNumberCache<3> : public TriaNumberCache<2>
  *  data is spread over quite a lot of arrays and other places. However,
  *  there are ways powerful enough to work on these data structures
  *  without knowing their exact relations. This is done through the
- *  concept of iterators (see the STL documentation and \Ref{TriaRawIterator}).
+ *  concept of iterators (see the STL documentation and @ref{TriaRawIterator}).
  *  In order to make things as easy and dimension independent as possible,
  *  use of class local typedefs is made, see below.
  *  
@@ -497,13 +497,13 @@ struct TriaNumberCache<3> : public TriaNumberCache<2>
  *  @p{dim}>=2).
  *
  *  Additionaly, for @p{dim}==1, the following identities hold:
- *  \begin{verbatim}
+ *  @begin{verbatim}
  *    typedef raw_line_iterator    raw_cell_iterator;
  *    typedef line_iterator        cell_iterator;
  *    typedef active_line_iterator active_cell_iterator;
- *  \end{verbatim}
+ *  @end{verbatim}
  *  while for @p{dim}==2
- *  \begin{verbatim}
+ *  @begin{verbatim}
  *    typedef quad_line_iterator   raw_cell_iterator;    
  *    typedef quad_iterator        cell_iterator;
  *    typedef active_quad_iterator active_cell_iterator;
@@ -511,7 +511,7 @@ struct TriaNumberCache<3> : public TriaNumberCache<2>
  *    typedef raw_line_iterator    raw_face_iterator;
  *    typedef line_iterator        face_iterator;
  *    typedef active_line_iterator active_face_iterator;    
- *  \end{verbatim}
+ *  @end{verbatim}
  *
  *  By using the cell iterators, you can write code nearly independent of
  *  the spatial dimension. The same applies for substructure iterators,
@@ -525,9 +525,9 @@ struct TriaNumberCache<3> : public TriaNumberCache<2>
  *
  *  Usage of these iterators works mostly like with the STL iterators. Some
  *  examples taken from the @p{Triangulation} source code follow.
- *  \begin{itemize}
- *  \item @em{Counting the number of cells on a specific level}
- *    \begin{verbatim}
+ *  @begin{itemize}
+ *  @item @em{Counting the number of cells on a specific level}
+ *    @begin{verbatim}
  *     template <int dim>
  *     int Triangulation<dim>::n_cells (const int level) const {
  *        cell_iterator cell = begin (level),
@@ -537,9 +537,9 @@ struct TriaNumberCache<3> : public TriaNumberCache<2>
  *          ++n;
  *        return n;
  *      };
- *    \end{verbatim}
+ *    @end{verbatim}
  *    Another way which uses the STL @p{distance} function would be to write
- *    \begin{verbatim}
+ *    @begin{verbatim}
  *      template <int dim>
  *      int Triangulation<dim>::n_cells (const int level) const {
  *        int n=0;
@@ -550,10 +550,10 @@ struct TriaNumberCache<3> : public TriaNumberCache<2>
  *                  n);
  *        return n;
  *      };  
- *    \end{verbatim}
+ *    @end{verbatim}
  *    
- *  \item @em{Refining all cells of a triangulation}
- *    \begin{verbatim}
+ *  @item @em{Refining all cells of a triangulation}
+ *    @begin{verbatim}
  *      template <int dim>
  *      void Triangulation<dim>::refine_global () {
  *        active_cell_iterator cell = begin_active(),
@@ -563,15 +563,15 @@ struct TriaNumberCache<3> : public TriaNumberCache<2>
  *          cell->set_refine_flag ();
  *        execute_coarsening_and_refinement ();
  *      };
- *    \end{verbatim}
- *  \end{itemize}
+ *    @end{verbatim}
+ *  @end{itemize}
  *
  *
  *  @sect3{Usage}
  *
  *  Usage of a @p{Triangulation} is mainly done through the use of iterators.
  *  An example probably shows best how to use it:
- *  \begin{verbatim}
+ *  @begin{verbatim}
  *  void main () {
  *    Triangulation<2> tria;
  *
@@ -608,26 +608,26 @@ struct TriaNumberCache<3> : public TriaNumberCache<2>
  *    ofstream out("grid.1");
  *    GridOut::write_gnuplot (tria, out);
  *  };  
- *  \end{verbatim}
+ *  @end{verbatim}
  *
  *  
  *  @sect3{Creating a triangulation}
  *
  *  There are several possibilities to create a triangulation:
- *  \begin{itemize}
- *    \item The most common domains, such as hypercubes (i.e. lines, squares,
+ *  @begin{itemize}
+ *    @item The most common domains, such as hypercubes (i.e. lines, squares,
  *       cubes, etc), hyper-balls (circles, balls, ...) and some other, more
  *       weird domains such as the L-shape region and higher dimensional
  *       generalizations and others, are provided by the @p{GridGenerator}
  *       class which takes a triangulation and fills it by a division
  *       of the required domain.
  *   
- *     \item Reading in a triangulation: By using an object of the @p{DataIn}
+ *     @item Reading in a triangulation: By using an object of the @p{DataIn}
  *        class, you can read in fairly general triangulations. See there for
  *        more information. The mentioned class uses the interface described
  *        directly below to transfer the data into the triangulation.
  *
- *     \item Explicitely creating a triangulation: you can create a triangulation
+ *     @item Explicitely creating a triangulation: you can create a triangulation
  *        by providing a list of vertices and a list of cells. Each such cell
  *        consists of a vector storing the indices of the vertices of this cell
  *        in the vertex list. To see how this works, you can take a look at the
@@ -660,12 +660,12 @@ struct TriaNumberCache<3> : public TriaNumberCache<2>
  *
  *        There are more subtle conditions which must be imposed upon the
  *        vertex numbering within cells. See the documentation for the
- *        \Ref{DataIn} class for more details on this. They do not only
+ *        @ref{DataIn} class for more details on this. They do not only
  *        hold for the data read from an UCD or any other input file, but
  *        also for the data passed to the
  *        @p{Triangulation<dim>::create_triangulation (2)} function.
  *
- *     \item Copying a triangulation: when computing on time dependant meshes
+ *     @item Copying a triangulation: when computing on time dependant meshes
  *        of when using adaptive refinement, you will often want to create a
  *        new triangulation to be the same as another one. This is facilitated
  *        by the @p{copy_triangulation} function.
@@ -679,7 +679,7 @@ struct TriaNumberCache<3> : public TriaNumberCache<2>
  *        operation but guaranteeing some parallelity in the two triangulations
  *        seems more important since usually data will have to be transferred
  *        between the grids.
- *   \end{itemize}
+ *   @end{itemize}
  *
  *   The material id for each cell must be specified upon construction of
  *   a triangulation. (There is a special section on material identifier and
@@ -789,8 +789,8 @@ struct TriaNumberCache<3> : public TriaNumberCache<2>
  *
  *   There are two variations of these functions, which rely on @p{refine} and
  *   coarsen by computing the thresholds from other information:
- *   \begin{itemize}
- *   \item @p{refine_and_coarsen_fixed_number}: this function takes a vector as
+ *   @begin{itemize}
+ *   @item @p{refine_and_coarsen_fixed_number}: this function takes a vector as
  *     above and two values between zero and one denoting the fractions of cells to
  *     be refined and coarsened. For this purpose, it sorts the criteria per cell
  *     and takes the threshold to be the one belonging to the cell with the
@@ -813,7 +813,7 @@ struct TriaNumberCache<3> : public TriaNumberCache<2>
  *     want to chose a smaller value to avoid overrefinement in regions which
  *     do not contribute much to the error.
  *
- *   \item @p{refine_and_coarsen_fixed_fraction}: this function computes the
+ *   @item @p{refine_and_coarsen_fixed_fraction}: this function computes the
  *     threshold such that the number of cells getting flagged for refinement
  *     makes up for a certain fraction of the total error. If this fraction is 50
  *     per cent, for example, the threshold is computed such that the cells with
@@ -843,7 +843,7 @@ struct TriaNumberCache<3> : public TriaNumberCache<2>
  *     @p{coarsen}.
  *
  *     A typical value for the fraction of the total error is 0.5.
- *   \end{itemize}
+ *   @end{itemize}
  *
  *   For a more thorough discussion of advantages and disadvantages of the
  *   different strategies for refinement, see the paper of R. Becker and
@@ -887,12 +887,12 @@ struct TriaNumberCache<3> : public TriaNumberCache<2>
  *   The parameter taken by the constructor is an integer which may be composed
  *   bitwise by the constants defined in the @p{enum MeshSmoothing}. The meaning
  *   of these constants is explained in the following:
- *   \begin{itemize}
- *   \item @p{limit_level_difference_at_vertices}:
+ *   @begin{itemize}
+ *   @item @p{limit_level_difference_at_vertices}:
  *     It can be shown, that degradation of approximation occurs if the
  *     triangulation contains vertices which are member of cells with levels
  *     differing by more than one. One such example is the following:
- *     \begin{verbatim}
+ *     @begin{verbatim}
  *       |     |     |     |
  *       x-----x-----x--x--x--
  *       |     |     |  |  |
@@ -907,7 +907,7 @@ struct TriaNumberCache<3> : public TriaNumberCache<2>
  *       |           |     |
  *       |           |     |
  *       x-----------x-----x--
- *     \end{verbatim}
+ *     @end{verbatim}
  *     It seems that in two space dimensions, the maximum jump in levels between
  *     cells sharing a common vertex is two (as in the example above). This is
  *     not true if more than four cells meet at a vertex. It is not uncommon
@@ -932,7 +932,7 @@ struct TriaNumberCache<3> : public TriaNumberCache<2>
  *     @p{limit_level_difference_at_vertices}, situations as the above one are
  *     eliminated by also marking the lower left cell for refinement.
  *
- *   \item @p{eliminate_unrefined_islands}:
+ *   @item @p{eliminate_unrefined_islands}:
  *     Single cells which are not refined and are surrounded by cells which are
  *     refined usually also lead to a sharp decline in approximation properties
  *     locally. The reason is that the nodes on the faces between unrefined and
@@ -951,7 +951,7 @@ struct TriaNumberCache<3> : public TriaNumberCache<2>
  *     name of the flag may indicate. However, no better name came to mind to
  *     the author by now.
  *
- *   \item @p{eliminate_refined_*_islands}:
+ *   @item @p{eliminate_refined_*_islands}:
  *     This algorithm seeks for isolated cells which are refined or flagged
  *     for refinement. This definition is unlike that for
  *     @p{eliminate_unrefined_islands}, which would mean that an island is
@@ -983,12 +983,12 @@ struct TriaNumberCache<3> : public TriaNumberCache<2>
  *     refines the mesh according to a criterion associated with a boundary
  *     integral or if one has rough boundary data.
  *
- *   \item @p{do_not_produce_unrefined_islands}:
+ *   @item @p{do_not_produce_unrefined_islands}:
  *     This flag prevents the occurrence of unrefined islands. In more detail:
  *     It prohibits the coarsening of a cell if 'most of the neighbors' will
  *     be refined after the step.
  *
- * \item @p{patch_level_1}:
+ * @item @p{patch_level_1}:
  *     Ensures patch level 1. As result the triangulation consists of
  *     patches, i.e. of cells that are refined once. It follows that
  *     if at least one of the children of a cell is or will be refined
@@ -998,21 +998,21 @@ struct TriaNumberCache<3> : public TriaNumberCache<2>
  *     @p{eliminate_refined_boundary_islands} will be ignored as they will
  *     be fulfilled automatically.
  *
- *   \item @p{smoothing_on_refinement}:
+ *   @item @p{smoothing_on_refinement}:
  *     This flag sums up all smoothing algorithms which may be performed upon
  *     refinement by flagging some more cells for refinement.
  *
- *   \item @p{smoothing_on_coarsening}:
+ *   @item @p{smoothing_on_coarsening}:
  *     This flag sums up all smoothing algorithms which may be performed upon
  *     coarsening by flagging some more cells for coarsening.
  *
- *   \item @p{maximum_smoothing}:
+ *   @item @p{maximum_smoothing}:
  *     This flag includes all the above ones and therefore combines all
  *     smoothing algorithms implemented.
  *
- *   \item @p{none}:
+ *   @item @p{none}:
  *     Select no smoothing at all.
- *   \end{itemize}
+ *   @end{itemize}
  *
  *
  *   @sect3{Material and boundary information}
@@ -1059,7 +1059,7 @@ struct TriaNumberCache<3> : public TriaNumberCache<2>
  *   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:
- *   \begin{verbatim}
+ *   @begin{verbatim}
  *                                 // open output file
  *     ofstream history("mesh.history");
  *                                 // do 10 refinement steps
@@ -1070,10 +1070,10 @@ struct TriaNumberCache<3> : public TriaNumberCache<2>
  *       tria.save_refine_flags (history);
  *       tria.execute_coarsening_and_refinement ();
  *     };        
- *   \end{verbatim}
+ *   @end{verbatim}
  *
  *   If you want to re-create the grid from the stored information, you write:
- *   \begin{verbatim}
+ *   @begin{verbatim}
  *                                 // open input file
  *     ifstream history("mesh.history");
  *                                 // do 10 refinement steps
@@ -1081,7 +1081,7 @@ struct TriaNumberCache<3> : public TriaNumberCache<2>
  *       tria.load_refine_flags (history);
  *       tria.execute_coarsening_and_refinement ();
  *     };        
- *   \end{verbatim}
+ *   @end{verbatim}
  *
  *   The same scheme is employed for coarsening and the coarsening flags.
  *
@@ -1161,11 +1161,11 @@ struct TriaNumberCache<3> : public TriaNumberCache<2>
  *   component. If a new vertex is created on a side or face at the
  *   boundary, this function is used to compute where it will be
  *   placed. The boundary indicator of the face will be used to
- *   determine the proper component. See \Ref{Boundary} for the
+ *   determine the proper component. See @ref{Boundary} for the
  *   details. Usage with the @p{Triangulation} object is then like this
  *   (let @p{Ball} be a class derived from @p{Boundary<2>}):
  * 
- *   \begin{verbatim}
+ *   @begin{verbatim}
  *     void main () {
  *       Triangulation<2> tria;
  *                                        // set the boundary function
@@ -1192,7 +1192,7 @@ struct TriaNumberCache<3> : public TriaNumberCache<2>
  *           tria.execute_coarsening_and_refinement();
  *         };
  *     };            
- *   \end{verbatim}
+ *   @end{verbatim}
  *
  *   You should take note of one caveat: if you have concave
  *   boundaries, you must make sure that a new boundary vertex does
@@ -1223,8 +1223,8 @@ struct TriaNumberCache<3> : public TriaNumberCache<2>
  *   decides which additional cells to flag for refinement by looking
  *   at the old grid and the refinement flags for each cell.
  *
- *   \begin{itemize}
- *   \item @em{Regularization:} The algorithm walks over all cells checking
+ *   @begin{itemize}
+ *   @item @em{Regularization:} The algorithm walks over all cells checking
  *     whether the present cell is flagged for refinement and a neighbor of the
  *     present cell is refined once less than the present one. If so, flag the
  *     neighbor for refinement. Because of the induction above, there may be no
@@ -1238,9 +1238,9 @@ struct TriaNumberCache<3> : public TriaNumberCache<2>
  *     on lower levels, but if these induce more refinement needed, this is
  *     performed later on when we visit them in out backward running loop.
  *
- *   \item @em{Smoothing:}
- *     \begin{itemize}
- *     \item @p{limit_level_difference_at_vertices}:
+ *   @item @em{Smoothing:}
+ *     @begin{itemize}
+ *     @item @p{limit_level_difference_at_vertices}:
  *       First a list is set up which stores for each vertex
  *       the highest level one of the adjacent cells belongs to. Now, since we did
  *       smoothing in the previous refinement steps also, each cell may only have
@@ -1254,7 +1254,7 @@ struct TriaNumberCache<3> : public TriaNumberCache<2>
  *       refinement, but these are on lower levels, as above, which is why we
  *       may do all kinds of additional flagging in one loop only.
  *
- *     \item @p{eliminate_unrefined_islands}:
+ *     @item @p{eliminate_unrefined_islands}:
  *       For each cell we count the number of neighbors which are refined or
  *       flagged for refinement. If this exceeds the total number of neighbors
  *       (which is the number of faces minus the number of faces of this cell
@@ -1263,7 +1263,7 @@ struct TriaNumberCache<3> : public TriaNumberCache<2>
  *       will need refinement, we will need additional loops of regularization
  *       and smoothing over all cells until nothing changes any more.
  *
- *     \item @p{eliminate_refined_*_islands}:
+ *     @item @p{eliminate_refined_*_islands}:
  *       This one does much the same as the above one, but for coarsening. If
  *       a cell is flagged for refinement or if all of its children are active
  *       and if the number of neighbors which are either active and not flagged
@@ -1277,8 +1277,8 @@ struct TriaNumberCache<3> : public TriaNumberCache<2>
  *       of this classes description.
  *
  *       The same applies as above: several loops may be necessary.
- *     \end{itemize}
- *   \end{itemize}
+ *     @end{itemize}
+ *   @end{itemize}
  *
  *   Regularization and smoothing are a bit complementary in that we check
  *   whether we need to set additional refinement flags when being on a cell
@@ -1297,7 +1297,7 @@ struct TriaNumberCache<3> : public TriaNumberCache<2>
  *   2D. The direction of a line is the direction of point 0 towards point 1. We
  *   define, that allowed cells contain of lines of which the direction is
  *   as follows:
- *   \begin{verbatim}
+ *   @begin{verbatim}
  *          2
  *      3--->---2
  *      |       |
@@ -1305,7 +1305,7 @@ struct TriaNumberCache<3> : public TriaNumberCache<2>
  *      |       |
  *      0--->---1
  *          0
- *   \end{verbatim}
+ *   @end{verbatim}
  *   The number of the vertices and lines is also indicated. This orientation of
  *   lines has to be checked/generated upon construction of a grid and is
  *   preserved upon refinement.
@@ -1323,14 +1323,14 @@ struct TriaNumberCache<3> : public TriaNumberCache<2>
  *   When explicit coordinates are required for points in a cell (e.g for
  *   quadrature formulae or the point of definition of trial functions), we
  *   define the following coordinate system for the unit cell:
- *   \begin{verbatim}
+ *   @begin{verbatim}
  *    y^   3-------2
  *     |   |       |
  *     |   |       |
  *     |   |       |
  *     |   0-------1
  *     *-------------->x
- *   \end{verbatim}
+ *   @end{verbatim}
  *   with vertex 0 being the origin of the coordinate system, vertex 1 having
  *   coordinates @p{(1,0)}, vertex 2 at @p{(1,1)} and vertex 3 at @p{(0,1)}.
  *
@@ -1341,7 +1341,7 @@ struct TriaNumberCache<3> : public TriaNumberCache<2>
  *   faces of hexahedra in three space dimensions. Before giving these 
  *   conventions we declare the following sketch to be the standard way of
  *   drawing 3d pictures of hexahedra:
- *   \begin{verbatim}
+ *   @begin{verbatim}
  *         *-------*        *-------*
  *        /|       |       /       /|
  *       / |       |      /       / |
@@ -1352,7 +1352,7 @@ struct TriaNumberCache<3> : public TriaNumberCache<2>
  *     | /       /      |       | /
  *     |/       /       |       |/
  *     *-------*        *-------*
- *   \end{verbatim}
+ *   @end{verbatim}
  *   The left part of the picture shows the left, bottom and back face of the
  *   cube, while the right one shall be the top, right and front face. You may
  *   recover the whole cube by moving the two parts together into one.
@@ -1363,7 +1363,7 @@ struct TriaNumberCache<3> : public TriaNumberCache<2>
  *   the vertices on a quadrilateral. The vertices on the back face are numbered
  *   similarly by moving the front face to the back (no turning, no twisting, 
  *   just a shift):
- *   \begin{verbatim}
+ *   @begin{verbatim}
  *         7-------6        7-------6
  *        /|       |       /       /|
  *       / |       |      /       / |
@@ -1374,14 +1374,14 @@ struct TriaNumberCache<3> : public TriaNumberCache<2>
  *     | /       /      |       | /
  *     |/       /       |       |/
  *     0-------1        0-------1
- *   \end{verbatim}
+ *   @end{verbatim}
  *
  *   @sect4{Lines}
  *
  *   Here, the same holds as for the vertices: the lines of the front face are
  *   numbered as for the quadrilateral, for the back face they are just shifted.
  *   Finally, the four lines connecting front and back face are numbered:
- *   \begin{verbatim}
+ *   @begin{verbatim}
  *         *---6---*        *---6---*
  *        /|       |       /       /|
  *      11 |       5      11     10 5
@@ -1392,10 +1392,10 @@ struct TriaNumberCache<3> : public TriaNumberCache<2>
  *     3 8       9      3       | 9
  *     |/       /       |       |/
  *     *---0---*        *---0---*
- *   \end{verbatim}
+ *   @end{verbatim}
  *   The directions of the front and back lines is as for the respective faces, while
  *   the connecting lines always point to the back:
- *   \begin{verbatim}
+ *   @begin{verbatim}
  *         *--->---*        *--->---*
  *        /|       |       /       /|
  *       ^ |       ^      ^       ^ ^
@@ -1406,13 +1406,13 @@ struct TriaNumberCache<3> : public TriaNumberCache<2>
  *     ^ ^       ^      ^       | ^
  *     |/       /       |       |/
  *     *--->---*        *--->---*
- *   \end{verbatim}
+ *   @end{verbatim}
  *
  *   @sect4{Faces}
  *
  *   The faces are numbered in the same order as the lines were numbered: front
  *   face, back face, then the four side faces:
- *   \begin{verbatim}
+ *   @begin{verbatim}
  *         *-------*        *-------*
  *        /|       |       /       /|
  *       / |   1   |      /   4   / |
@@ -1423,13 +1423,13 @@ struct TriaNumberCache<3> : public TriaNumberCache<2>
  *     | /   2   /      |   0   | /
  *     |/       /       |       |/
  *     *-------*        *-------*
- *   \end{verbatim}
+ *   @end{verbatim}
  *
  *   The direction of the faces is determined by the numbers the lines have within
  *   a given face. This is like follows:
- *   \begin{itemize}
- *   \item Faces 0 and 1:
- *    \begin{verbatim}
+ *   @begin{itemize}
+ *   @item Faces 0 and 1:
+ *    @begin{verbatim}
  *          *---2---*        *-------*
  *         /|       |       /       /|
  *        / |       1      /       / |
@@ -1440,10 +1440,10 @@ struct TriaNumberCache<3> : public TriaNumberCache<2>
  *      | /       /      3       | /
  *      |/       /       |       |/
  *      *-------*        *---0---*
- *    \end{verbatim}
+ *    @end{verbatim}
  * 
- *   \item Faces 2 and 4:
- *    \begin{verbatim}
+ *   @item Faces 2 and 4:
+ *    @begin{verbatim}
  *          *-------*        *---2---*
  *         /|       |       /       /|
  *        / |       |      3       1 |
@@ -1454,10 +1454,10 @@ struct TriaNumberCache<3> : public TriaNumberCache<2>
  *      | 3       1      |       | /
  *      |/       /       |       |/
  *      *---0---*        *-------*
- *    \end{verbatim} 
+ *    @end{verbatim} 
  * 
- *   \item Faces 3 and 5:
- *    \begin{verbatim}
+ *   @item Faces 3 and 5:
+ *    @begin{verbatim}
  *          *-------*        *-------*
  *         /|       |       /       /|
  *        2 1       |      /       2 1
@@ -1468,30 +1468,30 @@ struct TriaNumberCache<3> : public TriaNumberCache<2>
  *      | 0       /      |       | 0
  *      |/       /       |       |/
  *      *-------*        *-------*
- *    \end{verbatim}
- *   \end{itemize}
+ *    @end{verbatim}
+ *   @end{itemize}
  * 
  *   Due to this numbering, the following lines are identical:
- *   \begin{itemize}
- *   \item Line 0 of face 0, and line 0 of face 2;
- *   \item Line 1 of face 0, and line 3 of face 3;
- *   \item Line 2 of face 0, and line 0 of face 4;
- *   \item Line 3 of face 0, and line 3 of face 5;
- *   \item Line 0 of face 1, and line 2 of face 2;
- *   \item Line 1 of face 1, and line 1 of face 3;
- *   \item Line 2 of face 1, and line 2 of face 4;
- *   \item Line 3 of face 1, and line 1 of face 5;
- *   \item Line 3 of face 2, and line 0 of face 5;
- *   \item Line 1 of face 2, and line 0 of face 3;
- *   \item Line 1 of face 4, and line 2 of face 3;
- *   \item Line 3 of face 4, and line 2 of face 5.
- *   \end{itemize}
+ *   @begin{itemize}
+ *   @item Line 0 of face 0, and line 0 of face 2;
+ *   @item Line 1 of face 0, and line 3 of face 3;
+ *   @item Line 2 of face 0, and line 0 of face 4;
+ *   @item Line 3 of face 0, and line 3 of face 5;
+ *   @item Line 0 of face 1, and line 2 of face 2;
+ *   @item Line 1 of face 1, and line 1 of face 3;
+ *   @item Line 2 of face 1, and line 2 of face 4;
+ *   @item Line 3 of face 1, and line 1 of face 5;
+ *   @item Line 3 of face 2, and line 0 of face 5;
+ *   @item Line 1 of face 2, and line 0 of face 3;
+ *   @item Line 1 of face 4, and line 2 of face 3;
+ *   @item Line 3 of face 4, and line 2 of face 5.
+ *   @end{itemize}
  *
  *
  *   @sect4{Children}
  *
  *   The eight children of a cell are numbered as follows:
- *   \begin{verbatim}
+ *   @begin{verbatim}
  *         *-------*        *-------*
  *        /| 7   6 |       / 7   6 /|
  *       /7|       |      /       /6|
@@ -1502,18 +1502,18 @@ struct TriaNumberCache<3> : public TriaNumberCache<2>
  *     |0/       /      |       |1/
  *     |/0    1 /       | 0   1 |/
  *     *-------*        *-------*
- *   \end{verbatim}
+ *   @end{verbatim}
  *
  *   Taking into account the orientation of the faces, the following
  *   children are adjacent to the respective faces:
- *   \begin{itemize}
- *   \item Face 0: children 0, 1, 2, 3;
- *   \item Face 1: children 4, 5, 6, 7;
- *   \item Face 2: children 0, 1, 5, 4;
- *   \item Face 3: children 1, 5, 6, 2;
- *   \item Face 4: children 3, 2, 6, 7;
- *   \item Face 5: children 0, 4, 7, 3.
- *   \end{itemize}
+ *   @begin{itemize}
+ *   @item Face 0: children 0, 1, 2, 3;
+ *   @item Face 1: children 4, 5, 6, 7;
+ *   @item Face 2: children 0, 1, 5, 4;
+ *   @item Face 3: children 1, 5, 6, 2;
+ *   @item Face 4: children 3, 2, 6, 7;
+ *   @item Face 5: children 0, 4, 7, 3.
+ *   @end{itemize}
  *   You can get these numbers using the @p{GeometryInfo<3>::child_cell_on_face}
  *   function. Each child is adjacent to the vertex with the same number.
  *
@@ -1522,7 +1522,7 @@ struct TriaNumberCache<3> : public TriaNumberCache<2>
  *
  *   We define the following coordinate system for the explicit coordinates of
  *   the vertices of the unit cell:
- *   \begin{verbatim}
+ *   @begin{verbatim}
  *                         7-------6        7-------6
  *                        /|       |       /       /|
  *                       / |       |      /       / |
@@ -1533,7 +1533,7 @@ struct TriaNumberCache<3> : public TriaNumberCache<2>
  *    | /              | /       /      |       | /
  *    |/               |/       /       |       |/
  *    *------>x        0-------1        0-------1
- *   \end{verbatim}
+ *   @end{verbatim}
  *   This convention in conjunction with the numbering of the vertices is a bit
  *   unfortunate, since the vertices 0 through 3 have the coordinates @p{(x,0,z)}
  *   with @p{x} and @p{z} being the same as the @p{x} and @p{y} coordinates of a quad
@@ -1542,16 +1542,16 @@ struct TriaNumberCache<3> : public TriaNumberCache<2>
  *
  *   By the convention laid down as above, the vertices have the following
  *   coordinates:
- *   \begin{itemize}
- *      \item Vertex 0: @p{(0,0,0)};
- *      \item Vertex 1: @p{(1,0,0)};
- *      \item Vertex 2: @p{(1,0,1)};
- *      \item Vertex 3: @p{(0,0,1)};
- *      \item Vertex 4: @p{(0,1,0)};
- *      \item Vertex 5: @p{(1,1,0)};
- *      \item Vertex 6: @p{(1,1,1)};
- *      \item Vertex 7: @p{(0,1,1)}.
- *   \end{itemize}
+ *   @begin{itemize}
+ *      @item Vertex 0: @p{(0,0,0)};
+ *      @item Vertex 1: @p{(1,0,0)};
+ *      @item Vertex 2: @p{(1,0,1)};
+ *      @item Vertex 3: @p{(0,0,1)};
+ *      @item Vertex 4: @p{(0,1,0)};
+ *      @item Vertex 5: @p{(1,1,0)};
+ *      @item Vertex 6: @p{(1,1,1)};
+ *      @item Vertex 7: @p{(0,1,1)}.
+ *   @end{itemize}
  *
  *
  *   @sect3{Warning}
index 2b4c559fec76c0a83d40f6478591309634ae2f88..816e9c9a8718d800bff78e2044bf511c0ab52155 100644 (file)
@@ -37,7 +37,7 @@ class Hexahedron;
 
 /**
  *   Implements the accessor class descibed in the documentation of
- *   the iterator classes (see \Ref{TriaRawIterator}.
+ *   the iterator classes (see @ref{TriaRawIterator}.
  *
  *   This class offers only the basic functionality (stores the necessary
  *   data members, offers comparison operators and the like), but has no
@@ -158,7 +158,7 @@ class TriaAccessor
                                      *  Return the state of the iterator.
                                      *  For the different states an accessor 
                                      *  can be in, refer to the
-                                     *  \Ref{TriaRawIterator} documentation.
+                                     *  @ref{TriaRawIterator} documentation.
                                      */
     IteratorState state () const;
 
@@ -1035,7 +1035,7 @@ class TriaObjectAccessor<2, dim> :  public TriaAccessor<dim>
                                      *  a quad. The @p{i}th vertex is the common
                                      *  one of line @p{i} and @p{(i+3)%4}. See also
                                      *  the introduced convention
-                                     *  (\Ref{Triangulation}).
+                                     *  (@ref{Triangulation}).
                                      */ 
     int vertex_index (const unsigned int i) const;
 
@@ -1751,7 +1751,7 @@ class TriaObjectAccessor<3, dim> :  public TriaAccessor<dim>
  *
  * The following refers to any space dimension:
  * 
- * This class allows access to a {\bf cell}, which is a line in 1D and a quad in
+ * This class allows access to a @em{cell}, which is a line in 1D and a quad in
  * 2D. Cells have more functionality than lines or quads by themselves, for
  * example they can be flagged for refinement, they have neighbors, they have
  * the possibility to check whether they are at the boundary etc. This class
index 907f8f47e7cb86d6f5bb5b5f095647aecaad643b..61dbfd3bdff3b057afecb5235f289b82d6b9e941 100644 (file)
@@ -27,17 +27,17 @@ template <int 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):
- *   \begin{verbatim}
+ *   @begin{verbatim}
  *     ...
  *     Point<2> new_vertex = boundary.get_new_point_on_line (line);
  *     ...
- *   \end{verbatim}
+ *   @end{verbatim}
  *   @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
- *   \begin{verbatim}
+ *   @begin{verbatim}
  *     ...
  *     Point<3> new_line_vertices[4]
  *       = { boundary.get_new_point_on_line (face->line(0)),
@@ -45,14 +45,14 @@ template <int dim> class Triangulation;
  *           boundary.get_new_point_on_line (face->line(2)),
  *           boundary.get_new_point_on_line (face->line(3))  };
  *     ...
- *   \end{verbatim}
+ *   @end{verbatim}
  *   to get the four midpoints of the lines bounding the quad at the
  *   boundary, and after that
- *   \begin{verbatim}
+ *   @begin{verbatim}
  *     ...
  *     Point<3> new_quad_vertex = boundary.get_new_point_on_quad (face);
  *     ...
- *   \end{verbatim}
+ *   @end{verbatim}
  *   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
@@ -124,7 +124,7 @@ class Boundary : public Subscriptor {
 
 
 /**
- *   Specialisation of \Ref{Boundary}<dim>, which places the new point right
+ *   Specialisation of @ref{Boundary}<dim>, which places the new point right
  *   into the middle of the given points. The middle is defined as the
  *   arithmetic mean of the points.
  *
index 4a079c524616227fadee64bc7fb62945696a7f24..70a8695cd61458f6a10764fc03df111853180e36 100644 (file)
@@ -18,7 +18,7 @@
 
 
 /**
- *   Specialisation of \Ref{Boundary}<dim>, which places the new point on
+ *   Specialisation of @ref{Boundary}<dim>, which places the new point on
  *   the boundary of a ball in arbitrary dimension. It works by projecting
  *   the point in the middle of the old points onto the ball. The middle is
  *   defined as the arithmetic mean of the points. 
index 9a4a48ee9a96b376115b47041070c23ac8d31e75..73435e7a6847e00b35ad5d6d584cf130c7362a05 100644 (file)
@@ -40,20 +40,20 @@ template <int dim> class Triangulation;
  *   iterators an iterator of this class provides a @p{->} operator, i.e. you can
  *   write statements like @p{i->set_refine_flag ();}.
  *   
- *   {\bf Note:} Please read the documentation about the prefix and the
+ *   @em{Note:} Please read the documentation about the prefix and the
  *   postfix @p{++} operators in this and the derived classes!
  *   
  *   @sect3{Purpose}
  *
  *   @p{iterators} are used whenever a loop over all lines, quads, cells etc.
  *   is to be performed. These loops can then be coded like this:
- *   \begin{verbatim}
+ *   @begin{verbatim}
  *     cell_iterator i   = tria.begin();
  *     cell_iterator end = tria.end();
  *     for (; i!=end; ++i)
  *       if (cell->at_boundary())
  *         cell->set_refine_flag();
- *   \end{verbatim}
+ *   @end{verbatim}
  *   Note the usage of @p{++i} instead of @p{i++} since this does not involve
  *   temporaries and copying. You should also really use a fixed value
  *   @p{end} rather than coding @p{for (; i!=tria.end(); ++i)}, since
@@ -105,7 +105,7 @@ template <int dim> class Triangulation;
  *   input and bidirectional iterators as stated by the C++ standard and
  *   the STL documentation. It is therefore possible to use the functions
  *   from the @em{algorithm section} of the C++ standard, e.g. @p{count_if}
- *   (see the documentation for \Ref{Triangulation} for an example) and
+ *   (see the documentation for @ref{Triangulation} for an example) and
  *   several others.
  *   
  *
@@ -117,7 +117,7 @@ template <int dim> class Triangulation;
  *   also do not want to destroy the ordering induced by the numbering
  *   in the vectors). Therefore not all raw iterators point to valid objects.
  *   
- *   There are two derived versions of this class: \Ref{TriaIterator}
+ *   There are two derived versions of this class: @ref{TriaIterator}
  *   objects, which only loop over used (valid) cells and
  *   @p{TriaActiveIterator} objects
  *   which only loop over active cells (not refined).
@@ -129,30 +129,30 @@ template <int dim> class Triangulation;
  *   only becomes useful when assigned an @p{Accessor} (the second template
  *   parameter), which really does the access to data. An @p{Accessor} has to
  *   fulfil some requirements:
- *   \begin{itemize}
- *     \item It must have two members named @p{present_level} and @p{present_index}
+ *   @begin{itemize}
+ *     @item It must have two members named @p{present_level} and @p{present_index}
  *       storing the address of the element in the triangulation presently
  *       pointed to. Furthermore, the three @p{Tria{Raw| |Active}Iterator} classes
  *       have to be friends to the accessor or these data members must be public.
- *     \item It must have a constructor which takes 1. a @p{Triangulation<dim>*},
+ *     @item It must have a constructor which takes 1. a @p{Triangulation<dim>*},
  *       2. and 3. and integer, denoting the initial level and index.
- *     \item For the @p{TriaIterator} and the @p{TriaActiveIterator} class, it must
+ *     @item For the @p{TriaIterator} and the @p{TriaActiveIterator} class, it must
  *       have a member function @p{bool used()}, for the latter a member function
  *       @p{bool active()}.
- *     \item It must have void operators @p{++} and @p{--}.
- *     \item It must declare a local @p{typedef} @p{AccessorData} which states
+ *     @item It must have void operators @p{++} and @p{--}.
+ *     @item It must declare a local @p{typedef} @p{AccessorData} which states
  *       the data type the accessor expects to get passed as fourth constructor
  *       argument. By declaring a local data type, the respective iterator
  *       class may type-safely enforce that data type to be one of its own
  *       constructor argument types. If an accessor class does not need
  *       additional data, this type shall be @p{void}.
- *   \end{itemize}
+ *   @end{itemize}
  *   Then the iterator is able to do what it is supposed to. All of the necessary
  *   functions are implemented in the @p{Accessor} base class, but you may write
  *   your own version (non-virtual, since we use templates) to add functionality.
  *
  *   There is a standard implementation, using classes which are derived from
- *   \Ref{TriaAccessor}. These classes point to @p{Line}s, @p{Quad}s and the like.
+ *   @ref{TriaAccessor}. These classes point to @p{Line}s, @p{Quad}s and the like.
  *   For advanced use of the iterator classes, derive classes from
  *   @p{{Line|Quad|Cell}Accessor} which also dereference data structures in other
  *   objects, e.g. in a finite element context. An iterator with such an accessor
@@ -252,11 +252,11 @@ class TriaRawIterator : public bidirectional_iterator<Accessor,int> {
                                      * Through this constructor, it is also
                                      * possible to construct object for
                                      * derived iterators:
-                                     * \begin{verbatim}
+                                     * @begin{verbatim}
                                      * DoFCellAccessor dof_accessor;
                                      * Triangulation::active_cell_iterator cell
                                      *   = accessor;
-                                     * \end{verbatim}
+                                     * @end{verbatim}
                                      */
     TriaRawIterator (const Accessor &a);
     
@@ -500,7 +500,7 @@ class TriaRawIterator : public bidirectional_iterator<Accessor,int> {
 
 
 /**
- *   This specialization of \Ref{TriaRawIterator} provides access only to the
+ *   This specialization of @ref{TriaRawIterator} provides access only to the
  *   @em{used} lines, quads, cells, etc.
  */
 template <int dim, typename Accessor>
@@ -645,7 +645,7 @@ class TriaIterator : public TriaRawIterator<dim,Accessor> {
 
 
 /**
- *   This specialization of \Ref{TriaIterator} provides access only to the
+ *   This specialization of @ref{TriaIterator} provides access only to the
  *   @em{active} lines, quads, cells, etc. An active cell is a cell which is not
  *   refined and thus a cell on which calculations on the finest level are done.
  */
index f4b423ded0a6e1531f16c2c8402b5d15968541c8..c8fc2b696d07fc97b13fe02ec81f5d0799c562bf 100644 (file)
@@ -95,7 +95,7 @@ class TriangulationLevel<0> {
                                      *  at the boundary), @p{level=index=-1}
                                      *  is set.
                                      *
-                                     *  {\bf Conventions:} The @p{i}th neighbor
+                                     *  @em{Conventions:} The @p{i}th neighbor
                                      *  of a cell is the one which shares
                                      *  the @p{i}th face (@p{Line} in 2D, @p{Quad}
                                      *  in 3D) of this cell.
index fd65894c5b579e55ce427f14f29e105a0ccb558f..ae1f046c67f54d502d46752522cef432afd5be75 100644 (file)
@@ -263,7 +263,7 @@ class MGTransferBase : public Subscriptor
  * Basic class for preconditioning by multigrid.
  *
  * The functionality of the multigrid method is restricted to defect
- * correction. It is {\bf not} iterative and the start solution is
+ * correction. It is @em{not} iterative and the start solution is
  * always zero. Since by this $u^E_l$ and $u^A_l$ (see report on
  * multigrid) are always zero, restriction is simplified a lot and
  * maybe even the seam condition on grids is oblivious. Still, I am
index 18be3c550f05a5556cabbf1010f07c799199293f..c09d075ac2406b0585602089a43065239a5df4af 100644 (file)
@@ -190,7 +190,7 @@ class MGDoFObjectAccessor<0, dim>
 /**
  * Grant access to the degrees of freedom located on lines.
  * This class follows mainly the route laid out by the accessor library
- * declared in the triangulation library (\Ref{TriaAccessor}). It enables
+ * declared in the triangulation library (@ref{TriaAccessor}). It enables
  * the user to access the degrees of freedom on the lines (there are similar
  * versions for the DoFs on quads, etc), where the dimension of the underlying
  * triangulation does not really matter (i.e. this accessor works with the
@@ -199,7 +199,7 @@ class MGDoFObjectAccessor<0, dim>
  *
  * @sect3{Usage}
  *
- * The \Ref{DoFDimensionInfo} classes inherited by the \Ref{DoFHandler} classes
+ * The @ref{DoFDimensionInfo} classes inherited by the @ref{DoFHandler} classes
  * declare typedefs to iterators using the accessors declared in this class
  * hierarchy tree. Usage is best to happens through these typedefs, since they
  * are more secure to changes in the class naming and template interface as well
index d1661cdc955af0b6961d5d32d50d309663a13761..4a6abcc1c6f9eabfabdedd34e82d9f7b72d2bc4b 100644 (file)
@@ -24,7 +24,7 @@ template <int celldim, int dim> class MGDoFObjectAccessor;
 
 /**
  * Define some types which differ between the dimensions. This class
- * is analogous to the \Ref{TriaDimensionInfo} class hierarchy.
+ * is analogous to the @ref{TriaDimensionInfo} class hierarchy.
  * 
  * @see MGDoFDimensionInfo<1>
  * @see MGDoFDimensionInfo<2>
@@ -36,7 +36,7 @@ class MGDoFDimensionInfo;
 /**
  * Define some types for the DoF handling in one dimension.
  *
- * The types have the same meaning as those declared in \Ref{TriaDimensionInfo<2>}.
+ * The types have the same meaning as those declared in @ref{TriaDimensionInfo<2>}.
  */
 class MGDoFDimensionInfo<1> {
   public:
@@ -65,7 +65,7 @@ class MGDoFDimensionInfo<1> {
 /**
  * Define some types for the DoF handling in two dimensions.
  *
- * The types have the same meaning as those declared in \Ref{TriaDimensionInfo<2>}.
+ * The types have the same meaning as those declared in @ref{TriaDimensionInfo<2>}.
  */
 class MGDoFDimensionInfo<2> {
   public:
@@ -94,7 +94,7 @@ class MGDoFDimensionInfo<2> {
 /**
  * Define some types for the DoF handling in two dimensions.
  *
- * The types have the same meaning as those declared in \Ref{TriaDimensionInfo<2>}.
+ * The types have the same meaning as those declared in @ref{TriaDimensionInfo<2>}.
  */
 class MGDoFDimensionInfo<3> {
   public:
index 49eecc2283331c281d61670141b80e9c09f76253..b19feb219ace8a5ea858b94fc28ade231e1c6b81 100644 (file)
@@ -150,7 +150,7 @@ class Assembler : public DoFCellAccessor<dim>
                                      * Structure to be passed upon
                                      * construction of an assembler object
                                      * through the iterator object. See
-                                     * \Ref{TriaRawIterator} for a discussion
+                                     * @ref{TriaRawIterator} for a discussion
                                      * of this mechanism.
                                      */
     struct AssemblerData {
index 92e2f0d9f194f1eda01a1d5625b4c5135425b5e1..626ceb09099b7c40970b05a6acb7fa7ad7589939 100644 (file)
@@ -46,19 +46,19 @@ template <int dim> class Equation;
  *
  * The @p{assemble} member function does the assemblage of the system matrix and
  * the given number of right hand sides. It does the following steps:
- * \begin{itemize}
- *   \item Initialize solution vector with zero entries.
- *   \item Create sparsity pattern of the system matrix and condense it with
+ * @begin{itemize}
+ *   @item Initialize solution vector with zero entries.
+ *   @item Create sparsity pattern of the system matrix and condense it with
  *     the constraints induced by hanging nodes.
- *   \item Initialize an assembler object.
- *   \item Loop over all cells and assemble matrix and vectors using the given
+ *   @item Initialize an assembler object.
+ *   @item Loop over all cells and assemble matrix and vectors using the given
  *     quadrature formula and the equation object which contains the weak
  *     formulation of the equation.
- *   \item Apply Dirichlet boundary conditions. See the section on boundary
+ *   @item Apply Dirichlet boundary conditions. See the section on boundary
  *     conditions for more details.
- *   \item Condense the system matrix and right hand side with the constraints
+ *   @item Condense the system matrix and right hand side with the constraints
  *     induced by hanging nodes.
- * \end{itemize}
+ * @end{itemize}
  *
  * The @p{assemble} function needs an object describing the boundary of the domain,
  * since for higher order finite elements, we may be tempted to use curved faces
@@ -80,7 +80,7 @@ template <int dim> class Equation;
  * During assemblage of matrices and right hand side, use is made of dirichlet
  * boundary conditions (in short: bc) specified to the @p{assemble} function. You
  * can specify a list of pairs of boundary indicators (of type @p{unsigned char};
- * see the section in the documentation of the \Ref{Triangulation} class for more
+ * see the section in the documentation of the @ref{Triangulation} class for more
  * details) and the according functions denoting the dirichlet boundary values
  * of the nodes on boundary faces with this boundary indicator.
  *
index 31336cd2eaedc3ed4fa1b0f95a9fecc35c82a6d0..93db1b6f2a6702e328fe81b263bdedbccad9ca97 100644 (file)
@@ -152,15 +152,15 @@ class EpsOutputData;
  * Vectors are added as usual by @p{add_data_vector}. Then one has to
  * decide, wether to produce a 2D or 3D plot. This is done by setting
  * @p{height_info} to 
- * \begin{description
- *   \item[NoHeight] for 2D-Output (or Top-View thats the same by no
+ * @begin{itemize
+ *   @item @em{NoHeight} for 2D-Output (or Top-View thats the same by no
  *     turning is done) or to
- *   \item[HeightVector] for 3D-Output. You have to attach a
+ *   @item @em{HeightVector} for 3D-Output. You have to attach a
  *     @p{dof_data_vector} to actually get 3D. If you don't then output
  *     will be generated in 2D.
- *   \item[DefaultHeight] is 3D if there is a @p{dof_data_vector} and 2D if
+ *   @item @em{DefaultHeight} is 3D if there is a @p{dof_data_vector} and 2D if
  *     none is present.
- * \end{description}
+ * @end{itemize}
  * For 3D-Output one has to set @p{azimuth} and @p{elevation} for the
  * angle of view and @p{height_vector} to the number of the @p{dof_data}
  * vector that provides the height information to be used. The default
@@ -169,32 +169,32 @@ class EpsOutputData;
  *
  * The cells can be shaded in four different modes, controlled by the
  * attribute @p{cell_shading}:
- * \begin{enumerate}
- *   \item[NoShading] provides transparent shading.
- *   \item[ShadingVector] uses a cell vector to do shading. The number
+ * @begin{enumerate}
+ *   @item @em{NoShading} provides transparent shading.
+ *   @item @em{ShadingVector} uses a cell vector to do shading. The number
  *     of the cell vector to be uses is provided in @p{cell_vector}. To
  *     scale the cell vector there is the method @p{color}. It is called
  *     with the actual value of the cell, the maximum and the minimum
  *     value of a cell in the cell vector. It returns three values for
  *     red, green and blue. If there no @p{cell_data} vector than there is
  *     transparent shading.
- *   \item[LightShaded] just shades the plot. This is controlled by
+ *   @item @em{LightShaded} just shades the plot. This is controlled by
  *     the vector @p{light} which stores the direction of the light 
  *     beams. This is done only if there is height information.
- *   \item[DefaultShading] is controlled by presence of different
+ *   @item @em{DefaultShading} is controlled by presence of different
  *     vectors. If there no height information then do no
  *     shading. Otherwise if there is @p{cell_data} use this for shading.
  *     Otherwise do light shading.
- * \end{enumerate}
+ * @end{enumerate}
  *
  * Finnaly one can choose to mark the cell boundaries by setting
  * @p{cell_boundary_shading}. It can take one of four values:
- * \begin{itemize}
- *   \item NoBoundary for no cell boundaries,
- *   \item DefaultBoundary or
- *   \item BlackBoundary for black cell boundaries,
- *   \item WhiteBoundary for white cell boundaries, 
- * \end{itemize}
+ * @begin{itemize}
+ *   @item NoBoundary for no cell boundaries,
+ *   @item DefaultBoundary or
+ *   @item BlackBoundary for black cell boundaries,
+ *   @item WhiteBoundary for white cell boundaries, 
+ * @end{itemize}
  *
  * Another interesting feature is that you can write multiple
  * eps-pictures to one file by just doing several invocations of
@@ -349,14 +349,14 @@ class DataOut_Old {
                                      * suffix with a given output format
                                      * usually has. At present the following
                                      * formats are defined:
-                                     * \begin{itemize}
-                                     * \item @p{ucd}: @p{.inp}
-                                     * \item @p{gnuplot} and @p{gnuplot_draft}:
+                                     * @begin{itemize}
+                                     * @item @p{ucd}: @p{.inp}
+                                     * @item @p{gnuplot} and @p{gnuplot_draft}:
                                      *    @p{.gnuplot}
-                                     * \item @p{povray_mesh}: @p{.pov}
-                                     * \item @p{eps}: @p{.eps}
-                                     * \item @p{gmv}: @p{.gmv}.
-                                     * \end{itemize}
+                                     * @item @p{povray_mesh}: @p{.pov}
+                                     * @item @p{eps}: @p{.eps}
+                                     * @item @p{gmv}: @p{.gmv}.
+                                     * @end{itemize}
                                      *
                                      * Since this function does not need data
                                      * from this object, it is static and can
index 8b04cc83fbe0442dd44e3a9af09e56a188cb3619..82f60b61be57511fa8628de9e15ce8188ed7c670 100644 (file)
@@ -35,7 +35,7 @@ template <int dim> class DoFHandler;
  * vectors which will later be written to a file in some format. Instead of
  * pondering about the different functions, an example is probably the best
  * way:
- * \begin{verbatim}
+ * @begin{verbatim}
  *   ...
  *   ...   // compute solution, which is of type Vector<double>
  *   ...   // and contains nodal values
@@ -58,7 +58,7 @@ template <int dim> class DoFHandler;
  *   data_out.write_xxx (output_file);
  *
  *   data_out.clear();
- * \end{verbatim}
+ * @end{verbatim}
  *
  * @p{attach_dof_handler} tells this class that all future operations are to take
  * place with the @p{DoFHandler} object and the triangulation it lives on. We then
index dcc1eb43d3910da15f518ced2fd89fa9ce5102eb..be16959583cb6715784b77e2b282044a10bf3cd3 100644 (file)
@@ -66,7 +66,7 @@ template <int dim> class DoFHandler;
  * which is suitable for quadratic finite elements in space, for
  * example.
  *
- * \begin{verbatim}
+ * @begin{verbatim}
  *   DataOutStack<dim> data_out_stack;
  *
  *                                  // first declare the vectors
@@ -94,7 +94,7 @@ template <int dim> class DoFHandler;
  *       data_out_stack.build_patches (2);
  *       data_out_stack.finish_parameter_value ();
  *     };
- * \end{verbatim}
+ * @end{verbatim}
  *
  * @author Wolfgang Bangerth, 1999
  */
index 978636baf98a0d09da1612dba860ecbd01d9c309..f391330082121f1cddb509fc33f455e0123b9293 100644 (file)
@@ -120,8 +120,8 @@ template <int dim> class FESubfaceValues;
  *  
  *  If the face is at the boundary, i.e. there is no neighboring cell to which
  *  the jump in the gradiend could be computed, there are two possibilities:
- *  \begin{itemize}
- *  \item The face belongs to a Dirichlet boundary. Then the face is not
+ *  @begin{itemize}
+ *  @item The face belongs to a Dirichlet boundary. Then the face is not
  *    considered, which can be justified looking at a dual problem technique and
  *    should hold exactly if the boundary can be approximated exactly by the
  *    finite element used (i.e. it is a linear boundary for linear finite elements,
@@ -138,15 +138,15 @@ template <int dim> class FESubfaceValues;
  *    store a zero for this face, which makes summing up the contributions of
  *    the different faces to the cells easier.
  *
- *  \item The face belongs to a Neumann boundary.  In this case, the
+ *  @item The face belongs to a Neumann boundary.  In this case, the
  *    contribution of the face $F\in\partial K$ looks like
  *    $$ \int_F \left|g-a\frac{\partial u_h}{\partial n}\right|^2 ds $$
  *    where $g$ is the Neumann boundary function. If the finite element is
  *    vector-valued, then obviously the function denoting the Neumann boundary
  *    conditions needs to be vector-valued as well.
  *
- *  \item No other boundary conditions are considered.
- *  \end{itemize}
+ *  @item No other boundary conditions are considered.
+ *  @end{itemize}
  *  The object describing the boundary conditions is obtained from the
  *  triangulation.
  *
index cf2d5f00f6f3fdf2dc954cf69fb62c832fe86474..e808aa89b6231c1e4ad39cc7ce75105dae063e62 100644 (file)
  * @sect3{Ways to generate the intervals}
  *
  * At present, the following schemes for interval spacing are implemented:
- * \begin{itemize}
- * \item Linear spacing: The intervals are distributed in constant steps
+ * @begin{itemize}
+ * @item Linear spacing: The intervals are distributed in constant steps
  *    between the minimum and maximum values of the data.
- * \item Logaritmic spacing: The intervals are distributed in constant
+ * @item Logaritmic spacing: The intervals are distributed in constant
  *    steps between the minimum and maximum values of the logs of the values.
  *    This scheme is only useful if the data has only positive values.
  *    Negative and zero values are sorted into the leftmost interval.
- * \end{itemize}
+ * @end{itemize}
  *
  * To keep programs extendible, you can use the two functions
  * @p{get_interval_spacing_names} and @p{parse_interval_spacing}, which always
index 95982c09bf9ecf624629dde99b80b61c6427f798..28d12b55bfc53823b47b7e784d0254d2d0f70a68 100644 (file)
@@ -57,8 +57,8 @@ template <int dim> class Equation;
  * @sect3{Supported matrices}
  *
  * At present there are functions to create the following matrices:
- * \begin{itemize}
- * \item @p{create_mass_matrix}: create the matrix with entries
+ * @begin{itemize}
+ * @item @p{create_mass_matrix}: create the matrix with entries
  *   $m_{ij} = \int_\Omega \phi_i(x) \phi_j(x) dx$. Here, the $\phi_i$
  *   are the basis functions of the finite element space given.
  *   This function uses the @p{MassMatrix} class.
@@ -92,7 +92,7 @@ template <int dim> class Equation;
  *   parameters, you need to pass a function object representing the
  *   respective number of components.
  *
- * \item @p{create_laplace_matrix}: there are two versions of this; the
+ * @item @p{create_laplace_matrix}: there are two versions of this; the
  *   one which takes the @p{Function<dim>} object creates
  *   $a_{ij} = \int_\Omega a(x) \nabla\phi_i(x) \nabla\phi_j(x) dx$,
  *   $a$ being the given function, while the other one assumes that
@@ -104,7 +104,7 @@ template <int dim> class Equation;
  *   If the finite element in use presently has more than only one
  *   component, this function may not be overly useful and presently
  *   throws an error.
- * \end{itemize}
+ * @end{itemize}
  *
  * All created matrices are `raw': they are not condensed, i.e. hanging
  * nodes are not eliminated. The reason is that you may want to add
@@ -518,8 +518,8 @@ class MatrixTools : public MatrixCreator<dim>
  *
  * The useful use of this object is therefore probable one of the following
  * cases:
- * \begin{itemize}
- * \item Mass lumping: use an @p{Assembler} object and a special quadrature
+ * @begin{itemize}
+ * @item Mass lumping: use an @p{Assembler} object and a special quadrature
  *   formula to voluntarily evaluate the mass matrix incorrect. For example
  *   by using the trapezoidal formula, the mass matrix will become a
  *   diagonal (at least if no hanging nodes are considered). However, there
@@ -527,7 +527,7 @@ class MatrixTools : public MatrixCreator<dim>
  *   scaling the diagonal elements of the unit matrix by the area element
  *   of the respective cell.
  *
- * \item Nonconstant coefficient: if the coefficient varies considerably over
+ * @item Nonconstant coefficient: if the coefficient varies considerably over
  *   each element, there is no way around this class. However, there are many
  *   cases where it is sufficient to assume that the function be constant on
  *   each cell (taking on its mean value throughout the cell for example, or
@@ -539,7 +539,7 @@ class MatrixTools : public MatrixCreator<dim>
  *   if the density or other mechanical properties vary with the space
  *   coordinate.
  *
- * \item Simple plugging together of system matrices: if the system matrix has
+ * @item Simple plugging together of system matrices: if the system matrix has
  *    the form $s_{ij} = m_{ij} + \alpha a_{ij}$, for example, with $M$ and
  *    $A$ being the mass and laplace matrix, respectively (this matrix $S$
  *    occurs in the discretization of the heat and the wave equation, amoung
@@ -550,7 +550,7 @@ class MatrixTools : public MatrixCreator<dim>
  *    justifyable to quickly try something out. In the further process it
  *    may be useful to replace this behaviour by more sophisticated methods,
  *    however.
- * \end{itemize}
+ * @end{itemize}
  */
 template <int dim>
 class MassMatrix :  public Equation<dim> {
index 951dd7bdff470754d927946e977b79585301d1d9..d9067d437bf4e9dbe4ee93bf39c22ddc27567082 100644 (file)
  * coarsening is much more complicated to organize 
  * (see further documentation below) than interpolation while pure refinement,
  * @p{SolutionTransfer} offers two possible usages.
- * \begin{itemize}
- * \item If the grid will only be purely refined
+ * @begin{itemize}
+ * @item If the grid will only be purely refined
  * (i.e. not locally coarsened) then use @p{SolutionTransfer} as follows
- * \begin{verbatim}
+ * @begin{verbatim}
  * SolutionTransfer<dim, double> soltrans(*dof_handler);
  * soltrans.prepare_for_pure_refinement();
  *                                     // some refinement e.g.
  *                                     // more functions
  * soltrans.refine_interpolate(sol2, interpolated_sol2);
  * ...
- * \end{verbatim}
- * \item If the grid will be coarsenend and refined
+ * @end{verbatim}
+ * @item If the grid will be coarsenend and refined
  * then use @p{SolutionTransfer} as follows
- * \begin{verbatim}
+ * @begin{verbatim}
  * SolutionTransfer<dim, double> soltrans(*dof_handler);
  *                                     // some refinement e.g.
  * tria->refine_and_coarsen_fixed_fraction(error_indicator, 0.3, 0.05);
@@ -64,7 +64,7 @@
  * tria->execute_coarsening_and_refinement ();
  * dof_handler->distribute_dofs (fe);
  * soltrans.interpolate(solution, interpolated_solution);
- * \end{verbatim}
+ * @end{verbatim}
  *
  * Multiple calling of the function 
  * @p{interpolate (const Vector<number> &in, Vector<number> &out)}
@@ -74,7 +74,7 @@
  * and using the respective @p{prepare_for_coarsening_and_refinement} function 
  * taking several vectors as input before actually refining and coarsening the
  * triangulation (see there).
- * \end{itemize}
+ * @end{itemize}
  *
  * For deleting all stored data in @p{SolutionTransfer} and reinitializing it
  * use the @p{clear()} function.
@@ -88,8 +88,8 @@
  *
  * @sect3{Implementation}
  *
- * \begin{itemize}
- * \item Solution transfer while pure refinement. Assume that we have got a
+ * @begin{itemize}
+ * @item Solution transfer while pure refinement. Assume that we have got a
  * solution vector on the current (original) grid.
  * Each entry of this vector belongs to one of the
  * DoFs of the discretisation. If we now refine the grid then the calling of
  * The @p{refine_interpolate(in,out)} function can be called multiplely for
  * arbitrary many discrete functions (solution vectors) on the original grid. 
  *
- * \item Solution transfer while coarsening and refinement. After 
+ * @item Solution transfer while coarsening and refinement. After 
  * calling @p{Triangulation::prepare_coarsening_and_refinement} the
  * coarsen flags of either all or none of the children of a 
  * (father-)cell are set. While coarsening 
  * of the @p{prepare_for_coarsening_and_refinement(all_in)} function. Hence 
  * @p{interpolate(all_in, all_out)} can (in contrast to 
  * @p{refine_interpolate(in, out)}) only be called once.
- * \end{itemize}
+ * @end{itemize}
  *
  * @author Ralf Hartmann, 1999
  */
index 63ab5416af71df757c64756a846e9a6d9f45ee8f..9cc5e757dcb6d8859cd3732335fdbf35c4c6c3c7 100644 (file)
@@ -70,7 +70,7 @@
  * perform another sweep on these refined meshes. A total run will therefore
  * often be a sequence of several sweeps. The global setup therefore looks
  * like this:
- * \begin{verbatim}
+ * @begin{verbatim}
  *    for sweep=0 to n_sweeps-1
  *    {
  *      for i=0 to n_timesteps-1
@@ -98,7 +98,7 @@
  *        notify timestep i of the end of the sweep, e.g. for cleanups,
  *        deletion of temporary files, etc.
  *    }
- * \end{verbatim}
+ * @end{verbatim}
  * The user may specify that a loop shall run forward or backward (the latter
  * being needed for the solution of global dual problems, for example).
  *
  * data of the last two time steps, the following pseudocode described
  * what the centeral loop function of this class will do when we move
  * from timestep @p{n-1} to timestep @p{n}:
- * \begin{verbatim}
+ * @begin{verbatim}
  *   wake up timestep n+1 with signal 1
  *   wake up timestep n with signal 0
  *   do computation on timestep n
  *   let timestep n-2 sleep with signal 2
  *
  *   move from n to n+1
- * \end{verbatim}
+ * @end{verbatim}
  * The signal number here denotes the distance of the timestep being sent
  * the signal to the timestep where computations are done on. The calls to
  * the @p{wake_up} and @p{sleep} functions with signal 0 could in principle
  *
  * From the given sketch above, it is clear that each time step object sees
  * the following sequence of events:
- * \begin{verbatim}
+ * @begin{verbatim}
  *   wake up with signal 1
  *   wake up signal 0
  *   do computation
  *   sleep with signal 0
  *   sleep with signal 1
  *   sleep with signal 2
- * \end{verbatim}
+ * @end{verbatim}
  * This pattern is repeated for each loop in each sweep.
  *
  * For the different loops within each sweep, the numbers of timesteps
  *
  * The main loop of a program using this class will usually look like
  * the following one, taken modified from the wave program:
- * \begin{verbatim}
+ * @begin{verbatim}
  *   template <int dim>
  *   void TimeDependent_Wave<dim>::run_sweep (const unsigned int sweep_no)
  *   {
  *     for (unsigned int sweep=0; sweep<number_of_sweeps; ++sweep)
  *       timestep_manager.run_sweep (sweep);
  *   };
- * \end{verbatim}
+ * @end{verbatim}
  * Here, @p{timestep_manager} is an object of type @p{TimeDependent_Wave}, which
  * is a class derived from @p{TimeDependent}. @p{start_sweep}, 
  * @p{solve_primal_problem}, @p{solve_dual_problem}, @p{postprocess} and @p{end_sweep}
  * 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:
- * \begin{verbatim}
+ * @begin{verbatim}
  *   void TimeDependent::start_sweep (const unsigned int s) 
  *   {
  *     sweep_no = s;
  *             timestepping_data_primal,
  *             forward);
  *   };
- * \end{verbatim}
+ * @end{verbatim}
  * 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
  * the @p{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}:
- * \begin{verbatim}
+ * @begin{verbatim}
  *   ...
  *   compute the thresholds for refinement
  *   ...
  *                                                            bottom_threshold)),
  *            TimeDependent::TimeSteppingData (0,1),
  *            TimeDependent::forward);
- * \end{verbatim}
+ * @end{verbatim}
  * @p{TimeStepBase_Wave<dim>::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
  * 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 @p{0..n_timesteps-1}.
- * \begin{verbatim}
+ * @begin{verbatim}
  *   template <typename InitFunctionObject, typename LoopFunctionObject>
  *   void TimeDependent::do_loop (InitFunctionObject      init_function,
  *                          LoopFunctionObject      loop_function,
  *       for (int look_back=0; look_back<=timestepping_data.look_back; ++look_back)
  *         timesteps[step-look_back]->sleep(look_back);
  *   };
- * \end{verbatim}
+ * @end{verbatim}
  *
  *
  * @author Wolfgang Bangerth, 1999
@@ -485,10 +485,10 @@ class TimeDependent
                                      *
                                      * This mechanism usually will result
                                      * in a set-up loop like this
-                                     * \begin{verbatim}
+                                     * @begin{verbatim}
                                      * for (i=0; i<N; ++i)
                                      *   manager.add_timestep(new MyTimeStep());
-                                     * \end{verbatim}
+                                     * @end{verbatim}
                                      */
     void add_timestep (TimeStepBase *new_timestep);
 
@@ -1459,24 +1459,24 @@ struct TimeStepBase_Tria<dim>::Flags
 /**
  * This structure is used to tell the @p{TimeStepBase_Tria} class how grids should
  * be refined. Before we explain all the different variables, fist some terminology:
- * \begin{itemize}
- * \item Correction: after having flagged some cells of the triangulation for
+ * @begin{itemize}
+ * @item Correction: after having flagged some cells of the triangulation for
  *   following some given criterion, we may want to change the number of flagged
  *   cells on this grid according to another criterion that the number of cells
  *   may be only a certain fraction more or less then the number of cells on
  *   the previous grid. This change of refinement flags will be called
  *   "correction" in the sequel.
- * \item Adaption: in order to make the change between one grid and the next not
+ * @item Adaption: in order to make the change between one grid and the next not
  *   to large, we may want to flag some additional cells on one of the two
  *   grids such that there are not too grave differences. This process will
  *   be called "adaption".
- * \end{itemize}
+ * @end{itemize}
  *
  *
  * @sect3{Description of flags}
  *
- * \begin{itemize}
- * \item @p{max_refinement_level}: Cut the refinement of cells at a given level.
+ * @begin{itemize}
+ * @item @p{max_refinement_level}: Cut the refinement of cells at a given level.
  *   This flag does not influence the flagging of cells, so not more cells
  *   on the coarser levels are flagged than usual. Rather, the flags are all
  *   set, but when it comes to the actual refinement, the maximum refinement
@@ -1486,7 +1486,7 @@ struct TimeStepBase_Tria<dim>::Flags
  *   refinement with adaptive refinement when you don't want the latter
  *   to refine more than the global refinement.
  *
- * \item @p{first_sweep_with_correction}: When using cell number correction
+ * @item @p{first_sweep_with_correction}: When using cell number correction
  *   as defined above, it may be worth while to start with this only in
  *   later sweeps, not already in the first one. If this variable is
  *   zero, then start with the first sweep, else with a higher one. The
@@ -1495,18 +1495,18 @@ struct TimeStepBase_Tria<dim>::Flags
  *   the sweeps where we start to be interested in the actual results of
  *   the computations.
  *
- * \item @p{min_cells_for_correction}: If we want a more free process of
+ * @item @p{min_cells_for_correction}: If we want a more free process of
  *   grid development, we may want to impose less rules for grids with few
  *   cells also. This variable sets a lower bound for the cell number of
  *   grids where corrections are to be performed.
  *
- * \item @p{cell_number_corridor_top}: Fraction of the number of cells by
+ * @item @p{cell_number_corridor_top}: Fraction of the number of cells by
  *   which the number of cells of one grid may be higher than that on the
  *   previous grid. Common values are 10 per cent (i.e. 0.1). The naming
  *   of the variable results from the goal to define a target corridor
  *   for the number of cells after refinement has taken place.
  *
- * \item @p{cell_number_corridor_bottom}: Fraction of the number of cells by
+ * @item @p{cell_number_corridor_bottom}: Fraction of the number of cells by
  *   which the number of cells of one grid may be lower than that on the
  *   previous grid. Common values are 5 per cent (i.e. 0.05). Usually this
  *   number will be smaller than @p{cell_number_corridor_top} since an
@@ -1520,7 +1520,7 @@ struct TimeStepBase_Tria<dim>::Flags
  *   direction is reversed, so the two values defining the cell number
  *   corridor should be about equal.
  *
- * \item @p{correction_relaxations}: This is a list of pairs of number with the
+ * @item @p{correction_relaxations}: This is a list of pairs of number with the
  *   following meaning: just as for @p{min_cells_for_correction}, it may be
  *   worth while to reduce the requirements upon grids if the have few cells.
  *   The present variable stores a list of cell numbers along with some values
@@ -1541,7 +1541,7 @@ struct TimeStepBase_Tria<dim>::Flags
  *   can use as a default value. It is an empty list and thus defines no
  *   relaxations.
  *
- * \item @p{cell_number_correction_steps}: Usually, if you want the number of
+ * @item @p{cell_number_correction_steps}: Usually, if you want the number of
  *   cells to be corrected, the target corridor for the cell number is computed
  *   and some additional cells are flagged or flags are removed. But since
  *   the cell number resulting after flagging and deflagging can not be
@@ -1552,7 +1552,7 @@ struct TimeStepBase_Tria<dim>::Flags
  *   regularly. Setting the variable to zero will result in no correction
  *   steps at all.
  *
- * \item @p{mirror_flags_to_previous_grid}: If a cell on the present grid is
+ * @item @p{mirror_flags_to_previous_grid}: If a cell on the present grid is
  *   flagged for refinement, also flag the corresponding cell on the previous
  *   grid. This is useful if, for example, error indicators are computed for
  *   space-time cells, but are stored for the second grid only. Now, since the
@@ -1560,7 +1560,7 @@ struct TimeStepBase_Tria<dim>::Flags
  *   may be useful to flag both if necessary. This is done if the present
  *   variable is set.
  *
- * \item @p{adapt_grids}: adapt the present grid to the previous one in the sense
+ * @item @p{adapt_grids}: adapt the present grid to the previous one in the sense
  *   defined above. What is actually done here is the following: if going from
  *   the previous to the present grid would result in double refinement or
  *   double coarsening of some cells, then we try to flag these cells for
@@ -1574,7 +1574,7 @@ struct TimeStepBase_Tria<dim>::Flags
  *   by looping iteratively through all grids, back and forth, until nothing
  *   changes anymore, which is obviously impossible if there are many time steps
  *   with very large grids.
- * \end{itemize}
+ * @end{itemize}
  */
 template <int dim>
 struct TimeStepBase_Tria<dim>::RefinementFlags
index 6fa410bfc66cdb4a644456720a91dcc9edf2ad0e..3e010209b49fedc569a9a6c04665818f247f4246 100644 (file)
@@ -31,13 +31,13 @@ class ConstraintMatrix;
 /**
  *  Denote which norm/integral is to be computed. The following possibilities
  *  are implemented:
- *  \begin{itemize}
- *  \item @p{mean}: the function or difference of functions is integrated
+ *  @begin{itemize}
+ *  @item @p{mean}: the function or difference of functions is integrated
  *    on each cell.
- *  \item @p{L1_norm}: the absolute value of the function is integrated.
- *  \item @p{L2_norm}: the square of the function is integrated on each
+ *  @item @p{L1_norm}: the absolute value of the function is integrated.
+ *  @item @p{L2_norm}: the square of the function is integrated on each
  *    cell; afterwards the root is taken of this value.
- *  \end{itemize}
+ *  @end{itemize}
  */
 enum NormType {
       mean,
@@ -60,8 +60,8 @@ enum NormType {
  * @sect3{Description of operations}
  *
  * This collection of methods offers the following operations:
- * \begin{itemize}
- * \item Interpolation: assign each degree of freedom in the vector to be
+ * @begin{itemize}
+ * @item Interpolation: assign each degree of freedom in the vector to be
  *   created the value of the function given as argument. This is identical
  *   to saying that the resulting finite element function (which is isomorphic
  *   to the output vector) has exact function values in all off-points of
@@ -82,7 +82,7 @@ enum NormType {
  *   given function may be, taking into account that a virtual function has
  *   to be called.
  *
- * \item Projection: compute the $L_2$-projection of the given function onto
+ * @item Projection: compute the $L_2$-projection of the given function onto
  *   the finite element space. This is done through the solution of the
  *   linear system of equations $M v = f$ where $M$ is the mass matrix
  *   $m_{ij} = \int_\Omega \phi_i(x) \phi_j(x) dx$ and
@@ -142,19 +142,19 @@ enum NormType {
  *   too efficient, but sufficient in many cases and simple to implement. This
  *   detail may change in the future.
  *
- * \item Creation of right hand side vectors:
+ * @item Creation of right hand side vectors:
  *   The @p{create_right_hand_side} function computes the vector
  *   $f_i = \int_\Omega f(x) \phi_i(x) dx$. This is the same as what the
  *   @p{MatrixCreator::create_*} functions which take a right hand side do,
  *   but without assembling a matrix.
  *
- * \item Interpolation of boundary values:
+ * @item Interpolation of boundary values:
  *   The @p{MatrixTools::apply_boundary_values} function takes a list
  *   of boundary nodes and their values. You can get such a list by interpolation
  *   of a boundary function using the @p{interpolate_boundary_values} function.
  *   To use it, you have to
  *   specify a list of pairs of boundary indicators (of type @p{unsigned char};
- *   see the section in the documentation of the \Ref{Triangulation} class for more
+ *   see the section in the documentation of the @ref{Triangulation} class for more
  *   details) and the according functions denoting the dirichlet boundary values
  *   of the nodes on boundary faces with this boundary indicator.
  *
@@ -183,7 +183,7 @@ enum NormType {
  *   index 1 in the map. The respective boundary functions are then evaluated at
  *   the place of the respective boundary point.
  *
- * \item Projection of boundary values:
+ * @item Projection of boundary values:
  *   The @p{project_boundary_values} function acts similar to the
  *   @p{interpolate_boundary_values} function, apart from the fact that it does
  *   not get the nodal values of boundary nodes by interpolation but rather
@@ -197,7 +197,7 @@ enum NormType {
  *   solved using a simple CG method (without preconditioning), which is in most
  *   cases sufficient for the present purpose.
  *
- * \item Computing errors:
+ * @item Computing errors:
  *   The function @p{integrate_difference} performs the calculation of the error
  *   between the finite element solution and a given (continuous) reference
  *   function in different norms. The integration is performed using a given
@@ -255,7 +255,7 @@ enum NormType {
  *
  *   For the global $H_1$ norm and seminorm, the same rule applies as for the
  *   $L_2$ norm: compute the $l_2$ norm of the cell error vector.
- * \end{itemize}
+ * @end{itemize}
  *
  * All functions use the finite element given to the @p{DoFHandler} object the last
  * time that the degrees of freedom were distributed over the triangulation. Also,
index 10c249ffa8e32baeb000798973dbf28bbd44064f..880a93edc2ad3a3673564f8ed4de3ff60df025aa 100644 (file)
     <p>
     In order to allow better structured output for long comments, we
     have extended <acronym>kdoc</acronym> to understand the following
-    tags inside comments (since they are LaTeX, they are understood by
-    the LaTeX output of Doc++ automatically):
+    tags inside comments, which are partly borrowed from LaTeX like
+    languages: 
     <ul>
     <li> <em>Itemized lists:</em>
          <p>
         By writing comments like the following,
         <code><pre>
           /**
-           * \begin{itemize}
-           *   \item foo
-           *   \item bar
-           * \end{itemize}
+           * @begin{itemize}
+           *   @item foo
+           *   @item bar
+           * @end{itemize}
            */
         </pre></code>
         you can get itemized lists both in the online and printed
         <li> bar
         </ul> 
         </p>
+        
+        <p>
+        Likewise, you can get numbered lists by using the tags
+        <code>@begin{enumerate}</code> and
+        <code>@end{enumerate}</code> along with <code>@item</code>s. 
+        </p>
 
     <li> <em>Verbatim output:</em>
          <p>
         If you write comments like this,
         <code><pre>
           /**
-           * \begin{verbatim}
+           * @begin{verbatim}
            *   void foobar ()
            *   {
            *     i = 0;
            *   };
-           * \end{verbatim}
+           * @end{verbatim}
            */
         </pre></code>
         you will get the lines between the verbatim environment with
     notably the example programs is not really supported, and we
     consider ways to convert them to SGML along with most other
     documentation, since SGML is readily convertible into many other
-    formats, for Postscript.
-    </p>
-
-    <p>
-    Switching to SGML would also include replacing the LaTeX-like
-    layout extensions described above by their DocBook SGML
-    alikes. However, since this is not imminent, you need not care
-    about this at present. However, if you have spare time to pass, it
-    would be a valuable goal to invent a way to, for example, convert
-    the example programs to DocBook SGML.
+    formats, for example Postscript.
     </p>
 
 
index fd574f84d5447c33ffeb5154fb4012a98eaa0b0b..b7e9af29980c040bf408f51af1c80f24b3130439 100644 (file)
@@ -546,7 +546,7 @@ class FullMatrix : public Subscriptor
                                      * when the function exits.
                                      *
                                      * You should be aware that this function
-                                     * may produce {\bf large} amounts of
+                                     * may produce @em{large} amounts of
                                      * output if applied to a large matrix!
                                      * Be careful with it.
                                      */
index a12d0783a5b84e7d0235f9c5bc9cfe07c8cb27b3..d2e934e2bf14717b8f740303604369bdc15a7d24 100644 (file)
@@ -67,14 +67,14 @@ class PreconditionIdentity
  * @sect3{Use}
  * You will usually not want to create a named object of this type,
  * although possible. The most common use is like this:
- * \begin{verbatim}
+ * @begin{verbatim}
  *    SolverGMRES<SparseMatrix<double>,
  *                Vector<double> >      gmres(control,memory,500);
  *
  *    gmres.solve (matrix, solution, right_hand_side,
  *                PreconditionUseMatrix<SparseMatrix<double>,Vector<double> >
  *                (matrix,&SparseMatrix<double>::template precondition_Jacobi));
- * \end{verbatim}
+ * @end{verbatim}
  * This creates an unnamed object to be passed as the fourth parameter to
  * the solver function of the @p{SolverGMRES} class. It assumes that the
  * @p{SparseMatrix} class has a function @p{precondition_Jacobi} taking two
@@ -85,12 +85,12 @@ class PreconditionIdentity
  *
  * Note that due to the default template parameters, the above example
  * could be written shorter as follows:
- * \begin{verbatim}
+ * @begin{verbatim}
  *    ...
  *    gmres.solve (matrix, solution, right_hand_side,
  *                PreconditionUseMatrix<>
  *                  (matrix,&SparseMatrix<double>::template precondition_Jacobi));
- * \end{verbatim}
+ * @end{verbatim}
  *
  * @author Guido Kanschat, Wolfgang Bangerth, 1999
  */
index b186150418f2d467646abf2c46f3c35cb63cba96..81167f6e429aaca9db48c2234ef154d623604b99 100644 (file)
@@ -33,7 +33,7 @@
  *
  * @sect3{Usage}
  * The simplest use of this class is the following:
- * \begin{verbatim}
+ * @begin{verbatim}
  *                                  // generate a @p{SolverControl} and
  *                                  // a @p{VectorMemory}
  * SolverControl control;
@@ -51,9 +51,9 @@
  *                                  // call the @p{solve} function with this
  *                                  // preconditioning as last argument
  * solver.solve(A,x,b,preconditioning);
- * \end{verbatim}
+ * @end{verbatim}
  * The same example where also the @p{SolverSelector} class is used reads
- * \begin{verbatim}
+ * @begin{verbatim}
  *                                  // generate a @p{SolverControl} and
  *                                  // a @p{VectorMemory}
  * SolverControl control;
@@ -69,7 +69,7 @@
  * preconditioning.use_matrix(A);
  *
  * solver_selector.solve(A,x,b,preconditioning);
- * \end{verbatim}
+ * @end{verbatim}
  * 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 a245f31b1f94b390fd0d4b9ef0d06e426368dfa7..9f783b3669ca6e9257851677e6bb21334e75ef75 100644 (file)
@@ -39,7 +39,7 @@ class SolverControl;
  * class, they are rather intended to form a `signature' which a concrete
  * class has to conform to.
  *
- * \begin{verbatim}
+ * @begin{verbatim}
  * class Matrix
  * {
  *   public:
@@ -95,7 +95,7 @@ class SolverControl;
  *     void equ (double a, const Vector& x,
  *               double b, const Vector& z);
  * };
- * \end{verbatim}
+ * @end{verbatim}
  *
  *
  * @sect3{AdditionalData}
@@ -109,7 +109,7 @@ class SolverControl;
  * an argument as a default @p{AdditionalData} is set by default. 
  *
  * Now the generating of a solver looks like
- * \begin{verbatim}
+ * @begin{verbatim}
  *                               // GMRES with 50 tmp vectors
  * SolverGMRES solver_gmres (solver_control, vector_memory,
  *                           SolverGMRES::AdditionalData(50));
@@ -120,7 +120,7 @@ class SolverControl;
  *
  *                               // CG with default AdditionalData
  * SolverCG solver_cg (solver_control, vector_memory);
- * \end{verbatim}
+ * @end{verbatim}
  *
  * Using a unified constructor parameter list for all solvers was introduced when the
  * @p{SolverSelector} class was written; the unified interface enabled us to use this
index e8ff1b7ac224d6ef46b8054a30ecdd2f22050478..5186620fcded4b03741e14286f32d3abcf7d72d4 100644 (file)
@@ -41,14 +41,14 @@ class ParameterHandler;
  * solver is in.
  *
  * The possible values of State are
- * \begin{itemize}
- * \item @p{iterate = 0}: continue the iteration.
- * \item @p{success}: the goal is reached, the iterative method can terminate
+ * @begin{itemize}
+ * @item @p{iterate = 0}: continue the iteration.
+ * @item @p{success}: the goal is reached, the iterative method can terminate
  *       successfully.
- * \item @p{failure}: the iterative method should stop because convergence 
+ * @item @p{failure}: the iterative method should stop because convergence 
  *       could not be achieved or at least was not achieved within the given
  *       maximal number of iterations.
- * \end{itemize}
+ * @end{itemize}
  */
 class SolverControl : public Subscriptor
 {
index b80618209b19d4af848e05f283a68aebf61a7b98..bcf138ff7dc601c83ad5d8fcf832e82a12211826 100644 (file)
@@ -34,7 +34,7 @@
  *
  * @sect3{Usage}
  * The simplest use of this class is the following:
- * \begin{verbatim}
+ * @begin{verbatim}
  *                                  // generate a @p{SolverControl} and
  *                                  // a @p{VectorMemory}
  * SolverControl control;
  *                                  // call the @p{solve} function with this
  *                                  // preconditioning as last argument
  * solver_selector.solve(A,x,b,preconditioning);
- * \end{verbatim}
+ * @end{verbatim}
  * 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
- * \begin{verbatim}
+ * @begin{verbatim}
  * Parameter_Handler prm;
  * prm.declare_entry ("solver", "none",
  *                    Patterns::Sequence(SolverSelector::get_solver_names()));
  * ...
- * \end{verbatim}
+ * @end{verbatim}
  * Assuming that in the users parameter file there exists the line
- * \begin{verbatim}
+ * @begin{verbatim}
  * set solver = cg
- * \end{verbatim}
+ * @end{verbatim}
  * then `Line 3' of the above example reads
- * \begin{verbatim}
+ * @begin{verbatim}
  * SolverSelector<SparseMatrix<double>, Vector<double> > 
  *   solver_selector(prm.get("solver"), control, memory);
- * \end{verbatim}
+ * @end{verbatim}
  *
  *
  * If at some time there exists a new solver "xyz" then the user does not need
index e2631e9e29422d887e8d8ae303b31f287d86a459..ef14099b0ccfcbd10c59f5f3360a5dca0b042f6a 100644 (file)
@@ -26,7 +26,7 @@
  *
  * The algorithm used by this class is as follows (indices run from @p{0}
  * to @p{N-1}):
- * \begin{verbatim}
+ * @begin{verbatim}
  * copy original matrix into a[i,j]
  * 
  * for i=1..N-1
@@ -38,7 +38,7 @@
  *     for j=k+1..N-1
  *      if (a[i,j] exists & a[k,j] exists)
  *        a[i,j] -= a[i,k] * a[k,j]
- * \end{verbatim}
+ * @end{verbatim}
  * Using this algorithm, we store the decomposition as a sparse matrix, for
  * which the user has to give a sparsity pattern and which is why this
  * class is derived from the @p{SparseMatrix}. Since it is not a matrix in
  * matrix, you can do so by calling the solver function using the following
  * sequence, for example (@p{ilu_sparsity} is some sparsity pattern to be used
  * for the decomposition, which you have to create beforehand):
- * \begin{verbatim}
+ * @begin{verbatim}
  *   SparseILU<double> ilu (ilu_sparsity);
  *   ilu.decompose (global_matrix);
  *
  *   somesolver.solve (A, x, f,
  *                     PreconditionUseMatrix<SparseILU<double>,Vector<double> >
  *                           (ilu,&SparseILU<double>::template apply_decomposition<double>));
- * \end{verbatim}
+ * @end{verbatim}
  *
  *
  * @sect2{On template instantiations}
index 7c8f1e4c31dd734d10e9d303c30790dd0fa1bf00..228d1a463f898fa72b09ddd44e0b98c218e7ad3c 100644 (file)
@@ -637,7 +637,7 @@ class SparseMatrix : public Subscriptor
                                      * integers.
                                      *
                                      * This function
-                                     * may produce {\bf large} amounts of
+                                     * may produce @em{large} amounts of
                                      * output if applied to a large matrix!
                                      * Be careful with it.
                                      */
index 533687942a70b3090fcfc1345b8c941f5b7c734f..5213b4102ad4c964e6eab98b425c8d98d6ec60d2 100644 (file)
@@ -82,7 +82,7 @@ template <typename number> class Vector;
  * 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.
- * \begin{verbatim}
+ * @begin{verbatim}
  *                        // tag the Lagrange multiplier variable
  *    vector<bool> signature(3);
  *    signature[0] = signature[1] = false;
@@ -102,7 +102,7 @@ template <typename number> class Vector;
  *                       // solve
  *    gmres.solve (global_matrix, solution, right_hand_side,
  *                vanka);
- * \end{verbatim}
+ * @end{verbatim}
  *
  *
  * @sect4{Implementor's remark}
@@ -395,8 +395,8 @@ class SparseVanka
  * blocks equals the interval @p{[0,N)}, where @p{N} is the number of
  * degrees of freedom of the system of equations.
  *
- * \begin{itemize}
- * \item @p{index_intervals}:
+ * @begin{itemize}
+ * @item @p{index_intervals}:
  *    Here, we chose the blocks to be intervals @p{[a_i,a_{i+1})},
  *    i.e. consecutive degrees of freedom are usually also within the
  *    same block. This is a reasonable strategy, if the degrees of
@@ -424,7 +424,7 @@ class SparseVanka
  *    preconditioner useless if the degrees of freedom are numbered by
  *    component, i.e. all Lagrange multipliers en bloc.
  *
- * \item @p{adaptive}: This strategy is a bit more clever in cases where
+ * @item @p{adaptive}: This strategy is a bit more clever in cases where
  *    the Langrange DoFs are clustered, as in the example above. It
  *    works as follows: it first groups the Lagrange DoFs into blocks,
  *    using the same strategy as above. However, instead of grouping
@@ -446,7 +446,7 @@ class SparseVanka
  *    does not differ much. However, unlike the first strategy, the
  *    performance of the second strategy does not deteriorate if the
  *    DoFs are renumbered by component.
- * \end{itemize}
+ * @end{itemize}
  *
  *
  * @sect3{Typical results}
@@ -459,14 +459,14 @@ class SparseVanka
  * @p{SparseBlockVanka} with @p{n_blocks==1}), the following numbers of
  * iterations is needed to solver the linear system in each nonlinear
  * step:
- * \begin{verbatim}
+ * @begin{verbatim}
  *   101 68 64 53 35 21
- * \end{verbatim}
+ * @end{verbatim}
  *
  * With four blocks, we need the following numbers of iterations
- * \begin{verbatim}
+ * @begin{verbatim}
  *   124 88 83 66 44 28
- * \end{verbatim}
+ * @end{verbatim}
  * As can be seen, more iterations are needed. However, in terms of
  * computing time, the first version needs 72 seconds wall time (and
  * 79 seconds CPU time, which is more than wall time since some other
index b6d579cd5c01e1051f51f454b95f5090b7bf625c..47f051de02738551d29fc4a82ab2c49c38d3aa03 100644 (file)
@@ -28,7 +28,7 @@ template <typename number> class SparseMatrix;
  * The following picture will illustrate the relation between the
  * @p{SparsityPattern} an the @p{SparseMatrix}.
  *
- * \begin{verbatim}
+ * @begin{verbatim}
  *  SparsityPattern:                               \
  *                                                 |
  *              _________________________          |
@@ -58,9 +58,9 @@ template <typename number> class SparseMatrix;
  *   /_________colnums[0]                          |
  *                                                 |                    
  *                                                /                    
- * \end{verbatim}
+ * @end{verbatim}
  *
- * \begin{verbatim}
+ * @begin{verbatim}
  * For row = 0
  *   
  * it exists: (0| 3) = colnums[0]
@@ -74,9 +74,9 @@ template <typename number> class SparseMatrix;
  *            (1| 4) = colnums[5]
  * ....
  *
- * \end{verbatim}
+ * @end{verbatim}
  *
- * \begin{verbatim}
+ * @begin{verbatim}
  * SparseMatrix:                                  \
  *                                                 |
  *              _____________________________      |
@@ -85,7 +85,7 @@ template <typename number> class SparseMatrix;
  *                                                 |
  *                                                 |
  *                                                /
- * \end{verbatim}
+ * @end{verbatim}
  *
  * If you want to get the @p{3} you need to get its position in the
  * table above and its value by returning the value of the element on
index f596a461efaaae4421af1f76b795632a1ebef82b..785d860baffc995d6988373225bfa699ca4953c4 100644 (file)
@@ -1224,127 +1224,127 @@ template <int dim> class EvaluationBase;
  *
  * \subsection{Subsection #Grid#}
  * \begin{itemize}
- * \item #Coarse mesh#: Names a grid to be taken as a coarse grid. The following
+ * @item #Coarse mesh#: Names a grid to be taken as a coarse grid. The following
  *    names are allowed:
  *    \begin{itemize}
- *    \item #uniform channel#: The domain is $[0,3]\times[0,1]$, triangulated
+ *    @item #uniform channel#: The domain is $[0,3]\times[0,1]$, triangulated
  *        by three cells. Left and right boundary are of Dirichlet type, top
  *        and bottom boundary are of homogeneous Neumann type.
- *    \item #split channel bottom#: As above, but the lower half is refined once
+ *    @item #split channel bottom#: As above, but the lower half is refined once
  *        more than the top half.
- *    \item #split channel {left | right}#: Same as #uniform channel#, but with
+ *    @item #split channel {left | right}#: Same as #uniform channel#, but with
  *        cells on the left or right, according to the last word, more refined
  *        than on the other side.
- *    \item #square#: $[-1,1]\times[-1,1]$.
- *    \item #seismic square#: same as #square#, but with Neumann boundary
+ *    @item #square#: $[-1,1]\times[-1,1]$.
+ *    @item #seismic square#: same as #square#, but with Neumann boundary
  *        at top.
- *    \item #temperature-square#: Square with size $400,000,000$ (we use the
+ *    @item #temperature-square#: Square with size $400,000,000$ (we use the
  *        cgs system, so this amounts to 4000 km).
- *    \item #temperature-testcase#: As above, but with a sequence of
+ *    @item #temperature-testcase#: As above, but with a sequence of
  *        continuously growing cells set atop to avoid the implementation of
  *        absorbing boundary conditions. The left boundary is of Neumann
  *        type (mirror boundary).
- *    \item #random#: Unit square, but randomly refined to test for correctness
+ *    @item #random#: Unit square, but randomly refined to test for correctness
  *        of the time stepping scheme.
- *    \item #earth#: Circle with radius 6371 (measured in km).
- *    \end{itemize}
- * \item #Initial refinement#: States how often the grid named by the above
+ *    @item #earth#: Circle with radius 6371 (measured in km).
+ *    @begin{itemize}
+ * @item #Initial refinement#: States how often the grid named by the above
  *    parameter shall be globally refined to form the coarse mesh.
- * \item #Maximum refinement#: maximum refinement level a cell may attain.
+ * @item #Maximum refinement#: maximum refinement level a cell may attain.
  *    Cells with such a refinement level are flagged as others are, but they
  *    are not refined any more; it is therefore not necessary to lower the
  *    fraction of cells to be refined in order to avoid the refinement of a
  *    similar number of cells with a lower level number.
  *
  *    The default to this value is zero, meaning no limit.
- * \item #Refinement fraction#: Upon refinement, those cells are refined which
+ * @item #Refinement fraction#: Upon refinement, those cells are refined which
  *    together make up for a given fraction of the total error. This parameter
  *    gives that fraction. Default is #0.95#.
- * \item #Coarsening fraction#: Similar as above, gives the fraction of the
+ * @item #Coarsening fraction#: Similar as above, gives the fraction of the
  *    total error for which the cells shall be coarsened. Default is #0.03#.
- * \item #Top cell number deviation#: Denotes a fraction by which the number of
+ * @item #Top cell number deviation#: Denotes a fraction by which the number of
  *    cells on a time level may be higher than the number of cells on the
  *    previous time level. This and the next two parameters help to avoid
  *    to much differing grids on the time levels and try to smooth the numbers
  *    of cells as a function of time. The default value is #0.1#.
- * \item #Bottom cell number deviation#: Denotes the fraction by which the
+ * @item #Bottom cell number deviation#: Denotes the fraction by which the
  *    number of cells on a time level may be lower than on the previous time
  *    level. Default is #0.03#.
- * \item #Cell number correction steps#: Usually, the goal denoted by the two
+ * @item #Cell number correction steps#: Usually, the goal denoted by the two
  *    parameters above cannot be reached directly because the number of cells
  *    is modified by grid regularization etc. The goal can therefore only be
  *    reached by an iterative process. This parameter tells how many iterations
  *    of this process shall be done. Default is #2#.
- * \end{itemize}
+ * @begin{itemize}
  *
  * \subsection{Subsection #Equation data#}
  * \begin{itemize}
- * \item #Coefficient#: Names for the different coefficients for the Laplace
+ * @item #Coefficient#: Names for the different coefficients for the Laplace
  *    like part of the wave operator. Allowed values are:
  *    \begin{itemize}
- *    \item #unit#: Constant one.
- *    \item #kink#: One for $y<\frac 13$, 4 otherwise.
- *    \item #gradient#: $1+8*y^2$.
- *    \item #tube#: $0.2$ for $|x|<0.2$, one otherwise.
- *    \item #temperature VAL81#: Coefficient computed from the temperature
+ *    @item #unit#: Constant one.
+ *    @item #kink#: One for $y<\frac 13$, 4 otherwise.
+ *    @item #gradient#: $1+8*y^2$.
+ *    @item #tube#: $0.2$ for $|x|<0.2$, one otherwise.
+ *    @item #temperature VAL81#: Coefficient computed from the temperature
  *        field given by Varnazza, Avrett, Loeser 1981.
- *    \item #temperature kolmogorov#: Broadened temperature spectrum.
- *    \item #temperature undisturbed#: Quiet atmosphere.
- *    \item #temperature monochromatic 20s#: Temperature as computed with
+ *    @item #temperature kolmogorov#: Broadened temperature spectrum.
+ *    @item #temperature undisturbed#: Quiet atmosphere.
+ *    @item #temperature monochromatic 20s#: Temperature as computed with
  *        shock waves with $T=20s$.
- *    \item #temperature monochromatic 40s#: Temperature as computed with
+ *    @item #temperature monochromatic 40s#: Temperature as computed with
  *        shock waves with $T=40s$.
- *    \end{itemize}
- * \item #Initial u#: Names for the initial value for the amplitude. Allowed
+ *    @begin{itemize}
+ * @item #Initial u#: Names for the initial value for the amplitude. Allowed
  *    names are:
  *    \begin{itemize}
- *    \item #zero#: $u_0=0$.
- *    \item #eigenmode#: $u_0=sin(2\pi x)sin(2\pi y)$.
- *    \item #bump#: $u_0=(1-\frac{\vec x^2}{a^2})e^{-\frac{\vec x^2}{a^2}}$
+ *    @item #zero#: $u_0=0$.
+ *    @item #eigenmode#: $u_0=sin(2\pi x)sin(2\pi y)$.
+ *    @item #bump#: $u_0=(1-\frac{\vec x^2}{a^2})e^{-\frac{\vec x^2}{a^2}}$
  *        for $|\vec x|<a$ and $u_0=0$ otherwise. $a=0.1$
- *    \item #center-kink#: $u_0=r/a$ for $r<a$, $u_0=2-r/a$ for $a<r<2a$,
+ *    @item #center-kink#: $u_0=r/a$ for $r<a$, $u_0=2-r/a$ for $a<r<2a$,
  *        $u=0$ otherwise. $a=0.1$, $r=|\vec x|$.
- *    \item #shifted bump#: Same as #bump# but the center of the bump is
+ *    @item #shifted bump#: Same as #bump# but the center of the bump is
  *        located at $x=0.5, y=0$.
- *    \item #tube#: $u_0=1$ for $|x|<0.2, zero otherwise.
- *    \end{itemize}
- * \item #Initial v#: Names for the initial value for the amplitude. Allowed
+ *    @item #tube#: $u_0=1$ for $|x|<0.2, zero otherwise.
+ *    @begin{itemize}
+ * @item #Initial v#: Names for the initial value for the amplitude. Allowed
  *    names are the same as above.
- * \item #Boundary#: Names for the boundary functions. The boundary values
+ * @item #Boundary#: Names for the boundary functions. The boundary values
  *    for $u$ and $v$ are always set together. The boundary values apply only
  *    to those boundary parts which are of Dirichlet type. Allowed names are:
  *    \begin{itemize}
- *    \item #zero#: Homogeneous boundary values.
- *    \item #wave from left#: For $t<T=0.4$ we set $u=sin^2(\pi \frac tT)$ at
+ *    @item #zero#: Homogeneous boundary values.
+ *    @item #wave from left#: For $t<T=0.4$ we set $u=sin^2(\pi \frac tT)$ at
  *        the boundary where $x=0$.
- *    \item #wave from left center#: For $t<T=0.4$ and $0.4<y<0.6$ we set
+ *    @item #wave from left center#: For $t<T=0.4$ and $0.4<y<0.6$ we set
  *        $u=sin^2(\pi \frac tT) (y-0.4) (0.6-y)$ at
  *        the boundary where $x=0$.
- *    \item #wave from left bottom#: For $t<T=60s$ and $r=|\vec x|<a=5000000cm=50km$
+ *    @item #wave from left bottom#: For $t<T=60s$ and $r=|\vec x|<a=5000000cm=50km$
  *        let $u=(cos(\pi/2 r/a) sin(\pi t/T))^2$.
  *        This boundary condition is only suited to the temperature domains. 
- *    \end{itemize}
- * \end{itemize}
+ *    @begin{itemize}
+ * @begin{itemize}
  *
  * \subsection{Subsection #Time stepping#}
  * \begin{itemize}
- * \item #Primal method#: Time stepping method for the primal problem.
+ * @item #Primal method#: Time stepping method for the primal problem.
  *     Allowed values are:
  *     \begin{itemize}
- *     \item #theta#: Use the $\theta$ scheme with the $\theta$-parameter
+ *     @item #theta#: Use the $\theta$ scheme with the $\theta$-parameter
  *         as given below.
- *     \item #fractional step#: Use the fractional step $\theta$ scheme.
- *     \end{itemize}
- * \item #Dual method#: Time stepping method for the dual problem. Allowed
+ *     @item #fractional step#: Use the fractional step $\theta$ scheme.
+ *     @begin{itemize}
+ * @item #Dual method#: Time stepping method for the dual problem. Allowed
  *     values are the same as above. Note that the fractional step scheme
  *     is not implemented for right hand sides not equal to zero, i.e. the
  *     fractional step scheme will fail of the error functional evaluates
  *     to non-zero at times not equal to the end time.
- * \item #Theta#: $\theta$ parameter for the $\theta$ time stepping scheme.
+ * @item #Theta#: $\theta$ parameter for the $\theta$ time stepping scheme.
  *     $\theta=1/2$ denotes the Crank-Nicolson scheme.
- * \item #Time step#: Selfdocumenting.
- * \item #End time#: Selfdocumenting.
- * \end{itemize}
+ * @item #Time step#: Selfdocumenting.
+ * @item #End time#: Selfdocumenting.
+ * @begin{itemize}
  */
 template <int dim>
 class WaveParameters

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.