*
* 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
*
* 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
*
* 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.
* 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
*
* 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
*
* You need povray (>=3.0) to render the scene. The minimum options for povray
* are:
- * \begin{verbatim}
+ * @begin{verbatim}
* povray +I<inputfile> +W<horiz. size> +H<ver. size> +L<include path>
- * \end{verbatim}
+ * @end{verbatim}
* If the external file "data.inc" is used, the path to this file has to be
* included in the povray options.
*
* @p{n_subdivision} = 4 because
* the number of cells is
* equal to @p{2^dim}.
- * \begin{verbatim}
+ * @begin{verbatim}
* __ __ __ __
* | | | | |
* |__|__|__|__|
* |__|__|__|__|
* | | | | |
* |__|__|__|__|
- * \end{verbatim}
+ * @end{verbatim}
* @author Wolfgang Bangerth
*/
template <int dim>
* @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
* / /|
* | / | /
* | / | /
* 0|/______1/
- * \end{verbatim}
+ * @end{verbatim}
*
* For exemple in 2d: If
* @p{subdivisions==2} the
* given by the following
* numeration:
*
- * \begin{verbatim}
+ * @begin{verbatim}
* 2 ____5 ____8
* | | |
* | | |
* | | |
* | | |
* 0|____3|____6|
- * \end{verbatim}
+ * @end{verbatim}
*
* Since the number of data vectors
* is usually the same for all
* Gnuplot-default of 0 is
* the following:
*
- * \begin{verbatim}
+ * @begin{verbatim}
*
* 3________7
* / /|
* | / | /
* 1|/______5/
*
- * \end{verbatim}
+ * @end{verbatim}
*/
double turn_angle;
* presently implemented.
*
* Usage is as follows:
- * \begin{verbatim}
+ * @begin{verbatim}
* // within function declaring parameters:
* ...
* prm.enter_subsection ("Output format options");
* 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.
*
* 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
* @p{DeclException} macro family.
*
*
- * @sect2{General overview of the exception handling mechanism in @p{deal.II}}
+ * @sect2{General overview of the exception handling mechanism in deal.II}
*
* The error handling mechanism in @p{deal.II} is generally used in two ways.
* The first uses error checking in debug mode only and is useful for programs
* Both modes use exception classes, which need to have special features
* additionally to the @p{C++} standard's @p{exception} class. Such a class
* is declared by the following lines of code:
- * \begin{verbatim}
+ * @begin{verbatim}
* DeclException2 (ExcDomain, int, int,
* << "Index= " << arg1 << "Upper Bound= " << arg2);
- * \end{verbatim}
+ * @end{verbatim}
* This declares an exception class named @p{ExcDomain}, which
* has two variables as additional information (named
* @p{arg1} and @p{arg2} by default) and which outputs the
*
* To use the exception mechanism for debug mode error checking, write lines
* like the following in your source code:
- * \begin{verbatim}
+ * @begin{verbatim}
* Assert (n<dim, ExcDomain(n,dim));
- * \end{verbatim}
+ * @end{verbatim}
* which by macro expansion does the following:
- * \begin{verbatim}
+ * @begin{verbatim}
* #ifdef DEBUG
* if (!cond)
* issue error of class ExcDomain(n,dim)
* #else
* do nothing
* #endif
- * \end{verbatim}
+ * @end{verbatim}
* i.e. it issues an error only if the preprocessor variable
* @p{DEBUG} is set and if the given condition (in this case
* @p{n<dim} is violated.
* @sect3{How it works internally}
* If the @p{DEBUG} preprocessor directive is set, the call @p{Assert (cond, exc);}
* is converted by the preprocessor into the sequence
- * \begin{verbatim}
+ * @begin{verbatim}
* if (!(cond))
* __IssueError_Assert (__FILE__,
* __LINE__,
* #cond,
* #exc,
* &exc);
- * \end{verbatim}
+ * @end{verbatim}
* i.e. if the given condition is violated, then the file and
* line in which the exception occured as well as
* the condition itself and the call sequence of the
* than that the program flow should not have reached a certain point,
* e.g. a @p{default} section of a @p{switch} statement. In this case,
* raise the exception by the following construct:
- * \begin{verbatim}
+ * @begin{verbatim}
* Assert (false, ExcInternalError());
- * \end{verbatim}
+ * @end{verbatim}
*
*
* @sect2{Use of run-time exceptions}
* For this mode, the standard @p{C++} @p{throw} and @p{catch} concept exists. We
* want to keep to this, but want to extend it a bit. In general, the
* structure is the same, i.e. you normally raise and exception by
- * \begin{verbatim}
+ * @begin{verbatim}
* if (!cond)
* throw ExcSomething();
- * \end{verbatim}
+ * @end{verbatim}
* and catch it using the statement
- * \begin{verbatim}
+ * @begin{verbatim}
* try {
* do_something ();
* }
* << endl;
* do_something_to_reciver ();
* };
- * \end{verbatim}
+ * @end{verbatim}
* @p{exception} is a standard @p{C++} class providing basic functionality for
* exceptions, such as the virtual function @p{what()} which returns some
* information on the exception itself. This information is useful if an
* done using the @p{DeclExceptionN} macros, but putting the right information,
* which is the same as explained above for the @p{Assert} expansion, requires
* some work if one would want to write it down each time:
- * \begin{verbatim}
+ * @begin{verbatim}
* if (!cond)
* {
* ExcSomething e(additional information);
* "name of condition as a string");
* throw e;
* };
- * \end{verbatim}
+ * @end{verbatim}
*
* For this purpose, the macro @p{AssertThrow} was invented. It does mainly
* the same job as does the @p{Assert} macro, but it does not kill the
* program, it rather throws an exception as shown above. The mode of usage
* is
- * \begin{verbatim}
+ * @begin{verbatim}
* AssertThrow (cond, ExcSomething(additional information));
- * \end{verbatim}
+ * @end{verbatim}
* The condition to be checked is incorporated into the macro in order to
* allow passing the violated condition as a string. The expansion of the
* @p{AssertThrow} macro is not affected by the @p{DEBUG} preprocessor variable.
*
*
- * @sect2{Description of the @p{DeclExceptionN} macro family}
+ * @sect2{Description of the DeclExceptionN macro family}
*
* Declare an exception class without any additional parameters.
* There is a whole family of @p{DeclException?} macros
* parameters (0 to 5 presently).
*
* The syntax is as follows:
- * \begin{verbatim}
+ * @begin{verbatim}
* DeclException2 (ExcDomain,
* int,
* int,
* << " i=" << arg1 << ", m=" << arg2);
- * \end{verbatim}
+ * @end{verbatim}
* The first is the name of the exception class to be created.
* The next arguments are the types of the parameters (in this
* case there are two type names needed) and finally the output
*
* The syntax of the output sequence is a bit weird but gets
* clear once you see how this macro is defined:
- * \begin{verbatim}
+ * @begin{verbatim}
* class name : public ExceptionBase {
* public:
* name (const type1 a1, const type2 a2) :
* type1 arg1;
* type2 arg2;
* };
- * \end{verbatim}
+ * @end{verbatim}
*
* If declared as specified, you can later use this exception class
* in the following manner:
- * \begin{verbatim}
+ * @begin{verbatim}
* int i=5;
* int m=3;
* Assert (i<m, MyExc2(i,m));
- * \end{verbatim}
+ * @end{verbatim}
* and the output if the condition fails will be
- * \begin{verbatim}
+ * @begin{verbatim}
* --------------------------------------------------------
* An error occurred in line <301> of file <exc-test.cc>.
* The violated condition was:
* Additional Information:
* i=5, m=3
* --------------------------------------------------------
- * \end{verbatim}
+ * @end{verbatim}
*
* Obviously for the @p{DeclException0(name)} macro, no types and
* also no output sequence is allowed.
#ifdef DEBUG ////////////////////////////////////////
/**
- * This is the main routine in the exception mechanism for debug mode
- * error checking. See the
- * @p{ExceptionBase} class for more information.
+ * This is the main routine in the exception mechanism for debug mode
+ * error checking. It assert that a certain condition is fulfilled,
+ * otherwise issues an error and aborts the program.
*
- * @memo Assert that a certain condition is fulfilled, otherwise
- * issue an error and abort the program.
- * @see ExceptionBase
- * @author Wolfgang Bangerth, November 1997, extensions 1998
+ * See the @p{ExceptionBase} class for more information.
+ *
+ * @see ExceptionBase
+ * @author Wolfgang Bangerth, November 1997, extensions 1998
*/
#define Assert(cond, exc) \
{ \
/**
- * This is the main routine in the exception mechanism for run-time mode
- * error checking. See the
- * @p{ExceptionBase} class for more information.
+ * This is the main routine in the exception mechanism for run-time
+ * mode error checking. It assert that a certain condition is
+ * fulfilled, otherwise issues an error and aborts the program.
*
- * @memo Assert that a certain condition is fulfilled, otherwise
- * throw an exception
- * @see ExceptionBase
- * @author Wolfgang Bangerth, November 1997, extensions 1998
+ * The configuration parameter NO_THROW can be used to disable this
+ * feature. This should not be done on a regular basis, but gcc
+ * 2.95.2 on DEC Alpha stops compiling here.
*
- * The configuration parameter NO_THROW can be used to disable this feature.
- * This should not be done on a regular basis, but gcc 2.95.2 on DEC Alpha
- * stops compiling here.
+ * See the @p{ExceptionBase} class for more information.
+ *
+ * @see ExceptionBase
+ * @author Wolfgang Bangerth, November 1997, extensions 1998
*/
#ifndef NO_THROW
#define AssertThrow(cond, exc) \
*
* Access to function objects therefore is through the following
* methods:
- * \begin{verbatim}
+ * @begin{verbatim}
* // access to one component at one point
* double value (const Point<dim> &p,
* const unsigned int component = 0) const;
* // return all components at one point
* void vector_value (const Point<dim> &p,
* Vector<double> &value) const;
- * \end{verbatim}
+ * @end{verbatim}
*
* For more efficiency, there are other functions returning one or all
* components at a list of points at once:
- * \begin{verbatim}
+ * @begin{verbatim}
* // access to one component at several points
* void value_list (const vector<Point<dim> > &point_list,
* vector<double> &value_list,
* // return all components at several points
* void vector_value_list (const vector<Point<dim> > &point_list,
* vector<Vector<double> > &value_list) const;
- * \end{verbatim}
+ * @end{verbatim}
*
* Furthermore, there are functions returning the gradient of the
* function at one or several points.
* Support for time dependant functions can be found in the base
* class @p{FunctionTime}.
*
- * {\bf Note}: if the functions you are dealing with have sizes which
+ * @em{Note}: if the functions you are dealing with have sizes which
* are a priori known (for example, @p{dim} elements), you might
* consider using the @p{TensorFunction} class instead.
*
* for time dependent problems.
*
* Access to the time goes through the following functions:
- * \begin{verbatim}
- * \item @p{get_time}: return the present value of the time variable.
- * \item @p{set_time}: set the time value to a specific value.
- * \item @p{advance_time}: increase the time by a certain time step.
- * \end{verbatim}
+ * @begin{verbatim}
+ * @item @p{get_time}: return the present value of the time variable.
+ * @item @p{set_time}: set the time value to a specific value.
+ * @item @p{advance_time}: increase the time by a certain time step.
+ * @end{verbatim}
* The latter two functions are virtual, so that derived classes can
* perform computations which need only be done once for every new time.
* For example, if a time dependent function had a factor @p{sin(t)}, then
/**
* A class that simplifies the process of execution logging. It does so by
* providing
- * \begin{itemize}
- * \item a push and pop mechanism for prefixes, and
- * \item the possibility of distributing information to files and the
+ * @begin{itemize}
+ * @item a push and pop mechanism for prefixes, and
+ * @item the possibility of distributing information to files and the
* console.
- * \end{itemize}
+ * @end{itemize}
*
* The usual usage of this class is through the pregenerated object
* @p{deallog}. Typical steps are
* Declare some regexps which
* may be used to define patterns.
*/
-struct Patterns {
+struct Patterns
+{
public:
/**
* Base class to declare common
* interface.
*/
- class PatternBase {
+ class PatternBase
+ {
public:
/**
* Make destructor of this and all
* derived classes virtual.
*/
- virtual ~PatternBase () {};
+ virtual ~PatternBase ();
/**
* Return true if the given string
* Test for the string being an
* integer.
*/
- class Integer : public PatternBase {
+ class Integer : public PatternBase
+ {
public:
virtual bool match (const string &test_string) const;
virtual string description () const;
/**
* Test for the string being a double.
*/
- class Double : public PatternBase {
+ class Double : public PatternBase
+ {
public:
virtual bool match (const string &test_string) const;
virtual string description () const;
* signs do not matter and are
* eliminated.
*/
- class Selection : public PatternBase {
+ class Selection : public PatternBase
+ {
public:
Selection (const string &seq);
virtual bool match (const string &test_string) const;
* However, commas are not allowed inside
* the values given to the constructor.
*/
- class MultipleSelection : public PatternBase {
+ class MultipleSelection : public PatternBase
+ {
public:
MultipleSelection (const string &seq);
virtual bool match (const string &test_string) const;
* "true" or "false". This is mapped
* to the @p{Selection} class.
*/
- class Bool : public Selection {
+ class Bool : public Selection
+ {
public:
Bool ();
virtual PatternBase * clone () const;
* Always returns true when testing a
* string.
*/
- class Anything : public PatternBase {
+ class Anything : public PatternBase
+ {
public:
/**
* Allow for at least one non-virtual
* which provides at run-time for program parameters such as time step sizes,
* geometries, right hand sides etc. The input for the program is given in files,
* streams or strings in memory using text like
- * \begin{verbatim}
+ * @begin{verbatim}
* set Time step size = 0.3
* set Geometry = [0,1]x[0,3]
- * \end{verbatim}
+ * @end{verbatim}
* Input may be sorted into subsection trees in order to give the input a logical
* structure.
*
* In order to use the facilities of a @p{ParameterHandler} object, one first has
* to make known the different entries the input file may or may not contain. This
* is done in the following way:
- * \begin{verbatim}
+ * @begin{verbatim}
* ...
* ParameterHandler prm;
* prm.declare_entry ("Time step size",
* "[0,1]x[0,1]",
* Patterns::Anything());
* ...
- * \end{verbatim}
+ * @end{verbatim}
* Each entry is declared using the function @p{declare_entry}. The first parameter is
* the name of the entry (in short: the entry). The second is the default answer to
* be taken in case the entry is not specified in the input file. The third parameter
* input parameters for linear solver routines should be classified in a subsection
* named @p{Linear solver} or any other suitable name. This is accomplished in the
* following way:
- * \begin{verbatim}
+ * @begin{verbatim}
* ...
* LinEq eq;
* eq.declare_parameters (prm);
* ...
* prm.leave_subsection ();
* };
- * \end{verbatim}
+ * @end{verbatim}
*
* Subsections may be nested. For example a nonlinear solver may have a linear solver
* as member object. Then the function call tree would be something like (if the class
* @p{NonLinEq} has a member variables @p{eq} of type @p{LinEq}):
- * \begin{verbatim}
+ * @begin{verbatim}
* void NonLinEq::declare_parameters (ParameterHandler &prm) {
* prm.enter_subsection ("Nonlinear solver");
* prm.declare_entry ("Nonlinear method",
* eq.declare_parameters (prm);
* prm.leave_subsection ();
* };
- * \end{verbatim}
+ * @end{verbatim}
*
* For class member functions which declare the different entries we propose to use the
* common name @p{declare_parameters}. In normal cases this method can be @p{static} since the
* a class has two or more member variables of the same type both of which should have
* their own parameters, this parent class' method @p{declare_parameters} is responsible to
* group them into different subsections:
- * \begin{verbatim}
+ * @begin{verbatim}
* void NonLinEq::declare_parameters (ParameterHandler &prm) {
* prm.enter_subsection ("Nonlinear solver");
* prm.enter_subsection ("Linear solver 1");
* prm.leave_subsection ();
* prm.leave_subsection ();
* };
- * \end{verbatim}
+ * @end{verbatim}
*
*
* @sect3{Input files and special characters}
*
* For the first example above the input file would look like the following:
- * \begin{verbatim}
+ * @begin{verbatim}
* ...
* subsection Nonlinear solver
* set Nonlinear method = Gradient
* end
* end
* ... # other stuff
- * \end{verbatim}
+ * @end{verbatim}
* The words @p{subsection}, @p{set} and @p{end} may be either written in lowercase or uppercase
* letters. Leading and trailing whitespace is removed, multiple whitespace is condensed into
* only one. Since the latter applies also to the name of an entry, an entry name will not
* be recognised if in the declaration multiple whitespace is used.
*
* In entry names and values the following characters are not allowed: @p{#}, @p{\{},
- * @p{\}}, @p{|}. Their use is reserved for the \ref{MultipleParameterLoop} class.
+ * @p{\}}, @p{|}. Their use is reserved for the @ref{MultipleParameterLoop} class.
*
* Comments starting with \# are skipped.
*
* In order to read input you can use three possibilities: reading from an @p{istream} object,
* reading from a file of which the name is given and reading from a string in memory in
* which the lines are separated by @p{\n} characters. These possibilites are used as follows:
- * \begin{verbatim}
+ * @begin{verbatim}
* ParameterHandler prm;
* ...
* // declaration of entries
* char *in = "set Time step size = 0.3 \n ...";
* prm.read_input (in);
* ...
- * \end{verbatim}
+ * @end{verbatim}
* You can use several sources of input successively. Entries which are changed more than
* once will be overwritten everytime they are used. It is suggested to let the name of
* parameter input end in @p{.prm}.
*
* Each class gets its data out of a @p{ParameterHandler} object by calling the @p{get (...)}
* member functions like this:
- * \begin{verbatim}
+ * @begin{verbatim}
* void NonLinEq::get_parameters (ParameterHandler &prm) {
* prm.enter_subsection ("Nonlinear solver");
* string method = prm.get ("Nonlinear method");
* eq.get_parameters (prm);
* prm.leave_subsection ();
* };
- * \end{verbatim}
+ * @end{verbatim}
* @p{get()} returns the value of the given entry. If the entry was not specified in the input
* source(s), the default value is returned. You have to enter and leave subsections
* exactly as you did when declaring subsection. You may chose the order in which to
*
* @sect3{Possible future extensions}
*
- * \begin{itemize}
- * \item Allow long input lines to be broken by appending a backslash character
+ * @begin{itemize}
+ * @item Allow long input lines to be broken by appending a backslash character
* (just like C macros and shell input).
- * \item Provide an @p{input filename} command for the input file to enable users to put the
+ * @item Provide an @p{input filename} command for the input file to enable users to put the
* most common parameters into separate files.
- * \end{itemize}
+ * @end{itemize}
*
*
*
* @sect3{Worked Example}
*
* This is the code:
- * \begin{verbatim}
+ * @begin{verbatim}
* #include <iostream>
* #include "../include/parameter_handler.h"
*
* << "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
* 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
* 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
*/
* 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
* 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 ();
* 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
* @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);
*
* 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.
*
* 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 }}
* 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
* 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.
*
* @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
*
* @p{SmartPointer} does NOT implement any memory handling! Especially,
* deleting a @p{SmartPointer} does not delete the object. Writing
- * \begin{verbatim}
+ * @begin{verbatim}
* SmartPointer<T> t = new T;
- * \end{verbatim}
+ * @end{verbatim}
* is a sure way to program a memory leak! The secure version is
- * \begin{verbatim}
+ * @begin{verbatim}
* T* p = new T;
* {
* SmartPointer<T> t = p;
* ...
* }
* delete p;
- * \end{verbatim}
+ * @end{verbatim}
*
* Note that a smart pointer can handle @p{const}ness of an object, i.e.
* a @p{SmartPointer<const ABC>} really behaves as if it were a pointer to
* 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)
* ofstream out_file("number_table.tex");
* table.write_tex(out_file);
* out_file.close();
- * \end{verbatim}
+ * @end{verbatim}
*
* @author Ralf Hartmann, 1999
*/
*
* Use of this class is as you might expect by looking at the member
* functions:
- * \begin{verbatim}
+ * @begin{verbatim}
* Time timer;
* timer.start ();
*
*
* // 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
#include <list>
-bool Patterns::Integer::match (const string &test_string) const {
+
+Patterns::PatternBase::~PatternBase ()
+{};
+
+
+
+bool Patterns::Integer::match (const string &test_string) const
+{
istrstream str(test_string.c_str());
int i;
if (str >> i) return true;
};
-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;
};
-string Patterns::Double::description () const {
+
+string Patterns::Double::description () const
+{
return "[Integer]";
};
};
-Patterns::Selection::Selection (const string &seq) {
+
+Patterns::Selection::Selection (const string &seq)
+{
sequence = seq;
while (sequence.find(" |") != string::npos)
};
-bool Patterns::Selection::match (const string &test_string) const {
+
+bool Patterns::Selection::match (const string &test_string) const
+{
vector<string> choices;
string tmp(sequence);
// check the different possibilities
};
-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;
};
-bool Patterns::MultipleSelection::match (const string &test_string_list) const {
+
+bool Patterns::MultipleSelection::match (const string &test_string_list) const
+{
string tmp = test_string_list;
list<string> split_list;
};
-// check the different possibilities
+ // check the different possibilities
for (list<string>::const_iterator test_string = split_list.begin();
test_string != split_list.end(); ++test_string)
{
};
-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;
};
+
bool ParameterHandler::read_input (const string &filename)
{
ifstream input (filename.c_str());
}
-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;
};
-void ParameterHandler::clear () {
+
+void ParameterHandler::clear ()
+{
status = true;
subsection_path.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:
};
-void ParameterHandler::enter_subsection (const string &subsection) {
+
+void ParameterHandler::enter_subsection (const string &subsection)
+{
Section* pd = get_present_defaults_subsection ();
// does subsection already exist?
};
-bool ParameterHandler::leave_subsection () {
+
+bool ParameterHandler::leave_subsection ()
+{
// assert there is a subsection that
// we may leave
// (use assert since this is a logical
};
-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 ();
};
-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);
};
-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);
};
-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));
};
-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());
};
+
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());
};
-// now transverse subsections tree
+ // now transverse subsections tree
map<string, Section*>::const_iterator ptrss;
for (ptrss = pd->subsections.begin(); ptrss != pd->subsections.end(); ++ptrss)
{
};
-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);
};
-ParameterHandler::Section* ParameterHandler::get_present_defaults_subsection () {
+
+ParameterHandler::Section* ParameterHandler::get_present_defaults_subsection ()
+{
Section* sec = &defaults;
vector<string>::const_iterator SecName = subsection_path.begin();
};
-const ParameterHandler::Section* ParameterHandler::get_present_defaults_subsection () const {
+
+const ParameterHandler::Section* ParameterHandler::get_present_defaults_subsection () const
+{
Section* sec = const_cast<Section*>(&defaults); // not nice, but needs to be and
// after all: we do not change @p{sec}
vector<string>::const_iterator SecName = subsection_path.begin();
};
-ParameterHandler::Section* ParameterHandler::get_present_changed_subsection () {
+
+ParameterHandler::Section* ParameterHandler::get_present_changed_subsection ()
+{
Section* sec = &changed_entries;
vector<string>::iterator SecName = subsection_path.begin();
};
-const ParameterHandler::Section* ParameterHandler::get_present_changed_subsection () const {
+
+const ParameterHandler::Section* ParameterHandler::get_present_changed_subsection () const
+{
Section* sec = const_cast<Section*>(&changed_entries); // same as in get_present_default_s...
vector<string>::const_iterator SecName = subsection_path.begin();
};
+
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);
};
+
bool MultipleParameterLoop::read_input (const string &filename)
{
return ParameterHandler::read_input (filename);
};
-bool MultipleParameterLoop::read_input_from_string (const char *s) {
+
+bool MultipleParameterLoop::read_input_from_string (const char *s)
+{
bool x = ParameterHandler::read_input (s);
init_branches ();
return x;
};
-void MultipleParameterLoop::loop (MultipleParameterLoop::UserClass &uc) {
+
+void MultipleParameterLoop::loop (MultipleParameterLoop::UserClass &uc)
+{
for (int run_no=0; run_no<n_branches; ++run_no)
{
// give create_new one-based numbers
};
-void MultipleParameterLoop::init_branches () {
+
+void MultipleParameterLoop::init_branches ()
+{
multiple_choices.clear ();
ParameterHandler::Section *sec;
<< " " << n_branches << " variant runs that will be performed." << endl;
-// do a first run on filling the values to
+ // do a first run on filling the values to
// check for the conformance with the regexp
// (afterwards, this will be lost in the whole
// other output)
};
-void MultipleParameterLoop::init_branches_section (const ParameterHandler::Section &sec) {
+
+void MultipleParameterLoop::init_branches_section (const ParameterHandler::Section &sec)
+{
// check all entries in the present subsection
// whether it is a multiple entry
Section::EntryType::const_iterator e;
e->second.first));
-// transverse subsections
+ // transverse subsections
map<string, Section*>::const_iterator s;
for (s = sec.subsections.begin(); s != sec.subsections.end(); ++s)
{
};
-void MultipleParameterLoop::fill_entry_values (const unsigned int run_no) {
+
+void MultipleParameterLoop::fill_entry_values (const unsigned int run_no)
+{
int possibilities = 1;
vector<Entry>::iterator choice;
};
+
MultipleParameterLoop::Entry::Entry (const vector<string> &ssp,
const string& Name,
const string& Value) :
- subsection_path (ssp), entry_name(Name), entry_value(Value) {};
+ subsection_path (ssp), entry_name(Name), entry_value(Value)
+{};
+
-void MultipleParameterLoop::Entry::split_different_values () {
+void MultipleParameterLoop::Entry::split_different_values ()
+{
// split string into three parts:
// part before the opening "{",
// the selection itself, final
my $out = "";
my $text;
- # escape @x commands
- foreach $text ( split (/(\@\w+(?:\s+.+?(?=\s)|\{.*?\}))/, $str ) ) {
-
+ # first escape @x directives. these are @x commands that do
+ # not take parameters, i.e. they do not take an argument which
+ # would either be the next word or the string in braces after
+ # the command name
+ $str =~ s/\@item/<li>/g;
+
+ # escape @x commands. by using the `split' command, we get a
+ # list of strings that contain either the matched command or the
+ # string in between. if an element of this list matches a
+ # command, then we process it further, otherwise we simply
+ # copy it over to the output
+ foreach $text ( split (/(\@\w+(?:\s+.+?(?=\s)|\{.*?\}))/, $str ) ) {
# check whether $text is an @command or the text between
# @commands
if ( $text =~ /\@(\w+)(?:\s+(.+?)(?:\s|$)|\{(.*?)\})/ ) {
$out .= "<h$1>".esc($content)."</h$1>";
}
+ # @begin{...} -- start environment
+ elsif ( $command =~ /^begin$/ ) {
+ if ( $content eq "itemize" ) {
+ $out .= "<ul>";
+ }
+ elsif ( $content eq "enumerate" ) {
+ $out .= "<ol>";
+ }
+ elsif ( $content eq "verbatim" ) {
+ $out .= "<pre><code>";
+ }
+ else {
+ print "Unknown command @", "$command($content)\n";
+ $out .= esc($text);
+ }
+ }
+
+ # @end{...} -- close environment
+ elsif ( $command =~ /^end$/ ) {
+ if ( $content eq "itemize") {
+ $out .= "</ul>";
+ }
+ elsif ( $content eq "enumerate") {
+ $out .= "</ol>";
+ }
+ elsif ( $content eq "verbatim") {
+ $out .= "</code></pre>";
+ }
+ else {
+ print "Unknown command @", "$command($content)\n";
+ $out .= esc($text);
+ }
+ }
+
# unknown command. warn and copy command
else {
print "Unknown command @", $command, "\n";
$out .= esc($text);
}
}
- # no @x command, thus regular text
+ # no @x command, thus regular text. simply forward it
else {
$out .= esc($text);
}
* 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
*
* @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
/**
* 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
*
* @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
* 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
* @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
* 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.
/**
* 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>
/**
* 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:
/**
* 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:
/**
* 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:
* 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
/**
* Space to store the DoF numbers for the
* different levels. Analogous to the
- * @p{levels[]} tree of the \Ref{Triangulation}
+ * @p{levels[]} tree of the @ref{Triangulation}
* objects.
*/
vector<DoFLevel<dim>*> levels;
public:
/**
* Store the global indices of the degrees
- * of freedom. See \Ref{DoFLevel} for
+ * of freedom. See @ref{DoFLevel} for
* detailed information.
*/
vector<unsigned int> line_dofs;
/**
* Store the indices of the degrees of freedom which are located on quads.
- * See \Ref{DoFLevel<1>} for more information.
+ * See @ref{DoFLevel<1>} for more information.
*/
class DoFLevel<2> : public DoFLevel<1> {
public:
/**
* Store the global indices of the degrees
- * of freedom. See \Ref{DoFLevel} for
+ * of freedom. See @ref{DoFLevel} for
* detailed information.
*/
vector<unsigned int> quad_dofs;
/**
* Store the indices of the degrees of freedom which are located on hexhedra.
- * See \Ref{DoFLevel<1>} for more information.
+ * See @ref{DoFLevel<1>} for more information.
*/
class DoFLevel<3> : public DoFLevel<2> {
public:
/**
* Store the global indices of the degrees
- * of freedom. See \Ref{DoFLevel} for
+ * of freedom. See @ref{DoFLevel} for
* detailed information.
*/
vector<unsigned int> hex_dofs;
* 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
* 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
* 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
* 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}
* *-->---*-->---*
* | | |
* ^ ^ ^
* ^ ^ ^
* | | |
* *-->---*-->---*
- * \end{verbatim}
+ * @end{verbatim}
* The orientation of the quads should be obvious.
*
* The faces of a hexahedron are arranged in a way such that
* 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}
* *---------*---------*
* / / /|
* / / / |
* | | | /
* | | |/
* *---------*---------*
- * \end{verbatim}
+ * @end{verbatim}
*
* Assume the two top faces represent the boundary of the
* triangulation; assume further that the boundary of the original
* 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}
* ..*--.*---..*---------*
* *----*----* / /|
* : : :/ / |
* | | | | /
* | | | |/
* *----*----*---------*
- * \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
* 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
* 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
* 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
*/
* 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.
*
* however be noted that the support of basis functions get quite
* complicated in the presence of hanging nodes, as the following figure
* depicts:
- * \begin{verbatim}
+ * @begin{verbatim}
* *-----------------*--------*----
* | /|\ |
* | /..|.\ |
* | /...............|.....\ |
* |/................|.......\|
* *-----------------o--------*-----
- * \end{verbatim}
+ * @end{verbatim}
* The dotted area is the support of the basis function associated with the
* bottom middle vertex (denoted by @p{o}) after the hanging node in the center
* of the `picture' was eliminated. This strange structure of the support
* When using one of the usual quadrature formulae, a common problem is
* that some of the quadrature points lie on the interfaces of the
* triangles. For this reason, there is a family of quadrature formulae
- * defined below, names \ref{QCrissCross1} and higher order, which
+ * defined below, names @ref{QCrissCross1} and higher order, which
* resemble the quadrature formulae used on triangular domains, but
* taken four-fold, i.e. for each of the four subtriangles.
*
* 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
* | / 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
*/
* 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
* 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.
* 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
* 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.
* 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
* @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.)
* 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}
* 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
* 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
* 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
*
* For example, in 2D the layout of
* a cell is as follows:
- * \begin{verbatim}
+ * @begin{verbatim}
* . 2
* . 3-->--2
* . | |
* . | |
* . 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
* 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
* 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$
* $[-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
* 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)},
* 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
*/
*
* 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.
*
*
* 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
* 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 |
* 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 |
* 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
*
* @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.
*
* 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
* 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,
* 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
*
* 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
* 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.
* @sect2{Usage}
*
* In practice, use of this class is as follows:
- * \begin{verbatim}
+ * @begin{verbatim}
* // have two grids, which are derived from the
* // same coarse grid
* Triangulation<dim> tria1, tria2;
* // corresponding to @p{cell} (which is one of
* // dof_handler_1
* f( grid_1_to_2_map[cell]);
- * \end{verbatim}
+ * @end{verbatim}
*
* Note that the template parameters to this class have to be given as
* @p{InterGridMap<DoFHandler,2>}, i.e. the dimension is given explicitely and
* object of this class.
*
* Basically, usage looks like this:
- * \begin{verbatim}
+ * @begin{verbatim}
* Triangulation<dim> coarse_grid;
* ... // initialize coarse grid
*
* // 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
* @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
* 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;
* 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> {
* 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;
* 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> {
* 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.
*
* @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;
* 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,
*
* Usage of these iterators works mostly like with the STL iterators. Some
* examples taken from the @p{Triangulation} source code follow.
- * \begin{itemize}
- * \item @em{Counting the number of cells on a specific level}
- * \begin{verbatim}
+ * @begin{itemize}
+ * @item @em{Counting the number of cells on a specific level}
+ * @begin{verbatim}
* template <int dim>
* int Triangulation<dim>::n_cells (const int level) const {
* cell_iterator cell = begin (level),
* ++n;
* return n;
* };
- * \end{verbatim}
+ * @end{verbatim}
* Another way which uses the STL @p{distance} function would be to write
- * \begin{verbatim}
+ * @begin{verbatim}
* template <int dim>
* int Triangulation<dim>::n_cells (const int level) const {
* int n=0;
* n);
* return n;
* };
- * \end{verbatim}
+ * @end{verbatim}
*
- * \item @em{Refining all cells of a triangulation}
- * \begin{verbatim}
+ * @item @em{Refining all cells of a triangulation}
+ * @begin{verbatim}
* template <int dim>
* void Triangulation<dim>::refine_global () {
* active_cell_iterator cell = begin_active(),
* 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;
*
* 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
*
* There are more subtle conditions which must be imposed upon the
* vertex numbering within cells. See the documentation for the
- * \Ref{DataIn} class for more details on this. They do not only
+ * @ref{DataIn} class for more details on this. They do not only
* hold for the data read from an UCD or any other input file, but
* also for the data passed to the
* @p{Triangulation<dim>::create_triangulation (2)} function.
*
- * \item Copying a triangulation: when computing on time dependant meshes
+ * @item Copying a triangulation: when computing on time dependant meshes
* of when using adaptive refinement, you will often want to create a
* new triangulation to be the same as another one. This is facilitated
* by the @p{copy_triangulation} function.
* 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
*
* 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
* 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
* @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
* 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--
* | | | | |
* | | |
* | | |
* 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
* @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
* 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
* 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
* @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}
* 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
* 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
* 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.
*
* 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
* 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
* 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
* 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
* 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
* 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
* 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
* 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
* | |
* | |
* 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.
* 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)}.
*
* 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}
* *-------* *-------*
* /| | / /|
* / | | / / |
* | / / | | /
* |/ / | |/
* *-------* *-------*
- * \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.
* 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
* /| | / /|
* / | | / / |
* | / / | | /
* |/ / | |/
* 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
* 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}
* *--->---* *--->---*
* /| | / /|
* ^ | ^ ^ ^ ^
* ^ ^ ^ ^ | ^
* |/ / | |/
* *--->---* *--->---*
- * \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 / |
* | / 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 / / |
* | / / 3 | /
* |/ / | |/
* *-------* *---0---*
- * \end{verbatim}
+ * @end{verbatim}
*
- * \item Faces 2 and 4:
- * \begin{verbatim}
+ * @item Faces 2 and 4:
+ * @begin{verbatim}
* *-------* *---2---*
* /| | / /|
* / | | 3 1 |
* | 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
* | 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|
* |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.
*
*
* 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
* /| | / /|
* / | | / / |
* | / | / / | | /
* |/ |/ / | |/
* *------>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
*
* 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}
/**
* 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
* 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;
* 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;
*
* 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
* 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)),
* 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
/**
- * Specialisation of \Ref{Boundary}<dim>, which places the new point right
+ * Specialisation of @ref{Boundary}<dim>, which places the new point right
* into the middle of the given points. The middle is defined as the
* arithmetic mean of the points.
*
/**
- * Specialisation of \Ref{Boundary}<dim>, which places the new point on
+ * Specialisation of @ref{Boundary}<dim>, which places the new point on
* the boundary of a ball in arbitrary dimension. It works by projecting
* the point in the middle of the old points onto the ball. The middle is
* defined as the arithmetic mean of the points.
* 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
* 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.
*
*
* 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).
* only becomes useful when assigned an @p{Accessor} (the second template
* parameter), which really does the access to data. An @p{Accessor} has to
* fulfil some requirements:
- * \begin{itemize}
- * \item It must have two members named @p{present_level} and @p{present_index}
+ * @begin{itemize}
+ * @item It must have two members named @p{present_level} and @p{present_index}
* storing the address of the element in the triangulation presently
* pointed to. Furthermore, the three @p{Tria{Raw| |Active}Iterator} classes
* have to be friends to the accessor or these data members must be public.
- * \item It must have a constructor which takes 1. a @p{Triangulation<dim>*},
+ * @item It must have a constructor which takes 1. a @p{Triangulation<dim>*},
* 2. and 3. and integer, denoting the initial level and index.
- * \item For the @p{TriaIterator} and the @p{TriaActiveIterator} class, it must
+ * @item For the @p{TriaIterator} and the @p{TriaActiveIterator} class, it must
* have a member function @p{bool used()}, for the latter a member function
* @p{bool active()}.
- * \item It must have void operators @p{++} and @p{--}.
- * \item It must declare a local @p{typedef} @p{AccessorData} which states
+ * @item It must have void operators @p{++} and @p{--}.
+ * @item It must declare a local @p{typedef} @p{AccessorData} which states
* the data type the accessor expects to get passed as fourth constructor
* argument. By declaring a local data type, the respective iterator
* class may type-safely enforce that data type to be one of its own
* constructor argument types. If an accessor class does not need
* additional data, this type shall be @p{void}.
- * \end{itemize}
+ * @end{itemize}
* Then the iterator is able to do what it is supposed to. All of the necessary
* functions are implemented in the @p{Accessor} base class, but you may write
* your own version (non-virtual, since we use templates) to add functionality.
*
* There is a standard implementation, using classes which are derived from
- * \Ref{TriaAccessor}. These classes point to @p{Line}s, @p{Quad}s and the like.
+ * @ref{TriaAccessor}. These classes point to @p{Line}s, @p{Quad}s and the like.
* For advanced use of the iterator classes, derive classes from
* @p{{Line|Quad|Cell}Accessor} which also dereference data structures in other
* objects, e.g. in a finite element context. An iterator with such an accessor
* 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);
/**
- * This specialization of \Ref{TriaRawIterator} provides access only to the
+ * This specialization of @ref{TriaRawIterator} provides access only to the
* @em{used} lines, quads, cells, etc.
*/
template <int dim, typename Accessor>
/**
- * 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.
*/
* 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.
* 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
/**
* 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
*
* @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
/**
* 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>
/**
* 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:
/**
* 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:
/**
* 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:
* 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 {
*
* 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
* 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.
*
* 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
*
* 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
* 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
* vectors which will later be written to a file in some format. Instead of
* pondering about the different functions, an example is probably the best
* way:
- * \begin{verbatim}
+ * @begin{verbatim}
* ...
* ... // compute solution, which is of type Vector<double>
* ... // and contains nodal values
* 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
* which is suitable for quadratic finite elements in space, for
* example.
*
- * \begin{verbatim}
+ * @begin{verbatim}
* DataOutStack<dim> data_out_stack;
*
* // first declare the vectors
* data_out_stack.build_patches (2);
* data_out_stack.finish_parameter_value ();
* };
- * \end{verbatim}
+ * @end{verbatim}
*
* @author Wolfgang Bangerth, 1999
*/
*
* 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,
* 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.
*
* @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
* @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.
* parameters, you need to pass a function object representing the
* respective number of components.
*
- * \item @p{create_laplace_matrix}: there are two versions of this; the
+ * @item @p{create_laplace_matrix}: there are two versions of this; the
* one which takes the @p{Function<dim>} object creates
* $a_{ij} = \int_\Omega a(x) \nabla\phi_i(x) \nabla\phi_j(x) dx$,
* $a$ being the given function, while the other one assumes that
* 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
*
* 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
* 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
* 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
* justifyable to quickly try something out. In the further process it
* may be useful to replace this behaviour by more sophisticated methods,
* however.
- * \end{itemize}
+ * @end{itemize}
*/
template <int dim>
class MassMatrix : public Equation<dim> {
* coarsening is much more complicated to organize
* (see further documentation below) than interpolation while pure refinement,
* @p{SolutionTransfer} offers two possible usages.
- * \begin{itemize}
- * \item If the grid will only be purely refined
+ * @begin{itemize}
+ * @item If the grid will only be purely refined
* (i.e. not locally coarsened) then use @p{SolutionTransfer} as follows
- * \begin{verbatim}
+ * @begin{verbatim}
* SolutionTransfer<dim, double> soltrans(*dof_handler);
* soltrans.prepare_for_pure_refinement();
* // some refinement e.g.
* // more functions
* soltrans.refine_interpolate(sol2, interpolated_sol2);
* ...
- * \end{verbatim}
- * \item If the grid will be coarsenend and refined
+ * @end{verbatim}
+ * @item If the grid will be coarsenend and refined
* then use @p{SolutionTransfer} as follows
- * \begin{verbatim}
+ * @begin{verbatim}
* SolutionTransfer<dim, double> soltrans(*dof_handler);
* // some refinement e.g.
* tria->refine_and_coarsen_fixed_fraction(error_indicator, 0.3, 0.05);
* tria->execute_coarsening_and_refinement ();
* dof_handler->distribute_dofs (fe);
* soltrans.interpolate(solution, interpolated_solution);
- * \end{verbatim}
+ * @end{verbatim}
*
* Multiple calling of the function
* @p{interpolate (const Vector<number> &in, Vector<number> &out)}
* 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.
*
* @sect3{Implementation}
*
- * \begin{itemize}
- * \item Solution transfer while pure refinement. Assume that we have got a
+ * @begin{itemize}
+ * @item Solution transfer while pure refinement. Assume that we have got a
* solution vector on the current (original) grid.
* Each entry of this vector belongs to one of the
* DoFs of the discretisation. If we now refine the grid then the calling of
* The @p{refine_interpolate(in,out)} function can be called multiplely for
* arbitrary many discrete functions (solution vectors) on the original grid.
*
- * \item Solution transfer while coarsening and refinement. After
+ * @item Solution transfer while coarsening and refinement. After
* calling @p{Triangulation::prepare_coarsening_and_refinement} the
* coarsen flags of either all or none of the children of a
* (father-)cell are set. While coarsening
* of the @p{prepare_for_coarsening_and_refinement(all_in)} function. Hence
* @p{interpolate(all_in, all_out)} can (in contrast to
* @p{refine_interpolate(in, out)}) only be called once.
- * \end{itemize}
+ * @end{itemize}
*
* @author Ralf Hartmann, 1999
*/
* 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
* notify timestep i of the end of the sweep, e.g. for cleanups,
* deletion of temporary files, etc.
* }
- * \end{verbatim}
+ * @end{verbatim}
* The user may specify that a loop shall run forward or backward (the latter
* being needed for the solution of global dual problems, for example).
*
* data of the last two time steps, the following pseudocode described
* what the centeral loop function of this class will do when we move
* from timestep @p{n-1} to timestep @p{n}:
- * \begin{verbatim}
+ * @begin{verbatim}
* wake up timestep n+1 with signal 1
* wake up timestep n with signal 0
* do computation on timestep n
* let timestep n-2 sleep with signal 2
*
* move from n to n+1
- * \end{verbatim}
+ * @end{verbatim}
* The signal number here denotes the distance of the timestep being sent
* the signal to the timestep where computations are done on. The calls to
* the @p{wake_up} and @p{sleep} functions with signal 0 could in principle
*
* From the given sketch above, it is clear that each time step object sees
* the following sequence of events:
- * \begin{verbatim}
+ * @begin{verbatim}
* wake up with signal 1
* wake up signal 0
* do computation
* sleep with signal 0
* sleep with signal 1
* sleep with signal 2
- * \end{verbatim}
+ * @end{verbatim}
* This pattern is repeated for each loop in each sweep.
*
* For the different loops within each sweep, the numbers of timesteps
*
* The main loop of a program using this class will usually look like
* the following one, taken modified from the wave program:
- * \begin{verbatim}
+ * @begin{verbatim}
* template <int dim>
* void TimeDependent_Wave<dim>::run_sweep (const unsigned int sweep_no)
* {
* for (unsigned int sweep=0; sweep<number_of_sweeps; ++sweep)
* timestep_manager.run_sweep (sweep);
* };
- * \end{verbatim}
+ * @end{verbatim}
* Here, @p{timestep_manager} is an object of type @p{TimeDependent_Wave}, which
* is a class derived from @p{TimeDependent}. @p{start_sweep},
* @p{solve_primal_problem}, @p{solve_dual_problem}, @p{postprocess} and @p{end_sweep}
* timesteps within this object and call the respective function on each of
* these objects. For example, here are two of the functions as they are
* implemented by the library:
- * \begin{verbatim}
+ * @begin{verbatim}
* void TimeDependent::start_sweep (const unsigned int s)
* {
* sweep_no = s;
* timestepping_data_primal,
* forward);
* };
- * \end{verbatim}
+ * @end{verbatim}
* The latter function shows rather clear how most of the loops are
* invoked (@p{solve_primal_problem}, @p{solve_dual_problem}, @p{postprocess},
* @p{refine_grids} and @p{write_statistics} all have this form, where the
* the @p{C++} standard library, it is possible to do neat tricks, like
* the following, also taken from the wave program, in this case from
* the function @p{refine_grids}:
- * \begin{verbatim}
+ * @begin{verbatim}
* ...
* compute the thresholds for refinement
* ...
* bottom_threshold)),
* TimeDependent::TimeSteppingData (0,1),
* TimeDependent::forward);
- * \end{verbatim}
+ * @end{verbatim}
* @p{TimeStepBase_Wave<dim>::refine_grid} is a function taking an argument, unlike
* all the other functions used above within the loops. However, in this special
* case the parameter was the same for all timesteps and known before the loop
* brevity we have omitted the parts that deal with backward running loops
* as well as the checks whether wake-up and sleep operations act on timesteps
* outside @p{0..n_timesteps-1}.
- * \begin{verbatim}
+ * @begin{verbatim}
* template <typename InitFunctionObject, typename LoopFunctionObject>
* void TimeDependent::do_loop (InitFunctionObject init_function,
* LoopFunctionObject loop_function,
* for (int look_back=0; look_back<=timestepping_data.look_back; ++look_back)
* timesteps[step-look_back]->sleep(look_back);
* };
- * \end{verbatim}
+ * @end{verbatim}
*
*
* @author Wolfgang Bangerth, 1999
*
* This mechanism usually will result
* in a set-up loop like this
- * \begin{verbatim}
+ * @begin{verbatim}
* for (i=0; i<N; ++i)
* manager.add_timestep(new MyTimeStep());
- * \end{verbatim}
+ * @end{verbatim}
*/
void add_timestep (TimeStepBase *new_timestep);
/**
* 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
* 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
* 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
* 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
* 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
* 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
* 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
* by looping iteratively through all grids, back and forth, until nothing
* changes anymore, which is obviously impossible if there are many time steps
* with very large grids.
- * \end{itemize}
+ * @end{itemize}
*/
template <int dim>
struct TimeStepBase_Tria<dim>::RefinementFlags
/**
* 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,
* @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
* 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
* 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.
*
* 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
* 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
*
* 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,
<p>
In order to allow better structured output for long comments, we
have extended <acronym>kdoc</acronym> to understand the following
- tags inside comments (since they are LaTeX, they are understood by
- the LaTeX output of Doc++ automatically):
+ tags inside comments, which are partly borrowed from LaTeX like
+ languages:
<ul>
<li> <em>Itemized lists:</em>
<p>
By writing comments like the following,
<code><pre>
/**
- * \begin{itemize}
- * \item foo
- * \item bar
- * \end{itemize}
+ * @begin{itemize}
+ * @item foo
+ * @item bar
+ * @end{itemize}
*/
</pre></code>
you can get itemized lists both in the online and printed
<li> bar
</ul>
</p>
+
+ <p>
+ Likewise, you can get numbered lists by using the tags
+ <code>@begin{enumerate}</code> and
+ <code>@end{enumerate}</code> along with <code>@item</code>s.
+ </p>
<li> <em>Verbatim output:</em>
<p>
If you write comments like this,
<code><pre>
/**
- * \begin{verbatim}
+ * @begin{verbatim}
* void foobar ()
* {
* i = 0;
* };
- * \end{verbatim}
+ * @end{verbatim}
*/
</pre></code>
you will get the lines between the verbatim environment with
notably the example programs is not really supported, and we
consider ways to convert them to SGML along with most other
documentation, since SGML is readily convertible into many other
- formats, for Postscript.
- </p>
-
- <p>
- Switching to SGML would also include replacing the LaTeX-like
- layout extensions described above by their DocBook SGML
- alikes. However, since this is not imminent, you need not care
- about this at present. However, if you have spare time to pass, it
- would be a valuable goal to invent a way to, for example, convert
- the example programs to DocBook SGML.
+ formats, for example Postscript.
</p>
* 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.
*/
* @sect3{Use}
* You will usually not want to create a named object of this type,
* although possible. The most common use is like this:
- * \begin{verbatim}
+ * @begin{verbatim}
* SolverGMRES<SparseMatrix<double>,
* Vector<double> > gmres(control,memory,500);
*
* gmres.solve (matrix, solution, right_hand_side,
* PreconditionUseMatrix<SparseMatrix<double>,Vector<double> >
* (matrix,&SparseMatrix<double>::template precondition_Jacobi));
- * \end{verbatim}
+ * @end{verbatim}
* This creates an unnamed object to be passed as the fourth parameter to
* the solver function of the @p{SolverGMRES} class. It assumes that the
* @p{SparseMatrix} class has a function @p{precondition_Jacobi} taking two
*
* Note that due to the default template parameters, the above example
* could be written shorter as follows:
- * \begin{verbatim}
+ * @begin{verbatim}
* ...
* gmres.solve (matrix, solution, right_hand_side,
* PreconditionUseMatrix<>
* (matrix,&SparseMatrix<double>::template precondition_Jacobi));
- * \end{verbatim}
+ * @end{verbatim}
*
* @author Guido Kanschat, Wolfgang Bangerth, 1999
*/
*
* @sect3{Usage}
* The simplest use of this class is the following:
- * \begin{verbatim}
+ * @begin{verbatim}
* // generate a @p{SolverControl} and
* // a @p{VectorMemory}
* SolverControl control;
* // call the @p{solve} function with this
* // preconditioning as last argument
* solver.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;
* 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
* class, they are rather intended to form a `signature' which a concrete
* class has to conform to.
*
- * \begin{verbatim}
+ * @begin{verbatim}
* class Matrix
* {
* public:
* void equ (double a, const Vector& x,
* double b, const Vector& z);
* };
- * \end{verbatim}
+ * @end{verbatim}
*
*
* @sect3{AdditionalData}
* 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));
*
* // 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
* 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
{
*
* @sect3{Usage}
* The simplest use of this class is the following:
- * \begin{verbatim}
+ * @begin{verbatim}
* // generate a @p{SolverControl} and
* // a @p{VectorMemory}
* SolverControl control;
* // call the @p{solve} function with this
* // preconditioning as last argument
* solver_selector.solve(A,x,b,preconditioning);
- * \end{verbatim}
+ * @end{verbatim}
* But the full usefulness of the @p{SolverSelector} class is not
* clear until the presentation of the following example that assumes
* the user using the @p{ParameterHandler} class and having declared a
* "solver" entry, e.g. with
- * \begin{verbatim}
+ * @begin{verbatim}
* Parameter_Handler prm;
* prm.declare_entry ("solver", "none",
* Patterns::Sequence(SolverSelector::get_solver_names()));
* ...
- * \end{verbatim}
+ * @end{verbatim}
* Assuming that in the users parameter file there exists the line
- * \begin{verbatim}
+ * @begin{verbatim}
* set solver = cg
- * \end{verbatim}
+ * @end{verbatim}
* then `Line 3' of the above example reads
- * \begin{verbatim}
+ * @begin{verbatim}
* SolverSelector<SparseMatrix<double>, Vector<double> >
* solver_selector(prm.get("solver"), control, memory);
- * \end{verbatim}
+ * @end{verbatim}
*
*
* If at some time there exists a new solver "xyz" then the user does not need
*
* 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
* for j=k+1..N-1
* if (a[i,j] exists & a[k,j] exists)
* a[i,j] -= a[i,k] * a[k,j]
- * \end{verbatim}
+ * @end{verbatim}
* Using this algorithm, we store the decomposition as a sparse matrix, for
* which the user has to give a sparsity pattern and which is why this
* class is derived from the @p{SparseMatrix}. Since it is not a matrix in
* matrix, you can do so by calling the solver function using the following
* sequence, for example (@p{ilu_sparsity} is some sparsity pattern to be used
* for the decomposition, which you have to create beforehand):
- * \begin{verbatim}
+ * @begin{verbatim}
* SparseILU<double> ilu (ilu_sparsity);
* ilu.decompose (global_matrix);
*
* somesolver.solve (A, x, f,
* PreconditionUseMatrix<SparseILU<double>,Vector<double> >
* (ilu,&SparseILU<double>::template apply_decomposition<double>));
- * \end{verbatim}
+ * @end{verbatim}
*
*
* @sect2{On template instantiations}
* 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.
*/
* This little example is taken from a program doing parameter optimization.
* The Lagrange multiplier is the third component of the finite element
* used. The system is solved by the GMRES method.
- * \begin{verbatim}
+ * @begin{verbatim}
* // tag the Lagrange multiplier variable
* vector<bool> signature(3);
* signature[0] = signature[1] = false;
* // solve
* gmres.solve (global_matrix, solution, right_hand_side,
* vanka);
- * \end{verbatim}
+ * @end{verbatim}
*
*
* @sect4{Implementor's remark}
* 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
* 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
* 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}
* @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
* The following picture will illustrate the relation between the
* @p{SparsityPattern} an the @p{SparseMatrix}.
*
- * \begin{verbatim}
+ * @begin{verbatim}
* SparsityPattern: \
* |
* _________________________ |
* /_________colnums[0] |
* |
* /
- * \end{verbatim}
+ * @end{verbatim}
*
- * \begin{verbatim}
+ * @begin{verbatim}
* For row = 0
*
* it exists: (0| 3) = colnums[0]
* (1| 4) = colnums[5]
* ....
*
- * \end{verbatim}
+ * @end{verbatim}
*
- * \begin{verbatim}
+ * @begin{verbatim}
* 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
*
* \subsection{Subsection #Grid#}
* \begin{itemize}
- * \item #Coarse mesh#: Names a grid to be taken as a coarse grid. The following
+ * @item #Coarse mesh#: Names a grid to be taken as a coarse grid. The following
* names are allowed:
* \begin{itemize}
- * \item #uniform channel#: The domain is $[0,3]\times[0,1]$, triangulated
+ * @item #uniform channel#: The domain is $[0,3]\times[0,1]$, triangulated
* by three cells. Left and right boundary are of Dirichlet type, top
* and bottom boundary are of homogeneous Neumann type.
- * \item #split channel bottom#: As above, but the lower half is refined once
+ * @item #split channel bottom#: As above, but the lower half is refined once
* more than the top half.
- * \item #split channel {left | right}#: Same as #uniform channel#, but with
+ * @item #split channel {left | right}#: Same as #uniform channel#, but with
* cells on the left or right, according to the last word, more refined
* than on the other side.
- * \item #square#: $[-1,1]\times[-1,1]$.
- * \item #seismic square#: same as #square#, but with Neumann boundary
+ * @item #square#: $[-1,1]\times[-1,1]$.
+ * @item #seismic square#: same as #square#, but with Neumann boundary
* at top.
- * \item #temperature-square#: Square with size $400,000,000$ (we use the
+ * @item #temperature-square#: Square with size $400,000,000$ (we use the
* cgs system, so this amounts to 4000 km).
- * \item #temperature-testcase#: As above, but with a sequence of
+ * @item #temperature-testcase#: As above, but with a sequence of
* continuously growing cells set atop to avoid the implementation of
* absorbing boundary conditions. The left boundary is of Neumann
* type (mirror boundary).
- * \item #random#: Unit square, but randomly refined to test for correctness
+ * @item #random#: Unit square, but randomly refined to test for correctness
* of the time stepping scheme.
- * \item #earth#: Circle with radius 6371 (measured in km).
- * \end{itemize}
- * \item #Initial refinement#: States how often the grid named by the above
+ * @item #earth#: Circle with radius 6371 (measured in km).
+ * @begin{itemize}
+ * @item #Initial refinement#: States how often the grid named by the above
* parameter shall be globally refined to form the coarse mesh.
- * \item #Maximum refinement#: maximum refinement level a cell may attain.
+ * @item #Maximum refinement#: maximum refinement level a cell may attain.
* Cells with such a refinement level are flagged as others are, but they
* are not refined any more; it is therefore not necessary to lower the
* fraction of cells to be refined in order to avoid the refinement of a
* similar number of cells with a lower level number.
*
* The default to this value is zero, meaning no limit.
- * \item #Refinement fraction#: Upon refinement, those cells are refined which
+ * @item #Refinement fraction#: Upon refinement, those cells are refined which
* together make up for a given fraction of the total error. This parameter
* gives that fraction. Default is #0.95#.
- * \item #Coarsening fraction#: Similar as above, gives the fraction of the
+ * @item #Coarsening fraction#: Similar as above, gives the fraction of the
* total error for which the cells shall be coarsened. Default is #0.03#.
- * \item #Top cell number deviation#: Denotes a fraction by which the number of
+ * @item #Top cell number deviation#: Denotes a fraction by which the number of
* cells on a time level may be higher than the number of cells on the
* previous time level. This and the next two parameters help to avoid
* to much differing grids on the time levels and try to smooth the numbers
* of cells as a function of time. The default value is #0.1#.
- * \item #Bottom cell number deviation#: Denotes the fraction by which the
+ * @item #Bottom cell number deviation#: Denotes the fraction by which the
* number of cells on a time level may be lower than on the previous time
* level. Default is #0.03#.
- * \item #Cell number correction steps#: Usually, the goal denoted by the two
+ * @item #Cell number correction steps#: Usually, the goal denoted by the two
* parameters above cannot be reached directly because the number of cells
* is modified by grid regularization etc. The goal can therefore only be
* reached by an iterative process. This parameter tells how many iterations
* of this process shall be done. Default is #2#.
- * \end{itemize}
+ * @begin{itemize}
*
* \subsection{Subsection #Equation data#}
* \begin{itemize}
- * \item #Coefficient#: Names for the different coefficients for the Laplace
+ * @item #Coefficient#: Names for the different coefficients for the Laplace
* like part of the wave operator. Allowed values are:
* \begin{itemize}
- * \item #unit#: Constant one.
- * \item #kink#: One for $y<\frac 13$, 4 otherwise.
- * \item #gradient#: $1+8*y^2$.
- * \item #tube#: $0.2$ for $|x|<0.2$, one otherwise.
- * \item #temperature VAL81#: Coefficient computed from the temperature
+ * @item #unit#: Constant one.
+ * @item #kink#: One for $y<\frac 13$, 4 otherwise.
+ * @item #gradient#: $1+8*y^2$.
+ * @item #tube#: $0.2$ for $|x|<0.2$, one otherwise.
+ * @item #temperature VAL81#: Coefficient computed from the temperature
* field given by Varnazza, Avrett, Loeser 1981.
- * \item #temperature kolmogorov#: Broadened temperature spectrum.
- * \item #temperature undisturbed#: Quiet atmosphere.
- * \item #temperature monochromatic 20s#: Temperature as computed with
+ * @item #temperature kolmogorov#: Broadened temperature spectrum.
+ * @item #temperature undisturbed#: Quiet atmosphere.
+ * @item #temperature monochromatic 20s#: Temperature as computed with
* shock waves with $T=20s$.
- * \item #temperature monochromatic 40s#: Temperature as computed with
+ * @item #temperature monochromatic 40s#: Temperature as computed with
* shock waves with $T=40s$.
- * \end{itemize}
- * \item #Initial u#: Names for the initial value for the amplitude. Allowed
+ * @begin{itemize}
+ * @item #Initial u#: Names for the initial value for the amplitude. Allowed
* names are:
* \begin{itemize}
- * \item #zero#: $u_0=0$.
- * \item #eigenmode#: $u_0=sin(2\pi x)sin(2\pi y)$.
- * \item #bump#: $u_0=(1-\frac{\vec x^2}{a^2})e^{-\frac{\vec x^2}{a^2}}$
+ * @item #zero#: $u_0=0$.
+ * @item #eigenmode#: $u_0=sin(2\pi x)sin(2\pi y)$.
+ * @item #bump#: $u_0=(1-\frac{\vec x^2}{a^2})e^{-\frac{\vec x^2}{a^2}}$
* for $|\vec x|<a$ and $u_0=0$ otherwise. $a=0.1$
- * \item #center-kink#: $u_0=r/a$ for $r<a$, $u_0=2-r/a$ for $a<r<2a$,
+ * @item #center-kink#: $u_0=r/a$ for $r<a$, $u_0=2-r/a$ for $a<r<2a$,
* $u=0$ otherwise. $a=0.1$, $r=|\vec x|$.
- * \item #shifted bump#: Same as #bump# but the center of the bump is
+ * @item #shifted bump#: Same as #bump# but the center of the bump is
* located at $x=0.5, y=0$.
- * \item #tube#: $u_0=1$ for $|x|<0.2, zero otherwise.
- * \end{itemize}
- * \item #Initial v#: Names for the initial value for the amplitude. Allowed
+ * @item #tube#: $u_0=1$ for $|x|<0.2, zero otherwise.
+ * @begin{itemize}
+ * @item #Initial v#: Names for the initial value for the amplitude. Allowed
* names are the same as above.
- * \item #Boundary#: Names for the boundary functions. The boundary values
+ * @item #Boundary#: Names for the boundary functions. The boundary values
* for $u$ and $v$ are always set together. The boundary values apply only
* to those boundary parts which are of Dirichlet type. Allowed names are:
* \begin{itemize}
- * \item #zero#: Homogeneous boundary values.
- * \item #wave from left#: For $t<T=0.4$ we set $u=sin^2(\pi \frac tT)$ at
+ * @item #zero#: Homogeneous boundary values.
+ * @item #wave from left#: For $t<T=0.4$ we set $u=sin^2(\pi \frac tT)$ at
* the boundary where $x=0$.
- * \item #wave from left center#: For $t<T=0.4$ and $0.4<y<0.6$ we set
+ * @item #wave from left center#: For $t<T=0.4$ and $0.4<y<0.6$ we set
* $u=sin^2(\pi \frac tT) (y-0.4) (0.6-y)$ at
* the boundary where $x=0$.
- * \item #wave from left bottom#: For $t<T=60s$ and $r=|\vec x|<a=5000000cm=50km$
+ * @item #wave from left bottom#: For $t<T=60s$ and $r=|\vec x|<a=5000000cm=50km$
* let $u=(cos(\pi/2 r/a) sin(\pi t/T))^2$.
* This boundary condition is only suited to the temperature domains.
- * \end{itemize}
- * \end{itemize}
+ * @begin{itemize}
+ * @begin{itemize}
*
* \subsection{Subsection #Time stepping#}
* \begin{itemize}
- * \item #Primal method#: Time stepping method for the primal problem.
+ * @item #Primal method#: Time stepping method for the primal problem.
* Allowed values are:
* \begin{itemize}
- * \item #theta#: Use the $\theta$ scheme with the $\theta$-parameter
+ * @item #theta#: Use the $\theta$ scheme with the $\theta$-parameter
* as given below.
- * \item #fractional step#: Use the fractional step $\theta$ scheme.
- * \end{itemize}
- * \item #Dual method#: Time stepping method for the dual problem. Allowed
+ * @item #fractional step#: Use the fractional step $\theta$ scheme.
+ * @begin{itemize}
+ * @item #Dual method#: Time stepping method for the dual problem. Allowed
* values are the same as above. Note that the fractional step scheme
* is not implemented for right hand sides not equal to zero, i.e. the
* fractional step scheme will fail of the error functional evaluates
* to non-zero at times not equal to the end time.
- * \item #Theta#: $\theta$ parameter for the $\theta$ time stepping scheme.
+ * @item #Theta#: $\theta$ parameter for the $\theta$ time stepping scheme.
* $\theta=1/2$ denotes the Crank-Nicolson scheme.
- * \item #Time step#: Selfdocumenting.
- * \item #End time#: Selfdocumenting.
- * \end{itemize}
+ * @item #Time step#: Selfdocumenting.
+ * @item #End time#: Selfdocumenting.
+ * @begin{itemize}
*/
template <int dim>
class WaveParameters