* but make sure that the object pointed to is not deleted in the course of
* use of the pointer by signalling the pointee its use.
*
- * Objects pointed to, that is ,the class T, should inherit
+ * Objects pointed to, i.e. the class T, should inherit
* Subscriptor or must implement the same functionality. Null pointers
* are an exception from this rule and are allowed, too.
*
* use the <tt>vector_value</tt> function, which however does not return
* the value, but rather writes it into the address provided by its
* second argument. The reason for the different behaviour of the
- * classes is that in the case if tensor valued functions, the size
+ * classes is that in the case of tensor valued functions, the size
* of the argument is known to the compiler a priori, such that the
* correct amount of memory can be allocated on the stack for the
* return value; on the other hand, for the vector valued functions,
* coarsening a distributed grid and
* handles the necessary communication.
*
- * @note: It is important to note, that if you use more than one
+ * @note It is important to note, that if you use more than one
* SolutionTransfer object at the same time, that the calls to
* prepare_*() and interpolate()/deserialize() need to be in the same order.
*
* that is associated with faces, rather than cells, as this information is independent of
* the hierarchical structure of cells, which are organized in levels. In 2D we store
* information on degrees of freedom located on lines whereas in 3D we store information on
- * drefrees of freedom located on quads and lines. In 1D we do nothing, as the faces of
+ * degrees of freedom located on quads and lines. In 1D we do nothing, as the faces of
* lines are vertices which are treated seperately.
*
* Apart from the DoFObjects object containing the data to store (degree of freedom
*
* The indices of degrees of freedom located on lower dimensional
* objects, i.e. on lines for 2D and on quads and lines for 3D are
- * treated similarly than that on cells. However, theses geometrical
+ * treated similarly than that on cells. However, these geometrical
* objects, which are called faces as a generalisation, are not
* organised in a hierarchical structure of levels. Therefore, the
* degrees of freedom located on these objects are stored in separate
* A structure used by the
* DoFHandler classes to store
* information about the degrees
- * of freedom they deals with.
+ * of freedom they deal with.
*/
struct NumberCache
{
* the library, for example the
* constructors of FESystem as
* well as the hp::FECollection
- * class, need to make copied of
+ * class, need to make copies of
* finite elements without
* knowing their exact type. They
* do so through this function.
/**
* Constructor, computing all necessary values from the distribution of dofs
- * to geometrcal objects.
+ * to geometrical objects.
*
* @param dofs_per_object Number of dofs on geometrical objects for each
* dimension. In this vector, entry 0 refers to dofs on vertices, entry 1 on
* Return a string that uniquely
* identifies a finite
* element. This class returns
- * <tt>FE_DGQ<dim>(degree)</tt> , with
+ * <tt>FE_DGQ<dim>(degree)</tt>, with
* <tt>dim</tt> and <tt>degree</tt>
* replaced by appropriate
* values.
* Return a string that uniquely
* identifies a finite
* element. This class returns
- * <tt>FE_DGQ<dim>(degree)</tt> , with
+ * <tt>FE_DGQ<dim>(degree)</tt>, with
* <tt>dim</tt> and <tt>degree</tt>
* replaced by appropriate
* values.
/**
* This class gives a unified framework for the implementation of
- * FiniteElement classes based on a polynomial spaces like the
- * TensorProductPolynomials or a PolynomialSpace classes.
+ * FiniteElement classes based on polynomial spaces like the
+ * TensorProductPolynomials or PolynomialSpace classes.
*
* Every class conforming to the following interface can be used as
* template parameter POLY.
* based on polynomial spaces like the TensorProductPolynomials or a
* PolynomialSpace classes.
*
- * Every class that implements following functions can be used as
+ * Every class that implements the following functions can be used as
* template parameter POLY.
*
* @code
*
* @note The matrix #inverse_node_matrix should have dimensions zero
* before this piece of code is executed. Only then,
- * shape_value_component() will return the raw bolynomial <i>j</i> as
+ * shape_value_component() will return the raw polynomial <i>j</i> as
* defined in the polynomial space POLY.
*
* <h4>Setting the transformation</h4>
* of the cells. Convention is, that the
* neighbors of the cell with index @p i
* are stored in the fields following
- * $i*(2*real_space_dimension)$, e.g. in
+ * $i*(2*real\_space\_dimension)$, e.g. in
* one spatial dimension, the neighbors
* of cell 0 are stored in <tt>neighbors[0]</tt>
* and <tt>neighbors[1]</tt>, the neighbors of
* element function. In order to do so, it needs to find out where
* the points lie.
*
- * If you know in advance in which cell your points lye, you can
+ * If you know in advance in which cell your points lie, you can
* accelerate things a bit, by calling set_active_cell before
* asking for values or gradients of the function. If you don't do
* this, and your points don't lie in the cell that is currently
* or to the first nonzero main diagonal entry if it is zero for some reason.
* Of course we have to change the right hand side appropriately. This is not
* a very good strategy, but it at least should give the main diagonal entry a
- * value in the right order of dimension, which makes the solvution process a
+ * value in the right order of dimension, which makes the solution process a
* bit more stable. A refined algorithm would set the entry to the mean of the
* other diagonal entries, but this seems to be too expensive.
*
* map of boundary values.
*
* The parameter
- * @p function_map argument
+ * @p function_map
* provides a list of boundary
* indicators to be handled by
* this function and corresponding
projects / dealii-svn.git / commitdiff