From ddac7620ccda2c27e7f9f7ff87e729b1935d61ff Mon Sep 17 00:00:00 2001 From: Timo Heister Date: Mon, 23 Feb 2015 16:20:40 -0500 Subject: [PATCH] run wrapcomments --- include/deal.II/base/function.h | 51 ++++---- include/deal.II/base/index_set.h | 28 ++--- include/deal.II/base/mpi.h | 33 +++-- include/deal.II/base/multithread_info.h | 6 +- include/deal.II/base/point.h | 117 +++++++++--------- include/deal.II/base/polynomials_bdm.h | 4 +- include/deal.II/base/std_cxx11/unique_ptr.h | 29 ++--- include/deal.II/base/symmetric_tensor.h | 33 +++-- include/deal.II/base/template_constraints.h | 110 ++++++++-------- include/deal.II/base/tensor.h | 95 +++++++------- include/deal.II/base/tensor_base.h | 87 +++++++------ include/deal.II/distributed/tria.h | 3 +- include/deal.II/fe/fe.h | 18 +-- include/deal.II/fe/fe_dgp.h | 46 +++---- include/deal.II/fe/fe_dgp_monomial.h | 46 +++---- include/deal.II/fe/fe_dgp_nonparametric.h | 46 +++---- include/deal.II/fe/fe_q_hierarchical.h | 104 ++++++++-------- include/deal.II/fe/fe_system.h | 50 ++++---- include/deal.II/grid/grid_generator.h | 26 ++-- include/deal.II/grid/tria_accessor.h | 25 ++-- include/deal.II/hp/dof_faces.h | 24 ++-- include/deal.II/hp/dof_handler.h | 12 +- include/deal.II/hp/dof_level.h | 6 +- include/deal.II/lac/block_matrix_array.h | 15 +-- include/deal.II/lac/constraint_matrix.h | 49 ++++---- include/deal.II/lac/filtered_matrix.h | 4 +- include/deal.II/lac/lapack_full_matrix.h | 27 ++-- include/deal.II/lac/solver_control.h | 5 +- include/deal.II/lac/solver_gmres.h | 3 +- include/deal.II/lac/sparse_direct.h | 6 +- include/deal.II/lac/sparse_mic.h | 4 +- include/deal.II/lac/trilinos_precondition.h | 55 ++++---- include/deal.II/matrix_free/matrix_free.h | 4 +- .../deal.II/multigrid/mg_transfer_component.h | 5 +- include/deal.II/numerics/data_out.h | 66 +++++----- include/deal.II/numerics/data_out_dof_data.h | 46 ++++--- include/deal.II/numerics/data_out_faces.h | 13 +- include/deal.II/numerics/data_out_rotation.h | 17 ++- include/deal.II/numerics/data_out_stack.h | 15 ++- include/deal.II/numerics/fe_field_function.h | 9 +- include/deal.II/numerics/vector_tools.h | 23 ++-- 41 files changed, 647 insertions(+), 718 deletions(-) diff --git a/include/deal.II/base/function.h b/include/deal.II/base/function.h index 30f7cc011d..04e37d5302 100644 --- a/include/deal.II/base/function.h +++ b/include/deal.II/base/function.h @@ -80,13 +80,13 @@ template class TensorFunction; * vector_value(), and gradient analogs), while those ones will throw an * exception when called but not overloaded. * - * Conversely, the functions returning all components of the function at - * one or several points (i.e. vector_value(), vector_value_list()), - * will not call the function returning one component at - * one point repeatedly, once for each point and component. The reason is - * efficiency: this would amount to too many virtual function calls. If you - * have vector-valued functions, you should therefore also provide overloads - * of the virtual functions for all components at a time. + * Conversely, the functions returning all components of the function at one + * or several points (i.e. vector_value(), vector_value_list()), will + * not call the function returning one component at one point + * repeatedly, once for each point and component. The reason is efficiency: + * this would amount to too many virtual function calls. If you have vector- + * valued functions, you should therefore also provide overloads of the + * virtual functions for all components at a time. * * Also note, that unless only called a very small number of times, you should * overload all sets of functions (returning only one value, as well as those @@ -99,31 +99,28 @@ template class TensorFunction; * *

Functions that return tensors

* - * If the functions you are dealing with have a number of - * components that are a priori known (for example, dim - * elements), you might consider using the TensorFunction class - * instead. This is, in particular, true if the objects you return - * have the properties of a tensor, i.e., they are for example - * dim-dimensional vectors or dim-by-dim matrices. On the other hand, + * If the functions you are dealing with have a number of components that are + * a priori known (for example, dim elements), you might consider + * using the TensorFunction class instead. This is, in particular, true if the + * objects you return have the properties of a tensor, i.e., they are for + * example dim-dimensional vectors or dim-by-dim matrices. On the other hand, * functions like VectorTools::interpolate or - * VectorTools::interpolate_boundary_values definitely only want - * objects of the current type. You can use the - * VectorFunctionFromTensorFunction class to convert the former to the - * latter. + * VectorTools::interpolate_boundary_values definitely only want objects of + * the current type. You can use the VectorFunctionFromTensorFunction class to + * convert the former to the latter. * * *

Functions that return different fields

* - * Most of the time, your functions will have the form - * $f : \Omega \rightarrow {\mathbb R}^{n_\text{components}}$. However, - * there are occasions where you want the function to return vectors (or - * scalars) over a different number field, for example functions that - * return complex numbers or vectors of complex numbers: - * $f : \Omega \rightarrow {\mathbb C}^{n_\text{components}}$. In such - * cases, you can use the second template argument of this class: it - * describes the scalar type to be used for each component of your return - * values. It defaults to @p double, but in the example above, it could - * be set to std::complex@. + * Most of the time, your functions will have the form $f : \Omega \rightarrow + * {\mathbb R}^{n_\text{components}}$. However, there are occasions where you + * want the function to return vectors (or scalars) over a different number + * field, for example functions that return complex numbers or vectors of + * complex numbers: $f : \Omega \rightarrow {\mathbb + * C}^{n_\text{components}}$. In such cases, you can use the second template + * argument of this class: it describes the scalar type to be used for each + * component of your return values. It defaults to @p double, but in the + * example above, it could be set to std::complex@. * * * @ingroup functions diff --git a/include/deal.II/base/index_set.h b/include/deal.II/base/index_set.h index 89ccbeffba..759da23ad0 100644 --- a/include/deal.II/base/index_set.h +++ b/include/deal.II/base/index_set.h @@ -60,23 +60,21 @@ class IndexSet { public: /** - * One can see an IndexSet as a container of size size(), where the - * elements of the containers are bool values that are either false - * or true, depending on whether a particular index is an element of - * the IndexSet or not. In other words, an IndexSet is a bit like a - * vector in which the elements we store are booleans. In this view, - * the correct local typedef indicating the type of the elements of - * the vector would then be @p bool. + * One can see an IndexSet as a container of size size(), where the elements + * of the containers are bool values that are either false or true, + * depending on whether a particular index is an element of the IndexSet or + * not. In other words, an IndexSet is a bit like a vector in which the + * elements we store are booleans. In this view, the correct local typedef + * indicating the type of the elements of the vector would then be @p bool. * * On the other hand, @p bool has the disadvantage that it is not a - * numerical type that, for example, allows multiplication with a @p - * double. In other words, one can not easily use a vector of - * booleans in a place where other vectors are - * allowed. Consequently, we declare the type of the elements of - * such a vector as a signed integer. This uses the fact that in the - * C++ language, booleans are implicitly convertible to integers. In - * other words, declaring the type of the elements of the vector as - * a signed integer is only a small lie, but it is a useful one. + * numerical type that, for example, allows multiplication with a @p double. + * In other words, one can not easily use a vector of booleans in a place + * where other vectors are allowed. Consequently, we declare the type of the + * elements of such a vector as a signed integer. This uses the fact that in + * the C++ language, booleans are implicitly convertible to integers. In + * other words, declaring the type of the elements of the vector as a signed + * integer is only a small lie, but it is a useful one. */ typedef signed int value_type; diff --git a/include/deal.II/base/mpi.h b/include/deal.II/base/mpi.h index 0f2bf7f21f..34bbc4d462 100644 --- a/include/deal.II/base/mpi.h +++ b/include/deal.II/base/mpi.h @@ -279,19 +279,18 @@ namespace Utilities * main. * @param[in] max_num_threads The maximal number of threads this MPI * process should utilize. If this argument is set to - * numbers::invalid_unsigned_int (the default value), - * then the number of threads is determined - * automatically in the following way: the number of threads to run on - * this MPI process is set in such a way that all of the cores in your - * node are spoken for. In other words, if you have started one MPI - * process per node, setting this argument is equivalent to setting it - * to the number of cores present in the node this MPI process runs on. - * If you have started as many MPI processes per node as there are cores - * on each node, then this is equivalent to passing 1 as the argument. - * On the other hand, if, for example, you start 4 MPI processes on each - * 16-core node, then this option will start 4 worker threads for each - * node. If you start 3 processes on an 8 core node, then they will - * start 3, 3 and 2 threads, respectively. + * numbers::invalid_unsigned_int (the default value), then the number of + * threads is determined automatically in the following way: the number + * of threads to run on this MPI process is set in such a way that all + * of the cores in your node are spoken for. In other words, if you have + * started one MPI process per node, setting this argument is equivalent + * to setting it to the number of cores present in the node this MPI + * process runs on. If you have started as many MPI processes per node + * as there are cores on each node, then this is equivalent to passing 1 + * as the argument. On the other hand, if, for example, you start 4 MPI + * processes on each 16-core node, then this option will start 4 worker + * threads for each node. If you start 3 processes on an 8 core node, + * then they will start 3, 3 and 2 threads, respectively. * * @note This function calls MultithreadInfo::set_thread_limit() with * either @p max_num_threads or, following the discussion above, a @@ -308,10 +307,10 @@ namespace Utilities * * @note MultithreadInfo::set_thread_limit() can only work if it is * called before any threads are created. The safest place for a call to - * it is therefore at the beginning of - * main(). Consequently, this extends to the current class: - * the best place to create an object of this type is also at or close - * to the top of main(). + * it is therefore at the beginning of main(). + * Consequently, this extends to the current class: the best place to + * create an object of this type is also at or close to the top of + * main(). */ MPI_InitFinalize (int &argc, char ** &argv, diff --git a/include/deal.II/base/multithread_info.h b/include/deal.II/base/multithread_info.h index df2951b350..a28c179612 100644 --- a/include/deal.II/base/multithread_info.h +++ b/include/deal.II/base/multithread_info.h @@ -37,9 +37,9 @@ DEAL_II_NAMESPACE_OPEN * @ref threads * for more information on this. Thread-based parallel methods need to * explicitly created threads and may want to use a number of threads that is - * related to the number of CPUs in your system. The recommended number of threads - * can be queried using MultithreadInfo::n_threads(), while the number of cores - * in the system is returned by MultithreadInfo::n_cores(). + * related to the number of CPUs in your system. The recommended number of + * threads can be queried using MultithreadInfo::n_threads(), while the number + * of cores in the system is returned by MultithreadInfo::n_cores(). * * @ingroup threads * @author Thomas Richter, Wolfgang Bangerth, 2000 diff --git a/include/deal.II/base/point.h b/include/deal.II/base/point.h index 4a3a6cf919..8d9af919a7 100644 --- a/include/deal.II/base/point.h +++ b/include/deal.II/base/point.h @@ -28,60 +28,58 @@ DEAL_II_NAMESPACE_OPEN * A class that represents a point in a space with arbitrary dimension * dim. * - * Objects of this class are used to represent points, i.e., vectors - * anchored at the origin of a Cartesian vector space. They are, among - * other uses, passed to functions that operate on points in spaces of - * a priori fixed dimension: rather than using functions like - * double f(double x) and double f(double x, double - * y), you should use double f(Point &p) instead as - * it allows writing dimension independent code. + * Objects of this class are used to represent points, i.e., vectors anchored + * at the origin of a Cartesian vector space. They are, among other uses, + * passed to functions that operate on points in spaces of a priori fixed + * dimension: rather than using functions like double f(double x) and + * double f(double x, double y), you should use double + * f(Point &p) instead as it allows writing dimension independent + * code. * * - *

What's a Point@ and what is a Tensor@<1,dim@>?

+ *

What's a Point@ and what is a + * Tensor@<1,dim@>?

* - * The Point class is derived from Tensor@<1,dim@> and consequently - * shares the latter's member functions and other attributes. In fact, - * it has relatively few additional functions itself (the most notable - * exception being the distance() function to compute the Euclidean - * distance between two points in space), and these two classes can - * therefore often be used interchangeably. + * The Point class is derived from Tensor@<1,dim@> and consequently shares the + * latter's member functions and other attributes. In fact, it has relatively + * few additional functions itself (the most notable exception being the + * distance() function to compute the Euclidean distance between two points in + * space), and these two classes can therefore often be used interchangeably. * - * Nonetheless, there are semantic differences that make us use these - * classes in different and well-defined contexts. Within deal.II, we - * use the Point class to denote points in space, i.e., for - * vectors (rank-1 tensors) that are anchored at the - * origin. On the other hand, vectors that are anchored elsewhere - * (and consequently do not represent points in the common - * usage of the word) are represented by objects of type - * Tensor@<1,dim@>. In particular, this is the case for direction - * vectors, normal vectors, gradients, and the differences between two - * points (i.e., what you get when you subtract one point from - * another): all of these are represented by Tensor@<1,dim@> objects - * rather than Point@. + * Nonetheless, there are semantic differences that make us use these classes + * in different and well-defined contexts. Within deal.II, we use the + * Point class to denote points in space, i.e., for vectors (rank-1 + * tensors) that are anchored at the origin. On the other hand, + * vectors that are anchored elsewhere (and consequently do not represent + * points in the common usage of the word) are represented by objects + * of type Tensor@<1,dim@>. In particular, this is the case for direction + * vectors, normal vectors, gradients, and the differences between two points + * (i.e., what you get when you subtract one point from another): all of these + * are represented by Tensor@<1,dim@> objects rather than Point@. * - * Furthermore, the Point class is only used where the coordinates of - * an object can be thought to possess the dimension of a length. An - * object that represents the weight, height, and cost of an object is - * neither a point nor a tensor (because it lacks the transformation - * properties under rotation of the coordinate system) and should - * consequently not be represented by either of these classes. Use an - * array of size 3 in this case, or the std_cxx11::array - * class. Alternatively, as in the case of vector-valued functions, - * you can use objects of type Vector or std::vector. + * Furthermore, the Point class is only used where the coordinates of an + * object can be thought to possess the dimension of a length. An object that + * represents the weight, height, and cost of an object is neither a point nor + * a tensor (because it lacks the transformation properties under rotation of + * the coordinate system) and should consequently not be represented by either + * of these classes. Use an array of size 3 in this case, or the + * std_cxx11::array class. Alternatively, as in the case of + * vector-valued functions, you can use objects of type Vector or + * std::vector. * * - * @tparam dim An integer that denotes the dimension of the space in which - * a point lies. This of course equals the number of coordinates that - * identify a point. - * @tparam Number The data type in which the coordinates values are - * to be stored. This will, in almost all cases, simply be the default - * @p double, but there are cases where one may want to store coordinates - * in a different (and always scalar) type. An example would be an interval - * type that can store the value of a coordinate as well as its uncertainty. - * Another example would be a type that allows for Automatic Differentiation - * (see, for example, the Sacado type used in step-33) and thereby can - * generate analytic (spatial) derivatives of a function when passed a - * Point object whose coordinates are stored in such a type. + * @tparam dim An integer that denotes the dimension of the space in which a + * point lies. This of course equals the number of coordinates that identify a + * point. + * @tparam Number The data type in which the coordinates values are to be + * stored. This will, in almost all cases, simply be the default @p double, + * but there are cases where one may want to store coordinates in a different + * (and always scalar) type. An example would be an interval type that can + * store the value of a coordinate as well as its uncertainty. Another example + * would be a type that allows for Automatic Differentiation (see, for + * example, the Sacado type used in step-33) and thereby can generate analytic + * (spatial) derivatives of a function when passed a Point object whose + * coordinates are stored in such a type. * * * @ingroup geomprimitives @@ -139,9 +137,9 @@ public: const Number z); /** - * Return a unit vector in coordinate direction i, i.e., a - * vector that is zero in all coordinates except for a single 1 in - * the ith coordinate. + * Return a unit vector in coordinate direction i, i.e., a vector + * that is zero in all coordinates except for a single 1 in the ith + * coordinate. */ static Point unit_vector(const unsigned int i); @@ -166,20 +164,19 @@ public: Point operator + (const Tensor<1,dim,Number> &) const; /** - * Subtract two points, i.e., obtain the vector that connects the - * two. As discussed in the documentation of this class, subtracting - * two points results in a vector anchored at one of the two points - * (rather than at the origin) and, consequently, the result is - * returned as a Tensor@<1,dim@> rather than as a Point@. + * Subtract two points, i.e., obtain the vector that connects the two. As + * discussed in the documentation of this class, subtracting two points + * results in a vector anchored at one of the two points (rather than at the + * origin) and, consequently, the result is returned as a Tensor@<1,dim@> + * rather than as a Point@. */ Tensor<1,dim,Number> operator - (const Point &) const; /** - * Subtract a difference vector (represented by a Tensor@<1,dim@>) - * from the current point. This results in another point and, as - * discussed in the documentation of this class, the result is then - * naturally returned as a Point@ object rather than as a - * Tensor@<1,dim@>. + * Subtract a difference vector (represented by a Tensor@<1,dim@>) from the + * current point. This results in another point and, as discussed in the + * documentation of this class, the result is then naturally returned as a + * Point@ object rather than as a Tensor@<1,dim@>. */ Point operator - (const Tensor<1,dim,Number> &) const; diff --git a/include/deal.II/base/polynomials_bdm.h b/include/deal.II/base/polynomials_bdm.h index 5845574543..c181983ae2 100644 --- a/include/deal.II/base/polynomials_bdm.h +++ b/include/deal.II/base/polynomials_bdm.h @@ -46,8 +46,8 @@ DEAL_II_NAMESPACE_OPEN * (xk-iyzi+1,0,0) and * (0,xi+1yk-iz,0) * - * Note the curl of a scalar function is given by - * $\text{curl}(f(x,y)) = \begin{pmatrix} f_{y}(x,y) \\ -f_{x}(x,y) \end{pmatrix}$. + * Note the curl of a scalar function is given by $\text{curl}(f(x,y)) = + * \begin{pmatrix} f_{y}(x,y) \\ -f_{x}(x,y) \end{pmatrix}$. * @todo Second derivatives in 3D are missing. * * @ingroup Polynomials diff --git a/include/deal.II/base/std_cxx11/unique_ptr.h b/include/deal.II/base/std_cxx11/unique_ptr.h index 9e4f931310..11e226d9fd 100644 --- a/include/deal.II/base/std_cxx11/unique_ptr.h +++ b/include/deal.II/base/std_cxx11/unique_ptr.h @@ -36,26 +36,23 @@ DEAL_II_NAMESPACE_OPEN namespace std_cxx11 { /** - * Implementation of a basic replacement for C++11's std::unique_ptr - * class. + * Implementation of a basic replacement for C++11's std::unique_ptr class. * - * BOOST does not have a replacement for std::unique_ptr (because - * unique_ptr requires move semantics that aren't available unless - * you have a C++11 compiler -- in which case you also have - * std::unique_ptr; see for example + * BOOST does not have a replacement for std::unique_ptr (because unique_ptr + * requires move semantics that aren't available unless you have a C++11 + * compiler -- in which case you also have std::unique_ptr; see for example * http://stackoverflow.com/questions/2953530/unique-ptr-boost-equivalent) * - * Consequently, we emulate the class by just wrapping a - * boost::shared_ptr in the cheapest possible way -- by just - * deriving from it and repeating the basic constructors. Everything - * else is inherited from the shared_ptr class. + * Consequently, we emulate the class by just wrapping a boost::shared_ptr + * in the cheapest possible way -- by just deriving from it and repeating + * the basic constructors. Everything else is inherited from the shared_ptr + * class. * - * This replacement comes with a certain overhead: doing reference - * counting instead of just passing ownership of pointers has a - * cost. But we don't use unique_ptrs in expensive places, and it is - * also a cost that will disappear once we require C++11 (and the - * cost of course does not apply if your compiler already supports - * C++11 and deal.II uses it). + * This replacement comes with a certain overhead: doing reference counting + * instead of just passing ownership of pointers has a cost. But we don't + * use unique_ptrs in expensive places, and it is also a cost that will + * disappear once we require C++11 (and the cost of course does not apply if + * your compiler already supports C++11 and deal.II uses it). */ template class unique_ptr : public boost::shared_ptr diff --git a/include/deal.II/base/symmetric_tensor.h b/include/deal.II/base/symmetric_tensor.h index 52b922de13..0b42c16f3d 100644 --- a/include/deal.II/base/symmetric_tensor.h +++ b/include/deal.II/base/symmetric_tensor.h @@ -552,9 +552,9 @@ public: SymmetricTensor (const Number (&array) [n_independent_components]); /** - * Copy constructor from tensors with different underlying scalar - * type. This obviously requires that the @p OtherNumber type is - * convertible to @p Number. + * Copy constructor from tensors with different underlying scalar type. This + * obviously requires that the @p OtherNumber type is convertible to @p + * Number. */ template explicit @@ -2666,10 +2666,9 @@ symmetrize (const Tensor<2,3,Number> &t) /** - * Multiplication of a symmetric tensor of general rank with a scalar - * from the right. This version of the operator is used if the scalar - * has the same data type as is used to store the elements of the - * symmetric tensor. + * Multiplication of a symmetric tensor of general rank with a scalar from the + * right. This version of the operator is used if the scalar has the same data + * type as is used to store the elements of the symmetric tensor. * * @relates SymmetricTensor */ @@ -2688,9 +2687,8 @@ operator * (const SymmetricTensor &t, /** * Multiplication of a symmetric tensor of general rank with a scalar from the - * left. This version of the operator is used if the scalar - * has the same data type as is used to store the elements of the - * symmetric tensor. + * left. This version of the operator is used if the scalar has the same data + * type as is used to store the elements of the symmetric tensor. * * @relates SymmetricTensor */ @@ -2718,13 +2716,14 @@ operator * (const Number factor, * prohibited of considering this operator for multiplication with non-scalar * types are explained in the documentation of the EnableIfScalar class. * - * The return type of the function is chosen so that it matches the types - * of both the tensor and the scalar argument. For example, if you multiply - * a SymmetricTensor@<2,dim,double@> by std::complex@, - * then the result will be a SymmetricTensor@<2,dim,std::complex@@>. - * In other words, the type with which the returned tensor stores its - * components equals the type you would get if you multiplied an individual - * component of the input tensor by the scalar factor. + * The return type of the function is chosen so that it matches the types of + * both the tensor and the scalar argument. For example, if you multiply a + * SymmetricTensor@<2,dim,double@> by + * std::complex@, then the result will be a + * SymmetricTensor@<2,dim,std::complex@@>. In other + * words, the type with which the returned tensor stores its components equals + * the type you would get if you multiplied an individual component of the + * input tensor by the scalar factor. * * @relates SymmetricTensor * @relates EnableIfScalar diff --git a/include/deal.II/base/template_constraints.h b/include/deal.II/base/template_constraints.h index da97f7e93c..a8f08c7436 100644 --- a/include/deal.II/base/template_constraints.h +++ b/include/deal.II/base/template_constraints.h @@ -301,10 +301,10 @@ struct types_are_equal /** - * A class with a local typedef that represents the type that results from - * the product of two variables of type @p T and @p U. In other words, - * we would like to infer the type of the product variable - * in code like this: + * A class with a local typedef that represents the type that results from the + * product of two variables of type @p T and @p U. In other words, we would + * like to infer the type of the product variable in code like + * this: * @code * T t; * U u; @@ -316,37 +316,35 @@ struct types_are_equal * *

Where is this useful

* - * The purpose of this class is principally to represent the type one needs - * to use to represent the values or gradients of finite element fields at + * The purpose of this class is principally to represent the type one needs to + * use to represent the values or gradients of finite element fields at * quadrature points. For example, assume you are storing the values $U_j$ of - * unknowns in a Vector, then evaluating - * $u_h(x_q) = \sum_j U_j \varphi_j(x_q)$ at quadrature points results - * in values $u_h(x_q)$ that need to be stored as @p double variables - * because the $U_j$ are @p float values and the $\varphi_j(x_q)$ are - * computed as @p double values, and the product are then @p double - * values. On the other hand, if you store your unknowns $U_j$ as - * std::complex@ values and you try to evaluate + * unknowns in a Vector, then evaluating $u_h(x_q) = \sum_j U_j + * \varphi_j(x_q)$ at quadrature points results in values $u_h(x_q)$ that need + * to be stored as @p double variables because the $U_j$ are @p float values + * and the $\varphi_j(x_q)$ are computed as @p double values, and the product + * are then @p double values. On the other hand, if you store your unknowns + * $U_j$ as std::complex@ values and you try to evaluate * $\nabla u_h(x_q) = \sum_j U_j \nabla\varphi_j(x_q)$ at quadrature points, - * then the gradients $\nabla u_h(x_q)$ need to be stored as objects of - * type Tensor@<1,dim,std::complex@@> because - * that's what you get when you multiply a complex number by a - * Tensor@<1,dim@> (the type used to represent the gradient - * of shape functions of scalar finite elements). + * then the gradients $\nabla u_h(x_q)$ need to be stored as objects of type + * Tensor@<1,dim,std::complex@@> because that's what you + * get when you multiply a complex number by a Tensor@<1,dim@> + * (the type used to represent the gradient of shape functions of scalar + * finite elements). * * Likewise, if you are using a vector valued element (with dim components) - * and the $U_j$ are stored as @p double variables, then - * $u_h(x_q) = \sum_j U_j \varphi_j(x_q)$ needs to have type - * Tensor@<1,dim@> (because the shape functions have type - * Tensor@<1,dim@>). Finally, if you store the $U_j$ as - * objects of type std::complex@ and you have a - * vector valued element, then the gradients - * $\nabla u_h(x_q) = \sum_j U_j \nabla\varphi_j(x_q)$ will result in - * objects of type - * Tensor@<2,dim,std::complex@ @>. + * and the $U_j$ are stored as @p double variables, then $u_h(x_q) = \sum_j + * U_j \varphi_j(x_q)$ needs to have type Tensor@<1,dim@> + * (because the shape functions have type Tensor@<1,dim@>). + * Finally, if you store the $U_j$ as objects of type + * std::complex@ and you have a vector valued element, + * then the gradients $\nabla u_h(x_q) = \sum_j U_j \nabla\varphi_j(x_q)$ will + * result in objects of type Tensor@<2,dim,std::complex@ + * @>. * - * In all of these cases, this type is used to identify which type needs - * to be used for the result of computing the product of unknowns - * and the values, gradients, or other properties of shape functions. + * In all of these cases, this type is used to identify which type needs to be + * used for the result of computing the product of unknowns and the values, + * gradients, or other properties of shape functions. * * @author Wolfgang Bangerth, 2015 */ @@ -430,53 +428,53 @@ struct ProductType,float> /** - * This class provides a local typedef @p type that is equal to the - * template argument but only if the template argument corresponds to - * a scalar type (i.e., one of the floating point types, signed or unsigned - * integer, or a complex number). If the template type @p T is not a scalar, - * then no class EnableIfScalar@ is declared and, - * consequently, no local typedef is available. + * This class provides a local typedef @p type that is equal to the template + * argument but only if the template argument corresponds to a scalar type + * (i.e., one of the floating point types, signed or unsigned integer, or a + * complex number). If the template type @p T is not a scalar, then no class + * EnableIfScalar@ is declared and, consequently, no local + * typedef is available. * - * The purpose of the class is to disable certain template functions if - * one of the arguments is not a scalar number. By way of (nonsensical) - * example, consider the following function: + * The purpose of the class is to disable certain template functions if one of + * the arguments is not a scalar number. By way of (nonsensical) example, + * consider the following function: * @code * template * T multiply (const T t1, const T t2) { return t1*t2; } * @endcode * This function can be called with any two arguments of the same type @p T. - * This includes arguments for which this clearly makes no sense. Consequently, - * one may want to restrict the function to only scalars, and this can be - * written as + * This includes arguments for which this clearly makes no sense. + * Consequently, one may want to restrict the function to only scalars, and + * this can be written as * @code * template * typename EnableIfScalar::type * multiply (const T t1, const T t2) { return t1*t2; } * @endcode - * At a place where you call the function, the compiler will deduce the - * type @p T from the arguments. For example, in + * At a place where you call the function, the compiler will deduce the type + * @p T from the arguments. For example, in * @code * multiply(1.234, 2.345); * @endcode * it will deduce @p T to be @p double, and because * EnableIfScalar@::type equals @p double, the compiler - * will instantiate a function - * double multiply(const double, const double) from the template - * above. On the other hand, in a context like + * will instantiate a function double multiply(const double, const + * double) from the template above. On the other hand, in a context + * like * @code * std::vector v1, v2; * multiply(v1, v2); * @endcode * the compiler will deduce @p T to be std::vector@ but - * because EnableIfScalar@@>::type does not exist - * the compiler does not consider the template for instantiation. This technique - * is called "Substitution Failure is not an Error (SFINAE)". It makes sure that - * the template function can not even be called, rather than leading to a - * later error about the fact that the operation t1*t2 is not - * defined (or may lead to some nonsensical result). It also allows the - * declaration of overloads of a function such as @p multiply for different - * types of arguments, without resulting in ambiguous call errors by the - * compiler. + * because EnableIfScalar@@>::type does not + * exist the compiler does not consider the template for instantiation. This + * technique is called "Substitution Failure is not an Error (SFINAE)". It + * makes sure that the template function can not even be called, rather than + * leading to a later error about the fact that the operation + * t1*t2 is not defined (or may lead to some nonsensical result). + * It also allows the declaration of overloads of a function such as @p + * multiply for different types of arguments, without resulting in ambiguous + * call errors by the compiler. * * @author Wolfgang Bangerth, 2015 */ diff --git a/include/deal.II/base/tensor.h b/include/deal.II/base/tensor.h index 87e578240a..f9f0232704 100644 --- a/include/deal.II/base/tensor.h +++ b/include/deal.II/base/tensor.h @@ -26,42 +26,40 @@ template class Tensor; template class Tensor<1,dim,Number>; /** - * A general tensor class with an arbitrary rank, i.e. with an - * arbitrary number of indices. The Tensor class provides an indexing operator - * and a bit of infrastructure, but most functionality is recursively handed - * down to tensors of rank 1 or put into external templated functions, e.g. - * the contract family. - * - * Using this tensor class for objects of rank 2 has advantages over - * matrices in many cases since the dimension is known to the compiler - * as well as the location of the data. It is therefore possible to - * produce far more efficient code than for matrices with - * runtime-dependent dimension. It also makes the code easier to read - * because of the semantic difference between a tensor (an object that - * relates to a coordinate system and has transformation properties - * with regard to coordinate rotations and transforms) and matrices - * (which we consider as operators on arbitrary vector spaces related - * to linear algebra things). - * - * @tparam rank_ An integer that denotes the rank of this tensor. A - * rank-0 tensor is a scalar, a rank-1 tensor is a vector with @p dim - * components, a rank-2 tensor is a matrix with dim-by-dim components, - * etc. There are specializations of this class for rank-0 and rank-1 - * tensors. There is also a related class SymmetricTensor for - * tensors of even rank whose elements are symmetric. + * A general tensor class with an arbitrary rank, i.e. with an arbitrary + * number of indices. The Tensor class provides an indexing operator and a bit + * of infrastructure, but most functionality is recursively handed down to + * tensors of rank 1 or put into external templated functions, e.g. the + * contract family. + * + * Using this tensor class for objects of rank 2 has advantages over matrices + * in many cases since the dimension is known to the compiler as well as the + * location of the data. It is therefore possible to produce far more + * efficient code than for matrices with runtime-dependent dimension. It also + * makes the code easier to read because of the semantic difference between a + * tensor (an object that relates to a coordinate system and has + * transformation properties with regard to coordinate rotations and + * transforms) and matrices (which we consider as operators on arbitrary + * vector spaces related to linear algebra things). + * + * @tparam rank_ An integer that denotes the rank of this tensor. A rank-0 + * tensor is a scalar, a rank-1 tensor is a vector with @p dim components, a + * rank-2 tensor is a matrix with dim-by-dim components, etc. There are + * specializations of this class for rank-0 and rank-1 tensors. There is also + * a related class SymmetricTensor for tensors of even rank whose elements are + * symmetric. * @tparam dim An integer that denotes the dimension of the space in which - * this tensor operates. This of course equals the number of coordinates that - * identify a point and rank-1 tensor. - * @tparam Number The data type in which the tensor elements are - * to be stored. This will, in almost all cases, simply be the default - * @p double, but there are cases where one may want to store elements - * in a different (and always scalar) type. It can be used to base - * tensors on @p float or @p complex numbers or any other data type that - * implements basic arithmetic operations. - * Another example would be a type that allows for Automatic Differentiation - * (see, for example, the Sacado type used in step-33) and thereby can - * generate analytic (spatial) derivatives of a function that takes a - * tensor as argument. + * this tensor operates. This of course equals the number of coordinates that + * identify a point and rank-1 tensor. + * @tparam Number The data type in which the tensor elements are to be stored. + * This will, in almost all cases, simply be the default @p double, but there + * are cases where one may want to store elements in a different (and always + * scalar) type. It can be used to base tensors on @p float or @p complex + * numbers or any other data type that implements basic arithmetic operations. + * Another example would be a type that allows for Automatic Differentiation + * (see, for example, the Sacado type used in step-33) and thereby can + * generate analytic (spatial) derivatives of a function that takes a tensor + * as argument. * * @ingroup geomprimitives * @author Wolfgang Bangerth, 1998-2005 @@ -124,9 +122,9 @@ public: Tensor (const array_type &initializer); /** - * Copy constructor from tensors with different underlying scalar - * type. This obviously requires that the @p OtherNumber type is - * convertible to @p Number. + * Copy constructor from tensors with different underlying scalar type. This + * obviously requires that the @p OtherNumber type is convertible to @p + * Number. */ template explicit @@ -168,9 +166,9 @@ public: Tensor &operator = (const Tensor &rhs); /** - * Assignment operator from tensors with different underlying scalar - * type. This obviously requires that the @p OtherNumber type is - * convertible to @p Number. + * Assignment operator from tensors with different underlying scalar type. + * This obviously requires that the @p OtherNumber type is convertible to @p + * Number. */ template Tensor &operator = (const Tensor &rhs); @@ -2027,13 +2025,14 @@ operator * (const Number factor, * prohibited of considering this operator for multiplication with non-scalar * types are explained in the documentation of the EnableIfScalar class. * - * The return type of the function is chosen so that it matches the types - * of both the tensor and the scalar argument. For example, if you multiply - * a Tensor@<1,dim,double@> by std::complex@, - * then the result will be a Tensor@<1,dim,std::complex@@>. - * In other words, the type with which the returned tensor stores its - * components equals the type you would get if you multiplied an individual - * component of the input tensor by the scalar factor. + * The return type of the function is chosen so that it matches the types of + * both the tensor and the scalar argument. For example, if you multiply a + * Tensor@<1,dim,double@> by std::complex@, + * then the result will be a + * Tensor@<1,dim,std::complex@@>. In other words, the + * type with which the returned tensor stores its components equals the type + * you would get if you multiplied an individual component of the input tensor + * by the scalar factor. * * @relates Tensor * @relates EnableIfScalar diff --git a/include/deal.II/base/tensor_base.h b/include/deal.II/base/tensor_base.h index 5b52ecf3fe..e65ddfbeb2 100644 --- a/include/deal.II/base/tensor_base.h +++ b/include/deal.II/base/tensor_base.h @@ -64,19 +64,18 @@ template class Tensor<1,dim,Number>; * family. * * @tparam dim An integer that denotes the dimension of the space in which - * this tensor operates. This of course equals the number of coordinates that - * identify a point and rank-1 tensor. Since the current object is a rank-0 - * tensor (a scalar), this template argument has no meaning for this class. - * @tparam Number The data type in which the tensor elements are - * to be stored. This will, in almost all cases, simply be the default - * @p double, but there are cases where one may want to store elements - * in a different (and always scalar) type. It can be used to base - * tensors on @p float or @p complex numbers or any other data type that - * implements basic arithmetic operations. - * Another example would be a type that allows for Automatic Differentiation - * (see, for example, the Sacado type used in step-33) and thereby can - * generate analytic (spatial) derivatives of a function that takes a - * tensor as argument. + * this tensor operates. This of course equals the number of coordinates that + * identify a point and rank-1 tensor. Since the current object is a rank-0 + * tensor (a scalar), this template argument has no meaning for this class. + * @tparam Number The data type in which the tensor elements are to be stored. + * This will, in almost all cases, simply be the default @p double, but there + * are cases where one may want to store elements in a different (and always + * scalar) type. It can be used to base tensors on @p float or @p complex + * numbers or any other data type that implements basic arithmetic operations. + * Another example would be a type that allows for Automatic Differentiation + * (see, for example, the Sacado type used in step-33) and thereby can + * generate analytic (spatial) derivatives of a function that takes a tensor + * as argument. * * @ingroup geomprimitives * @author Wolfgang Bangerth, 2009 @@ -132,9 +131,9 @@ public: Tensor (const Tensor<0,dim,Number> &initializer); /** - * Copy constructor from tensors with different underlying scalar - * type. This obviously requires that the @p OtherNumber type is - * convertible to @p Number. + * Copy constructor from tensors with different underlying scalar type. This + * obviously requires that the @p OtherNumber type is convertible to @p + * Number. */ template explicit @@ -161,9 +160,9 @@ public: Tensor<0,dim,Number> &operator = (const Tensor<0,dim,Number> &rhs); /** - * Assignment operator from tensors with different underlying scalar - * type. This obviously requires that the @p OtherNumber type is - * convertible to @p Number. + * Assignment operator from tensors with different underlying scalar type. + * This obviously requires that the @p OtherNumber type is convertible to @p + * Number. */ template Tensor<0,dim,Number> &operator = (const Tensor<0,dim,OtherNumber> &rhs); @@ -303,18 +302,17 @@ private: * different physical units), we use the Tensor<1,dim,Number> class. * * @tparam dim An integer that denotes the dimension of the space in which - * this tensor operates. This of course equals the number of coordinates that - * identify a point and rank-1 tensor. - * @tparam Number The data type in which the tensor elements are - * to be stored. This will, in almost all cases, simply be the default - * @p double, but there are cases where one may want to store elements - * in a different (and always scalar) type. It can be used to base - * tensors on @p float or @p complex numbers or any other data type that - * implements basic arithmetic operations. - * Another example would be a type that allows for Automatic Differentiation - * (see, for example, the Sacado type used in step-33) and thereby can - * generate analytic (spatial) derivatives of a function that takes - * a tensor as argument. + * this tensor operates. This of course equals the number of coordinates that + * identify a point and rank-1 tensor. + * @tparam Number The data type in which the tensor elements are to be stored. + * This will, in almost all cases, simply be the default @p double, but there + * are cases where one may want to store elements in a different (and always + * scalar) type. It can be used to base tensors on @p float or @p complex + * numbers or any other data type that implements basic arithmetic operations. + * Another example would be a type that allows for Automatic Differentiation + * (see, for example, the Sacado type used in step-33) and thereby can + * generate analytic (spatial) derivatives of a function that takes a tensor + * as argument. * * @ingroup geomprimitives * @author Wolfgang Bangerth, 1998-2005 @@ -387,9 +385,9 @@ public: Tensor (const Tensor<1,dim,Number> &initializer); /** - * Copy constructor from tensors with different underlying scalar - * type. This obviously requires that the @p OtherNumber type is - * convertible to @p Number. + * Copy constructor from tensors with different underlying scalar type. This + * obviously requires that the @p OtherNumber type is convertible to @p + * Number. */ template explicit @@ -427,9 +425,9 @@ public: Tensor<1,dim,Number> &operator = (const Tensor<1,dim,Number> &rhs); /** - * Assignment operator from tensors with different underlying scalar - * type. This obviously requires that the @p OtherNumber type is - * convertible to @p Number. + * Assignment operator from tensors with different underlying scalar type. + * This obviously requires that the @p OtherNumber type is convertible to @p + * Number. */ template Tensor<1,dim,Number> &operator = (const Tensor<1,dim,OtherNumber> &rhs); @@ -1365,13 +1363,14 @@ operator * (const Number factor, * prohibited of considering this operator for multiplication with non-scalar * types are explained in the documentation of the EnableIfScalar class. * - * The return type of the function is chosen so that it matches the types - * of both the tensor and the scalar argument. For example, if you multiply - * a Tensor@<1,dim,double@> by std::complex@, - * then the result will be a Tensor@<1,dim,std::complex@@>. - * In other words, the type with which the returned tensor stores its - * components equals the type you would get if you multiplied an individual - * component of the input tensor by the scalar factor. + * The return type of the function is chosen so that it matches the types of + * both the tensor and the scalar argument. For example, if you multiply a + * Tensor@<1,dim,double@> by std::complex@, + * then the result will be a + * Tensor@<1,dim,std::complex@@>. In other words, the + * type with which the returned tensor stores its components equals the type + * you would get if you multiplied an individual component of the input tensor + * by the scalar factor. * * @relates Tensor<1,dim,Number> * @relates EnableIfScalar diff --git a/include/deal.II/distributed/tria.h b/include/deal.II/distributed/tria.h index 735e1b0a83..606826b3be 100644 --- a/include/deal.II/distributed/tria.h +++ b/include/deal.II/distributed/tria.h @@ -184,8 +184,7 @@ namespace parallel * relies on the p4est library that does not support this. Attempts to * refine cells anisotropically will result in errors. * - * @note There is - * currently no support for distributing 1d triangulations. + * @note There is currently no support for distributing 1d triangulations. * * *

Interaction with boundary description

diff --git a/include/deal.II/fe/fe.h b/include/deal.II/fe/fe.h index 85dae36e14..f9587adb31 100644 --- a/include/deal.II/fe/fe.h +++ b/include/deal.II/fe/fe.h @@ -694,15 +694,15 @@ public: bool restriction_is_additive (const unsigned int index) const; /** - * Return a read only reference to the matrix that describes the - * constraints at the interface between a refined and an unrefined cell. - * - * Some finite elements do not (yet) implement hanging node - * constraints. If this is the case, then this function will generate an - * exception, since no useful return value can be generated. If you should - * have a way to live with this, then you might want to use the - * constraints_are_implemented() function to check up front whether this - * function will succeed or generate the exception. + * Return a read only reference to the matrix that describes the constraints + * at the interface between a refined and an unrefined cell. + * + * Some finite elements do not (yet) implement hanging node constraints. If + * this is the case, then this function will generate an exception, since no + * useful return value can be generated. If you should have a way to live + * with this, then you might want to use the constraints_are_implemented() + * function to check up front whether this function will succeed or generate + * the exception. */ const FullMatrix &constraints (const dealii::internal::SubfaceCase &subface_case=dealii::internal::SubfaceCase::case_isotropic) const; diff --git a/include/deal.II/fe/fe_dgp.h b/include/deal.II/fe/fe_dgp.h index 903817a9e1..b6b35ef169 100644 --- a/include/deal.II/fe/fe_dgp.h +++ b/include/deal.II/fe/fe_dgp.h @@ -104,28 +104,23 @@ template class MappingQ; * linear combincation of them. Consequently, the linear functions are not * within the range of the mapped $P_1$ polynomials. * - *

Visualization of shape functions

- * In 2d, the shape functions of this element look as follows. + *

Visualization of shape functions

In 2d, the shape functions of + * this element look as follows. * *

$P_0$ element

* - * - * - *
+ * * - * + * * - * - *
* @image html http://www.dealii.org/images/shape-functions/DGP/P1/P1_DGP_shape0000.png * - *
$P_0$ element, shape function 0
$P_0$ element, + * shape function 0
+ *
* *

$P_1$ element

* - * - * - * + * * * * @@ -423,8 +423,8 @@ template class MappingQ; * * + * * * * @@ -434,8 +434,8 @@ template class MappingQ; * * + * * * * @@ -445,8 +445,8 @@ template class MappingQ; * * + * * * * @@ -456,8 +456,8 @@ template class MappingQ; * * + * * * * @@ -467,8 +467,8 @@ template class MappingQ; * * + * * * * @@ -478,8 +478,8 @@ template class MappingQ; * * + * * * * @@ -489,8 +489,8 @@ template class MappingQ; * * + * * * * @@ -500,8 +500,8 @@ template class MappingQ; * * + * * * * @@ -511,8 +511,8 @@ template class MappingQ; * * + * * * * @@ -522,8 +522,8 @@ template class MappingQ; * * + * * * * @@ -533,8 +533,8 @@ template class MappingQ; * * + * * * * diff --git a/include/deal.II/fe/fe_system.h b/include/deal.II/fe/fe_system.h index 69eaa0b52c..c7d3ec2800 100644 --- a/include/deal.II/fe/fe_system.h +++ b/include/deal.II/fe/fe_system.h @@ -158,22 +158,22 @@ class FESystem : public FiniteElement public: /** - * Constructor. Take a finite element and the number of elements you - * want to group together using this class. + * Constructor. Take a finite element and the number of elements you want to + * group together using this class. * - * The object @p fe is not actually used for anything other than creating - * a copy that will then be owned by the current object. In other words, - * it is completely fine to call this constructor with a temporary object - * for the finite element, as in this code snippet: + * The object @p fe is not actually used for anything other than creating a + * copy that will then be owned by the current object. In other words, it is + * completely fine to call this constructor with a temporary object for the + * finite element, as in this code snippet: * @code * FESystem fe (FE_Q(2), 2); * @endcode - * Here, FE_Q@(2) constructs an unnamed, temporary - * object that is passed to the FESystem constructor to create a - * finite element that consists of two components, both of which are - * quadratic FE_Q elements. The temporary is destroyed again at the - * end of the code that corresponds to this line, but this does not - * matter because FESystem creates its own copy of the FE_Q object. + * Here, FE_Q@(2) constructs an unnamed, temporary object + * that is passed to the FESystem constructor to create a finite element + * that consists of two components, both of which are quadratic FE_Q + * elements. The temporary is destroyed again at the end of the code that + * corresponds to this line, but this does not matter because FESystem + * creates its own copy of the FE_Q object. * * This constructor (or its variants below) is used in essentially all * tutorial programs that deal with vector valued problems. See step-8, @@ -182,10 +182,10 @@ public: * * @dealiiVideoLecture{19,20} * - * @param[in] fe The finite element that will be used to represent - * the components of this composed element. - * @param[in] n_elements An integer denoting how many copies of - * @p fe this element should consist of. + * @param[in] fe The finite element that will be used to represent the + * components of this composed element. + * @param[in] n_elements An integer denoting how many copies of @p fe this + * element should consist of. */ FESystem (const FiniteElement &fe, const unsigned int n_elements); @@ -193,8 +193,8 @@ public: /** * Constructor for mixed discretizations with two base elements. * - * See the other constructor above for an explanation of the - * general idea of composing elements. + * See the other constructor above for an explanation of the general idea of + * composing elements. */ FESystem (const FiniteElement &fe1, const unsigned int n1, const FiniteElement &fe2, const unsigned int n2); @@ -202,8 +202,8 @@ public: /** * Constructor for mixed discretizations with three base elements. * - * See the other constructor above for an explanation of the - * general idea of composing elements. + * See the other constructor above for an explanation of the general idea of + * composing elements. */ FESystem (const FiniteElement &fe1, const unsigned int n1, const FiniteElement &fe2, const unsigned int n2, @@ -266,9 +266,9 @@ public: * @endcode * * If your compiler supports the C++11 language standard (or later) and - * deal.II has been configured to use it, then you could do something - * like this to create an element with four base elements and - * multiplicities 1, 2, 3 and 4: + * deal.II has been configured to use it, then you could do something like + * this to create an element with four base elements and multiplicities 1, + * 2, 3 and 4: * @code * template * MySimulator::MySimulator (const unsigned int polynomial_degree) @@ -284,8 +284,8 @@ public: * initializer list enclosed in braces { ... }. * * This code has a problem: it creates four memory leaks because the first - * vector above is created with pointers to elements that are allocated - * with new but never destroyed. Without C++11, you have another + * vector above is created with pointers to elements that are allocated with + * new but never destroyed. Without C++11, you have another * problem: brace-initializer don't exist in earlier C++ standards. * * The solution to the second of these problems is to create two static diff --git a/include/deal.II/grid/grid_generator.h b/include/deal.II/grid/grid_generator.h index 16a1b90c1f..cb51f6a991 100644 --- a/include/deal.II/grid/grid_generator.h +++ b/include/deal.II/grid/grid_generator.h @@ -56,8 +56,8 @@ namespace GridGenerator * in 2D, etc) consisting of exactly one cell. The hypercube volume is the * tensor product interval $[left,right]^{\text{dim}}$ in the present number * of dimensions, where the limits are given as arguments. They default to - * zero and unity, then producing the unit hypercube. If the argument - * @p colorize is false, all boundary indicators are set to zero ("not + * zero and unity, then producing the unit hypercube. If the argument @p + * colorize is false, all boundary indicators are set to zero ("not * colorized") for 2d and 3d. If it is true, the boundary is colorized as in * hyper_rectangle(). In 1d the indicators are always colorized, see * hyper_rectangle(). @@ -217,8 +217,8 @@ namespace GridGenerator * vectors. Colorizing is done according to hyper_rectangle(). * * @note This function silently reorders the vertices on the cells to - * lexicographic ordering (see GridReordering::reorder_grid). In - * other words, if reodering of the vertices does occur, the ordering of + * lexicographic ordering (see GridReordering::reorder_grid). + * In other words, if reodering of the vertices does occur, the ordering of * vertices in the array of corners will no longer refer to the * same triangulation. * @@ -248,9 +248,9 @@ namespace GridGenerator const bool colorize = false); /** - * A subdivided parallelepiped, i.e., the same as above, but where the number - * of subdivisions in each of the @p dim directions may vary. Colorizing is - * done according to hyper_rectangle(). + * A subdivided parallelepiped, i.e., the same as above, but where the + * number of subdivisions in each of the @p dim directions may vary. + * Colorizing is done according to hyper_rectangle(). * * @note The triangulation needs to be void upon calling this function. */ @@ -271,8 +271,8 @@ namespace GridGenerator * give the lower and upper bound of the inner hypercube in all coordinate * directions. @p thickness marks the size of the layer cells. * - * If the flag @p colorize is set, the outer cells get material id's according - * to the following scheme: extending over the inner cube in (+/-) + * If the flag @p colorize is set, the outer cells get material id's + * according to the following scheme: extending over the inner cube in (+/-) * x-direction: 1/2. In y-direction 4/8, in z-direction 16/32. The cells at * corners and edges (3d) get these values bitwise or'd. * @@ -427,10 +427,10 @@ namespace GridGenerator * of cells of the resulting triangulation, i.e., how many cells form the * ring (in 2d) or the shell (in 3d). * - * If the flag @p colorize is @p true, then the outer boundary will - * have the indicator 1, while the inner boundary has id zero. In - * 3d, this applies to both the faces and the edges of these - * boundaries. If the flag is @p false, both have indicator zero. + * If the flag @p colorize is @p true, then the outer boundary will have the + * indicator 1, while the inner boundary has id zero. In 3d, this applies to + * both the faces and the edges of these boundaries. If the flag is @p + * false, both have indicator zero. * * In 2d, the number n_cells of elements for this initial * triangulation can be chosen arbitrarily. If the number of initial cells diff --git a/include/deal.II/grid/tria_accessor.h b/include/deal.II/grid/tria_accessor.h index f9f129f876..ac7870a3fa 100644 --- a/include/deal.II/grid/tria_accessor.h +++ b/include/deal.II/grid/tria_accessor.h @@ -2069,19 +2069,18 @@ public: * The neighbor of a cell has at most the same level as this cell. For * example, consider the following situation: * @image html limit_level_difference_at_vertices.png "" - * Here, if you are on the top right cell and you ask for its left - * neighbor (which is, according to the conventions spelled out in the - * GeometryInfo class, its zeroth neighbor), then you will get - * the mother cell of the four small cells at the top left. In other - * words, the cell you get as neighbor has the same refinement level - * as the one you're on right now (the top right one) and it may have - * children. - * - * On the other hand, if you were at the top right cell of the four - * small cells at the top left, and you asked for the right neighbor - * (which is associated with index i=1), then you would - * get the large cell at the top right which in this case has - * a lower refinement level and no children of its own. + * Here, if you are on the top right cell and you ask for its left neighbor + * (which is, according to the conventions spelled out in the GeometryInfo + * class, its zeroth neighbor), then you will get the mother cell of + * the four small cells at the top left. In other words, the cell you get as + * neighbor has the same refinement level as the one you're on right now + * (the top right one) and it may have children. + * + * On the other hand, if you were at the top right cell of the four small + * cells at the top left, and you asked for the right neighbor (which is + * associated with index i=1), then you would get the large + * cell at the top right which in this case has a lower refinement level and + * no children of its own. */ TriaIterator > neighbor (const unsigned int i) const; diff --git a/include/deal.II/hp/dof_faces.h b/include/deal.II/hp/dof_faces.h index ec542c34d5..b4c0598318 100644 --- a/include/deal.II/hp/dof_faces.h +++ b/include/deal.II/hp/dof_faces.h @@ -200,9 +200,9 @@ namespace internal std::size_t memory_consumption () const; /** - * Read or write the data of this object to or from a stream for the - * purpose of serialization - */ + * Read or write the data of this object to or from a stream for the + * purpose of serialization + */ template void serialize(Archive &ar, const unsigned int version); @@ -259,9 +259,9 @@ namespace internal std::size_t memory_consumption () const; /** - * Read or write the data of this object to or from a stream for the - * purpose of serialization - */ + * Read or write the data of this object to or from a stream for the + * purpose of serialization + */ template void serialize(Archive &ar, const unsigned int version); @@ -290,9 +290,9 @@ namespace internal std::size_t memory_consumption () const; /** - * Read or write the data of this object to or from a stream for the - * purpose of serialization - */ + * Read or write the data of this object to or from a stream for the + * purpose of serialization + */ template void serialize(Archive &ar, const unsigned int version); @@ -326,9 +326,9 @@ namespace internal std::size_t memory_consumption () const; /** - * Read or write the data of this object to or from a stream for the - * purpose of serialization - */ + * Read or write the data of this object to or from a stream for the + * purpose of serialization + */ template void serialize(Archive &ar, const unsigned int version); diff --git a/include/deal.II/hp/dof_handler.h b/include/deal.II/hp/dof_handler.h index 9fa74bfb79..4dda6a8fc0 100644 --- a/include/deal.II/hp/dof_handler.h +++ b/include/deal.II/hp/dof_handler.h @@ -608,16 +608,16 @@ namespace hp virtual std::size_t memory_consumption () const; /** - * Write the data of this object to a stream for the purpose of - * serialization. - */ + * Write the data of this object to a stream for the purpose of + * serialization. + */ template void save(Archive &ar, const unsigned int version) const; /** - * Read the data of this object from a stream for the purpose of - * serialization. - */ + * Read the data of this object from a stream for the purpose of + * serialization. + */ template void load(Archive &ar, const unsigned int version); diff --git a/include/deal.II/hp/dof_level.h b/include/deal.II/hp/dof_level.h index da7513a990..c4a138ec93 100644 --- a/include/deal.II/hp/dof_level.h +++ b/include/deal.II/hp/dof_level.h @@ -243,9 +243,9 @@ namespace internal std::size_t memory_consumption () const; /** - * Read or write the data of this object to or from a stream for the - * purpose of serialization - */ + * Read or write the data of this object to or from a stream for the + * purpose of serialization + */ template void serialize(Archive &ar, const unsigned int version); diff --git a/include/deal.II/lac/block_matrix_array.h b/include/deal.II/lac/block_matrix_array.h index 8c81eab915..d317b0b7ae 100644 --- a/include/deal.II/lac/block_matrix_array.h +++ b/include/deal.II/lac/block_matrix_array.h @@ -93,15 +93,12 @@ template class Vector; * @line Growing * * Now, we are ready to build a 2x2 BlockMatrixArray. - * @line Block - * First, we enter the matrix A multiplied by 2 in the upper left - * block - * @line enter - * Now -1 times B1 in the upper right block. - * @line enter - * We add the transpose of B2 to the upper right block and - * continue in a similar fashion. In the end, the block matrix structure is - * printed into an LaTeX table. + * @line Block First, we enter the matrix A multiplied by 2 in the + * upper left block + * @line enter Now -1 times B1 in the upper right block. + * @line enter We add the transpose of B2 to the upper right block + * and continue in a similar fashion. In the end, the block matrix structure + * is printed into an LaTeX table. * @until latex * * Now, we set up vectors to be multiplied with this matrix and do a diff --git a/include/deal.II/lac/constraint_matrix.h b/include/deal.II/lac/constraint_matrix.h index 9fa5e86025..d237a17916 100644 --- a/include/deal.II/lac/constraint_matrix.h +++ b/include/deal.II/lac/constraint_matrix.h @@ -521,22 +521,21 @@ public: /** - * Condense a sparsity pattern. The name of the function mimics the - * name of the function we use to condense linear systems, but it is - * a bit of a misnomer for the current context. This is because in - * the context of linear systems, we eliminate certain rows and - * columns of the linear system, i.e., we "reduce" or "condense" the - * linear system. On the other hand, in the current context, the - * functions does not remove nonzero entries from the sparsity - * pattern. Rather, it adds those nonzero entry locations to the - * sparsity pattern that will later be needed for the process of - * condensation of constrained degrees of freedom from a linear + * Condense a sparsity pattern. The name of the function mimics the name of + * the function we use to condense linear systems, but it is a bit of a + * misnomer for the current context. This is because in the context of + * linear systems, we eliminate certain rows and columns of the linear + * system, i.e., we "reduce" or "condense" the linear system. On the other + * hand, in the current context, the functions does not remove nonzero + * entries from the sparsity pattern. Rather, it adds those nonzero entry + * locations to the sparsity pattern that will later be needed for the + * process of condensation of constrained degrees of freedom from a linear * system. * - * Since this function adds new nonzero entries to the sparsity - * pattern, the given sparsity pattern must not be compressed. The - * constraint matrix (i.e., the current object) must be closed. The - * sparsity pattern is compressed at the end of the function. + * Since this function adds new nonzero entries to the sparsity pattern, the + * given sparsity pattern must not be compressed. The constraint matrix + * (i.e., the current object) must be closed. The sparsity pattern is + * compressed at the end of the function. */ void condense (SparsityPattern &sparsity) const; @@ -604,11 +603,11 @@ public: void condense (BlockCompressedSimpleSparsityPattern &sparsity) const; /** - * Condense a given matrix, i.e., eliminate the rows and columns of - * the matrix that correspond to constrained degrees of freedom. + * Condense a given matrix, i.e., eliminate the rows and columns of the + * matrix that correspond to constrained degrees of freedom. * - * See the general documentation of this - * class for more detailed information. + * See the general documentation of this class for more detailed + * information. */ template void condense (SparseMatrix &matrix) const; @@ -644,16 +643,16 @@ public: VectorType &output) const; /** - * Condense a given matrix and a given vector by eliminating rows - * and columns of the linear system that correspond to constrained - * degrees of freedom. The sparsity pattern associated with the - * matrix needs to be condensed and compressed. This function is - * the appropriate choice for applying inhomogeneous constraints. + * Condense a given matrix and a given vector by eliminating rows and + * columns of the linear system that correspond to constrained degrees of + * freedom. The sparsity pattern associated with the matrix needs to be + * condensed and compressed. This function is the appropriate choice for + * applying inhomogeneous constraints. * * The constraint matrix object must be closed to call this function. * - * See the general documentation of this - * class for more detailed information. + * See the general documentation of this class for more detailed + * information. */ template void condense (SparseMatrix &matrix, diff --git a/include/deal.II/lac/filtered_matrix.h b/include/deal.II/lac/filtered_matrix.h index a334c00da2..a34979998c 100644 --- a/include/deal.II/lac/filtered_matrix.h +++ b/include/deal.II/lac/filtered_matrix.h @@ -409,8 +409,8 @@ public: * Apply the constraints to a right hand side vector. This needs to be done * before starting to solve with the filtered matrix. If the matrix is * symmetric (i.e. the matrix itself, not only its sparsity pattern), set - * the second parameter to @p true to use a faster algorithm. - * Note: This method is deprecated as matrix_is_symmetric parameter is no longer used. + * the second parameter to @p true to use a faster algorithm. Note: This + * method is deprecated as matrix_is_symmetric parameter is no longer used. */ void apply_constraints (VECTOR &v, const bool matrix_is_symmetric) const DEAL_II_DEPRECATED; diff --git a/include/deal.II/lac/lapack_full_matrix.h b/include/deal.II/lac/lapack_full_matrix.h index 851d526d48..ddd45f1cf9 100644 --- a/include/deal.II/lac/lapack_full_matrix.h +++ b/include/deal.II/lac/lapack_full_matrix.h @@ -97,8 +97,8 @@ public: /** * Assignment operator from a regular FullMatrix. * - * @note Since LAPACK expects - * matrices in transposed order, this transposition is included here. + * @note Since LAPACK expects matrices in transposed order, this + * transposition is included here. */ template LAPACKFullMatrix & @@ -107,9 +107,8 @@ public: /** * Assignment operator from a regular SparseMatrix. * - * @note Since LAPACK - * expects matrices in transposed order, this transposition is included - * here. + * @note Since LAPACK expects matrices in transposed order, this + * transposition is included here. */ template LAPACKFullMatrix & @@ -149,16 +148,14 @@ public: /** * Return the dimension of the range space. * - * @note The matrix is of dimension - * $m \times n$. + * @note The matrix is of dimension $m \times n$. */ unsigned int m () const; /** * Return the number of the range space. * - * @note The matrix is of dimension $m - * \times n$. + * @note The matrix is of dimension $m \times n$. */ unsigned int n () const; @@ -439,8 +436,8 @@ public: * eigenvalues and the corresponding eigenvectors will be stored in the * columns of eigenvectors, whose dimension is set accordingly. * - * @note Calls the LAPACK function Xsyevx. For this to work, deal.II must - * be configured to use LAPACK. + * @note Calls the LAPACK function Xsyevx. For this to work, deal.II must be + * configured to use LAPACK. */ void compute_eigenvalues_symmetric (const number lower_bound, const number upper_bound, @@ -466,8 +463,8 @@ public: * eigenvalues and the corresponding eigenvectors will be stored in * eigenvectors, whose dimension is set accordingly. * - * @note Calls the LAPACK function Xsygvx. For this to work, deal.II must - * be configured to use LAPACK. + * @note Calls the LAPACK function Xsygvx. For this to work, deal.II must be + * configured to use LAPACK. */ void compute_generalized_eigenvalues_symmetric (LAPACKFullMatrix &B, const number lower_bound, @@ -490,8 +487,8 @@ public: * be retrieved using the eigenvalue() function. The number of computed * eigenvectors is equal to eigenvectors.size() * - * @note Calls the LAPACK function Xsygv. For this to work, deal.II must - * be configured to use LAPACK. + * @note Calls the LAPACK function Xsygv. For this to work, deal.II must be + * configured to use LAPACK. */ void compute_generalized_eigenvalues_symmetric (LAPACKFullMatrix &B, std::vector > &eigenvectors, diff --git a/include/deal.II/lac/solver_control.h b/include/deal.II/lac/solver_control.h index 40d7de92d8..f7be1988c9 100644 --- a/include/deal.II/lac/solver_control.h +++ b/include/deal.II/lac/solver_control.h @@ -179,9 +179,8 @@ public: * value (@p NaN). Note, however, that this check is only performed if the * @p isnan function is provided by the operating system, which is not * always true. CMake checks this with the 'check_01_cxx_features.cmake' - * test and sets the flag - * @p DEAL_II_HAVE_ISNAN in the include file deal.II/base/config.h - * if this function was found. + * test and sets the flag @p DEAL_II_HAVE_ISNAN in the include file + * deal.II/base/config.h if this function was found. * * check() additionally preserves @p step and @p check_value. These * values are accessible by last_value() and last_step(). diff --git a/include/deal.II/lac/solver_gmres.h b/include/deal.II/lac/solver_gmres.h index 39d29d49b7..dbe037f2d2 100644 --- a/include/deal.II/lac/solver_gmres.h +++ b/include/deal.II/lac/solver_gmres.h @@ -313,7 +313,8 @@ private: * preconditioner. * * FGMRES needs two vectors in each iteration steps yielding a total of - * 2*SolverFGMRES::AdditionalData::max_basis_size+1 auxiliary vectors. + * 2*SolverFGMRES::AdditionalData::max_basis_size+1 auxiliary + * vectors. * * Caveat: Documentation of this class is not up to date. There are also a few * parameters of GMRES we would like to introduce here. diff --git a/include/deal.II/lac/sparse_direct.h b/include/deal.II/lac/sparse_direct.h index e057bcddd5..42d622348b 100644 --- a/include/deal.II/lac/sparse_direct.h +++ b/include/deal.II/lac/sparse_direct.h @@ -296,9 +296,9 @@ private: void sort_arrays (const BlockSparseMatrix &); /** - * The arrays in which we store the data for the solver. - * SuiteSparse_long has to be used here for Windows 64 build, - * if we used only long int, compilation would fail. + * The arrays in which we store the data for the solver. SuiteSparse_long + * has to be used here for Windows 64 build, if we used only long int, + * compilation would fail. */ std::vector Ap; std::vector Ai; diff --git a/include/deal.II/lac/sparse_mic.h b/include/deal.II/lac/sparse_mic.h index e273ddf69d..fff293d7ca 100644 --- a/include/deal.II/lac/sparse_mic.h +++ b/include/deal.II/lac/sparse_mic.h @@ -36,8 +36,8 @@ DEAL_II_NAMESPACE_OPEN * Let a symmetric, positive-definite, sparse matrix $A$ be in the form $A = D * - L - L^T$, where $D$ is the diagonal part of $A$ and $-L$ is a strictly * lower triangular matrix. The MIC(0) decomposition of the matrix $A$ is - * defined by $B = (X-L)X^{-1}(X-L^T)$, where $X$ is a diagonal matrix - * defined by the condition $\text{rowsum}(A) = \text{rowsum}(B)$. + * defined by $B = (X-L)X^{-1}(X-L^T)$, where $X$ is a diagonal matrix defined + * by the condition $\text{rowsum}(A) = \text{rowsum}(B)$. * * @author Stephen "Cheffo" Kolaroff, 2002, unified interface: Ralf Hartmann * 2003. diff --git a/include/deal.II/lac/trilinos_precondition.h b/include/deal.II/lac/trilinos_precondition.h index 08359d77fe..079c2dd551 100644 --- a/include/deal.II/lac/trilinos_precondition.h +++ b/include/deal.II/lac/trilinos_precondition.h @@ -886,23 +886,22 @@ namespace TrilinosWrappers /** - * A wrapper class for an incomplete LU factorization (ILU(k)) preconditioner - * for Trilinos matrices. This preconditioner works both in serial and in - * parallel, depending on the matrix it is based on. In general, an - * incomplete factorization does not take all fill-in elements that would - * appear in a full factorization (that is the basis for a direct solve). - * Trilinos allows to set the amount of fill-in elements, governed by the - * additional data argument ilu_fill, so one can gradually choose - * between a factorization on the sparse matrix structure only + * A wrapper class for an incomplete LU factorization (ILU(k)) + * preconditioner for Trilinos matrices. This preconditioner works both in + * serial and in parallel, depending on the matrix it is based on. In + * general, an incomplete factorization does not take all fill-in elements + * that would appear in a full factorization (that is the basis for a direct + * solve). Trilinos allows to set the amount of fill-in elements, governed + * by the additional data argument ilu_fill, so one can gradually + * choose between a factorization on the sparse matrix structure only * (ilu_fill=0) to a full factorization (ilu_fill in the * range of 10 to 50, depending on the spatial dimension of the PDE problem * and the degree of the finite element basis functions; generally, more * required fill-in elements require this parameter to be set to a higher * integer value). * - * The AdditionalData data structure allows to set preconditioner - * options. See the documentation of the AdditionalData structure for - * details. + * The AdditionalData data structure allows to set preconditioner options. + * See the documentation of the AdditionalData structure for details. * * Note that a parallel application of the ILU preconditioner is actually a * block-Jacobi preconditioner with block size equal to the local matrix @@ -925,33 +924,33 @@ namespace TrilinosWrappers * *
  • @p ilu_fill: This specifies the amount of additional fill-in * elements besides the original sparse matrix structure. If $k$ is @p - * fill, the sparsity pattern of $A^{k+1}$ is used for the storage of - * the result of the Gaussian elemination. This is known as ILU($k$) in - * the literature. When @p fill is large, the preconditioner comes - * closer to a (direct) sparse LU decomposition. Note, however, that this - * will drastically increase the memory requirement, especially when the + * fill, the sparsity pattern of $A^{k+1}$ is used for the storage of the + * result of the Gaussian elemination. This is known as ILU($k$) in the + * literature. When @p fill is large, the preconditioner comes closer to + * a (direct) sparse LU decomposition. Note, however, that this will + * drastically increase the memory requirement, especially when the * preconditioner is used in 3D. * *
  • @p ilu_atol and @p ilu_rtol: These two parameters allow * perturbation of the diagonal of the matrix, which sometimes can help to - * get better preconditioners especially in the case of bad - * conditioning. Before factorization, the diagonal entry $a_{ii}$ is - * replaced by $\alpha sign(a_{ii}) + \beta a_{ii}$, where $\alpha\geq 0$ - * is the absolute threshold @p ilu_atol and $\beta\geq 1$ is the relative + * get better preconditioners especially in the case of bad conditioning. + * Before factorization, the diagonal entry $a_{ii}$ is replaced by + * $\alpha sign(a_{ii}) + \beta a_{ii}$, where $\alpha\geq 0$ is the + * absolute threshold @p ilu_atol and $\beta\geq 1$ is the relative * threshold @p ilu_rtol. The default values ($\alpha = 0$, $\beta = 1$) * therefore use the original, unmodified diagonal entry. Suggested values * are in the order of $10^{-5}$ to $10^{-2}$ for @p ilu_atol and 1.01 for * @p ilu_rtol. * *
  • @p overlap: This determines how large the overlap of the local - * matrix portions on each processor in a parallel application should - * be. An overlap of 0 corresponds to a block diagonal decomposition on - * each processor, an overlap of 1 will additionally include a row j if - * there is a nonzero entry in column j in one of the own rows. Higher - * overlap numbers work accordingly in a recursive fashion. Increasing @p - * overlap will increase communication and storage cost. According to the - * IFPACK documentation, an overlap of 1 is often effective and values of - * more than 3 are rarely needed. + * matrix portions on each processor in a parallel application should be. + * An overlap of 0 corresponds to a block diagonal decomposition on each + * processor, an overlap of 1 will additionally include a row j if there + * is a nonzero entry in column j in one of the own rows. Higher overlap + * numbers work accordingly in a recursive fashion. Increasing @p overlap + * will increase communication and storage cost. According to the IFPACK + * documentation, an overlap of 1 is often effective and values of more + * than 3 are rarely needed. */ struct AdditionalData { diff --git a/include/deal.II/matrix_free/matrix_free.h b/include/deal.II/matrix_free/matrix_free.h index fd4220502b..88c56e6da6 100644 --- a/include/deal.II/matrix_free/matrix_free.h +++ b/include/deal.II/matrix_free/matrix_free.h @@ -599,8 +599,8 @@ public: * range in @p cell_loop runs from zero to n_macro_cells() (exclusive), so * this is the appropriate size if you want to store arrays of data for all * cells to be worked on. This number is approximately - * n_physical_cells()/VectorizedArray::n_array_elements (depending - * on how many cell chunks that do not get filled up completely). + * n_physical_cells()/VectorizedArray::n_array_elements (depending on how + * many cell chunks that do not get filled up completely). */ unsigned int n_macro_cells () const; diff --git a/include/deal.II/multigrid/mg_transfer_component.h b/include/deal.II/multigrid/mg_transfer_component.h index 9dfc70f5c0..9ec57830a7 100644 --- a/include/deal.II/multigrid/mg_transfer_component.h +++ b/include/deal.II/multigrid/mg_transfer_component.h @@ -347,9 +347,8 @@ private: /** * The degrees of freedom on the refinement edges. For each level the index - * set denotes which level - * degrees of freedom are on the refinement edge towards the lower level, - * excluding boundary dofs. + * set denotes which level degrees of freedom are on the refinement edge + * towards the lower level, excluding boundary dofs. */ std::vector interface_dofs; diff --git a/include/deal.II/numerics/data_out.h b/include/deal.II/numerics/data_out.h index 9c9b5e4d8d..f9a3b249cc 100644 --- a/include/deal.II/numerics/data_out.h +++ b/include/deal.II/numerics/data_out.h @@ -180,43 +180,41 @@ public: * This is the central function of this class since it builds the list of * patches to be written by the low-level functions of the base class. A * patch is, in essence, some intermediate representation of the data on - * each cell of a triangulation and DoFHandler object that can then be - * used to write files in some format that is readable by visualization - * programs. + * each cell of a triangulation and DoFHandler object that can then be used + * to write files in some format that is readable by visualization programs. * - * You can find an overview of the use of this function in - * the general documentation of this class. An example is also provided in - * the documentation of this class's base class DataOut_DoFData. + * You can find an overview of the use of this function in the general + * documentation of this class. An example is also provided in the + * documentation of this class's base class DataOut_DoFData. * * @param n_subdivisions A parameter that determines how many "patches" this - * function will build out of every cell. If you do not specify this - * value in calling, or provide the default value zero, then this is - * interpreted as DataOutInterface::default_subdivisions which most of - * the time will be equal to one (unless you have set it to something else). - * The purpose of this parameter is to subdivide each cell of the mesh - * into $2\times 2, 3\times 3, \ldots$ "patches" in 2d, and - * $2\times 2\times 2, 3\times 3\times 3, \ldots$ (if passed the value - * 2, 3, etc) where each patch represents the data from a regular subdivision - * of the cell into equal parts. Most of the times, this is not necessary - * and outputting one patch per cell is exactly what you want to plot - * the solution. That said, the data we write into files for visualization - * can only represent (bi-, tri)linear data on each cell, and most - * visualization programs can in fact only visualize this kind of data. - * That's good enough if you work with (bi-, tri)linear finite elements, - * in which case what you get to see is exactly what has been computed. - * On the other hand, if you work with (bi-, tri)quadratic elements, then - * what is written into the output file is just a (bi-, tri)linear - * interpolation onto the current mesh, i.e., only the values at the - * vertices. If this is not good enough, you can, for example, specify - * @p n_subdivisions equal to 2 to plot the solution on a once-refined - * mesh, or if set to 3, on a mesh where each cell is represented by - * 3-by-3 patches. On each of these smaller patches, given the limitations - * of output formats, the data is still linearly interpolated, but a - * linear interpolation of quadratic data on a finer mesh is still a - * better representation of the actual quadratic surface than on the - * original mesh. In other words, using this parameter can not help - * you plot the solution exactly, but it can get you closer if you - * use finite elements of higher polynomial degree. + * function will build out of every cell. If you do not specify this value + * in calling, or provide the default value zero, then this is interpreted + * as DataOutInterface::default_subdivisions which most of the time will be + * equal to one (unless you have set it to something else). The purpose of + * this parameter is to subdivide each cell of the mesh into $2\times 2, + * 3\times 3, \ldots$ "patches" in 2d, and $2\times 2\times 2, 3\times + * 3\times 3, \ldots$ (if passed the value 2, 3, etc) where each patch + * represents the data from a regular subdivision of the cell into equal + * parts. Most of the times, this is not necessary and outputting one patch + * per cell is exactly what you want to plot the solution. That said, the + * data we write into files for visualization can only represent (bi-, + * tri)linear data on each cell, and most visualization programs can in fact + * only visualize this kind of data. That's good enough if you work with + * (bi-, tri)linear finite elements, in which case what you get to see is + * exactly what has been computed. On the other hand, if you work with (bi-, + * tri)quadratic elements, then what is written into the output file is just + * a (bi-, tri)linear interpolation onto the current mesh, i.e., only the + * values at the vertices. If this is not good enough, you can, for example, + * specify @p n_subdivisions equal to 2 to plot the solution on a once- + * refined mesh, or if set to 3, on a mesh where each cell is represented by + * 3-by-3 patches. On each of these smaller patches, given the limitations + * of output formats, the data is still linearly interpolated, but a linear + * interpolation of quadratic data on a finer mesh is still a better + * representation of the actual quadratic surface than on the original mesh. + * In other words, using this parameter can not help you plot the solution + * exactly, but it can get you closer if you use finite elements of higher + * polynomial degree. */ virtual void build_patches (const unsigned int n_subdivisions = 0); diff --git a/include/deal.II/numerics/data_out_dof_data.h b/include/deal.II/numerics/data_out_dof_data.h index a80702b8a5..2ecaf2a498 100644 --- a/include/deal.II/numerics/data_out_dof_data.h +++ b/include/deal.II/numerics/data_out_dof_data.h @@ -324,22 +324,20 @@ namespace internal * @ref step_22 "step-22" * tutorial program). * - * This class does not copy the vector given to it - * through 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. + * This class does not copy the vector given to it through 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 (i.e., some intermediate data representation) for output from - * the stored data. Derived classes name this - * function build_patches(). Finally, you write() the data in one format or - * other, to a file. + * the stored data. Derived classes name this function build_patches(). + * Finally, you write() the data in one format or other, to a file. * - * In the example above, an object of type DataOut was used, - * i.e. an object of a derived class. This is necessary since the current class does - * not provide means to actually generate the patches, only aids to store and - * access data. Any real functionality is implemented in derived classes such - * as DataOut. + * In the example above, an object of type DataOut was used, i.e. an object of + * a derived class. This is necessary since the current class does not provide + * means to actually generate the patches, only aids to store and access data. + * Any real functionality is implemented in derived classes such as DataOut. * * Note that the base class of this class, DataOutInterface offers several * functions to ease programming with run-time determinable output formats @@ -353,18 +351,18 @@ namespace internal * *

    Information for derived classes

    * - * What this class lacks is a way to produce the patches for - * output itself, from the stored data and degree of freedom information. - * Since this task is often application dependent it is left to derived - * classes. For example, in many applications, it might be wanted to limit the - * depth of output to a certain number of refinement levels and write data - * from finer cells only in a way interpolated to coarser cells, to reduce the - * amount of output. Also, it might be wanted to use different numbers of - * subdivisions on different cells when forming a patch, for example to - * accomplish for different polynomial degrees of the trial space on different - * cells. Also, the output need not necessarily consist of a patch for each - * cell, but might be made up of patches for faces, of other things. Take a - * look at derived classes to what is possible in this respect. + * What this class lacks is a way to produce the patches for output itself, + * from the stored data and degree of freedom information. Since this task is + * often application dependent it is left to derived classes. For example, in + * many applications, it might be wanted to limit the depth of output to a + * certain number of refinement levels and write data from finer cells only in + * a way interpolated to coarser cells, to reduce the amount of output. Also, + * it might be wanted to use different numbers of subdivisions on different + * cells when forming a patch, for example to accomplish for different + * polynomial degrees of the trial space on different cells. Also, the output + * need not necessarily consist of a patch for each cell, but might be made up + * of patches for faces, of other things. Take a look at derived classes to + * what is possible in this respect. * * For this reason, it is left to a derived class to provide a function, named * usually build_patches() or the like, which fills the #patches array of this diff --git a/include/deal.II/numerics/data_out_faces.h b/include/deal.II/numerics/data_out_faces.h index 06dde1d5a9..fa6f5de554 100644 --- a/include/deal.II/numerics/data_out_faces.h +++ b/include/deal.II/numerics/data_out_faces.h @@ -144,16 +144,15 @@ public: * This is the central function of this class since it builds the list of * patches to be written by the low-level functions of the base class. A * patch is, in essence, some intermediate representation of the data on - * each face of a triangulation and DoFHandler object that can then be - * used to write files in some format that is readable by visualization - * programs. + * each face of a triangulation and DoFHandler object that can then be used + * to write files in some format that is readable by visualization programs. * - * You can find an overview of the use of this function in - * the general documentation of this class. An example is also provided in - * the documentation of this class's base class DataOut_DoFData. + * You can find an overview of the use of this function in the general + * documentation of this class. An example is also provided in the + * documentation of this class's base class DataOut_DoFData. * * @param n_subdivisions See DataOut::build_patches() for an extensive - * description of this parameter. + * description of this parameter. */ virtual void build_patches (const unsigned int n_subdivisions = 0); diff --git a/include/deal.II/numerics/data_out_rotation.h b/include/deal.II/numerics/data_out_rotation.h index 8f0f9c12be..af9c5688cf 100644 --- a/include/deal.II/numerics/data_out_rotation.h +++ b/include/deal.II/numerics/data_out_rotation.h @@ -141,19 +141,18 @@ public: * This is the central function of this class since it builds the list of * patches to be written by the low-level functions of the base class. A * patch is, in essence, some intermediate representation of the data on - * each cell of a triangulation and DoFHandler object that can then be - * used to write files in some format that is readable by visualization - * programs. + * each cell of a triangulation and DoFHandler object that can then be used + * to write files in some format that is readable by visualization programs. * - * You can find an overview of the use of this function in - * the general documentation of this class. An example is also provided in - * the documentation of this class's base class DataOut_DoFData. + * You can find an overview of the use of this function in the general + * documentation of this class. An example is also provided in the + * documentation of this class's base class DataOut_DoFData. * - * @param n_patches_per_circle Denotes into how many intervals - * the angular (rotation) variable is to be subdivided. + * @param n_patches_per_circle Denotes into how many intervals the angular + * (rotation) variable is to be subdivided. * * @param n_subdivisions See DataOut::build_patches() for an extensive - * description of this parameter. + * description of this parameter. */ virtual void build_patches (const unsigned int n_patches_per_circle, const unsigned int n_subdivisions = 0); diff --git a/include/deal.II/numerics/data_out_stack.h b/include/deal.II/numerics/data_out_stack.h index dd5a029f6a..5874e0b738 100644 --- a/include/deal.II/numerics/data_out_stack.h +++ b/include/deal.II/numerics/data_out_stack.h @@ -212,17 +212,16 @@ public: * This is the central function of this class since it builds the list of * patches to be written by the low-level functions of the base class. A * patch is, in essence, some intermediate representation of the data on - * each cell of a triangulation and DoFHandler object that can then be - * used to write files in some format that is readable by visualization - * programs. + * each cell of a triangulation and DoFHandler object that can then be used + * to write files in some format that is readable by visualization programs. * - * You can find an overview of the use of this function in - * the general documentation of this class. An example is also provided in - * the documentation of this class's base class DataOut_DoFData. + * You can find an overview of the use of this function in the general + * documentation of this class. An example is also provided in the + * documentation of this class's base class DataOut_DoFData. * * @param n_subdivisions See DataOut::build_patches() for an extensive - * description of this parameter. The number of subdivisions is always - * one in the direction of the time-like parameter used by this class. + * description of this parameter. The number of subdivisions is always one + * in the direction of the time-like parameter used by this class. */ void build_patches (const unsigned int n_subdivisions = 0); diff --git a/include/deal.II/numerics/fe_field_function.h b/include/deal.II/numerics/fe_field_function.h index 49b857530f..1bd3d875a7 100644 --- a/include/deal.II/numerics/fe_field_function.h +++ b/include/deal.II/numerics/fe_field_function.h @@ -150,10 +150,11 @@ namespace Functions * * @note To C++, * Functions::FEFieldFunction::ExcPointNotAvailableHere - * and Functions::FEFieldFunction, TrilinosWrappers::MPI::Vector>::ExcPointNotAvailableHere - * are distinct types. You - * need to make sure that the type of the exception you catch matches the - * type of the object that throws it, as shown in the example above. + * and Functions::FEFieldFunction, + * TrilinosWrappers::MPI::Vector>::ExcPointNotAvailableHere are + * distinct types. You need to make sure that the type of the exception you + * catch matches the type of the object that throws it, as shown in the + * example above. * * @ingroup functions * @author Luca Heltai, 2006, Markus Buerg, 2012, Wolfgang Bangerth, 2013 diff --git a/include/deal.II/numerics/vector_tools.h b/include/deal.II/numerics/vector_tools.h index 1ef987c5fc..1c86ec796e 100644 --- a/include/deal.II/numerics/vector_tools.h +++ b/include/deal.II/numerics/vector_tools.h @@ -1702,18 +1702,17 @@ namespace VectorTools * @param[in] weight The additional argument @p weight allows to evaluate * weighted norms. The weight function may be scalar, establishing a * spatially variable weight in the domain for all components equally. This - * may be used, for instance, to only integrate over parts of the - * domain. The weight function may also be vector-valued, with as many - * components as the finite element: Then, different components get - * different weights. A typical application is when the error with respect - * to only one or a subset of the solution variables is to be computed, in - * which case the other components would have weight values equal to - * zero. The ComponentSelectFunction class is particularly useful for this - * purpose as it provides such a "mask" weight. The weight function is - * expected to be positive, but negative values are not filtered. The - * default value of this function, a null pointer, is interpreted as "no - * weighting function", i.e., weight=1 in the whole domain for all vector - * components uniformly. + * may be used, for instance, to only integrate over parts of the domain. + * The weight function may also be vector-valued, with as many components as + * the finite element: Then, different components get different weights. A + * typical application is when the error with respect to only one or a + * subset of the solution variables is to be computed, in which case the + * other components would have weight values equal to zero. The + * ComponentSelectFunction class is particularly useful for this purpose as + * it provides such a "mask" weight. The weight function is expected to be + * positive, but negative values are not filtered. The default value of this + * function, a null pointer, is interpreted as "no weighting function", + * i.e., weight=1 in the whole domain for all vector components uniformly. * @param[in] exponent This value denotes the $p$ used in computing * $L^p$-norms and $W^{1,p}$-norms. The value is ignores if a @p norm other * than NormType::Lp_norm or NormType::W1p_norm is chosen. -- 2.39.5
    • + * * @@ -139,16 +134,15 @@ template class MappingQ; * @image html http://www.dealii.org/images/shape-functions/DGP/P1/P1_DGP_shape0002.png * * - * + * * *
    * @image html http://www.dealii.org/images/shape-functions/DGP/P1/P1_DGP_shape0000.png * - *
    $P_1$ element, shape function 2
    $P_1$ element, + * shape function 2
    * * *

    $P_2$ element

    * - * - *
    + * * @@ -176,14 +170,12 @@ template class MappingQ; * @image html http://www.dealii.org/images/shape-functions/DGP/P2/P2_DGP_shape0005.png * * - * - *
    * @image html http://www.dealii.org/images/shape-functions/DGP/P2/P2_DGP_shape0000.png *
    $P_2$ element, shape function 4 $P_2$ element, shape function 5
    + *     		$P_2$ element, shape function 5
    * * *

    $P_3$ element

    * - * - *
    + * * @@ -231,13 +223,10 @@ template class MappingQ; * @image html http://www.dealii.org/images/shape-functions/DGP/P3/P3_DGP_shape0009.png * * - * - *
    * @image html http://www.dealii.org/images/shape-functions/DGP/P3/P3_DGP_shape0000.png *
    $P_3$ element, shape function 8 $P_3$ element, shape function 9
    + *     		$P_3$ element, shape function 9
    * * - *

    $P_4$ element

    - * - *
    + *

    $P_4$ element

    * @@ -311,11 +300,10 @@ template class MappingQ; * @image html http://www.dealii.org/images/shape-functions/DGP/P4/P4_DGP_shape0014.png * * - * + * * - * - *
    * @image html http://www.dealii.org/images/shape-functions/DGP/P4/P4_DGP_shape0000.png * - *
    $P_4$ element, shape function 14
    $P_4$ element, + * shape function 14
    + *
    * * @author Guido Kanschat, 2001, 2002, Ralf Hartmann 2004 */ diff --git a/include/deal.II/fe/fe_dgp_monomial.h b/include/deal.II/fe/fe_dgp_monomial.h index 03023c4ebf..a21d3e7c39 100644 --- a/include/deal.II/fe/fe_dgp_monomial.h +++ b/include/deal.II/fe/fe_dgp_monomial.h @@ -80,28 +80,23 @@ template class MappingQ; * within the range of the mapped $P_1$ polynomials. * * - *

    Visualization of shape functions

    - * In 2d, the shape functions of this element look as follows. + *

    Visualization of shape functions

    In 2d, the shape functions of + * this element look as follows. * *

    $P_0$ element

    * - * - * - *
    + * * - * + * * - * - *
    * @image html http://www.dealii.org/images/shape-functions/DGPMonomial/P1/P1_DGPMonomial_shape0000.png * - *
    $P_0$ element, shape function 0
    $P_0$ element, + * shape function 0
    + *
    * *

    $P_1$ element

    * - * - * - * + * * * * @@ -236,8 +236,8 @@ template class MappingQ; * * + * * * * @@ -247,8 +247,8 @@ template class MappingQ; * * + * * * * @@ -258,8 +258,8 @@ template class MappingQ; * * + * * * * @@ -300,8 +300,8 @@ template class MappingQ; * * + * * * * @@ -311,8 +311,8 @@ template class MappingQ; * * + * * * * @@ -322,8 +322,8 @@ template class MappingQ; * * + * * * * @@ -333,8 +333,8 @@ template class MappingQ; * * + * * * * @@ -344,8 +344,8 @@ template class MappingQ; * * + * * * * @@ -355,8 +355,8 @@ template class MappingQ; * * + * * * * @@ -366,8 +366,8 @@ template class MappingQ; * * + * * * * @@ -377,8 +377,8 @@ template class MappingQ; * * + * * *
    + * * @@ -115,16 +110,15 @@ template class MappingQ; * @image html http://www.dealii.org/images/shape-functions/DGPMonomial/P1/P1_DGPMonomial_shape0002.png * * - * + * * *
    * @image html http://www.dealii.org/images/shape-functions/DGPMonomial/P1/P1_DGPMonomial_shape0000.png * - *
    $P_1$ element, shape function 2
    $P_1$ element, + * shape function 2
    * * *

    $P_2$ element

    * - * - *
    + * * @@ -152,14 +146,12 @@ template class MappingQ; * @image html http://www.dealii.org/images/shape-functions/DGPMonomial/P2/P2_DGPMonomial_shape0005.png * * - * - *
    * @image html http://www.dealii.org/images/shape-functions/DGPMonomial/P2/P2_DGPMonomial_shape0000.png *
    $P_2$ element, shape function 4 $P_2$ element, shape function 5
    + *     		$P_2$ element, shape function 5
    * * *

    $P_3$ element

    * - * - *
    + * * @@ -207,13 +199,10 @@ template class MappingQ; * @image html http://www.dealii.org/images/shape-functions/DGPMonomial/P3/P3_DGPMonomial_shape0009.png * * - * - *
    * @image html http://www.dealii.org/images/shape-functions/DGPMonomial/P3/P3_DGPMonomial_shape0000.png *
    $P_3$ element, shape function 8 $P_3$ element, shape function 9
    + *     		$P_3$ element, shape function 9
    * * - *

    $P_4$ element

    - * - *
    + *

    $P_4$ element

    * @@ -287,11 +276,10 @@ template class MappingQ; * @image html http://www.dealii.org/images/shape-functions/DGPMonomial/P4/P4_DGPMonomial_shape0014.png * * - * + * * - * - *
    * @image html http://www.dealii.org/images/shape-functions/DGPMonomial/P4/P4_DGPMonomial_shape0000.png * - *
    $P_4$ element, shape function 14
    $P_4$ element, + * shape function 14
    + *
    * * @author Ralf Hartmann, 2004 */ diff --git a/include/deal.II/fe/fe_dgp_nonparametric.h b/include/deal.II/fe/fe_dgp_nonparametric.h index e4dab29fff..b5258327bb 100644 --- a/include/deal.II/fe/fe_dgp_nonparametric.h +++ b/include/deal.II/fe/fe_dgp_nonparametric.h @@ -51,28 +51,23 @@ template class MappingQ; * (spacedim != dim). * * - *

    Visualization of shape functions

    - * In 2d, the shape functions of this element look as follows. + *

    Visualization of shape functions

    In 2d, the shape functions of + * this element look as follows. * *

    $P_0$ element

    * - * - * - *
    + * * - * + * * - * - *
    * @image html http://www.dealii.org/images/shape-functions/DGPNonparametric/P1/P1_DGPNonparametric_shape0000.png * - *
    $P_0$ element, shape function 0
    $P_0$ element, + * shape function 0
    + *
    * *

    $P_1$ element

    * - * - * - * + * * * * @@ -135,8 +135,8 @@ template class MappingQ; * * + * * *
    + * * @@ -86,16 +81,15 @@ template class MappingQ; * @image html http://www.dealii.org/images/shape-functions/DGPNonparametric/P1/P1_DGPNonparametric_shape0002.png * * - * + * * *
    * @image html http://www.dealii.org/images/shape-functions/DGPNonparametric/P1/P1_DGPNonparametric_shape0000.png * - *
    $P_1$ element, shape function 2
    $P_1$ element, + * shape function 2
    * * *

    $P_2$ element

    * - * - *
    + * * @@ -123,14 +117,12 @@ template class MappingQ; * @image html http://www.dealii.org/images/shape-functions/DGPNonparametric/P2/P2_DGPNonparametric_shape0005.png * * - * - *
    * @image html http://www.dealii.org/images/shape-functions/DGPNonparametric/P2/P2_DGPNonparametric_shape0000.png *
    $P_2$ element, shape function 4 $P_2$ element, shape function 5
    + *     		$P_2$ element, shape function 5
    * * *

    $P_3$ element

    * - * - *
    + * * @@ -178,13 +170,10 @@ template class MappingQ; * @image html http://www.dealii.org/images/shape-functions/DGPNonparametric/P3/P3_DGPNonparametric_shape0009.png * * - * - *
    * @image html http://www.dealii.org/images/shape-functions/DGPNonparametric/P3/P3_DGPNonparametric_shape0000.png *
    $P_3$ element, shape function 8 $P_3$ element, shape function 9
    + *     		$P_3$ element, shape function 9
    * * - *

    $P_4$ element

    - * - *
    + *

    $P_4$ element

    * @@ -258,11 +247,10 @@ template class MappingQ; * @image html http://www.dealii.org/images/shape-functions/DGPNonparametric/P4/P4_DGPNonparametric_shape0014.png * * - * + * * - * - *
    * @image html http://www.dealii.org/images/shape-functions/DGPNonparametric/P4/P4_DGPNonparametric_shape0000.png * - *
    $P_4$ element, shape function 14
    $P_4$ element, + * shape function 14
    + *
    * * @author Guido Kanschat, 2002 */ diff --git a/include/deal.II/fe/fe_q_hierarchical.h b/include/deal.II/fe/fe_q_hierarchical.h index 0345ab913b..00a92026db 100644 --- a/include/deal.II/fe/fe_q_hierarchical.h +++ b/include/deal.II/fe/fe_q_hierarchical.h @@ -124,8 +124,8 @@ template class MappingQ; * *     		* @image html http://www.dealii.org/images/shape-functions/hierarchical/Q1/Q1H_shape0001.png - *
    $Q_1^H$ element, shape function 0
    $Q_1^H$ element, shape function 0 + * $Q_1^H$ element, shape function 1
    * @image html http://www.dealii.org/images/shape-functions/hierarchical/Q1/Q1H_shape0003.png - *
    $Q_1^H$ element, shape function 2
    $Q_1^H$ element, shape function 2 + * $Q_1^H$ element, shape function 3
    * @@ -225,8 +225,8 @@ template class MappingQ; * *     		* @image html http://www.dealii.org/images/shape-functions/hierarchical/Q2/Q2H_shape0001.png - *
    $Q_2^H$ element, shape function 0
    $Q_2^H$ element, shape function 0 + * $Q_2^H$ element, shape function 1
    * @image html http://www.dealii.org/images/shape-functions/hierarchical/Q2/Q2H_shape0003.png - *
    $Q_2^H$ element, shape function 2
    $Q_2^H$ element, shape function 2 + * $Q_2^H$ element, shape function 3
    * @image html http://www.dealii.org/images/shape-functions/hierarchical/Q2/Q2H_shape0005.png - *
    $Q_2^H$ element, shape function 4
    $Q_2^H$ element, shape function 4 + * $Q_2^H$ element, shape function 5
    * @image html http://www.dealii.org/images/shape-functions/hierarchical/Q2/Q2H_shape0007.png - *
    $Q_2^H$ element, shape function 6
    $Q_2^H$ element, shape function 6 + * $Q_2^H$ element, shape function 7
    * @image html http://www.dealii.org/images/shape-functions/hierarchical/Q3/Q3H_shape0001.png - *
    $Q_3^H$ element, shape function 0
    $Q_3^H$ element, shape function 0 + * $Q_3^H$ element, shape function 1
    * @image html http://www.dealii.org/images/shape-functions/hierarchical/Q3/Q3H_shape0003.png - *
    $Q_3^H$ element, shape function 2
    $Q_3^H$ element, shape function 2 + * $Q_3^H$ element, shape function 3
    * @image html http://www.dealii.org/images/shape-functions/hierarchical/Q3/Q3H_shape0005.png - *
    $Q_3^H$ element, shape function 4
    $Q_3^H$ element, shape function 4 + * $Q_3^H$ element, shape function 5
    * @image html http://www.dealii.org/images/shape-functions/hierarchical/Q3/Q3H_shape0007.png - *
    $Q_3^H$ element, shape function 6
    $Q_3^H$ element, shape function 6 + * $Q_3^H$ element, shape function 7
    * @image html http://www.dealii.org/images/shape-functions/hierarchical/Q3/Q3H_shape0009.png - *
    $Q_3^H$ element, shape function 8
    $Q_3^H$ element, shape function 8 + * $Q_3^H$ element, shape function 9
    * @image html http://www.dealii.org/images/shape-functions/hierarchical/Q3/Q3H_shape0011.png - *
    $Q_3^H$ element, shape function 10
    $Q_3^H$ element, shape function 10 + * $Q_3^H$ element, shape function 11
    * @image html http://www.dealii.org/images/shape-functions/hierarchical/Q3/Q3H_shape0013.png - *
    $Q_3^H$ element, shape function 12
    $Q_3^H$ element, shape function 12 + * $Q_3^H$ element, shape function 13
    * @image html http://www.dealii.org/images/shape-functions/hierarchical/Q3/Q3H_shape0015.png - *
    $Q_3^H$ element, shape function 14
    $Q_3^H$ element, shape function 14 + * $Q_3^H$ element, shape function 15
    * @@ -412,8 +412,8 @@ template class MappingQ; * *     		* @image html http://www.dealii.org/images/shape-functions/hierarchical/Q4/Q4H_shape0001.png - *
    $Q_4^H$ element, shape function 0
    $Q_4^H$ element, shape function 0 + * $Q_4^H$ element, shape function 1
    * @image html http://www.dealii.org/images/shape-functions/hierarchical/Q4/Q4H_shape0003.png - *
    $Q_4^H$ element, shape function 2
    $Q_4^H$ element, shape function 2 + * $Q_4^H$ element, shape function 3
    * @image html http://www.dealii.org/images/shape-functions/hierarchical/Q4/Q4H_shape0005.png - *
    $Q_4^H$ element, shape function 4
    $Q_4^H$ element, shape function 4 + * $Q_4^H$ element, shape function 5
    * @image html http://www.dealii.org/images/shape-functions/hierarchical/Q4/Q4H_shape0007.png - *
    $Q_4^H$ element, shape function 6
    $Q_4^H$ element, shape function 6 + * $Q_4^H$ element, shape function 7
    * @image html http://www.dealii.org/images/shape-functions/hierarchical/Q4/Q4H_shape0009.png - *
    $Q_4^H$ element, shape function 8
    $Q_4^H$ element, shape function 8 + * $Q_4^H$ element, shape function 9
    * @image html http://www.dealii.org/images/shape-functions/hierarchical/Q4/Q4H_shape0011.png - *
    $Q_4^H$ element, shape function 10
    $Q_4^H$ element, shape function 10 + * $Q_4^H$ element, shape function 11
    * @image html http://www.dealii.org/images/shape-functions/hierarchical/Q4/Q4H_shape0013.png - *
    $Q_4^H$ element, shape function 12
    $Q_4^H$ element, shape function 12 + * $Q_4^H$ element, shape function 13
    * @image html http://www.dealii.org/images/shape-functions/hierarchical/Q4/Q4H_shape0015.png - *
    $Q_4^H$ element, shape function 14
    $Q_4^H$ element, shape function 14 + * $Q_4^H$ element, shape function 15
    * @image html http://www.dealii.org/images/shape-functions/hierarchical/Q4/Q4H_shape0017.png - *
    $Q_4^H$ element, shape function 16
    $Q_4^H$ element, shape function 16 + * $Q_4^H$ element, shape function 17
    * @image html http://www.dealii.org/images/shape-functions/hierarchical/Q4/Q4H_shape0019.png - *
    $Q_4^H$ element, shape function 18
    $Q_4^H$ element, shape function 18 + * $Q_4^H$ element, shape function 19
    * @image html http://www.dealii.org/images/shape-functions/hierarchical/Q4/Q4H_shape0021.png - *
    $Q_4^H$ element, shape function 20
    $Q_4^H$ element, shape function 20 + * $Q_4^H$ element, shape function 21
    * @image html http://www.dealii.org/images/shape-functions/hierarchical/Q4/Q4H_shape0023.png - *
    $Q_4^H$ element, shape function 22
    $Q_4^H$ element, shape function 22 + * $Q_4^H$ element, shape function 23