From 0e9a00e2777a23fb0ec8ae030a3eceab1db8e515 Mon Sep 17 00:00:00 2001 From: wolf Date: Mon, 26 Jun 2000 14:33:11 +0000 Subject: [PATCH] More doc changes for the conversion to kdoc2. git-svn-id: https://svn.dealii.org/trunk@3075 0785d39b-7218-0410-832d-ea1e28bc413d --- deal.II/base/include/base/convergence_table.h | 8 +- deal.II/base/include/base/data_out_base.h | 50 ++-- deal.II/base/include/base/exceptions.h | 90 +++---- deal.II/base/include/base/function.h | 10 +- deal.II/base/include/base/function_time.h | 10 +- deal.II/base/include/base/logstream.h | 8 +- deal.II/base/include/base/parameter_handler.h | 119 ++++----- deal.II/base/include/base/smartpointer.h | 8 +- deal.II/base/include/base/table_handler.h | 4 +- deal.II/base/include/base/timer.h | 4 +- deal.II/base/source/parameter_handler.cc | 199 ++++++++++---- deal.II/contrib/kdoc/src/kdocHTMLutil.pm | 51 +++- deal.II/deal.II/include/dofs/dof_accessor.h | 8 +- .../deal.II/include/dofs/dof_constraints.h | 8 +- deal.II/deal.II/include/dofs/dof_handler.h | 12 +- deal.II/deal.II/include/dofs/dof_levels.h | 10 +- deal.II/deal.II/include/dofs/dof_tools.h | 8 +- deal.II/deal.II/include/fe/fe.h | 26 +- .../deal.II/include/fe/fe_lib.criss_cross.h | 6 +- deal.II/deal.II/include/fe/fe_lib.lagrange.h | 96 +++---- deal.II/deal.II/include/fe/fe_system.h | 12 +- deal.II/deal.II/include/fe/fe_values.h | 20 +- deal.II/deal.II/include/grid/geometry_info.h | 8 +- deal.II/deal.II/include/grid/grid_generator.h | 14 +- deal.II/deal.II/include/grid/grid_in.h | 18 +- deal.II/deal.II/include/grid/grid_out.h | 26 +- deal.II/deal.II/include/grid/intergrid_map.h | 20 +- .../deal.II/include/grid/persistent_tria.h | 4 +- deal.II/deal.II/include/grid/tria.h | 248 +++++++++--------- deal.II/deal.II/include/grid/tria_accessor.h | 8 +- deal.II/deal.II/include/grid/tria_boundary.h | 14 +- .../deal.II/include/grid/tria_boundary_lib.h | 2 +- deal.II/deal.II/include/grid/tria_iterator.h | 34 +-- deal.II/deal.II/include/grid/tria_levels.h | 2 +- deal.II/deal.II/include/multigrid/mg_base.h | 2 +- .../include/multigrid/mg_dof_accessor.h | 4 +- .../include/multigrid/mg_dof_handler.h | 8 +- deal.II/deal.II/include/numerics/assembler.h | 2 +- deal.II/deal.II/include/numerics/base.h | 18 +- deal.II/deal.II/include/numerics/data_io.h | 48 ++-- deal.II/deal.II/include/numerics/data_out.h | 4 +- .../deal.II/include/numerics/data_out_stack.h | 4 +- .../include/numerics/error_estimator.h | 10 +- deal.II/deal.II/include/numerics/histogram.h | 8 +- deal.II/deal.II/include/numerics/matrices.h | 18 +- .../include/numerics/solution_transfer.h | 24 +- .../deal.II/include/numerics/time_dependent.h | 62 ++--- deal.II/deal.II/include/numerics/vectors.h | 28 +- .../development/writing-documentation.html | 33 ++- deal.II/lac/include/lac/full_matrix.h | 2 +- deal.II/lac/include/lac/precondition.h | 8 +- .../lac/include/lac/precondition_selector.h | 8 +- deal.II/lac/include/lac/solver.h | 8 +- deal.II/lac/include/lac/solver_control.h | 10 +- deal.II/lac/include/lac/solver_selector.h | 16 +- deal.II/lac/include/lac/sparse_ilu.h | 8 +- deal.II/lac/include/lac/sparse_matrix.h | 2 +- deal.II/lac/include/lac/sparse_vanka.h | 20 +- deal.II/lac/include/lac/sparsity_pattern.h | 12 +- tests/deal.II/wave-test-3.cc | 110 ++++---- 60 files changed, 892 insertions(+), 750 deletions(-) diff --git a/deal.II/base/include/base/convergence_table.h b/deal.II/base/include/base/convergence_table.h index 6682431b27..e345b938c5 100644 --- a/deal.II/base/include/base/convergence_table.h +++ b/deal.II/base/include/base/convergence_table.h @@ -39,13 +39,13 @@ * * There are two possibilities of how to evaluate the convergence rates of multiple * columns in the same @p{RateMode}. - * \begin{enumerate} - * \item call @p{evaluate_convergence_rates(data_column_key, ...)} for all wanted columns - * \item call @p{omit_column_from_convergence_rate_evaluation(data_column_key)} for all + * @begin{enumerate} + * @item call @p{evaluate_convergence_rates(data_column_key, ...)} for all wanted columns + * @item call @p{omit_column_from_convergence_rate_evaluation(data_column_key)} for all * NOT wanted columns and then * @p{evaluate_all_convergence_rates(...)} to evaluate the convergence rates of all columns * that are not signed to be omitted. - * \end{enumerate} + * @end{enumerate} * * * @author Ralf Hartmann, 1999 diff --git a/deal.II/base/include/base/data_out_base.h b/deal.II/base/include/base/data_out_base.h index 90908defdc..01d7b382f0 100644 --- a/deal.II/base/include/base/data_out_base.h +++ b/deal.II/base/include/base/data_out_base.h @@ -128,10 +128,10 @@ class ParameterHandler; * * Given the lines as described above, a cut through this data in Gnuplot * can then be achieved like this: - * \begin{verbatim} + * @begin{verbatim} * set data style lines * splot [:][:][0:] "T" using 1:2:($3==.5 ? $4 : -1) - * \end{verbatim} + * @end{verbatim} * This command plots data in x- and y-direction unbounded, but in z-direction * only those data points which are above the x-y-plane (we assume here a * positive solution, if it has negative values, you might want to decrease the @@ -156,9 +156,9 @@ class ParameterHandler; * * The output uses two different povray-objects: - * \begin{itemize} + * @begin{itemize} * - * \item @p{BICUBIC_PATCH} + * @item @p{BICUBIC_PATCH} * A @p{bicubic_patch} is a 3-dimensional Bezier patch. It consists of 16 Points * describing the surface. The 4 corner points are touched by the object, * while the other 12 points pull and stretch the patch into shape. @@ -166,7 +166,7 @@ class ParameterHandler; * subdivisions has to be 3 to provide the patch with 16 points. * A bicubic patch is not exact but generates very smooth images. * - * \item @p{MESH} + * @item @p{MESH} * The mesh object is used to store large number of triangles. * Every square of the patch data is split into one upper-left and one * lower-right triangle. If the number of subdivisions is three, 32 triangle @@ -174,7 +174,7 @@ class ParameterHandler; * * Using the smooth flag povray interpolates the normals on the triangles, * imitating a curved surface - * \end{itemize} + * @end{itemize} * * All objects get one texture definition called Tex. This texture has to be * declared somewhere before the object data. This may be in an external @@ -186,9 +186,9 @@ class ParameterHandler; * * You need povray (>=3.0) to render the scene. The minimum options for povray * are: - * \begin{verbatim} + * @begin{verbatim} * povray +I +W +H +L - * \end{verbatim} + * @end{verbatim} * If the external file "data.inc" is used, the path to this file has to be * included in the povray options. * @@ -285,7 +285,7 @@ class DataOutBase * @p{n_subdivision} = 4 because * the number of cells is * equal to @p{2^dim}. - * \begin{verbatim} + * @begin{verbatim} * __ __ __ __ * | | | | | * |__|__|__|__| @@ -295,7 +295,7 @@ class DataOutBase * |__|__|__|__| * | | | | | * |__|__|__|__| - * \end{verbatim} + * @end{verbatim} * @author Wolfgang Bangerth */ template @@ -361,7 +361,7 @@ class DataOutBase * @p{(0, 3, 1,2)} in 2d, and * @p{(0, 4, 3, 7, 1, 5, 2, 6)} * in 3d as following: - * \begin{verbatim} + * @begin{verbatim} * * 7________6 * / /| @@ -372,7 +372,7 @@ class DataOutBase * | / | / * | / | / * 0|/______1/ - * \end{verbatim} + * @end{verbatim} * * For exemple in 2d: If * @p{subdivisions==2} the @@ -380,7 +380,7 @@ class DataOutBase * given by the following * numeration: * - * \begin{verbatim} + * @begin{verbatim} * 2 ____5 ____8 * | | | * | | | @@ -390,7 +390,7 @@ class DataOutBase * | | | * | | | * 0|____3|____6| - * \end{verbatim} + * @end{verbatim} * * Since the number of data vectors * is usually the same for all @@ -642,7 +642,7 @@ class DataOutBase * Gnuplot-default of 0 is * the following: * - * \begin{verbatim} + * @begin{verbatim} * * 3________7 * / /| @@ -654,7 +654,7 @@ class DataOutBase * | / | / * 1|/______5/ * - * \end{verbatim} + * @end{verbatim} */ double turn_angle; @@ -1080,7 +1080,7 @@ class DataOutBase * presently implemented. * * Usage is as follows: - * \begin{verbatim} + * @begin{verbatim} * // within function declaring parameters: * ... * prm.enter_subsection ("Output format options"); @@ -1096,7 +1096,7 @@ class DataOutBase * out.parse_parameters (prm); * prm.leave_subsection (); * ... - * \end{verbatim} + * @end{verbatim} * Note that in the present example, the class @p{DataOut} was used. However, any * other class derived from @p{DataOut_Interface} would work alike. * @@ -1228,13 +1228,13 @@ class DataOutInterface : private DataOutBase * suffix with a given output format * usually has. At present the following * formats are defined: - * \begin{itemize} - * \item @p{ucd}: @p{.inp} - * \item @p{gnuplot}: @p{.gnuplot} - * \item @p{povray}: @p{.pov} - * \item @p{eps}: @p{.eps} - * \item @p{gmv}: @p{.gmv}. - * \end{itemize} + * @begin{itemize} + * @item @p{ucd}: @p{.inp} + * @item @p{gnuplot}: @p{.gnuplot} + * @item @p{povray}: @p{.pov} + * @item @p{eps}: @p{.eps} + * @item @p{gmv}: @p{.gmv}. + * @end{itemize} * * If this function is called * with no argument or @p{default_format}, the diff --git a/deal.II/base/include/base/exceptions.h b/deal.II/base/include/base/exceptions.h index 86518c7064..3ebde4735f 100644 --- a/deal.II/base/include/base/exceptions.h +++ b/deal.II/base/include/base/exceptions.h @@ -32,7 +32,7 @@ * @p{DeclException} macro family. * * - * @sect2{General overview of the exception handling mechanism in @p{deal.II}} + * @sect2{General overview of the exception handling mechanism in deal.II} * * The error handling mechanism in @p{deal.II} is generally used in two ways. * The first uses error checking in debug mode only and is useful for programs @@ -62,10 +62,10 @@ * Both modes use exception classes, which need to have special features * additionally to the @p{C++} standard's @p{exception} class. Such a class * is declared by the following lines of code: - * \begin{verbatim} + * @begin{verbatim} * DeclException2 (ExcDomain, int, int, * << "Index= " << arg1 << "Upper Bound= " << arg2); - * \end{verbatim} + * @end{verbatim} * This declares an exception class named @p{ExcDomain}, which * has two variables as additional information (named * @p{arg1} and @p{arg2} by default) and which outputs the @@ -87,18 +87,18 @@ * * To use the exception mechanism for debug mode error checking, write lines * like the following in your source code: - * \begin{verbatim} + * @begin{verbatim} * Assert (n * #include "../include/parameter_handler.h" * @@ -539,11 +547,11 @@ struct Patterns { * << "Getting parameters:" << endl; * p.get_parameters (prm); * }; - * \end{verbatim} + * @end{verbatim} * * * This is the input file (named "prmtest.prm"): - * \begin{verbatim} + * @begin{verbatim} * # first declare the types of equations * set Equation 1 = Poisson * set Equation 2 = Navier-Stokes @@ -563,10 +571,10 @@ struct Patterns { * set Maximum number of iterations = 100 * end * end - * \end{verbatim} + * @end{verbatim} * * And here is the ouput of the program: - * \begin{verbatim} + * @begin{verbatim} * Line 8: * The entry value * Gauss-Seidel @@ -603,17 +611,13 @@ struct Patterns { * Problem: outfile=out * eq1=Poisson, eq2=Navier-Stokes * Matrix1=Sparse, Matrix2=Full - * \end{verbatim} + * @end{verbatim} * * * @sect3{References} * * This class is inspired by the @p{MenuSystem} class of @p{DiffPack}. * - * @memo This class provides a standard interface to an input file - * which provides at run-time for program parameters such as time step sizes, - * geometries, right hand sides etc. - * * @author Wolfgang Bangerth, October 1997, revised February 1998 * @see MultipleParameterLoop */ @@ -892,24 +896,24 @@ class ParameterHandler * variant entry values and performs a loop over all combinations of parameters. * * Variant entry values are given like this: - * \begin{verbatim} + * @begin{verbatim} * set Time step size = { 0.1 | 0.2 | 0.3 } - * \end{verbatim} + * @end{verbatim} * The loop will then perform three runs of the program, one for each value * of @p{Time step size}, while all other parameters are as specified or with their * default value. If there are several variant entry values in the input a loop is * performed for each combination of variant values: - * \begin{verbatim} + * @begin{verbatim} * set Time step size = { 0.1 | 0.2 } * set Solver = { CG | GMRES } - * \end{verbatim} + * @end{verbatim} * will result in four runs of the programs, with time step 0.1 and 0.2 for each * of the two solvers. * * Opposite to a variant entry, an array entry looks like this: - * \begin{verbatim} + * @begin{verbatim} * set Output file = ofile.{{ 1 | 2 | 3 | 4 }} - * \end{verbatim} + * @end{verbatim} * This indicates that if there are variant entries producing a total of four * different runs will write their results to the files @p{ofile.1}, @p{ofile.2}, * @p{ofile.3} and @p{ofile.4}, respectively. Array entries do not generate multiple @@ -937,7 +941,7 @@ class ParameterHandler * the different parameter sets are set, a new instance of a user class is created * which is then called. Taking the classes of the example for the * @p{ParameterHandler} class, the extended program would look like this: - * \begin{verbatim} + * @begin{verbatim} * class HelperClass : public MultipleParameterLoop::UserClass { * public: * HelperClass (); @@ -983,7 +987,7 @@ class ParameterHandler * prm.read_input ("prmtest.prm"); * prm.loop (h); * }; - * \end{verbatim} + * @end{verbatim} * * As can be seen, first a new helper class has to be set up. This must contain * a virtual constructor for a problem class. You can also derive your problem @@ -1005,7 +1009,7 @@ class ParameterHandler * @p{MultipleParameterLoop} class, the entries have to be declared in the same way * as for the @p{ParameterHandler} class. Then the input has to be read. Finally * the loop is called. This executes the following steps: - * \begin{verbatim} + * @begin{verbatim} * for each combination * { * UserObject.create_new (runNo); @@ -1014,7 +1018,7 @@ class ParameterHandler * * UserObject.run (*this); * }; - * \end{verbatim} + * @end{verbatim} * @p{UserObject} is the parameter to the @p{loop} function. @p{create_new} is given the number * of the run (starting from one) to enable naming output files differently for each * run. @@ -1037,7 +1041,7 @@ class ParameterHandler * * Given the above extensions to the example program for the @p{ParameterHandler} and the * following input file - * \begin{verbatim} + * @begin{verbatim} * set Equation 1 = Poisson * set Equation 2 = Navier-Stokes * set Output file= results.{{ 1 | 2 | 3 | 4 | 5 | 6 }} @@ -1057,9 +1061,9 @@ class ParameterHandler * set Maximum number of iterations = 100 * end * end - * \end{verbatim} + * @end{verbatim} * this is the output: - * \begin{verbatim} + * @begin{verbatim} * LinEq: Method=CG, MaxIterations=10 * LinEq: Method=BiCGStab, MaxIterations=100 * Problem: outfile=results.1 @@ -1090,7 +1094,7 @@ class ParameterHandler * Problem: outfile=results.6 * eq1=Poisson, eq2=Navier-Stokes * Matrix1=Sparse, Matrix2=Full - * \end{verbatim} + * @end{verbatim} * Since @p{create_new} gets the number of the run it would also be possible to output * the number of the run. * @@ -1098,15 +1102,12 @@ class ParameterHandler * @sect3{References} * This class is inspired by the @p{Multipleloop} class of @p{DiffPack}. * - * @memo This class provides an interface to an input file which provides at - * run-time for multiple program parameters sets. The class performs a loop over - * all combinations of parameter sets. - * * @author Wolfgang Bangerth, October 1997 * @version 1.0 * @see ParameterHandler */ -class MultipleParameterLoop : public ParameterHandler { +class MultipleParameterLoop : public ParameterHandler +{ public: /** * This is the class the helper class or the diff --git a/deal.II/base/include/base/smartpointer.h b/deal.II/base/include/base/smartpointer.h index 4f2a5d68e5..59b1da370e 100644 --- a/deal.II/base/include/base/smartpointer.h +++ b/deal.II/base/include/base/smartpointer.h @@ -30,18 +30,18 @@ * * @p{SmartPointer} does NOT implement any memory handling! Especially, * deleting a @p{SmartPointer} does not delete the object. Writing - * \begin{verbatim} + * @begin{verbatim} * SmartPointer t = new T; - * \end{verbatim} + * @end{verbatim} * is a sure way to program a memory leak! The secure version is - * \begin{verbatim} + * @begin{verbatim} * T* p = new T; * { * SmartPointer t = p; * ... * } * delete p; - * \end{verbatim} + * @end{verbatim} * * Note that a smart pointer can handle @p{const}ness of an object, i.e. * a @p{SmartPointer} really behaves as if it were a pointer to diff --git a/deal.II/base/include/base/table_handler.h b/deal.II/base/include/base/table_handler.h index 481e3c4ee8..9552beae66 100644 --- a/deal.II/base/include/base/table_handler.h +++ b/deal.II/base/include/base/table_handler.h @@ -133,7 +133,7 @@ class TableEntry : public TableEntryBase * aligned to the right (the default was @p{centered}) and the precision of * the square roots are set to be 6 (instead of 4 as default). * - * \begin{verbatim} + * @begin{verbatim} * TableHandler table(); * * for (unsigned int i=1; i<=n; ++i) @@ -154,7 +154,7 @@ class TableEntry : public TableEntryBase * ofstream out_file("number_table.tex"); * table.write_tex(out_file); * out_file.close(); - * \end{verbatim} + * @end{verbatim} * * @author Ralf Hartmann, 1999 */ diff --git a/deal.II/base/include/base/timer.h b/deal.II/base/include/base/timer.h index a160d1c576..2e9691d37f 100644 --- a/deal.II/base/include/base/timer.h +++ b/deal.II/base/include/base/timer.h @@ -26,7 +26,7 @@ * * Use of this class is as you might expect by looking at the member * functions: - * \begin{verbatim} + * @begin{verbatim} * Time timer; * timer.start (); * @@ -39,7 +39,7 @@ * * // reset timer for the next thing it shall do * timer.reset(); - * \end{verbatim} + * @end{verbatim} * * Alternatively, you can also restart the timer instead of resetting * it. The times between successive calls to @p{start/stop} will then be diff --git a/deal.II/base/source/parameter_handler.cc b/deal.II/base/source/parameter_handler.cc index a7daf6b6fc..9c307444da 100644 --- a/deal.II/base/source/parameter_handler.cc +++ b/deal.II/base/source/parameter_handler.cc @@ -21,7 +21,14 @@ #include -bool Patterns::Integer::match (const string &test_string) const { + +Patterns::PatternBase::~PatternBase () +{}; + + + +bool Patterns::Integer::match (const string &test_string) const +{ istrstream str(test_string.c_str()); int i; if (str >> i) return true; @@ -29,18 +36,24 @@ bool Patterns::Integer::match (const string &test_string) const { }; -string Patterns::Integer::description () const { + +string Patterns::Integer::description () const +{ return "[Integer]"; }; + Patterns::PatternBase * -Patterns::Integer::clone () const { +Patterns::Integer::clone () const +{ return new Patterns::Integer(); }; -bool Patterns::Double::match (const string &test_string) const { + +bool Patterns::Double::match (const string &test_string) const +{ istrstream str(test_string.c_str()); double d; if (str >> d) return true; @@ -48,7 +61,9 @@ bool Patterns::Double::match (const string &test_string) const { }; -string Patterns::Double::description () const { + +string Patterns::Double::description () const +{ return "[Integer]"; }; @@ -59,7 +74,9 @@ Patterns::Double::clone () const { }; -Patterns::Selection::Selection (const string &seq) { + +Patterns::Selection::Selection (const string &seq) +{ sequence = seq; while (sequence.find(" |") != string::npos) @@ -69,7 +86,9 @@ Patterns::Selection::Selection (const string &seq) { }; -bool Patterns::Selection::match (const string &test_string) const { + +bool Patterns::Selection::match (const string &test_string) const +{ vector choices; string tmp(sequence); // check the different possibilities @@ -89,18 +108,24 @@ bool Patterns::Selection::match (const string &test_string) const { }; -string Patterns::Selection::description () const { + +string Patterns::Selection::description () const +{ return sequence; }; + Patterns::PatternBase * -Patterns::Selection::clone () const { +Patterns::Selection::clone () const +{ return new Patterns::Selection(sequence); }; -Patterns::MultipleSelection::MultipleSelection (const string &seq) { + +Patterns::MultipleSelection::MultipleSelection (const string &seq) +{ Assert (seq.find (",") == string::npos, ExcCommasNotAllowed(seq.find(","))); sequence = seq; @@ -111,7 +136,9 @@ Patterns::MultipleSelection::MultipleSelection (const string &seq) { }; -bool Patterns::MultipleSelection::match (const string &test_string_list) const { + +bool Patterns::MultipleSelection::match (const string &test_string_list) const +{ string tmp = test_string_list; list split_list; @@ -139,7 +166,7 @@ bool Patterns::MultipleSelection::match (const string &test_string_list) const { }; -// check the different possibilities + // check the different possibilities for (list::const_iterator test_string = split_list.begin(); test_string != split_list.end(); ++test_string) { @@ -173,56 +200,75 @@ bool Patterns::MultipleSelection::match (const string &test_string_list) const { }; -string Patterns::MultipleSelection::description () const { + +string Patterns::MultipleSelection::description () const +{ return sequence; }; + Patterns::PatternBase * -Patterns::MultipleSelection::clone () const { +Patterns::MultipleSelection::clone () const +{ return new Patterns::MultipleSelection(sequence); }; + Patterns::Bool::Bool () : Selection ("true|false") {}; + Patterns::PatternBase * -Patterns::Bool::clone () const { +Patterns::Bool::clone () const +{ return new Patterns::Bool(); }; + Patterns::Anything::Anything () {}; -bool Patterns::Anything::match (const string &) const { + +bool Patterns::Anything::match (const string &) const +{ return true; }; -string Patterns::Anything::description () const { + +string Patterns::Anything::description () const +{ return "[Anything]"; }; + Patterns::PatternBase * -Patterns::Anything::clone () const { +Patterns::Anything::clone () const +{ return new Patterns::Anything(); }; + ParameterHandler::ParameterHandler () : status(true) {}; -ParameterHandler::~ParameterHandler () {}; + +ParameterHandler::~ParameterHandler () +{}; + -bool ParameterHandler::read_input (istream &input) { +bool ParameterHandler::read_input (istream &input) +{ AssertThrow (input, ExcIO()); string line; @@ -239,6 +285,7 @@ bool ParameterHandler::read_input (istream &input) { }; + bool ParameterHandler::read_input (const string &filename) { ifstream input (filename.c_str()); @@ -262,7 +309,9 @@ bool ParameterHandler::read_input (const string &filename) } -bool ParameterHandler::read_input_from_string (const char *s) { + +bool ParameterHandler::read_input_from_string (const char *s) +{ // if empty string then exit // with success if ((s == 0) || ((*s) == 0)) return true; @@ -293,7 +342,9 @@ bool ParameterHandler::read_input_from_string (const char *s) { }; -void ParameterHandler::clear () { + +void ParameterHandler::clear () +{ status = true; subsection_path.clear (); @@ -316,9 +367,11 @@ void ParameterHandler::clear () { }; + bool ParameterHandler::declare_entry (const string &entry, const string &default_value, - const Patterns::PatternBase &pattern) { + const Patterns::PatternBase &pattern) +{ Section* p = get_present_defaults_subsection (); // assertions: @@ -344,7 +397,9 @@ bool ParameterHandler::declare_entry (const string &entry, }; -void ParameterHandler::enter_subsection (const string &subsection) { + +void ParameterHandler::enter_subsection (const string &subsection) +{ Section* pd = get_present_defaults_subsection (); // does subsection already exist? @@ -364,7 +419,9 @@ void ParameterHandler::enter_subsection (const string &subsection) { }; -bool ParameterHandler::leave_subsection () { + +bool ParameterHandler::leave_subsection () +{ // assert there is a subsection that // we may leave // (use assert since this is a logical @@ -381,7 +438,9 @@ bool ParameterHandler::leave_subsection () { }; -const string & ParameterHandler::get (const string &entry_string) const { + +const string & ParameterHandler::get (const string &entry_string) const +{ const Section* pd = get_present_defaults_subsection (); const Section* pc = get_present_changed_subsection (); @@ -410,7 +469,9 @@ const string & ParameterHandler::get (const string &entry_string) const { }; -long int ParameterHandler::get_integer (const string &entry_string) const { + +long int ParameterHandler::get_integer (const string &entry_string) const +{ string s = get (entry_string); char *endptr; long int i = strtol (s.c_str(), &endptr, 10); @@ -422,7 +483,9 @@ long int ParameterHandler::get_integer (const string &entry_string) const { }; -double ParameterHandler::get_double (const string &entry_string) const { + +double ParameterHandler::get_double (const string &entry_string) const +{ string s = get (entry_string); char *endptr; double d = strtod (s.c_str(), &endptr); @@ -434,7 +497,9 @@ double ParameterHandler::get_double (const string &entry_string) const { }; -bool ParameterHandler::get_bool (const string &entry_string) const { + +bool ParameterHandler::get_bool (const string &entry_string) const +{ string s = get(entry_string); AssertThrow ((s=="true") || (s=="false"), ExcConversionError(s)); @@ -445,7 +510,9 @@ bool ParameterHandler::get_bool (const string &entry_string) const { }; -ostream & ParameterHandler::print_parameters (ostream &out, OutputStyle style) { + +ostream & ParameterHandler::print_parameters (ostream &out, OutputStyle style) +{ // assert that only known formats are // given as "style" Assert ((style == Text) || (style == LaTeX), ExcNotImplemented()); @@ -486,9 +553,11 @@ ostream & ParameterHandler::print_parameters (ostream &out, OutputStyle style) { }; + void ParameterHandler::print_parameters_section (ostream &out, const OutputStyle style, - const unsigned int indent_level) { + const unsigned int indent_level) +{ // assert that only known formats are // given as "style" Assert ((style == Text) || (style == LaTeX), ExcNotImplemented()); @@ -560,7 +629,7 @@ void ParameterHandler::print_parameters_section (ostream &out, }; -// now transverse subsections tree + // now transverse subsections tree map::const_iterator ptrss; for (ptrss = pd->subsections.begin(); ptrss != pd->subsections.end(); ++ptrss) { @@ -611,7 +680,10 @@ void ParameterHandler::print_parameters_section (ostream &out, }; -bool ParameterHandler::scan_line (string line, const unsigned int lineno) { + +bool ParameterHandler::scan_line (string line, + const unsigned int lineno) +{ // if there is a comment, delete it if (line.find('#') != string::npos) line.erase (line.find("#"), string::npos); @@ -741,7 +813,9 @@ bool ParameterHandler::scan_line (string line, const unsigned int lineno) { }; -ParameterHandler::Section* ParameterHandler::get_present_defaults_subsection () { + +ParameterHandler::Section* ParameterHandler::get_present_defaults_subsection () +{ Section* sec = &defaults; vector::const_iterator SecName = subsection_path.begin(); @@ -755,7 +829,9 @@ ParameterHandler::Section* ParameterHandler::get_present_defaults_subsection () }; -const ParameterHandler::Section* ParameterHandler::get_present_defaults_subsection () const { + +const ParameterHandler::Section* ParameterHandler::get_present_defaults_subsection () const +{ Section* sec = const_cast(&defaults); // not nice, but needs to be and // after all: we do not change @p{sec} vector::const_iterator SecName = subsection_path.begin(); @@ -770,7 +846,9 @@ const ParameterHandler::Section* ParameterHandler::get_present_defaults_subsecti }; -ParameterHandler::Section* ParameterHandler::get_present_changed_subsection () { + +ParameterHandler::Section* ParameterHandler::get_present_changed_subsection () +{ Section* sec = &changed_entries; vector::iterator SecName = subsection_path.begin(); @@ -784,7 +862,9 @@ ParameterHandler::Section* ParameterHandler::get_present_changed_subsection () { }; -const ParameterHandler::Section* ParameterHandler::get_present_changed_subsection () const { + +const ParameterHandler::Section* ParameterHandler::get_present_changed_subsection () const +{ Section* sec = const_cast(&changed_entries); // same as in get_present_default_s... vector::const_iterator SecName = subsection_path.begin(); @@ -811,14 +891,20 @@ subsections.clear (); }; + MultipleParameterLoop::MultipleParameterLoop() : - n_branches(0) {}; + n_branches(0) +{}; -MultipleParameterLoop::~MultipleParameterLoop () {}; +MultipleParameterLoop::~MultipleParameterLoop () +{}; -bool MultipleParameterLoop::read_input (istream &input) { + + +bool MultipleParameterLoop::read_input (istream &input) +{ AssertThrow (input, ExcIO()); bool x = ParameterHandler::read_input (input); @@ -828,6 +914,7 @@ bool MultipleParameterLoop::read_input (istream &input) { }; + bool MultipleParameterLoop::read_input (const string &filename) { return ParameterHandler::read_input (filename); @@ -838,14 +925,18 @@ bool MultipleParameterLoop::read_input (const string &filename) }; -bool MultipleParameterLoop::read_input_from_string (const char *s) { + +bool MultipleParameterLoop::read_input_from_string (const char *s) +{ bool x = ParameterHandler::read_input (s); init_branches (); return x; }; -void MultipleParameterLoop::loop (MultipleParameterLoop::UserClass &uc) { + +void MultipleParameterLoop::loop (MultipleParameterLoop::UserClass &uc) +{ for (int run_no=0; run_nosecond.first)); -// transverse subsections + // transverse subsections map::const_iterator s; for (s = sec.subsections.begin(); s != sec.subsections.end(); ++s) { @@ -933,7 +1028,9 @@ void MultipleParameterLoop::init_branches_section (const ParameterHandler::Secti }; -void MultipleParameterLoop::fill_entry_values (const unsigned int run_no) { + +void MultipleParameterLoop::fill_entry_values (const unsigned int run_no) +{ int possibilities = 1; vector::iterator choice; @@ -1002,13 +1099,17 @@ void MultipleParameterLoop::fill_entry_values (const unsigned int run_no) { }; + MultipleParameterLoop::Entry::Entry (const vector &ssp, const string& Name, const string& Value) : - subsection_path (ssp), entry_name(Name), entry_value(Value) {}; + subsection_path (ssp), entry_name(Name), entry_value(Value) +{}; + -void MultipleParameterLoop::Entry::split_different_values () { +void MultipleParameterLoop::Entry::split_different_values () +{ // split string into three parts: // part before the opening "{", // the selection itself, final diff --git a/deal.II/contrib/kdoc/src/kdocHTMLutil.pm b/deal.II/contrib/kdoc/src/kdocHTMLutil.pm index f9ff6323c8..20e7268c25 100644 --- a/deal.II/contrib/kdoc/src/kdocHTMLutil.pm +++ b/deal.II/contrib/kdoc/src/kdocHTMLutil.pm @@ -602,9 +602,18 @@ sub deref my $out = ""; my $text; - # escape @x commands - foreach $text ( split (/(\@\w+(?:\s+.+?(?=\s)|\{.*?\}))/, $str ) ) { - + # first escape @x directives. these are @x commands that do + # not take parameters, i.e. they do not take an argument which + # would either be the next word or the string in braces after + # the command name + $str =~ s/\@item/
  • /g; + + # escape @x commands. by using the `split' command, we get a + # list of strings that contain either the matched command or the + # string in between. if an element of this list matches a + # command, then we process it further, otherwise we simply + # copy it over to the output + foreach $text ( split (/(\@\w+(?:\s+.+?(?=\s)|\{.*?\}))/, $str ) ) { # check whether $text is an @command or the text between # @commands if ( $text =~ /\@(\w+)(?:\s+(.+?)(?:\s|$)|\{(.*?)\})/ ) { @@ -632,13 +641,47 @@ sub deref $out .= "".esc($content).""; } + # @begin{...} -- start environment + elsif ( $command =~ /^begin$/ ) { + if ( $content eq "itemize" ) { + $out .= "
      "; + } + elsif ( $content eq "enumerate" ) { + $out .= "
        "; + } + elsif ( $content eq "verbatim" ) { + $out .= "
        ";
        +			    }
        +			    else {
        +				print "Unknown command @", "$command($content)\n";
        +				$out .= esc($text);
        +			    }
        +			}
        +
        +			# @end{...} -- close environment
        +			elsif ( $command =~ /^end$/ ) {
        +			    if ( $content eq "itemize") {
        +				$out .= "
    "; + } + elsif ( $content eq "enumerate") { + $out .= ""; + } + elsif ( $content eq "verbatim") { + $out .= ""; + } + 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); } diff --git a/deal.II/deal.II/include/dofs/dof_accessor.h b/deal.II/deal.II/include/dofs/dof_accessor.h index 9cff7b3681..f0d191b362 100644 --- a/deal.II/deal.II/include/dofs/dof_accessor.h +++ b/deal.II/deal.II/include/dofs/dof_accessor.h @@ -192,7 +192,7 @@ class DoFObjectAccessor_Inheritance * such as @p{quad} in the accessors for lines and quads, etc. * * This class follows mainly the route laid out by the accessor library - * declared in the triangulation library (\Ref{TriaAccessor}). It enables + * declared in the triangulation library (@ref{TriaAccessor}). It enables * the user to access the degrees of freedom on the lines (there are similar * versions for the DoFs on quads, etc), where the dimension of the underlying * triangulation does not really matter (i.e. this accessor works with the @@ -201,7 +201,7 @@ class DoFObjectAccessor_Inheritance * * @sect3{Usage} * - * The \Ref{DoFDimensionInfo} classes inherited by the \Ref{DoFHandler} classes + * The @ref{DoFDimensionInfo} classes inherited by the @ref{DoFHandler} classes * declare typedefs to iterators using the accessors declared in this class * hierarchy tree. Usage is best to happen through these typedefs, since they * are more secure to changes in the class naming and template interface as well @@ -444,7 +444,7 @@ class DoFObjectAccessor<0, dim> : public DoFAccessor, /** * Access to the degrees of freedom located on lines. * This class follows mainly the route laid out by the accessor library - * declared in the triangulation library (\Ref{TriaAccessor}). It enables + * declared in the triangulation library (@ref{TriaAccessor}). It enables * the user to access the degrees of freedom on the lines (there are similar * versions for the DoFs on quads, etc), where the dimension of the underlying * triangulation does not really matter (i.e. this accessor works with the @@ -453,7 +453,7 @@ class DoFObjectAccessor<0, dim> : public DoFAccessor, * * @sect3{Usage} * - * The \Ref{DoFDimensionInfo} classes inherited by the \Ref{DoFHandler} classes + * The @ref{DoFDimensionInfo} classes inherited by the @ref{DoFHandler} classes * declare typedefs to iterators using the accessors declared in this class * hierarchy tree. Usage is best to happens through these typedefs, since they * are more secure to changes in the class naming and template interface as well diff --git a/deal.II/deal.II/include/dofs/dof_constraints.h b/deal.II/deal.II/include/dofs/dof_constraints.h index 3707e11c22..c599e6407e 100644 --- a/deal.II/deal.II/include/dofs/dof_constraints.h +++ b/deal.II/deal.II/include/dofs/dof_constraints.h @@ -48,8 +48,8 @@ template class BlockIndices; * sparsity pattern of the condensed matrix is made out of the large sparsity * pattern and the constraints. After that the global matrix is assembled and * finally condensed. To do these steps, you have (at least) two possibilities: - * \begin{itemize} - * \item Use two different sparsity patterns and two different matrices: you + * @begin{itemize} + * @item Use two different sparsity patterns and two different matrices: you * may eliminate the lines and rows connected with a constraint and create * a totally new sparsity pattern and a new system matrix. This has the * advantage that the resulting system of equations is free from artifacts @@ -61,7 +61,7 @@ template class BlockIndices; * @em{all} entries of the matrix have to be copied, not only those which are * subject to constraints. * - * \item Use only one sparsity pattern and one matrix: doing it this way, the + * @item Use only one sparsity pattern and one matrix: doing it this way, the * condense functions add nonzero entries to the sparsity pattern of the * large matrix (with constrained nodes in it) where the condensation process * of the matrix will create additional nonzero elements. In the condensation @@ -84,7 +84,7 @@ template class BlockIndices; * consumption for those iterative solution methods using a larger number of * auxiliary vectors (e.g. methods using explicite orthogonalization * procedures). - * \end{itemize} + * @end{itemize} * * Usually, the second way is chosen since memory consumption upon construction * of a second matrix rules out the first possibility. diff --git a/deal.II/deal.II/include/dofs/dof_handler.h b/deal.II/deal.II/include/dofs/dof_handler.h index b3273c782d..a344be7c04 100644 --- a/deal.II/deal.II/include/dofs/dof_handler.h +++ b/deal.II/deal.II/include/dofs/dof_handler.h @@ -34,7 +34,7 @@ template class Triangulation; /** * Define some types which differ between the dimensions. This class - * is analogous to the \Ref{TriaDimensionInfo} class hierarchy. + * is analogous to the @ref{TriaDimensionInfo} class hierarchy. * * @see DoFDimensionInfo<1> * @see DoFDimensionInfo<2> @@ -46,7 +46,7 @@ class DoFDimensionInfo; /** * Define some types for the DoF handling in one dimension. * - * The types have the same meaning as those declared in \Ref{TriaDimensionInfo<2>}. + * The types have the same meaning as those declared in @ref{TriaDimensionInfo<2>}. */ class DoFDimensionInfo<1> { public: @@ -75,7 +75,7 @@ class DoFDimensionInfo<1> { /** * Define some types for the DoF handling in two dimensions. * - * The types have the same meaning as those declared in \Ref{TriaDimensionInfo<2>}. + * The types have the same meaning as those declared in @ref{TriaDimensionInfo<2>}. */ class DoFDimensionInfo<2> { public: @@ -104,7 +104,7 @@ class DoFDimensionInfo<2> { /** * Define some types for the DoF handling in two dimensions. * - * The types have the same meaning as those declared in \Ref{TriaDimensionInfo<3>}. + * The types have the same meaning as those declared in @ref{TriaDimensionInfo<3>}. */ class DoFDimensionInfo<3> { public: @@ -143,7 +143,7 @@ class DoFDimensionInfo<3> { * also refer to all degrees of freedom and some kind of condensation * is needed to restrict the systems of equations to the unconstrained * degrees of freedom only. The actual layout of storage of the indices - * is described in the \Ref{DoFLevel} class documentation. + * is described in the @ref{DoFLevel} class documentation. * * Finally it offers a starting point for the assemblage of the matrices * by offering @p{begin()} and @p{end()} functions which return iterators @@ -1189,7 +1189,7 @@ class DoFHandler : public Subscriptor, /** * Space to store the DoF numbers for the * different levels. Analogous to the - * @p{levels[]} tree of the \Ref{Triangulation} + * @p{levels[]} tree of the @ref{Triangulation} * objects. */ vector*> levels; diff --git a/deal.II/deal.II/include/dofs/dof_levels.h b/deal.II/deal.II/include/dofs/dof_levels.h index 2f6439efe8..f8e52e8cf9 100644 --- a/deal.II/deal.II/include/dofs/dof_levels.h +++ b/deal.II/deal.II/include/dofs/dof_levels.h @@ -82,7 +82,7 @@ class DoFLevel<1> public: /** * Store the global indices of the degrees - * of freedom. See \Ref{DoFLevel} for + * of freedom. See @ref{DoFLevel} for * detailed information. */ vector line_dofs; @@ -91,13 +91,13 @@ class DoFLevel<1> /** * Store the indices of the degrees of freedom which are located on quads. - * See \Ref{DoFLevel<1>} for more information. + * See @ref{DoFLevel<1>} for more information. */ class DoFLevel<2> : public DoFLevel<1> { public: /** * Store the global indices of the degrees - * of freedom. See \Ref{DoFLevel} for + * of freedom. See @ref{DoFLevel} for * detailed information. */ vector quad_dofs; @@ -106,13 +106,13 @@ class DoFLevel<2> : public DoFLevel<1> { /** * Store the indices of the degrees of freedom which are located on hexhedra. - * See \Ref{DoFLevel<1>} for more information. + * See @ref{DoFLevel<1>} for more information. */ class DoFLevel<3> : public DoFLevel<2> { public: /** * Store the global indices of the degrees - * of freedom. See \Ref{DoFLevel} for + * of freedom. See @ref{DoFLevel} for * detailed information. */ vector hex_dofs; diff --git a/deal.II/deal.II/include/dofs/dof_tools.h b/deal.II/deal.II/include/dofs/dof_tools.h index 362bdc1dbd..0ed2a26456 100644 --- a/deal.II/deal.II/include/dofs/dof_tools.h +++ b/deal.II/deal.II/include/dofs/dof_tools.h @@ -131,10 +131,10 @@ class DoFTools * equations, * * - * \begin{verbatim} + * @begin{verbatim} * -\Delta \vec u + \nabla p = 0, * \div u = 0 - * \end{verbatim} + * @end{verbatim} * * in two space dimensions, * using stable Q2/Q1 mixed @@ -146,11 +146,11 @@ class DoFTools * following pattern of * couplings: * - * \begin{verbatim} + * @begin{verbatim} * 1 0 1 * 0 1 1 * 1 1 0 - * \end{verbatim} + * @end{verbatim} * where "1" indicates that two * variables (i.e. components of * the @p{FESystem}) couple in the diff --git a/deal.II/deal.II/include/fe/fe.h b/deal.II/deal.II/include/fe/fe.h index 79a80f7792..846302a518 100644 --- a/deal.II/deal.II/include/fe/fe.h +++ b/deal.II/deal.II/include/fe/fe.h @@ -811,7 +811,7 @@ class FiniteElementBase : public Subscriptor, * The order of the twelve lines and the four child faces can be extracted * from the following sketch, where the overall order of the different * dof groups is depicted: - * \begin{verbatim} + * @begin{verbatim} * *--13--3--14--* * | | | * 16 20 7 19 12 @@ -821,13 +821,13 @@ class FiniteElementBase : public Subscriptor, * 15 17 5 18 11 * | | | * *--9---1--10--* - * \end{verbatim} + * @end{verbatim} * It should be noted that the face as shown here is in the standard form, * i.e. with vertex zero at the bottom left, and the other vertices numbered * counter clockwise. This explains the numbering of the lines labeled 13 and * 14, as well as those labeled 15 and 16. The dofs on the lines need to * be numbered in the direction of the lines, which is as follows: - * \begin{verbatim} + * @begin{verbatim} * *-->---*-->---* * | | | * ^ ^ ^ @@ -837,7 +837,7 @@ class FiniteElementBase : public Subscriptor, * ^ ^ ^ * | | | * *-->---*-->---* - * \end{verbatim} + * @end{verbatim} * The orientation of the quads should be obvious. * * The faces of a hexahedron are arranged in a way such that @@ -871,7 +871,7 @@ class FiniteElementBase : public Subscriptor, * face of two cells need not match exactly, if one of the cells is * refined and the two cells are at the boundary. To understand this, * look at the following sketch: - * \begin{verbatim} + * @begin{verbatim} * *---------*---------* * / / /| * / / / | @@ -883,7 +883,7 @@ class FiniteElementBase : public Subscriptor, * | | | / * | | |/ * *---------*---------* - * \end{verbatim} + * @end{verbatim} * * Assume the two top faces represent the boundary of the * triangulation; assume further that the boundary of the original @@ -893,7 +893,7 @@ class FiniteElementBase : public Subscriptor, * children of this line will not take the same place as their mother * line did (this is not properly drawable using only ASCII characters, * use some imagination): - * \begin{verbatim} + * @begin{verbatim} * ..*--.*---..*---------* * *----*----* / /| * : : :/ / | @@ -905,7 +905,7 @@ class FiniteElementBase : public Subscriptor, * | | | | / * | | | |/ * *----*----*---------* - * \end{verbatim} + * @end{verbatim} * While this is the case with boundary faces in two spatial * dimensions also, it here leads to the fact that the four child * faces of the common face of the two cells will not coincide with @@ -973,8 +973,8 @@ class FiniteElementBase : public Subscriptor, * There is no guarantee that this list is complete; in fact, doubts are in * place that that be so. * - * \begin{itemize} - * \item Lagrange elements: at several places in the library, use is made of the + * @begin{itemize} + * @item Lagrange elements: at several places in the library, use is made of the * assumption that the basis functions of a finite element corresponds to a * function value (as opposed to derivatives or the like, as used in the * Hermitean finite element class or in the quintic Argyris element). It is @@ -998,7 +998,7 @@ class FiniteElementBase : public Subscriptor, * the degrees of freedom denote function values and not derivatives or * the like. * - * \item Vanishing of basis functions on faces: when projecting a function + * @item Vanishing of basis functions on faces: when projecting a function * to the boundary, use if made of the assumption that all basis functions * on a cell adjacent to the boundary vanish on the boundary except for those * on the boundary face itself. For Lagrange elements this is true, but it @@ -1020,7 +1020,7 @@ class FiniteElementBase : public Subscriptor, * the assumption does not hold, then the distribution has to happen * with all nodes on the small and the large cells. This is not * implemented in the @p{DoFHandler} class as of now. - * \end{itemize} + * @end{itemize} * * @author Wolfgang Bangerth, 1998 */ @@ -1122,7 +1122,7 @@ class FiniteElement : public FiniteElementBase * of the fields to actually compute. * * Refer to the documentation of the - * \Ref{FEValues} class for a definition + * @ref{FEValues} class for a definition * of the Jacobi matrix and of the various * structures to be filled. * diff --git a/deal.II/deal.II/include/fe/fe_lib.criss_cross.h b/deal.II/deal.II/include/fe/fe_lib.criss_cross.h index bb50d27771..d927390925 100644 --- a/deal.II/deal.II/include/fe/fe_lib.criss_cross.h +++ b/deal.II/deal.II/include/fe/fe_lib.criss_cross.h @@ -115,7 +115,7 @@ * however be noted that the support of basis functions get quite * complicated in the presence of hanging nodes, as the following figure * depicts: - * \begin{verbatim} + * @begin{verbatim} * *-----------------*--------*---- * | /|\ | * | /..|.\ | @@ -129,7 +129,7 @@ * | /...............|.....\ | * |/................|.......\| * *-----------------o--------*----- - * \end{verbatim} + * @end{verbatim} * The dotted area is the support of the basis function associated with the * bottom middle vertex (denoted by @p{o}) after the hanging node in the center * of the `picture' was eliminated. This strange structure of the support @@ -164,7 +164,7 @@ * When using one of the usual quadrature formulae, a common problem is * that some of the quadrature points lie on the interfaces of the * triangles. For this reason, there is a family of quadrature formulae - * defined below, names \ref{QCrissCross1} and higher order, which + * defined below, names @ref{QCrissCross1} and higher order, which * resemble the quadrature formulae used on triangular domains, but * taken four-fold, i.e. for each of the four subtriangles. * diff --git a/deal.II/deal.II/include/fe/fe_lib.lagrange.h b/deal.II/deal.II/include/fe/fe_lib.lagrange.h index e07607c309..2122262833 100644 --- a/deal.II/deal.II/include/fe/fe_lib.lagrange.h +++ b/deal.II/deal.II/include/fe/fe_lib.lagrange.h @@ -137,23 +137,23 @@ class FEQ1 : public FEQ1Mapping * to the real cell is implemented. * * The numbering of the degrees of freedom is as follows: - * \begin{itemize} - * \item 1D case: - * \begin{verbatim} + * @begin{itemize} + * @item 1D case: + * @begin{verbatim} * 0---2---1 - * \end{verbatim} + * @end{verbatim} * - * \item 2D case: - * \begin{verbatim} + * @item 2D case: + * @begin{verbatim} * 3---6---2 * | | * 7 8 5 * | | * 0---4---1 - * \end{verbatim} + * @end{verbatim} * - * \item 3D case: - * \begin{verbatim} + * @item 3D case: + * @begin{verbatim} * 7--14---6 7--14---6 * /| | / /| * 19 | 13 19 1813 @@ -175,41 +175,41 @@ class FEQ1 : public FEQ1Mapping * | / 22 / | | / * |/ / | |/ * *-------* *-------* - * \end{verbatim} + * @end{verbatim} * The center vertex has number 26. * * The respective coordinate values of the support points of the degrees * of freedom are as follows: - * \begin{itemize} - * \item Index 0: @p{[0, 0, 0]}; - * \item Index 1: @p{[1, 0, 0]}; - * \item Index 2: @p{[1, 0, 1]}; - * \item Index 3: @p{[0, 0, 1]}; - * \item Index 4: @p{[0, 1, 0]}; - * \item Index 5: @p{[1, 1, 0]}; - * \item Index 6: @p{[1, 1, 1]}; - * \item Index 7: @p{[0, 1, 1]}; - * \item Index 8: @p{[1/2, 0, 0]}; - * \item Index 9: @p{[1, 0, 1/2]}; - * \item Index 10: @p{[1/2, 0, 1]}; - * \item Index 11: @p{[0, 0, 1/2]}; - * \item Index 12: @p{[1/2, 1, 0]}; - * \item Index 13: @p{[1, 1, 1/2]}; - * \item Index 14: @p{[1/2, 1, 1]}; - * \item Index 15: @p{[0, 1, 1/2]}; - * \item Index 16: @p{[0, 1/2, 0]}; - * \item Index 17: @p{[1, 1/2, 0]}; - * \item Index 18: @p{[1, 1/2, 1]}; - * \item Index 19: @p{[0, 1/2, 1]}; - * \item Index 20: @p{[1/2, 0, 1/2]}; - * \item Index 21: @p{[1/2, 1, 1/2]}; - * \item Index 22: @p{[1/2, 1/2, 0]}; - * \item Index 23: @p{[1, 1/2, 1/2]}; - * \item Index 24: @p{[1/2, 1/2, 1]}; - * \item Index 25: @p{[0, 1/2, 1/2]}; - * \item Index 26: @p{[1/2, 1/2, 1/2]}; - * \end{itemize} - * \end{itemize} + * @begin{itemize} + * @item Index 0: @p{[0, 0, 0]}; + * @item Index 1: @p{[1, 0, 0]}; + * @item Index 2: @p{[1, 0, 1]}; + * @item Index 3: @p{[0, 0, 1]}; + * @item Index 4: @p{[0, 1, 0]}; + * @item Index 5: @p{[1, 1, 0]}; + * @item Index 6: @p{[1, 1, 1]}; + * @item Index 7: @p{[0, 1, 1]}; + * @item Index 8: @p{[1/2, 0, 0]}; + * @item Index 9: @p{[1, 0, 1/2]}; + * @item Index 10: @p{[1/2, 0, 1]}; + * @item Index 11: @p{[0, 0, 1/2]}; + * @item Index 12: @p{[1/2, 1, 0]}; + * @item Index 13: @p{[1, 1, 1/2]}; + * @item Index 14: @p{[1/2, 1, 1]}; + * @item Index 15: @p{[0, 1, 1/2]}; + * @item Index 16: @p{[0, 1/2, 0]}; + * @item Index 17: @p{[1, 1/2, 0]}; + * @item Index 18: @p{[1, 1/2, 1]}; + * @item Index 19: @p{[0, 1/2, 1]}; + * @item Index 20: @p{[1/2, 0, 1/2]}; + * @item Index 21: @p{[1/2, 1, 1/2]}; + * @item Index 22: @p{[1/2, 1/2, 0]}; + * @item Index 23: @p{[1, 1/2, 1/2]}; + * @item Index 24: @p{[1/2, 1/2, 1]}; + * @item Index 25: @p{[0, 1/2, 1/2]}; + * @item Index 26: @p{[1/2, 1/2, 1/2]}; + * @end{itemize} + * @end{itemize} * * @author Wolfgang Bangerth, 1998, 1999 */ @@ -314,12 +314,12 @@ class FEQ2 : public FEQ1Mapping * to the real cell is implemented. * * The numbering of degrees of freedom in one spatial dimension is as follows: - * \begin{verbatim} + * @begin{verbatim} * 0--2--3--1 - * \end{verbatim} + * @end{verbatim} * * The numbering of degrees of freedom in two spatial dimension is as follows: - * \begin{verbatim} + * @begin{verbatim} * 3--8--9--2 * | | * 11 15 14 7 @@ -327,7 +327,7 @@ class FEQ2 : public FEQ1Mapping * 10 12 13 6 * | | * 0--4--5--1 - * \end{verbatim} + * @end{verbatim} * Note the reverse ordering of degrees of freedom on the left and upper * line and the counterclockwise numbering of the interior degrees of * freedom. @@ -435,12 +435,12 @@ class FEQ3 : public FEQ1Mapping * to the real cell is implemented. * * The numbering of degrees of freedom in one spatial dimension is as follows: - * \begin{verbatim} + * @begin{verbatim} * 0--2--3--4--1 - * \end{verbatim} + * @end{verbatim} * * The numbering of degrees of freedom in two spatial dimension is as follows: - * \begin{verbatim} + * @begin{verbatim} * 3--10-11-12-2 * | | * 15 19 22 18 9 @@ -450,7 +450,7 @@ class FEQ3 : public FEQ1Mapping * 13 16 20 17 7 * | | * 0--4--5--6--1 - * \end{verbatim} + * @end{verbatim} * Note the reverse ordering of degrees of freedom on the left and upper * line and the numbering of the interior degrees of * freedom. diff --git a/deal.II/deal.II/include/fe/fe_system.h b/deal.II/deal.II/include/fe/fe_system.h index c07bdd5093..4b9d753ed4 100644 --- a/deal.II/deal.II/include/fe/fe_system.h +++ b/deal.II/deal.II/include/fe/fe_system.h @@ -45,14 +45,14 @@ * For example, for the bicubic element in one space dimension, and for * two subobjects grouped together by this class, the ordering for * the system @p{s=(u,v)} is: - * \begin{itemize} - * \item First vertex: @p{u0, v0 = s0, s1} - * \item Second vertex: @p{u1, v1 = s2, s3} - * \item First degree of freedom on the line (=cell): + * @begin{itemize} + * @item First vertex: @p{u0, v0 = s0, s1} + * @item Second vertex: @p{u1, v1 = s2, s3} + * @item First degree of freedom on the line (=cell): * @p{u2, v2 = s3, s4} - * \item Second degree of freedom on the line: + * @item Second degree of freedom on the line: * @p{u3, v3 = s5, s6}. - * \end{itemize} + * @end{itemize} * * In the most cases, the composed element behaves as if it were a usual element * with more degrees of freedom. However the underlying structure is visible in diff --git a/deal.II/deal.II/include/fe/fe_values.h b/deal.II/deal.II/include/fe/fe_values.h index d3bc21b1df..1505ca2441 100644 --- a/deal.II/deal.II/include/fe/fe_values.h +++ b/deal.II/deal.II/include/fe/fe_values.h @@ -143,17 +143,17 @@ template class Quadrature; * @sect3{Member functions} * * The functions of this class fall into different cathegories: - * \begin{itemize} - * \item @p{shape_value}, @p{shape_grad}, etc: return one of the values + * @begin{itemize} + * @item @p{shape_value}, @p{shape_grad}, etc: return one of the values * of this object at a time. In many cases you will want to get * a whole bunch at a time for performance or convenience reasons, * then use the @p{get_*} functions. * - * \item @p{get_shape_values}, @p{get_shape_grads}, etc: these return + * @item @p{get_shape_values}, @p{get_shape_grads}, etc: these return * a reference to a whole field. Usually these fields contain * the values of all trial functions at all quadrature points. * - * \item @p{get_function_values}, @p{get_function_grads}, @p{...}: these + * @item @p{get_function_values}, @p{get_function_grads}, @p{...}: these * functions offer a simple way to avoid the detour of the * trial functions, if you have a finite element solution (resp. the * vector of values associated with the different trial functions.) @@ -178,11 +178,11 @@ template class Quadrature; * other involved instance between the @p{reinit} and the @p{get_function_*} * functions are called. * - * \item @p{reinit}: initialize the @p{FEValues} object for a certain cell. + * @item @p{reinit}: initialize the @p{FEValues} object for a certain cell. * This function is not in the present class but only in the derived * classes and has a variable call syntax. * See the docs for the derived classes for more information. - * \end{itemize} + * @end{itemize} * * * @sect3{Implementational issues} @@ -1133,8 +1133,8 @@ class FEFaceValues : public FEFaceValuesBase * cells is more refined than the other. * * To this end, there seem to be two ways which may be applicable: - * \begin{itemize} - * \item Prolong the coarser cell to the finer refinement level: we could + * @begin{itemize} + * @item Prolong the coarser cell to the finer refinement level: we could * compute the prolongation of the finite element functions to the * child cells and consider the subface a face of one of the child cells. * This approach seems clear and rather simple to implement, however it @@ -1151,7 +1151,7 @@ class FEFaceValues : public FEFaceValuesBase * programming style. Apart from that, we already have iterators, why * shouldn't we use them? * - * \item Use 'different' quadrature formulae: this second approach is the + * @item Use 'different' quadrature formulae: this second approach is the * way we chose here. The idea is to evaluate the finite element trial * functions on the two cells restricted to the face in question separately, * by restricting the trial functions on the less refined cell to its @@ -1181,7 +1181,7 @@ class FEFaceValues : public FEFaceValuesBase * quadrature formula projected to the common face, but using the original * quadrature formula. This way, the locations of the quadrature points * on both sides of the common face match each other. - * \end{itemize} + * @end{itemize} * * For a use of this mechanism, take a look of the code in the error * estimation hierarchy, since there often the jump of a finite element diff --git a/deal.II/deal.II/include/grid/geometry_info.h b/deal.II/deal.II/include/grid/geometry_info.h index 7e52eaa1bb..b9ed710ac5 100644 --- a/deal.II/deal.II/include/grid/geometry_info.h +++ b/deal.II/deal.II/include/grid/geometry_info.h @@ -151,7 +151,7 @@ struct GeometryInfo * * For example, in 2D the layout of * a cell is as follows: - * \begin{verbatim} + * @begin{verbatim} * . 2 * . 3-->--2 * . | | @@ -159,20 +159,20 @@ struct GeometryInfo * . | | * . 0-->--1 * . 0 - * \end{verbatim} + * @end{verbatim} * Vertices and faces are indicated * with their numbers, faces also with * their directions. * * Now, when refined, the layout is * like this: - * \begin{verbatim} + * @begin{verbatim} * *--*--* * | 3|2 | * *--*--* * | 0|1 | * *--*--* - * \end{verbatim} + * @end{verbatim} * * Thus, the child cells on face zero * are (ordered in the direction of the diff --git a/deal.II/deal.II/include/grid/grid_generator.h b/deal.II/deal.II/include/grid/grid_generator.h index d33e0e70f9..25d2f04827 100644 --- a/deal.II/deal.II/include/grid/grid_generator.h +++ b/deal.II/deal.II/include/grid/grid_generator.h @@ -24,8 +24,8 @@ template class Triangulation; * This class offers triangulations of some standard domains such as hypercubes, * hyperball and the like. Following is a list of domains that can be generated * by the functions of this class: - * \begin{itemize} - * \item Hypercube triangulations: a hypercube triangulation is a + * @begin{itemize} + * @item Hypercube triangulations: a hypercube triangulation is a * domain which is the tensor product of an interval $[a,b]$ in * the given number of spatial dimensions. If you want to create such * a domain, which is a common test case for model problems, call @@ -33,7 +33,7 @@ template class Triangulation; * hypercube domain triangulated with exactly one element. You can * get tensor product meshes by successive refinement of this cell. * - * \item Generalized L-shape domain: + * @item Generalized L-shape domain: * using the @p{GridGenerator::hyper_L (tria, a,b)} function produces * the hypercube with the interval $[a,b]$ without the hypercube * made out of the interval $[(a+b)/2,b]$. Let, for example, be $a=-1$ @@ -41,7 +41,7 @@ template class Triangulation; * $[-1,1]^2 - [0,1]^2$. To create a hyper-L in one dimension results in * an error. The function is also implemented for three space dimensions. * - * \item Hyper balls: + * @item Hyper balls: * You get the circle or ball (or generalized: hyperball) around origin * @p{p} and with radius @p{r} by calling * @p{GridGenerator::hyper_ball (tria, p, r)}. The circle is triangulated @@ -54,7 +54,7 @@ template class Triangulation; * to the triangulation object you passed to this function if you later want * the triangulation to be refined at the outer boundaries. * - * \item Hyper shell: A hyper shell is the region between two hyper + * @item Hyper shell: A hyper shell is the region between two hyper * sphere with the same origin. Therefore, it is a ring in two * spatial dimensions. To triangulation it, call the function * @pGridGenerator::hyper_shell (tria, origin, inner_radius, outer_radius, N)}, @@ -75,14 +75,14 @@ template class Triangulation; * suitable boundary class is provided as @p{HyperSphereBoundary} * in the library. * - * \item Slit domain: The slit domain is a variant of the hyper cube + * @item Slit domain: The slit domain is a variant of the hyper cube * domain. In two spatial dimensions, it is a square into which a slit * is sawed; if the initial square is though to be composed of four * smaller squares, then two of them are not connected even though * they are neighboring each other. Analogously, into the cube in * three spatial dimensions, a half-plane is sawed, disconnecting four * of the eight child-cubes from one of their neighbors. - * \end{itemize} + * @end{itemize} * * @author Wolfgang Bangerth, 1998, 1999. Slit domain by Stefan Nauber, 1999 */ diff --git a/deal.II/deal.II/include/grid/grid_in.h b/deal.II/deal.II/include/grid/grid_in.h index 4069d214b3..5aca63e999 100644 --- a/deal.II/deal.II/include/grid/grid_in.h +++ b/deal.II/deal.II/include/grid/grid_in.h @@ -43,7 +43,7 @@ template class Triangulation; * * Material indicators are accepted to denote the material id of cells and * to denote boundary part indication for lines in 2D. Read the according - * sections in the documentation of the \Ref{Triangulation} class for + * sections in the documentation of the @ref{Triangulation} class for * further details. * * @@ -58,20 +58,20 @@ template class Triangulation; * In two dimensions, another difficulty occurs, which has to do with the sense * of a quadrilateral. A quad consists of four lines which have a direction, * which is per definitionem as follows: - * \begin{verbatim} + * @begin{verbatim} * 3-->--2 * | | * ^ ^ * | | * 0-->--1 - * \end{verbatim} + * @end{verbatim} * Now, two adjacent cells must have a vertex numbering such that the direction * of the common side is the same. For example, the following two quads - * \begin{verbatim} + * @begin{verbatim} * 3---4---5 * | | | * 0---1---2 - * \end{verbatim} + * @end{verbatim} * may be characterised by the vertex numbers (0 1 4 3) and (1 2 5 4), since * the middle line would get the direction @p{1->4} when viewed from both cells. * The numbering (0 1 4 3) and (5 4 1 2) would not be allowed, since the left @@ -86,7 +86,7 @@ template class Triangulation; * There are more ambiguous cases, where the triangulation may not know what * to do at all without the use of very sophisticated algorithms. On such example * is the following: - * \begin{verbatim} + * @begin{verbatim} * 9---10-----11 * | | / | * 6---7---8 | @@ -94,10 +94,10 @@ template class Triangulation; * 3---4---5 | * | | \ | * 0---1------2 - * \end{verbatim} + * @end{verbatim} * Assume that you had numbered the vertices in the cells at the left boundary * in a way, that the following line directions are induced: - * \begin{verbatim} + * @begin{verbatim} * 9->-10-----11 * ^ ^ / | * 6->-7---8 | @@ -105,7 +105,7 @@ template class Triangulation; * 3->-4---5 | * ^ ^ \ | * 0->-1------2 - * \end{verbatim} + * @end{verbatim} * (This could for example be done by using the indices (0 1 4 3), (3 4 7 6), * (6 7 10 9) for the three cells). Now, you will not find a way of giving * indices for the right cells, without introducing either ambiguity for diff --git a/deal.II/deal.II/include/grid/grid_out.h b/deal.II/deal.II/include/grid/grid_out.h index 1c561f8007..516d5790bb 100644 --- a/deal.II/deal.II/include/grid/grid_out.h +++ b/deal.II/deal.II/include/grid/grid_out.h @@ -35,18 +35,18 @@ template class Triangulation; * * @sect3{Usage} * Usage is simple: either you use the direct form - * \begin{verbatim} + * @begin{verbatim} * ofstream output_file("some_filename"); * GridOut().write_gnuplot (tria, output_file); - * \end{verbatim} + * @end{verbatim} * if you know which format you want to have, or if you want the format to be * a runtime parameter, you can write - * \begin{verbatim} + * @begin{verbatim} * GridOut::OutputFormat grid_format = * GridOut::parse_output_format(get_format_name_from_somewhere()); * ofstream output_file("some_filename" + GridOut::default_suffix(output_format)); * GridOut().write (tria, output_file, output_format); - * \end{verbatim} + * @end{verbatim} * The function @p{get_output_format_names()} provides a list of possible names of * output formats in a string that is understandable by the @p{ParameterHandler} class. * @@ -70,14 +70,14 @@ template class Triangulation; * set of parameters for each supported output format. These are collected * in structures @p{EpsFlags}, @p{GnuplotFlags}, etc and you can set your preferred * flags like this: - * \begin{verbatim} + * @begin{verbatim} * GridOut grid_out; * GridOut::UcdFlags ucd_flags; * ... // set some fields in ucd_flags * grid_out.set_flags (ucd_flags); * ... * ... // write some file with data_out - * \end{verbatim} + * @end{verbatim} * The respective output function then use the so-set flags. By default, they * are set to reasonable values as described above and in the documentation * of the different flags structures. Resetting the flags can @@ -336,9 +336,9 @@ class GridOut * this feature is the following: * if you use the GNUPLOT * command (for a 2d grid here) - * \begin{verbatim} + * @begin{verbatim} * splot [:][:][2.5:3.5] "grid_file.gnuplot" * - * \end{verbatim} + * @end{verbatim} * then the * whole x- and y-range will be * plotted, i.e. the whole grid, @@ -503,11 +503,11 @@ class GridOut * suffix with a given output format * usually has. At present the following * formats are defined: - * \begin{itemize} - * \item @p{gnuplot}: @p{.gnuplot} - * \item @p{ucd}: @p{.inp} - * \item @p{eps}: @p{.eps}. - * \end{itemize} + * @begin{itemize} + * @item @p{gnuplot}: @p{.gnuplot} + * @item @p{ucd}: @p{.inp} + * @item @p{eps}: @p{.eps}. + * @end{itemize} * * Since this function does not need data * from this object, it is static and can diff --git a/deal.II/deal.II/include/grid/intergrid_map.h b/deal.II/deal.II/include/grid/intergrid_map.h index a5b329f607..ecad3db476 100644 --- a/deal.II/deal.II/include/grid/intergrid_map.h +++ b/deal.II/deal.II/include/grid/intergrid_map.h @@ -23,18 +23,18 @@ template class SmartPointer; * * Usually, the two grids will be refined differently. Then, the value * returned for an iterator on the source grid will be either: - * \begin{itemize} - * \item The same cell on the destination grid, if it exists there; - * \item The most refined cell of the destination grid from which the + * @begin{itemize} + * @item The same cell on the destination grid, if it exists there; + * @item The most refined cell of the destination grid from which the * pendant of the source cell could be obtained by refinement. This * cell is always active and has a refinement level less than that * of the source cell. - * \end{itemize} + * @end{itemize} * Keys for this map are all cells on the source grid, whether active or * not. * * For example, consider these two one-dimensional grids: - * \begin{verbatim} + * @begin{verbatim} * Grid 1: * x--x--x-----x-----------x * 1 2 3 4 @@ -42,18 +42,18 @@ template class SmartPointer; * Grid 2: * x-----x-----x-----x-----x * 1 2 3 4 - * \end{verbatim} + * @end{verbatim} * (Cell numbers are only given as an example and will not correspond * to real cell iterator's indices.) The mapping from grid 1 to grid 2 * will then be as follows: - * \begin{verbatim} + * @begin{verbatim} * Cell on grid 1 Cell on grid 2 * 1 ------------------> 1 * 2 ------------------> 1 * 3 ------------------> 2 * 4 ------------------> mother cell of cells 3 and 4 * (a non-active cell, not shown here) - * \end{verbatim} + * @end{verbatim} * Besides the mappings shown here, the non-active cells on grid 1 are also * valid keys. For example, the mapping for the mother cell of cells 1 and 2 * on the first grid will point to cell 1 on the second grid. @@ -73,7 +73,7 @@ template class SmartPointer; * @sect2{Usage} * * In practice, use of this class is as follows: - * \begin{verbatim} + * @begin{verbatim} * // have two grids, which are derived from the * // same coarse grid * Triangulation tria1, tria2; @@ -95,7 +95,7 @@ template class SmartPointer; * // corresponding to @p{cell} (which is one of * // dof_handler_1 * f( grid_1_to_2_map[cell]); - * \end{verbatim} + * @end{verbatim} * * Note that the template parameters to this class have to be given as * @p{InterGridMap}, i.e. the dimension is given explicitely and diff --git a/deal.II/deal.II/include/grid/persistent_tria.h b/deal.II/deal.II/include/grid/persistent_tria.h index cb0602e05d..16bc88e00e 100644 --- a/deal.II/deal.II/include/grid/persistent_tria.h +++ b/deal.II/deal.II/include/grid/persistent_tria.h @@ -55,7 +55,7 @@ * object of this class. * * Basically, usage looks like this: - * \begin{verbatim} + * @begin{verbatim} * Triangulation coarse_grid; * ... // initialize coarse grid * @@ -84,7 +84,7 @@ * // is not needed anymore, e.g. * // working with another grid * }; - * \end{verbatim} + * @end{verbatim} * * Note that initially, the @p{PersistentTriangulation} object does not * constitute a triangulation; it only becomes one after @p{restore} is first diff --git a/deal.II/deal.II/include/grid/tria.h b/deal.II/deal.II/include/grid/tria.h index fe23a3ae53..fab455c663 100644 --- a/deal.II/deal.II/include/grid/tria.h +++ b/deal.II/deal.II/include/grid/tria.h @@ -126,11 +126,11 @@ class TriaDimensionInfo; * @p{raw_line_iterator} objects operate on all lines, used or not. * * Since we are in one dimension, the following identities are declared: - * \begin{verbatim} + * @begin{verbatim} * typedef raw_line_iterator raw_cell_iterator; * typedef line_iterator cell_iterator; * typedef active_line_iterator active_cell_iterator; - * \end{verbatim} + * @end{verbatim} * * To enable the declaration of @p{begin_quad} and the like in * @p{Triangulation<1>}, the @p{quad_iterator}s are declared as @@ -189,7 +189,7 @@ class TriaDimensionInfo<1> { * certainly make any involuntary use visible. * * Since we are in two dimension, the following identities are declared: - * \begin{verbatim} + * @begin{verbatim} * typedef raw_quad_iterator raw_cell_iterator; * typedef quad_iterator cell_iterator; * typedef active_quad_iterator active_cell_iterator; @@ -197,7 +197,7 @@ class TriaDimensionInfo<1> { * typedef raw_line_iterator raw_face_iterator; * typedef line_iterator face_iterator; * typedef active_line_iterator active_face_iterator; - * \end{verbatim} + * @end{verbatim} */ template <> class TriaDimensionInfo<2> { @@ -231,7 +231,7 @@ class TriaDimensionInfo<2> { * For the declarations of the data types, more or less the same holds * as for lower dimensions (see @p{TriaDimensionInfo<[12]>}). The * dimension specific data types are here, since we are in three dimensions: - * \begin{verbatim} + * @begin{verbatim} * typedef raw_hex_iterator raw_cell_iterator; * typedef hex_iterator cell_iterator; * typedef active_hex_iterator active_cell_iterator; @@ -239,7 +239,7 @@ class TriaDimensionInfo<2> { * typedef raw_quad_iterator raw_face_iterator; * typedef quad_iterator face_iterator; * typedef active_quad_iterator active_face_iterator; - * \end{verbatim} + * @end{verbatim} */ template <> class TriaDimensionInfo<3> { @@ -466,7 +466,7 @@ struct TriaNumberCache<3> : public TriaNumberCache<2> * data is spread over quite a lot of arrays and other places. However, * there are ways powerful enough to work on these data structures * without knowing their exact relations. This is done through the - * concept of iterators (see the STL documentation and \Ref{TriaRawIterator}). + * concept of iterators (see the STL documentation and @ref{TriaRawIterator}). * In order to make things as easy and dimension independent as possible, * use of class local typedefs is made, see below. * @@ -497,13 +497,13 @@ struct TriaNumberCache<3> : public TriaNumberCache<2> * @p{dim}>=2). * * Additionaly, for @p{dim}==1, the following identities hold: - * \begin{verbatim} + * @begin{verbatim} * typedef raw_line_iterator raw_cell_iterator; * typedef line_iterator cell_iterator; * typedef active_line_iterator active_cell_iterator; - * \end{verbatim} + * @end{verbatim} * while for @p{dim}==2 - * \begin{verbatim} + * @begin{verbatim} * typedef quad_line_iterator raw_cell_iterator; * typedef quad_iterator cell_iterator; * typedef active_quad_iterator active_cell_iterator; @@ -511,7 +511,7 @@ struct TriaNumberCache<3> : public TriaNumberCache<2> * typedef raw_line_iterator raw_face_iterator; * typedef line_iterator face_iterator; * typedef active_line_iterator active_face_iterator; - * \end{verbatim} + * @end{verbatim} * * By using the cell iterators, you can write code nearly independent of * the spatial dimension. The same applies for substructure iterators, @@ -525,9 +525,9 @@ struct TriaNumberCache<3> : public TriaNumberCache<2> * * Usage of these iterators works mostly like with the STL iterators. Some * examples taken from the @p{Triangulation} source code follow. - * \begin{itemize} - * \item @em{Counting the number of cells on a specific level} - * \begin{verbatim} + * @begin{itemize} + * @item @em{Counting the number of cells on a specific level} + * @begin{verbatim} * template * int Triangulation::n_cells (const int level) const { * cell_iterator cell = begin (level), @@ -537,9 +537,9 @@ struct TriaNumberCache<3> : public TriaNumberCache<2> * ++n; * return n; * }; - * \end{verbatim} + * @end{verbatim} * Another way which uses the STL @p{distance} function would be to write - * \begin{verbatim} + * @begin{verbatim} * template * int Triangulation::n_cells (const int level) const { * int n=0; @@ -550,10 +550,10 @@ struct TriaNumberCache<3> : public TriaNumberCache<2> * n); * return n; * }; - * \end{verbatim} + * @end{verbatim} * - * \item @em{Refining all cells of a triangulation} - * \begin{verbatim} + * @item @em{Refining all cells of a triangulation} + * @begin{verbatim} * template * void Triangulation::refine_global () { * active_cell_iterator cell = begin_active(), @@ -563,15 +563,15 @@ struct TriaNumberCache<3> : public TriaNumberCache<2> * cell->set_refine_flag (); * execute_coarsening_and_refinement (); * }; - * \end{verbatim} - * \end{itemize} + * @end{verbatim} + * @end{itemize} * * * @sect3{Usage} * * Usage of a @p{Triangulation} is mainly done through the use of iterators. * An example probably shows best how to use it: - * \begin{verbatim} + * @begin{verbatim} * void main () { * Triangulation<2> tria; * @@ -608,26 +608,26 @@ struct TriaNumberCache<3> : public TriaNumberCache<2> * ofstream out("grid.1"); * GridOut::write_gnuplot (tria, out); * }; - * \end{verbatim} + * @end{verbatim} * * * @sect3{Creating a triangulation} * * There are several possibilities to create a triangulation: - * \begin{itemize} - * \item The most common domains, such as hypercubes (i.e. lines, squares, + * @begin{itemize} + * @item The most common domains, such as hypercubes (i.e. lines, squares, * cubes, etc), hyper-balls (circles, balls, ...) and some other, more * weird domains such as the L-shape region and higher dimensional * generalizations and others, are provided by the @p{GridGenerator} * class which takes a triangulation and fills it by a division * of the required domain. * - * \item Reading in a triangulation: By using an object of the @p{DataIn} + * @item Reading in a triangulation: By using an object of the @p{DataIn} * class, you can read in fairly general triangulations. See there for * more information. The mentioned class uses the interface described * directly below to transfer the data into the triangulation. * - * \item Explicitely creating a triangulation: you can create a triangulation + * @item Explicitely creating a triangulation: you can create a triangulation * by providing a list of vertices and a list of cells. Each such cell * consists of a vector storing the indices of the vertices of this cell * in the vertex list. To see how this works, you can take a look at the @@ -660,12 +660,12 @@ struct TriaNumberCache<3> : public TriaNumberCache<2> * * There are more subtle conditions which must be imposed upon the * vertex numbering within cells. See the documentation for the - * \Ref{DataIn} class for more details on this. They do not only + * @ref{DataIn} class for more details on this. They do not only * hold for the data read from an UCD or any other input file, but * also for the data passed to the * @p{Triangulation::create_triangulation (2)} function. * - * \item Copying a triangulation: when computing on time dependant meshes + * @item Copying a triangulation: when computing on time dependant meshes * of when using adaptive refinement, you will often want to create a * new triangulation to be the same as another one. This is facilitated * by the @p{copy_triangulation} function. @@ -679,7 +679,7 @@ struct TriaNumberCache<3> : public TriaNumberCache<2> * operation but guaranteeing some parallelity in the two triangulations * seems more important since usually data will have to be transferred * between the grids. - * \end{itemize} + * @end{itemize} * * The material id for each cell must be specified upon construction of * a triangulation. (There is a special section on material identifier and @@ -789,8 +789,8 @@ struct TriaNumberCache<3> : public TriaNumberCache<2> * * There are two variations of these functions, which rely on @p{refine} and * coarsen by computing the thresholds from other information: - * \begin{itemize} - * \item @p{refine_and_coarsen_fixed_number}: this function takes a vector as + * @begin{itemize} + * @item @p{refine_and_coarsen_fixed_number}: this function takes a vector as * above and two values between zero and one denoting the fractions of cells to * be refined and coarsened. For this purpose, it sorts the criteria per cell * and takes the threshold to be the one belonging to the cell with the @@ -813,7 +813,7 @@ struct TriaNumberCache<3> : public TriaNumberCache<2> * want to chose a smaller value to avoid overrefinement in regions which * do not contribute much to the error. * - * \item @p{refine_and_coarsen_fixed_fraction}: this function computes the + * @item @p{refine_and_coarsen_fixed_fraction}: this function computes the * threshold such that the number of cells getting flagged for refinement * makes up for a certain fraction of the total error. If this fraction is 50 * per cent, for example, the threshold is computed such that the cells with @@ -843,7 +843,7 @@ struct TriaNumberCache<3> : public TriaNumberCache<2> * @p{coarsen}. * * A typical value for the fraction of the total error is 0.5. - * \end{itemize} + * @end{itemize} * * For a more thorough discussion of advantages and disadvantages of the * different strategies for refinement, see the paper of R. Becker and @@ -887,12 +887,12 @@ struct TriaNumberCache<3> : public TriaNumberCache<2> * The parameter taken by the constructor is an integer which may be composed * bitwise by the constants defined in the @p{enum MeshSmoothing}. The meaning * of these constants is explained in the following: - * \begin{itemize} - * \item @p{limit_level_difference_at_vertices}: + * @begin{itemize} + * @item @p{limit_level_difference_at_vertices}: * It can be shown, that degradation of approximation occurs if the * triangulation contains vertices which are member of cells with levels * differing by more than one. One such example is the following: - * \begin{verbatim} + * @begin{verbatim} * | | | | * x-----x-----x--x--x-- * | | | | | @@ -907,7 +907,7 @@ struct TriaNumberCache<3> : public TriaNumberCache<2> * | | | * | | | * x-----------x-----x-- - * \end{verbatim} + * @end{verbatim} * It seems that in two space dimensions, the maximum jump in levels between * cells sharing a common vertex is two (as in the example above). This is * not true if more than four cells meet at a vertex. It is not uncommon @@ -932,7 +932,7 @@ struct TriaNumberCache<3> : public TriaNumberCache<2> * @p{limit_level_difference_at_vertices}, situations as the above one are * eliminated by also marking the lower left cell for refinement. * - * \item @p{eliminate_unrefined_islands}: + * @item @p{eliminate_unrefined_islands}: * Single cells which are not refined and are surrounded by cells which are * refined usually also lead to a sharp decline in approximation properties * locally. The reason is that the nodes on the faces between unrefined and @@ -951,7 +951,7 @@ struct TriaNumberCache<3> : public TriaNumberCache<2> * name of the flag may indicate. However, no better name came to mind to * the author by now. * - * \item @p{eliminate_refined_*_islands}: + * @item @p{eliminate_refined_*_islands}: * This algorithm seeks for isolated cells which are refined or flagged * for refinement. This definition is unlike that for * @p{eliminate_unrefined_islands}, which would mean that an island is @@ -983,12 +983,12 @@ struct TriaNumberCache<3> : public TriaNumberCache<2> * refines the mesh according to a criterion associated with a boundary * integral or if one has rough boundary data. * - * \item @p{do_not_produce_unrefined_islands}: + * @item @p{do_not_produce_unrefined_islands}: * This flag prevents the occurrence of unrefined islands. In more detail: * It prohibits the coarsening of a cell if 'most of the neighbors' will * be refined after the step. * - * \item @p{patch_level_1}: + * @item @p{patch_level_1}: * Ensures patch level 1. As result the triangulation consists of * patches, i.e. of cells that are refined once. It follows that * if at least one of the children of a cell is or will be refined @@ -998,21 +998,21 @@ struct TriaNumberCache<3> : public TriaNumberCache<2> * @p{eliminate_refined_boundary_islands} will be ignored as they will * be fulfilled automatically. * - * \item @p{smoothing_on_refinement}: + * @item @p{smoothing_on_refinement}: * This flag sums up all smoothing algorithms which may be performed upon * refinement by flagging some more cells for refinement. * - * \item @p{smoothing_on_coarsening}: + * @item @p{smoothing_on_coarsening}: * This flag sums up all smoothing algorithms which may be performed upon * coarsening by flagging some more cells for coarsening. * - * \item @p{maximum_smoothing}: + * @item @p{maximum_smoothing}: * This flag includes all the above ones and therefore combines all * smoothing algorithms implemented. * - * \item @p{none}: + * @item @p{none}: * Select no smoothing at all. - * \end{itemize} + * @end{itemize} * * * @sect3{Material and boundary information} @@ -1059,7 +1059,7 @@ struct TriaNumberCache<3> : public TriaNumberCache<2> * It is possible to reconstruct a grid from its refinement history, which * can be stored and loaded through the @p{save_refine_flags} and * @p{load_refine_flags} functions. Normally, the code will look like this: - * \begin{verbatim} + * @begin{verbatim} * // open output file * ofstream history("mesh.history"); * // do 10 refinement steps @@ -1070,10 +1070,10 @@ struct TriaNumberCache<3> : public TriaNumberCache<2> * tria.save_refine_flags (history); * tria.execute_coarsening_and_refinement (); * }; - * \end{verbatim} + * @end{verbatim} * * If you want to re-create the grid from the stored information, you write: - * \begin{verbatim} + * @begin{verbatim} * // open input file * ifstream history("mesh.history"); * // do 10 refinement steps @@ -1081,7 +1081,7 @@ struct TriaNumberCache<3> : public TriaNumberCache<2> * tria.load_refine_flags (history); * tria.execute_coarsening_and_refinement (); * }; - * \end{verbatim} + * @end{verbatim} * * The same scheme is employed for coarsening and the coarsening flags. * @@ -1161,11 +1161,11 @@ struct TriaNumberCache<3> : public TriaNumberCache<2> * component. If a new vertex is created on a side or face at the * boundary, this function is used to compute where it will be * placed. The boundary indicator of the face will be used to - * determine the proper component. See \Ref{Boundary} for the + * determine the proper component. See @ref{Boundary} for the * details. Usage with the @p{Triangulation} object is then like this * (let @p{Ball} be a class derived from @p{Boundary<2>}): * - * \begin{verbatim} + * @begin{verbatim} * void main () { * Triangulation<2> tria; * // set the boundary function @@ -1192,7 +1192,7 @@ struct TriaNumberCache<3> : public TriaNumberCache<2> * tria.execute_coarsening_and_refinement(); * }; * }; - * \end{verbatim} + * @end{verbatim} * * You should take note of one caveat: if you have concave * boundaries, you must make sure that a new boundary vertex does @@ -1223,8 +1223,8 @@ struct TriaNumberCache<3> : public TriaNumberCache<2> * decides which additional cells to flag for refinement by looking * at the old grid and the refinement flags for each cell. * - * \begin{itemize} - * \item @em{Regularization:} The algorithm walks over all cells checking + * @begin{itemize} + * @item @em{Regularization:} The algorithm walks over all cells checking * whether the present cell is flagged for refinement and a neighbor of the * present cell is refined once less than the present one. If so, flag the * neighbor for refinement. Because of the induction above, there may be no @@ -1238,9 +1238,9 @@ struct TriaNumberCache<3> : public TriaNumberCache<2> * on lower levels, but if these induce more refinement needed, this is * performed later on when we visit them in out backward running loop. * - * \item @em{Smoothing:} - * \begin{itemize} - * \item @p{limit_level_difference_at_vertices}: + * @item @em{Smoothing:} + * @begin{itemize} + * @item @p{limit_level_difference_at_vertices}: * First a list is set up which stores for each vertex * the highest level one of the adjacent cells belongs to. Now, since we did * smoothing in the previous refinement steps also, each cell may only have @@ -1254,7 +1254,7 @@ struct TriaNumberCache<3> : public TriaNumberCache<2> * refinement, but these are on lower levels, as above, which is why we * may do all kinds of additional flagging in one loop only. * - * \item @p{eliminate_unrefined_islands}: + * @item @p{eliminate_unrefined_islands}: * For each cell we count the number of neighbors which are refined or * flagged for refinement. If this exceeds the total number of neighbors * (which is the number of faces minus the number of faces of this cell @@ -1263,7 +1263,7 @@ struct TriaNumberCache<3> : public TriaNumberCache<2> * will need refinement, we will need additional loops of regularization * and smoothing over all cells until nothing changes any more. * - * \item @p{eliminate_refined_*_islands}: + * @item @p{eliminate_refined_*_islands}: * This one does much the same as the above one, but for coarsening. If * a cell is flagged for refinement or if all of its children are active * and if the number of neighbors which are either active and not flagged @@ -1277,8 +1277,8 @@ struct TriaNumberCache<3> : public TriaNumberCache<2> * of this classes description. * * The same applies as above: several loops may be necessary. - * \end{itemize} - * \end{itemize} + * @end{itemize} + * @end{itemize} * * Regularization and smoothing are a bit complementary in that we check * whether we need to set additional refinement flags when being on a cell @@ -1297,7 +1297,7 @@ struct TriaNumberCache<3> : public TriaNumberCache<2> * 2D. The direction of a line is the direction of point 0 towards point 1. We * define, that allowed cells contain of lines of which the direction is * as follows: - * \begin{verbatim} + * @begin{verbatim} * 2 * 3--->---2 * | | @@ -1305,7 +1305,7 @@ struct TriaNumberCache<3> : public TriaNumberCache<2> * | | * 0--->---1 * 0 - * \end{verbatim} + * @end{verbatim} * The number of the vertices and lines is also indicated. This orientation of * lines has to be checked/generated upon construction of a grid and is * preserved upon refinement. @@ -1323,14 +1323,14 @@ struct TriaNumberCache<3> : public TriaNumberCache<2> * When explicit coordinates are required for points in a cell (e.g for * quadrature formulae or the point of definition of trial functions), we * define the following coordinate system for the unit cell: - * \begin{verbatim} + * @begin{verbatim} * y^ 3-------2 * | | | * | | | * | | | * | 0-------1 * *-------------->x - * \end{verbatim} + * @end{verbatim} * with vertex 0 being the origin of the coordinate system, vertex 1 having * coordinates @p{(1,0)}, vertex 2 at @p{(1,1)} and vertex 3 at @p{(0,1)}. * @@ -1341,7 +1341,7 @@ struct TriaNumberCache<3> : public TriaNumberCache<2> * faces of hexahedra in three space dimensions. Before giving these * conventions we declare the following sketch to be the standard way of * drawing 3d pictures of hexahedra: - * \begin{verbatim} + * @begin{verbatim} * *-------* *-------* * /| | / /| * / | | / / | @@ -1352,7 +1352,7 @@ struct TriaNumberCache<3> : public TriaNumberCache<2> * | / / | | / * |/ / | |/ * *-------* *-------* - * \end{verbatim} + * @end{verbatim} * The left part of the picture shows the left, bottom and back face of the * cube, while the right one shall be the top, right and front face. You may * recover the whole cube by moving the two parts together into one. @@ -1363,7 +1363,7 @@ struct TriaNumberCache<3> : public TriaNumberCache<2> * the vertices on a quadrilateral. The vertices on the back face are numbered * similarly by moving the front face to the back (no turning, no twisting, * just a shift): - * \begin{verbatim} + * @begin{verbatim} * 7-------6 7-------6 * /| | / /| * / | | / / | @@ -1374,14 +1374,14 @@ struct TriaNumberCache<3> : public TriaNumberCache<2> * | / / | | / * |/ / | |/ * 0-------1 0-------1 - * \end{verbatim} + * @end{verbatim} * * @sect4{Lines} * * Here, the same holds as for the vertices: the lines of the front face are * numbered as for the quadrilateral, for the back face they are just shifted. * Finally, the four lines connecting front and back face are numbered: - * \begin{verbatim} + * @begin{verbatim} * *---6---* *---6---* * /| | / /| * 11 | 5 11 10 5 @@ -1392,10 +1392,10 @@ struct TriaNumberCache<3> : public TriaNumberCache<2> * 3 8 9 3 | 9 * |/ / | |/ * *---0---* *---0---* - * \end{verbatim} + * @end{verbatim} * The directions of the front and back lines is as for the respective faces, while * the connecting lines always point to the back: - * \begin{verbatim} + * @begin{verbatim} * *--->---* *--->---* * /| | / /| * ^ | ^ ^ ^ ^ @@ -1406,13 +1406,13 @@ struct TriaNumberCache<3> : public TriaNumberCache<2> * ^ ^ ^ ^ | ^ * |/ / | |/ * *--->---* *--->---* - * \end{verbatim} + * @end{verbatim} * * @sect4{Faces} * * The faces are numbered in the same order as the lines were numbered: front * face, back face, then the four side faces: - * \begin{verbatim} + * @begin{verbatim} * *-------* *-------* * /| | / /| * / | 1 | / 4 / | @@ -1423,13 +1423,13 @@ struct TriaNumberCache<3> : public TriaNumberCache<2> * | / 2 / | 0 | / * |/ / | |/ * *-------* *-------* - * \end{verbatim} + * @end{verbatim} * * The direction of the faces is determined by the numbers the lines have within * a given face. This is like follows: - * \begin{itemize} - * \item Faces 0 and 1: - * \begin{verbatim} + * @begin{itemize} + * @item Faces 0 and 1: + * @begin{verbatim} * *---2---* *-------* * /| | / /| * / | 1 / / | @@ -1440,10 +1440,10 @@ struct TriaNumberCache<3> : public TriaNumberCache<2> * | / / 3 | / * |/ / | |/ * *-------* *---0---* - * \end{verbatim} + * @end{verbatim} * - * \item Faces 2 and 4: - * \begin{verbatim} + * @item Faces 2 and 4: + * @begin{verbatim} * *-------* *---2---* * /| | / /| * / | | 3 1 | @@ -1454,10 +1454,10 @@ struct TriaNumberCache<3> : public TriaNumberCache<2> * | 3 1 | | / * |/ / | |/ * *---0---* *-------* - * \end{verbatim} + * @end{verbatim} * - * \item Faces 3 and 5: - * \begin{verbatim} + * @item Faces 3 and 5: + * @begin{verbatim} * *-------* *-------* * /| | / /| * 2 1 | / 2 1 @@ -1468,30 +1468,30 @@ struct TriaNumberCache<3> : public TriaNumberCache<2> * | 0 / | | 0 * |/ / | |/ * *-------* *-------* - * \end{verbatim} - * \end{itemize} + * @end{verbatim} + * @end{itemize} * * Due to this numbering, the following lines are identical: - * \begin{itemize} - * \item Line 0 of face 0, and line 0 of face 2; - * \item Line 1 of face 0, and line 3 of face 3; - * \item Line 2 of face 0, and line 0 of face 4; - * \item Line 3 of face 0, and line 3 of face 5; - * \item Line 0 of face 1, and line 2 of face 2; - * \item Line 1 of face 1, and line 1 of face 3; - * \item Line 2 of face 1, and line 2 of face 4; - * \item Line 3 of face 1, and line 1 of face 5; - * \item Line 3 of face 2, and line 0 of face 5; - * \item Line 1 of face 2, and line 0 of face 3; - * \item Line 1 of face 4, and line 2 of face 3; - * \item Line 3 of face 4, and line 2 of face 5. - * \end{itemize} + * @begin{itemize} + * @item Line 0 of face 0, and line 0 of face 2; + * @item Line 1 of face 0, and line 3 of face 3; + * @item Line 2 of face 0, and line 0 of face 4; + * @item Line 3 of face 0, and line 3 of face 5; + * @item Line 0 of face 1, and line 2 of face 2; + * @item Line 1 of face 1, and line 1 of face 3; + * @item Line 2 of face 1, and line 2 of face 4; + * @item Line 3 of face 1, and line 1 of face 5; + * @item Line 3 of face 2, and line 0 of face 5; + * @item Line 1 of face 2, and line 0 of face 3; + * @item Line 1 of face 4, and line 2 of face 3; + * @item Line 3 of face 4, and line 2 of face 5. + * @end{itemize} * * * @sect4{Children} * * The eight children of a cell are numbered as follows: - * \begin{verbatim} + * @begin{verbatim} * *-------* *-------* * /| 7 6 | / 7 6 /| * /7| | / /6| @@ -1502,18 +1502,18 @@ struct TriaNumberCache<3> : public TriaNumberCache<2> * |0/ / | |1/ * |/0 1 / | 0 1 |/ * *-------* *-------* - * \end{verbatim} + * @end{verbatim} * * Taking into account the orientation of the faces, the following * children are adjacent to the respective faces: - * \begin{itemize} - * \item Face 0: children 0, 1, 2, 3; - * \item Face 1: children 4, 5, 6, 7; - * \item Face 2: children 0, 1, 5, 4; - * \item Face 3: children 1, 5, 6, 2; - * \item Face 4: children 3, 2, 6, 7; - * \item Face 5: children 0, 4, 7, 3. - * \end{itemize} + * @begin{itemize} + * @item Face 0: children 0, 1, 2, 3; + * @item Face 1: children 4, 5, 6, 7; + * @item Face 2: children 0, 1, 5, 4; + * @item Face 3: children 1, 5, 6, 2; + * @item Face 4: children 3, 2, 6, 7; + * @item Face 5: children 0, 4, 7, 3. + * @end{itemize} * You can get these numbers using the @p{GeometryInfo<3>::child_cell_on_face} * function. Each child is adjacent to the vertex with the same number. * @@ -1522,7 +1522,7 @@ struct TriaNumberCache<3> : public TriaNumberCache<2> * * We define the following coordinate system for the explicit coordinates of * the vertices of the unit cell: - * \begin{verbatim} + * @begin{verbatim} * 7-------6 7-------6 * /| | / /| * / | | / / | @@ -1533,7 +1533,7 @@ struct TriaNumberCache<3> : public TriaNumberCache<2> * | / | / / | | / * |/ |/ / | |/ * *------>x 0-------1 0-------1 - * \end{verbatim} + * @end{verbatim} * This convention in conjunction with the numbering of the vertices is a bit * unfortunate, since the vertices 0 through 3 have the coordinates @p{(x,0,z)} * with @p{x} and @p{z} being the same as the @p{x} and @p{y} coordinates of a quad @@ -1542,16 +1542,16 @@ struct TriaNumberCache<3> : public TriaNumberCache<2> * * By the convention laid down as above, the vertices have the following * coordinates: - * \begin{itemize} - * \item Vertex 0: @p{(0,0,0)}; - * \item Vertex 1: @p{(1,0,0)}; - * \item Vertex 2: @p{(1,0,1)}; - * \item Vertex 3: @p{(0,0,1)}; - * \item Vertex 4: @p{(0,1,0)}; - * \item Vertex 5: @p{(1,1,0)}; - * \item Vertex 6: @p{(1,1,1)}; - * \item Vertex 7: @p{(0,1,1)}. - * \end{itemize} + * @begin{itemize} + * @item Vertex 0: @p{(0,0,0)}; + * @item Vertex 1: @p{(1,0,0)}; + * @item Vertex 2: @p{(1,0,1)}; + * @item Vertex 3: @p{(0,0,1)}; + * @item Vertex 4: @p{(0,1,0)}; + * @item Vertex 5: @p{(1,1,0)}; + * @item Vertex 6: @p{(1,1,1)}; + * @item Vertex 7: @p{(0,1,1)}. + * @end{itemize} * * * @sect3{Warning} diff --git a/deal.II/deal.II/include/grid/tria_accessor.h b/deal.II/deal.II/include/grid/tria_accessor.h index 2b4c559fec..816e9c9a87 100644 --- a/deal.II/deal.II/include/grid/tria_accessor.h +++ b/deal.II/deal.II/include/grid/tria_accessor.h @@ -37,7 +37,7 @@ class Hexahedron; /** * Implements the accessor class descibed in the documentation of - * the iterator classes (see \Ref{TriaRawIterator}. + * the iterator classes (see @ref{TriaRawIterator}. * * This class offers only the basic functionality (stores the necessary * data members, offers comparison operators and the like), but has no @@ -158,7 +158,7 @@ class TriaAccessor * Return the state of the iterator. * For the different states an accessor * can be in, refer to the - * \Ref{TriaRawIterator} documentation. + * @ref{TriaRawIterator} documentation. */ IteratorState state () const; @@ -1035,7 +1035,7 @@ class TriaObjectAccessor<2, dim> : public TriaAccessor * a quad. The @p{i}th vertex is the common * one of line @p{i} and @p{(i+3)%4}. See also * the introduced convention - * (\Ref{Triangulation}). + * (@ref{Triangulation}). */ int vertex_index (const unsigned int i) const; @@ -1751,7 +1751,7 @@ class TriaObjectAccessor<3, dim> : public TriaAccessor * * The following refers to any space dimension: * - * This class allows access to a {\bf cell}, which is a line in 1D and a quad in + * This class allows access to a @em{cell}, which is a line in 1D and a quad in * 2D. Cells have more functionality than lines or quads by themselves, for * example they can be flagged for refinement, they have neighbors, they have * the possibility to check whether they are at the boundary etc. This class diff --git a/deal.II/deal.II/include/grid/tria_boundary.h b/deal.II/deal.II/include/grid/tria_boundary.h index 907f8f47e7..61dbfd3bdf 100644 --- a/deal.II/deal.II/include/grid/tria_boundary.h +++ b/deal.II/deal.II/include/grid/tria_boundary.h @@ -27,17 +27,17 @@ template class Triangulation; * When a triangulation creates a new vertex on the boundary of the * domain, it determines the new vertex' coordinates through the * following code (here in two dimensions): - * \begin{verbatim} + * @begin{verbatim} * ... * Point<2> new_vertex = boundary.get_new_point_on_line (line); * ... - * \end{verbatim} + * @end{verbatim} * @p{line} denotes the line at the boundary that shall be refined * and for which we seek the common point of the two child lines. * * In 3D, a new vertex may be placed on the middle of a line or on * the middle of a side. Respectively, the library calls - * \begin{verbatim} + * @begin{verbatim} * ... * Point<3> new_line_vertices[4] * = { boundary.get_new_point_on_line (face->line(0)), @@ -45,14 +45,14 @@ template class Triangulation; * boundary.get_new_point_on_line (face->line(2)), * boundary.get_new_point_on_line (face->line(3)) }; * ... - * \end{verbatim} + * @end{verbatim} * to get the four midpoints of the lines bounding the quad at the * boundary, and after that - * \begin{verbatim} + * @begin{verbatim} * ... * Point<3> new_quad_vertex = boundary.get_new_point_on_quad (face); * ... - * \end{verbatim} + * @end{verbatim} * to get the midpoint of the face. It is guaranteed that this order * (first lines, then faces) holds, so you can use information from * the children of the four lines of a face, since these already exist @@ -124,7 +124,7 @@ class Boundary : public Subscriptor { /** - * Specialisation of \Ref{Boundary}, which places the new point right + * Specialisation of @ref{Boundary}, which places the new point right * into the middle of the given points. The middle is defined as the * arithmetic mean of the points. * diff --git a/deal.II/deal.II/include/grid/tria_boundary_lib.h b/deal.II/deal.II/include/grid/tria_boundary_lib.h index 4a079c5246..70a8695cd6 100644 --- a/deal.II/deal.II/include/grid/tria_boundary_lib.h +++ b/deal.II/deal.II/include/grid/tria_boundary_lib.h @@ -18,7 +18,7 @@ /** - * Specialisation of \Ref{Boundary}, which places the new point on + * Specialisation of @ref{Boundary}, which places the new point on * the boundary of a ball in arbitrary dimension. It works by projecting * the point in the middle of the old points onto the ball. The middle is * defined as the arithmetic mean of the points. diff --git a/deal.II/deal.II/include/grid/tria_iterator.h b/deal.II/deal.II/include/grid/tria_iterator.h index 9a4a48ee9a..73435e7a68 100644 --- a/deal.II/deal.II/include/grid/tria_iterator.h +++ b/deal.II/deal.II/include/grid/tria_iterator.h @@ -40,20 +40,20 @@ template class Triangulation; * iterators an iterator of this class provides a @p{->} operator, i.e. you can * write statements like @p{i->set_refine_flag ();}. * - * {\bf Note:} Please read the documentation about the prefix and the + * @em{Note:} Please read the documentation about the prefix and the * postfix @p{++} operators in this and the derived classes! * * @sect3{Purpose} * * @p{iterators} are used whenever a loop over all lines, quads, cells etc. * is to be performed. These loops can then be coded like this: - * \begin{verbatim} + * @begin{verbatim} * cell_iterator i = tria.begin(); * cell_iterator end = tria.end(); * for (; i!=end; ++i) * if (cell->at_boundary()) * cell->set_refine_flag(); - * \end{verbatim} + * @end{verbatim} * Note the usage of @p{++i} instead of @p{i++} since this does not involve * temporaries and copying. You should also really use a fixed value * @p{end} rather than coding @p{for (; i!=tria.end(); ++i)}, since @@ -105,7 +105,7 @@ template class Triangulation; * input and bidirectional iterators as stated by the C++ standard and * the STL documentation. It is therefore possible to use the functions * from the @em{algorithm section} of the C++ standard, e.g. @p{count_if} - * (see the documentation for \Ref{Triangulation} for an example) and + * (see the documentation for @ref{Triangulation} for an example) and * several others. * * @@ -117,7 +117,7 @@ template class Triangulation; * also do not want to destroy the ordering induced by the numbering * in the vectors). Therefore not all raw iterators point to valid objects. * - * There are two derived versions of this class: \Ref{TriaIterator} + * There are two derived versions of this class: @ref{TriaIterator} * objects, which only loop over used (valid) cells and * @p{TriaActiveIterator} objects * which only loop over active cells (not refined). @@ -129,30 +129,30 @@ template class Triangulation; * only becomes useful when assigned an @p{Accessor} (the second template * parameter), which really does the access to data. An @p{Accessor} has to * fulfil some requirements: - * \begin{itemize} - * \item It must have two members named @p{present_level} and @p{present_index} + * @begin{itemize} + * @item It must have two members named @p{present_level} and @p{present_index} * storing the address of the element in the triangulation presently * pointed to. Furthermore, the three @p{Tria{Raw| |Active}Iterator} classes * have to be friends to the accessor or these data members must be public. - * \item It must have a constructor which takes 1. a @p{Triangulation*}, + * @item It must have a constructor which takes 1. a @p{Triangulation*}, * 2. and 3. and integer, denoting the initial level and index. - * \item For the @p{TriaIterator} and the @p{TriaActiveIterator} class, it must + * @item For the @p{TriaIterator} and the @p{TriaActiveIterator} class, it must * have a member function @p{bool used()}, for the latter a member function * @p{bool active()}. - * \item It must have void operators @p{++} and @p{--}. - * \item It must declare a local @p{typedef} @p{AccessorData} which states + * @item It must have void operators @p{++} and @p{--}. + * @item It must declare a local @p{typedef} @p{AccessorData} which states * the data type the accessor expects to get passed as fourth constructor * argument. By declaring a local data type, the respective iterator * class may type-safely enforce that data type to be one of its own * constructor argument types. If an accessor class does not need * additional data, this type shall be @p{void}. - * \end{itemize} + * @end{itemize} * Then the iterator is able to do what it is supposed to. All of the necessary * functions are implemented in the @p{Accessor} base class, but you may write * your own version (non-virtual, since we use templates) to add functionality. * * There is a standard implementation, using classes which are derived from - * \Ref{TriaAccessor}. These classes point to @p{Line}s, @p{Quad}s and the like. + * @ref{TriaAccessor}. These classes point to @p{Line}s, @p{Quad}s and the like. * For advanced use of the iterator classes, derive classes from * @p{{Line|Quad|Cell}Accessor} which also dereference data structures in other * objects, e.g. in a finite element context. An iterator with such an accessor @@ -252,11 +252,11 @@ class TriaRawIterator : public bidirectional_iterator { * Through this constructor, it is also * possible to construct object for * derived iterators: - * \begin{verbatim} + * @begin{verbatim} * DoFCellAccessor dof_accessor; * Triangulation::active_cell_iterator cell * = accessor; - * \end{verbatim} + * @end{verbatim} */ TriaRawIterator (const Accessor &a); @@ -500,7 +500,7 @@ class TriaRawIterator : public bidirectional_iterator { /** - * This specialization of \Ref{TriaRawIterator} provides access only to the + * This specialization of @ref{TriaRawIterator} provides access only to the * @em{used} lines, quads, cells, etc. */ template @@ -645,7 +645,7 @@ class TriaIterator : public TriaRawIterator { /** - * This specialization of \Ref{TriaIterator} provides access only to the + * This specialization of @ref{TriaIterator} provides access only to the * @em{active} lines, quads, cells, etc. An active cell is a cell which is not * refined and thus a cell on which calculations on the finest level are done. */ diff --git a/deal.II/deal.II/include/grid/tria_levels.h b/deal.II/deal.II/include/grid/tria_levels.h index f4b423ded0..c8fc2b696d 100644 --- a/deal.II/deal.II/include/grid/tria_levels.h +++ b/deal.II/deal.II/include/grid/tria_levels.h @@ -95,7 +95,7 @@ class TriangulationLevel<0> { * at the boundary), @p{level=index=-1} * is set. * - * {\bf Conventions:} The @p{i}th neighbor + * @em{Conventions:} The @p{i}th neighbor * of a cell is the one which shares * the @p{i}th face (@p{Line} in 2D, @p{Quad} * in 3D) of this cell. diff --git a/deal.II/deal.II/include/multigrid/mg_base.h b/deal.II/deal.II/include/multigrid/mg_base.h index fd65894c5b..ae1f046c67 100644 --- a/deal.II/deal.II/include/multigrid/mg_base.h +++ b/deal.II/deal.II/include/multigrid/mg_base.h @@ -263,7 +263,7 @@ class MGTransferBase : public Subscriptor * Basic class for preconditioning by multigrid. * * The functionality of the multigrid method is restricted to defect - * correction. It is {\bf not} iterative and the start solution is + * correction. It is @em{not} iterative and the start solution is * always zero. Since by this $u^E_l$ and $u^A_l$ (see report on * multigrid) are always zero, restriction is simplified a lot and * maybe even the seam condition on grids is oblivious. Still, I am diff --git a/deal.II/deal.II/include/multigrid/mg_dof_accessor.h b/deal.II/deal.II/include/multigrid/mg_dof_accessor.h index 18be3c550f..c09d075ac2 100644 --- a/deal.II/deal.II/include/multigrid/mg_dof_accessor.h +++ b/deal.II/deal.II/include/multigrid/mg_dof_accessor.h @@ -190,7 +190,7 @@ class MGDoFObjectAccessor<0, dim> /** * Grant access to the degrees of freedom located on lines. * This class follows mainly the route laid out by the accessor library - * declared in the triangulation library (\Ref{TriaAccessor}). It enables + * declared in the triangulation library (@ref{TriaAccessor}). It enables * the user to access the degrees of freedom on the lines (there are similar * versions for the DoFs on quads, etc), where the dimension of the underlying * triangulation does not really matter (i.e. this accessor works with the @@ -199,7 +199,7 @@ class MGDoFObjectAccessor<0, dim> * * @sect3{Usage} * - * The \Ref{DoFDimensionInfo} classes inherited by the \Ref{DoFHandler} classes + * The @ref{DoFDimensionInfo} classes inherited by the @ref{DoFHandler} classes * declare typedefs to iterators using the accessors declared in this class * hierarchy tree. Usage is best to happens through these typedefs, since they * are more secure to changes in the class naming and template interface as well diff --git a/deal.II/deal.II/include/multigrid/mg_dof_handler.h b/deal.II/deal.II/include/multigrid/mg_dof_handler.h index d1661cdc95..4a6abcc1c6 100644 --- a/deal.II/deal.II/include/multigrid/mg_dof_handler.h +++ b/deal.II/deal.II/include/multigrid/mg_dof_handler.h @@ -24,7 +24,7 @@ template class MGDoFObjectAccessor; /** * Define some types which differ between the dimensions. This class - * is analogous to the \Ref{TriaDimensionInfo} class hierarchy. + * is analogous to the @ref{TriaDimensionInfo} class hierarchy. * * @see MGDoFDimensionInfo<1> * @see MGDoFDimensionInfo<2> @@ -36,7 +36,7 @@ class MGDoFDimensionInfo; /** * Define some types for the DoF handling in one dimension. * - * The types have the same meaning as those declared in \Ref{TriaDimensionInfo<2>}. + * The types have the same meaning as those declared in @ref{TriaDimensionInfo<2>}. */ class MGDoFDimensionInfo<1> { public: @@ -65,7 +65,7 @@ class MGDoFDimensionInfo<1> { /** * Define some types for the DoF handling in two dimensions. * - * The types have the same meaning as those declared in \Ref{TriaDimensionInfo<2>}. + * The types have the same meaning as those declared in @ref{TriaDimensionInfo<2>}. */ class MGDoFDimensionInfo<2> { public: @@ -94,7 +94,7 @@ class MGDoFDimensionInfo<2> { /** * Define some types for the DoF handling in two dimensions. * - * The types have the same meaning as those declared in \Ref{TriaDimensionInfo<2>}. + * The types have the same meaning as those declared in @ref{TriaDimensionInfo<2>}. */ class MGDoFDimensionInfo<3> { public: diff --git a/deal.II/deal.II/include/numerics/assembler.h b/deal.II/deal.II/include/numerics/assembler.h index 49eecc2283..b19feb219a 100644 --- a/deal.II/deal.II/include/numerics/assembler.h +++ b/deal.II/deal.II/include/numerics/assembler.h @@ -150,7 +150,7 @@ class Assembler : public DoFCellAccessor * Structure to be passed upon * construction of an assembler object * through the iterator object. See - * \Ref{TriaRawIterator} for a discussion + * @ref{TriaRawIterator} for a discussion * of this mechanism. */ struct AssemblerData { diff --git a/deal.II/deal.II/include/numerics/base.h b/deal.II/deal.II/include/numerics/base.h index 92e2f0d9f1..626ceb0909 100644 --- a/deal.II/deal.II/include/numerics/base.h +++ b/deal.II/deal.II/include/numerics/base.h @@ -46,19 +46,19 @@ template class Equation; * * The @p{assemble} member function does the assemblage of the system matrix and * the given number of right hand sides. It does the following steps: - * \begin{itemize} - * \item Initialize solution vector with zero entries. - * \item Create sparsity pattern of the system matrix and condense it with + * @begin{itemize} + * @item Initialize solution vector with zero entries. + * @item Create sparsity pattern of the system matrix and condense it with * the constraints induced by hanging nodes. - * \item Initialize an assembler object. - * \item Loop over all cells and assemble matrix and vectors using the given + * @item Initialize an assembler object. + * @item Loop over all cells and assemble matrix and vectors using the given * quadrature formula and the equation object which contains the weak * formulation of the equation. - * \item Apply Dirichlet boundary conditions. See the section on boundary + * @item Apply Dirichlet boundary conditions. See the section on boundary * conditions for more details. - * \item Condense the system matrix and right hand side with the constraints + * @item Condense the system matrix and right hand side with the constraints * induced by hanging nodes. - * \end{itemize} + * @end{itemize} * * The @p{assemble} function needs an object describing the boundary of the domain, * since for higher order finite elements, we may be tempted to use curved faces @@ -80,7 +80,7 @@ template class Equation; * During assemblage of matrices and right hand side, use is made of dirichlet * boundary conditions (in short: bc) specified to the @p{assemble} function. You * can specify a list of pairs of boundary indicators (of type @p{unsigned char}; - * see the section in the documentation of the \Ref{Triangulation} class for more + * see the section in the documentation of the @ref{Triangulation} class for more * details) and the according functions denoting the dirichlet boundary values * of the nodes on boundary faces with this boundary indicator. * diff --git a/deal.II/deal.II/include/numerics/data_io.h b/deal.II/deal.II/include/numerics/data_io.h index 31336cd2ea..93db1b6f2a 100644 --- a/deal.II/deal.II/include/numerics/data_io.h +++ b/deal.II/deal.II/include/numerics/data_io.h @@ -152,15 +152,15 @@ class EpsOutputData; * Vectors are added as usual by @p{add_data_vector}. Then one has to * decide, wether to produce a 2D or 3D plot. This is done by setting * @p{height_info} to - * \begin{description} - * \item[NoHeight] for 2D-Output (or Top-View thats the same by no + * @begin{itemize} + * @item @em{NoHeight} for 2D-Output (or Top-View thats the same by no * turning is done) or to - * \item[HeightVector] for 3D-Output. You have to attach a + * @item @em{HeightVector} for 3D-Output. You have to attach a * @p{dof_data_vector} to actually get 3D. If you don't then output * will be generated in 2D. - * \item[DefaultHeight] is 3D if there is a @p{dof_data_vector} and 2D if + * @item @em{DefaultHeight} is 3D if there is a @p{dof_data_vector} and 2D if * none is present. - * \end{description} + * @end{itemize} * For 3D-Output one has to set @p{azimuth} and @p{elevation} for the * angle of view and @p{height_vector} to the number of the @p{dof_data} * vector that provides the height information to be used. The default @@ -169,32 +169,32 @@ class EpsOutputData; * * The cells can be shaded in four different modes, controlled by the * attribute @p{cell_shading}: - * \begin{enumerate} - * \item[NoShading] provides transparent shading. - * \item[ShadingVector] uses a cell vector to do shading. The number + * @begin{enumerate} + * @item @em{NoShading} provides transparent shading. + * @item @em{ShadingVector} uses a cell vector to do shading. The number * of the cell vector to be uses is provided in @p{cell_vector}. To * scale the cell vector there is the method @p{color}. It is called * with the actual value of the cell, the maximum and the minimum * value of a cell in the cell vector. It returns three values for * red, green and blue. If there no @p{cell_data} vector than there is * transparent shading. - * \item[LightShaded] just shades the plot. This is controlled by + * @item @em{LightShaded} just shades the plot. This is controlled by * the vector @p{light} which stores the direction of the light * beams. This is done only if there is height information. - * \item[DefaultShading] is controlled by presence of different + * @item @em{DefaultShading} is controlled by presence of different * vectors. If there no height information then do no * shading. Otherwise if there is @p{cell_data} use this for shading. * Otherwise do light shading. - * \end{enumerate} + * @end{enumerate} * * Finnaly one can choose to mark the cell boundaries by setting * @p{cell_boundary_shading}. It can take one of four values: - * \begin{itemize} - * \item NoBoundary for no cell boundaries, - * \item DefaultBoundary or - * \item BlackBoundary for black cell boundaries, - * \item WhiteBoundary for white cell boundaries, - * \end{itemize} + * @begin{itemize} + * @item NoBoundary for no cell boundaries, + * @item DefaultBoundary or + * @item BlackBoundary for black cell boundaries, + * @item WhiteBoundary for white cell boundaries, + * @end{itemize} * * Another interesting feature is that you can write multiple * eps-pictures to one file by just doing several invocations of @@ -349,14 +349,14 @@ class DataOut_Old { * suffix with a given output format * usually has. At present the following * formats are defined: - * \begin{itemize} - * \item @p{ucd}: @p{.inp} - * \item @p{gnuplot} and @p{gnuplot_draft}: + * @begin{itemize} + * @item @p{ucd}: @p{.inp} + * @item @p{gnuplot} and @p{gnuplot_draft}: * @p{.gnuplot} - * \item @p{povray_mesh}: @p{.pov} - * \item @p{eps}: @p{.eps} - * \item @p{gmv}: @p{.gmv}. - * \end{itemize} + * @item @p{povray_mesh}: @p{.pov} + * @item @p{eps}: @p{.eps} + * @item @p{gmv}: @p{.gmv}. + * @end{itemize} * * Since this function does not need data * from this object, it is static and can diff --git a/deal.II/deal.II/include/numerics/data_out.h b/deal.II/deal.II/include/numerics/data_out.h index 8b04cc83fb..82f60b61be 100644 --- a/deal.II/deal.II/include/numerics/data_out.h +++ b/deal.II/deal.II/include/numerics/data_out.h @@ -35,7 +35,7 @@ template class DoFHandler; * vectors which will later be written to a file in some format. Instead of * pondering about the different functions, an example is probably the best * way: - * \begin{verbatim} + * @begin{verbatim} * ... * ... // compute solution, which is of type Vector * ... // and contains nodal values @@ -58,7 +58,7 @@ template class DoFHandler; * data_out.write_xxx (output_file); * * data_out.clear(); - * \end{verbatim} + * @end{verbatim} * * @p{attach_dof_handler} tells this class that all future operations are to take * place with the @p{DoFHandler} object and the triangulation it lives on. We then diff --git a/deal.II/deal.II/include/numerics/data_out_stack.h b/deal.II/deal.II/include/numerics/data_out_stack.h index dcc1eb43d3..be16959583 100644 --- a/deal.II/deal.II/include/numerics/data_out_stack.h +++ b/deal.II/deal.II/include/numerics/data_out_stack.h @@ -66,7 +66,7 @@ template class DoFHandler; * which is suitable for quadratic finite elements in space, for * example. * - * \begin{verbatim} + * @begin{verbatim} * DataOutStack data_out_stack; * * // first declare the vectors @@ -94,7 +94,7 @@ template class DoFHandler; * data_out_stack.build_patches (2); * data_out_stack.finish_parameter_value (); * }; - * \end{verbatim} + * @end{verbatim} * * @author Wolfgang Bangerth, 1999 */ diff --git a/deal.II/deal.II/include/numerics/error_estimator.h b/deal.II/deal.II/include/numerics/error_estimator.h index 978636baf9..f391330082 100644 --- a/deal.II/deal.II/include/numerics/error_estimator.h +++ b/deal.II/deal.II/include/numerics/error_estimator.h @@ -120,8 +120,8 @@ template class FESubfaceValues; * * If the face is at the boundary, i.e. there is no neighboring cell to which * the jump in the gradiend could be computed, there are two possibilities: - * \begin{itemize} - * \item The face belongs to a Dirichlet boundary. Then the face is not + * @begin{itemize} + * @item The face belongs to a Dirichlet boundary. Then the face is not * considered, which can be justified looking at a dual problem technique and * should hold exactly if the boundary can be approximated exactly by the * finite element used (i.e. it is a linear boundary for linear finite elements, @@ -138,15 +138,15 @@ template class FESubfaceValues; * store a zero for this face, which makes summing up the contributions of * the different faces to the cells easier. * - * \item The face belongs to a Neumann boundary. In this case, the + * @item The face belongs to a Neumann boundary. In this case, the * contribution of the face $F\in\partial K$ looks like * $$ \int_F \left|g-a\frac{\partial u_h}{\partial n}\right|^2 ds $$ * where $g$ is the Neumann boundary function. If the finite element is * vector-valued, then obviously the function denoting the Neumann boundary * conditions needs to be vector-valued as well. * - * \item No other boundary conditions are considered. - * \end{itemize} + * @item No other boundary conditions are considered. + * @end{itemize} * The object describing the boundary conditions is obtained from the * triangulation. * diff --git a/deal.II/deal.II/include/numerics/histogram.h b/deal.II/deal.II/include/numerics/histogram.h index cf2d5f00f6..e808aa89b6 100644 --- a/deal.II/deal.II/include/numerics/histogram.h +++ b/deal.II/deal.II/include/numerics/histogram.h @@ -35,14 +35,14 @@ * @sect3{Ways to generate the intervals} * * At present, the following schemes for interval spacing are implemented: - * \begin{itemize} - * \item Linear spacing: The intervals are distributed in constant steps + * @begin{itemize} + * @item Linear spacing: The intervals are distributed in constant steps * between the minimum and maximum values of the data. - * \item Logaritmic spacing: The intervals are distributed in constant + * @item Logaritmic spacing: The intervals are distributed in constant * steps between the minimum and maximum values of the logs of the values. * This scheme is only useful if the data has only positive values. * Negative and zero values are sorted into the leftmost interval. - * \end{itemize} + * @end{itemize} * * To keep programs extendible, you can use the two functions * @p{get_interval_spacing_names} and @p{parse_interval_spacing}, which always diff --git a/deal.II/deal.II/include/numerics/matrices.h b/deal.II/deal.II/include/numerics/matrices.h index 95982c09bf..28d12b55bf 100644 --- a/deal.II/deal.II/include/numerics/matrices.h +++ b/deal.II/deal.II/include/numerics/matrices.h @@ -57,8 +57,8 @@ template class Equation; * @sect3{Supported matrices} * * At present there are functions to create the following matrices: - * \begin{itemize} - * \item @p{create_mass_matrix}: create the matrix with entries + * @begin{itemize} + * @item @p{create_mass_matrix}: create the matrix with entries * $m_{ij} = \int_\Omega \phi_i(x) \phi_j(x) dx$. Here, the $\phi_i$ * are the basis functions of the finite element space given. * This function uses the @p{MassMatrix} class. @@ -92,7 +92,7 @@ template class Equation; * parameters, you need to pass a function object representing the * respective number of components. * - * \item @p{create_laplace_matrix}: there are two versions of this; the + * @item @p{create_laplace_matrix}: there are two versions of this; the * one which takes the @p{Function} object creates * $a_{ij} = \int_\Omega a(x) \nabla\phi_i(x) \nabla\phi_j(x) dx$, * $a$ being the given function, while the other one assumes that @@ -104,7 +104,7 @@ template class Equation; * If the finite element in use presently has more than only one * component, this function may not be overly useful and presently * throws an error. - * \end{itemize} + * @end{itemize} * * All created matrices are `raw': they are not condensed, i.e. hanging * nodes are not eliminated. The reason is that you may want to add @@ -518,8 +518,8 @@ class MatrixTools : public MatrixCreator * * The useful use of this object is therefore probable one of the following * cases: - * \begin{itemize} - * \item Mass lumping: use an @p{Assembler} object and a special quadrature + * @begin{itemize} + * @item Mass lumping: use an @p{Assembler} object and a special quadrature * formula to voluntarily evaluate the mass matrix incorrect. For example * by using the trapezoidal formula, the mass matrix will become a * diagonal (at least if no hanging nodes are considered). However, there @@ -527,7 +527,7 @@ class MatrixTools : public MatrixCreator * scaling the diagonal elements of the unit matrix by the area element * of the respective cell. * - * \item Nonconstant coefficient: if the coefficient varies considerably over + * @item Nonconstant coefficient: if the coefficient varies considerably over * each element, there is no way around this class. However, there are many * cases where it is sufficient to assume that the function be constant on * each cell (taking on its mean value throughout the cell for example, or @@ -539,7 +539,7 @@ class MatrixTools : public MatrixCreator * if the density or other mechanical properties vary with the space * coordinate. * - * \item Simple plugging together of system matrices: if the system matrix has + * @item Simple plugging together of system matrices: if the system matrix has * the form $s_{ij} = m_{ij} + \alpha a_{ij}$, for example, with $M$ and * $A$ being the mass and laplace matrix, respectively (this matrix $S$ * occurs in the discretization of the heat and the wave equation, amoung @@ -550,7 +550,7 @@ class MatrixTools : public MatrixCreator * justifyable to quickly try something out. In the further process it * may be useful to replace this behaviour by more sophisticated methods, * however. - * \end{itemize} + * @end{itemize} */ template class MassMatrix : public Equation { diff --git a/deal.II/deal.II/include/numerics/solution_transfer.h b/deal.II/deal.II/include/numerics/solution_transfer.h index 951dd7bdff..d9067d437b 100644 --- a/deal.II/deal.II/include/numerics/solution_transfer.h +++ b/deal.II/deal.II/include/numerics/solution_transfer.h @@ -36,10 +36,10 @@ * coarsening is much more complicated to organize * (see further documentation below) than interpolation while pure refinement, * @p{SolutionTransfer} offers two possible usages. - * \begin{itemize} - * \item If the grid will only be purely refined + * @begin{itemize} + * @item If the grid will only be purely refined * (i.e. not locally coarsened) then use @p{SolutionTransfer} as follows - * \begin{verbatim} + * @begin{verbatim} * SolutionTransfer soltrans(*dof_handler); * soltrans.prepare_for_pure_refinement(); * // some refinement e.g. @@ -51,10 +51,10 @@ * // more functions * soltrans.refine_interpolate(sol2, interpolated_sol2); * ... - * \end{verbatim} - * \item If the grid will be coarsenend and refined + * @end{verbatim} + * @item If the grid will be coarsenend and refined * then use @p{SolutionTransfer} as follows - * \begin{verbatim} + * @begin{verbatim} * SolutionTransfer soltrans(*dof_handler); * // some refinement e.g. * tria->refine_and_coarsen_fixed_fraction(error_indicator, 0.3, 0.05); @@ -64,7 +64,7 @@ * tria->execute_coarsening_and_refinement (); * dof_handler->distribute_dofs (fe); * soltrans.interpolate(solution, interpolated_solution); - * \end{verbatim} + * @end{verbatim} * * Multiple calling of the function * @p{interpolate (const Vector &in, Vector &out)} @@ -74,7 +74,7 @@ * and using the respective @p{prepare_for_coarsening_and_refinement} function * taking several vectors as input before actually refining and coarsening the * triangulation (see there). - * \end{itemize} + * @end{itemize} * * For deleting all stored data in @p{SolutionTransfer} and reinitializing it * use the @p{clear()} function. @@ -88,8 +88,8 @@ * * @sect3{Implementation} * - * \begin{itemize} - * \item Solution transfer while pure refinement. Assume that we have got a + * @begin{itemize} + * @item Solution transfer while pure refinement. Assume that we have got a * solution vector on the current (original) grid. * Each entry of this vector belongs to one of the * DoFs of the discretisation. If we now refine the grid then the calling of @@ -110,7 +110,7 @@ * The @p{refine_interpolate(in,out)} function can be called multiplely for * arbitrary many discrete functions (solution vectors) on the original grid. * - * \item Solution transfer while coarsening and refinement. After + * @item Solution transfer while coarsening and refinement. After * calling @p{Triangulation::prepare_coarsening_and_refinement} the * coarsen flags of either all or none of the children of a * (father-)cell are set. While coarsening @@ -153,7 +153,7 @@ * of the @p{prepare_for_coarsening_and_refinement(all_in)} function. Hence * @p{interpolate(all_in, all_out)} can (in contrast to * @p{refine_interpolate(in, out)}) only be called once. - * \end{itemize} + * @end{itemize} * * @author Ralf Hartmann, 1999 */ diff --git a/deal.II/deal.II/include/numerics/time_dependent.h b/deal.II/deal.II/include/numerics/time_dependent.h index 63ab5416af..9cc5e757dc 100644 --- a/deal.II/deal.II/include/numerics/time_dependent.h +++ b/deal.II/deal.II/include/numerics/time_dependent.h @@ -70,7 +70,7 @@ * perform another sweep on these refined meshes. A total run will therefore * often be a sequence of several sweeps. The global setup therefore looks * like this: - * \begin{verbatim} + * @begin{verbatim} * for sweep=0 to n_sweeps-1 * { * for i=0 to n_timesteps-1 @@ -98,7 +98,7 @@ * notify timestep i of the end of the sweep, e.g. for cleanups, * deletion of temporary files, etc. * } - * \end{verbatim} + * @end{verbatim} * The user may specify that a loop shall run forward or backward (the latter * being needed for the solution of global dual problems, for example). * @@ -117,7 +117,7 @@ * data of the last two time steps, the following pseudocode described * what the centeral loop function of this class will do when we move * from timestep @p{n-1} to timestep @p{n}: - * \begin{verbatim} + * @begin{verbatim} * wake up timestep n+1 with signal 1 * wake up timestep n with signal 0 * do computation on timestep n @@ -126,7 +126,7 @@ * let timestep n-2 sleep with signal 2 * * move from n to n+1 - * \end{verbatim} + * @end{verbatim} * The signal number here denotes the distance of the timestep being sent * the signal to the timestep where computations are done on. The calls to * the @p{wake_up} and @p{sleep} functions with signal 0 could in principle @@ -148,14 +148,14 @@ * * From the given sketch above, it is clear that each time step object sees * the following sequence of events: - * \begin{verbatim} + * @begin{verbatim} * wake up with signal 1 * wake up signal 0 * do computation * sleep with signal 0 * sleep with signal 1 * sleep with signal 2 - * \end{verbatim} + * @end{verbatim} * This pattern is repeated for each loop in each sweep. * * For the different loops within each sweep, the numbers of timesteps @@ -180,7 +180,7 @@ * * The main loop of a program using this class will usually look like * the following one, taken modified from the wave program: - * \begin{verbatim} + * @begin{verbatim} * template * void TimeDependent_Wave::run_sweep (const unsigned int sweep_no) * { @@ -209,7 +209,7 @@ * for (unsigned int sweep=0; sweep::refine_grid} is a function taking an argument, unlike * all the other functions used above within the loops. However, in this special * case the parameter was the same for all timesteps and known before the loop @@ -293,7 +293,7 @@ * brevity we have omitted the parts that deal with backward running loops * as well as the checks whether wake-up and sleep operations act on timesteps * outside @p{0..n_timesteps-1}. - * \begin{verbatim} + * @begin{verbatim} * template * void TimeDependent::do_loop (InitFunctionObject init_function, * LoopFunctionObject loop_function, @@ -335,7 +335,7 @@ * for (int look_back=0; look_back<=timestepping_data.look_back; ++look_back) * timesteps[step-look_back]->sleep(look_back); * }; - * \end{verbatim} + * @end{verbatim} * * * @author Wolfgang Bangerth, 1999 @@ -485,10 +485,10 @@ class TimeDependent * * This mechanism usually will result * in a set-up loop like this - * \begin{verbatim} + * @begin{verbatim} * for (i=0; i::Flags /** * This structure is used to tell the @p{TimeStepBase_Tria} class how grids should * be refined. Before we explain all the different variables, fist some terminology: - * \begin{itemize} - * \item Correction: after having flagged some cells of the triangulation for + * @begin{itemize} + * @item Correction: after having flagged some cells of the triangulation for * following some given criterion, we may want to change the number of flagged * cells on this grid according to another criterion that the number of cells * may be only a certain fraction more or less then the number of cells on * the previous grid. This change of refinement flags will be called * "correction" in the sequel. - * \item Adaption: in order to make the change between one grid and the next not + * @item Adaption: in order to make the change between one grid and the next not * to large, we may want to flag some additional cells on one of the two * grids such that there are not too grave differences. This process will * be called "adaption". - * \end{itemize} + * @end{itemize} * * * @sect3{Description of flags} * - * \begin{itemize} - * \item @p{max_refinement_level}: Cut the refinement of cells at a given level. + * @begin{itemize} + * @item @p{max_refinement_level}: Cut the refinement of cells at a given level. * This flag does not influence the flagging of cells, so not more cells * on the coarser levels are flagged than usual. Rather, the flags are all * set, but when it comes to the actual refinement, the maximum refinement @@ -1486,7 +1486,7 @@ struct TimeStepBase_Tria::Flags * refinement with adaptive refinement when you don't want the latter * to refine more than the global refinement. * - * \item @p{first_sweep_with_correction}: When using cell number correction + * @item @p{first_sweep_with_correction}: When using cell number correction * as defined above, it may be worth while to start with this only in * later sweeps, not already in the first one. If this variable is * zero, then start with the first sweep, else with a higher one. The @@ -1495,18 +1495,18 @@ struct TimeStepBase_Tria::Flags * the sweeps where we start to be interested in the actual results of * the computations. * - * \item @p{min_cells_for_correction}: If we want a more free process of + * @item @p{min_cells_for_correction}: If we want a more free process of * grid development, we may want to impose less rules for grids with few * cells also. This variable sets a lower bound for the cell number of * grids where corrections are to be performed. * - * \item @p{cell_number_corridor_top}: Fraction of the number of cells by + * @item @p{cell_number_corridor_top}: Fraction of the number of cells by * which the number of cells of one grid may be higher than that on the * previous grid. Common values are 10 per cent (i.e. 0.1). The naming * of the variable results from the goal to define a target corridor * for the number of cells after refinement has taken place. * - * \item @p{cell_number_corridor_bottom}: Fraction of the number of cells by + * @item @p{cell_number_corridor_bottom}: Fraction of the number of cells by * which the number of cells of one grid may be lower than that on the * previous grid. Common values are 5 per cent (i.e. 0.05). Usually this * number will be smaller than @p{cell_number_corridor_top} since an @@ -1520,7 +1520,7 @@ struct TimeStepBase_Tria::Flags * direction is reversed, so the two values defining the cell number * corridor should be about equal. * - * \item @p{correction_relaxations}: This is a list of pairs of number with the + * @item @p{correction_relaxations}: This is a list of pairs of number with the * following meaning: just as for @p{min_cells_for_correction}, it may be * worth while to reduce the requirements upon grids if the have few cells. * The present variable stores a list of cell numbers along with some values @@ -1541,7 +1541,7 @@ struct TimeStepBase_Tria::Flags * can use as a default value. It is an empty list and thus defines no * relaxations. * - * \item @p{cell_number_correction_steps}: Usually, if you want the number of + * @item @p{cell_number_correction_steps}: Usually, if you want the number of * cells to be corrected, the target corridor for the cell number is computed * and some additional cells are flagged or flags are removed. But since * the cell number resulting after flagging and deflagging can not be @@ -1552,7 +1552,7 @@ struct TimeStepBase_Tria::Flags * regularly. Setting the variable to zero will result in no correction * steps at all. * - * \item @p{mirror_flags_to_previous_grid}: If a cell on the present grid is + * @item @p{mirror_flags_to_previous_grid}: If a cell on the present grid is * flagged for refinement, also flag the corresponding cell on the previous * grid. This is useful if, for example, error indicators are computed for * space-time cells, but are stored for the second grid only. Now, since the @@ -1560,7 +1560,7 @@ struct TimeStepBase_Tria::Flags * may be useful to flag both if necessary. This is done if the present * variable is set. * - * \item @p{adapt_grids}: adapt the present grid to the previous one in the sense + * @item @p{adapt_grids}: adapt the present grid to the previous one in the sense * defined above. What is actually done here is the following: if going from * the previous to the present grid would result in double refinement or * double coarsening of some cells, then we try to flag these cells for @@ -1574,7 +1574,7 @@ struct TimeStepBase_Tria::Flags * by looping iteratively through all grids, back and forth, until nothing * changes anymore, which is obviously impossible if there are many time steps * with very large grids. - * \end{itemize} + * @end{itemize} */ template struct TimeStepBase_Tria::RefinementFlags diff --git a/deal.II/deal.II/include/numerics/vectors.h b/deal.II/deal.II/include/numerics/vectors.h index 6fa410bfc6..3e010209b4 100644 --- a/deal.II/deal.II/include/numerics/vectors.h +++ b/deal.II/deal.II/include/numerics/vectors.h @@ -31,13 +31,13 @@ class ConstraintMatrix; /** * Denote which norm/integral is to be computed. The following possibilities * are implemented: - * \begin{itemize} - * \item @p{mean}: the function or difference of functions is integrated + * @begin{itemize} + * @item @p{mean}: the function or difference of functions is integrated * on each cell. - * \item @p{L1_norm}: the absolute value of the function is integrated. - * \item @p{L2_norm}: the square of the function is integrated on each + * @item @p{L1_norm}: the absolute value of the function is integrated. + * @item @p{L2_norm}: the square of the function is integrated on each * cell; afterwards the root is taken of this value. - * \end{itemize} + * @end{itemize} */ enum NormType { mean, @@ -60,8 +60,8 @@ enum NormType { * @sect3{Description of operations} * * This collection of methods offers the following operations: - * \begin{itemize} - * \item Interpolation: assign each degree of freedom in the vector to be + * @begin{itemize} + * @item Interpolation: assign each degree of freedom in the vector to be * created the value of the function given as argument. This is identical * to saying that the resulting finite element function (which is isomorphic * to the output vector) has exact function values in all off-points of @@ -82,7 +82,7 @@ enum NormType { * given function may be, taking into account that a virtual function has * to be called. * - * \item Projection: compute the $L_2$-projection of the given function onto + * @item Projection: compute the $L_2$-projection of the given function onto * the finite element space. This is done through the solution of the * linear system of equations $M v = f$ where $M$ is the mass matrix * $m_{ij} = \int_\Omega \phi_i(x) \phi_j(x) dx$ and @@ -142,19 +142,19 @@ enum NormType { * too efficient, but sufficient in many cases and simple to implement. This * detail may change in the future. * - * \item Creation of right hand side vectors: + * @item Creation of right hand side vectors: * The @p{create_right_hand_side} function computes the vector * $f_i = \int_\Omega f(x) \phi_i(x) dx$. This is the same as what the * @p{MatrixCreator::create_*} functions which take a right hand side do, * but without assembling a matrix. * - * \item Interpolation of boundary values: + * @item Interpolation of boundary values: * The @p{MatrixTools::apply_boundary_values} function takes a list * of boundary nodes and their values. You can get such a list by interpolation * of a boundary function using the @p{interpolate_boundary_values} function. * To use it, you have to * specify a list of pairs of boundary indicators (of type @p{unsigned char}; - * see the section in the documentation of the \Ref{Triangulation} class for more + * see the section in the documentation of the @ref{Triangulation} class for more * details) and the according functions denoting the dirichlet boundary values * of the nodes on boundary faces with this boundary indicator. * @@ -183,7 +183,7 @@ enum NormType { * index 1 in the map. The respective boundary functions are then evaluated at * the place of the respective boundary point. * - * \item Projection of boundary values: + * @item Projection of boundary values: * The @p{project_boundary_values} function acts similar to the * @p{interpolate_boundary_values} function, apart from the fact that it does * not get the nodal values of boundary nodes by interpolation but rather @@ -197,7 +197,7 @@ enum NormType { * solved using a simple CG method (without preconditioning), which is in most * cases sufficient for the present purpose. * - * \item Computing errors: + * @item Computing errors: * The function @p{integrate_difference} performs the calculation of the error * between the finite element solution and a given (continuous) reference * function in different norms. The integration is performed using a given @@ -255,7 +255,7 @@ enum NormType { * * For the global $H_1$ norm and seminorm, the same rule applies as for the * $L_2$ norm: compute the $l_2$ norm of the cell error vector. - * \end{itemize} + * @end{itemize} * * All functions use the finite element given to the @p{DoFHandler} object the last * time that the degrees of freedom were distributed over the triangulation. Also, diff --git a/deal.II/doc/development/writing-documentation.html b/deal.II/doc/development/writing-documentation.html index 10c249ffa8..880a93edc2 100644 --- a/deal.II/doc/development/writing-documentation.html +++ b/deal.II/doc/development/writing-documentation.html @@ -124,18 +124,18 @@

    In order to allow better structured output for long comments, we have extended kdoc to understand the following - tags inside comments (since they are LaTeX, they are understood by - the LaTeX output of Doc++ automatically): + tags inside comments, which are partly borrowed from LaTeX like + languages:

    • Itemized lists:

      By writing comments like the following,

       	   /**
      -	    * \begin{itemize}
      -	    *   \item foo
      -	    *   \item bar
      -	    * \end{itemize}
      +	    * @begin{itemize}
      +	    *   @item foo
      +	    *   @item bar
      +	    * @end{itemize}
       	    */
       	 
      you can get itemized lists both in the online and printed @@ -145,18 +145,24 @@
    • bar

    + +

    + Likewise, you can get numbered lists by using the tags + @begin{enumerate} and + @end{enumerate} along with @items. +

  • Verbatim output:

    If you write comments like this,

     	   /**
    -	    * \begin{verbatim}
    +	    * @begin{verbatim}
     	    *   void foobar ()
     	    *   {
     	    *     i = 0;
     	    *   };
    -	    * \end{verbatim}
    +	    * @end{verbatim}
     	    */
     	 
    you will get the lines between the verbatim environment with @@ -212,16 +218,7 @@ notably the example programs is not really supported, and we consider ways to convert them to SGML along with most other documentation, since SGML is readily convertible into many other - formats, for Postscript. -

    - -

    - Switching to SGML would also include replacing the LaTeX-like - layout extensions described above by their DocBook SGML - alikes. However, since this is not imminent, you need not care - about this at present. However, if you have spare time to pass, it - would be a valuable goal to invent a way to, for example, convert - the example programs to DocBook SGML. + formats, for example Postscript.

    diff --git a/deal.II/lac/include/lac/full_matrix.h b/deal.II/lac/include/lac/full_matrix.h index fd574f84d5..b7e9af2998 100644 --- a/deal.II/lac/include/lac/full_matrix.h +++ b/deal.II/lac/include/lac/full_matrix.h @@ -546,7 +546,7 @@ class FullMatrix : public Subscriptor * when the function exits. * * You should be aware that this function - * may produce {\bf large} amounts of + * may produce @em{large} amounts of * output if applied to a large matrix! * Be careful with it. */ diff --git a/deal.II/lac/include/lac/precondition.h b/deal.II/lac/include/lac/precondition.h index a12d0783a5..d2e934e2bf 100644 --- a/deal.II/lac/include/lac/precondition.h +++ b/deal.II/lac/include/lac/precondition.h @@ -67,14 +67,14 @@ class PreconditionIdentity * @sect3{Use} * You will usually not want to create a named object of this type, * although possible. The most common use is like this: - * \begin{verbatim} + * @begin{verbatim} * SolverGMRES, * Vector > gmres(control,memory,500); * * gmres.solve (matrix, solution, right_hand_side, * PreconditionUseMatrix,Vector > * (matrix,&SparseMatrix::template precondition_Jacobi)); - * \end{verbatim} + * @end{verbatim} * This creates an unnamed object to be passed as the fourth parameter to * the solver function of the @p{SolverGMRES} class. It assumes that the * @p{SparseMatrix} class has a function @p{precondition_Jacobi} taking two @@ -85,12 +85,12 @@ class PreconditionIdentity * * Note that due to the default template parameters, the above example * could be written shorter as follows: - * \begin{verbatim} + * @begin{verbatim} * ... * gmres.solve (matrix, solution, right_hand_side, * PreconditionUseMatrix<> * (matrix,&SparseMatrix::template precondition_Jacobi)); - * \end{verbatim} + * @end{verbatim} * * @author Guido Kanschat, Wolfgang Bangerth, 1999 */ diff --git a/deal.II/lac/include/lac/precondition_selector.h b/deal.II/lac/include/lac/precondition_selector.h index b186150418..81167f6e42 100644 --- a/deal.II/lac/include/lac/precondition_selector.h +++ b/deal.II/lac/include/lac/precondition_selector.h @@ -33,7 +33,7 @@ * * @sect3{Usage} * The simplest use of this class is the following: - * \begin{verbatim} + * @begin{verbatim} * // generate a @p{SolverControl} and * // a @p{VectorMemory} * SolverControl control; @@ -51,9 +51,9 @@ * // call the @p{solve} function with this * // preconditioning as last argument * solver.solve(A,x,b,preconditioning); - * \end{verbatim} + * @end{verbatim} * The same example where also the @p{SolverSelector} class is used reads - * \begin{verbatim} + * @begin{verbatim} * // generate a @p{SolverControl} and * // a @p{VectorMemory} * SolverControl control; @@ -69,7 +69,7 @@ * preconditioning.use_matrix(A); * * solver_selector.solve(A,x,b,preconditioning); - * \end{verbatim} + * @end{verbatim} * Now the use of the @p{SolverSelector} in combination with the @p{PreconditionSelector} * allows the user to select both, the solver and the preconditioner, at the * beginning of his program and each time the diff --git a/deal.II/lac/include/lac/solver.h b/deal.II/lac/include/lac/solver.h index a245f31b1f..9f783b3669 100644 --- a/deal.II/lac/include/lac/solver.h +++ b/deal.II/lac/include/lac/solver.h @@ -39,7 +39,7 @@ class SolverControl; * class, they are rather intended to form a `signature' which a concrete * class has to conform to. * - * \begin{verbatim} + * @begin{verbatim} * class Matrix * { * public: @@ -95,7 +95,7 @@ class SolverControl; * void equ (double a, const Vector& x, * double b, const Vector& z); * }; - * \end{verbatim} + * @end{verbatim} * * * @sect3{AdditionalData} @@ -109,7 +109,7 @@ class SolverControl; * an argument as a default @p{AdditionalData} is set by default. * * Now the generating of a solver looks like - * \begin{verbatim} + * @begin{verbatim} * // GMRES with 50 tmp vectors * SolverGMRES solver_gmres (solver_control, vector_memory, * SolverGMRES::AdditionalData(50)); @@ -120,7 +120,7 @@ class SolverControl; * * // CG with default AdditionalData * SolverCG solver_cg (solver_control, vector_memory); - * \end{verbatim} + * @end{verbatim} * * Using a unified constructor parameter list for all solvers was introduced when the * @p{SolverSelector} class was written; the unified interface enabled us to use this diff --git a/deal.II/lac/include/lac/solver_control.h b/deal.II/lac/include/lac/solver_control.h index e8ff1b7ac2..5186620fcd 100644 --- a/deal.II/lac/include/lac/solver_control.h +++ b/deal.II/lac/include/lac/solver_control.h @@ -41,14 +41,14 @@ class ParameterHandler; * solver is in. * * The possible values of State are - * \begin{itemize} - * \item @p{iterate = 0}: continue the iteration. - * \item @p{success}: the goal is reached, the iterative method can terminate + * @begin{itemize} + * @item @p{iterate = 0}: continue the iteration. + * @item @p{success}: the goal is reached, the iterative method can terminate * successfully. - * \item @p{failure}: the iterative method should stop because convergence + * @item @p{failure}: the iterative method should stop because convergence * could not be achieved or at least was not achieved within the given * maximal number of iterations. - * \end{itemize} + * @end{itemize} */ class SolverControl : public Subscriptor { diff --git a/deal.II/lac/include/lac/solver_selector.h b/deal.II/lac/include/lac/solver_selector.h index b80618209b..bcf138ff7d 100644 --- a/deal.II/lac/include/lac/solver_selector.h +++ b/deal.II/lac/include/lac/solver_selector.h @@ -34,7 +34,7 @@ * * @sect3{Usage} * The simplest use of this class is the following: - * \begin{verbatim} + * @begin{verbatim} * // generate a @p{SolverControl} and * // a @p{VectorMemory} * SolverControl control; @@ -52,26 +52,26 @@ * // call the @p{solve} function with this * // preconditioning as last argument * solver_selector.solve(A,x,b,preconditioning); - * \end{verbatim} + * @end{verbatim} * But the full usefulness of the @p{SolverSelector} class is not * clear until the presentation of the following example that assumes * the user using the @p{ParameterHandler} class and having declared a * "solver" entry, e.g. with - * \begin{verbatim} + * @begin{verbatim} * Parameter_Handler prm; * prm.declare_entry ("solver", "none", * Patterns::Sequence(SolverSelector::get_solver_names())); * ... - * \end{verbatim} + * @end{verbatim} * Assuming that in the users parameter file there exists the line - * \begin{verbatim} + * @begin{verbatim} * set solver = cg - * \end{verbatim} + * @end{verbatim} * then `Line 3' of the above example reads - * \begin{verbatim} + * @begin{verbatim} * SolverSelector, Vector > * solver_selector(prm.get("solver"), control, memory); - * \end{verbatim} + * @end{verbatim} * * * If at some time there exists a new solver "xyz" then the user does not need diff --git a/deal.II/lac/include/lac/sparse_ilu.h b/deal.II/lac/include/lac/sparse_ilu.h index e2631e9e29..ef14099b0c 100644 --- a/deal.II/lac/include/lac/sparse_ilu.h +++ b/deal.II/lac/include/lac/sparse_ilu.h @@ -26,7 +26,7 @@ * * The algorithm used by this class is as follows (indices run from @p{0} * to @p{N-1}): - * \begin{verbatim} + * @begin{verbatim} * copy original matrix into a[i,j] * * for i=1..N-1 @@ -38,7 +38,7 @@ * for j=k+1..N-1 * if (a[i,j] exists & a[k,j] exists) * a[i,j] -= a[i,k] * a[k,j] - * \end{verbatim} + * @end{verbatim} * Using this algorithm, we store the decomposition as a sparse matrix, for * which the user has to give a sparsity pattern and which is why this * class is derived from the @p{SparseMatrix}. Since it is not a matrix in @@ -73,14 +73,14 @@ * matrix, you can do so by calling the solver function using the following * sequence, for example (@p{ilu_sparsity} is some sparsity pattern to be used * for the decomposition, which you have to create beforehand): - * \begin{verbatim} + * @begin{verbatim} * SparseILU ilu (ilu_sparsity); * ilu.decompose (global_matrix); * * somesolver.solve (A, x, f, * PreconditionUseMatrix,Vector > * (ilu,&SparseILU::template apply_decomposition)); - * \end{verbatim} + * @end{verbatim} * * * @sect2{On template instantiations} diff --git a/deal.II/lac/include/lac/sparse_matrix.h b/deal.II/lac/include/lac/sparse_matrix.h index 7c8f1e4c31..228d1a463f 100644 --- a/deal.II/lac/include/lac/sparse_matrix.h +++ b/deal.II/lac/include/lac/sparse_matrix.h @@ -637,7 +637,7 @@ class SparseMatrix : public Subscriptor * integers. * * This function - * may produce {\bf large} amounts of + * may produce @em{large} amounts of * output if applied to a large matrix! * Be careful with it. */ diff --git a/deal.II/lac/include/lac/sparse_vanka.h b/deal.II/lac/include/lac/sparse_vanka.h index 533687942a..5213b4102a 100644 --- a/deal.II/lac/include/lac/sparse_vanka.h +++ b/deal.II/lac/include/lac/sparse_vanka.h @@ -82,7 +82,7 @@ template class Vector; * This little example is taken from a program doing parameter optimization. * The Lagrange multiplier is the third component of the finite element * used. The system is solved by the GMRES method. - * \begin{verbatim} + * @begin{verbatim} * // tag the Lagrange multiplier variable * vector signature(3); * signature[0] = signature[1] = false; @@ -102,7 +102,7 @@ template class Vector; * // solve * gmres.solve (global_matrix, solution, right_hand_side, * vanka); - * \end{verbatim} + * @end{verbatim} * * * @sect4{Implementor's remark} @@ -395,8 +395,8 @@ class SparseVanka * blocks equals the interval @p{[0,N)}, where @p{N} is the number of * degrees of freedom of the system of equations. * - * \begin{itemize} - * \item @p{index_intervals}: + * @begin{itemize} + * @item @p{index_intervals}: * Here, we chose the blocks to be intervals @p{[a_i,a_{i+1})}, * i.e. consecutive degrees of freedom are usually also within the * same block. This is a reasonable strategy, if the degrees of @@ -424,7 +424,7 @@ class SparseVanka * preconditioner useless if the degrees of freedom are numbered by * component, i.e. all Lagrange multipliers en bloc. * - * \item @p{adaptive}: This strategy is a bit more clever in cases where + * @item @p{adaptive}: This strategy is a bit more clever in cases where * the Langrange DoFs are clustered, as in the example above. It * works as follows: it first groups the Lagrange DoFs into blocks, * using the same strategy as above. However, instead of grouping @@ -446,7 +446,7 @@ class SparseVanka * does not differ much. However, unlike the first strategy, the * performance of the second strategy does not deteriorate if the * DoFs are renumbered by component. - * \end{itemize} + * @end{itemize} * * * @sect3{Typical results} @@ -459,14 +459,14 @@ class SparseVanka * @p{SparseBlockVanka} with @p{n_blocks==1}), the following numbers of * iterations is needed to solver the linear system in each nonlinear * step: - * \begin{verbatim} + * @begin{verbatim} * 101 68 64 53 35 21 - * \end{verbatim} + * @end{verbatim} * * With four blocks, we need the following numbers of iterations - * \begin{verbatim} + * @begin{verbatim} * 124 88 83 66 44 28 - * \end{verbatim} + * @end{verbatim} * As can be seen, more iterations are needed. However, in terms of * computing time, the first version needs 72 seconds wall time (and * 79 seconds CPU time, which is more than wall time since some other diff --git a/deal.II/lac/include/lac/sparsity_pattern.h b/deal.II/lac/include/lac/sparsity_pattern.h index b6d579cd5c..47f051de02 100644 --- a/deal.II/lac/include/lac/sparsity_pattern.h +++ b/deal.II/lac/include/lac/sparsity_pattern.h @@ -28,7 +28,7 @@ template class SparseMatrix; * The following picture will illustrate the relation between the * @p{SparsityPattern} an the @p{SparseMatrix}. * - * \begin{verbatim} + * @begin{verbatim} * SparsityPattern: \ * | * _________________________ | @@ -58,9 +58,9 @@ template class SparseMatrix; * /_________colnums[0] | * | * / - * \end{verbatim} + * @end{verbatim} * - * \begin{verbatim} + * @begin{verbatim} * For row = 0 * * it exists: (0| 3) = colnums[0] @@ -74,9 +74,9 @@ template class SparseMatrix; * (1| 4) = colnums[5] * .... * - * \end{verbatim} + * @end{verbatim} * - * \begin{verbatim} + * @begin{verbatim} * SparseMatrix: \ * | * _____________________________ | @@ -85,7 +85,7 @@ template class SparseMatrix; * | * | * / - * \end{verbatim} + * @end{verbatim} * * If you want to get the @p{3} you need to get its position in the * table above and its value by returning the value of the element on diff --git a/tests/deal.II/wave-test-3.cc b/tests/deal.II/wave-test-3.cc index f596a461ef..785d860baf 100644 --- a/tests/deal.II/wave-test-3.cc +++ b/tests/deal.II/wave-test-3.cc @@ -1224,127 +1224,127 @@ template class EvaluationBase; * * \subsection{Subsection #Grid#} * \begin{itemize} - * \item #Coarse mesh#: Names a grid to be taken as a coarse grid. The following + * @item #Coarse mesh#: Names a grid to be taken as a coarse grid. The following * names are allowed: * \begin{itemize} - * \item #uniform channel#: The domain is $[0,3]\times[0,1]$, triangulated + * @item #uniform channel#: The domain is $[0,3]\times[0,1]$, triangulated * by three cells. Left and right boundary are of Dirichlet type, top * and bottom boundary are of homogeneous Neumann type. - * \item #split channel bottom#: As above, but the lower half is refined once + * @item #split channel bottom#: As above, but the lower half is refined once * more than the top half. - * \item #split channel {left | right}#: Same as #uniform channel#, but with + * @item #split channel {left | right}#: Same as #uniform channel#, but with * cells on the left or right, according to the last word, more refined * than on the other side. - * \item #square#: $[-1,1]\times[-1,1]$. - * \item #seismic square#: same as #square#, but with Neumann boundary + * @item #square#: $[-1,1]\times[-1,1]$. + * @item #seismic square#: same as #square#, but with Neumann boundary * at top. - * \item #temperature-square#: Square with size $400,000,000$ (we use the + * @item #temperature-square#: Square with size $400,000,000$ (we use the * cgs system, so this amounts to 4000 km). - * \item #temperature-testcase#: As above, but with a sequence of + * @item #temperature-testcase#: As above, but with a sequence of * continuously growing cells set atop to avoid the implementation of * absorbing boundary conditions. The left boundary is of Neumann * type (mirror boundary). - * \item #random#: Unit square, but randomly refined to test for correctness + * @item #random#: Unit square, but randomly refined to test for correctness * of the time stepping scheme. - * \item #earth#: Circle with radius 6371 (measured in km). - * \end{itemize} - * \item #Initial refinement#: States how often the grid named by the above + * @item #earth#: Circle with radius 6371 (measured in km). + * @begin{itemize} + * @item #Initial refinement#: States how often the grid named by the above * parameter shall be globally refined to form the coarse mesh. - * \item #Maximum refinement#: maximum refinement level a cell may attain. + * @item #Maximum refinement#: maximum refinement level a cell may attain. * Cells with such a refinement level are flagged as others are, but they * are not refined any more; it is therefore not necessary to lower the * fraction of cells to be refined in order to avoid the refinement of a * similar number of cells with a lower level number. * * The default to this value is zero, meaning no limit. - * \item #Refinement fraction#: Upon refinement, those cells are refined which + * @item #Refinement fraction#: Upon refinement, those cells are refined which * together make up for a given fraction of the total error. This parameter * gives that fraction. Default is #0.95#. - * \item #Coarsening fraction#: Similar as above, gives the fraction of the + * @item #Coarsening fraction#: Similar as above, gives the fraction of the * total error for which the cells shall be coarsened. Default is #0.03#. - * \item #Top cell number deviation#: Denotes a fraction by which the number of + * @item #Top cell number deviation#: Denotes a fraction by which the number of * cells on a time level may be higher than the number of cells on the * previous time level. This and the next two parameters help to avoid * to much differing grids on the time levels and try to smooth the numbers * of cells as a function of time. The default value is #0.1#. - * \item #Bottom cell number deviation#: Denotes the fraction by which the + * @item #Bottom cell number deviation#: Denotes the fraction by which the * number of cells on a time level may be lower than on the previous time * level. Default is #0.03#. - * \item #Cell number correction steps#: Usually, the goal denoted by the two + * @item #Cell number correction steps#: Usually, the goal denoted by the two * parameters above cannot be reached directly because the number of cells * is modified by grid regularization etc. The goal can therefore only be * reached by an iterative process. This parameter tells how many iterations * of this process shall be done. Default is #2#. - * \end{itemize} + * @begin{itemize} * * \subsection{Subsection #Equation data#} * \begin{itemize} - * \item #Coefficient#: Names for the different coefficients for the Laplace + * @item #Coefficient#: Names for the different coefficients for the Laplace * like part of the wave operator. Allowed values are: * \begin{itemize} - * \item #unit#: Constant one. - * \item #kink#: One for $y<\frac 13$, 4 otherwise. - * \item #gradient#: $1+8*y^2$. - * \item #tube#: $0.2$ for $|x|<0.2$, one otherwise. - * \item #temperature VAL81#: Coefficient computed from the temperature + * @item #unit#: Constant one. + * @item #kink#: One for $y<\frac 13$, 4 otherwise. + * @item #gradient#: $1+8*y^2$. + * @item #tube#: $0.2$ for $|x|<0.2$, one otherwise. + * @item #temperature VAL81#: Coefficient computed from the temperature * field given by Varnazza, Avrett, Loeser 1981. - * \item #temperature kolmogorov#: Broadened temperature spectrum. - * \item #temperature undisturbed#: Quiet atmosphere. - * \item #temperature monochromatic 20s#: Temperature as computed with + * @item #temperature kolmogorov#: Broadened temperature spectrum. + * @item #temperature undisturbed#: Quiet atmosphere. + * @item #temperature monochromatic 20s#: Temperature as computed with * shock waves with $T=20s$. - * \item #temperature monochromatic 40s#: Temperature as computed with + * @item #temperature monochromatic 40s#: Temperature as computed with * shock waves with $T=40s$. - * \end{itemize} - * \item #Initial u#: Names for the initial value for the amplitude. Allowed + * @begin{itemize} + * @item #Initial u#: Names for the initial value for the amplitude. Allowed * names are: * \begin{itemize} - * \item #zero#: $u_0=0$. - * \item #eigenmode#: $u_0=sin(2\pi x)sin(2\pi y)$. - * \item #bump#: $u_0=(1-\frac{\vec x^2}{a^2})e^{-\frac{\vec x^2}{a^2}}$ + * @item #zero#: $u_0=0$. + * @item #eigenmode#: $u_0=sin(2\pi x)sin(2\pi y)$. + * @item #bump#: $u_0=(1-\frac{\vec x^2}{a^2})e^{-\frac{\vec x^2}{a^2}}$ * for $|\vec x| class WaveParameters -- 2.39.5