From 69179cd13a8d7009ebaf61599f97736125967cf5 Mon Sep 17 00:00:00 2001
From: Wolfgang Bangerth
Date: Mon, 26 Jun 2000 14:33:11 +0000
Subject: [PATCH] More doc changes for the conversion to kdoc2.
git-svn-id: https://svn.dealii.org/trunk@3075 0785d39b-7218-0410-832d-ea1e28bc413d
---
deal.II/base/include/base/convergence_table.h | 8 +-
deal.II/base/include/base/data_out_base.h | 50 ++--
deal.II/base/include/base/exceptions.h | 90 +++----
deal.II/base/include/base/function.h | 10 +-
deal.II/base/include/base/function_time.h | 10 +-
deal.II/base/include/base/logstream.h | 8 +-
deal.II/base/include/base/parameter_handler.h | 119 ++++-----
deal.II/base/include/base/smartpointer.h | 8 +-
deal.II/base/include/base/table_handler.h | 4 +-
deal.II/base/include/base/timer.h | 4 +-
deal.II/base/source/parameter_handler.cc | 199 ++++++++++----
deal.II/deal.II/include/dofs/dof_accessor.h | 8 +-
.../deal.II/include/dofs/dof_constraints.h | 8 +-
deal.II/deal.II/include/dofs/dof_handler.h | 12 +-
deal.II/deal.II/include/dofs/dof_levels.h | 10 +-
deal.II/deal.II/include/dofs/dof_tools.h | 8 +-
deal.II/deal.II/include/fe/fe.h | 26 +-
.../deal.II/include/fe/fe_lib.criss_cross.h | 6 +-
deal.II/deal.II/include/fe/fe_lib.lagrange.h | 96 +++----
deal.II/deal.II/include/fe/fe_system.h | 12 +-
deal.II/deal.II/include/fe/fe_values.h | 20 +-
deal.II/deal.II/include/grid/geometry_info.h | 8 +-
deal.II/deal.II/include/grid/grid_generator.h | 14 +-
deal.II/deal.II/include/grid/grid_in.h | 18 +-
deal.II/deal.II/include/grid/grid_out.h | 26 +-
deal.II/deal.II/include/grid/intergrid_map.h | 20 +-
.../deal.II/include/grid/persistent_tria.h | 4 +-
deal.II/deal.II/include/grid/tria.h | 248 +++++++++---------
deal.II/deal.II/include/grid/tria_accessor.h | 8 +-
deal.II/deal.II/include/grid/tria_boundary.h | 14 +-
.../deal.II/include/grid/tria_boundary_lib.h | 2 +-
deal.II/deal.II/include/grid/tria_iterator.h | 34 +--
deal.II/deal.II/include/grid/tria_levels.h | 2 +-
deal.II/deal.II/include/multigrid/mg_base.h | 2 +-
.../include/multigrid/mg_dof_accessor.h | 4 +-
.../include/multigrid/mg_dof_handler.h | 8 +-
deal.II/deal.II/include/numerics/assembler.h | 2 +-
deal.II/deal.II/include/numerics/base.h | 18 +-
deal.II/deal.II/include/numerics/data_io.h | 48 ++--
deal.II/deal.II/include/numerics/data_out.h | 4 +-
.../deal.II/include/numerics/data_out_stack.h | 4 +-
.../include/numerics/error_estimator.h | 10 +-
deal.II/deal.II/include/numerics/histogram.h | 8 +-
deal.II/deal.II/include/numerics/matrices.h | 18 +-
.../include/numerics/solution_transfer.h | 24 +-
.../deal.II/include/numerics/time_dependent.h | 62 ++---
deal.II/deal.II/include/numerics/vectors.h | 28 +-
.../development/writing-documentation.html | 33 ++-
deal.II/lac/include/lac/full_matrix.h | 2 +-
deal.II/lac/include/lac/precondition.h | 8 +-
.../lac/include/lac/precondition_selector.h | 8 +-
deal.II/lac/include/lac/solver.h | 8 +-
deal.II/lac/include/lac/solver_control.h | 10 +-
deal.II/lac/include/lac/solver_selector.h | 16 +-
deal.II/lac/include/lac/sparse_ilu.h | 8 +-
deal.II/lac/include/lac/sparse_matrix.h | 2 +-
deal.II/lac/include/lac/sparse_vanka.h | 20 +-
deal.II/lac/include/lac/sparsity_pattern.h | 12 +-
tests/deal.II/wave-test-3.cc | 110 ++++----
59 files changed, 845 insertions(+), 746 deletions(-)
diff --git a/deal.II/base/include/base/convergence_table.h b/deal.II/base/include/base/convergence_table.h
index 6682431b27..e345b938c5 100644
--- a/deal.II/base/include/base/convergence_table.h
+++ b/deal.II/base/include/base/convergence_table.h
@@ -39,13 +39,13 @@
*
* 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
diff --git a/deal.II/base/include/base/data_out_base.h b/deal.II/base/include/base/data_out_base.h
index 90908defdc..01d7b382f0 100644
--- a/deal.II/base/include/base/data_out_base.h
+++ b/deal.II/base/include/base/data_out_base.h
@@ -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 +W +H +L
- * \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
@@ -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
diff --git a/deal.II/base/include/base/exceptions.h b/deal.II/base/include/base/exceptions.h
index 86518c7064..3ebde4735f 100644
--- a/deal.II/base/include/base/exceptions.h
+++ b/deal.II/base/include/base/exceptions.h
@@ -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
@@ -62,10 +62,10 @@
* 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
@@ -87,18 +87,18 @@
*
* 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
* #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
diff --git a/deal.II/base/include/base/smartpointer.h b/deal.II/base/include/base/smartpointer.h
index 4f2a5d68e5..59b1da370e 100644
--- a/deal.II/base/include/base/smartpointer.h
+++ b/deal.II/base/include/base/smartpointer.h
@@ -30,18 +30,18 @@
*
* @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 = 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 = 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} really behaves as if it were a pointer to
diff --git a/deal.II/base/include/base/table_handler.h b/deal.II/base/include/base/table_handler.h
index 481e3c4ee8..9552beae66 100644
--- a/deal.II/base/include/base/table_handler.h
+++ b/deal.II/base/include/base/table_handler.h
@@ -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
*/
diff --git a/deal.II/base/include/base/timer.h b/deal.II/base/include/base/timer.h
index a160d1c576..2e9691d37f 100644
--- a/deal.II/base/include/base/timer.h
+++ b/deal.II/base/include/base/timer.h
@@ -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
diff --git a/deal.II/base/source/parameter_handler.cc b/deal.II/base/source/parameter_handler.cc
index a7daf6b6fc..9c307444da 100644
--- a/deal.II/base/source/parameter_handler.cc
+++ b/deal.II/base/source/parameter_handler.cc
@@ -21,7 +21,14 @@
#include
-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 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 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::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::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::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(&defaults); // not nice, but needs to be and
// after all: we do not change @p{sec}
vector::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::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(&changed_entries); // same as in get_present_default_s...
vector::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_nosecond.first));
-// transverse subsections
+ // transverse subsections
map::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::iterator choice;
@@ -1002,13 +1099,17 @@ void MultipleParameterLoop::fill_entry_values (const unsigned int run_no) {
};
+
MultipleParameterLoop::Entry::Entry (const vector &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
diff --git a/deal.II/deal.II/include/dofs/dof_accessor.h b/deal.II/deal.II/include/dofs/dof_accessor.h
index 9cff7b3681..f0d191b362 100644
--- a/deal.II/deal.II/include/dofs/dof_accessor.h
+++ b/deal.II/deal.II/include/dofs/dof_accessor.h
@@ -192,7 +192,7 @@ class DoFObjectAccessor_Inheritance
* 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
*
* @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,
/**
* 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,
*
* @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
diff --git a/deal.II/deal.II/include/dofs/dof_constraints.h b/deal.II/deal.II/include/dofs/dof_constraints.h
index 3707e11c22..c599e6407e 100644
--- a/deal.II/deal.II/include/dofs/dof_constraints.h
+++ b/deal.II/deal.II/include/dofs/dof_constraints.h
@@ -48,8 +48,8 @@ template 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 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 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.
diff --git a/deal.II/deal.II/include/dofs/dof_handler.h b/deal.II/deal.II/include/dofs/dof_handler.h
index b3273c782d..a344be7c04 100644
--- a/deal.II/deal.II/include/dofs/dof_handler.h
+++ b/deal.II/deal.II/include/dofs/dof_handler.h
@@ -34,7 +34,7 @@ template 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*> levels;
diff --git a/deal.II/deal.II/include/dofs/dof_levels.h b/deal.II/deal.II/include/dofs/dof_levels.h
index 2f6439efe8..f8e52e8cf9 100644
--- a/deal.II/deal.II/include/dofs/dof_levels.h
+++ b/deal.II/deal.II/include/dofs/dof_levels.h
@@ -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 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 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 hex_dofs;
diff --git a/deal.II/deal.II/include/dofs/dof_tools.h b/deal.II/deal.II/include/dofs/dof_tools.h
index 362bdc1dbd..0ed2a26456 100644
--- a/deal.II/deal.II/include/dofs/dof_tools.h
+++ b/deal.II/deal.II/include/dofs/dof_tools.h
@@ -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
diff --git a/deal.II/deal.II/include/fe/fe.h b/deal.II/deal.II/include/fe/fe.h
index 79a80f7792..846302a518 100644
--- a/deal.II/deal.II/include/fe/fe.h
+++ b/deal.II/deal.II/include/fe/fe.h
@@ -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
* 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.
*
diff --git a/deal.II/deal.II/include/fe/fe_lib.criss_cross.h b/deal.II/deal.II/include/fe/fe_lib.criss_cross.h
index bb50d27771..d927390925 100644
--- a/deal.II/deal.II/include/fe/fe_lib.criss_cross.h
+++ b/deal.II/deal.II/include/fe/fe_lib.criss_cross.h
@@ -115,7 +115,7 @@
* 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}
* *-----------------*--------*----
* | /|\ |
* | /..|.\ |
@@ -129,7 +129,7 @@
* | /...............|.....\ |
* |/................|.......\|
* *-----------------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
@@ -164,7 +164,7 @@
* 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.
*
diff --git a/deal.II/deal.II/include/fe/fe_lib.lagrange.h b/deal.II/deal.II/include/fe/fe_lib.lagrange.h
index e07607c309..2122262833 100644
--- a/deal.II/deal.II/include/fe/fe_lib.lagrange.h
+++ b/deal.II/deal.II/include/fe/fe_lib.lagrange.h
@@ -137,23 +137,23 @@ class FEQ1 : public FEQ1Mapping
* 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
* | / 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
* 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
* 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
* 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
* 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.
diff --git a/deal.II/deal.II/include/fe/fe_system.h b/deal.II/deal.II/include/fe/fe_system.h
index c07bdd5093..4b9d753ed4 100644
--- a/deal.II/deal.II/include/fe/fe_system.h
+++ b/deal.II/deal.II/include/fe/fe_system.h
@@ -45,14 +45,14 @@
* 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
diff --git a/deal.II/deal.II/include/fe/fe_values.h b/deal.II/deal.II/include/fe/fe_values.h
index d3bc21b1df..1505ca2441 100644
--- a/deal.II/deal.II/include/fe/fe_values.h
+++ b/deal.II/deal.II/include/fe/fe_values.h
@@ -143,17 +143,17 @@ template 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 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
* 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
* 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
* 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
diff --git a/deal.II/deal.II/include/grid/geometry_info.h b/deal.II/deal.II/include/grid/geometry_info.h
index 7e52eaa1bb..b9ed710ac5 100644
--- a/deal.II/deal.II/include/grid/geometry_info.h
+++ b/deal.II/deal.II/include/grid/geometry_info.h
@@ -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
diff --git a/deal.II/deal.II/include/grid/grid_generator.h b/deal.II/deal.II/include/grid/grid_generator.h
index d33e0e70f9..25d2f04827 100644
--- a/deal.II/deal.II/include/grid/grid_generator.h
+++ b/deal.II/deal.II/include/grid/grid_generator.h
@@ -24,8 +24,8 @@ template 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 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 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 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 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
*/
diff --git a/deal.II/deal.II/include/grid/grid_in.h b/deal.II/deal.II/include/grid/grid_in.h
index 4069d214b3..5aca63e999 100644
--- a/deal.II/deal.II/include/grid/grid_in.h
+++ b/deal.II/deal.II/include/grid/grid_in.h
@@ -43,7 +43,7 @@ template 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 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 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 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 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
diff --git a/deal.II/deal.II/include/grid/grid_out.h b/deal.II/deal.II/include/grid/grid_out.h
index 1c561f8007..516d5790bb 100644
--- a/deal.II/deal.II/include/grid/grid_out.h
+++ b/deal.II/deal.II/include/grid/grid_out.h
@@ -35,18 +35,18 @@ template 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 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
diff --git a/deal.II/deal.II/include/grid/intergrid_map.h b/deal.II/deal.II/include/grid/intergrid_map.h
index a5b329f607..ecad3db476 100644
--- a/deal.II/deal.II/include/grid/intergrid_map.h
+++ b/deal.II/deal.II/include/grid/intergrid_map.h
@@ -23,18 +23,18 @@ template 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 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 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 tria1, tria2;
@@ -95,7 +95,7 @@ template 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}, i.e. the dimension is given explicitely and
diff --git a/deal.II/deal.II/include/grid/persistent_tria.h b/deal.II/deal.II/include/grid/persistent_tria.h
index cb0602e05d..16bc88e00e 100644
--- a/deal.II/deal.II/include/grid/persistent_tria.h
+++ b/deal.II/deal.II/include/grid/persistent_tria.h
@@ -55,7 +55,7 @@
* object of this class.
*
* Basically, usage looks like this:
- * \begin{verbatim}
+ * @begin{verbatim}
* Triangulation 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
diff --git a/deal.II/deal.II/include/grid/tria.h b/deal.II/deal.II/include/grid/tria.h
index fe23a3ae53..fab455c663 100644
--- a/deal.II/deal.II/include/grid/tria.h
+++ b/deal.II/deal.II/include/grid/tria.h
@@ -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 Triangulation::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 Triangulation::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
* void Triangulation::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::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}
diff --git a/deal.II/deal.II/include/grid/tria_accessor.h b/deal.II/deal.II/include/grid/tria_accessor.h
index 2b4c559fec..816e9c9a87 100644
--- a/deal.II/deal.II/include/grid/tria_accessor.h
+++ b/deal.II/deal.II/include/grid/tria_accessor.h
@@ -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
* 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
*
* 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
diff --git a/deal.II/deal.II/include/grid/tria_boundary.h b/deal.II/deal.II/include/grid/tria_boundary.h
index 907f8f47e7..61dbfd3bdf 100644
--- a/deal.II/deal.II/include/grid/tria_boundary.h
+++ b/deal.II/deal.II/include/grid/tria_boundary.h
@@ -27,17 +27,17 @@ template class Triangulation;
* When a triangulation creates a new vertex on the boundary of the
* domain, it determines the new vertex' coordinates through the
* following code (here in two dimensions):
- * \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 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}, which places the new point right
+ * Specialisation of @ref{Boundary}, which places the new point right
* into the middle of the given points. The middle is defined as the
* arithmetic mean of the points.
*
diff --git a/deal.II/deal.II/include/grid/tria_boundary_lib.h b/deal.II/deal.II/include/grid/tria_boundary_lib.h
index 4a079c5246..70a8695cd6 100644
--- a/deal.II/deal.II/include/grid/tria_boundary_lib.h
+++ b/deal.II/deal.II/include/grid/tria_boundary_lib.h
@@ -18,7 +18,7 @@
/**
- * Specialisation of \Ref{Boundary}, which places the new point on
+ * Specialisation of @ref{Boundary}, 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.
diff --git a/deal.II/deal.II/include/grid/tria_iterator.h b/deal.II/deal.II/include/grid/tria_iterator.h
index 9a4a48ee9a..73435e7a68 100644
--- a/deal.II/deal.II/include/grid/tria_iterator.h
+++ b/deal.II/deal.II/include/grid/tria_iterator.h
@@ -40,20 +40,20 @@ template 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 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 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 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*},
+ * @item It must have a constructor which takes 1. a @p{Triangulation*},
* 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 {
* 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 {
/**
- * 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
@@ -645,7 +645,7 @@ class TriaIterator : public TriaRawIterator {
/**
- * 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.
*/
diff --git a/deal.II/deal.II/include/grid/tria_levels.h b/deal.II/deal.II/include/grid/tria_levels.h
index f4b423ded0..c8fc2b696d 100644
--- a/deal.II/deal.II/include/grid/tria_levels.h
+++ b/deal.II/deal.II/include/grid/tria_levels.h
@@ -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.
diff --git a/deal.II/deal.II/include/multigrid/mg_base.h b/deal.II/deal.II/include/multigrid/mg_base.h
index fd65894c5b..ae1f046c67 100644
--- a/deal.II/deal.II/include/multigrid/mg_base.h
+++ b/deal.II/deal.II/include/multigrid/mg_base.h
@@ -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
diff --git a/deal.II/deal.II/include/multigrid/mg_dof_accessor.h b/deal.II/deal.II/include/multigrid/mg_dof_accessor.h
index 18be3c550f..c09d075ac2 100644
--- a/deal.II/deal.II/include/multigrid/mg_dof_accessor.h
+++ b/deal.II/deal.II/include/multigrid/mg_dof_accessor.h
@@ -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
diff --git a/deal.II/deal.II/include/multigrid/mg_dof_handler.h b/deal.II/deal.II/include/multigrid/mg_dof_handler.h
index d1661cdc95..4a6abcc1c6 100644
--- a/deal.II/deal.II/include/multigrid/mg_dof_handler.h
+++ b/deal.II/deal.II/include/multigrid/mg_dof_handler.h
@@ -24,7 +24,7 @@ template 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:
diff --git a/deal.II/deal.II/include/numerics/assembler.h b/deal.II/deal.II/include/numerics/assembler.h
index 49eecc2283..b19feb219a 100644
--- a/deal.II/deal.II/include/numerics/assembler.h
+++ b/deal.II/deal.II/include/numerics/assembler.h
@@ -150,7 +150,7 @@ class Assembler : public DoFCellAccessor
* 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 {
diff --git a/deal.II/deal.II/include/numerics/base.h b/deal.II/deal.II/include/numerics/base.h
index 92e2f0d9f1..626ceb0909 100644
--- a/deal.II/deal.II/include/numerics/base.h
+++ b/deal.II/deal.II/include/numerics/base.h
@@ -46,19 +46,19 @@ template 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 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.
*
diff --git a/deal.II/deal.II/include/numerics/data_io.h b/deal.II/deal.II/include/numerics/data_io.h
index 31336cd2ea..93db1b6f2a 100644
--- a/deal.II/deal.II/include/numerics/data_io.h
+++ b/deal.II/deal.II/include/numerics/data_io.h
@@ -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
diff --git a/deal.II/deal.II/include/numerics/data_out.h b/deal.II/deal.II/include/numerics/data_out.h
index 8b04cc83fb..82f60b61be 100644
--- a/deal.II/deal.II/include/numerics/data_out.h
+++ b/deal.II/deal.II/include/numerics/data_out.h
@@ -35,7 +35,7 @@ template 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
* ... // and contains nodal values
@@ -58,7 +58,7 @@ template 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
diff --git a/deal.II/deal.II/include/numerics/data_out_stack.h b/deal.II/deal.II/include/numerics/data_out_stack.h
index dcc1eb43d3..be16959583 100644
--- a/deal.II/deal.II/include/numerics/data_out_stack.h
+++ b/deal.II/deal.II/include/numerics/data_out_stack.h
@@ -66,7 +66,7 @@ template class DoFHandler;
* which is suitable for quadratic finite elements in space, for
* example.
*
- * \begin{verbatim}
+ * @begin{verbatim}
* DataOutStack data_out_stack;
*
* // first declare the vectors
@@ -94,7 +94,7 @@ template class DoFHandler;
* data_out_stack.build_patches (2);
* data_out_stack.finish_parameter_value ();
* };
- * \end{verbatim}
+ * @end{verbatim}
*
* @author Wolfgang Bangerth, 1999
*/
diff --git a/deal.II/deal.II/include/numerics/error_estimator.h b/deal.II/deal.II/include/numerics/error_estimator.h
index 978636baf9..f391330082 100644
--- a/deal.II/deal.II/include/numerics/error_estimator.h
+++ b/deal.II/deal.II/include/numerics/error_estimator.h
@@ -120,8 +120,8 @@ template 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 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.
*
diff --git a/deal.II/deal.II/include/numerics/histogram.h b/deal.II/deal.II/include/numerics/histogram.h
index cf2d5f00f6..e808aa89b6 100644
--- a/deal.II/deal.II/include/numerics/histogram.h
+++ b/deal.II/deal.II/include/numerics/histogram.h
@@ -35,14 +35,14 @@
* @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
diff --git a/deal.II/deal.II/include/numerics/matrices.h b/deal.II/deal.II/include/numerics/matrices.h
index 95982c09bf..28d12b55bf 100644
--- a/deal.II/deal.II/include/numerics/matrices.h
+++ b/deal.II/deal.II/include/numerics/matrices.h
@@ -57,8 +57,8 @@ template 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 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} 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 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
*
* 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
* 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
* 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
* 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
class MassMatrix : public Equation {
diff --git a/deal.II/deal.II/include/numerics/solution_transfer.h b/deal.II/deal.II/include/numerics/solution_transfer.h
index 951dd7bdff..d9067d437b 100644
--- a/deal.II/deal.II/include/numerics/solution_transfer.h
+++ b/deal.II/deal.II/include/numerics/solution_transfer.h
@@ -36,10 +36,10 @@
* 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 soltrans(*dof_handler);
* soltrans.prepare_for_pure_refinement();
* // some refinement e.g.
@@ -51,10 +51,10 @@
* // 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 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 &in, Vector &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
@@ -110,7 +110,7 @@
* 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
@@ -153,7 +153,7 @@
* 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
*/
diff --git a/deal.II/deal.II/include/numerics/time_dependent.h b/deal.II/deal.II/include/numerics/time_dependent.h
index 63ab5416af..9cc5e757dc 100644
--- a/deal.II/deal.II/include/numerics/time_dependent.h
+++ b/deal.II/deal.II/include/numerics/time_dependent.h
@@ -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).
*
@@ -117,7 +117,7 @@
* 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
@@ -126,7 +126,7 @@
* 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
@@ -148,14 +148,14 @@
*
* 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
@@ -180,7 +180,7 @@
*
* 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
* void TimeDependent_Wave::run_sweep (const unsigned int sweep_no)
* {
@@ -209,7 +209,7 @@
* for (unsigned int sweep=0; sweep::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
@@ -293,7 +293,7 @@
* 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
* void TimeDependent::do_loop (InitFunctionObject init_function,
* LoopFunctionObject loop_function,
@@ -335,7 +335,7 @@
* 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::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::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::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::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::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::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::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::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
struct TimeStepBase_Tria::RefinementFlags
diff --git a/deal.II/deal.II/include/numerics/vectors.h b/deal.II/deal.II/include/numerics/vectors.h
index 6fa410bfc6..3e010209b4 100644
--- a/deal.II/deal.II/include/numerics/vectors.h
+++ b/deal.II/deal.II/include/numerics/vectors.h
@@ -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,
diff --git a/deal.II/doc/development/writing-documentation.html b/deal.II/doc/development/writing-documentation.html
index 10c249ffa8..880a93edc2 100644
--- a/deal.II/doc/development/writing-documentation.html
+++ b/deal.II/doc/development/writing-documentation.html
@@ -124,18 +124,18 @@
In order to allow better structured output for long comments, we
have extended kdoc 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:
- Itemized lists:
By writing comments like the following,
/**
- * \begin{itemize}
- * \item foo
- * \item bar
- * \end{itemize}
+ * @begin{itemize}
+ * @item foo
+ * @item bar
+ * @end{itemize}
*/
you can get itemized lists both in the online and printed
@@ -145,18 +145,24 @@
- bar
+
+
+ Likewise, you can get numbered lists by using the tags
+ @begin{enumerate}
and
+ @end{enumerate}
along with @item
s.
+
Verbatim output:
If you write comments like this,
/**
- * \begin{verbatim}
+ * @begin{verbatim}
* void foobar ()
* {
* i = 0;
* };
- * \end{verbatim}
+ * @end{verbatim}
*/
you will get the lines between the verbatim environment with
@@ -212,16 +218,7 @@
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.
-
-
-
- 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.
diff --git a/deal.II/lac/include/lac/full_matrix.h b/deal.II/lac/include/lac/full_matrix.h
index fd574f84d5..b7e9af2998 100644
--- a/deal.II/lac/include/lac/full_matrix.h
+++ b/deal.II/lac/include/lac/full_matrix.h
@@ -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.
*/
diff --git a/deal.II/lac/include/lac/precondition.h b/deal.II/lac/include/lac/precondition.h
index a12d0783a5..d2e934e2bf 100644
--- a/deal.II/lac/include/lac/precondition.h
+++ b/deal.II/lac/include/lac/precondition.h
@@ -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,
* Vector > gmres(control,memory,500);
*
* gmres.solve (matrix, solution, right_hand_side,
* PreconditionUseMatrix,Vector >
* (matrix,&SparseMatrix::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::template precondition_Jacobi));
- * \end{verbatim}
+ * @end{verbatim}
*
* @author Guido Kanschat, Wolfgang Bangerth, 1999
*/
diff --git a/deal.II/lac/include/lac/precondition_selector.h b/deal.II/lac/include/lac/precondition_selector.h
index b186150418..81167f6e42 100644
--- a/deal.II/lac/include/lac/precondition_selector.h
+++ b/deal.II/lac/include/lac/precondition_selector.h
@@ -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
diff --git a/deal.II/lac/include/lac/solver.h b/deal.II/lac/include/lac/solver.h
index a245f31b1f..9f783b3669 100644
--- a/deal.II/lac/include/lac/solver.h
+++ b/deal.II/lac/include/lac/solver.h
@@ -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
diff --git a/deal.II/lac/include/lac/solver_control.h b/deal.II/lac/include/lac/solver_control.h
index e8ff1b7ac2..5186620fcd 100644
--- a/deal.II/lac/include/lac/solver_control.h
+++ b/deal.II/lac/include/lac/solver_control.h
@@ -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
{
diff --git a/deal.II/lac/include/lac/solver_selector.h b/deal.II/lac/include/lac/solver_selector.h
index b80618209b..bcf138ff7d 100644
--- a/deal.II/lac/include/lac/solver_selector.h
+++ b/deal.II/lac/include/lac/solver_selector.h
@@ -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;
@@ -52,26 +52,26 @@
* // 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, Vector >
* 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
diff --git a/deal.II/lac/include/lac/sparse_ilu.h b/deal.II/lac/include/lac/sparse_ilu.h
index e2631e9e29..ef14099b0c 100644
--- a/deal.II/lac/include/lac/sparse_ilu.h
+++ b/deal.II/lac/include/lac/sparse_ilu.h
@@ -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
@@ -73,14 +73,14 @@
* 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 ilu (ilu_sparsity);
* ilu.decompose (global_matrix);
*
* somesolver.solve (A, x, f,
* PreconditionUseMatrix,Vector >
* (ilu,&SparseILU::template apply_decomposition));
- * \end{verbatim}
+ * @end{verbatim}
*
*
* @sect2{On template instantiations}
diff --git a/deal.II/lac/include/lac/sparse_matrix.h b/deal.II/lac/include/lac/sparse_matrix.h
index 7c8f1e4c31..228d1a463f 100644
--- a/deal.II/lac/include/lac/sparse_matrix.h
+++ b/deal.II/lac/include/lac/sparse_matrix.h
@@ -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.
*/
diff --git a/deal.II/lac/include/lac/sparse_vanka.h b/deal.II/lac/include/lac/sparse_vanka.h
index 533687942a..5213b4102a 100644
--- a/deal.II/lac/include/lac/sparse_vanka.h
+++ b/deal.II/lac/include/lac/sparse_vanka.h
@@ -82,7 +82,7 @@ template 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 signature(3);
* signature[0] = signature[1] = false;
@@ -102,7 +102,7 @@ template 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
diff --git a/deal.II/lac/include/lac/sparsity_pattern.h b/deal.II/lac/include/lac/sparsity_pattern.h
index b6d579cd5c..47f051de02 100644
--- a/deal.II/lac/include/lac/sparsity_pattern.h
+++ b/deal.II/lac/include/lac/sparsity_pattern.h
@@ -28,7 +28,7 @@ template 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 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 class SparseMatrix;
* (1| 4) = colnums[5]
* ....
*
- * \end{verbatim}
+ * @end{verbatim}
*
- * \begin{verbatim}
+ * @begin{verbatim}
* SparseMatrix: \
* |
* _____________________________ |
@@ -85,7 +85,7 @@ template 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
diff --git a/tests/deal.II/wave-test-3.cc b/tests/deal.II/wave-test-3.cc
index f596a461ef..785d860baf 100644
--- a/tests/deal.II/wave-test-3.cc
+++ b/tests/deal.II/wave-test-3.cc
@@ -1224,127 +1224,127 @@ template 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|
class WaveParameters
--
2.39.5