* CompressedSetSparsityPattern
* class instead, see for example
* @ref step_27 "step-27" and
- * @ref step_31 "step-31".
+ * @ref step_22 "step-22".
*/
void condense (CompressedSparsityPattern &sparsity) const;
* BlockCompressedSetSparsityPattern
* class instead, see for example
* @ref step_27 "step-27" and
- * @ref step_31 "step-31".
+ * @ref step_22 "step-22".
*/
void condense (BlockCompressedSparsityPattern &sparsity) const;
* Access to base element
* objects. If the element is
* scalar, then
- * #base_element(0) is
+ * <code>base_element(0)</code> is
* @p this.
*/
virtual
* @note The triangulation needs to be
* void upon calling this
* function.
- *
- * @note For an example of the
- * use of this function see the
- * @ref step_28 "step-28"
- * tutorial program.
*/
template <int dim>
static
* This material_id may be set upon construction of a
* triangulation (through the CellData data structure), or later
* through use of cell iterators. For a typical use of this
- * functionality, see the @ref step_28 "step-28" tutorial
- * program. The functions of the GridGenerator namespace typically
+ * functionality. The functions of the GridGenerator namespace typically
* set the material ID of all cells to zero. When reading a
* triangulation, the material id must be specified in the input
* file (UCD format) or is otherwise set to zero. Material IDs are
/**
* Return the material id of this
* cell.
- *
- * For a typical use of this
- * function, see the @ref step_28
- * "step-28" tutorial program.
*/
unsigned char material_id () const;
/**
* Set the material id of this
* cell.
- *
- * For a typical use of this
- * function, see the @ref step_28
- * "step-28" tutorial program.
*/
void set_material_id (const unsigned char new_material_id) const;
* distribute the solution vector
* afterwards.
*
- * The use of this function is
- * explained in more detail in
- * @ref step_31 "step-31". It
- * doesn't make much sense in 1d,
- * so the function throws an
- * exception in that case.
- *
* The second argument of this
* function denotes the first
* vector component in the finite
../../deal.II/include/multigrid \
../../deal.II/include/numerics \
tutorial/doxygen \
- ../news/6.0.0-vs-6.1.0.h \
- ../news/changes.h
+ ../news/6.0.0-vs-6.1.0.h
HTML_OUTPUT = deal.II
LATEX_OUTPUT = LaTeX/deal.II
* solution is the scalar pressure and the vector-valued velocity
* at each point.
* <li>The Stokes equation and its extensions discussed in
- * @ref step_22 "step-22", and @ref step_31 "step-31" in which again
+ * @ref step_22 "step-22" in which again
* the solution is the scalar pressure and the vector-valued velocity
* at each point.
* <li>Complex-valued solutions consisting of real and imaginary parts, as
* </ul>
* Other examples of using extractors and views are shown in tutorial programs
* @ref step_21 "step-21",
- * @ref step_22 "step-22",
- * @ref step_31 "step-31" and a few other programs.
+ * @ref step_22 "step-22" and a few other programs.
*
*
* @anchor VVAlternative
* What is needed is to re-enumerate degrees of freedom so that velocities
* come first and pressures last. This can be done using the
* DoFRenumbering::component_wise function, as explained in @ref step_20
- * "step-20", @ref step_21 "step-21", @ref step_22 "step-22", and @ref step_31
- * "step-31". After this, at least the degrees of freedom are partitioned
+ * "step-20", @ref step_21 "step-21", and @ref step_22 "step-22".
+ * After this, at least the degrees of freedom are partitioned
* properly.
*
* But then we still have to make use of it, i.e. we have to come up with a
* large whole matrix we had before.
*
* How a solver like this is implemented is explained in more detail in @ref
- * step_20 "step-20", @ref step_31 "step-31", and a few other tutorial
+ * step_20 "step-20" and a few other tutorial
* programs. What we would like to point out here is that we now need a way to
* extract certain parts of a matrix or vector: if we are to multiply, say,
* the $U$ part of the solution vector by the $M$ part of the global matrix,
+++ /dev/null
-/**
- * @page changes_after_6.1 Changes after Version 6.1
-
-<p>
-This is the list of changes made after the release of
-deal.II version 6.1. It is subdivided into changes
-made to the three sub-libraries <a href="#base">base</a>,
-<a href="#lac">lac</a>, and <a href="#deal.II">deal.II</a>, as well as
-changes to the <a href="#general">general infrastructure,
-documentation, etc</a>.
-</p>
-
-<p>
-All entries are signed with the names of the author. Regular
-contributor's names are abbreviated by WB (Wolfgang Bangerth), GK
-(Guido Kanschat), RH (Ralf Hartmann).
-</p>
-
-
-<a name="incompatible"></a>
-<h3 style="color:red">Incompatibilities</h3>
-
-<p style="color:red">
-Following are a few modifications to the library that unfortunately
-are incompatible with previous versions of the library, but which we
-deem necessary for the future maintainability of the
-library. Unfortunately, some of these changes will require
-modifications to application programs. We apologize for the
-inconvenience this causes.
-</p>
-
-<ol>
-
-</ol>
-
-
-<a name="general"></a>
-<h3>General</h3>
-
-<ol>
-
-</ol>
-
-
-
-<a name="base"></a>
-<h3>base</h3>
-
-<ol>
-
-</ol>
-
-
-
-<a name="lac"></a>
-<h3>lac</h3>
-
-<ol>
-
-</ol>
-
-
-
-<a name="deal.II"></a>
-<h3>deal.II</h3>
-
-<ol>
-
-</ol>
-
-
-*/
values of the quadrature point data on other cells if the corresponding cells
on the new mesh are assigned to this process after subdividing the new mesh. A
global communication of these data elements is therefore necessary, making the
-entire process a little more unpleasant. The @ref step_28 "step-28" tutorial
-program shows how to work with different meshes at the same time, albeit for a
-different kind of problem, giving indications on how to approach the problem
-for time-dependent adaptivity as well.
+entire process a little more unpleasant.
<h5>Ensuring mesh regularity</h5> At present, the program makes no attempt
$M^n=M^{n,n-1}=M$ and $A^n=A^{n,n-1}=A$. On the other hand, if we had
used different shape functions, then we would have to compute
integrals that contain shape functions defined on two meshes. This is a
-somewhat messy process that we omit here, but that is treated in some
-detail in @ref step_28 "step-28".
+somewhat messy process that we omit here.
Under these conditions (i.e. a mesh that doesn't change), one can optimize the
solution procedure a bit by basically eliminating the solution of the second
* BlockCompressedSetSparsityPattern) are interface-compatible it is
* frequently worth checking which version is more efficient.
*
- * This class is used in @ref step_31 "step-31".
+ * This class is used in @ref step_22 "step-22".
*
* @author Wolfgang Bangerth, 2007
*/
* module.
*
* This class is an example of the "dynamic" type of @ref Sparsity. It
- * is discussed in the @ref step_27 "step-27" and @ref step_31
- * "step-31" tutorial programs.
+ * is discussed in the @ref step_27 "step-27" and @ref step_22
+ * "step-22" tutorial programs.
*
* <h3>Interface</h3>
*
* situations, but seems to work much better than the
* CompressedSparsityPattern in the context of hp-adaptivity (see for
* example @ref step_27 "step-27"), or generally when there are many
- * nonzero entries in each row of a matrix (see @ref step_31
- * "step-31"). On the other hand, a benchmark where nonzero entries
+ * nonzero entries in each row of a matrix (see @ref step_22
+ * "step-22"). On the other hand, a benchmark where nonzero entries
* were randomly inserted into the sparsity pattern revealed that this
* class is slower by a factor 4-6 in this situation. Hence, currently
* the suggestion is to carefully analyze which of the
* that appears to be more efficient in some situations, in particular
* when using hp finite elements or, more generally, in cases with
* many nonzero entries. See for example the @ref step_27 "step-27"
- * and @ref step_31 "step-31" tutorial programs.
+ * and @ref step_22 "step-22" tutorial programs.
*
* @author Wolfgang Bangerth, 2001
*/
projects / dealii-svn.git / commitdiff