From: David Wells Date: Tue, 18 Aug 2015 11:55:36 +0000 (-0400) Subject: Fix references to classes that are now namespaces. X-Git-Tag: v8.4.0-rc2~589^2 X-Git-Url: https://gitweb.dealii.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=99e018702476e2a0240c5c2c4d48025b0d0bab2c;p=dealii.git Fix references to classes that are now namespaces. GridTools, DoFTools, MGTools, VectorTools, MatrixCreator, and MatrixTools were converted to namespaces in 2011 (see the list of changes between 7.0.0 and 7.1.0 file for a discussion). --- diff --git a/doc/doxygen/headers/dofs.h b/doc/doxygen/headers/dofs.h index d6bb74e321..36f5e9c792 100644 --- a/doc/doxygen/headers/dofs.h +++ b/doc/doxygen/headers/dofs.h @@ -58,6 +58,6 @@ * 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. */ diff --git a/doc/doxygen/headers/multithreading.h b/doc/doxygen/headers/multithreading.h index 9442d9d7af..0ac72826af 100644 --- a/doc/doxygen/headers/multithreading.h +++ b/doc/doxygen/headers/multithreading.h @@ -193,11 +193,6 @@ 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 diff --git a/doc/doxygen/headers/numerical_algorithms.h b/doc/doxygen/headers/numerical_algorithms.h index 8c709872b7..907e3ad94f 100644 --- a/doc/doxygen/headers/numerical_algorithms.h +++ b/doc/doxygen/headers/numerical_algorithms.h @@ -1,6 +1,6 @@ // --------------------------------------------------------------------- // -// 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. // @@ -27,8 +27,8 @@ * 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 diff --git a/examples/step-11/step-11.cc b/examples/step-11/step-11.cc index 1230b33b31..5f329f5720 100644 --- a/examples/step-11/step-11.cc +++ b/examples/step-11/step-11.cc @@ -138,11 +138,11 @@ namespace Step11 // 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 DoFTools class has a function that - // returns an array of Boolean values where true 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 DoFTools namespace has a function + // that returns an array of Boolean values where true + // 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 true value. However, the ComponentMask class @@ -289,7 +289,7 @@ namespace Step11 // 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 MatrixCreator and - // MatrixTools classes. Whenever you need a slightly + // MatrixTools 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. diff --git a/examples/step-17/step-17.cc b/examples/step-17/step-17.cc index 8d21b3c43d..c9ca29d365 100644 --- a/examples/step-17/step-17.cc +++ b/examples/step-17/step-17.cc @@ -73,8 +73,8 @@ #include // 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 GridTools class, -// and we need an additional include file for a function in +// partitioning algorithm is implemented in the GridTools +// namespace, and we need an additional include file for a function in // DoFRenumbering that allows to sort the indices associated with // degrees of freedom so that they are numbered according to the subdomain // they are associated with: diff --git a/examples/step-24/step-24.cc b/examples/step-24/step-24.cc index 62ebdffaff..86a9a74147 100644 --- a/examples/step-24/step-24.cc +++ b/examples/step-24/step-24.cc @@ -54,8 +54,8 @@ #include #include -// 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 // The last step is as in all previous programs: diff --git a/examples/step-25/step-25.cc b/examples/step-25/step-25.cc index 3a7af27620..7b18fb5549 100644 --- a/examples/step-25/step-25.cc +++ b/examples/step-25/step-25.cc @@ -285,7 +285,7 @@ namespace Step25 // and refines it several times. Also, all matrix and vector members of the // SineGordonProblem class are initialized to their appropriate // sizes once the degrees of freedom have been assembled. Like step-24, we - // use the MatrixCreator class to generate a mass matrix $M$ + // use MatrixCreator 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 diff --git a/examples/step-27/doc/intro.dox b/examples/step-27/doc/intro.dox index d728c0814c..3945e32e73 100644 --- a/examples/step-27/doc/intro.dox +++ b/examples/step-27/doc/intro.dox @@ -65,7 +65,7 @@ the hp namespace. This namespace provides classes that handle $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. diff --git a/include/deal.II/dofs/dof_tools.h b/include/deal.II/dofs/dof_tools.h index 7e6c33c19c..7123a4ffbd 100644 --- a/include/deal.II/dofs/dof_tools.h +++ b/include/deal.II/dofs/dof_tools.h @@ -65,10 +65,6 @@ namespace GridTools * 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. - * - * *

Setting up sparsity patterns

* * When assembling system matrices, the entries are usually of the form @@ -108,7 +104,7 @@ namespace GridTools * 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 @@ -160,14 +156,14 @@ namespace GridTools * 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 diff --git a/include/deal.II/multigrid/mg_tools.h b/include/deal.II/multigrid/mg_tools.h index 0ab1530731..7d21e6a88f 100644 --- a/include/deal.II/multigrid/mg_tools.h +++ b/include/deal.II/multigrid/mg_tools.h @@ -42,9 +42,9 @@ template class BlockSparseMatrix; /** * 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 */ diff --git a/include/deal.II/multigrid/multigrid.h b/include/deal.II/multigrid/multigrid.h index 5a2aa5e8d9..1fa5a5cc21 100644 --- a/include/deal.II/multigrid/multigrid.h +++ b/include/deal.II/multigrid/multigrid.h @@ -129,8 +129,8 @@ public: * 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 copy_*_mg in class MGTools if you want to use - * these vectors yourself. + * #solution. See copy_*_mg in the MGTools namespace if you want to + * use these vectors yourself. * * The actual work for this function is done in level_v_step(). */ diff --git a/source/numerics/point_value_history.cc b/source/numerics/point_value_history.cc index 006d19abca..4894478158 100644 --- a/source/numerics/point_value_history.cc +++ b/source/numerics/point_value_history.cc @@ -291,7 +291,7 @@ void PointValueHistory // 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;