* freedom; among its functions are ones that sort degrees of freedom in
* downstream direction, for example, and ones that sort degrees of freedom in
* such a way that the bandwidth of associated matrices is minimized. Finally,
- * the DoFTools class offers a variety of algorithms around handling degrees
- * of freedom.
+ * the DoFTools namespace offers a variety of algorithms around handling
+ * degrees of freedom.
*/
dof_handler,
hanging_node_constraints);
* @endcode
- * Note that DoFTools::make_hanging_node_constraints is a static member
- * function and so does not need an object of type DoFTools to work on.
- * (In fact, DoFTools has only static member functions and could as well be
- * a namespace instead of class; that it is a class at the time of writing
- * this is mostly a historic relic.)
*
* Similarly, if we want to call a member function on a different task, we can
* do so by specifying the object on which to call the function as first
// ---------------------------------------------------------------------
//
-// Copyright (C) 2006 - 2013 by the deal.II authors
+// Copyright (C) 2006 - 2015 by the deal.II authors
//
// This file is part of the deal.II library.
//
* quantities in the first two cases, or help transferring a set of vectors
* from one mesh to another.
*
- * The remaining classes MatrixCreator, MatrixTools, and VectorTools provide
- * an assortment of services, such as creating a Laplac matrix, projecting or
+ * The namespaces MatrixCreator, MatrixTools, and VectorTools provide an
+ * assortment of services, such as creating a Laplac matrix, projecting or
* interpolating a function onto the present finite element space, etc. The
* difference to the functions in the DoFTools and FETools functions is that
* they work on vectors (i.e. members of a finite element function space on a
// Next task is to construct the object representing the constraint that
// the mean value of the degrees of freedom on the boundary shall be
// zero. For this, we first want a list of those nodes which are actually
- // at the boundary. The <code>DoFTools</code> class has a function that
- // returns an array of Boolean values where <code>true</code> indicates
- // that the node is at the boundary. The second argument denotes a mask
- // selecting which components of vector valued finite elements we want to
- // be considered. This sort of information is encoded using the
+ // at the boundary. The <code>DoFTools</code> namespace has a function
+ // that returns an array of Boolean values where <code>true</code>
+ // indicates that the node is at the boundary. The second argument denotes
+ // a mask selecting which components of vector valued finite elements we
+ // want to be considered. This sort of information is encoded using the
// ComponentMask class (see also @ref GlossComponentMask). Since we have a
// scalar finite element anyway, this mask in reality should have only one
// entry with a <code>true</code> value. However, the ComponentMask class
// mapping; or you want to assembled the matrix with a coefficient in the
// Laplace operator. For this reason, there are quite a large number of
// variants of these functions in the <code>MatrixCreator</code> and
- // <code>MatrixTools</code> classes. Whenever you need a slightly
+ // <code>MatrixTools</code> namespaces. Whenever you need a slightly
// different version of these functions than the ones called above, it is
// certainly worthwhile to take a look at the documentation and to check
// whether something fits your needs.
#include <deal.II/lac/petsc_precondition.h>
// And in addition, we need some algorithms for partitioning our meshes so
// that they can be efficiently distributed across an MPI network. The
-// partitioning algorithm is implemented in the <code>GridTools</code> class,
-// and we need an additional include file for a function in
+// partitioning algorithm is implemented in the <code>GridTools</code>
+// namespace, and we need an additional include file for a function in
// <code>DoFRenumbering</code> that allows to sort the indices associated with
// degrees of freedom so that they are numbered according to the subdomain
// they are associated with:
#include <fstream>
#include <iostream>
-// This is the only new one: We will need a library function defined in a
-// class GridTools that computes the minimal cell diameter.
+// This is the only new one: We will need a library function defined in the
+// namespace GridTools that computes the minimal cell diameter.
#include <deal.II/grid/grid_tools.h>
// The last step is as in all previous programs:
// and refines it several times. Also, all matrix and vector members of the
// <code>SineGordonProblem</code> class are initialized to their appropriate
// sizes once the degrees of freedom have been assembled. Like step-24, we
- // use the <code>MatrixCreator</code> class to generate a mass matrix $M$
+ // use <code>MatrixCreator</code> functions to generate a mass matrix $M$
// and a Laplace matrix $A$ and store them in the appropriate variables for
// the remainder of the program's life.
template <int dim>
$hp$ discretizations, assembling matrices and vectors, and other
tasks. We will get to know many of them further down below. In
addition, many of the functions in the DoFTools, and VectorTools
-classes accept $hp$ objects in addition to the non-$hp$ ones. Much of
+namespaces accept $hp$ objects in addition to the non-$hp$ ones. Much of
the $hp$ implementation is also discussed in the @ref hp documentation
module and the links found there.
* versions, there are sections in this global documentation stating some
* commonalities.
*
- * All member functions are static, so there is no need to create an object of
- * class DoFTools.
- *
- *
* <h3>Setting up sparsity patterns</h3>
*
* When assembling system matrices, the entries are usually of the form
* interior to the domain, the result would be DoFHandler::invalid_dof_index.
* We need this mapping, for example, to build the mass matrix on the boundary
* (for this, see make_boundary_sparsity_pattern() function, the corresponding
- * section below, as well as the MatrixCreator class documentation).
+ * section below, as well as the MatrixCreator namespace documentation).
*
* Actually, there are two map_dof_to_boundary_indices() functions, one
* producing a numbering for all boundary degrees of freedom and one producing
* are on the boundary (i.e. much smaller matrices, in which we do not even
* build the large zero block that stems from the fact that most degrees of
* freedom have no support on the boundary of the domain). The first of these
- * tasks is done by the map_dof_to_boundary_indices() function of this class
- * (described above).
+ * tasks is done by the map_dof_to_boundary_indices() function (described
+ * above).
*
* The second part requires us first to build a sparsity pattern for the
* couplings between boundary nodes, and then to actually build the components
* of this matrix. While actually computing the entries of these small
- * boundary matrices is discussed in the MatrixCreator class, the creation of
- * the sparsity pattern is done by the create_boundary_sparsity_pattern()
+ * boundary matrices is discussed in the MatrixCreator namespace, the creation
+ * of the sparsity pattern is done by the create_boundary_sparsity_pattern()
* function. For its work, it needs to have a numbering of all those degrees
* of freedom that are on those parts of the boundary that we are interested
* in. You can get this from the map_dof_to_boundary_indices() function. It
/**
* This is a collection of functions operating on, and manipulating the
* numbers of degrees of freedom in a multilevel triangulation. It is similar
- * in purpose and function to the @p DoFTools class, but operates on levels of
- * DoFHandler objects. See there and the documentation of the member functions
- * for more information.
+ * in purpose and function to the @p DoFTools namespace, but operates on
+ * levels of DoFHandler objects. See there and the documentation of the member
+ * functions for more information.
*
* @author Wolfgang Bangerth, Guido Kanschat, 1999 - 2005, 2012
*/
* the multilevel vector #defect is filled with the residual of an outer
* defect correction scheme. This is usually taken care of by
* PreconditionMG). After vcycle(), the result is in the multilevel vector
- * #solution. See <tt>copy_*_mg</tt> in class MGTools if you want to use
- * these vectors yourself.
+ * #solution. See <tt>copy_*_mg</tt> in the MGTools namespace if you want to
+ * use these vectors yourself.
*
* The actual work for this function is done in level_v_step().
*/
// GridTools::find_active_cell_around_point
// to obtain a cell to search is an
// option for these methods, but currently
- // the GridTools method does not cater for
+ // the GridTools function does not cater for
// a vector of points, and does not seem to
// be intrinsicly faster than this method.
for (unsigned int component = 0;
projects / dealii.git / commitdiff