// 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
// 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
// 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
// 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
// class as we prefer to get function
// values of type ``Point'' rather
// than of type
- // ``Vector<double>''. This, because
+ // ``Vector@<double@>''. This, because
// there exist scalar products
// between ``Point'' and ``Point'' as
// well as between ``Point'' and
// neighbors of the
// neighboring
// cell. Hence,
- // neighbor->neighbor(neighbor2)
+ // neighbor-@>neighbor(neighbor2)
// equals the
// current cell
// ``cell''.
ue_vi_matrix(i,k));
}
// End of ``if
- // (face->has_children())''
+ // (face-@>has_children())''
}
else
{
ui_vi_matrix,
ue_vi_matrix);
// End of ``if
- // (neighbor->level()
+ // (neighbor-@>level()
// ==
- // cell->level())''
+ // cell-@>level())''
}
else
{
// by a statement like
// ``Assert
// (dof_handler.get_fe().dofs_per_vertex
- // > 0,
+ // @> 0,
// ExcNotImplemented())'',
// which should make it
// quite clear what is
// 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
// 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
// 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''
// of freedom of the primal solver,
// we would have to indicate this
// like so:
- // ``PrimalSolver<dim>::n_dofs()''.
+ // ``PrimalSolver@<dim@>::n_dofs()''.
// However, the compiler does not
// accept this since the ``n_dofs''
// function is actually from a base
// get all that characterizes the
// curved ridge solution, we would
// simply generate an instance of
- // ``Data::SetUp<Data::CurvedRidge>'',
+ // ``Data::SetUp@<Data::CurvedRidge@>'',
// and everything we need to know
// about the solution would be static
// member variables and functions of
// is a worthwhile strategy. Other
// possibilities for special cases
// are to derive from
- // ``Data::SetUp<SomeSetUp>'' where
+ // ``Data::SetUp@<SomeSetUp@>'' where
// ``SomeSetUp'' denotes a class, or
// even to explicitly specialize
- // ``Data::SetUp<SomeSetUp>''. The
+ // ``Data::SetUp@<SomeSetUp@>''. The
// latter allows to transparently use
// the way the ``SetUp'' class is
// used for other set-ups, but with
// take here the description of
// ``Exercise_2_3'', but you
// can also use
- // ``CurvedRidges<dim>'':
+ // ``CurvedRidges@<dim@>'':
descriptor.data = new Data::SetUp<Data::Exercise_2_3<dim>,dim> ();
// Next set first a dual
// 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
// 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
// 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
// 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.
//
// 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);
// situations, the library will silently
// also have to refine the neighbor cell
// once. It does so by calling the
- // ``Triangulation<dim>::prepare_coarsening_and_refinement''
+ // ``Triangulation@<dim@>::prepare_coarsening_and_refinement''
// function before actually doing the
// refinement and coarsening. This function
// flags a set of additional cells for
};
// Again use zero boundary values:
-// std::map<unsigned int,double> boundary_values;
+// std::map@<unsigned int,double@> boundary_values;
// VectorTools::interpolate_boundary_values (mg_dof_handler,
// 0,
-// ZeroFunction<dim>(),
+// ZeroFunction@<dim@>(),
// boundary_values);
// MatrixTools::apply_boundary_values (boundary_values,
// system_matrix,
};
// Again use zero boundary values:
-// std::map<unsigned int,double> boundary_values;
+// std::map@<unsigned int,double@> boundary_values;
// VectorTools::interpolate_boundary_values (mg_dof_handler,
// 0,
-// ZeroFunction<dim>(),
+// ZeroFunction@<dim@>(),
// boundary_values);
// MatrixTools::apply_boundary_values (boundary_values,
// system_matrix,
// 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,
// 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<dim>'', but in fact a reference
+ // ``Point@<dim@>'', 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
// one, and ``dim+1'' components,
// respectively, and that we pass the
// number of components down to the
- // ``Function<dim>'' base class. For
+ // ``Function@<dim@>'' base class. For
// the exact solution, we only
// declare the function that actually
// returns the entire solution vector
// its base elements, with the way we
// have done so in step-8: there, we
// have built it as ``fe
- // (FE_Q<dim>(1), dim)'', i.e. we
+ // (FE_Q@<dim@>(1), dim)'', i.e. we
// have simply used ``dim'' copies of
// the ``FE_Q(1)'' element, one copy
// for the displacement in each
// and preconditioner system is the
// class that approximates the Schur
// complement so we can form a
- // ``InverseMatrix<ApproximateSchurComplement>''
+ // ``InverseMatrix@<ApproximateSchurComplement@>''
// object that approximates the
// inverse of the Schur
// complement. It follows the same
// quadrature. This actually
// presents a slight twist here: if
// we naively chose an object of
- // type ``QGauss<dim>(degree+1)''
+ // type ``QGauss@<dim@>(degree+1)''
// as one may be inclined to do
// (this is what we used for
// integrating the linear system),
// class as we prefer to get function
// values of type ``Point'' rather
// than of type
- // ``Vector<double>''. This, because
+ // ``Vector@<double@>''. This, because
// there exist scalar products
// between ``Point'' and ``Point'' as
// well as between ``Point'' and
// neighbors of the
// neighboring
// cell. Hence,
- // neighbor->neighbor(neighbor2)
+ // neighbor-@>neighbor(neighbor2)
// equals the
// current cell
// ``cell''.
un_v_matrix(i,k));
}
// End of ``if
- // (face->has_children())''
+ // (face-@>has_children())''
}
else
{
u_v_matrix,
un_v_matrix);
// End of ``if
- // (neighbor->level()
+ // (neighbor-@>level()
// ==
- // cell->level())''
+ // cell-@>level())''
}
else
{
// 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
// of the vectors, but the empty angle
// brackets indicate that we simply take
// the default arguments (which are
- // ``SparseMatrix<double>'' and
- // ``Vector<double>''):
+ // ``SparseMatrix@<double@>'' and
+ // ``Vector@<double@>''):
SolverCG<> cg (solver_control);
// Now solve the system of equations. The
// 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
// 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
// above right away.
//
// The last thing to note is that a
- // ``Point<dim>'' denotes a point in
+ // ``Point@<dim@>'' denotes a point in
// dim-dimensionsal space, and its individual
// components (i.e. `x', `y',
// ... coordinates) can be accessed using the
// ``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<dim>'' by
- // ``RightHandSide<2>'' and instantiate the
+ // ``RightHandSide@<dim@>'' 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<dim>'' template, replace
+ // ``LaplaceProblem@<dim@>'' 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
// ``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)''
// 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
// class takes a template argument
// denoting the matrix type it is
// supposed to work on. The default
- // value is ``SparseMatrix<double>'',
+ // value is ``SparseMatrix@<double@>'',
// which is exactly what we need
// here, so we simply stick with the
// default and do not specify
// corresponding Neumann values. This
// information is represented by an
// object of type
- // ``FunctionMap<dim>::type'' that is
+ // ``FunctionMap@<dim@>::type'' that is
// essentially a map from boundary
// indicators to function objects
// describing Neumann boundary values
// 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
// the classes representing these
// two. They both represent
// continuous functions, so they are
- // derived from the ``Function<dim>''
+ // derived from the ``Function@<dim@>''
// base class, and they also inherit
// the characteristics defined in the
// ``SolutionBase'' class.
// elements of a base class that is
// template dependent (in this case
// the elements of
- // ``SolutionBase<dim>''), then the
+ // ``SolutionBase@<dim@>''), 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
// initialization.
//
// Note that we could as well have taken the
- // type of the object to be ``Point<dim>''
- // instead of ``Tensor<1,dim>''. Tensors of
+ // type of the object to be ``Point@<dim@>''
+ // 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<dim>'' class is derived from the
- // ``Tensor<1,dim>'' class, which makes up
+ // ``Point@<dim@>'' 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
// the finite element object; since the
// finite element object is actually
// never changed in our computations, we
- // pass a ``const FiniteElement<dim>'' as
+ // pass a ``const FiniteElement@<dim@>'' as
// template argument to the
// ``SmartPointer'' class. Note that the
// pointer so declared is assigned at
// maximum value over all cell-wise
// entries, an operation that is
// conveniently done using the
- // ``Vector<float>::linfty'' function:
+ // ``Vector@<float@>::linfty'' function:
const QTrapez<1> q_trapez;
const QIterated<dim> q_iterated (q_trapez, 5);
VectorTools::integrate_difference (dof_handler,
//
// We can prevent this situation by
// calling
- // ``RightHandSide<dim>::vector_valued''
+ // ``RightHandSide@<dim@>::vector_valued''
// on each point in the input
// list. Note that by giving the
// full name of the function,
// ``rhs_values'' array is
// changed. We initialize it by
// ``n_q_points'' elements, each of
- // which is a ``Vector<double>''
+ // which is a ``Vector@<double@>''
// with ``dim'' elements.
RightHandSide<dim> right_hand_side;
std::vector<Vector<double> > rhs_values (n_q_points,
// that there is more in
// it. In fact, the
// function returns a
- // ``std::pair<unsigned int,
- // unsigned int>'', of
+ // ``std::pair@<unsigned int,
+ // unsigned int@>'', of
// which the first element
// is ``comp(i)'' and the
// second is the value
// 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
// only for a range of cell
// iterators, but for iterators in
// general, so you could use it for
- // ``std::vector<T>::iterator'' or
+ // ``std::vector@<T@>::iterator'' or
// usual pointers as well.
//
// The function returns a vector of