From 7bc021ed47c55e843da6ea8f44103e9a79210939 Mon Sep 17 00:00:00 2001 From: guido Date: Tue, 26 Jul 2005 11:36:43 +0000 Subject: [PATCH] further adaption to doxygen git-svn-id: https://svn.dealii.org/trunk@11206 0785d39b-7218-0410-832d-ea1e28bc413d --- deal.II/deal.II/include/numerics/data_out.h | 132 ++++++++++-------- .../numerics/derivative_approximation.h | 6 +- .../include/numerics/error_estimator.h | 10 +- deal.II/deal.II/include/numerics/histogram.h | 4 +- deal.II/deal.II/include/numerics/matrices.h | 14 +- .../include/numerics/solution_transfer.h | 4 +- .../deal.II/include/numerics/time_dependent.h | 6 +- 7 files changed, 93 insertions(+), 83 deletions(-) diff --git a/deal.II/deal.II/include/numerics/data_out.h b/deal.II/deal.II/include/numerics/data_out.h index 2c8aefc248..3c4471d8a9 100644 --- a/deal.II/deal.II/include/numerics/data_out.h +++ b/deal.II/deal.II/include/numerics/data_out.h @@ -27,13 +27,15 @@ template class FEValuesBase; +//TODO: Most of the documentation of DataOut_DoFData applies to DataOut. /** - * This is an abstract class which provides the functionality to generate - * patches for output by base classes from data vectors on a grid. It allows - * to store a pointer to a DoFHandler object and one or more pointers to - * node and cell data denoting functions on the grid which shall later - * be written in any of the implemented data formats. + * This is an abstract class which provides the functionality to + * generate patches for output by base classes from data vectors on a + * grid. It allows to store a pointer to a DoFHandler object and one + * or more pointers to node and cell data denoting functions on the + * grid which shall later be written in any of the implemented data + * formats. * * *

User visible interface

@@ -43,7 +45,7 @@ template class FEValuesBase; * 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: - * @verbatim + * @code * ... * ... // compute solution, which contains nodal values * ... @@ -64,32 +66,34 @@ template class FEValuesBase; * data_out.write_xxx (output_file); * * data_out.clear(); - * @endverbatim + * @endcode * - * @p attach_dof_handler tells this class that all future operations are to take - * place with the DoFHandler object and the triangulation it lives on. We then - * add the solution vector and the error estimator; note that they have different - * dimensions, because the solution is a nodal vector, here consisting of two - * components ("x-displacement" and "y-displacement") while the error estimator - * probably is a vector holding cell data. When attaching a data vector, you have - * to give a name to each component of the vector, which is done through an object - * of type vector as second argument; if only one component is in the - * vector, for example if we are adding cell data as in the second case, or if - * the finite element used by the DoFHandler has only one component, then you - * can use the second @p add_data_vector function which takes a @p string instead - * of the vector. + * attach_dof_handler() tells this class that all future operations + * are to take place with the DoFHandler object and the triangulation + * it lives on. We then add the solution vector and the error + * estimator; note that they have different dimensions, because the + * solution is a nodal vector, here consisting of two components + * ("x-displacement" and "y-displacement") while the error estimator + * probably is a vector holding cell data. When attaching a data + * vector, you have to give a name to each component of the vector, + * which is done through an object of type vector as + * second argument; if only one component is in the vector, for + * example if we are adding cell data as in the second case, or if the + * finite element used by the DoFHandler has only one component, then + * you can use the second add_data_vector() function which takes a @p + * string instead of the vector. * * You should note that this class does not copy the vector given to it through - * the @p add_data_vector functions, for memory consumption reasons. It only + * the add_data_vector() functions, for memory consumption reasons. It only * stores a reference to it, so it is in your responsibility to make sure that * the data vectors exist long enough. * * After adding all data vectors, you need to call a function which generates * the patches for output from the stored data. This function is here called - * @p build_patches, but the naming is up to the derived class that actually + * build_patches(), but the naming is up to the derived class that actually * implements this. * - * Finally, you write the data in one format or other, indicated by @p write_xxx, + * Finally, you write() the data in one format or other, * to a file and may want to clear this object as soon as possible to reduce * memory requirements. * @@ -98,16 +102,17 @@ template class FEValuesBase; * class does not provide means to actually generate the patches, only aids to * store and access data. * - * Note that the base class of this class, DataOutInterface offers several - * functions to ease programming with run-time determinable output formats - * (i.e. you need not use a fixed format by calling @p write_xxx in the above - * example, but you can select it by a run-time parameter without having - * to write the if () ... else ... clauses yourself), and also functions - * and classes offering ways to control the appearance of the output by - * setting flags for each output format. + * Note that the base class of this class, DataOutInterface offers + * several functions to ease programming with run-time determinable + * output formats (i.e. you need not use a fixed format by calling + * DataOutInterface::write_xxx in the above example, but you can + * select it by a run-time parameter without having to write the + * if () ... else ... clauses yourself), and also functions + * and classes offering ways to control the appearance of the output + * by setting flags for each output format. * * - * @sect3{Information for derived classes} + *

Information for derived classes

* * What is actually missing this class is a way to produce the patches * for output itself, from the stored data and degree of freedom @@ -125,8 +130,8 @@ template class FEValuesBase; * possible in this respect. * * For this reason, it is left to a derived class to provide a - * function, named usually @p build_patches or the like, which fills - * the @p patches array of this class. + * function, named usually build_patches() or the like, which fills + * the #patches array of this class. * * Regarding the templates of this class, it needs three values: first * the space dimension in which the triangulation and the DoF handler @@ -173,15 +178,20 @@ class DataOut_DoFData : public DataOutInterface * triangulation underlying the * DoFHandler object (such * as error per cell data). The - * value @p type_automatic tells + * value #type_automatic tells * add_data_vector() to find * out itself (see the * documentation of - * @p add_data_vector for the + * add_data_vector() for the * method used). */ enum DataVectorType { - type_dof_data, type_cell_data, type_automatic + /// Data vector entries are associated to degrees of freedom + type_dof_data, + /// Data vector entries are one per grid cell + type_cell_data, + /// Find out automatically + type_automatic }; /** @@ -244,8 +254,8 @@ class DataOut_DoFData : public DataOutInterface * case, you can change the last * argument of the function from * its default value - * @p type_automatic to either - * @p type_dof_data or @p type_cell_data, + * #type_automatic to either + * #type_dof_data or #type_cell_data, * depending on what the vector * represents. Apart from this * corner case, you can leave the @@ -270,16 +280,16 @@ class DataOut_DoFData : public DataOutInterface * shall only contain characters * which are letters, underscore * and a few other ones. Refer to - * the @p ExcInvalidCharacter + * the ExcInvalidCharacter * exception declared in this * class to see which characters * are valid and which are not. * * The actual type for the template * argument may be any vector type from - * which FEValue can extract values + * which FEValues can extract values * on a cell using the - * @p get_function_values function. + * FEValuesBase::get_function_values() function. */ template void add_data_vector (const VECTOR &data, @@ -299,7 +309,7 @@ class DataOut_DoFData : public DataOutInterface * after a conversion of the * @p name to a vector of * strings, to the other - * @p add_data_vector function + * add_data_vector() function * above. * * If @p data is a vector with @@ -312,9 +322,9 @@ class DataOut_DoFData : public DataOutInterface * * The actual type for the template * argument may be any vector type from - * which FEValue can extract values + * which FEValues can extract values * on a cell using the - * @p get_function_values function. + * FEValuesBase::get_function_values() function. */ template void add_data_vector (const VECTOR &data, @@ -414,7 +424,7 @@ class DataOut_DoFData : public DataOutInterface * data vectors and the DoF * handler. You have to set all * data entries again using the - * @p add_data_vector + * add_data_vector() * function. The pointer to the * dof handler is cleared as * well, along with all other @@ -528,7 +538,7 @@ class DataOut_DoFData : public DataOutInterface get_cell_data_value (const unsigned int cell_number) const = 0; /** - * Given a @p FEValuesBase object, + * Given a FEValuesBase object, * extract the values on the present * cell from the vector we actually * store. @@ -539,7 +549,7 @@ class DataOut_DoFData : public DataOutInterface std::vector &patch_values) const = 0; /** - * Given a @p FEValuesBase object, + * Given a FEValuesBase object, * extract the values on the present * cell from the vector we actually * store. This function does the same @@ -602,7 +612,7 @@ class DataOut_DoFData : public DataOutInterface get_cell_data_value (const unsigned int cell_number) const; /** - * Given a @p FEValuesBase object, + * Given a FEValuesBase object, * extract the values on the present * cell from the vector we actually * store. @@ -613,7 +623,7 @@ class DataOut_DoFData : public DataOutInterface std::vector &patch_values) const; /** - * Given a @p FEValuesBase object, + * Given a FEValuesBase object, * extract the values on the present * cell from the vector we actually * store. This function does the same @@ -652,7 +662,7 @@ class DataOut_DoFData : public DataOutInterface /** * Abbreviate the somewhat lengthy - * name for the @p Patch class. + * name for the Patch class. */ typedef ::DataOutBase::Patch Patch; @@ -675,7 +685,7 @@ class DataOut_DoFData : public DataOutInterface /** * This is a list of patches that is - * created each time @p build_patches + * created each time build_patches() * is called. These patches are used * in the output routines of the base * classes. @@ -702,7 +712,7 @@ class DataOut_DoFData : public DataOutInterface /** * Make all template siblings * friends. Needed for the - * @p merge_patches function. + * merge_patches() function. */ template friend class DataOut_DoFData; @@ -737,7 +747,7 @@ class DataOut_DoFData : public DataOutInterface /** * This class is an actual implementation of the functionality proposed by - * the DataOut_DoFData() class. It offers a function @p build_patches that + * the DataOut_DoFData class. It offers a function build_patches() that * generates the patches to be written in some graphics format from the data * stored in the base class. Most of the interface and an example of its * use is described in the documentation of the base class. @@ -759,8 +769,8 @@ class DataOut_DoFData : public DataOutInterface * output is to subdivide each cell of the mesh into several cells for * graphical output. * - * Note that after having called @p build_patches once, you can call one or - * more of the write_* functions of the base classes. You can therefore + * Note that after having called build_patches() once, you can call one or + * more of the write() functions of DataOutInterface. You can therefore * output the same data in more than one format without having to rebuild * the patches. * @@ -786,9 +796,9 @@ class DataOut_DoFData : public DataOutInterface * region of the domain (for example in parallel programs such as the step-18 * example program), or for some other reason. * - * For this, internally the @p build_patches function does not generate + * For this, internally build_patches() does not generate * the sequence of cells to be converted into patches itself, but relies - * on the two functions @p first_cell and @p next_cell. By default, they + * on the two functions first_cell() and next_cell(). By default, they * return the first active cell, and the next active cell, respectively. * Since they are @p virtual functions, you may overload them to select other * cells for output. If cells are not active, interpolated values are taken @@ -800,8 +810,8 @@ class DataOut_DoFData : public DataOutInterface * determine the next one. * * There is one caveat, however: if you have cell data (in contrast to nodal, - * or dof, data) such as error indicators, then you must make sure that the @p - * first_cell and @p next_cell only walk over active cells, since cell data + * or dof, data) such as error indicators, then you must make sure that + * first_cell() and next_cell() only walk over active cells, since cell data * cannot be interpolated to a coarser cell. If you do have cell data and use * this pair of functions and they return a non-active cell, then an exception * will be thrown. @@ -888,7 +898,7 @@ class DataOut : public DataOut_DoFData * Return the next cell after * @p cell which we want output * for. If there are no more - * cells, dofs->end() shall + * cells, #dofs->end() shall * be returned. * * The default implementation @@ -899,7 +909,7 @@ class DataOut : public DataOut_DoFData * implementation assumes that * the given @p cell is active, * which is guaranteed as long as - * @p first_cell is also used + * first_cell() is also used * from the default * implementation. Overloading * only one of the two functions @@ -924,7 +934,7 @@ class DataOut : public DataOut_DoFData * globally to avoid allocation * of memory in the threads. * - * The @p index_to_patch_map is + * The #index_to_patch_map is * an array that stores for index * [i][j] the number of the * patch that associated with the diff --git a/deal.II/deal.II/include/numerics/derivative_approximation.h b/deal.II/deal.II/include/numerics/derivative_approximation.h index 653f6f5d9d..a19944c5cd 100644 --- a/deal.II/deal.II/include/numerics/derivative_approximation.h +++ b/deal.II/deal.II/include/numerics/derivative_approximation.h @@ -79,7 +79,7 @@ * gradients themselves. * * - * @sect2{Approximation of higher derivatives} + *

Approximation of higher derivatives

* * Similar to the reasoning above, approximations to higher * derivatives can be computed in a similar fashion. For example, the @@ -114,7 +114,7 @@ * same lines as exposed above. * * - * @sect2{Refinement indicators based on the derivatives} + *

Refinement indicators based on the derivatives

* * If you would like to base a refinement criterion upon these * approximation of the derivatives, you will have to scale the results @@ -129,7 +129,7 @@ * the mesh size $h$ one higher than for the gradient. * * - * @sect2{Implementation} + *

Implementation

* * The formulae for the computation of approximations to the gradient * and to the tensor of second derivatives shown above are very much diff --git a/deal.II/deal.II/include/numerics/error_estimator.h b/deal.II/deal.II/include/numerics/error_estimator.h index f0cb4435ff..5ca9f0be90 100644 --- a/deal.II/deal.II/include/numerics/error_estimator.h +++ b/deal.II/deal.II/include/numerics/error_estimator.h @@ -55,7 +55,7 @@ template class FESubfaceValues; * a lot of memory, when using many cells. * * - * @sect3{Implementation} + *

Implementation

* * In principle, the implementation of the error estimation is simple: let * \f[ @@ -97,7 +97,7 @@ template class FESubfaceValues; * the diameter of the cell. * * - * @sect3{Vector-valued functions} + *

Vector-valued functions

* * If the finite element field for which the error is to be estimated * is vector-valued, i.e. the finite element has more than one @@ -119,7 +119,7 @@ template class FESubfaceValues; * a scalar coefficient which will then be used for all components. * * - * @sect3{Boundary values} + *

Boundary values

* * 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: @@ -157,7 +157,7 @@ template class FESubfaceValues; * conditions. * * - * @sect3{Handling of hanging nodes} + *

Handling of hanging nodes

* * The integration along faces with hanging nodes is quite tricky, since one * of the elements has to be shifted one level up or down. See the @@ -182,7 +182,7 @@ template class FESubfaceValues; * above. * * - * @sect3{Multiple solution vectors} + *

Multiple solution vectors

* * In some cases, for example in time-dependent problems, one would * like to compute the error estimates for several solution vectors diff --git a/deal.II/deal.II/include/numerics/histogram.h b/deal.II/deal.II/include/numerics/histogram.h index 23ef4afef4..c9d63d642c 100644 --- a/deal.II/deal.II/include/numerics/histogram.h +++ b/deal.II/deal.II/include/numerics/histogram.h @@ -33,7 +33,7 @@ * intervals are used for each of them anyway, to make comparison easier. * * - * @sect3{Ways to generate the intervals} + *

Ways to generate the intervals

* * At present, the following schemes for interval spacing are implemented: *
    @@ -54,7 +54,7 @@ * code. * * - * @sect3{Output formats} + *

    Output formats

    * * At present, only GNUPLOT output is supported. * diff --git a/deal.II/deal.II/include/numerics/matrices.h b/deal.II/deal.II/include/numerics/matrices.h index 255d1e2e48..dd0711a0b4 100644 --- a/deal.II/deal.II/include/numerics/matrices.h +++ b/deal.II/deal.II/include/numerics/matrices.h @@ -57,7 +57,7 @@ namespace PETScWrappers * necessary to create an object of this type, though you may do so. * * - * @sect3{Conventions for all functions} + *

    Conventions for all functions

    * * There exist two versions of each function. One with a Mapping * argument and one without. If a code uses a mapping different from @@ -104,7 +104,7 @@ namespace PETScWrappers * side. * * - * @sect3{Supported matrices} + *

    Supported matrices

    * * At present there are functions to create the following matrices: *
      @@ -144,7 +144,7 @@ namespace PETScWrappers * finite element. * * - * @sect3{Matrices on the boundary} + *

      Matrices on the boundary

      * * The @p create_boundary_mass_matrix creates the matrix with entries * $m_{ij} = \int_{\Gamma} \phi_i \phi_j dx$, where $\Gamma$ is the @@ -173,7 +173,7 @@ namespace PETScWrappers * triangulation object. * * - * @sect3{Right hand sides} + *

      Right hand sides

      * * In many cases, you will not only want to build the matrix, but also * a right hand side, which will give a vector with @@ -565,7 +565,7 @@ class MatrixCreator * and others. * * - * @sect3{Boundary conditions} + *

      Boundary conditions

      * * The apply_boundary_values() function inserts boundary conditions * into a system of equations. To actually do this you have to @@ -578,7 +578,7 @@ class MatrixCreator * nodes into a linear system, as discussed below. * * - * @sect3{Global elimination} + *

      Global elimination

      * * In the first method, we first assemble the global linear system without * respect for fixed degrees of freedom, and in a second step eliminate them @@ -677,7 +677,7 @@ class MatrixCreator * values. * * - * @sect3{Local elimination} + *

      Local elimination

      * * The second way of handling boundary values is to modify the local * matrix and vector contributions appropriately before transferring diff --git a/deal.II/deal.II/include/numerics/solution_transfer.h b/deal.II/deal.II/include/numerics/solution_transfer.h index b8a60335e4..1f316c5a64 100644 --- a/deal.II/deal.II/include/numerics/solution_transfer.h +++ b/deal.II/deal.II/include/numerics/solution_transfer.h @@ -32,7 +32,7 @@ * vector is reinitialized to the new size and filled with the interpolated * values. * - * @sect3{Usage} + *

      Usage

      * * As the interpolation while * coarsening is much more complicated to organize @@ -131,7 +131,7 @@ * to transfer. * * - * @sect3{Implementation} + *

      Implementation

      * *
        *
      • Solution transfer while pure refinement. Assume that we have got a diff --git a/deal.II/deal.II/include/numerics/time_dependent.h b/deal.II/deal.II/include/numerics/time_dependent.h index 3d2b71e98d..a61b06bb5e 100644 --- a/deal.II/deal.II/include/numerics/time_dependent.h +++ b/deal.II/deal.II/include/numerics/time_dependent.h @@ -52,7 +52,7 @@ template class Triangulation; * use the same setup and therefore this class. * * - * @sect3{Overview} + *

        Overview

        * * The general structure of a time dependent problem solver using a timestepping * scheme is about the following: we have a collection of time step objects @@ -180,7 +180,7 @@ template class Triangulation; * problem, this order is reversed. * * - * @sect3{Implementation} + *

        Implementation

        * * The main loop of a program using this class will usually look like * the following one, taken modified from an application program that @@ -1245,7 +1245,7 @@ namespace TimeStepBase_Tria_Flags *
      * * - * @sect3{Description of flags} + *

      Description of flags

      * *
        *
      • @p max_refinement_level: Cut the refinement of cells at a given level. -- 2.39.5