]> https://gitweb.dealii.org/ - dealii.git/commitdiff
Since we now have only a single set of documentation pages, move everything up one...
authorWolfgang Bangerth <bangerth@math.tamu.edu>
Fri, 13 Jan 2006 23:13:05 +0000 (23:13 +0000)
committerWolfgang Bangerth <bangerth@math.tamu.edu>
Fri, 13 Jan 2006 23:13:05 +0000 (23:13 +0000)
git-svn-id: https://svn.dealii.org/trunk@12019 0785d39b-7218-0410-832d-ea1e28bc413d

22 files changed:
deal.II/doc/doxygen/headers/boundary.h [new file with mode: 0644]
deal.II/doc/doxygen/headers/dofs.h [new file with mode: 0644]
deal.II/doc/doxygen/headers/exceptions.h [new file with mode: 0644]
deal.II/doc/doxygen/headers/fe.h [new file with mode: 0644]
deal.II/doc/doxygen/headers/glossary.h [moved from deal.II/doc/doxygen/headers/deal.II/glossary.h with 93% similarity]
deal.II/doc/doxygen/headers/grid.h [new file with mode: 0644]
deal.II/doc/doxygen/headers/hp.h [moved from deal.II/doc/doxygen/headers/deal.II/dox.h with 86% similarity]
deal.II/doc/doxygen/headers/instantiations.h [moved from deal.II/doc/doxygen/headers/base/instantiations.h with 100% similarity]
deal.II/doc/doxygen/headers/io.h [new file with mode: 0644]
deal.II/doc/doxygen/headers/iterators.h [moved from deal.II/doc/doxygen/headers/deal.II/iterators.h with 100% similarity]
deal.II/doc/doxygen/headers/lac.h [new file with mode: 0644]
deal.II/doc/doxygen/headers/lac/dox.h [deleted file]
deal.II/doc/doxygen/headers/matrices.h [new file with mode: 0644]
deal.II/doc/doxygen/headers/mg.h [new file with mode: 0644]
deal.II/doc/doxygen/headers/petsc.h [new file with mode: 0644]
deal.II/doc/doxygen/headers/polynomials.h [new file with mode: 0644]
deal.II/doc/doxygen/headers/preconditioners.h [new file with mode: 0644]
deal.II/doc/doxygen/headers/quadrature.h [moved from deal.II/doc/doxygen/headers/base/dox.h with 86% similarity]
deal.II/doc/doxygen/headers/software.h [moved from deal.II/doc/doxygen/headers/base/software.h with 60% similarity]
deal.II/doc/doxygen/headers/solvers.h [new file with mode: 0644]
deal.II/doc/doxygen/headers/vector_memory.h [new file with mode: 0644]
deal.II/doc/doxygen/headers/vectors.h [new file with mode: 0644]

diff --git a/deal.II/doc/doxygen/headers/boundary.h b/deal.II/doc/doxygen/headers/boundary.h
new file mode 100644 (file)
index 0000000..f087304
--- /dev/null
@@ -0,0 +1,65 @@
+//-------------------------------------------------------------------------
+//    $Id$
+//    Version: $Name$
+//
+//    Copyright (C) 2003, 2005, 2006 by the deal.II authors
+//
+//    This file is subject to QPL and may not be  distributed
+//    without copyright and license information. Please refer
+//    to the file deal.II/doc/license.html for the  text  and
+//    further information on this license.
+//
+//-------------------------------------------------------------------------
+
+/**
+ * @defgroup boundary Boundary description for triangulations
+ *
+ * The classes in this module are concerned with the description of the
+ * boundary of a domain in which a Triangulation lives. This boundary
+ * description is necessary in two contexts:
+ * <ul>
+ * 
+ *   <li> Mesh refinement: whenever a cell at the boundary is refined, it is
+ *   necessary to introduce at least one new vertex on the boundary. In the
+ *   simplest case, one assumes that the boundary consists of straight line
+ *   segments between the vertices of the original, coarsest mesh, and the
+ *   next vertex is simply put into the middle of the old ones. This is the
+ *   default behavior of the Triangulation class, and is described by the
+ *   StraightBoundary class.
+ *
+ *   On the other hand, if one deals with curved boundaries, this is not the
+ *   appropriate thing to do. The classes derived from the Boundary base class
+ *   therefore describe the geometry of a domain. One can then attach an
+ *   object of a class derived from this base class to the Triangulation
+ *   object using the Triangulation::set_boundary() function. Several classes
+ *   exist to support the most common geometries.
+ *
+ *   <li> Integration: When using higher order finite element methods, it is
+ *   often necessary to compute cell terms (like cell contributions to the
+ *   matrix and right hand side of the linear system) using curved
+ *   approximations of the boundary, rather than the straight line
+ *   approximation. The actual implementation of such curved elements happens
+ *   in the Mapping class (see the @ref mapping module), which however obtains
+ *   its information about the boundary of the domain from the classes
+ *   described here.
+ *
+ * </ul>
+ *
+ * In the context of triangulations, each face of a cell that is located at
+ * the boundary of the domain stores a number called <tt>boundary_id</tt> that
+ * uniquely identifies which part of the boundary this face is on. If nothing
+ * is specified at creation time, each boundary face has a zero boundary
+ * id. On the other hand, the boundary id of faces can be set either at
+ * creation time or later by looping over all cells and querying their faces.
+ *
+ * It is then possible to associate objects describing the boundary to certain
+ * boundary_id values used in a triangulation. Note that this is not
+ * necessary: in some cases one may want to use the default straight boundary
+ * approximation, and use non-zero boundary indicators for completely
+ * different purposes, for example to indicate that a part of the boundary has
+ * a different kind of boundary condition in the partial differential
+ * equation.
+ * 
+ * @ingroup grid
+ * @author Wolfgang Bangerth, 1998-2006
+ */
diff --git a/deal.II/doc/doxygen/headers/dofs.h b/deal.II/doc/doxygen/headers/dofs.h
new file mode 100644 (file)
index 0000000..bd411d4
--- /dev/null
@@ -0,0 +1,42 @@
+//-------------------------------------------------------------------------
+//    $Id$
+//    Version: $Name$
+//
+//    Copyright (C) 2003, 2005, 2006 by the deal.II authors
+//
+//    This file is subject to QPL and may not be  distributed
+//    without copyright and license information. Please refer
+//    to the file deal.II/doc/license.html for the  text  and
+//    further information on this license.
+//
+//-------------------------------------------------------------------------
+
+/**
+ * @defgroup dofs Degrees of Freedom
+ *
+ * This module groups classes and namespace that have to do with handling
+ * degrees of freedom. The central class of this group is the DoFHandler
+ * class: it is built on top of a triangulation and a finite element class and
+ * allocated degrees of freedom on each cell of the triangulation as required
+ * for the finite element space described by the finite element object.
+ *
+ * DoFHandlers extend Triangulation objects (and the other classes in the @ref
+ * grid module) in that they, too, offer iterators that run over all cells,
+ * faces, or other geometric objects that make up a triangulation. These
+ * iterators are derived from the triangulation iterators and therefore offer
+ * the same functionality, but they also offer additional functions. For
+ * example, they allow to query the indices of the degrees of freedom
+ * associated with the present cell.
+ *
+ * In addition to the DoFHandler class, this module holds a number of
+ * auxiliary classes not commonly used in application programs, as well as
+ * three classes that are not directly associated with the data structures of
+ * the DoFHandler class. The first of these is the ConstraintMatrix class that
+ * stores and treats the constraints associated with hanging nodes. Secondly,
+ * the DoFRenumbering namespace offers functions that can reorder degrees of
+ * 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.
+ */
diff --git a/deal.II/doc/doxygen/headers/exceptions.h b/deal.II/doc/doxygen/headers/exceptions.h
new file mode 100644 (file)
index 0000000..27b1054
--- /dev/null
@@ -0,0 +1,18 @@
+//-------------------------------------------------------------------------
+//    $Id$
+//    Version: $Name$
+//
+//    Copyright (C) 2003, 2005, 2006 by the deal.II authors
+//
+//    This file is subject to QPL and may not be  distributed
+//    without copyright and license information. Please refer
+//    to the file deal.II/doc/license.html for the  text  and
+//    further information on this license.
+//
+//-------------------------------------------------------------------------
+
+/**
+ * @defgroup Exceptions Exceptions
+ *
+ * @author Wolfgang Bangerth, 1998-2006
+ */
diff --git a/deal.II/doc/doxygen/headers/fe.h b/deal.II/doc/doxygen/headers/fe.h
new file mode 100644 (file)
index 0000000..756b6e5
--- /dev/null
@@ -0,0 +1,83 @@
+//-------------------------------------------------------------------------
+//    $Id$
+//    Version: $Name$
+//
+//    Copyright (C) 2003, 2005, 2006 by the deal.II authors
+//
+//    This file is subject to QPL and may not be  distributed
+//    without copyright and license information. Please refer
+//    to the file deal.II/doc/license.html for the  text  and
+//    further information on this license.
+//
+//-------------------------------------------------------------------------
+
+/**
+ * @defgroup feall Finite elements
+ *
+ * All classes related to shape functions and to access to shape
+ * functions.  This concerns the actual values of finite elements. For
+ * the numbering of degrees of freedom refer to the module on @ref dofs.
+ *
+ * The classes and functions of this module fall into several sub-groups that
+ * are discussed in their respective sub-modules listed above. In addition,
+ * the FETools class provides functions that provide information on finite
+ * elements, transformations between elements, etc.
+ */
+
+
+/**
+ * @defgroup febase Base classes
+ *
+ * The members of this sub-module describe the implementational mechanics of
+ * finite element classes, without actually implementing a concrete
+ * element. For example, the FiniteElement base class declares the virtual
+ * functions a derived class has to implement if it wants to describe a finite
+ * element space. Likewise, the FiniteElementData holds variables that
+ * describe certain values characterizing a finite element, such as the number
+ * of degrees of freedom per vertex, line, or face.
+ *
+ * On the other hand, classes like FE_Poly and FE_PolyTensor are higher
+ * abstractions. They describe finite elements that are built atop polynomial
+ * descriptions of the shape functions on the unit cell. Classes derived from
+ * them then only have to provide a description of the particular polynomial
+ * from which a finite element is built. For example, the FE_Q class that
+ * implements the usual Lagrange elements uses the FE_Poly base class to
+ * generate a finite element by providing it with a set of Lagrange
+ * interpolation polynomials corresponding to an equidistant subdivision of
+ * interpolation points.
+ *
+ * Finally, the FESystem class is used for vector-valued problems. There, one
+ * may want to couple a number of scalar (or also vector-valued) base elements
+ * together to form the joint finite element of a vector-valued operator. As
+ * an example, for 3d Navier-Stokes flow, one may want to use three Q1
+ * elements for the three components of the velocity, and a piecewise constant
+ * Q0 element for the pressure. The FESystem class can be used to couple these
+ * four base elements together into a single, vector-valued element with 4
+ * vector components. The step-8, step-17, and step-18 tutorial programs give
+ * an introduction into the use of this class in the context of the
+ * vector-valued elasticity (Lam&eacute;) equations. step-20 discusses a mixed
+ * Laplace discretization that also uses vector-valued elements.
+ * 
+ * @ingroup feall
+ */
+
+
+/**
+ * @defgroup feaccess Finite element access classes (FEValues etc.)
+ *
+ * @ingroup feall
+ */
+
+
+/**
+ * @defgroup fe Finite element shape functions
+ *
+ * @ingroup feall
+ */
+
+
+/**
+ * @defgroup mapping Mappings between reference and real cell
+ *
+ * @ingroup feall
+ */
similarity index 93%
rename from deal.II/doc/doxygen/headers/deal.II/glossary.h
rename to deal.II/doc/doxygen/headers/glossary.h
index 34a1b6e0509b12a9976bb06b9bd39cd52747b207..6c1b6ac5d8147233f501633ab7bc9bf8efd79f37 100644 (file)
  *
  * <dt>@anchor GlossUnitSupport Unit support points</dt>
  * <dd>@ref GlossSupport "Support points" on the reference cell, defined in
- * FiniteElementBase.
+ * FiniteElementBase. For example, the usual Q1 element in 1d has support
+ * points  at <tt>x=0</tt> and <tt>x=1</tt> (and similarly, in higher
+ * dimensions at the vertices of the unit square or cube). On the other
+ * hand, higher order Lagrangian elements have unit support points also
+ * in the interior of the unit line, square, or cube.
  * </dd>
  *
  * </dl>
diff --git a/deal.II/doc/doxygen/headers/grid.h b/deal.II/doc/doxygen/headers/grid.h
new file mode 100644 (file)
index 0000000..fc76205
--- /dev/null
@@ -0,0 +1,107 @@
+//-------------------------------------------------------------------------
+//    $Id$
+//    Version: $Name$
+//
+//    Copyright (C) 2003, 2005, 2006 by the deal.II authors
+//
+//    This file is subject to QPL and may not be  distributed
+//    without copyright and license information. Please refer
+//    to the file deal.II/doc/license.html for the  text  and
+//    further information on this license.
+//
+//-------------------------------------------------------------------------
+
+/**
+ * @defgroup grid Grid classes
+ *
+ * This module groups classes that have to do with the topology and geometry
+ * of meshes. A mesh can be thought of a collection of cells; if the mesh has
+ * been refined (possibly in an adaptive way), then this collection is grouped
+ * into a hierarchy of refinement levels. In addition to cells, the geometric
+ * objects that make up a triangulation are the faces of cells (and in 3d the
+ * edges of cells) as well as the vertices of the cells.
+ *
+ * This collection of cells is managed by the Triangulation class. It holds
+ * the relevant data in memory and offers interfaces to query it. Most things
+ * you want to do on cells are performed in loops over all cells. For this
+ * purpose, the Triangulation class offers the concept of iterators (see @ref
+ * Iterators): although implemented differently, they behave like pointers to
+ * cells or faces and can be queried for the geometric properties of cells as
+ * well as information like neighboring cells or faces of a cell.
+ *
+ * It is worth noting that the Triangulation class only stores geometry
+ * (i.e. the location of vertices and cells) and topology of a mesh
+ * (i.e. which cells are neighbors of which other cells, etc). It has nothing
+ * to do with finite elements or degrees of freedom that might be defined on a
+ * mesh. These functions are performed by the DoFHandler class (see the @ref
+ * dofs module) that gets a description of the finite element space and the
+ * allocates and manages degrees of freedom on vertices, faces, or cells, as
+ * described by the finite element class. This separation makes it possible to
+ * have multiple DoFHandler classes work on the same mesh at the same time.
+ * 
+ * 
+ * <h3>Grid generation</h3>
+ *
+ * There are three ways to create a mesh:
+ * <ul>
+ * <li> Creation by the GridGenerator class;
+ * <li> Reading from a file;
+ * <li> Creation by hand.
+ * </ul>
+ *
+ * For the first case, the GridGenerator class provides functions that can
+ * generate the simplest and most common geometries automatically. For
+ * example, a rectangular (or brick) geometry as well as circles, spheres, or
+ * cylinders can be generate with the functions in this class. Most of the
+ * tutorial programs use this mechanism.
+ *
+ * Secondly, it is possible to read in meshes from an input file in a number
+ * of different formats using the GridIn class. Using this class, it is
+ * possible to read meshes with several 10 or 100 thousand cells, although
+ * this is not really recommended: the power of adaptive finite element
+ * methods only comes to bear if the initial mesh is as coarse as possible and
+ * there is room for a number of adaptive refinement steps. If the initial
+ * mesh is too fine already, then one runs out of memory or compute time
+ * before adaptive mesh refinement is able to do much good. Nevertheless, the
+ * GridIn class can be used in cases of complicated geometries or for
+ * comparison or interaction with other programs that compute on meshes that
+ * are then exchanged through this class The step-5 tutorial program shows how
+ * to use the GridIn class.
+ *
+ * The third way is to create a mesh by hand, by building a data structure
+ * that describes the vertices and cells of a triangulation. This is useful in
+ * cases of moderate complexity where a mesh can still be built by hand
+ * without resorting to a mesh generator, but where the domain is not one of
+ * those already supported by the GridIn class. In this method, the data
+ * structure so built is handed to the create_triangulation() function of the
+ * Triangulation class. The step-14 tutorial program shows how this can be
+ * done.
+ *
+ *
+ * <h3>Grid output</h3>
+ *
+ * Meshes can be written to output files in a number of different formats. If
+ * this involves simulation results obtained on this mesh, then this is done
+ * using the DataOut class (described in more detail in the @ref Output
+ * module). On the other hand, if only the geometry and topology of the mesh
+ * is to be written to a file, the GridOut class can do this for you.
+ *
+ *
+ * <h3>Tool classes</h3>
+ *
+ * The GridTool class offers an assortment of functions that act on grids. For
+ * example, this includes moving around nodes, stretching or rotating entire
+ * triangulations, computing the diameter of a domain, or subdividing it into
+ * chunks of roughly equal size for parallel computations.
+ *
+ * 
+ * <h3>Internal classes</h3>
+ *
+ * In addition to the above, there are a significant number of classes in this
+ * module that are only used in the internal data structures of mesh
+ * handling. They are generally in the internal namespace, and not meant for
+ * use in application code.
+ *
+ * 
+ * @author Wolfgang Bangerth, 1998-2006
+ */
similarity index 86%
rename from deal.II/doc/doxygen/headers/deal.II/dox.h
rename to deal.II/doc/doxygen/headers/hp.h
index 36c7a786c1a8cb544b34776fda1bdab49f46b06e..36716ef4fa7851517cb12d81fd3816ad7477e1d4 100644 (file)
 //
 //-------------------------------------------------------------------------
 
-/**
- * @defgroup grid Grid Classes
- */
-
-/**
- * @defgroup dofs Degrees of Freedom
- */
-
-/**
- * @defgroup feall Finite Elements
- *
- * All classes related to shape functions and to access to shape
- * functions.  This concerns the actual values of finite elements. For
- * the numbering of degrees of freedom refer to @ref dofs.
- *
- * @{
- */
-/**
- * @defgroup febase Base classes
- */
-
-/**
- * @defgroup feaccess Finite element access classes (FEValues etc.)
- */
-
-/**
- * @defgroup fe Finite element shape functions
- */
-
-/**
- * @defgroup mapping Mappings to the reference cell
- */
-
-/*@}*/
-
-/**
- * @defgroup mg Multilevel support
- */
-
 /**
  * @defgroup hp hp finite element support
  *
- * Classes and functions that have to do with hp finite elements.
+ * Classes and functions that have to do with hp finite elements. See the
+ * step-21 tutorial program for an example of how to use these classes.
  */
 
 /**
diff --git a/deal.II/doc/doxygen/headers/io.h b/deal.II/doc/doxygen/headers/io.h
new file mode 100644 (file)
index 0000000..ff69adc
--- /dev/null
@@ -0,0 +1,107 @@
+//-------------------------------------------------------------------------
+//    $Id$
+//    Version: $Name$
+//
+//    Copyright (C) 2005, 2006 by the deal.II authors
+//
+//    This file is subject to QPL and may not be  distributed
+//    without copyright and license information. Please refer
+//    to the file deal.II/doc/license.html for the  text  and
+//    further information on this license.
+//
+//-------------------------------------------------------------------------
+
+/**
+ * @defgroup IO Input/Output
+ *
+ * This module collects the classes used for reading and writing meshes and
+ * data. There are two sub-modules for each of these operations.
+ */
+
+/**
+ * @defgroup input Input
+ *
+ * deal.II can read meshes in a number of different formats. However, all of
+ * them are constrained to so-called "coarse meshes", i.e. meshes that have no
+ * refinement hierarchy and in particular no hanging nodes. The GridIn class
+ * describes in detail what formats are supported.
+ *
+ * In addition, deal.II can read an intermediate graphics format using the
+ * DataOutReader. This format is used as an intermediate step between data
+ * associated wiht a simulation and is written by the DataOutBase class (or
+ * through the more derived classes described in the \ref output module). The
+ * DataOutReader class reads this data back in, and it can then be converted
+ * to any of a number of data formats supported by visualization programs.
+ *
+ * @ingroup IO
+ */
+
+/**
+ * @defgroup output Output
+ *
+ * deal.II generates three types of output: it can write triangulations/meshes
+ * in formats understood by several mesh readers (including those of deal.II
+ * itself), and it can create output used for visualization of data. Finally,
+ * it can output matrices in a graphical format.
+ *
+ * 
+ * <h3>Visualization of data</h3>
+ * 
+ * deal.II supports, through the DataOutBase class, a large number of popular
+ * visualization formats, such as those used by the OpenDX, gmv, or gnuplot
+ * programs. A complete list of supported formats is listed in the
+ * documentation of the DataOutBase class.
+ *
+ * The DataOutBase class is only responsible for actually writing some
+ * intermediate format in a number of different visualization formats. This
+ * intermediate format is generated by classes derived, directly or
+ * indirectly, from DataOutBase. For example, the DataOut class is most often
+ * used to generate this intermediate format from a triangulation, a
+ * DoFHandler object (that associates a particular finite element class with
+ * the triangulation), and one or more data vectors. The DataOut class creates
+ * intermediate data from each cell, which is subsequently written by the
+ * DataOutBase class in some final format. Almost all example programs,
+ * starting with step-3, make use of this method of generating output.
+ *
+ * The DataOutFaces is another way to create intermediate format from
+ * simulation data. However, instead of creating visualization data from each
+ * cell of the triangulation, it only creates information for all faces of
+ * cells that are located on the surface (though the class has a way to
+ * override the choice for which faces output should be generated). While this
+ * may not be particularly interesting in 2d (the faces would only be line
+ * segments) it is often helpful in 3d if what one really wants to know is the
+ * shape of the domain or the value of one variable on the surface. Using the
+ * DataOutFaces class then saves the effort of generating and storing data for
+ * all interior cells, which can be very expensive for large 3d simulations.
+ *
+ * A third class, the DataOutRotation class, allows to take a two-dimensional
+ * simulation and generate three-dimensional data from it by rotating the
+ * two-dimensional domain around a given axis. This is mostly useful for the
+ * visualization of simulations that use the rotational symmetry of, for
+ * example, a cylinder.
+ *
+ * Finally, the DataOutStack class allows to visualize data from time
+ * dependent simulations in the space-time domain: it collects the results
+ * from each time step and at the end outputs all of this information at once
+ * as a space-time file.
+ * 
+ * 
+ * <h3>Grid output</h3>
+ *
+ * Meshes, without any data vectors associated with it, can be written in a
+ * number of formats as well. This is done through the GridOut class, and the
+ * documentation of that class lists the supported formats.
+ *
+ * Several of the tutorial programs, notably step-1, step-6, step-9, step-10,
+ * step-12, and step-14 demonstrate the use of the GridOut class.
+ *
+ *
+ * <h3>Matrix output</h3>
+ *
+ * Through the MatrixOut class, deal.II can also give a graphical
+ * visualization of matrices, in the form of color or skyline plots. The
+ * MatrixOut class uses the DataOutBase for output. Therefore, matrices can be
+ * visualization in all formats supported by the latter class.
+ *
+ * @ingroup IO
+ */
diff --git a/deal.II/doc/doxygen/headers/lac.h b/deal.II/doc/doxygen/headers/lac.h
new file mode 100644 (file)
index 0000000..361a15e
--- /dev/null
@@ -0,0 +1,24 @@
+//-------------------------------------------------------------------------
+//    $Id$
+//    Version: $Name$
+//
+//    Copyright (C) 2003, 2004, 2006 by the deal.II authors
+//
+//    This file is subject to QPL and may not be  distributed
+//    without copyright and license information. Please refer
+//    to the file deal.II/doc/license.html for the  text  and
+//    further information on this license.
+//
+//-------------------------------------------------------------------------
+
+
+/**
+ * @defgroup LAC Linear algebra classes
+ *
+ * In this module, classes that have to do with linear algebra are collected,
+ * i.e. mainly those associated matrices, vectors, and the solution of linear
+ * systems.
+ *
+ * The description of individual groups of classes can be found in
+ * sub-modules.
+ */
diff --git a/deal.II/doc/doxygen/headers/lac/dox.h b/deal.II/doc/doxygen/headers/lac/dox.h
deleted file mode 100644 (file)
index e24c799..0000000
+++ /dev/null
@@ -1,141 +0,0 @@
-//-------------------------------------------------------------------------
-//    $Id$
-//    Version: $Name$
-//
-//    Copyright (C) 2003, 2004, 2006 by the deal.II authors
-//
-//    This file is subject to QPL and may not be  distributed
-//    without copyright and license information. Please refer
-//    to the file deal.II/doc/license.html for the  text  and
-//    further information on this license.
-//
-//-------------------------------------------------------------------------
-
-
-/**
- * @defgroup LAC Linear algebra classes
- *
- * In this module, classes that have to do with linear algebra are collected,
- * i.e. mainly those associated matrices, vectors, and the solution of linear
- * systems.
- *
- * The description of individual groups of classes can be found in
- * sub-modules.
- */
-
-/**
- * @defgroup Vectors Vector classes
- *
- * Here, we list all the classes that can be used as VECTOR in linear solvers
- * (see Solver) and for matrix operations.
- *
- * @ingroup LAC
- */
-
-/**
- * @defgroup Matrices Matrix classes
- * @{
- *
- * All matrices in this library have a common minimal interface, defined
- * through MATRIX (see Solver documentation). This interface consists of
- * functions for multiplication with appropriate vectors.
- *
- * We split this module into several parts. Basic matrices are all the matrix
- * classes actually storing their entries. Derived matrices use basic
- * matrices, but change the meaning of the matrix-vector multiplication.
- *
- * Preconditioners are matrix classes as well, since they perform linear
- * operations on vectors.
- *
- * @author Guido Kanschat, 2003
- *
- * @ingroup LAC
- */
-
-/**
- * @defgroup Matrix1 Basic matrices
- *
- * These are the actual matrix classes provided by deal.II. It is possible to
- * store values in them and retrieve them. Furthermore, they provide the full
- * interface required by linear solvers (see Solver).
- *
- * @author Guido Kanschat, 2003
- *
- * @ingroup LAC
- */
-
-
-/**
- * @defgroup Matrix2 Derived matrices
- *
- * These matrices are built on top of the basic matrices. They perform special
- * operations using the interface defined in Solver.
- *
- * @author Guido Kanschat, 2003
- *
- * @ingroup LAC
- */
-
-/**
- * @defgroup Preconditioners Preconditioners
- * In principle, preconditioners are matrices themselves. But, since they are
- * only used in a special context, we put them in a separate group.
- *
- * @author Guido Kanschat, 2003
- *
- * @ingroup LAC
- */
-
- /*@}*/
-
-/**
- * @defgroup Solvers Linear solver classes
- *
- * Here we collect iterative solvers and some control classes. All
- * solvers inherit from the class template Solver, which provides some
- * basic maintenance methods.
- *
- * The number of iteration steps of all solvers is controlled by
- * objects of class SolverControl or its derived class
- * ReductionControl.
- *
- * All solvers receive the matrix and vector classes as template
- * arguments. Therefore, any objects defining the interface described in the
- * documentation of Solver are admissible.
- *
- * @author Guido Kanschat, 2003
- *
- * @ingroup LAC
- */
-
-/**
- * @defgroup VMemory Vector memory management
- *
- * A few classes that are used to avoid allocating and deallocating vectors in
- * iterative procedures. These methods all use an object of the base class
- * VectorMemory to get their auxiliary vectors. Unfortunately, the
- * intelligence put into both implementations provided right now is not
- * overwhelming.
- *
- * @author Guido Kanschat, 2003
- *
- * @ingroup LAC
- */
-
-/**
- * @defgroup PETScWrappers PETScWrappers
- * 
- * The classes in this module are
- * wrappers around functionality provided by the PETSc library. They provide a
- * modern object-oriented interface that is compatible with the interfaces of
- * the other linear algebra classes in deal.II. All classes and functions in
- * this group reside in a namespace @p PETScWrappers.
- *
- * These classes are only available if a PETSc installation was detected
- * during configuration of deal.II. Refer to the README file for more details
- * about this.
- *
- * @author Wolfgang Bangerth, 2004
- *
- * @ingroup LAC
- */
diff --git a/deal.II/doc/doxygen/headers/matrices.h b/deal.II/doc/doxygen/headers/matrices.h
new file mode 100644 (file)
index 0000000..2e0f6e4
--- /dev/null
@@ -0,0 +1,56 @@
+//-------------------------------------------------------------------------
+//    $Id$
+//    Version: $Name$
+//
+//    Copyright (C) 2003, 2004, 2006 by the deal.II authors
+//
+//    This file is subject to QPL and may not be  distributed
+//    without copyright and license information. Please refer
+//    to the file deal.II/doc/license.html for the  text  and
+//    further information on this license.
+//
+//-------------------------------------------------------------------------
+
+
+/**
+ * @defgroup Matrices Matrix classes
+ *
+ * All matrices in this library have a common minimal interface, defined
+ * through MATRIX (see Solver documentation). This interface consists of
+ * functions for multiplication with appropriate vectors.
+ *
+ * We split this module into several parts. Basic matrices are all the matrix
+ * classes actually storing their entries. Derived matrices use basic
+ * matrices, but change the meaning of the matrix-vector multiplication.
+ *
+ * Preconditioners are matrix classes as well, since they perform linear
+ * operations on vectors.
+ *
+ * @author Guido Kanschat, 2003
+ *
+ * @ingroup LAC
+ */
+
+/**
+ * @defgroup Matrix1 Basic matrices
+ *
+ * These are the actual matrix classes provided by deal.II. It is possible to
+ * store values in them and retrieve them. Furthermore, they provide the full
+ * interface required by linear solvers (see Solver).
+ *
+ * @author Guido Kanschat, 2003
+ *
+ * @ingroup LAC Matrices
+ */
+
+
+/**
+ * @defgroup Matrix2 Derived matrices
+ *
+ * These matrices are built on top of the basic matrices. They perform special
+ * operations using the interface defined in Solver.
+ *
+ * @author Guido Kanschat, 2003
+ *
+ * @ingroup LAC Matrices
+ */
diff --git a/deal.II/doc/doxygen/headers/mg.h b/deal.II/doc/doxygen/headers/mg.h
new file mode 100644 (file)
index 0000000..9b04fad
--- /dev/null
@@ -0,0 +1,21 @@
+//-------------------------------------------------------------------------
+//    $Id$
+//    Version: $Name$
+//
+//    Copyright (C) 2003, 2005, 2006 by the deal.II authors
+//
+//    This file is subject to QPL and may not be  distributed
+//    without copyright and license information. Please refer
+//    to the file deal.II/doc/license.html for the  text  and
+//    further information on this license.
+//
+//-------------------------------------------------------------------------
+
+/**
+ * @defgroup mg Multilevel support
+ *
+ * Classes that have to do with multigrid algorithms.
+ * 
+ * See the step-16 example program on how to use this functionality.
+ */
+
diff --git a/deal.II/doc/doxygen/headers/petsc.h b/deal.II/doc/doxygen/headers/petsc.h
new file mode 100644 (file)
index 0000000..014f305
--- /dev/null
@@ -0,0 +1,31 @@
+//-------------------------------------------------------------------------
+//    $Id$
+//    Version: $Name$
+//
+//    Copyright (C) 2003, 2004, 2006 by the deal.II authors
+//
+//    This file is subject to QPL and may not be  distributed
+//    without copyright and license information. Please refer
+//    to the file deal.II/doc/license.html for the  text  and
+//    further information on this license.
+//
+//-------------------------------------------------------------------------
+
+
+/**
+ * @defgroup PETScWrappers PETScWrappers
+ * 
+ * The classes in this module are
+ * wrappers around functionality provided by the PETSc library. They provide a
+ * modern object-oriented interface that is compatible with the interfaces of
+ * the other linear algebra classes in deal.II. All classes and functions in
+ * this group reside in a namespace @p PETScWrappers.
+ *
+ * These classes are only available if a PETSc installation was detected
+ * during configuration of deal.II. Refer to the README file for more details
+ * about this.
+ *
+ * @author Wolfgang Bangerth, 2004
+ *
+ * @ingroup LAC
+ */
diff --git a/deal.II/doc/doxygen/headers/polynomials.h b/deal.II/doc/doxygen/headers/polynomials.h
new file mode 100644 (file)
index 0000000..e56bf7a
--- /dev/null
@@ -0,0 +1,22 @@
+//-------------------------------------------------------------------------
+//    $Id$
+//    Version: $Name$
+//
+//    Copyright (C) 2005, 2006 by the deal.II authors
+//
+//    This file is subject to QPL and may not be  distributed
+//    without copyright and license information. Please refer
+//    to the file deal.II/doc/license.html for the  text  and
+//    further information on this license.
+//
+//-------------------------------------------------------------------------
+
+/**
+ * @defgroup Polynomials Polynomials and polynomial spaces
+ *
+ * This module groups classes that define certain families of polynomial
+ * functions. In particular, this includes Lagrangian interpolation
+ * polynomials for equidistant support points and their tensor products in
+ * higher dimensions, but also more exotic ones like Brezzi-Douglas-Marini or
+ * Raviart-Thomas spaces.
+ */
diff --git a/deal.II/doc/doxygen/headers/preconditioners.h b/deal.II/doc/doxygen/headers/preconditioners.h
new file mode 100644 (file)
index 0000000..9baa0d8
--- /dev/null
@@ -0,0 +1,33 @@
+//-------------------------------------------------------------------------
+//    $Id$
+//    Version: $Name$
+//
+//    Copyright (C) 2003, 2004, 2006 by the deal.II authors
+//
+//    This file is subject to QPL and may not be  distributed
+//    without copyright and license information. Please refer
+//    to the file deal.II/doc/license.html for the  text  and
+//    further information on this license.
+//
+//-------------------------------------------------------------------------
+
+
+/**
+ * @defgroup Preconditioners Preconditioners
+ *
+ * Preconditioners are used to accelerate the iterative solution of linear
+ * systems. Typical preconditioners are Jacobi, Gauss-Seidel, or SSOR, but the
+ * library also supports more complex ones such as Vanka or incomplete LU
+ * decompositions (ILU). In addition, sparse direct solvers can be used as
+ * preconditioners when available.
+ * 
+ * In principle, and in the mathematical literature, preconditioners are
+ * treated as matrices in the sense that one can do a matrix-vector
+ * multiplication with them. On the other hand, one doesn't usually have an
+ * element-by-element representation of these matrices, only their action on a
+ * vector. The preconditioner classes therefore often have a <tt>vmult()</tt>
+ * function that symbolizes the ability to perform matrix-vector
+ * multiplications, just like the real matrix classes.
+ *
+ * @ingroup LAC
+ */
similarity index 86%
rename from deal.II/doc/doxygen/headers/base/dox.h
rename to deal.II/doc/doxygen/headers/quadrature.h
index 7cdffdd9416c1716e21173e58eb09a023d98342d..6750e13ef0bea8fab5af68a9c63e2b9980b73a64 100644 (file)
  * All other classes in this module actually implement quadrature
  * rules of different order and other characteristics.
  */
-
-/**
- * @defgroup IO Input/Output
- *
- * This module collects the classes used for reading and writing
- * meshes and data.
- *
- * The list of supported formats can be found in the
- * description of the classes
- * <ul>
- * <li> GridIn for reading meshes,
- * <li> GridOut for writing meshes,
- * <li> DataOutBase for writing simulation results.
- * </ul>
- *
- * For writing data, you would normally use objects of the class
- * DataOut (DataOutBase only provides the low level output
- * functions). Still, there are some other options for more
- * specialized needs, like DataOutFaces, DataOutRotation and
- * DataOutStack.
- */
-
-/**
- * @defgroup Polynomials Polynomials and polynomial spaces
- */
similarity index 60%
rename from deal.II/doc/doxygen/headers/base/software.h
rename to deal.II/doc/doxygen/headers/software.h
index 7fa2271a978d994b879f6bbc76af087f9a0b0dc2..dfae8699b75c951d3c6004128d3f55e0a2cc0409 100644 (file)
@@ -1,41 +1,59 @@
 /**
- * @page DEALSoftware Third party software deal.II collaborates with
+ * @page DEALSoftware Third party software deal.II interfaces with
  *
  * @note Names of software products are trademarks of their respective owners.
  *
+ * 
  * @section SoftwareVis Visualization tools
  *
+ * This is a list of visualization formats and software that deal.II
+ * supports. Data in these formats is written by the DataOutBase and in parts
+ * by the GridOut classes (see @ref output).
+ * 
+ *
  * @subsection SoftwareAVS AVS Express
  *
  * deal.II reads and writes the UCD format specified in the AVS
- * Express user manual. See http://www.avs.com for more details on
+ * Express user manual. See http://www.avs.com/ for more details on
  * this software.
  *
+ * 
  * @subsection SoftwareGnuplot gnuplot
  *
  * Two-dimensional data can be written in a format suitable for
  * gnuplot, even on locally refined and unstructured meshes, See
  * http://www.gnuplot.info/
  *
+ * 
  * @subsection SoftwareOpenDX OpenDX
  *
  * The former IBM Visual Data Explorer, now an OpenSource project at
- * http://www.opendx.org.
+ * http://www.opendx.org/.
  *
+ * 
  * @subsection SoftwarePovray Povray
  *
  * While it is not actually taylored to scientific visualization, you
  * may be able to produce impressive pictures of three-dimensional
- * deformed bodies with http://www.povray.org
+ * deformed bodies with http://www.povray.org/
  *
+ * 
  * @subsection SoftwareTecplot Tecplot
  *
- * deal.II writes textual and binary files for Tecplot. @see
+ * deal.II writes textual and binary files for Tecplot. See
  * http://www.tecplot.com for more details on this software.
  *
+ * 
  * @subsection SoftwareXFig XFig
  *
  * Though not a visualization tool at all, you can nevertheless write grids in
  * XFig format 3.2. Those can be postprocessed manually within XFig and
- * written in many different graphics formats. See http://www.xfig.org
+ * written in many different graphics formats. See http://www.xfig.org/
+ *
+ *
+ * @subsection SoftwareVTK Visualization Toolkit (VTK)
+ *
+ * VTK is an increasingly popular open format supported by a number of newer
+ * visualization projects such as ParaView, VisIt, or MayaVi. See
+ * http://www.kitware.com/vtk.html
  */
diff --git a/deal.II/doc/doxygen/headers/solvers.h b/deal.II/doc/doxygen/headers/solvers.h
new file mode 100644 (file)
index 0000000..af775e7
--- /dev/null
@@ -0,0 +1,33 @@
+//-------------------------------------------------------------------------
+//    $Id$
+//    Version: $Name$
+//
+//    Copyright (C) 2003, 2004, 2006 by the deal.II authors
+//
+//    This file is subject to QPL and may not be  distributed
+//    without copyright and license information. Please refer
+//    to the file deal.II/doc/license.html for the  text  and
+//    further information on this license.
+//
+//-------------------------------------------------------------------------
+/**
+ * @defgroup Solvers Linear solver classes
+ *
+ * This module groups iterative and direct solvers, eigenvalue solvers, and
+ * some control classes. All iterative solvers inherit from the class template
+ * Solver, which provides some basic maintenance methods.
+ *
+ * The number of iteration steps of iterative solvers is controlled by
+ * objects of class SolverControl or its derived class
+ * ReductionControl.
+ *
+ * All solvers receive the matrix and vector classes as template
+ * arguments. Therefore, any objects defining the interface described in the
+ * documentation of Solver are admissible. These requirements are listed in
+ * the documentation page of the Solver class.
+ *
+ * If detected during configuration (see the ReadMe file), some sparse direct
+ * solvers are also supported.
+ *
+ * @ingroup LAC
+ */
diff --git a/deal.II/doc/doxygen/headers/vector_memory.h b/deal.II/doc/doxygen/headers/vector_memory.h
new file mode 100644 (file)
index 0000000..5aee115
--- /dev/null
@@ -0,0 +1,26 @@
+//-------------------------------------------------------------------------
+//    $Id$
+//    Version: $Name$
+//
+//    Copyright (C) 2003, 2004, 2006 by the deal.II authors
+//
+//    This file is subject to QPL and may not be  distributed
+//    without copyright and license information. Please refer
+//    to the file deal.II/doc/license.html for the  text  and
+//    further information on this license.
+//
+//-------------------------------------------------------------------------
+
+
+/**
+ * @defgroup VMemory Vector memory management
+ *
+ * This module groups a few classes that are used to avoid allocating and
+ * deallocating vectors over and over in iterative procedures. These methods
+ * all use an object of the base class VectorMemory to get their auxiliary
+ * vectors.
+ *
+ * Presently, only step-20 illustrates the use of these classes.
+ *
+ * @ingroup LAC
+ */
diff --git a/deal.II/doc/doxygen/headers/vectors.h b/deal.II/doc/doxygen/headers/vectors.h
new file mode 100644 (file)
index 0000000..24ed560
--- /dev/null
@@ -0,0 +1,21 @@
+//-------------------------------------------------------------------------
+//    $Id$
+//    Version: $Name$
+//
+//    Copyright (C) 2003, 2004, 2006 by the deal.II authors
+//
+//    This file is subject to QPL and may not be  distributed
+//    without copyright and license information. Please refer
+//    to the file deal.II/doc/license.html for the  text  and
+//    further information on this license.
+//
+//-------------------------------------------------------------------------
+
+/**
+ * @defgroup Vectors Vector classes
+ *
+ * Here, we list all the classes that can be used as VECTOR in linear solvers
+ * (see @ref Solvers) and for matrix-vector operations.
+ *
+ * @ingroup LAC
+ */

In the beginning the Universe was created. This has made a lot of people very angry and has been widely regarded as a bad move.

Douglas Adams


Typeset in Trocchi and Trocchi Bold Sans Serif.