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
\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}
#=# 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
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:
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
- {\bf Worked Example}
+ \subsection{Worked Example}
This is the code:
\begin{verbatim}
\end{verbatim}
- {\bf References}
+ \subsection{References}
This class is inspired by the #MenuSystem# class of #DiffPack#.
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
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
#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
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
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
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#.
/**
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>#
/**
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<N># classes
store the global indices of the degrees of freedom for each cell on a
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
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
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
(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
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
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
this variable.
- {\bf Definitions}
+ \subsection{Definitions}
The Jacobian matrix is defined to be
$$ J_{ij} = {d\xi_i \over dx_j} $$
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}
\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
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,
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
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
\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:
\end{verbatim}
- {\bf Creating a triangulation}
+ \subsection{Creating a triangulation}
There are several possibilities to create a triangulation:
\begin{itemize}
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
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
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
grid.
- {\bf User flags}
+ \subsection{User flags}
A triangulation offers one bit per line, quad, etc for user data.
This field can be
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
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
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
/**
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>#
{\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:
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}
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
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#:
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:
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
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
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
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
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
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,
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
can be used to feed the #Triangulation<dim>::refine_*# functions.
- {\bf Implementation}
+ \subsection{Implementation}
In principle, the implementation of the error estimation is simple: let
$$ \eta_K^2 =
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:
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