From: Wolfgang Bangerth Date: Fri, 8 May 1998 12:21:42 +0000 (+0000) Subject: Update doc text markup. X-Git-Tag: v8.0.0~22985 X-Git-Url: https://gitweb.dealii.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=719ae9793d0a6ba57ea708a65ab485e1c892b6da;p=dealii.git Update doc text markup. git-svn-id: https://svn.dealii.org/trunk@269 0785d39b-7218-0410-832d-ea1e28bc413d --- diff --git a/deal.II/base/include/base/parameter_handler.h b/deal.II/base/include/base/parameter_handler.h index 20ff371172..c290fae041 100644 --- a/deal.II/base/include/base/parameter_handler.h +++ b/deal.II/base/include/base/parameter_handler.h @@ -54,7 +54,7 @@ enum OutputStyle { structure. - {\bf Declaration of entries} + \subsection{Declaration of entries} In order to use the facilities of a #ParameterHandler# object, one first has to make known the different entries the input file may or may not contain. This @@ -135,7 +135,7 @@ enum OutputStyle { \end{verbatim} - {\bf Input files and special characters} + \subsection{Input files and special characters} For the first example above the input file would look like the following: \begin{verbatim} @@ -165,7 +165,7 @@ enum OutputStyle { #=# sign. - {\bf Reading data from input sources} + \subsection{Reading data from input sources} In order to read input you can use three possibilities: reading from an #istream# object, reading from a file of which the name is given and reading from a string in memory in @@ -194,7 +194,7 @@ enum OutputStyle { If an error occurs upon reading the input, error messages are written to #cerr#. - {\bf Getting entry values out of a #ParameterHandler# object} + \subsection{Getting entry values out of a #ParameterHandler# object} Each class gets its data out of a #ParameterHandler# object by calling the #get (...)# member functions like this: @@ -232,14 +232,14 @@ enum OutputStyle { input file. - {\bf Style guide for data retrieval} + \subsection{Style guide for data retrieval} We propose that every class which gets data out of a #ParameterHandler# object provides a function named #get_parameters#. This should be declared #virtual#. #get_parameters# functions in derived classes should call the #BaseClass::get_parameters# function. - {\bf Possible future extensions} + \subsection{Possible future extensions} \begin{itemize} \item Allow long input lines to be broken by appending a backslash character @@ -250,7 +250,7 @@ enum OutputStyle { - {\bf Worked Example} + \subsection{Worked Example} This is the code: \begin{verbatim} @@ -448,7 +448,7 @@ enum OutputStyle { \end{verbatim} - {\bf References} + \subsection{References} This class is inspired by the #MenuSystem# class of #DiffPack#. @@ -782,7 +782,7 @@ class ParameterHandler { program. - {\bf Usage} + \subsection{Usage} The usage of this class is similar to the #ParameterHandler# class. First the entries and subsections have to be declared, then a loop is performed in which @@ -872,7 +872,7 @@ class ParameterHandler { run. - {\bf Syntax for variant and array entry values} + \subsection{Syntax for variant and array entry values} Variant values are specified like #prefix{ v1 | v2 | v3 | ... }postfix#. Whitespace to the right of the opening brace #{# is ignored as well as to the left of the @@ -885,7 +885,7 @@ class ParameterHandler { #prefix{{ v1 | v2 | v3 }}postfix#. - {\bf Worked example} + \subsection{Worked example} Given the above extensions to the example program for the #ParameterHandler# and the following input file @@ -947,7 +947,7 @@ class ParameterHandler { the number of the run. - {\bf References} + \subsection{References} This class is inspired by the #Multipleloop# class of #DiffPack#. @memo This class provides an interface to an input file which provides at diff --git a/deal.II/deal.II/include/dofs/dof_accessor.h b/deal.II/deal.II/include/dofs/dof_accessor.h index ab626c4301..585bcb1b8b 100644 --- a/deal.II/deal.II/include/dofs/dof_accessor.h +++ b/deal.II/deal.II/include/dofs/dof_accessor.h @@ -111,7 +111,7 @@ class DoFAccessor { lines in 1D-, 2D-, etc dimensions). - {\bf Usage} + \subsection{Usage} The \Ref{DoFDimensionInfo} classes inherited by the \Ref{DoFHandler} classes declare typedefs to iterators using the accessors declared in this class @@ -120,7 +120,7 @@ class DoFAccessor { as they provide easier typing (much less complicated names!). - {\bf Notes about the class hierarchy structure} + \subsection{Notes about the class hierarchy structure} The class hierarchy seems to be a bit confused here. The reason for this is that we would really like to derive a #DoFLineAccessor# from a #LineAccessor#. @@ -355,7 +355,7 @@ class DoFSubstructAccessor : public DoFAccessor, /** Intermediate, "typedef"-class, not for public use. - {\bf Rationale} + \subsection{Rationale} This class is only a wrapper class used to do kind of a typedef with template parameters. This class and #DoFSubstructAccessor<2># diff --git a/deal.II/deal.II/include/dofs/dof_handler.h b/deal.II/deal.II/include/dofs/dof_handler.h index 13e924d8b0..4e3793c943 100644 --- a/deal.II/deal.II/include/dofs/dof_handler.h +++ b/deal.II/deal.II/include/dofs/dof_handler.h @@ -51,7 +51,7 @@ class DoFLevel; /** Store the indices of the degrees of freedom which are located on the lines. - {\bf Information for all #DoFLevel# classes} + \subsection{Information for all #DoFLevel# classes} The #DoFLevel# classes store the global indices of the degrees of freedom for each cell on a @@ -244,7 +244,7 @@ enum RenumberingMethod { is the same as that for the alike triangulation iterators. - {\bf Distribution of degrees of freedom} + \subsection{Distribution of degrees of freedom} The degrees of freedom (`dofs') are distributed on the given triangulation by the function #distribute_dofs()#. It gets passed a finite element object @@ -299,7 +299,7 @@ enum RenumberingMethod { not that important any more. - {\bf Implementation of renumbering schemes} + \subsection{Implementation of renumbering schemes} The renumbering algorithms need quite a lot of memory, since they have to store for each dof with which other dofs it couples. This is done @@ -333,7 +333,7 @@ enum RenumberingMethod { will search for its own starting point. - {\bf Results of renumbering} + \subsection{Results of renumbering} The renumbering schemes mentioned above do not lead to optimal results. However, after all there is no algorithm that accomplishes this within @@ -366,7 +366,7 @@ enum RenumberingMethod { (e.g. when using adaptive algorithms), searching a best starting point may be difficult, however, and in many cases will not justify the effort. - {\bf Data transfer between grids} + \subsection{Data transfer between grids} The #DoFHandler# class offers two functions #make_transfer_matrix# which create a matrix to transform the data of one grid to another. The functions assumes the diff --git a/deal.II/deal.II/include/fe/fe.h b/deal.II/deal.II/include/fe/fe.h index 09a9dba0f2..0e9f5bf18d 100644 --- a/deal.II/deal.II/include/fe/fe.h +++ b/deal.II/deal.II/include/fe/fe.h @@ -340,7 +340,7 @@ struct FiniteElementBase : public FiniteElementData { implementation. - {\bf Finite Elements in one dimension} + \subsection{Finite Elements in one dimension} Finite elements in one dimension need only set the #restriction# and #prolongation# matrices in #FiniteElementBase<1>#. The constructor of @@ -350,7 +350,7 @@ struct FiniteElementBase : public FiniteElementData { in terrible trouble. - {\bf Finite elements in two dimensions} + \subsection{Finite elements in two dimensions} In addition to the fields already present in 1D, a constraint matrix is needed in case two quads meet at a common line of which one is refined diff --git a/deal.II/deal.II/include/fe/fe_values.h b/deal.II/deal.II/include/fe/fe_values.h index b69eb9ba88..ba7364ccf4 100644 --- a/deal.II/deal.II/include/fe/fe_values.h +++ b/deal.II/deal.II/include/fe/fe_values.h @@ -58,7 +58,7 @@ template class Quadrature; this variable. - {\bf Definitions} + \subsection{Definitions} The Jacobian matrix is defined to be $$ J_{ij} = {d\xi_i \over dx_j} $$ @@ -80,7 +80,7 @@ template class Quadrature; Jacobi matrix to get the scaling of the surface element $do$. - {\bf Member functions} + \subsection{Member functions} The functions of this class fall into different cathegories: \begin{itemize} @@ -124,7 +124,7 @@ template class Quadrature; \end{itemize} - {\bf Implementational issues} + \subsection{Implementational issues} The #FEValues# object keeps track of those fields which really need to be computed, since the computation of the gradients of the ansatz functions @@ -589,7 +589,7 @@ class FEValues : public FEValuesBase { those common concepts here, rather than in the derived classes. - {\bf Technical issues} + \subsection{Technical issues} The unit face is defined to be the tensor product of the interval $[0,1]$ in the present number of dimensions minus one. In part of the literature, @@ -881,7 +881,7 @@ class FEFaceValues : public FEFaceValuesBase { function's gradient across cell boundaries is computed. - {\bf Other implementational subjects} + \subsection{Other implementational subjects} It does not seem useful to ask for the off-points of the ansatz functions (name #ansatz_points# in the #FEValuesBase# class) for subfaces. These are diff --git a/deal.II/deal.II/include/grid/tria.h b/deal.II/deal.II/include/grid/tria.h index 0498f6fc4d..baf094f207 100644 --- a/deal.II/deal.II/include/grid/tria.h +++ b/deal.II/deal.II/include/grid/tria.h @@ -547,7 +547,7 @@ class TriaDimensionInfo<2> { specialized versions for distinct dimensions. - {\bf Structure and iterators} + \subsection{Structure and iterators} The actual data structure of a #Triangulation# object is rather complex and quite inconvenient if one attempted to operate on it directly, since @@ -660,7 +660,7 @@ class TriaDimensionInfo<2> { \end{itemize} - {\bf Usage} + \subsection{Usage} Usage of a #Triangulation# is mainly done through the use of iterators. An example probably shows best how to use it: @@ -704,7 +704,7 @@ class TriaDimensionInfo<2> { \end{verbatim} - {\bf Creating a triangulation} + \subsection{Creating a triangulation} There are several possibilities to create a triangulation: \begin{itemize} @@ -812,7 +812,7 @@ class TriaDimensionInfo<2> { interface between regions of different materials. - {\bf Refinement of a triangulation} + \subsection{Refinement of a triangulation} Refinement of a triangulation may be done through several ways. The most low-level way is directly through iterators: let #i# be an iterator to @@ -926,7 +926,7 @@ class TriaDimensionInfo<2> { squares of the criteria on the cells. - {\bf Material and boundary information} + \subsection{Material and boundary information} Each line, quad, etc stores one byte of information denoting the material a cell is made of (used in the computation of stiffness matrices) and to @@ -965,7 +965,7 @@ class TriaDimensionInfo<2> { the different handling of vertices from lines and quads. - {\bf History of a triangulation} + \subsection{History of a triangulation} It is possible to reconstruct a grid from its refinement history, which can be stored and loaded through the #save_refine_flags# and @@ -999,7 +999,7 @@ class TriaDimensionInfo<2> { grid. - {\bf User flags} + \subsection{User flags} A triangulation offers one bit per line, quad, etc for user data. This field can be @@ -1031,7 +1031,7 @@ class TriaDimensionInfo<2> { documentation. - {\bf Boundary approximation} + \subsection{Boundary approximation} You can specify a boundary function: if a new vertex is created on a side or face at the boundary, this function is used to compute where @@ -1075,7 +1075,7 @@ class TriaDimensionInfo<2> { of such situations when defining the coarse grid. - {\bf Implementational conventions for two spatial dimensions} + \subsection{Implementational conventions for two spatial dimensions} There is a convention about the direction of the bounding lines of quads in 2D. The direction of a line is the direction of point 0 towards point 1. We @@ -1102,7 +1102,7 @@ class TriaDimensionInfo<2> { vertex with the same number of the old quad. - {\bf Warning} + \subsection{Warning} It seems impossible to preserve #const#ness of a triangulation through iterator usage. Thus, if you declare pointers to a #const# triangulation diff --git a/deal.II/deal.II/include/grid/tria_accessor.h b/deal.II/deal.II/include/grid/tria_accessor.h index 16e94db21a..b8be69f2f5 100644 --- a/deal.II/deal.II/include/grid/tria_accessor.h +++ b/deal.II/deal.II/include/grid/tria_accessor.h @@ -732,7 +732,7 @@ class TriaSubstructAccessor; /** Intermediate, "typedef"-class, not for public use. - {\bf Rationale} + \subsection{Rationale} This class is only a wrapper class used to do kind of a typedef with template parameters. This class and #TriaSubstructAccessor<2># diff --git a/deal.II/deal.II/include/grid/tria_iterator.h b/deal.II/deal.II/include/grid/tria_iterator.h index 4658a20095..56b2e80105 100644 --- a/deal.II/deal.II/include/grid/tria_iterator.h +++ b/deal.II/deal.II/include/grid/tria_iterator.h @@ -37,7 +37,7 @@ template class Triangulation; {\bf Note:} Please read the documentation about the prefix and the postfix #++# operators in this and the derived classes! - {\bf Purpose} + \subsection{Purpose} #iterators# are used whenever a loop over all lines, quads, cells etc. is to be performed. These loops can then be coded like this: @@ -104,7 +104,7 @@ template class Triangulation; g++2.7 has some problems and we will have to wait for g++2.8. - {\bf Differences between the classes in this inheritance tree} + \subsection{Differences between the classes in this inheritance tree} #TriaRawIterator# objects point to lines, cells, etc in the lists whether they are used or not (in the vectors, also {\it dead} @@ -118,7 +118,7 @@ template class Triangulation; which only loop over active cells (not refined). - {\bf Implementation} + \subsection{Implementation} In principle, the Iterator class does not have much functionality. It only becomes useful when assigned an #Accessor# (the second template @@ -183,14 +183,14 @@ template class Triangulation; line. - {\bf Warning} + \subsection{Warning} It seems impossible to preserve #const#ness of a triangulation through iterator usage. Thus, if you declare pointers to a #const# triangulation object, you should be well aware that you might involuntarily alter the data stored in the triangulation. - {\bf Internals} + \subsection{Internals} There is a representation of past-the-end-pointers, denoted by special values of the member variables #present_level# and #present_index#: diff --git a/deal.II/deal.II/include/numerics/base.h b/deal.II/deal.II/include/numerics/base.h index ab68ddf70d..4c56a3bd57 100644 --- a/deal.II/deal.II/include/numerics/base.h +++ b/deal.II/deal.II/include/numerics/base.h @@ -60,7 +60,7 @@ enum NormType { a display of concept haw to work with deal.II. - {\bf Assemblage} + \subsection{Assemblage} The #assemble# member function does the assemblage of the system matrix and the given number of right hand sides. It does the following steps: @@ -85,7 +85,7 @@ enum NormType { the exact boundary of the domain. - {\bf Solving} + \subsection{Solving} Calling the #solve# function with a solver object, the system of equations which results after having called the #assemble# function is solved. After @@ -93,7 +93,7 @@ enum NormType { are given their correct values. - {\bf Boundary conditions} + \subsection{Boundary conditions} During assemblage of matrices and right hand side, use is made of dirichlet boundary conditions (in short: bc) specified to the #assemble# function. You @@ -173,7 +173,7 @@ enum NormType { sure that the returned values are reasonable in some sense anyway. - {\bf Computing errors} + \subsection{Computing errors} The function #integrate_difference# performs the calculation of the error between the finite element solution and a given (continuous) reference diff --git a/deal.II/deal.II/include/numerics/data_io.h b/deal.II/deal.II/include/numerics/data_io.h index 4cb4f8ed84..d5628946dc 100644 --- a/deal.II/deal.II/include/numerics/data_io.h +++ b/deal.II/deal.II/include/numerics/data_io.h @@ -116,7 +116,7 @@ struct SubCellData { further details. - {\bf Structure of input grid data} + \subsection{Structure of input grid data} It is your duty to use a correct numbering of vertices in the cell list, i.e. for lines, you have to first give the vertex with the lower coordinate @@ -260,7 +260,7 @@ class DataIn { are to be written. - {\bf Limitations} + \subsection{Limitations} At present, no grouping of components to vectors is implemented, i.e. you can only write each component independent of the others. Also, it @@ -268,7 +268,7 @@ class DataIn { with more or less than one degree of freedom per vertex. - {\bf UCD format} + \subsection{UCD format} The UCD format is described in the AVS developer's guide. Due to limitations in the present format, only node based data can be output, @@ -286,7 +286,7 @@ class DataIn { much easier. - {\bg GNUPLOT format} + \subsection{GNUPLOT format} The GNUPLOT format is not able to handle data on unstructured grids directly. Directly would mean that you only give the vertices and diff --git a/deal.II/deal.II/include/numerics/error_estimator.h b/deal.II/deal.II/include/numerics/error_estimator.h index 83dc2d8ec6..e3abc10889 100644 --- a/deal.II/deal.II/include/numerics/error_estimator.h +++ b/deal.II/deal.II/include/numerics/error_estimator.h @@ -39,7 +39,7 @@ class dVector; can be used to feed the #Triangulation::refine_*# functions. - {\bf Implementation} + \subsection{Implementation} In principle, the implementation of the error estimation is simple: let $$ \eta_K^2 = @@ -76,7 +76,7 @@ class dVector; the diameter of the cell. - {\bf Boundary values} + \subsection{Boundary values} If the face is at the boundary, i.e. there is no neighboring cell to which the jump in the gradiend could be computed, there are two possibilities: @@ -110,7 +110,7 @@ class dVector; conditions. - {\bf Handling of hanging nodes} + \subsection{Handling of hanging nodes} The integration along faces with hanging nodes is quite tricky, since one of the elements has to be shifted one level up or down. See the