From: wolf Date: Tue, 23 May 2006 15:15:51 +0000 (+0000) Subject: Use @< and @> instead of plain < and > and letting program2doxygen fix this up. This... X-Git-Url: https://gitweb.dealii.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=4df990c7055d476b496b89732f94212ae1934f6d;p=dealii-svn.git Use @< and @> instead of plain < and > and letting program2doxygen fix this up. This is so that we can actually use < and > in formulas, or as html tags git-svn-id: https://svn.dealii.org/trunk@13130 0785d39b-7218-0410-832d-ea1e28bc413d --- diff --git a/deal.II/examples/step-1/step-1.cc b/deal.II/examples/step-1/step-1.cc index 5ed263f2c8..2915e1ac35 100644 --- a/deal.II/examples/step-1/step-1.cc +++ b/deal.II/examples/step-1/step-1.cc @@ -52,14 +52,14 @@ void first_grid () // two-dimensional domain: Triangulation<2> triangulation; // Here and in many following - // cases, the string "<2>" after a + // cases, the string "@<2@>" after a // class name indicates that this // is an object that shall work in // two space dimensions. Likewise, // there are versions of the // triangulation class that are - // working in one ("<1>") and three - // ("<3>") space dimensions. The + // working in one ("@<1@>") and three + // ("@<3@>") space dimensions. The // way this works is through some // template magic that we will // investigate in some more detail @@ -218,8 +218,8 @@ void second_grid () // time getting the program // to also run in 3d: we only // have to change all - // occurrences of ``<2>'' to - // ``<3>'', and do not have + // occurrences of ``@<2@>'' to + // ``@<3@>'', and do not have // to audit our code for the // hidden appearance of magic // numbers like a 4 that diff --git a/deal.II/examples/step-11/step-11.cc b/deal.II/examples/step-11/step-11.cc index fb0ae9afcd..4f1c21305e 100644 --- a/deal.II/examples/step-11/step-11.cc +++ b/deal.II/examples/step-11/step-11.cc @@ -442,7 +442,7 @@ void LaplaceProblem::assemble_and_solve () // of Gauss-r is 2r, and the order // of the boundary approximation // using polynomials of degree p is - // p+1, we know that 2r>=p+1. Since + // p+1, we know that 2r@>=p+1. Since // r has to be an integer and (as // mentioned above) has to be at // least 2, this makes up for the @@ -662,7 +662,7 @@ int main () // mappings of linear through // cubic mappings. Note that // since we need the object of - // type ``LaplaceProblem<2>'' + // type ``LaplaceProblem@<2@>'' // only once, we do not even // name it, but create an // unnamed such object and call diff --git a/deal.II/examples/step-12/step-12.cc b/deal.II/examples/step-12/step-12.cc index a053480287..755dcbaeb5 100644 --- a/deal.II/examples/step-12/step-12.cc +++ b/deal.II/examples/step-12/step-12.cc @@ -116,7 +116,7 @@ class BoundaryValues: public Function // class as we prefer to get function // values of type ``Point'' rather // than of type - // ``Vector''. This, because + // ``Vector@''. This, because // there exist scalar products // between ``Point'' and ``Point'' as // well as between ``Point'' and @@ -941,7 +941,7 @@ void DGMethod::assemble_system1 () // neighbors of the // neighboring // cell. Hence, - // neighbor->neighbor(neighbor2) + // neighbor-@>neighbor(neighbor2) // equals the // current cell // ``cell''. @@ -1046,7 +1046,7 @@ void DGMethod::assemble_system1 () ue_vi_matrix(i,k)); } // End of ``if - // (face->has_children())'' + // (face-@>has_children())'' } else { @@ -1091,9 +1091,9 @@ void DGMethod::assemble_system1 () ui_vi_matrix, ue_vi_matrix); // End of ``if - // (neighbor->level() + // (neighbor-@>level() // == - // cell->level())'' + // cell-@>level())'' } else { diff --git a/deal.II/examples/step-13/step-13.cc b/deal.II/examples/step-13/step-13.cc index f0f9079cfb..4dab4ca04e 100644 --- a/deal.II/examples/step-13/step-13.cc +++ b/deal.II/examples/step-13/step-13.cc @@ -382,7 +382,7 @@ namespace Evaluation // by a statement like // ``Assert // (dof_handler.get_fe().dofs_per_vertex - // > 0, + // @> 0, // ExcNotImplemented())'', // which should make it // quite clear what is @@ -395,7 +395,7 @@ namespace Evaluation // that that does not // hurt here, since the // statement - // ``cell->vertex_dof_index(vertex,0)'' + // ``cell-@>vertex_dof_index(vertex,0)'' // would fail if we asked // it to give us the DoF // index of a vertex if @@ -652,7 +652,7 @@ namespace Evaluation // passed as second argument. // // Also note that we have to prefix - // ``this->'' to access a member + // ``this-@>'' to access a member // variable of the template // dependent base class. The reason // here, and further down in the @@ -1625,7 +1625,7 @@ namespace LaplaceSolver // The first, doing global // refinement, is rather simple: // its main function just calls - // ``triangulation->refine_global + // ``triangulation-@>refine_global // (1);'', which does all the work. // // Note that since the ``Base'' diff --git a/deal.II/examples/step-14/step-14.cc b/deal.II/examples/step-14/step-14.cc index ec822783c7..0d2c5a7166 100644 --- a/deal.II/examples/step-14/step-14.cc +++ b/deal.II/examples/step-14/step-14.cc @@ -789,7 +789,7 @@ namespace LaplaceSolver // of freedom of the primal solver, // we would have to indicate this // like so: - // ``PrimalSolver::n_dofs()''. + // ``PrimalSolver@::n_dofs()''. // However, the compiler does not // accept this since the ``n_dofs'' // function is actually from a base @@ -1251,7 +1251,7 @@ namespace LaplaceSolver // get all that characterizes the // curved ridge solution, we would // simply generate an instance of - // ``Data::SetUp'', + // ``Data::SetUp@'', // and everything we need to know // about the solution would be static // member variables and functions of @@ -1737,10 +1737,10 @@ namespace Data // is a worthwhile strategy. Other // possibilities for special cases // are to derive from - // ``Data::SetUp'' where + // ``Data::SetUp@'' where // ``SomeSetUp'' denotes a class, or // even to explicitly specialize - // ``Data::SetUp''. The + // ``Data::SetUp@''. The // latter allows to transparently use // the way the ``SetUp'' class is // used for other set-ups, but with @@ -3975,7 +3975,7 @@ int main () // take here the description of // ``Exercise_2_3'', but you // can also use - // ``CurvedRidges'': + // ``CurvedRidges@'': descriptor.data = new Data::SetUp,dim> (); // Next set first a dual diff --git a/deal.II/examples/step-15/step-15.cc b/deal.II/examples/step-15/step-15.cc index 5e1f4c5b97..d602acd41e 100644 --- a/deal.II/examples/step-15/step-15.cc +++ b/deal.II/examples/step-15/step-15.cc @@ -52,9 +52,9 @@ // The first thing we have here is a helper - // function that computes an even power |v|^n - // of a vector ``v'', by evaluating - // (v*v)^(n/2). We need this in the + // function that computes an even power $|v|^n$ + // of a vector $v$, by evaluating + // $(v\cdot v)^{n/2}. We need this in the // computations below where we do not want to // dwell on the fact that the gradient of the // solution is actually a scalar in the 1d @@ -106,7 +106,7 @@ double gradient_power (const Tensor<1,dim> &v, // i.e. it has a member operator that returns // for a given point the value of the // function. The value we return is a random - // perturbation of the ``x^1/3'' function + // perturbation of the $x^{1/3}$ function // which we know is the optimal solution in a // larger function space. To make things a // little simpler on the optimizer, we return @@ -130,7 +130,7 @@ class InitializationValues : public Function<1> // So here comes the function that implements // the function object. The ``base'' value is - // ``x^1/3'', while ``random'' is a random + // $x^{1/3}$, while ``random'' is a random // number between -1 and 1 (note that // ``rand()'' returns a random integer value // between zero and ``RAND_MAX''; to convert @@ -395,7 +395,7 @@ void MinimizationProblem::assemble_step () // quadrature point. In addition, we need // to have the coordinate values of each // quadrature point in real space for the - // ``x-u^3'' terms; to get these from the + // $x-u^3$ terms; to get these from the // ``FEValues'' object, we need to pass it // the ``update_q_points'' flag. // @@ -492,7 +492,7 @@ void MinimizationProblem::assemble_step () // quadrature point, as well as the // location in real space of this // quadrature point, and of the - // expression (x-u^3), since it + // expression $x-u^3$, since it // appears so often: const double u = local_solution_values[q_point], x = fe_values.quadrature_point(q_point)(0); @@ -1148,7 +1148,7 @@ void MinimizationProblem<1>::refine_grid () // situations, the library will silently // also have to refine the neighbor cell // once. It does so by calling the - // ``Triangulation::prepare_coarsening_and_refinement'' + // ``Triangulation@::prepare_coarsening_and_refinement'' // function before actually doing the // refinement and coarsening. This function // flags a set of additional cells for diff --git a/deal.II/examples/step-16/step-16.cc b/deal.II/examples/step-16/step-16.cc index 1e2de26497..7f96f4f705 100644 --- a/deal.II/examples/step-16/step-16.cc +++ b/deal.II/examples/step-16/step-16.cc @@ -268,10 +268,10 @@ void LaplaceProblem::assemble_system () }; // Again use zero boundary values: -// std::map boundary_values; +// std::map@ boundary_values; // VectorTools::interpolate_boundary_values (mg_dof_handler, // 0, -// ZeroFunction(), +// ZeroFunction@(), // boundary_values); // MatrixTools::apply_boundary_values (boundary_values, // system_matrix, @@ -357,10 +357,10 @@ void LaplaceProblem::assemble_multigrid () }; // Again use zero boundary values: -// std::map boundary_values; +// std::map@ boundary_values; // VectorTools::interpolate_boundary_values (mg_dof_handler, // 0, -// ZeroFunction(), +// ZeroFunction@(), // boundary_values); // MatrixTools::apply_boundary_values (boundary_values, // system_matrix, diff --git a/deal.II/examples/step-18/step-18.cc b/deal.II/examples/step-18/step-18.cc index 5dd32a5d2b..52f81117b8 100644 --- a/deal.II/examples/step-18/step-18.cc +++ b/deal.II/examples/step-18/step-18.cc @@ -2323,7 +2323,7 @@ namespace QuasiStaticElasticity // function. First, how we get the // displacement field at a given vertex // using the - // ``cell->vertex_dof_index(v,d)'' function + // ``cell-@>vertex_dof_index(v,d)'' function // that returns the index of the ``d''th // degree of freedom at vertex ``v'' of the // given cell. In the present case, @@ -2410,9 +2410,9 @@ namespace QuasiStaticElasticity // the number of a vertex once it has come // into existence, even if vertices with // lower number go away. Secondly, the - // location returned by ``cell->vertex(v)'' + // location returned by ``cell-@>vertex(v)'' // is not only a read-only object of type - // ``Point'', but in fact a reference + // ``Point@'', but in fact a reference // that can be written to. This allows to // move around the nodes of a mesh with // relative ease, but it is worth pointing diff --git a/deal.II/examples/step-20/step-20.cc b/deal.II/examples/step-20/step-20.cc index 7e95e170fb..d9f151f570 100644 --- a/deal.II/examples/step-20/step-20.cc +++ b/deal.II/examples/step-20/step-20.cc @@ -140,7 +140,7 @@ class MixedLaplaceProblem // one, and ``dim+1'' components, // respectively, and that we pass the // number of components down to the - // ``Function'' base class. For + // ``Function@'' base class. For // the exact solution, we only // declare the function that actually // returns the entire solution vector @@ -417,7 +417,7 @@ double extract_p (const FEValuesBase &fe_values, // its base elements, with the way we // have done so in step-8: there, we // have built it as ``fe - // (FE_Q(1), dim)'', i.e. we + // (FE_Q@(1), dim)'', i.e. we // have simply used ``dim'' copies of // the ``FE_Q(1)'' element, one copy // for the displacement in each @@ -1007,7 +1007,7 @@ void SchurComplement::vmult (Vector &dst, // and preconditioner system is the // class that approximates the Schur // complement so we can form a - // ``InverseMatrix'' + // ``InverseMatrix@'' // object that approximates the // inverse of the Schur // complement. It follows the same @@ -1227,7 +1227,7 @@ void MixedLaplaceProblem::compute_errors () const // quadrature. This actually // presents a slight twist here: if // we naively chose an object of - // type ``QGauss(degree+1)'' + // type ``QGauss@(degree+1)'' // as one may be inclined to do // (this is what we used for // integrating the linear system), diff --git a/deal.II/examples/step-21/step-21.cc b/deal.II/examples/step-21/step-21.cc index 51b0c453d0..e4dafe6f06 100644 --- a/deal.II/examples/step-21/step-21.cc +++ b/deal.II/examples/step-21/step-21.cc @@ -135,7 +135,7 @@ class BoundaryValues: public Function // class as we prefer to get function // values of type ``Point'' rather // than of type - // ``Vector''. This, because + // ``Vector@''. This, because // there exist scalar products // between ``Point'' and ``Point'' as // well as between ``Point'' and @@ -969,7 +969,7 @@ void DGMethod::assemble_system1 () // neighbors of the // neighboring // cell. Hence, - // neighbor->neighbor(neighbor2) + // neighbor-@>neighbor(neighbor2) // equals the // current cell // ``cell''. @@ -1090,7 +1090,7 @@ void DGMethod::assemble_system1 () un_v_matrix(i,k)); } // End of ``if - // (face->has_children())'' + // (face-@>has_children())'' } else { @@ -1143,9 +1143,9 @@ void DGMethod::assemble_system1 () u_v_matrix, un_v_matrix); // End of ``if - // (neighbor->level() + // (neighbor-@>level() // == - // cell->level())'' + // cell-@>level())'' } else { diff --git a/deal.II/examples/step-3/step-3.cc b/deal.II/examples/step-3/step-3.cc index 3d9991a818..a00e322675 100644 --- a/deal.II/examples/step-3/step-3.cc +++ b/deal.II/examples/step-3/step-3.cc @@ -558,7 +558,7 @@ void LaplaceProblem::assemble_system () // fe_values.shape_grad(i,q_point); // this gradient is a 2-dimensional // vector (in fact it is of type - // Tensor<1,dim>, with here dim=2) and + // Tensor@<1,dim@>, with here dim=2) and // the product of two such vectors is // the scalar product, i.e. the product // of the two shape_grad function calls @@ -771,8 +771,8 @@ void LaplaceProblem::solve () // of the vectors, but the empty angle // brackets indicate that we simply take // the default arguments (which are - // ``SparseMatrix'' and - // ``Vector''): + // ``SparseMatrix@'' and + // ``Vector@''): SolverCG<> cg (solver_control); // Now solve the system of equations. The diff --git a/deal.II/examples/step-4/step-4.cc b/deal.II/examples/step-4/step-4.cc index 8e65deac5a..067c93ef13 100644 --- a/deal.II/examples/step-4/step-4.cc +++ b/deal.II/examples/step-4/step-4.cc @@ -172,8 +172,8 @@ class BoundaryValues : public Function // For this example, we choose as right hand - // side function to function 4*(x^4+y^4) in - // 2D, or 4*(x^4+y^4+z^4) in 3D. We could + // side function to function $4(x^4+y^4)$ in + // 2D, or $4(x^4+y^4+z^4)$ in 3D. We could // write this distinction using an // if-statement on the space dimension, but // here is a simple way that also allows us @@ -185,7 +185,7 @@ class BoundaryValues : public Function // the template, the compiler doesn't know // the value of ``dim'', but when it later // encounters a statement or declaration - // ``RightHandSide<2>'', it will take the + // ``RightHandSide@<2@>'', it will take the // template, replace all occurrences of dim // by 2 and compile the resulting function); // in other words, at the time of compiling @@ -197,7 +197,7 @@ class BoundaryValues : public Function // above right away. // // The last thing to note is that a - // ``Point'' denotes a point in + // ``Point@'' denotes a point in // dim-dimensionsal space, and its individual // components (i.e. `x', `y', // ... coordinates) can be accessed using the @@ -241,26 +241,26 @@ double BoundaryValues::value (const Point &p, // ``dim'' that we assume unknown at the time // we define the template functions. Only // later, the compiler will find a - // declaration of ``LaplaceProblem<2>'' (in + // declaration of ``LaplaceProblem@<2@>'' (in // the ``main'' function, actually) and // compile the entire class with ``dim'' // replaced by 2, a process referred to as // `instantiation of a template'. When doing // so, it will also replace instances of - // ``RightHandSide'' by - // ``RightHandSide<2>'' and instantiate the + // ``RightHandSide@'' by + // ``RightHandSide@<2@>'' and instantiate the // latter class from the class template. // // In fact, the compiler will also find a - // declaration ``LaplaceProblem<3>'' in + // declaration ``LaplaceProblem@<3@>'' in // ``main()''. This will cause it to again go // back to the general - // ``LaplaceProblem'' template, replace + // ``LaplaceProblem@'' template, replace // all occurrences of ``dim'', this time by // 3, and compile the class a second // time. Note that the two instantiations - // ``LaplaceProblem<2>'' and - // ``LaplaceProblem<3>'' are completely + // ``LaplaceProblem@<2@>'' and + // ``LaplaceProblem@<3@>'' are completely // independent classes; their only common // feature is that they are both instantiated // from the same general template, but they @@ -494,7 +494,7 @@ void LaplaceProblem::assemble_system () // ``fe_values.shape_grad(i,q_point)'' // returns a ``dim'' dimensional // vector, represented by a - // ``Tensor<1,dim>'' object, and the + // ``Tensor@<1,dim@>'' object, and the // operator* that multiplies it with // the result of // ``fe_values.shape_grad(j,q_point)'' @@ -653,7 +653,7 @@ void LaplaceProblem::run () // looks mostly like in step-3, but if you // look at the code below, note how we first // create a variable of type - // ``LaplaceProblem<2>'' (forcing the + // ``LaplaceProblem@<2@>'' (forcing the // compiler to compile the class template // with ``dim'' replaced by ``2'') and run a // 2d simulation, and then we do the whole diff --git a/deal.II/examples/step-5/step-5.cc b/deal.II/examples/step-5/step-5.cc index 3de1ac8df5..c87b12618b 100644 --- a/deal.II/examples/step-5/step-5.cc +++ b/deal.II/examples/step-5/step-5.cc @@ -606,7 +606,7 @@ void LaplaceProblem::assemble_system () // class takes a template argument // denoting the matrix type it is // supposed to work on. The default - // value is ``SparseMatrix'', + // value is ``SparseMatrix@'', // which is exactly what we need // here, so we simply stick with the // default and do not specify diff --git a/deal.II/examples/step-6/step-6.cc b/deal.II/examples/step-6/step-6.cc index c29de1f970..98bc5bea55 100644 --- a/deal.II/examples/step-6/step-6.cc +++ b/deal.II/examples/step-6/step-6.cc @@ -790,7 +790,7 @@ void LaplaceProblem::solve () // corresponding Neumann values. This // information is represented by an // object of type - // ``FunctionMap::type'' that is + // ``FunctionMap@::type'' that is // essentially a map from boundary // indicators to function objects // describing Neumann boundary values diff --git a/deal.II/examples/step-7/step-7.cc b/deal.II/examples/step-7/step-7.cc index 2948829b32..9fe8898ac5 100644 --- a/deal.II/examples/step-7/step-7.cc +++ b/deal.II/examples/step-7/step-7.cc @@ -141,7 +141,7 @@ class SolutionBase // First we assign values to the centers for // the 1d case, where we place the centers // equidistantly at -1/3, 0, and 1/3. The - // ``template <>'' header for this definition + // ``template @<@>'' header for this definition // indicates an explicit specialization. This // means, that the variable belongs to a // template, but that instead of providing @@ -193,7 +193,7 @@ const double SolutionBase::width = 1./3.; // the classes representing these // two. They both represent // continuous functions, so they are - // derived from the ``Function'' + // derived from the ``Function@'' // base class, and they also inherit // the characteristics defined in the // ``SolutionBase'' class. @@ -249,10 +249,10 @@ class Solution : public Function, // elements of a base class that is // template dependent (in this case // the elements of - // ``SolutionBase''), then the + // ``SolutionBase@''), then the // C++ language forces us to write - // ``this->n_source_centers'' (for - // example). Note that the ``this->'' + // ``this-@>n_source_centers'' (for + // example). Note that the ``this-@>'' // qualification is not necessary if // the base class is not template // dependent, and also that the gcc @@ -293,13 +293,13 @@ double Solution::value (const Point &p, // initialization. // // Note that we could as well have taken the - // type of the object to be ``Point'' - // instead of ``Tensor<1,dim>''. Tensors of + // type of the object to be ``Point@'' + // instead of ``Tensor@<1,dim@>''. Tensors of // rank 1 and points are almost exchangeable, // and have only very slightly different // mathematical meanings. In fact, the - // ``Point'' class is derived from the - // ``Tensor<1,dim>'' class, which makes up + // ``Point@'' class is derived from the + // ``Tensor@<1,dim@>'' class, which makes up // for their mutual exchange ability. Their // main difference is in what they logically // mean: points are points in space, such as @@ -625,7 +625,7 @@ class HelmholtzProblem // the finite element object; since the // finite element object is actually // never changed in our computations, we - // pass a ``const FiniteElement'' as + // pass a ``const FiniteElement@'' as // template argument to the // ``SmartPointer'' class. Note that the // pointer so declared is assigned at @@ -1308,7 +1308,7 @@ void HelmholtzProblem::process_solution (const unsigned int cycle) // maximum value over all cell-wise // entries, an operation that is // conveniently done using the - // ``Vector::linfty'' function: + // ``Vector@::linfty'' function: const QTrapez<1> q_trapez; const QIterated q_iterated (q_trapez, 5); VectorTools::integrate_difference (dof_handler, diff --git a/deal.II/examples/step-8/step-8.cc b/deal.II/examples/step-8/step-8.cc index 3b5fdf0a56..a77bb2ba69 100644 --- a/deal.II/examples/step-8/step-8.cc +++ b/deal.II/examples/step-8/step-8.cc @@ -336,7 +336,7 @@ void RightHandSide::vector_value_list (const std::vector > &poin // // We can prevent this situation by // calling - // ``RightHandSide::vector_valued'' + // ``RightHandSide@::vector_valued'' // on each point in the input // list. Note that by giving the // full name of the function, @@ -582,7 +582,7 @@ void ElasticProblem::assemble_system () // ``rhs_values'' array is // changed. We initialize it by // ``n_q_points'' elements, each of - // which is a ``Vector'' + // which is a ``Vector@'' // with ``dim'' elements. RightHandSide right_hand_side; std::vector > rhs_values (n_q_points, @@ -636,8 +636,8 @@ void ElasticProblem::assemble_system () // that there is more in // it. In fact, the // function returns a - // ``std::pair'', of + // ``std::pair@'', of // which the first element // is ``comp(i)'' and the // second is the value diff --git a/deal.II/examples/step-9/step-9.cc b/deal.II/examples/step-9/step-9.cc index 04d4e30cc3..3c4d0fe1eb 100644 --- a/deal.II/examples/step-9/step-9.cc +++ b/deal.II/examples/step-9/step-9.cc @@ -280,7 +280,7 @@ class AdvectionField : public TensorFunction<1,dim> // output directives that will be // piped into the ``std::cerr'' // object, thus the strange - // format with the leading ``<<'' + // format with the leading ``@<@<'' // operator and the like. Note // that we can access the // parameters which are passed to @@ -806,7 +806,7 @@ void AdvectionProblem::assemble_system () // only for a range of cell // iterators, but for iterators in // general, so you could use it for - // ``std::vector::iterator'' or + // ``std::vector@::iterator'' or // usual pointers as well. // // The function returns a vector of