<ol>
+<li> Fixed: Many places in the documentation have been made to consistently
+use doxygen markup that indicates that this is code, so that doxygen will
+cross-link the piece of code to class and function names. Many typos have also
+been fixed.
+<br>
+(Felix Gruber, 2013/02/15)
+
<li> Fixed: Starting in release 7.1, we first built the deal.II shared libraries
in the local <code>/tmp</code> or similar directory rather than the final location
because linking becomes very slow over remotely mounted file systems. Unfortunately,
* function parser (see the ReadMe file of deal.II on instructions for this).
*
* The following example shows how to use this class:
- * @verbatim
+ * @code
// Define some constants that will be used by the function parser
std::map<std::string,double> constants;
constants["pi"] = numbers::PI;
vector_function.initialize(variables,
expressions,
constants);
- @endverbatim
+ @endcode
* FunctionParser also provides an option to use <b>units</b> in expressions.
* We illustrate the use of this functionality with the following example:
- * @verbatim
+ * @code
// Define some constants that will be used by the function parser
std::map<std::string> constants;
std::map<std::string> units;
" @point " << "[" << point << "]" << " is " <<
"[" << vector_function.value(point) << "]" << std::endl;
- * @endverbatim
+ * @endcode
*
* Units are similar to <b>constants</b> in the way they are passed to the
* parser, i.e. via std::map<std::string,double>. But units are slightly different
* strings each defining one vector component.
*
* An example of time dependent scalar function is the following:
- @verbatim
+ @code
// Empty constants object
std::map<std::string> constants;
// and there is another variable
// to be taken into account (t).
- @endverbatim
+ @endcode
* The following is another example of how to instantiate a
* vector valued function by using a single string:
- @verbatim
+ @code
// Empty constants object
std::map<std::string> constants;
expression,
constants);
- @endverbatim
+ @endcode
*
*
* @ingroup functions
* is only considered in a call, if all parts of its signature can be
* instantiated with the template parameter replaced by the respective
* types/values in this particular call. Example:
- * @verbatim
+ * @code
* template <typename T>
* typename T::type foo(T) {...};
* ...
* foo(1);
- * @endverbatim
+ * @endcode
* The compiler should detect that in this call, the template
* parameter T must be identified with the type "int". However,
* the return type T::type does not exist. The trick now is
*
* The idea is then to make the return type un-instantiatable if
* certain constraints on the template types are not satisfied:
- * @verbatim
+ * @code
* template <bool, typename> struct constraint_and_return_value;
* template <typename T> struct constraint_and_return_value<true,T> {
* typedef T type;
* };
- * @endverbatim
+ * @endcode
* constraint_and_return_value<false,T> is not defined. Given something like
- * @verbatim
+ * @code
* template <typename>
* struct int_or_double { static const bool value = false;};
* template <>
* struct int_or_double<int> { static const bool value = true; };
* template <>
* struct int_or_double<double> { static const bool value = true; };
- * @endverbatim
+ * @endcode
* we can write a template
- * @verbatim
+ * @code
* template <typename T>
* typename constraint_and_return_value<int_or_double<T>::value,void>::type
* f (T);
- * @endverbatim
+ * @endcode
* which can only be instantiated if T=int or T=double. A call to
* f('c') will just fail with a compiler error: "no instance of
* f(char) found". On the other hand, if the predicate in the first
* A type that is sometimes used for template tricks. For example, in
* some situations one would like to do this:
*
- * @verbatim
+ * @code
* template <int dim>
* class X {
* // do something on subdim-dimensional sub-objects of the big
* template <int dim, int subdim> void f(X<dim> &x) {
* x.f<subdim> ();
* }
- * @endverbatim
+ * @endcode
*
* The problem is: the language doesn't allow us to specialize
* <code>X::f()</code> without specializing the outer class first. One
* of the common tricks is therefore to use something like this:
*
- * @verbatim
+ * @code
* template <int N> struct int2type {};
*
* template <int dim>
* template <int dim, int subdim> void f(X<dim> &x) {
* x.f (int2type<subdim>());
* }
- * @endverbatim
+ * @endcode
*
* Note that we have replaced specialization of <code>X::f()</code> by
* overloading, but that from inside the function <code>g()</code>, we
* <h3>Transfering a solution</h3>
* Here VECTOR is your favorite vector type, e.g. PETScWrappers::MPI::Vector,
* TrilinosWrappers::MPI::Vector, or corresponding blockvectors.
- * @verbatim
+ * @code
SolutionTransfer<dim, VECTOR> soltrans(dof_handler);
// flag some cells for refinement
// and coarsening, e.g.
VECTOR interpolated_solution;
//create VECTOR in the right size here
soltrans.interpolate(interpolated_solution);
- @endverbatim
+ @endcode
*
* <h3>Use for Serialization</h3>
*
* to a file. If you use more than one DoFHandler and therefore more than one SolutionTransfer object, they need to be serialized and deserialized in the same order.
*
* If vector has the locally relevant DoFs, serialization works as follows:
- *@verbatim
+ *@code
parallel::distributed::SolutionTransfer<dim,VECTOR> sol_trans(dof_handler);
sol_trans.prepare_serialization (vector);
triangulation.save(filename);
- @endverbatim
+ @endcode
* For deserialization the vector needs to be a distributed vector (without ghost elements):
- * @verbatim
+ * @code
//[create coarse mesh...]
triangulation.load(filename);
parallel::distributed::SolutionTransfer<dim,VECTOR> sol_trans(dof_handler);
sol_trans.deserialize (distributed_vector);
- @endverbatim
+ @endcode
*
* @ingroup distributed
* @author Timo Heister, 2009-2011
* version hp::DoFHandler, since
* one can then write code like
* this:
- * @verbatim
+ * @code
* dofs_per_cell
* = dof_handler->get_fe()[cell->active_fe_index()].dofs_per_cell;
- * @endverbatim
+ * @endcode
*
* This code doesn't work in both
* situations without the present
* Therefore, the constructor of a derived class should have a
* structure like this (example for interpolation in support points):
*
- * @verbatim
+ * @code
* fill_support_points();
*
* const unsigned int n_dofs = this->dofs_per_cell;
*
* this->inverse_node_matrix.reinit(n_dofs, n_dofs);
* this->inverse_node_matrix.invert(N);
- * @endverbatim
+ * @endcode
*
* @note The matrix #inverse_node_matrix should have dimensions zero
* before this piece of code is executed. Only then,
* transformations can be selected from the set MappingType and stored
* in #mapping_type. Therefore, each constructor should contain a line
* like:
- * @verbatim
+ * @code
* this->mapping_type = this->mapping_none;
- * @endverbatim
+ * @endcode
*
* @see PolynomialsBDM, PolynomialsRaviartThomas
* @ingroup febase
* to it.
*
* An example is shown below:
- * @verbatim
+ * @code
* FESystem<dim> fe(FE_Q<dim>(1), dim);
* DoFHandler<dim> flowfield_dof_handler(triangulation);
* flowfield_dof_handler.distribute_dofs(fe);
* Vector<double> map_points(flowfield_dof_handler.n_dofs());
* MappingQ1Eulerian<dim> mymapping(map_points, flowfield_dof_handler);
- * @endverbatim
+ * @endcode
*
* Note that since the vector of shift values and the dof handler are
* only associated to this object at construction time, you have to
* Typically, the DoFHandler operates on a finite element that
* is constructed as a system element (FESystem) from continuous FE_Q()
* objects. An example is shown below:
- * @verbatim
+ * @code
* FESystem<dim> fe(FE_Q<dim>(2), dim, FE_Q<dim>(1), 1);
* DoFHandler<dim> dof_handler(triangulation);
* dof_handler.distribute_dofs(fe);
* Vector<double> soln_vector(dof_handler.n_dofs());
* MappingQEulerian<dim> q2_mapping(2,soln_vector,dof_handler);
- * @endverbatim
+ * @endcode
*
* In this example, our element consists of <tt>(dim+1)</tt> components.
* Only the first <tt>dim</tt> components will be used, however, to define
* and the corresponding output function names.
*
* Usage is simple: either you use the direct form
- * @verbatim
+ * @code
* ofstream output_file("some_filename");
* GridOut().write_gnuplot (tria, output_file);
- * @endverbatim
+ * @endcode
* if you know which format you want to have, or if you want the format to be
* a runtime parameter, you can write
- * @verbatim
+ * @code
* 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);
- * @endverbatim
+ * @endcode
* The function <tt>get_output_format_names()</tt> provides a list of possible names of
* output formats in a string that is understandable by the ParameterHandler class.
*
* format. These are collected in structures GridOutFlags::Eps(),
* GridOutFlags::Gnuplot(), etc declared in the GridOutFlags
* namespace, and you can set your preferred flags like this:
- * @verbatim
+ * @code
* GridOut grid_out;
* GridOutFlags::Ucd ucd_flags;
* ... // set some fields in ucd_flags
* grid_out.set_flags (ucd_flags);
* ...
* ... // write some file with data_out
- * @endverbatim
+ * @endcode
* 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
* object of this class.
*
* Basically, usage looks like this:
- * @verbatim
+ * @code
* Triangulation<dim> coarse_grid;
* ... // initialize coarse grid
*
* // is not needed anymore, e.g.
* // working with another grid
* };
- * @endverbatim
+ * @endcode
*
* Note that initially, the PersistentTriangulation object does not
* constitute a triangulation; it only becomes one after @p restore is first
* </ul>
*
* For <tt>dim==1</tt>, these iterators are mapped as follows:
- * @verbatim
+ * @code
* typedef line_iterator cell_iterator;
* typedef active_line_iterator active_cell_iterator;
- * @endverbatim
+ * @endcode
* while for @p dim==2 we have the additional face iterator:
- * @verbatim
+ * @code
* typedef quad_iterator cell_iterator;
* typedef active_quad_iterator active_cell_iterator;
*
* typedef line_iterator face_iterator;
* typedef active_line_iterator active_face_iterator;
- * @endverbatim
+ * @endcode
*
* By using the cell iterators, you can write code independent of
* the spatial dimension. The same applies for substructure iterators,
* the default value <code>dim</code>).
* <ul>
* <li> <em>Counting the number of cells on a specific level</em>
- * @verbatim
+ * @code
* template <int dim, int spacedim>
* int Triangulation<dim, spacedim>::n_cells (const int level) const {
* cell_iterator cell = begin (level),
* ++n;
* return n;
* };
- * @endverbatim
+ * @endcode
* Another way which uses the STL @p distance function would be to write
- * @verbatim
+ * @code
* template <int dim>
* int Triangulation<dim>::n_cells (const int level) const {
* int n=0;
* n);
* return n;
* };
- * @endverbatim
+ * @endcode
*
* <li> <em>Refining all cells of a triangulation</em>
- * @verbatim
+ * @code
* template <int dim>
* void Triangulation<dim>::refine_global () {
* active_cell_iterator cell = begin_active(),
* cell->set_refine_flag ();
* execute_coarsening_and_refinement ();
* };
- * @endverbatim
+ * @endcode
* </ul>
*
*
*
* Usage of a Triangulation is mainly done through the use of iterators.
* An example probably shows best how to use it:
- * @verbatim
+ * @code
* void main () {
* Triangulation<2> tria;
*
* ofstream out("grid.1");
* GridOut::write_gnuplot (tria, out);
* };
- * @endverbatim
+ * @endcode
*
*
* <h3>Creating a triangulation</h3>
* 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:
- * @verbatim
+ * @code
* // open output file
* ofstream history("mesh.history");
* // do 10 refinement steps
* tria.save_refine_flags (history);
* tria.execute_coarsening_and_refinement ();
* };
- * @endverbatim
+ * @endcode
*
* If you want to re-create the grid from the stored information, you write:
- * @verbatim
+ * @code
* // open input file
* ifstream history("mesh.history");
* // do 10 refinement steps
* tria.load_refine_flags (history);
* tria.execute_coarsening_and_refinement ();
* };
- * @endverbatim
+ * @endcode
*
* The same scheme is employed for coarsening and the coarsening flags.
*
* details. Usage with the Triangulation object is then like this
* (let @p Ball be a class derived from Boundary<tt><2></tt>):
*
- * @verbatim
+ * @code
* void main () {
* Triangulation<2> tria;
* // set the boundary function
* tria.execute_coarsening_and_refinement();
* };
* };
- * @endverbatim
+ * @endcode
*
* You should take note of one caveat: if you have concave
* boundaries, you must make sure that a new boundary vertex does
* 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):
- * @verbatim
+ * @code
* ...
* Point<2> new_vertex = boundary.get_new_point_on_line (line);
* ...
- * @endverbatim
+ * @endcode
* @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
- * @verbatim
+ * @code
* ...
* Point<3> new_line_vertices[4]
* = { boundary.get_new_point_on_line (face->line(0)),
* boundary.get_new_point_on_line (face->line(2)),
* boundary.get_new_point_on_line (face->line(3)) };
* ...
- * @endverbatim
+ * @endcode
* to get the four midpoints of the lines bounding the quad at the
* boundary, and after that
- * @verbatim
+ * @code
* ...
* Point<3> new_quad_vertex = boundary.get_new_point_on_quad (face);
* ...
- * @endverbatim
+ * @endcode
* 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
* Through this constructor, it is also
* possible to construct objects for
* derived iterators:
- * @verbatim
+ * @code
* DoFCellAccessor dof_accessor;
* Triangulation::active_cell_iterator cell
* = accessor;
- * @endverbatim
+ * @endcode
*/
TriaRawIterator (const Accessor &a);
* @p raw_line_iterator objects operate on all lines, used or not.
*
* Since we are in one dimension, the following identities are declared:
- * @verbatim
+ * @code
* typedef raw_line_iterator raw_cell_iterator;
* typedef line_iterator cell_iterator;
* typedef active_line_iterator active_cell_iterator;
- * @endverbatim
+ * @endcode
*
* To enable the declaration of @p begin_quad and the like in
* <tt>Triangulation<1></tt>, the @p quad_iterators are declared as
* are useless and will certainly make any involuntary use visible.
*
* Since we are in two dimension, the following identities are declared:
- * @verbatim
+ * @code
* typedef raw_quad_iterator raw_cell_iterator;
* typedef quad_iterator cell_iterator;
* typedef active_quad_iterator active_cell_iterator;
* typedef raw_line_iterator raw_face_iterator;
* typedef line_iterator face_iterator;
* typedef active_line_iterator active_face_iterator;
- * @endverbatim
+ * @endcode
*
* @author Wolfgang Bangerth, 1998
*/
* For the declarations of the data types, more or less the same holds
* as for lower dimensions (see <tt>Iterators<[12]></tt>). The
* dimension specific data types are here, since we are in three dimensions:
- * @verbatim
+ * @code
* typedef raw_hex_iterator raw_cell_iterator;
* typedef hex_iterator cell_iterator;
* typedef active_hex_iterator active_cell_iterator;
* typedef raw_quad_iterator raw_face_iterator;
* typedef quad_iterator face_iterator;
* typedef active_quad_iterator active_face_iterator;
- * @endverbatim
+ * @endcode
*
* @author Wolfgang Bangerth, 1998
*/
*
* The ArpackSolver can be used in application codes in the
* following way:
- @verbatim
+ @code
SolverControl solver_control (1000, 1e-9);
ArpackSolver (solver_control);
system.solve (A, B, lambda, x, size_of_spectrum);
- @endverbatim
+ @endcode
* for the generalized eigenvalue problem $Ax=B\lambda x$, where
* the variable <code>const unsigned int size_of_spectrum</code>
* tells ARPACK the number of eigenvector/eigenvalue pairs to
* <h3>Usage</h3>
*
* Use this class as follows:
- * @verbatim
+ * @code
* CompressedSetSparsityPattern compressed_pattern (dof_handler.n_dofs());
* DoFTools::make_sparsity_pattern (dof_handler,
* compressed_pattern);
*
* SparsityPattern sp;
* sp.copy_from (compressed_pattern);
- * @endverbatim
+ * @endcode
*
* See also step-11 and step-18 for usage
* patterns of the related CompressedSparsityPattern class, and
* <h3>Usage</h3>
*
* Use this class as follows:
- * @verbatim
+ * @code
* CompressedSimpleSparsityPattern compressed_pattern (dof_handler.n_dofs());
* DoFTools::make_sparsity_pattern (dof_handler,
* compressed_pattern);
*
* SparsityPattern sp;
* sp.copy_from (compressed_pattern);
- * @endverbatim
+ * @endcode
*
*
* <h3>Notes</h3>
* <h3>Usage</h3>
*
* Use this class as follows:
- * @verbatim
+ * @code
* CompressedSparsityPattern compressed_pattern (dof_handler.n_dofs());
* DoFTools::make_sparsity_pattern (dof_handler,
* compressed_pattern);
*
* SparsityPattern sp;
* sp.copy_from (compressed_pattern);
- * @endverbatim
+ * @endcode
*
* See also step-11 and step-18 for usage
* patterns.
* available.
*
* A typical code snippet showing the above steps is as follows:
- * @verbatim
+ * @code
* ... // set up sparse matrix A and right hand side b somehow
*
* // initialize filtered matrix with
*
* // solve for solution vector x
* solver.solve (filtered_A, x, b, filtered_prec);
- * @endverbatim
+ * @endcode
*
*
* <h3>Connection to other classes</h3>
* constructor, one can easily
* create an identity matrix of
* size <code>n</code> by saying
- * @verbatim
+ * @code
* FullMatrix<double> M(IdentityMatrix(n));
- * @endverbatim
+ * @endcode
*/
FullMatrix (const IdentityMatrix &id);
/**
* the argument. This way, one can easily
* create an identity matrix of
* size <code>n</code> by saying
- * @verbatim
+ * @code
* M = IdentityMatrix(n);
- * @endverbatim
+ * @endcode
*/
FullMatrix<number> &
operator = (const IdentityMatrix &id);
*
* The main usefulness of this class lies in its ability to initialize
* other matrix, like this:
- @verbatim
+ @code
FullMatrix<double> identity (IdentityMatrix(10));
- @endverbatim
+ @endcode
*
* This creates a $10\times 10$ matrix with ones on the diagonal and
* zeros everywhere else. Most matrix types, in particular FullMatrix
* context as shown in the documentation of that class. The present
* class can be used in much the same way, although without any
* additional benefit:
- @verbatim
+ @code
SolverControl solver_control (1000, 1e-12);
SolverCG<> cg (solver_control);
cg.solve (system_matrix, solution, system_rhs,
IdentityMatrix(solution.size()));
- @endverbatim
+ @endcode
*
*
* @author Wolfgang Bangerth, 2006
* of the base class.
*
* A typical usage of this class would be as follows:
- * @verbatim
+ * @code
* FullMatrix<double> M;
* ... // fill matrix M with some values
*
* std::ofstream out ("M.gnuplot");
* matrix_out.build_patches (M, "M");
* matrix_out.write_gnuplot (out);
- * @endverbatim
+ * @endcode
* Of course, you can as well choose a different graphical output
* format. Also, this class supports any matrix, not only of type
* FullMatrix, as long as it satisfies a number of requirements,
* DataOutInterface does so as well, this does no harm, but
* calms the compiler which is suspecting an access control conflict
* otherwise. Testcase here:
- * @verbatim
+ * @code
* template <typename T> class V {};
*
* struct B1 {
* };
*
* D d;
- * @endverbatim
+ * @endcode
*
* @ingroup output
* @author Wolfgang Bangerth, 2001
* operation of the opposite kind, it calls compress() and flips the
* state. This can sometimes lead to very confusing behavior, in code that may
* for example look like this:
- * @verbatim
+ * @code
* PETScWrappers::MPI::Vector vector;
* ...
* // do some write operations on the vector
*
* // do another collective operation
* const double norm = vector.l2_norm();
- * @endverbatim
+ * @endcode
*
* This code can run into trouble: by the time we see the first addition
* operation, we need to flush the overwrite buffers for the vector, and the
* preconditioner. Therefore, you must use the identity provided here
* to avoid preconditioning. It can be used in the following way:
*
- @verbatim
+ @code
SolverControl solver_control (1000, 1e-12);
SolverCG<> cg (solver_control);
cg.solve (system_matrix, solution, system_rhs,
PreconditionIdentity());
- @endverbatim
+ @endcode
*
* See the step-3 tutorial program for an example and
* additional explanations.
*
* <h3>Usage</h3>
* The simplest use of this class is the following:
- * @verbatim
+ * @code
* // generate a @p SolverControl and
* // a @p VectorMemory
* SolverControl control;
* // call the @p solve function with this
* // preconditioning as last argument
* solver.solve(A,x,b,preconditioning);
- * @endverbatim
+ * @endcode
* The same example where also the @p SolverSelector class is used reads
- * @verbatim
+ * @code
* // generate a @p SolverControl and
* // a @p VectorMemory
* SolverControl control;
* preconditioning.use_matrix(A);
*
* solver_selector.solve(A,x,b,preconditioning);
- * @endverbatim
+ * @endcode
* 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
* Applying these transformations, the solution of the system above by a
* @p SchurMatrix @p schur is coded as follows:
*
- * @verbatim
+ * @code
* schur.prepare_rhs (g, f);
* solver.solve (schur, p, g, precondition);
* schur.postprocess (u, p);
- * @endverbatim
+ * @endcode
*
* @see @ref GlossBlockLA "Block (linear algebra)"
* @author Guido Kanschat, 2000, 2001, 2002
* interface to SLEPc solvers that handle both of these problem sets.
*
* SLEPcWrappers can be implemented in application codes in the
- * following way: @verbatim SolverControl solver_control (1000, 1e-9);
- * SolverArnoldi system (solver_control, mpi_communicator);
- * system.solve (A, B, lambda, x, size_of_spectrum); @endverbatim for
- * the generalized eigenvalue problem $Ax=B\lambda x$, where the
+ * following way:
+ * @code
+ * SolverControl solver_control (1000, 1e-9);
+ * SolverArnoldi system (solver_control, mpi_communicator);
+ * system.solve (A, B, lambda, x, size_of_spectrum);
+ * @endcode
+ * for the generalized eigenvalue problem $Ax=B\lambda x$, where the
* variable <code>const unsigned int size_of_spectrum</code> tells
* SLEPc the number of eigenvector/eigenvalue pairs to solve for: See
* also <code>step-36</code> for a hands-on example.
* rather than just one. This freedom is intended for use of the
* SLEPcWrappers that require a greater handle on the eigenvalue
* problem solver context. See also the API of:
- @verbatim
+ @code
template <typename OutputVector>
void
SolverBase::solve (const PETScWrappers::MatrixBase &A,
std::vector<OutputVector> &vr,
const unsigned int n_eigenvectors)
{ ... }
- @endverbatim
+ @endcode
* as an example on how to do this.
*
* For further information and explanations on handling the @ref
*
* <h3>Usage</h3>
* The simplest use of this class is the following:
- * @verbatim
+ * @code
* // generate a @p SolverControl and
* // a @p VectorMemory
* SolverControl control;
* // call the @p solve function with this
* // preconditioning as last argument
* solver_selector.solve(A,x,b,preconditioning);
- * @endverbatim
+ * @endcode
* 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
- * @verbatim
+ * @code
* Parameter_Handler prm;
* prm.declare_entry ("solver", "none",
* Patterns::Selection(SolverSelector<>::get_solver_names()));
* ...
- * @endverbatim
+ * @endcode
* Assuming that in the users parameter file there exists the line
- * @verbatim
- * set solver = cg
- * @endverbatim
+ @verbatim
+ set solver = cg
+ @endverbatim
* then `Line 3' of the above example reads
- * @verbatim
+ * @code
* SolverSelector<SparseMatrix<double>, Vector<double> >
* solver_selector(prm.get("solver"), control, memory);
- * @endverbatim
+ * @endcode
*
*
* If at some time there exists a new solver "xyz" then the user does not need
* 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.
- * @verbatim
+ * @code
* // tag the Lagrange multiplier variable
* vector<bool> signature(3);
* signature[0] = signature[1] = false;
* // solve
* gmres.solve (global_matrix, solution, right_hand_side,
* vanka);
- * @endverbatim
+ * @endcode
*
*
* <h4>Implementor's remark</h4>
* compress() and flips the state. This can sometimes lead to very
* confusing behavior, in code that may for example look like this:
*
- * @verbatim
+ * @code
* TrilinosWrappers::Vector vector;
* // do some write operations on the vector
* for (unsigned int i=0; i<vector->size(); ++i)
*
* // do another collective operation
* const double norm = vector->l2_norm();
- * @endverbatim
+ * @endcode
*
* This code can run into trouble: by the time we see the first addition
* operation, we need to flush the overwrite buffers for the vector, and
* which is suitable for quadratic finite elements in space, for
* example.
*
- * @verbatim
+ * @code
* DataOutStack<dim> data_out_stack;
*
* // first declare the vectors
* data_out_stack.build_patches (2);
* data_out_stack.finish_parameter_value ();
* };
- * @endverbatim
+ * @endcode
*
* @ingroup output
* @author Wolfgang Bangerth, 1999
* <ul>
* <li> If the grid will only be refined
* (i.e. no cells are coarsened) then use @p SolutionTransfer as follows:
- * @verbatim
+ * @code
* SolutionTransfer<dim, double> soltrans(*dof_handler);
* // flag some cells for refinement, e.g.
* GridRefinement::refine_and_coarsen_fixed_fraction(
* tria->execute_coarsening_and_refinement();
* // and redistribute dofs.
* dof_handler->distribute_dofs (fe);
- * @endverbatim
+ * @endcode
*
* Then to proceed do
- * @verbatim
+ * @code
* // take a copy of the solution vector
* Vector<double> solution_old(solution);
* // resize solution vector to the correct
* solution.reinit(dof_handler->n_dofs());
* // and finally interpolate
* soltrans.refine_interpolate(solution_old, solution);
- * @endverbatim
+ * @endcode
*
* Although the @p refine_interpolate functions are allowed to be
* called multiple times, e.g. for interpolating several solution
* vectors, there is following possibility of interpolating several
* functions simultaneously.
- * @verbatim
+ * @code
* vector<Vector<double> > solutions_old(n_vectors, Vector<double> (n));
* ...
* vector<Vector<double> > solutions(n_vectors, Vector<double> (n));
* soltrans.refine_interpolate(solutions_old, solutions);
- * @endverbatim
+ * @endcode
* This is used in several of the tutorial programs, for example
* step-31.
*
* <li> If the grid has cells that will be coarsened,
* then use @p SolutionTransfer as follows:
- * @verbatim
+ * @code
* SolutionTransfer<dim, Vector<double> > soltrans(*dof_handler);
* // flag some cells for refinement
* // and coarsening, e.g.
* // and interpolate the solution
* Vector<double> interpolate_solution(dof_handler->n_dofs());
* soltrans.interpolate(solution, interpolated_solution);
- * @endverbatim
+ * @endcode
*
* Multiple calls to the function
* <tt>interpolate (const Vector<number> &in, Vector<number> &out)</tt>
* The main loop of a program using this class will usually look like
* the following one, taken modified from an application program that
* isn't distributed as part of the library:
- * @verbatim
+ * @code
* template <int dim>
* void TimeDependent_Wave<dim>::run_sweep (const unsigned int sweep_no)
* {
* for (unsigned int sweep=0; sweep<number_of_sweeps; ++sweep)
* timestep_manager.run_sweep (sweep);
* };
- * @endverbatim
+ * @endcode
* Here, @p timestep_manager is an object of type TimeDependent_Wave(), which
* is a class derived from TimeDependent. @p start_sweep,
* @p solve_primal_problem, @p solve_dual_problem, @p postprocess and @p end_sweep
* timesteps within this object and call the respective function on each of
* these objects. For example, here are two of the functions as they are
* implemented by the library:
- * @verbatim
+ * @code
* void TimeDependent::start_sweep (const unsigned int s)
* {
* sweep_no = s;
* timestepping_data_primal,
* forward);
* };
- * @endverbatim
+ * @endcode
* The latter function shows rather clear how most of the loops are
* invoked (@p solve_primal_problem, @p solve_dual_problem, @p postprocess,
* @p refine_grids and @p write_statistics all have this form, where the
* the <tt>C++</tt> standard library, it is possible to do neat tricks, like
* the following, also taken from the wave program, in this case from
* the function @p refine_grids:
- * @verbatim
+ * @code
* ...
* compute the thresholds for refinement
* ...
* bottom_threshold)),
* TimeDependent::TimeSteppingData (0,1),
* TimeDependent::forward);
- * @endverbatim
+ * @endcode
* TimeStepBase_Wave::refine_grid is a function taking an argument, unlike
* all the other functions used above within the loops. However, in this special
* case the parameter was the same for all timesteps and known before the loop
* brevity we have omitted the parts that deal with backward running loops
* as well as the checks whether wake-up and sleep operations act on timesteps
* outside <tt>0..n_timesteps-1</tt>.
- * @verbatim
+ * @code
* template <typename InitFunctionObject, typename LoopFunctionObject>
* void TimeDependent::do_loop (InitFunctionObject init_function,
* LoopFunctionObject loop_function,
* for (int look_back=0; look_back<=timestepping_data.look_back; ++look_back)
* timesteps[step-look_back]->sleep(look_back);
* };
- * @endverbatim
+ * @endcode
*
*
* @author Wolfgang Bangerth, 1999
*
* This mechanism usually will result
* in a set-up loop like this
- * @verbatim
+ * @code
* for (i=0; i<N; ++i)
* manager.add_timestep(new MyTimeStep());
- * @endverbatim
+ * @endcode
*/
void add_timestep (TimeStepBase *new_timestep);
projects / dealii-svn.git / commitdiff