Error Estimate and Adaptivity

- -

- - diff --git a/deal.II/doc/tutorial/chapter-1.elements/boundary.html b/deal.II/doc/tutorial/chapter-1.elements/boundary.html deleted file mode 100644 index 4a79f21d45..0000000000 --- a/deal.II/doc/tutorial/chapter-1.elements/boundary.html +++ /dev/null @@ -1,121 +0,0 @@ - - - - - -deal.II tutorial: Boundary conditions - - - - - - - - - -

Boundary Conditions

- -

Setting boundary conditions

- -

-There are two deal.II functions relevant for us at the moment: -

-
-void VectorTools::interpolate_boundary_values(...)
-
-

-which does exactly what it says. This function accepts a number -describing which part of the boundary we want to consider -and the according function which shall be interpolated on that portion -of the boundary. It returns a list of -pairs of degrees of freedom numbers and values denoting the respective -Dirichlet boundary values. -

-This output is used by -

-
-void MatrixTools::apply_boundary_values(...)
-
-

-that inserts the proper boundary conditions into the system of equations. -

- -

-Example: We insert Dirichlet boundary conditions into -a system of equations of the form Au=f. The vectors u and -f and the matrix A have already been initialized, likewise -the handler for the degrees of freedom dof and the corresponding finite -element fe. -


-                      // this will hold the boundary value for
-                      // the degrees of freedom on the boundary
-                      // part with number '0'
-map<int,double> boundary_values;
-                      // and this is some user-defined function
-                      // describing the boundary values
-BoundaryFunction<dim> boundary_function;
-                      // interpolate the DoFs on boundary
-                      // portion '0':
-VectorTools<dim>::interpolate_boundary_values 
-               (dof_handler,
-                0, boundary_function, 
-                boundary_values);
-
-                      // set solution vector to the right size
-u.reinit(dof_handler.n_dofs());
-                      // we assume that the global matrix and
-                      // right hand side have already been
-                      // assembled.
-
-                      // now insert the boundary values into
-                      // the linear system of equations:
-MatrixTools<dim>::apply_boundary_values 
-               (boundary_values,
-                A, u, f);  
-

-You may have several different parts of the boundary which are -identified by different boundary indicators. For example, this is -commonly the case if you have inflow and outflow boundaries, or if -your domain has inner boundaries, such as obstacles inside your -domain. You may then want to associate different boundary functions -with the different parts of the boundary, and you can do so by -multiply calling interpolate_boundary_values with -different boundary indicators (the '0' above) and -respective functions. Since the function does not clear the contents -of the map, you may use it for each of this successive calls and pass -only the final object to apply_boundary_values. - - - -

- - - - - - - -

- -

- - diff --git a/deal.II/doc/tutorial/chapter-1.elements/condense.html b/deal.II/doc/tutorial/chapter-1.elements/condense.html deleted file mode 100644 index ca787aad2d..0000000000 --- a/deal.II/doc/tutorial/chapter-1.elements/condense.html +++ /dev/null @@ -1,166 +0,0 @@ - - - - - -deal.II tutorial: Condensing the Hanging Nodes - - - - - - - - - -

Condensing the Hanging Nodes

- -

-On locally refined grids you get hanging nodes -that need to be integrated into your problem matrix, and before that, into -the matrix structure. Hanging nodes are -constrained degrees of freedom; these constraints need to be taken into -account when dealing with them. -

-The deal.II class -that has the ability to handle constraint matrices is called -ConstraintMatrix. It provides all functions -necessary to condense hanging nodes into a matrix structure. -You will have to: -

Clear the hanging nodes so there is no mess left from previous use. - Clearing them if they are already cleared doesn't hurt. This is - accomplished with the function void ConstraintMatrix::clear(). -
-Create a global sparsity pattern (as described in the chapter on -matrix structure) using -void DoFTools::make_sparsity_pattern(const DoFHandler<dim> &, - SparsityPattern &). -
-Create the constraints on the hanging nodes using -void DoFHandler::make_constraint_matrix(ConstraintMatrix &). -
Close the constraints matrix using void -ConstraintMatrix::close(). Closing the object performs some -sorting and reshuffling of data (but you need not care about what -actually happens). -This method is needed because you might wish to implement additional constraints -(apart from those for the hanging nodes). This would have to be done before -closing the object; therefore you can't have it closed automatically somewhere. -
Finally, condense the hanging nodes into the matrix structure -using ConstraintMatrix::condense(SparsityPattern &). -

- -

-Example: We will create a -constraint matrix for hanging nodes and condense the hanging nodes into our matrix structure. Below we show the includes, -definitions and -function calls needed. Be sure to use them in their appropriate places. -

-
-#include <dofs/dof_handler.h>
-#include <lac/sparse_matrix.h>
-#include <dofs/dof_constraints.h>
-#include <dofs/dof_tools.h>
-
-const unsigned int dim=2; // Work in two dimensions, could also be three
-SparsityPattern sparsity_pattern;
-DoFHandler<dim> dof_handler;
-ConstraintMatrix hanging_nodes; 
-
-hanging_nodes.clear();
-DoFTools::make_sparsity_pattern(dof_handler, sparsity_pattern);
-DoFTools::make_hanging_nodes_constraints(dof_handler, hanging_nodes);
-hanging_nodes.close();
-hanging_nodes.condense(matrix_structure);
-
-

- -You will later need to condense the matrix itself, and the right hand -side vector, which is done by the following calls: -

-
-
-SparseMatrix system_matrix;
-Vector       right_hand_side;
-
-// set up matrix and rhs, possibly apply boundary values, etc
-...
-
-// now condense the hanging nodes into the matrix:
-hanging_nodes.condense (system_matrix);
-hanging_nodes.condense (right_hand_side);
-
-

- - -

Generalizations

- -The ConstraintMatrix is more general than only for use -with hanging nodes. In fact, it is able to represent general -constraints of the form -

-  Cx = 0
-

-where C is a matrix and is represented by an object of -type ConstraintMatrix. Constraints due to hanging nodes -are of this form, since for example using bilinear elements, the -hanging node on the middle of a line equals the mean value of the two -neighboring points, i.e. the entries of the respective row in the -matrix are 1, -0.5, -0.5. Since C can be -scaled arbitrarily, we can chose its diagonal elements to be one, and -then only need to store the nondiagonal elements. The -ConstraintMatrix is specialized in storing these -nondiagonal elements if there are only relatively few such elements -per row (as is commonly the case for hanging nodes) and if the number -of constraints itself is relatively low, i.e. much smaller than the -total size of the matrix. In the latter case, most rows of the matrix -contain only zeroes, and we only store those lines that constitute -constraints, which are exactly the lines corresponding to hanging -nodes. - -

- -Some other constraints can be written in the same form as above, with -a sparse matrix C. In these cases, the -ConstraintMatrix can be used as well. For example, it has -been used to perform computations on two grids at the same time, where -the interpolation between the grids can be represented by some such -matrix. - - - - - -

- - - - - - - -

- -

- - diff --git a/deal.II/doc/tutorial/chapter-1.elements/dofs.html b/deal.II/doc/tutorial/chapter-1.elements/dofs.html deleted file mode 100644 index 1ed47eccb4..0000000000 --- a/deal.II/doc/tutorial/chapter-1.elements/dofs.html +++ /dev/null @@ -1,150 +0,0 @@ - - - - - -deal.II tutorial: Degrees of Freedom - - - - - - - - - -

Degrees of Freedom

- -

-Degrees of freedom - short DoFs - are needed to associate a numering -to the shape functions living on our triangulation. Using this -numbering, we can then interpret the discretized operator as a matrix, -where the matrix row and column numbers are identified with the DoF -numbers, and likewise the index of a vector denotes the number of the -respective degree of freedom. -

-For now we will only discuss how and when to number and renumber the -degrees of freedom. this needs to be done so deal.II -has a consistent numbering. -

- -

When to Distribute and Renumber Degrees of Freedom

-Degrees of freedom must always be renumbered after the triangulation -has changed in any way, i.e. has been created or refined. -In particular the degrees of freedom must be distributed after the -triangulation has been created ! -Degrees of freedom -can but should not be renumbered at any other time. The reason is that -sparse matrix structures and constraint matrices - to name two examples - -rely on the numbering. If you -construct a sparse matrix structure and renumber your degrees of freedom -afterwards the structure will be invalid. -

- - - -

How to Distribute and Renumber Degrees of Freedom

-The degrees of freedom are distributed on a triangulation using the function
-void DoFHandler<dim>::distribute_dofs(const FiniteElement<dim> &)
-The argument to distribute_dofs is a finite element that describes -how many degrees of freedom are located on vertices, lines etc. -(FiniteElement objects have much more functionality than only storing -these numbers. Parts of this functionality are discussed in the chapter on -matrix and vector -generation.) -distribute_dofs works its way through the triangulation cell by -cell, starting at the coarsest level, and numbers every degree of freedom that is not yet numbered. -For non-multigrid algorithms it considers only active cells, i.e. cells -without children. -

-Example: We show the include files, definitions -and function calls needed. Be sure to use them in their appropriate places. -This example creates a hypercube and distributes the degrees of freedom. -The finite elements used are bilinear. -

-
-#include <grid/tria.h>
-#include <dofs/dof_handler.h>
-#include <grid/grid_generator.h>
-#include <fe/fe_lib.lagrange.h>
-
-// first build up the triangulation
-Triangulation<dim> triangulation;
-GridGenerator::hyper_cube (triangulation,-1,1);
-
-// you may want to refine the triangulation a bit here
-...
-
-// then associate a DoFHandler object with this triangulation...
-DoFHandler<dim> dof_handler (tria);
-
-// ...and distribute degrees of freedom for linear elements
-FEQ1<dim> fe;
-dof_handler.distribute_dofs(fe);
-
-

- -

-For a number of solution algorithms this way of numbering is way below -optimal. In particular, as mentioned above, the degrees of freedom are -numbered starting on the active cells of coarser levels and going to -finer levels, but depending on how your triangulation was refined, the -order in which the cells are traversed will have no geometrical -pattern. Likewise, the distribution of DoF numbers will look mostly -random. -

-For some problems, it is better if the numbering of DoFs is roughly -into a certain direction, for example from inflow to outflow in -hyperbolic problems. -To achieve a kind of numbering better suited to your problem the deal.II -offers the class -DoFRenumbering with several functions implementing -different ways of renumbering. -The methods presently available are Cuthill-McKee and reverse -Cuthill-McKee, and some other methods you will only want to ask for in -more advanced applications. The first two algorithms are usually much -better than the one used -by distribute_dofs, but neither is optimal (there is no algorithm -that accomplishes optimal results within a reasonable amount of time). -Both algorithms require a good point to start numbering from (for -example one or more degrees of freedom on the inflow boundary) to -achieve good results. -

-The documentation of the DoFRenumbering gives a good -overview of how the methods mentioned above work, and how the -functions performing the re-enumerations have to be called. - - - -

- - - - - - - -

- -

- - diff --git a/deal.II/doc/tutorial/chapter-1.elements/grid_creation.html b/deal.II/doc/tutorial/chapter-1.elements/grid_creation.html deleted file mode 100644 index 4a7bfa4353..0000000000 --- a/deal.II/doc/tutorial/chapter-1.elements/grid_creation.html +++ /dev/null @@ -1,308 +0,0 @@ - - - -deal.II tutorial: Creation of a Grid - - - - - - - - -

Creation of a Grid

- -

Different kinds of grids

- -

-The numerics for which this library was written is always done on a grid. -Choosing the right kind of grid can be essential for solving your problem. -A grid should be chosen to fit your problem space in the best way possible. -This chapter describes coarse grids for the triangulation of your domain. -

-deal.II offers various ways to produce grids for -standard domains, such as -a hypercube, a hyperball -and a hyper_L. There may be more in the meantime (for -example I can now see a ring domain), and you may want to check out -the documentation of the GridGenerator class for this. -

-Furthermore it is possible to -read a triangulation from a ucd-file or -generate a custom grid from within a program. -

We note before actually going to some code snippets that -a triangulation object must be empty before it is initialized with a -grid. However, you need not fear now, since the library will tell you -if you try to initialize a triangulation which is already initialized; -in general, the library will warn you about almost all errors you do, -since in the debug version there are very many checks. -

- -

Hypercube

- -

-A hypercube can be created using the function
-void GridGenerator::hyper_cube(Triangulation<dim> &tria,const double left=0.,const double right=1.)
-The cube created is the tensor product of the left and right edges which -default to 0 and 1, creating the unit hypercube. The hypercube will consist of -exactly one cell. In two dimensions, this amounts to a unit square, in -three, to a unit cube. In one dimension, you simply get a line. -

- - - - -

Hypercubes in two and three dimensions
- -

- -

-Example - create the square [-1,-1]x[-1,1]: Below we show the includes, -definitions and -function calls needed. Be sure to use them in their appropriate places. -

-
-#include <grid/tria.h>
-#include <grid/grid_generator.h>
-
-const unsigned int dim=2;  // Two dimensions; to create a cube set to dim=3
-Triangulation<dim> triangulation;
-
-GridGenerator::hyper_cube (triangulation, -1, 1);
-
-

- - -

Hyperball

-A hyperball can be created using the function
-void GridGenerator::hyper_ball(Triangulation<dim> &tria,const Point<dim> center=0.,const double radius=1.)
-This will create a hyperball of given centre and radius where the -location of the centre defaults to the origin and the radius to -unity. Note that the left figure is scaled a bit large, since the -corner points of the outer square will later be the points on the -circles surface in diagonal directions. -

- - - - -

Different levels of refinement for a 2D-Hyperball
- -

- -

-Example: Below we show the includes, -definitions and -function calls needed. Be sure to use them in their appropriate places. -This example will create a hyperball with unit radius centred on (1,0). -

-
-#include <grid/tria.h>
-#include <grid/grid_generator.h>
-#include <base/point.h>
-
-const unsigned int dim=2;  // For example
-Triangulation<dim> triangulation;
-Point<dim> centre(1,0); // Taking (1,0) as the centre of the ball
-
-GridGenerator::hyper_ball (triangulation, centre, 1);
-
-
-

- -As can be seen above, the unrefined ball (or circle) does not look -very much like a ball (or circle). After several refinement -steps, it looks much better, though. However, along the rays pointing -outward in the initial grid, the cells ar distorted even in the fine -grid and if you want to do high-accuracy computations on circles, you -may want to use a better coarse grid than the one on the left. - - -

Hyper-L

-A hyper-L can be created using the function
-void GridGenerator::hyper_L(Triangulation<dim> &tria,const double left=-1.,const double right=1.)
-This will create a hyper-L consisting of 2^dimension-1 cells. -The hyper-L is created from the hypercube [left,right]^dimension by taking -away the hypercube [left+right/2,right]^dimension. -

-Use of the hyper-L: -The hyper-L is mainly of use in testing grid refinement, error estimates etc. -Boundary conditions of the form u=g on the faces of the original -hypercube and ∂_nu=0 on the "inner" faces resulting -from the smaller hypercube taken away are chosen, this will usually lead to -a singular solution because of the reentrant corner; these singularities -can be used to test the efficiency of error estimators. -

- - - - -

-Hyper-L in three dimensions (not a good picture, since the proportions -of short and long lines is not exactly one half, but you might get a -clue about it) -
- -

- -

-Example: Below we show the includes, -definitions and -function calls needed. Be sure to use them in their appropriate places. -This example will create the default hyper-L. -

-
-#include <grid/tria.h>
-#include <grid/grid_generator.h>
-
-const unsigned int dim=2;  // For example
-Triangulation<dim> triangulation;
-
-GridGenerator::hyper_L (triangulation, -1, 1);
-
-

- - -

Reading a grid from a file

- -

In many problems taken from real life you will find those grid types -insufficient and you will need to create your own grid. -This is possible: deal.II offers the possibility of -reading a complete triangulation from a file in the ucd-format -used by avs. A ucd-file can be read with the function
-void GridIn::read_ucd(istream&)
-

- -

-Since the creation of input grids is probably not something you need to do on a -daily basis, we will only very briefly describe the format of the -input file. More information can be found in the documentation of the -GridIn class. -

-Vertex numbering in input files: -The vertex numbering must start at the vertex with the lowest number for lines -and be counterclockwise for quads. Also, faces between adjacent cells -must face in the same direction. This must be ensured by you, or by the -grid construction algorithm. Otherwise some of your matrix elements -may have the wrong sign (plus instead of minus or vice versa). -A more detailed description of the problems -encountered in two dimensions can be found in the - GridIn class description. -

- - -

Custom grid creation from within a program

- -

-Another way to build cutom grids is to use deal.II methods -for creating grid cells and their properties. This is done in the order -

vertices
cells
boundaries
create a triangulation from this information

-In fact, this is the way the functions in the -GridGenerator class use to produce the grids we have -shown above. -

-Example: Below we show the includes, -definitions and -function calls needed. Be sure to use them in their appropriate places. -This example will create a triangulation as shown in this figure. It will -work only in two dimensions. It creates three rectangular cells, the leftmost -boundary is a Neumann-boundary. -

-
-// First, create an array holding the (2-dimensional) vertices
-const Point<2> vertices[8] = { Point<2> (0,0),               
-                                 Point<2> (1,0),               
-                                 Point<2> (1,1),
-                                 Point<2> (0,1),            
-                                 Point<2> (2,0),        
-                                 Point<2> (2,1),         
-                                 Point<2> (3,0),      
-                                 Point<2> (3,1)  };
-
-// Next, create a two-dimensional array holding the information
-// on what cell consists of which vertices
-const int cell_vertices[3][4] = {{0, 1, 2, 3},      
-                                 {1, 4, 5, 2},
-                                 {4, 6, 7, 5}};
-
-// Next, create a vector of type CellData<2> that holds the
-// cells
-vector<CellData<2> > cells (3, CellData<2>());             
-
-// The information on the cells is copied into this vector and the 
-// material is set to 0. This index can be used to distinguish cells
-// of different types. 
-for (unsigned int i=0; i<3; ++i)                                        
-  {                                                         
-    for (unsigned int j=0; j<4; ++j)        
-      cells[i].vertices[j] = cell_vertices[i][j];
-    cells[i].material_id = 0;
-  };
-
-// The Neumann boundary is set below:
-// Boundaries are parts of cells, therefore the class is called SubCellData
-// to distinguish them from cell data like vertices and material.
-SubCellData boundary_info;                                       
-
-// We want to describe a line in 2d, which would be a cell in 1d,
-// which is why we can use the object for a 1d cell
-// (CellData<1>) for its description:
-boundary_info.boundary_lines.push_back (CellData<1>());
-
-// The boundary gets a material id of 1. The boundary id of lines in 2d
-// will be interpreted as the boundary id
-boundary_info.boundary_lines[0].material_id = 1;
-
-// The boundary is between vertices number 0 and 3
-boundary_info.boundary_lines[0].vertices[0] = 0; 
-boundary_info.boundary_lines[0].vertices[1] = 3;
-
-// From this information the triangulation is created 
-coarse_grid->create_triangulation (vector<Point<2> >(&vertices[0],
-                                                       &vertices[8]),
-                                      cells, boundary_info);
-
-

- - -

- - - - - - - - -

- -

- - - diff --git a/deal.II/doc/tutorial/chapter-1.elements/hanging_nodes.html b/deal.II/doc/tutorial/chapter-1.elements/hanging_nodes.html deleted file mode 100644 index 74e8173dd6..0000000000 --- a/deal.II/doc/tutorial/chapter-1.elements/hanging_nodes.html +++ /dev/null @@ -1,139 +0,0 @@ - - - - - -deal.II tutorial: Hanging Nodes - - - - - - - - - -

Hanging Nodes

- -This chapter discusses one aspect of locally refined grids. Using the -approach chosen in deal.II, grids are produced with -so-called hanging nodes. -A node is called hanging if its value is subject to a -constraint induced by the requirement of globally continuous -functions. We will make this clearer in the following. - -

When do you get hanging nodes?

- -

-You get hanging nodes after some refinements. Hanging nodes are those that -are situated on the boundary of a larger active cell. The global function -is assumed -to be linear on the boundary of each active cell, therefore the value -of the hanging node must be adjusted accordingly. Newly created nodes that -are not situated on boundaries of larger active cells are not subject to this -constraint because there is no reason to assume that the global function -is linear on the boundary of a parent cell. -Hanging nodes -and the constraints they are subject to need to be -taken into account when generating your matrix structure. -This is further discussed in the chapters on -matrix structure and -condensing the hanging nodes. -

- - - - -

Hanging nodes on a locally refined grid
- -

- -

Constraints on Hanging Nodes

- -

Where do the constraints come from?

-In order to get constraints for your hanging nodes you have to assume -some function on the boundaries of your cells, as mentioned above. -Take a linear function on the cell boundary between vertices 1 and 2 -with function values x1 and x2. If you get -a hanging node on this boundary during refinement it will be situated -in the middle and therefore its value - the value of the function on -the boundary at this point - will be x3 = 1/2 (x1+x2). -The value x3 is therefore not a free degree of freedom, -but it is bound by this constraining equation and we will have to take -this into account. -

- -

Mathematical implications, or
-why is it a constraint matrix ?

- -

-Assume a system Au=f with u being the solution -vector with all the degrees of freedom of the finite elements, in particular -base functions associated with hanging nodes, which are not true degrees of -freedom of the system of equations. -

-The constraint for hanging nodes now is that we must be able to calculate -their value from the values of the surrounding nodes by interpolation. -Let y be a vector with entries corresponding to true degrees of -freedom only. We must be able to write u as
-u=Cy
-where C, the constraint matrix is a square matrix containing the -interpolation. -

-Now we have to solve -

-
-  Au = f
-
-with the constraint, that there is a y satisfying
-
-  u = Cy
-
-From this we get
-
-  C^TACy = C^Tf
-
-or, taking
-
-  ~A := C^TAC, b := C^Tf 
-  ~A y = b.
-
-

- -

-It is not possible to generate ~A directly, but -we can generate A and condense it to ~A -using the constraints, solve the system and obtain u by -u=Cy. -

- -

- - - - - - - -

- -

- - diff --git a/deal.II/doc/tutorial/chapter-1.elements/index.html b/deal.II/doc/tutorial/chapter-1.elements/index.html deleted file mode 100644 index 9cb4311b88..0000000000 --- a/deal.II/doc/tutorial/chapter-1.elements/index.html +++ /dev/null @@ -1,34 +0,0 @@ - - - -deal.II tutorial: Elements of finite element programs - - - - - - - - - - - - - - - - - -<h1>The deal.II Tutorial</h1> -Your browser does not seem to understand frames. A version of this -tutorial that does not use frames can be found at -<a href="toc.html">../../tutorial/chapter-1.elements/toc.html</a>. - - - - - - - - diff --git a/deal.II/doc/tutorial/chapter-1.elements/matrix_generation.html b/deal.II/doc/tutorial/chapter-1.elements/matrix_generation.html deleted file mode 100644 index 2af2e7a3b0..0000000000 --- a/deal.II/doc/tutorial/chapter-1.elements/matrix_generation.html +++ /dev/null @@ -1,253 +0,0 @@ - - - - - -deal.II tutorial: Matrix and Vector Generation - - - - - - - - - -

Matrix and Vector Generation

- -

Different kinds of matrices

-There are several kinds of matrices which we will deal with: -

-Full matrices, i.e. matrices where we store all -entries, which is useful if the majority of entries is non-zero. -
-Sparse matrices, i.e. matrices where the majority of -cells has zero value; these zeroes are not stored in order to save memory. -

- -

The full matrix

- -

-The full matrix is useful is we can assume that the we have mostly -entries of non-zero value. Since we then store all entries, it -consumes a lot of memory, much more than the other matrix types. It -is initialized using FullMatrix::reinit(const unsigned int rows, -const unsigned int cols). -

- -

-Example: We show the include files you need, -the definitions and the function calls. Make sure to use them in their -appropriate places. This example initializes two full matrices of doubles -with 100 rows and 50 columns in two different ways. -

-
-#include <dofs/dof_handler.h>
-#include <lac/full_matrix.h>
-
-FullMatrix<double> A;
-
-A.reinit(100,50);
-
-// or, alternatively (important for const objects):
-
-FullMatrix<double> B(100,50);
-
-
-

- - -

The sparse matrix

- -

-A sparse matrix is a matrix with mostly zero elements. In other words, -it is possible to store this matrix efficiently, which can be important -for large systems of equations. Before generating a sparse matrix you -will have to generate a -sparse matrix structure -to initialize the sparse matrix with. This is simply due to the fact that -before you can generate a memory-efficient matrix for your special -problem you need information about the matrix structure, i.e. where -the matrix has non-zero entries. -

- - -

-Example: We show the include files you need, -the definitions and the function calls. Make sure to use them in their -appropriate places. This example initializes a sparse square matrix structure. -

-
-#include <dofs/dof_handler.h>
-#include <lac/sparse_matrix.h>
-
-
-const unsigned int dim=2; // For example
-SparsityPattern sparsity_pattern;
-SparseMatrix<double> sparse_matrix;
-DoFHandler<dim> dof_handler;
-
-// Your degrees of freedom must already be distributed
-
-sparsity_pattern.reinit (dof_handler.n_dofs(),
-                         dof_handler.n_dofs(),
-                         dof_handler.max_couplings_between_dofs());
-
-// If your grid is locally refined, condense the hanging nodes into the
-// structure.
-
-sparsity_pattern.compress();
-
-// initialize the actual matrix with the sparsity pattern
-sparse_matrix.reinit (sparsity_pattern);
-
-

- - -

Vector Generation

- -

-Vector operations are supplied by the class Vector. -The first and most important operation on a vector is its -initialization using void Vector::reinit(const usigned int N, -const bool fast=false), which resets the vector's size to -N and sets all elements to zero. If the second parameter -fast is set true, this means that the entries will not be -cleared; this is useful if the vector is being assigned to immediately -after, in which case an initialization with zeroes would be -redundant. Note that this mode of use is rather uncommon and mostly -only useful inside linear solvers where it is important to save as -much computing time as possible. -

- -

-In addition to standard vector operations such as addition, multiplication with -a vector etc. deal.II provides several vector norms, too: -

- -

the l1-norm: Number Vector::l1_norm() const
the l2-norm: Number Vector::l2_norm() const
the infinity-norm: Number Vector::infty_norm() const

- -

-Example:Continuing the above example, -we initialize the vector for the right hand side. Recall that the problem -matrix is a sparse square matrix of size -dof.n_dofs()². -

-
-#include <lac/vector.h>
-
-Vector<double> f;
-
-f.reinit(dof.n_dofs());
-
-

- - -

A word on memory allocation

- -Since vectors and matrices are used very often, it is necessary -to be rather conservative with operations that may use significant -computing time. One of such operations is memory allocation and -de-allocation. For this reason, the reinit functions of -all vector and matrix classes are implemented in a way to only allow -the allocated memory to grow, since this reduces the number of times -allocation and de-allocation has to happen, and in addition reduces -memory fragmentation. -

-One immediate consequence is that if you write -

-
-Vector<double> f;
-f.reinit(100);
-f.reinit(50);
-
-

-then the second reinit will only have the effect of -reducing the internal size of the vector, but the memory that is no -more needed will not be released. Likewise, if you later write -

-
-f.reinit(100);
-
-

-this will again only set the size of the vector to a different value, -but since enough memory is still allocated, no re-allocation has to -happen. Only if the required number of entries exceeds the memory -already allocated, will there be a re-allocation. -

-All matrix and vector classes in deal.II work this -way, and in fact this is also the way the standard C++ container -classes like vector or map work. -However, this is not very useful if you use vectors or matrices -as member variables, since at times they may not be used at all if -your program works on other objects or you are in other parts of the -object. You would then like to let the vectors and matrices sleep with -no memory presently lying around unused. For this purpose, all -matrices and vectors support a mode of their reinit -function which frees all memory that is presently allocated: just call -it with parameters such that the new size is zero. For example, the -following lines will release all memory from their objects: -

-
-f.reinit(0);
-full_matrix.reinit(0,0);
-sparse_matrix_struct.reinit (0,0);
-sparse_matrix.reinit (sparse_matrix_struct);
-
-

-Note that in the last line, you have to pass an empty sparsity pattern -to the sparse matrix to tell it to release all of its memory. - - -

A word of caution

- -It is noted that several vector and matrix classes have a -clear function. These, however, work differently than -might be expected from the analogous functions in the C++ standard -library. There, clear removes all data from the objects -and resets it into a virgin state. In deal.II, -clear only resets the values of a metrix or vector to -zero, but does not change the size and does no re-allocation -either. This unfortunate name clash is due to historical reasons. - - -

- - - - - - - -

- -

- - diff --git a/deal.II/doc/tutorial/chapter-1.elements/matrix_structure.html b/deal.II/doc/tutorial/chapter-1.elements/matrix_structure.html deleted file mode 100644 index f0b7cddcfb..0000000000 --- a/deal.II/doc/tutorial/chapter-1.elements/matrix_structure.html +++ /dev/null @@ -1,225 +0,0 @@ - - - - - -deal.II tutorial: Matrix Structure - - - - - - - - - -

Matrix Structure

- -

Why thinking about matrix structures is important

-Many of the matrices encountered when trying to solve systems of differential -equations consist mostly of zero entries. At the same time those matrices are -very large, and therefore storage is expensive in terms of memory. -deal.II attempts to resolve this problem by -providing means of generating memory efficient structures for sparse -matrices where only non-zero elements are stored. -

-To show only two example of matrices which are quite typical of finite -element discretizations of partial differential equations, we present -the following two graphics, in which each dot represents a non-zero -entry of the matrix: -

- Sparsity 1 - Sparsity 2 -

-The first is a 300x300 matrix, the second has approximately 4000 rows -and columns. As can be seen, the vast majority of entries is zero, and -we can also guess that the proportion of zeroes is even growing as the -matrix size is increased (this is in fact so, but can not so clearly -be seen from the pictures, admittedly). The equation discretized to -yield these matrices is rather complex, so the number of non-zero -entries per row is quite large for finite element matrices. -Both matrices were derived after renumbering of the degrees of freedom -using the algorithm of Cuthill-McKee, which concentrates the entries -around the diagonal of the matrix. - - -

Ways of dealing with matrix structures provided by deal.II

-Before you can build the appropriate matrices for your problem you -need to ascertain where the components of your matrix are non-zero -and generate a structure for storing the matrix accordingly. -This structure -is then used to actually initialize the matrix, i.e. -tell the matrix for which elements to allocate memory. -

- -

The Standard Sparse Matrix

-The deal.II function initializing a standard sparse matrix -structure is void SparsityPattern::reinit(const unsigned int m, const unsigned int n, const unsigned int max_per_row). It takes as its arguments -the size of the matrix in question and the maximum number of non-zero elements -in one row. This first sets up a blank sparsity pattern which, -however, has as yet no information which entries are non-zero. -

-Before going on with showing how to find out which elements are -non-zero, we have to talk about how to find out about the maximum -number of non-zero entries per row which we will need for our matrix. -Since this number depends of the actual finite element used (higher -order elements need more non-zero entries than linear elements, for -example), of the equation under consideration, and of some properties -of the triangulation on which we want to do our computations. Since -all these factors can't be considered by the user all the time, there -is a library function which does the necessary computations for you: -unsigned int DoFHandler::max_couplings_between_dofs(). -We note that this function was written to cope with refined grids, and -if you only have structured grids without local refinement and hanging -nodes, the result of this function will overestimate the maximal -number of non-zero entries per row. -

-After having fixed the basic properties of the sparsity structure, we -can tell it which entries actually are non-zero. This is again done -using a library function, -DoFTools::make_sparsity_pattern. Then we have to take -into account that constraints due to hanging nodes (see the previous -chapter) add some more non-zero entries, which is again done using -some library functions (see the example below). After this, we can -instruct the sparsity pattern to throw out all unused elements -(in those rows where the actual number of non-zero elements is less -than the maximal number given to reinit, we can discard -the unused one to save some more memory). This is discussed in the -next subsection. -

-This matrix structure can then be used to serve as sparsity pattern to -one or several matrices using -void SparseMatrix::reinit(const SparsityPattern &sparsity). -We note the distinction that the SparsityPattern only -stores the places of the non-zero elements, while the -SparseMatrix actually stores the values of these -elements. The separation was made since often several matrices are -needed with the same sparsity pattern, but different entry values; -this way, we can save some memory space. -

- -

-Example: We show the include files you need, -the definitions and the function calls. Make sure to use them in their -appropriate places. This example initializes a sparse square matrix structure. -

-
-#include <dofs/dof_handler.h>
-#include <lac/sparse_matrix.h>
-#include <dofs/dof_tools.h>
-
-
-const unsigned int dim=2; // For example
-SparsityPattern sparsity_pattern;
-DoFHandler<dim> dof_handler;
-
-// set up a triangulation, refine it, associate the DoFHandler object
-// shown above to it, and distribute the degrees of freedom
-...
-
-// now fix the size of the matrix and the maximal number
-// of non-zero entries:
-sparsity_pattern.reinit (dof_handler.n_dofs(),
-                         dof_handler.n_dofs(),
-                         dof_handler.max_couplings_between_dofs());
-
-// tell the sparsity pattern which entries are non-zero:
-make_sparsity_pattern (dof_handler, sparsity_pattern); 
-
-// Condense the hanging nodes into
-// the matrix structure, taking into account the constraints due to
-// the hanging nodes. 
-// You can skip this part if your grid is not locally refined.
-ConstraintMatrix hanging_nodes; 
-dof_handler.make_constraint_matrix(hanging_nodes);
-hanging_nodes.condense (sparsity_pattern);
-
-

- -

Compression of Matrix Structures

- -

-Sparse matrix structures can (and indeed must) be compressed before they are used -in objects of the class SparseMatrix<> that actually hold the matrix -data. The reason for this is the way matrix structures and matrices are generated: -

Initially a fixed number of non-zero entries is allocated for each matrix row. - Usually, though, rows will have much less entries than this maximum number. Rows - rows corresponding to degrees of freedom - on cells with hanging nodes have more entries than rows corresponding to degrees of freedom - in regular regions of the grid. -
When you compress the matrix structure - you stop adding new non-zero entries and all unused entries in each row - are deleted. Thus memory is saved. -
Only now are you allowed to associate this matrix structure - to a matrix object which then allocates memory for each non-zero entry, - rather than for the maximum number of non-zero entries of each row. -

- -The appropriate function is void SparsityPattern::compress(). -

- -

-Example: Starting from the example above, we -compress our matrix structure sparsity_pattern. -

-
-sparsity_pattern.compress();
-
-

- - -

More complex matrices

- -Finally, we note that in some cases not all variables in a system of -partial differential equations couple to each other, or that the -operators have a special structure. For this reason, there are more -specialized version of the -DoFTools::make_sparsity_pattern and -SparsityPattern::reinit functions, which allow you to -more flexibly determine the actual number of non-zero elements of all -or individual rows. See the documentation of the respective classes -for more information. - - - -

- - - - - - - -

- The Problem Matrix and the Right Hand Side -

- -

- - - diff --git a/deal.II/doc/tutorial/chapter-1.elements/navbar.html b/deal.II/doc/tutorial/chapter-1.elements/navbar.html deleted file mode 100644 index 3fee673561..0000000000 --- a/deal.II/doc/tutorial/chapter-1.elements/navbar.html +++ /dev/null @@ -1,123 +0,0 @@ - - - -deal.II tutorial: Structure of a Finite Element Program - - - - - - - -

-Table of contents -

- Long table of contents -

- Creation of a grid -

- -

- Degrees of Freedom -

- -

- Hanging Nodes -

- -

- Matrix Structure -

- -

- Matrix and Vector Generation -

- -

- -

- Boundary Conditions -

- -

- Condensing the Hanging Nodes -

- -

- Solving the Problem -

- -

- Postprocessing -

- -

- Error Estimation and Adaptivity -

- -

- Parameter Input -

- -

- Grid and Data Output -

- -

- -

- Back to the deal.II homepage -

- - -

- -

- Comments on the tutorial -

- - - - - - - - - - diff --git a/deal.II/doc/tutorial/chapter-1.elements/output.html b/deal.II/doc/tutorial/chapter-1.elements/output.html deleted file mode 100644 index 248c07d9b8..0000000000 --- a/deal.II/doc/tutorial/chapter-1.elements/output.html +++ /dev/null @@ -1,736 +0,0 @@ - - - - - -deal.II tutorial: Grid and Data Output - - - - - - - - - -

Grid and Data Output

- -

-Grid and data output becomes a difficult thing as soon as flexibility -in terms of different output formats and which parts of the data -are actually written is required. -Consequently, there is a bunch of classes in deal.II, -every one dealing with a different aspect of the problem. You, the -user, however, need to concern yourself only with two ouput classes: -GridOut and DataOut handling the output of -grid and data, respectively. In addition there is one class for -each kind of output storing the parameters for this particular -format. These parameters are common to both grid and data ouput -and are used by both GridOut and DataOut. -

- -

-Since deal.II is fairly versatile when it comes -to graphics output we shall have to talk about the following topics -in depth: -

- -

Graphics formats for - GridOut and DataOut -
Parameters for the different formats - common to both GridOut and DataOut -
Usage of DataOut -
Usage of GridOut -

- -

Graphics Formats

-deal.II provides a class called DataOut -dealing with the output of simulation data and a class called -GridOut handling the output of grid (triangulation) data. -Both are fairly versatile and can handle a -number of different data formats. -

- -

`DataOut` graphics formats

-The graphics formats available in DataOut are: -

Unstructured Cell Data (ucd) -
Gnuplot, in two different qualities. -
Encapsulated Postscript (eps) -
PoVRay mesh data, for use with the PoVRay raytracer. -
General Mesh Viewer -

- - -

`GridOut` graphics formats

-The graphics formats available in GridOut are: -

Unstructured Cell Data (ucd) -
Gnuplot -
Encapsulated Postscript (eps) -

- -

Parameters for grid and data output

- -

For each output format there is a class containing the -parameters that determine how the output will look. All these classes -have a sensible set of default parameters; you will only have -to bother about setting parameters yourself if your desires are -rather special. We shall commence with a brief description of -these classes and the most important parameters you can set. It is -also worthwhile to look at the online documentation to see whether -additional flags have been introduced in the meantime. -

- - -

UcdFlags

- -

-This class provides the settings for ucd output. The values in brackets -denote the default values. -

bool write_preamble (true): - Determines whether to write a preamble containing creation - date etc. -

- -

GnuplotFlags

- -

-This class provides the settings for gnuplot output. At present it -is empty. -

- -

EpsFlags

- -

-This class provides the settings for EPS output. The values in brackets -denote the default values. -

- -

unsigned int height_vector (0): - Number of the data vector to be used for generation of the height - information. The number is determined by the order in which - DataOut<dim>::add_data_vector was called - for the different vectors. -
unsigned int color_vector (0): - Number of the data vector to be used for colorizing cells. - The number is determined by the order in which - DataOut<dim>::add_data_vector was called - for the different vectors. -
SizeType sizetype (width): - Determines whether the width or the height is used to scale - the output. Can be set to width or height. -
unsigned int size (300): - Size of the output in points. One point is 1/72 inch. -
double line_width (0.5): - Width of a line in points. One point is 1/72 inch. -
double azimut_angle (60): - Viewing angle with respect to the positive z-axis. -
double turn_angle (30): - We quote the class documentation: - Angle by which the viewers position projected onto the - x-y-plane is rotated around the z-axis, in positive sense when - viewed from above. The unit are degrees, and zero - equals a position above or below the negative y-axis. - -
double z_scaling (1): - Factor by which the z-axis is stretched compared to the - x- and y-axis. -
bool draw_mesh (true): - Determines whether the cell boundaries are drawn. -
bool draw_cells (true): Determines whether the - cells are drawn. If this flag is true and - shade_cells is false the cells are filled with white. -
bool shade_cells (true): - Determines whether to colour cells. -
ColorFunction color_function (&default_color_function): - Determines the function to use for colouring the cells. The default - shifts the colours from black for the lowest values through the - spectrum towards white. -

- -

PovrayFlags

-This class provides the settings for PoVRay output. There are several -flags implemented presently, but we advise you to consult the online -documentation since they are rather special and you will probably have -to set them anyway, if you want high-quality output. -

- -

GmvFlags

-This class provides the settings for General Mesh Viewer output. At present it -is empty. -

- - -

- -

General description of the usage of -`DataOut`

- -

-What exactly it is you need to do in order to make use of the -DataOut -class is described in the table below. Note that data is written to an -ostream. That means you have to attach your ostream -to a file if you want to use the data later on. -

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

**Usage of the `DataOut` class**
Step -	What to do -	Function call -
1.	Use the correct include-file. -	`#include <numerics/data_out.h>` -
2.	Create an object of this class with the right dimension. - It takes no initialization parameters. -	`DataOut<dim> my_data_out;` -
3. -	Attach a `DoFHandler` - object to your `DataOut` - object. This `DoFHandler` - is used to extract geometry - data and the mapping between nodes and node values. -	`- void DataOut<dim>::attach_dof_handler(const DoFHandler<dim> &) -` -
4. -	Add data vectors to be written to a file. The second and third argument - are the name of the vector and its physical units. -	`- void DataOut<dim>::add_data_vector(const Vector<double> &data, - const string &name, const string & - units="<dimensionless>") -` -
5. -	Generate an `ostream` (and, normally, attach it to a file). -	`- ofstream out("filename"); -` -
6. -	Write your data to this ofstream. The second parameter denotes the - output format to be used. It must be one of `{ ucd, gnuplot, - gnuplot_draft, - povray_mesh, eps, gmv }`. -	`void DataOut<dim>::write(ostream &out, const OutputFormat output_format)` -

- - -

- -

`DataOut` data formats

- -

Unstructured Cell Data (ucd)

- -

-The ucd data format is described in the AVS developer's guide. There -are a binary and a ASCII version of this format. deal.II -uses the ASCII ucd format. -

- -

Limitations of the ucd format

-Only node based data can be written, higher order elements are written -with their node values, not with interior or line values. This is -due to limitations in the present format. In this implementation -it is not possible to give model data since this is not widely supported. -It is possible to give cell data. -

- -

Usage of the ucd format

- -

-In order to write your data in ucd format you need to follow the -steps described in the section on the usage of -DataOut. -The data is written using void write(ostream &out,"ucd"). -

- - -

Gnuplot data format

- -

Understanding gnuplot data

- -

-The gnuplot data format is a pure ASCII format where each line is -of the form
-x v1 v2 ...
-for one-dimensional data and
-x y v1 v2 ...
-for two-dimensional data.
-x and y denote the grid coordinates, -v_i denote the vertex values. -

- -

-A somewhat more elaborate description can be found in the -Gnuplot User's Guide (Postscript) -

- -

Viewing gnuplot data

- -

-In order to view a one-dimensional plot you use
--plot "filename" using 1:x
-where x denotes the number of the vertex you wish to plot. -

- -

-In order to view your grid in two dimensions you should use
--set data style lines -plot "filename" - -and to finally see your results
--set data style lines -plot "filename" using 1:2:x -
-where again x denotes the number of the vertex -to be plotted. -

- - -

Limitations of the gnuplot data format

- -

The limitations of the gnuplot data format have been well described -in the - -DataOutBase class description: -

-
-This format is somewhat restricted to coninuous data and to finite -elements of first order only. The reason for the first restriction is -that it takes nodal values and can therefore only work if a finite -element has degrees of freedom in the vertices of each cell. This is -not the case for discontinuous elements. The second restriction is -only a problem of quality of output: you actually can print quadratic -or higher order elements using this style, but you will only see the -contour of each cell with the bounding lines of each cell being -straight lines. You won't see the structure of the solution in the -interior of a cell nor on the lines bounding it. -
-

- -

The two different qualities of gnuplot output

- -

The limitations mentioned above can to some extent be remedied, -and that is why there is also an option for high quality output. -For how this is done, we quote (again) the - -DataOutBase class description: -

- -

-
-To remedy the abovementioned problems, the gnuplot "quality" format -was introduced. [...] gnuplot can handle tensor grids and -displays them quite nicely, -including hidden line removal. It can also handle more than one tensor grid, -then called a patch. The idea now is to describe each cell as a patch of -N x N points (in 2D). -For linear elements, 2 x 2 is sufficient, but for elements -of higher order you will want to use a higher number. The -write_gnuplot -function writes the data in this format and -the argument it takes is the number of subintervals it divides each cell into, - i.e. N-1. -
-
-This output routine also addresses the problem introduced with discontinuous -elements, since it takes its data locally from each cell and displays it as a -patch separately; it -therefore does not use continuity and gnuplot will also plot discontinuities -if there are any. -
-

- - -

Usage of the gnuplot data format

- -

-In order to write your data in gnuplot format you need to follow the -steps described in the section on the usage of -DataOut. -The data is written using -

- void write(ostream &out,"gnuplot_draft") for the lower - (draft) quality output. -
- void write(ostream &out,"gnuplot") for the high quality - output. -

- -

Encapsulated Postscript (EPS)

- -

EPS output of deal.II data consists of the grid -and the cells. The cells can be left empty, printed white (which leads -to hidden-line removal) or colorized using a data vector. This format -does not support gradient shading, i.e. each cell has one color which -is taken from the value of the data in its centre. Coordinates -have at most five digits, and the EPS files do not have an explicit -bounding box, i.e. the bonding box is close to the graphics on -all four sides. EPS output can only be used for two-dimensional -data. -

- -

EPS otput is performed by calling
-void DataOut<dim>::write_eps(ostream &out) -

- - -

PoVRay output

- -

-PoVRay is a most comprehensive raytracer freely available at -http://www.povray.org. -This is also the place to start looking for more information -on its features. -

- -

PoVRay output is accomplished by calling
-DataOut<dim>::write_povray(ostream &out)
-At present there is no more information available on PoVRay output -in deal.II. -

- - -

General Mesh Viewer (gmv) output

- -

-The General Mesh Viewer can display data in both 2D, 3D and cuts through -data sets. More information on the gmv is available at - -http://www-xdiv.lanl.gov/XCM/gmv/GMVHome.html -At present the gmv cannot output postscript or EPS data. -

- -

-gmv output is accomplished by calling
-void DataOut<dim>::write_gmv(ostream &out)
-There is no more information available on the output format. -

- -

General description of the usage of -`GridOut`

- -

-What exactly it is you need to do in order to make use of the -GridOut -class is described in the table below. Note that data is written to an -ostream. That means you have to attach your ostream -to a file if you want to use the data later on. -

- -

-There are essentially two ways to use GridOut: If you don't need -to change any of the default parameters (which will be explained along with -the graphics formats) you can use the class almost as if its methods -were static. There is no need to create a GridOut object -in advance. -

- -

-The second method requires the creation of a GridOut object -to which parameters can be passed. -

- - - - - - - - - - - - - - - - - - - - - - - -

**Usage of the `GridOut` class with the default parameters**
Step -	What to do -	Function call -
1.	Use the correct include-file. -	`#include <grid/grid_out.h>` -
2. -	Generate an `ostream` (and, normally, attach it to a file). -	`- ofstream out("filename"); -` -
3. -	Write your data to the ofstream by calling the appropriate - `write` method giving your triangulation object and - the output file type as parameters. `output_format` - is one of {ucd,gnuplot, eps}. -	`void GridOut().write(const Triangulation<dim> & tria,ostream &out, const OutputFormat output_format)` -

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

**Usage of the `GridOut` class with new parameters**
Step -	What to do -	Function call -
1.	Use the correct include-files. -	`#include <grid/grid_out.h>` - `#include <numerics/data_out_base.h>` -
2. -	Generate an `ostream` (and, normally, attach it to a file). -	`- ofstream out("filename"); -` -
3. -	Generate a `GridOut<dim>` object. -	`GridOut<dim> my_grid_out;` -
4. -	Set your parameters (in this example for ucd). -	`UcdFlags ucd_flags; - ucd_flags.write_preamble = 1; - my_grid_out.set_flags(ucd_flags); -` -
5. -	Write your data to the ostream by calling the appropriate - `write` method giving your triangulation object and - the output file type as parameters. `output_format` - is one of {ucd,gnuplot, eps}. -	`void my_grid_out.write(const Triangulation<dim> & tria,ostream &out, const OutputFormat output_format)` -

- -

`GridOut` data formats

- - -

Unstructured Cell Data (ucd)

- -

-The ucd data format is described in the AVS developer's guide. There -are a binary and a ASCII version of this format. deal.II -uses the ASCII ucd format. -

- -

-The ucd data format is special because it can not only be written but -also read by deal.II. I.e. you can use a triangulation -written to a ucd-file as a starting triangulation for -deal.II. In order to be able to reuse your triangulation -you will need to explicitly write all of your boundary indicators that -are not zero to the output file. Otherwise, upon reloading the triangulation, -all your boundaries will be labelled with the default value, zero. -There is a flag in the class UcdFlags -controlling GridOut with respect to whether -boundary indicators are explicitly written: -bool UcdFlags::write_preamble. It defaults to true, i.e. -boundary indicators are written by default and you can use the first, -simpler method for writing ucd-files. -

- -

Gnuplot data format

- -

-Gnuplot output is performed by calling
-void write_gnuplot (const Triangulation<dim> &tria, -ostream &out)
-It is controlled by the class GnuplotFlags. -

- -

-In Gnuplot format the boundaries of each cell -are written as a sequence of lines to your output stream. -Output can be modified by the following flags: -

GnuplotFlags::write_cell_numbers: - If this is set the (internal) number of each cell is written to the - output file before the cell data. -
GnuplotFlags::write_level: If this flag - is set the refinement level of each cell is written as an - additional column. This can be used to raise the cells according - to their refinement level if a 2D-grid is plotted as 3D, or, - alternatively, to plot only the cells within a given range of - levels of refinement using
- splot [:][:][level1:level2] "filename" -

-Contrary to, e.g., EPS, you do not need to set a viewpoint. -

- -

Encapsulated Postscript

- -

-EPS output is performed using the parameters set forth in the class -EpsFlags. Grid output in the EPS format is always -two-dimensional; 3D-grids are viewed from a given viewpoint -without hidden-line removal. -EPS output is performed by calling
-GridOut::write_eps (Triangulation& tria, ostream& output) -
-Alternatively, you can use the general GridOut::write method -as explained in the part on the usage of the -GridOut class. -

- - - - - - -

- -

- - diff --git a/deal.II/doc/tutorial/chapter-1.elements/parameters.html b/deal.II/doc/tutorial/chapter-1.elements/parameters.html deleted file mode 100644 index 8c16cf94e7..0000000000 --- a/deal.II/doc/tutorial/chapter-1.elements/parameters.html +++ /dev/null @@ -1,381 +0,0 @@ - - - - - -deal.II tutorial: Parameter Input - - - - - - - - - -

Parameter Input

- -

-When writing a numerical program you will usually wish to keep it flexible -with regard to parameter settings and the like. Rewriting a program -every time a parameter changes is ever so annoying. -For this reason deal.II provides a class -called ParameterHandler. This class enables you to easily -parse a parameter file and extract the values of the parameters. -The names and allowed values of the parameters can be defined by you. -

- -

Introducing parameters into your code

- -

Introduction - the most simple case

-The most simple way to using runtime parameters in your program is the following: -

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

**Using runtime parameters**
Step -	What to do -	Function call -
1.	Use the correct include-file. -	`#include <base/parameter_handler.h>` -
2.	Declare a parameter handler object. -	`ParameterHandler prm;` -
3.	Tell the parameter handler about the parameters, their types and their - default values. Here we get one parameter called - "My favourite booze", its default value is - "Stout" and we allow anything as its value. Note that - the parameter name may contain whitespace. -	`prm.declare_entry("My favourite booze", - "Stout",Patterns::Anything()); -` -
4.	Generate a parameter file. Following the example above, we - set "My favourite booze" to "Ale". This - file will be called "parameters.in". -	`set My favourite booze = Ale` -
5.	Read the parameters from the file. -	`prm.read_input("parameters.in");` -
6.	Find the values of your parameters. -	`string booze = prm.get("My favourite booze");` -

- -

-The few steps outlined above are indeed the most simple case. What, now, if -you have a more complex set of parameters, grouped by purpose ? You could, -for example, wish to solve different equations and set parameters for each -of them. For this purpose you can introduce subsections into -your parameter set. -

- -

Subsections

- -

-Parameters declared in different subsections are distinct, although they -may share the same name. Let us stay with the example of two equations -for which you wish to set parameters: Zeldovich-equation and -Sunyaev-equation. You want to be able to use different solvers, -and thus both take a parameter called Solver. -The way to go is to declare two subsections called (preferably) -Zeldovich-equation and Sunyaev-equation. Each of the two -subsections contains a parameter called Solver. -

- -

-Example: -We declare subsections for two equations called -Zeldovich-equation and Sunyaev-equation -within a parameter handler. -The allowed values for the parameter Solver are -CG (default) and GMRES. Afterwards -we read the settings from a file called "parameters.in" -and retrieve their values. The values are stored in the strings -zeldovich_solver and sunyaev_solver. -Please note that in order to stick to the essentials this example -violates the - -recommended style for parameter declaration. -

- -

 
-
-// We declare a parameter handler
-
-ParameterHandler prm;
-
-// We declare the first subsection and its entry
-
-prm.enter_subsection("Zeldovich-equation")
-prm.declare_entry("Solver","CG",Patterns::Sequence("CG|GMRES"));
-prm.leave_subsection();
-
-// We declare the second subsection and its entry
-
-prm.enter_subsection("Sunyaev-equation")
-prm.declare_entry("Solver","CG",Patterns::Sequence("CG|GMRES"));
-prm.leave_subsection();
-
-// The input file is read
-
-prm.read_input("parameters.in"
-
-// We retrieve the parameters from the first subsection
-
-prm.enter_subsection("Zeldovich-equation")
-string zeldovich_solver = prm.get("Solver");
-prm.leave_subsection();
-
-// We retrieve the parameters from the second subsection
-
-prm.enter_subsection("Sunyaev-equation")
-string sunyaev_solver = prm.get("Solver");
-prm.leave_subsection();
-
-

- -

We continue this example with a sample parameter -file that tells the code to solve the Zeldovich equation using GMRES -and the Sunyaev equation using CG. -

- -

-
-subsection Zeldovich-equation
-  set Solver = GMRES
-end
-
-subsection Sunyaev-equation
-  set Solver = CG
-end
-
-

- -

-There are, as we have seen, two methods within the -ParameterHandler class handling subsections:
--void ParameterHandler::enter_subsection(const string &subsection) -
-and
--bool ParameterHandler::leave_subsection() -
-Their names are telling. First you enter a subsection, then you declare -(or retrieve) -all the parameters for this subsection and finally you leave it. -Subsections may be nested, i.e. you are at liberty to declare -subsections within subsections within subsections... -

- -

Parameter types

- -

-The parameter handler allows you to specify that any parameter -be of a distinct type. -Upon reading a file the value of this -parameter is checked against the type and an exception is thrown -if they do not match. An exception is also thrown if the default -parameter does not match the specified type. -Below we show a list of the types available. The first column -gives an explanation, the second lists the corresponding C++ type -and the third column shows how to use this type in deal.II. -Parameter values may not contain linebreaks. -deal.II always gets passed a pointer to a class -handling that type. Those classes are defined in a structure -called Patterns. The include file to be used is the -same as for the ParameterHandler class. -

- - - - - - - - - - - - - - - - - - - - - - - - - - - - -

**Parameter types**
Type -	Correspondig C++ type -	deal.II type -
Integer number.	`int` -	`Patterns::Integer()` -
Floating point number of double length.	`double` -	`Patterns::Double()` -
One member of a set.	`enum` -	`Patterns::Sequence("element 1\|element 2\|...")` -
An arbitrary string.	`string` -	`Patterns::Anything()` -

- - -

Allowed characters

- -

-Neither the names nor the values of entries may contain the -following characters:
-\ { } |
-

- -

-Besides, entries may not contain linebreaks, i.e. entries may not span -multiple lines. -

- -

-Leading and trailing whitespace is ignored and multiple whitespace is -condensed into one. Entry or subsection -declarations within your code should therefore -not contain multiple whitespace, which will not be recognized. -

- -

Different input sources

- -

-You can obtain data from three different kinds of source: -

an istream
a file
a string

- -

-It is possible to use different sources successively. Parameters -that are entered more than once will be overwritten, i.e. the -value encountered last of the parameter in question is used. -

- -

-Example: -We read parameters successively -from three different sources. This example was taken from -the ParameterHandler class documentation. -

- -

-
-ParameterHandler prm;
-...
-// declaration of entries
-...
-prm.read_input (cin);         // read input from standard in,
-// or
-prm.read_input ("simulation.in");
-// or
-char *in = "set Time step size = 0.3 \n ...";
-prm.read_input (in);
-...
-
-

- -

Parameter output

- -

-You can, for example for logging purposes, write all the parameters -your code knows about to an ostream in a given format. -The formats supported at present are text and LaTeX. -The method handling this is called:
--ostream & ParameterHandler::print_parameters(ostream &out, const OutputStyle style) -
-

- -

-You can also write the parameters of a single subsection to an -ostream using
--void ParameterHandler::print_parameters_section (ostream &out, - const OutputStyle style, - const unsigned int indent_level); - -

- -

-In both cases out is the ostream -the parameters are written to, style is -the output format, either -text or LaTeX. In the case of subsections -the indent_level is the level of indentation. -

- - -

- - - - - - - -

- -

- - diff --git a/deal.II/doc/tutorial/chapter-1.elements/postprocess.html b/deal.II/doc/tutorial/chapter-1.elements/postprocess.html deleted file mode 100644 index 9d9acd3565..0000000000 --- a/deal.II/doc/tutorial/chapter-1.elements/postprocess.html +++ /dev/null @@ -1,48 +0,0 @@ - - - - - -deal.II tutorial: Condensing the Hanging Nodes - - - - - - - - - -

Postprocessing

- -

-This section has unfortunately not yet been written. -

- - - -

- - - - - - - -

- -

- - diff --git a/deal.II/doc/tutorial/chapter-1.elements/rhs.html b/deal.II/doc/tutorial/chapter-1.elements/rhs.html deleted file mode 100644 index ed8d86f1cf..0000000000 --- a/deal.II/doc/tutorial/chapter-1.elements/rhs.html +++ /dev/null @@ -1,199 +0,0 @@ - - - - - -deal.II tutorial: The Problem Matrix and the Right Hand Side - - - - - - - - - -

The Problem Matrix and the Right Hand Side

- -

-Having talked a lot about the initialization of matrices and vectors -we shall now discuss how to fill them. You have to: -

Define a quadrature rule which will be used for integration of - the local cell matrices and vectors.
Calculate the trial functions for the - finite elements and their faces. -
Integrate the problem locally.
Insert your local matrix into the global one.

- -

Calculating finite element trial functions

- -

-Example: The two lines below calculate -trial functions for the two-dimensional finite element fe -and for its faces using Gaussian quadrature. The first line -initializes an object for the trial and test functions of the -finite element associated with the degree of freedom handler -dof_handler, telling it to update the values of the gradients and -of the Jacobi determinant multiplied by a weight function given by the -quadrature quadrature whenever fe_values.reinit(fe) -is called on a cell. The second line does the same for the faces of the finite -element, telling it to update the JxW values and the -quadrature points. -

-
-// Initialize the trial functions on the cell faces.
-FEValues<2> fe_values(fe, quadrature,
-                   UpdateFlags(update_values    | 
-                               update_gradients |
-                               update_JxW_values));
-FEFaceValues<2> fe_face_values (fe, face_quadrature,
-                              UpdateFlags(update_values     | 
-                                          update_JxW_values |
-                                          update_q_points));
-
-

- -

Integrating the problem

- -

-Integration of a problem is performed locally, i.e. you have to traverse all -the cells and integrate the problem on the cell. This implies that you need a local -matrix to store your results. This local matrix must then be inserted -into the global problem matrix. -

- -

-Example: Integration of the two-dimensional Laplace-problem: -Integration is done locally. Therefore we need appropriate definitions for -

-an index vector that will allow us to reassemble the global matrix later on -
a vector of doubles with the dimension of the number of degrees of freedom per cell -
and a square matrix of doubles with the same dimension

- -

-
-  vector<int> dof_indices (fe.dofs_per_cell);
-  Vector<double> element_vector (fe.dofs_per_cell);
-  
-  FullMatrix<double> element_matrix (fe.dofs_per_cell, fe.dofs_per_cell);
-
-

- -

-Next we traverse all the cells and integrate the Laplace problem using the -discretized Laplace operator. quadrature is some quadrature -rule, for example a Gaussian rule. -

- -

-Within the loop over all cells, the outer loop traverses all the -points of the quadrature quadrature. The inner two loops -traverse the degrees of freedom of the finite element fe -where du and dv are the gradients of the -trial and test functions at the present quadrature points. -fe_values.JxW(k) gives -the Jacobi determinant multiplied by the weight of the quadrature -point k. Taken together the line
--element_matrix(i,j) += fevalues.JxW(k) * du * dv; - -
-gives the discretized Laplace operator. -

- -

-
-// Integrate the problem locally...
-vector<int>        local_dof_indices (fe.dofs_per_cell);
-Vector<double>     element_vector    (fe.dofs_per_cell);
-FullMatrix<double> element_matrix    (fe.dofs_per_cell);
-
-                        // traverse all cells  
-for (DoFHandler<2>::active_cell_iterator cell = dof_handler.begin_active();
-     cell != dof_handler.end(); ++cell)
-{
-                        // compute gradients and some other values
-                        // of the shape functions on this cell
-  fe_values.reinit (cell);
-                        // set entries of local matrix and vector
-                        // to zero
-  element_matrix.clear();
-  element_vector.clear();
-
-                        // The loop over the quadrature points
-                        // starts here. In effect, the  integration
-                        // is performed in this loop.
-  for (unsigned q_point=0; q_point<quadrature.n_quadrature_points; ++q_point)
-    for (unsigned i=0; i<fe.dofs_per_cell; ++i)
-      {
-        const Point<dim> dv = fe_values.shape_grad (i, q_point);
-	
-        for (unsigned j=0; j<fe.dofs_per_cell; ++j)
-          {
-	    const Point<2> du = fe_values.shape_grad(j,q_point);
-	
-	                // Perform the integration using
-                        // the weak form of the Laplace operator
-	    element_matrix(i,j) += fevalues.JxW(k) * du * dv;
-          }
-      }
-
-                        // get the global indices of the degrees
-                        // of freedom on the present cell
-  cell->get_dof_indices (local_dof_indices);
-                        // and insert the local matrix
-                        // into the global one.
-  for (unsigned i=0; i<fe.dofs_per_cell; ++i)
-    for (unsigned j=0; j<fe.dofs_per_cell; ++j)
-      A.add (local_indices[i], local_indices[j],
-             element_matrix (i,j));
-}    
-
-

- -The right hand side vector is set up analogously, but obviously you -only need one loop over the shape functions, since the right hand side -is a linear form instead of a bilinear one. - - - -

- - - - - - - -

- -

- - - - diff --git a/deal.II/doc/tutorial/chapter-1.elements/solve.html b/deal.II/doc/tutorial/chapter-1.elements/solve.html deleted file mode 100644 index 369fcc3e63..0000000000 --- a/deal.II/doc/tutorial/chapter-1.elements/solve.html +++ /dev/null @@ -1,454 +0,0 @@ - - - - - -deal.II tutorial: Solving the Problem - - - - - - - - - -

Solving the Problem

- -

-deal.II offers several solver classes: -

- -

- SolverBicgstab, the Bicgstab algorithm - by van der Worst -
- SolverCG, the preconditioned cg-algorithm -
- SolverGMRES, an implementation of the - Restarted - Preconditioned Direct Generalized Minimal Residual Method -
- SolverRichardson, the Richardson - iteration method -

-Some more specialized solvers may be implemented in the meantime. In -case you need some such solver, you should take a look at the -up-to-date online documentation. - -

-Besides the solver classes, there are several utility classes: -

-SolverControl to -control the iterative solvers, i.e. to determine whether the iteration -should be continued -
-SolverSelector, the use of which -offers several advantages over solver selection by hand -
-PreconditionSelector that allows -you to select a preconditioner -

- -

A note on deal.II solvers

- -

-All of the deal.II solvers have a structure -AdditionalData that is used to pass additional -arguments to the solver. We discuss this structure only for those -solvers that need it. -

- -

-Information on common solution methods can be found in any modern -textbook on finite elements, for example in Braess, Dietrich, Finite -Elements. The GMRES solver discussed below is rather -special, and if you are going to use it you probably know what -you are doing anyway. - -

-We will now begin with the discussion of the SolverControl, the -SolverSelector -and the PreconditionSelector classes, then discuss the solvers -in more detail. -

- -

Solver Control

- -

-The class SolverControl is used by iterative solvers -to determine whether to continue with the iteration. It takes two -to three parameters: the maximum number of iterations and the criterium for -abortion, usually the residual and a flag controlling whether to log the -history (the value to be checked and the number of the iteration step). -SolverControl is initialized using
-SolverControl (const unsigned int n, const double tol, const bool log_history = false) - -

-Example:We initialize a solver control with -a maximum of 1000 iterations and a maximum residual of 1e-6. -

- -

-
-#include <lac/solver_control.h>
-
-SolverControl control(1000,1e-6);
-
-

- -Thus, the iterative solver which with it shall be used will stop after -either 1000 iterations are performed or the norm of the residual is -below the given threshold. - - -

SolverSelector

- -

-The SolverSelector class is a wrapper for all the -deal.II solver classes. By calling it with the -right constructor you select your solver, and by calling its solve -method you call the solve method of the solver you selected. -The advantage of this approach is that your solver is an argument -to this class and - more important - an argument you can set in a -parameter file. That means that if you want to change your solver, e.g. -because a new one has been added you do not have to rewrite your program. -

-The SolverSelector is initialized using
--SolverSelector(const string solvername, SolverControl &control, -VectorMemory<Vector> &mem) - -

- -

-Example:We initialize a solver selector -that will call the cg-solver. The problem matrix is a sparse matrix of -doubles and the right hand side a vector of doubles. -

- -

-
-#include <lac/solver_control.h>
-#include <lac/solver_selector.h>
-#include <lac/sparse_matrix.h>
-#include <lac/vector.h>
-
-SolverControl control;
-VectorMemory<Vector<double> > mem;
-
-SolverSelector<SparseMatrix<double>, Vector<double> >
-  solver_selector("cg", control, mem);
-
-

- - -

Preconditioning

- -

-Before firing up the solver of your choice you will need some kind of -preconditioning. This is easiest selected by creating an instance of -the PreconditionSelect class with an appropriate choice of -parameters. This can be done using PreconditionSelector(const string -preconditioning, const typename Vector::value_type &omega=1.) -where preconditioning denotes the preconditioning method used -and omega is the damping parameter if the preconditioner -you selected uses it. -

-The preconditioning methods currently available using this class are -

none
jacobi
sor
ssor

-You can obtain a list of available methods by calling -string PreconditionSelector::get_precondition_names(). -

- -

-After having selected a preconditioner you will need to select a -matrix used for preconditioning. Usually this will be the problem matrix -A of the problem Au=f. -The method to be called is void PreconditionSelector::use_matrix(const -Matrix &M). -

- -

-Example:We initialize a Jacobi preconditioner -with a damping parameter of 1. The matrix used for preconditioning -is the matrix A -of the problem Au=f. -

- -

-
-#include <lac/precondition_selector.h>
-#include <dofs/dof_handler.h>
-#include <lac/full_matrix.h>
-
-FullMatrix<double> A(100,50);
-
-PreconditionSelector preconditioning("jacobi",1.);
-preconditioning.use_matrix(A);
-
-

- - - -

SolverBicgstab

- -

-This class implements the Bicgstab algorithm by van der Worst. -It is initialized by
-SolverBicgstab (SolverControl &cn, VectorMemory &mem). -

-Example:We initialize a Bicgstab-solver for -the problem Au=f, using the solver control -explained above. A shall be a sparse matrix and the vectors -u and f shall be vectors of doubles. Next, -we solve the problem. -

- -

-
-// Include files for solver control, solver and preconditioner
-#include <lac/solver_control.h>
-#include <lac/solver_bicgstab.h>
-#include <lac/precondition_selector.h>
-
-// Include files for matrices and vectors
-#include <lac/sparse_matrix.h>
-#include <lac/vector.h>
-
-// Initialize the solver control and the solver
-
-SolverControl control(1000,1e-6);
-VectorMemory<Vector<double> > vectormem;
-SolverBicgstab<SparseMatrix<double>,Vector<double> > solver(control,vectormem);
-
-// Initialize the problem matrices. Well...they shouldn't only be
-// initialized but also contain the problem, so this is just an example
-// to get the definitions and types and everything right. 
-
-SparseMatrix<double> A;
-Vector<double> u,f;
-
-// Generate a Jacobi preconditioner with the damping parameter 1
-PreconditionSelector<SparseMatrix<double>, Vector<double> > preconditioning("jacobi",1.);
-
-// Use the matrix of the linear equation system for preconditioning
-// (this is the usual case).
-preconditioning.use_matrix(A);
-
-solver.solve(A,u,f,preconditioning);
-
-

- -

SolverCG

- -

-This class implements the preconditioned cg-method. -It is initialized by
-SolverCG (SolverControl &cn, VectorMemory &mem). -

-Example:We initialize a CG-solver for -the problem Au=f, using the solver control -explained above. A shall be a sparse matrix and the vectors -u and f shall be vectors of doubles. Next, -we solve the problem. -

- -

-
-// Include files for solver control, solver and preconditioner
-#include <lac/solver_control.h>
-#include <lac/solver_bicgstab.h>
-#include <lac/precondition_selector.h>
-
-// Include files for matrices and vectors
-#include <lac/sparse_matrix.h>
-#include <lac/vector.h>
-
-// Initialize the solver control and the solver
-
-SolverControl control(1000,1e-6);
-VectorMemory<Vector<double> > vectormem;
-SolverCG<SparseMatrix<double>,Vector<double> > solver(control,vectormem);
-
-// Initialize the problem matrices. Well...they shouldn't only be
-// initialized but also contain the problem, so this is just an example
-// to get the definitions and types and everything right. 
-
-SparseMatrix<double> A;
-Vector<double> u,f;
-
-// Generate a Jacobi preconditioner with the damping parameter 1
-PreconditionSelector<SparseMatrix<double>, Vector<double> > preconditioning("jacobi",1.);
-
-// Use the matrix of the linear equation system for preconditioning
-// (this is the usual case).
-preconditioning.use_matrix(A);
-
-solver.solve(A,u,f,preconditioning);
-
-

- -

SolverGMRES

- -

This class implements the Restarted Preconditioned Direct Generalized -Minimal Residual Method. The stopping criterion is the norm of the residual. -It is initialized using
-SolverGMRES(SolverControl &cn, VectorMemory<Vector> &mem, -const AdditionalData &data=Additionaldata()) - -This constructor needs the maximum number of temporary vectors to be used. -A number too small can seriously affect its performance, but a number -too large will also increase the required computing time. This number is -contained in the AdditionalData structure with a default of 30. -This solver is rather special, and for a detailed explanation you should -take a look at the detailed description of the SolverGMRES -class. -

- -

-Example:We initialize a GMRES-solver for -the problem Au=f, using the solver control -explained above. A shall be a sparse matrix and the vectors -u and f shall be vectors of doubles. -Next, we solve the problem. We use the default number of thirty temporary -vectors. -

- -

-
-// Include files for solver control, solver and preconditioner
-#include <lac/solver_control.h>
-#include <lac/solver_gmres.h>
-#include <lac/precondition_selector.h>
-
-// Include files for matrices and vectors
-#include <lac/sparse_matrix.h>
-#include <lac/vector.h>
-
-// Initialize the solver control and the solver
-
-SolverControl control(1000,1e-6);
-VectorMemory<Vector<double> > vectormem;
-SolverGMRES<SparseMatrix<double>,Vector<double> > solver(control,vectormem);
-
-// Initialize the problem matrices. Well...they shouldn't only be
-// initialized but also contain the problem, so this is just an example
-// to get the definitions and types and everything right. 
-
-SparseMatrix<double> A;
-Vector<double> u,f;
-
-// Generate a Jacobi preconditioner with the damping parameter 1
-PreconditionSelector<SparseMatrix<double>, Vector<double> > preconditioning("jacobi",1.);
-
-// Use the matrix of the linear equation system for preconditioning
-// (this is the usual case).
-preconditioning.use_matrix(A);
-
-solver.solve(A,u,f,preconditioning);
-
-

- - -

SolverRichardson

- -

-This class implements the Richardson iteration method. The stopping criterion -is the norm of the residual. It is initialized using
-SolverRichardson(SolverControl &cn, VectorMemory<Vector> -&mem, const AdditionalData &data=Additionaldata()) - -The additional data for this solver is the damping, with a default of 1. -

- -

-Example:We initialize a Richardson-solver for -the problem Au=f, using the solver control -explained above. A shall be a sparse matrix and the vectors -u and f shall be vectors of doubles. Next, -we solve the problem. We use the default damping parameter of 1. -

- -

-
-// Include files for solver control, solver and preconditioner
-#include <lac/solver_control.h>
-#include <lac/solver_richardson.h>
-#include <lac/precondition_selector.h>
-
-// Include files for matrices and vectors
-#include <lac/sparse_matrix.h>
-#include <lac/vector.h>
-
-// Initialize the solver control and the solver
-
-SolverControl control(1000,1e-6);
-VectorMemory<Vector<double> > vectormem;
-SolverRichardson<SparseMatrix<double>,Vector<double> > solver(control,vectormem);
-
-// Initialize the problem matrices. Well...they shouldn't only be
-// initialized but also contain the problem, so this is just an example
-// to get the definitions and types and everything right. 
-
-SparseMatrix<double> A;
-Vector<double> u,f;
-
-// Generate a Jacobi preconditioner with the damping parameter 1
-PreconditionSelector<SparseMatrix<double>, Vector<double> > preconditioning("jacobi",1.);
-
-// Use the matrix of the linear equation system for preconditioning
-// (this is the usual case).
-preconditioning.use_matrix(A);
-
-solver.solve(A,u,f,preconditioning);
-
-

- - -

- - - - - - - -

- -

- - diff --git a/deal.II/doc/tutorial/chapter-1.elements/title.html b/deal.II/doc/tutorial/chapter-1.elements/title.html deleted file mode 100644 index 8b7984eda1..0000000000 --- a/deal.II/doc/tutorial/chapter-1.elements/title.html +++ /dev/null @@ -1,35 +0,0 @@ - - - - - -deal.II tutorial: Chapter title - - - - - - - - - - - -

-The deal.II tutorial - Chapter 1 - Elements of -finite element programs -

- - - - - - - - - - - diff --git a/deal.II/doc/tutorial/chapter-1.elements/toc.html b/deal.II/doc/tutorial/chapter-1.elements/toc.html deleted file mode 100644 index 878d50363b..0000000000 --- a/deal.II/doc/tutorial/chapter-1.elements/toc.html +++ /dev/null @@ -1,155 +0,0 @@ - - - -deal.II tutorial: Structure of a Finite Element Program - - - - - - - -

Basic Elements of a Finite Element Program

- -

About this tutorial

-This part of the deal.II documentation will discuss -some building blocks of a finite element program. We will take a look at the general -structure of programs of this kind and at the various possibilities -in that respect offered by deal.II. The order of -the table of contents below reflects the order in which -you need to perform the tasks. Some things may be left out according to -your needs. The application in actual programs can be found in other -chapters of this tutorial. -

- -

-
- Creation of a grid -
-
dealing with grid creation, grid input from a file and grid - refinement. - The various kinds of grid are also discussed. -
-
-
- Degrees of Freedom -
-
where degrees of freedom are distributed and numbered.
-
-
- Hanging Nodes -
-
where locally refined grids are discussed.
-
-
- Matrix Structure -
-
where efficient structures for sparse matrices are discussed.
-
-
- Matrix and Vector Generation -
-
where the different kinds of matrices and vectors are discussed.
-
-
- The Problem Matrix and the Right Hand Side -
-
which shows how to implement a particular problem.
-
-
- Boundary Conditions -
-
which shows how to set boundary conditions in deal.II.
-
-
- Condensing the Hanging Nodes -
-
which shows how, when and why to condense hanging nodes.
-
-
- Solving the Problem -
-
explaining the different solvers available and how to use them.
-
-
- Postprocessing -
-
where the data is postprocessed and stored and the error - is calculated. -
-
-
- Error Estimate and Adaptivity -
-
explaining how to use adaptive refinement with error estimates.
-
-
- Parameter Input -
-
explaining how to use a parameter file for configuring - your program. -
-
-
- Grid and Data Output -
-
explaining how to get output of your data, with an emphasis on - different graphic formats. -
-

- -

- - - - - - - -

- -

- - - - - - - diff --git a/deal.II/doc/tutorial/chapter-2.step-by-step/navbar.html b/deal.II/doc/tutorial/chapter-2.step-by-step/navbar.html index 370be4a69f..fc10c5610c 100644 --- a/deal.II/doc/tutorial/chapter-2.step-by-step/navbar.html +++ b/deal.II/doc/tutorial/chapter-2.step-by-step/navbar.html @@ -83,10 +83,6 @@

Back to the deal.II homepage

diff --git a/deal.II/doc/tutorial/chapter-2.step-by-step/toc.html b/deal.II/doc/tutorial/chapter-2.step-by-step/toc.html index 2cfcf3184c..73607e961a 100644 --- a/deal.II/doc/tutorial/chapter-2.step-by-step/toc.html +++ b/deal.II/doc/tutorial/chapter-2.step-by-step/toc.html @@ -153,14 +153,6 @@ At present, the following programs exist:

- - - - - -

diff --git a/deal.II/doc/tutorial/chapter-3.laplace/Makefile b/deal.II/doc/tutorial/chapter-3.laplace/Makefile deleted file mode 100644 index 9d7bf2c49c..0000000000 --- a/deal.II/doc/tutorial/chapter-3.laplace/Makefile +++ /dev/null @@ -1,12 +0,0 @@ -# $Id$ - - -# include paths and global variables -include ../../../common/Make.global_options - - -validate-xrefs: - $(PERL) $D/doc/auto/scripts/validate-xrefs.pl *.html - - -.PHONY: validate-xrefs diff --git a/deal.II/doc/tutorial/chapter-3.laplace/assemble.html b/deal.II/doc/tutorial/chapter-3.laplace/assemble.html deleted file mode 100644 index 504de98af3..0000000000 --- a/deal.II/doc/tutorial/chapter-3.laplace/assemble.html +++ /dev/null @@ -1,275 +0,0 @@ - - - - deal.II tutorial: the Laplace problem - - - - - - - - -

Assembling the problem

- -

What's to be done

-In order to assemble the matrices we basically need to: -

Generate the matrices, i.e. call the deal.II - functions that reserve storage space for us. -
-Calculate the finite element trial functions -
-Traverse all existing cells and integrate the problem -using the discretized Laplace operator -
-Insert the local matrices we have used into the global matrix using the -appropriate deal.II functions -
-Traverse all the cell faces and set the appropriate boundary conditions -

- -

...and how to do it

- -

Generating the matrix structures

- -

-First we generate a structure for the storage of a sparse n times n matrix -where n is the number of the degrees of freedom. -The parameter max_couplings_between_dofs() returns the maximum -number of couplings between degrees of freedom, i.e. the number of elements in the -matrix and allows deal.II to generate the matrix structure more -efficiently, which in effect is done in the next line of code. -

-Afterwards a constraint matrix for the hanging nodes is created and they -are copied into the matrix structure. -

-
-  matrix_structure.reinit(dof.n_dofs(),dof.n_dofs(),
-			  dof.max_couplings_between_dofs());
-  dof.make_sparsity_pattern(matrix_structure);
-  hanging_nodes.clear();
-  dof.make_constraint_matrix(hanging_nodes);
-  hanging_nodes.condense(matrix_structure);
-
-

-The problem is of the form Au=f, we generate the matrix A with the -structure given by matrix_structure: -

-
-  A.reinit(matrix_structure);
-  f.reinit(dof.n_dofs());
-
-

- -

Calculating finite element trial functions

-The two lines below calculate trial functions for the finite elements and -for their faces using Gaussian quadrature. The first line calculates the trial -function for the finite element associated with the degree of freedom dof -updating the values of the gradients and of the Jacobi determinant multiplied by a -weight function given by the quadrature qc. -

-
-  FEValues<dim> fevalues(dof->get_fe(), qc, UpdateFlags(update_gradients |
-						   update_JxW_values));
-  FEFaceValues<dim> ffvalues(dof->get_fe(), qf,
-			   UpdateFlags(update_JxW_values | update_q_points));
-
-

- -

Integrating the problem

-Integration is done locally. Therefore we need appropriate definitions for -

-an index vector that will allow us to reassemble the global matrix later on -
a vector of doubles with the dimension of the number of degrees of freedom per cell -
and a square matrix of doubles with the same dimension

- -

-
-  vector<int> indices(fe.total_dofs);
-  dVector elvec(fe.total_dofs);
-  
-  dFMatrix elmat(fe.total_dofs);
-
-

-Next we traverse all the cells and integrate the Laplace problem using the -discretized Laplace operator. qc is a -Quadrature<dim>. -

-The outer loop traverses all the points of the quadrature qc. -The inner two loops traverse the degrees of freedom of the finite element -fe where du and dv are the gradients -with respect to the quadrature points. fevalues.JxW(k) gives -the Jacobi determinant multiplied by the weight of the quadrature point -k. Taken together the line
--elmat(i,j) += fevalues.JxW(k) * du * dv; - -
-gives the discretized Laplace operator. -

- -

-
-  for (DoFHandler<2>::active_cell_iterator c = dof.begin_active()
-					; c != dof.end() ; ++c)
-  {
-    fevalues.reinit(c, stb);
-    elmat.clear();
-    elvec.clear();
-    c->get_dofindices(indices);
-    
-    for (unsigned k=0;k<qc.n_quadrature_points;++k)
-    {
-      for (unsigned i=0;i<fe.total_dofs;++i)
-      {
-	const Point<2> dv = fevalues.shape_grad(i,k);
-	
-	for (unsigned j=0;j<fe.total_dofs;++j)
-	{
-	  const Point<2> du = fevalues.shape_grad(j,k);
-	  
-	  elmat(i,j) += fevalues.JxW(k)
-			* du * dv
-			;
-	  
-	}
-      }
-    }
-
-

-The insertion of the local matrix into the global one -happens in the following piece of code (f is the right hand -vector of the problem, A the problem matrix): -

-
-    for (unsigned i=0;i<fe.total_dofs;++i)
-    {
-      f(indices[i]) += elvec(i);
-            
-      for (unsigned j=0;j<fe.total_dofs;++j)
-      {
-	A.add(indices[i], indices[j], elmat(i,j));
-      }
-    }
-
-

- -

Setting boundary conditions

- -

-There are two deal.II functions relevant for us at the moment: -

-
-void VectorTools::interpolate_boundary_values(...)
-
-

-which does exactly what it says. This function accepts a list of pairs -of boundary indicators and the according functions and returns a list of -pairs of DoF numbers and values denoting the respective -Dirichlet boundary values. -

-This output is used by -

-
-void MatrixTools::apply_boundary_values(...)
-
-

-that inserts the proper boundary conditions into the system of equations: -


-  map<int,double> boundary_values;
-  DoFHandler<2>::FunctionMap dirichlet_bc;
-  BoundaryFct bfct;
-  dirichlet_bc[0]=&bfct;
-  VectorTools<2>::interpolate_boundary_values(dof,dirichlet_bc,fe,boundary,boundary_values);
-  u.reinit(f);
-  MatrixTools<2>::apply_boundary_values(boundary_values,A,u,f);  
-

-First, we need a few definitions: -

-boundary_values maps DoF indices at the boundary computed by interpolate_boundary_values to their respective values. -
dirichlet_bc maps boundary indicators to boundary functions, supplied by us. All boundary indicators are zero by default, therefore the -above statement maps the same function to all the boundaries. The boundary functions compute the boundary values. -
bfct is a function returning cos(2*PI*x)*sin(2*PI*y) -, thereby supplying boundary values. -

-This may seem a bit confusing. What actually happens is the following: -

interpolate_boundary_values takes the boundary functions -bfct, its relation to boundaries dirichlet_bc and -the triangulation dof, fe and returns a -mapping boundary_values that maps values instead of functions -to our boundaries. The function looks at all the boundaries. All we -ever need to do is specify the initial triangulation. -
apply_boundary_values subsequently takes that mapping and -our system of equations Au=f and inserts the boundary values into -the system of equations which can then be solved. -

- - -

- - - - - - - - - -

-Last modified: $Date$ -

- - - - - - - diff --git a/deal.II/doc/tutorial/chapter-3.laplace/code/Makefile b/deal.II/doc/tutorial/chapter-3.laplace/code/Makefile deleted file mode 100644 index 637ab68aef..0000000000 --- a/deal.II/doc/tutorial/chapter-3.laplace/code/Makefile +++ /dev/null @@ -1,152 +0,0 @@ -# $Id$ -# Author: Wolfgang Bangerth, 1998 - -root = ../../../../ - -vpath %.a $(root)/deal.II/lib -vpath %.a $(root)/lac/lib -vpath %.a $(root)/base/lib - -# Template for makefiles for the examples subdirectory. In principle, -# everything should be done automatically if you set the target file -# here correctly: -target = laplace - -# All dependencies between files should be updated by the included -# file Makefile.dep if necessary. Object files are compiled into -# the archives ./Obj.a and ./Obj.g.a. By default, the debug version -# is used to link. It you don't like that, change the following -# variable to "off" -debug-mode = on - -# If you want your program to be linked with extra object or library -# files, specify them here: -user-libs = - -# To run the program, use "make run"; to give parameters to the program, -# give the parameters to the following variable: -run-parameters = 60 4 - -# To execute additional action apart from running the program, fill -# in this list: -#additional-run-action = - -# To specify which files are to be deleted by "make clean" (apart from -# the usual ones: object files, executables, backups, etc), fill in the -# following list -delete-files = gnuplot* *.eps - -deal_II_dimension=2 - - -############################################################################### -# Internals - -INCLUDE=-I$(root)/deal.II/include -I$(root)/lac/include -I$(root)/base/include - -CXXFLAGS.g= -DDEBUG -g -Wall -W -pedantic -Wconversion \ - -Winline -Woverloaded-virtual \ - $(INCLUDE) -Ddeal_II_dimension=$(deal_II_dimension) -CXXFLAGS =-O3 -Wuninitialized -finline-functions -ffast-math \ - -felide-constructors -fnonnull-objects \ - $(INCLUDE) \ - -Ddeal_II_dimension=$(deal_II_dimension) - -ifeq ($(shell uname),Linux) -CXX = g++ -endif - -ifeq ($(shell uname),SunOS) -CXX = g++ -endif - - -%.go : %.cc #Makefile - @echo ============================ Compiling with debugging information: $< - @echo $(CXX) ... -c $< -o $@ - @$(CXX) $(CXXFLAGS.g) -c $< -o $@ -%.o : %.cc #Makefile - @echo ============================ Compiling with optimization: $< - @echo $(CXX) ... -c $< -o $@ - @$(CXX) $(CXXFLAGS) -c $< -o $@ - - -# get lists of files we need -cc-files = $(wildcard *.cc) -o-files = $(cc-files:.cc=.o) -go-files = $(cc-files:.cc=.go) -h-files = $(wildcard *.h) -lib-h-files = $(wildcard $(root)/deal.II/include/*/*.h) - -# list of libraries needed to link with -libs = ./Obj.a $(wildcard $(root)/deal.II/lib/lib*2d.a) $(root)/lac/lib/liblac.a -libs.g = ./Obj.g.a $(wildcard $(root)/deal.II/lib/lib*2d.g.a) $(root)/lac/lib/liblac.a $(root)/base/lib/libbase.g.a - -#$(root)/deal.II/lib/deal_II_2d.g -llac.g -lbase.g#-lbasic.g -lfe.g -lgrid.g -lbasic.g -llac.g - - -# check whether we use debug mode or not -ifeq ($(debug-mode),on) -libraries = $(libs.g) -flags = $(CXXFLAGS.g) -endif - -ifeq ($(debug-mode),off) -libraries = $(libs) -flags = $(CXXFLAGS) -endif - - - -# make rule for the target -$(target) : $(libraries) $(user-libs) - @echo ============================ Linking $@ - $(CXX) $(flags) -o $@ $^ - -# rule how to run the program -run: $(target) - $(target) $(run-parameters) - $(additional-run-action) - - -# rule to make object files -%.go : %.cc - @echo ============================ Compiling with debugging information: $< - @echo $(CXX) ... -c $< -o $@ - @$(CXX) $(CXXFLAGS.g) -c $< -o $@ -%.o : %.cc - @echo ============================ Compiling with optimization: $< - @echo $(CXX) ... -c $< -o $@ - @$(CXX) $(CXXFLAGS) -c $< -o $@ - - -# rules which files the libraries depend upon -Obj.a: ./Obj.a($(o-files)) -Obj.g.a: ./Obj.g.a($(go-files)) - - -clean: - rm -f *.o *.go *~ Makefile.dep Obj.a Obj.g.a $(target) $(delete-files) - - - -.PHONY: clean - - -#Rule to generate the dependency file. This file is -#automagically remade whenever needed, i.e. whenever -#one of the cc-/h-files changed. Make detects whether -#to remake this file upon inclusion at the bottom -#of this file. -# -#use perl to generate rules for the .go files as well -#as to make rules not for tria.o and the like, but -#rather for libnumerics.a(tria.o) -Makefile.dep: $(cc-files) $(h-files) $(lib-h-files) - @echo ============================ Remaking Makefile - @$(PERL) $(root)/deal.II/Make_dep.pl ./Obj $(INCLUDE) $(cc-files) \ - > Makefile.dep - - -include Makefile.dep - diff --git a/deal.II/doc/tutorial/chapter-3.laplace/code/func.cc b/deal.II/doc/tutorial/chapter-3.laplace/code/func.cc deleted file mode 100644 index 8a739c6b2e..0000000000 --- a/deal.II/doc/tutorial/chapter-3.laplace/code/func.cc +++ /dev/null @@ -1,14 +0,0 @@ -// $Id$ - -const char* funcversion = "Functions: $Revision$"; - -#include "functions.h" - -#include - - -double -BoundaryFct::operator ()(const Point<2> &p) const -{ - return cos(2*M_PI*p(0))*cos(2*M_PI*p(1)); -} diff --git a/deal.II/doc/tutorial/chapter-3.laplace/code/functions.h b/deal.II/doc/tutorial/chapter-3.laplace/code/functions.h deleted file mode 100644 index 9b888fd69e..0000000000 --- a/deal.II/doc/tutorial/chapter-3.laplace/code/functions.h +++ /dev/null @@ -1,12 +0,0 @@ -// $Id$ - - -#include - -class BoundaryFct - : public Function<2> -{ - public: - virtual double operator()(const Point<2> &p) const; -}; - diff --git a/deal.II/doc/tutorial/chapter-3.laplace/code/laplace.cc b/deal.II/doc/tutorial/chapter-3.laplace/code/laplace.cc deleted file mode 100644 index 98c93d8fa2..0000000000 --- a/deal.II/doc/tutorial/chapter-3.laplace/code/laplace.cc +++ /dev/null @@ -1,195 +0,0 @@ -// $Id$ - -const char* laplaceversion = "Laplace: $Revision$"; - -#include "laplace.h" -#include "functions.h" - -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include - -#include -#include -#include - -#define PRIMEL FELinear<2> - -// Finite Elements - -static PRIMEL fe; - -// Quadrature formulae - -static QGauss2<2> qc; -static QGauss2<1> qf; -static QGauss5<2> qc_integrate; -static QGauss5<1> qf_integrate; - -StraightBoundary<2> stb; - -Laplace::Laplace() - : dof(&tr) -{ - // Generate the initial triangulation - tr.create_hypercube(-1.,1.); - - // Distribute the degrees of freedom - dof.distribute_dofs(fe); - } - -Laplace::~Laplace() -{} - - -// Remesh the grid -void -Laplace::remesh(unsigned int steps) -{ - if (tr.n_levels() <= 1) - { - tr.refine_global(1); // refine globally - } - - if (steps) - tr.refine_global(steps); - else - tr.execute_coarsening_and_refinement(); // refine locally - - // redistribute the degrees of freedom... - dof.distribute_dofs(fe); - // ...and renumber them so they can be used more efficiently - dof.renumber_dofs(Cuthill_McKee); -} - -// JS.Primales Problem zusammenstellen. -void -Laplace::assemble() -{ - // Initialize the problem matrix, i.e. reserve storage space - matrix_structure.reinit(dof.n_dofs(),dof.n_dofs(), - dof.max_couplings_between_dofs()); - // Generate the matrix structure - dof.make_sparsity_pattern(matrix_structure); - hanging_nodes.clear(); - dof.make_constraint_matrix(hanging_nodes); - hanging_nodes.condense(matrix_structure); - matrix_structure.compress(); - - // The problem has the form Au=f. - A.reinit(matrix_structure); - f.reinit(dof.n_dofs()); - - // Calculate the trial functions on the cell faces. - FEValues<2> fevalues(fe, qc, UpdateFlags(update_gradients | - update_JxW_values)); - FEFaceValues<2> ffvalues(fe, qf, - UpdateFlags(update_JxW_values | update_q_points)); - - // Integrate the problem locally... - vector indices(fe.total_dofs); - Vector elvec(fe.total_dofs); - - FullMatrix elmat(fe.total_dofs); - - for (DoFHandler<2>::active_cell_iterator c = dof.begin_active() - ; c != dof.end() ; ++c) - { - fevalues.reinit(c, stb); - elmat.clear(); - elvec.clear(); - c->get_dof_indices(indices); - - for (unsigned k=0;k dv = fevalues.shape_grad(i,k); - - - for (unsigned j=0;j du = fevalues.shape_grad(j,k); - - elmat(i,j) += fevalues.JxW(k) - * du * dv - ; - - } - } - } - // ...and insert the local matrix into the global one. - for (unsigned i=0;i boundary_values; - DoFHandler<2>::FunctionMap dirichlet_bc; - BoundaryFct bfct; - dirichlet_bc[0]=&bfct; - VectorTools<2>::interpolate_boundary_values(dof,dirichlet_bc, - fe,boundary, - boundary_values); - u.reinit(f); - MatrixTools<2>::apply_boundary_values(boundary_values,A,u,f); -} - -// Solve the primal problem. -void -Laplace::solve() -{ - // Solver control: max 1000 iterations, threshold 1e-10 - SolverControl control(1000, 1.e-10); - // Define the solver. - SolverCG> solver(control, mem); - - solver.solve(A,u,f); - - hanging_nodes.distribute(u); -} - - -// Data output for gnuplot. -void Laplace::write_data(const char* name) -{ - - DataOut<2> out; - char fname[100]; - { - ofstream gnuplot(fname); - - out.clear_data_vectors(); - out.attach_dof_handler(dof); - out.add_data_vector(u,"solution","kg"); - - out.write_gnuplot (gnuplot, 1); - gnuplot.close (); - } - -} - - - - diff --git a/deal.II/doc/tutorial/chapter-3.laplace/code/laplace.h b/deal.II/doc/tutorial/chapter-3.laplace/code/laplace.h deleted file mode 100644 index 1e93cedfb4..0000000000 --- a/deal.II/doc/tutorial/chapter-3.laplace/code/laplace.h +++ /dev/null @@ -1,54 +0,0 @@ -// $Id$ - -#include -#include -#include -#include -#include -#include -#include -#include -#include - -class AdvMatrix : - public SparseMatrix -{ -public: - void precondition(Vector& dst, const Vector& src) const - { - SparseMatrix::precondition_SSOR(dst, src); - } -}; - - -class Laplace -{ -protected: -// Point<2> direction; - Triangulation<2> tr; - DoFHandler<2> dof; - - SparsityPattern matrix_structure; - AdvMatrix A; - - Vector u; - Vector z; - Vector f; - - PrimitiveVectorMemory mem; - - ConstraintMatrix hanging_nodes; - - StraightBoundary<2> boundary; - -public: - Laplace(); - ~Laplace(); - - void remesh(unsigned int global_refine = 0); - void assemble(); - void solve(); - - void write_data(const char* name); -}; - diff --git a/deal.II/doc/tutorial/chapter-3.laplace/code/main.cc b/deal.II/doc/tutorial/chapter-3.laplace/code/main.cc deleted file mode 100644 index 76eb23f5eb..0000000000 --- a/deal.II/doc/tutorial/chapter-3.laplace/code/main.cc +++ /dev/null @@ -1,42 +0,0 @@ -// $Id$ - -#include "laplace.h" -#include "functions.h" - -#include -#include -#include - -char fname[30]; - -main(int argc, char** argv) -{ - if (argc==1) - cerr << "Usage: " << argv[0] << "firstgrid\nUsing 3" - << endl; - - int firstgrid = 3; - - if (argc>=2) firstgrid = atoi(argv[1]); - - Laplace lap; - - for (unsigned step = 0; step < 3 ; ++step) - { - // Generate a refined grid. - if (!step) - lap.remesh(firstgrid); - else - { - lap.remesh(1); - } - - - // Assemble and solve the problem. - lap.assemble(); - lap.solve(); - - // Data output. - lap.write_data(fname); - } -} diff --git a/deal.II/doc/tutorial/chapter-3.laplace/index.html b/deal.II/doc/tutorial/chapter-3.laplace/index.html deleted file mode 100644 index 56ffc7022a..0000000000 --- a/deal.II/doc/tutorial/chapter-3.laplace/index.html +++ /dev/null @@ -1,34 +0,0 @@ - - - -deal.II tutorial: The Laplace Problem - - - - - - - - - - - - - - - - - -<h1>The deal.II Tutorial</h1> -Your browser does not seem to understand frames. A version of this -tutorial that does not use frames can be found at -<a href="toc.html">http://www.dealii.org/doc/tutorial/chapter-3.laplace/toc.html</a>. - - - - - - - - diff --git a/deal.II/doc/tutorial/chapter-3.laplace/laplace.html b/deal.II/doc/tutorial/chapter-3.laplace/laplace.html deleted file mode 100644 index bfa2be2b1b..0000000000 --- a/deal.II/doc/tutorial/chapter-3.laplace/laplace.html +++ /dev/null @@ -1,91 +0,0 @@ - - - - deal.II tutorial: the Laplace problem - - - - - - -

The class Laplace

-The class Laplace contains most of the code we need to actually solve the problem at -hand. The purpose of this chapter is to establish the elements that are needed for this class -or any one like it. -

- -

-Let's have a look at the class definition: -

-
-class Laplace
-{
-
-  Triangulation<2> tr;
-  DoFHandler<2> dof;
-
-  SparsityPattern matrix_structure;
-  LapMatrix A;
-
-  ConstraintMatrix hanging_nodes;
-
-
-

-These few lines define several important elements: The triangulation tr, i.e. the grid, and a handler for the degrees -of freedom for the finite elements dof, all for the two-dimensional case. -In addition one matrix structure and two matrices are defined (the matrix A defining our problem). Further explanation can be found in the -chapter Assembling the problem. Note that -in order to solve any problem at all with deal.II the definitions above are paramount. -

- -

-The next bit are the functions actually called by our program, the working part, so to say. -The constructor has the task of generating a triangulation, too. -

-
-public:
-  Laplace();
-  ~Laplace();
-
-

-The next few functions refine the grid - non-adaptively - assemble the problem and -call the appropriate solver. -

-
-  void remesh(unsigned int global_refine = 0);
-  void assemble();
-  void solve();
-};
-
-

- -

- - - - - - - - - -

- -

-Assembling the problem matrix -

- - -

-Last modified: $Date$ -

- - diff --git a/deal.II/doc/tutorial/chapter-3.laplace/main.html b/deal.II/doc/tutorial/chapter-3.laplace/main.html deleted file mode 100644 index 901eb16af5..0000000000 --- a/deal.II/doc/tutorial/chapter-3.laplace/main.html +++ /dev/null @@ -1,137 +0,0 @@ - - - - deal.II tutorial: the Laplace problem - - - - - - - -

The Laplace Problem

- -

Main Program: main.cc

-The main program has several functions: -

- -

Inclusion of the necessary headers and variable - definitions. -
- Instantiation of the C++ class Laplace - dealing with the problem. -
Calling the Laplace methods for assemblage and solution of the - problem. -
- Writing out of the output data and termination. -

- -

-We shall look at this in detail now: -

- -

Program Header and Definitions

- -

-First the header files containing the Laplace class definition and -the function definition for our solution function are included: -

- -

-
-#include "laplace.h"
-#include "functions.h"
-
-

- -

-Our main program starts here. It will take the initial number of global grid -refinements as its argument. That means that the number 3 as argument will -lead to the initial grid being globally refined three times, no questions -asked. -

- -

-
-main(int argc, char** argv) 
-{
-
-

Instantiation of needed classes

-We need a solution function and an instance of the class dealing with the -Laplace problem: -

- -

-
-Laplace lap;
-
-

- -

-In addition we need to do some refinement (the command line argument was -previously stored in the variable firstgrid. During the first -execution -of the loop global refinement is done firstgrid times, every -following time it is done once more. -


-for (unsigned step = 0; step < 3 ; ++step)   
-{     
-  
-  if (step == 0) 
-     lap.remesh(firstgrid);
-  else
-  {
-     lap.remesh(1);
-  }
-

- -

Problem assemblage and solution

-Our class assembles and solves the primal problem. -


-  lap.assemble(); 
-  lap.solve();          
-

- -

Data output

-Finally the solution is written to a file.

-
-  lap.write_data(fname);   
- }   
-}
-

- - - - - - - - -

- The deal.II group

-Last modified: $Date$ -

- - - diff --git a/deal.II/doc/tutorial/chapter-3.laplace/navbar.html b/deal.II/doc/tutorial/chapter-3.laplace/navbar.html deleted file mode 100644 index 45f6d02464..0000000000 --- a/deal.II/doc/tutorial/chapter-3.laplace/navbar.html +++ /dev/null @@ -1,74 +0,0 @@ - - - -deal.II tutorial: The Laplace Problem - - - - - - - -Table of contents
- -

-Long table of contents -

-Program structure -

-The main program -

-The class Laplace -

-Generating a triangulation -

-Solving the problem -

-The source code -

- - -

- Comments on the tutorial -

- - - - - - - - - - diff --git a/deal.II/doc/tutorial/chapter-3.laplace/solution.html b/deal.II/doc/tutorial/chapter-3.laplace/solution.html deleted file mode 100644 index 3c203006bc..0000000000 --- a/deal.II/doc/tutorial/chapter-3.laplace/solution.html +++ /dev/null @@ -1,57 +0,0 @@ - - - - deal.II tutorial: the Laplace problem - - - - - - -

Solving the problem

- -

-Now that the problem matrix is assembled we need to define an appropriate -solver. In this case we use a CG-solver with a maximum of 1000 -iterations and a threshold of 1e-10. -

- -


-void
-Laplace::solve()
-{
-
-  SolverControl control(1000, 1.e-10);
-
-  SolverCG<AdvMatrix, Vector<double> > solver(control, mem);
-  
-  solver.solve(A,u,f);
-  
-  hanging_nodes.distribute(u);
-
-}
-

- -

- - - - - - - - - -

- -

-Last modified: $Date$ -

- - diff --git a/deal.II/doc/tutorial/chapter-3.laplace/source.html b/deal.II/doc/tutorial/chapter-3.laplace/source.html deleted file mode 100644 index ee54faffaf..0000000000 --- a/deal.II/doc/tutorial/chapter-3.laplace/source.html +++ /dev/null @@ -1,64 +0,0 @@ - - - -deal.II tutorial: The Laplace Problem - - - - - - -

The Source Code for the Solution of the Laplace Problem

- -

Warning: This source code is outdated and does not -compile with newer versions of deal.II. We will provide -an up-to-date version when deal.II gets more stable -(in terms of backwards-compatibility). - -

- -

-You can have a look at the complete source code for the solution of the -Laplace problem by following the links below: -

main.cc containing the main program which - sets some parameters and starts the solution process.
-
laplace.h and - laplace.cc which define the class - Laplace that assembles the laplace problem.
-
functions.h and - func.cc which define the function that sets - the boundary conditions.
-
Makefile. Last but not least. You will - probably need to edit the variable root defined at the - top of the Makefile. This variable defines the location of your - DEAL directory.
-

- -

- - - - - - - - -

-Last modified: $Date$ -

- - diff --git a/deal.II/doc/tutorial/chapter-3.laplace/structure.html b/deal.II/doc/tutorial/chapter-3.laplace/structure.html deleted file mode 100644 index 1c5efb9b6e..0000000000 --- a/deal.II/doc/tutorial/chapter-3.laplace/structure.html +++ /dev/null @@ -1,66 +0,0 @@ - - - - deal.II tutorial: the Laplace problem - - - - - -

Program structure

- In order to solve our differential equation we have to deal with the - the following tasks: -

Grid generation -
Assembly of the problem matrix -
Description of the boundary conditions -
Solution of the equation system -

- All these tasks are problem specific, therefore we will put them into - a class called Laplace. - The main program - will - for now - do nothing but call the methods of this class in their - proper order. -

- We end up with a program consisting of two major components: -

a main program that starts the process of problem - generation and solution by calling methods of -
the class Laplace that contains all the parts specific - to the problem at hand -

- - -

- - - - - - - - - -

- -

-Last modified: $Date$ -

- - diff --git a/deal.II/doc/tutorial/chapter-3.laplace/title.html b/deal.II/doc/tutorial/chapter-3.laplace/title.html deleted file mode 100644 index c52e18955e..0000000000 --- a/deal.II/doc/tutorial/chapter-3.laplace/title.html +++ /dev/null @@ -1,25 +0,0 @@ - - - - - - - - - - - - - - - - -

The deal.II tutorial - Chapter 3 - The Laplace Problem

- - - - - diff --git a/deal.II/doc/tutorial/chapter-3.laplace/toc.html b/deal.II/doc/tutorial/chapter-3.laplace/toc.html deleted file mode 100644 index 3e16a18e95..0000000000 --- a/deal.II/doc/tutorial/chapter-3.laplace/toc.html +++ /dev/null @@ -1,102 +0,0 @@ - - - -deal.II tutorial: The Laplace Problem - - - - - - - -

The Laplace Problem

-We will start with a simple example for a differential equation to be solved -with deal.II: the Laplace problem. We will try to solve the -Laplace equation on a square where one of the four boundaries has a constant -and the other three zero potential.

-In order to solve this problem we will need to:

-generate a triangulation, i.e. describe the grid on which the equation will be -solved -
-assemble the problem matrix, i.e. generate the matrix structure describing the -laplace problem -
-assemble matrices describing the boundary conditions -
-let deal.II solve the problem -
-take care of the data output -

-This tutorial will accordingly be split into several chapters:

-Program structure -
-where the overall design of the program and its classes are discussed
-
-The main program -
-where we take a look at how deal.II is used
-
-The class Laplace -
-where some of the details of the problem generation and solution are -discussed
-
-Generating a triangulation -
where a triangulation is generated and degrees of freedom are discussed
-
-Assembling the problem matrix -
-where the matrices describing the problem is assembled -and the boundary conditions are set -
-
-Solving the problem -
-where the problem is solved -
-
-The source code -
-contains link to all the source files. -
-

- - -

-Last modified: $Date$ -

- - - - - - - diff --git a/deal.II/doc/tutorial/chapter-3.laplace/triangulation.html b/deal.II/doc/tutorial/chapter-3.laplace/triangulation.html deleted file mode 100644 index 9f15faf518..0000000000 --- a/deal.II/doc/tutorial/chapter-3.laplace/triangulation.html +++ /dev/null @@ -1,67 +0,0 @@ - - - - deal.II tutorial: the Laplace problem - - - - - - -

Generating a triangulation

- -

-The initial triangulation is generated by the constructor of the class Laplace. -It is a hypercube with the coordinates along each axis ranging from -1 to 1. This first -triangulation consists of only one finite element. -

-
-Laplace::Laplace(Function<2>& solution)		
-{
-  tr.create_hypercube(-1.,1.);
-
-

- - -

-Afterwards all the degrees of freedom, i.e. all the cell vertices, are renumbered. -This step is necessary whenever the triangulation has changed, e.g. after each refinement. -

-
-  dof_primal.distribute_dofs(fe_primal);
- }
-
-

- -

- - - - - - - - - -

- -

- - Elements of finite element programs (Reference) - -

- -

-Last modified: $Date$ -

- - - - - - - - diff --git a/deal.II/doc/tutorial/index.html b/deal.II/doc/tutorial/index.html deleted file mode 100644 index adac1033ab..0000000000 --- a/deal.II/doc/tutorial/index.html +++ /dev/null @@ -1,29 +0,0 @@ - - - -deal.II tutorial: Elements of finite element programs - - - - - - - - - - - - - - - - - -<h1>The deal.II Tutorial</h1> -Your browser does not seem to understand frames. A version of this -page that does not use frames can be found at -<a href="toc.html">toc.html</a>. - - - diff --git a/deal.II/doc/tutorial/navbar.html b/deal.II/doc/tutorial/navbar.html deleted file mode 100644 index ebcc68ed54..0000000000 --- a/deal.II/doc/tutorial/navbar.html +++ /dev/null @@ -1,45 +0,0 @@ - - - -deal.II tutorial: Structure of a Finite Element Program - - - - - - - -

- Long table of contents -

- -

- - Step-by-step examples - -

- -

- -

- Back to the deal.II homepage -

- - -

- The deal.II mailing list -

- - - - - diff --git a/deal.II/doc/tutorial/scripts/filelist.pl b/deal.II/doc/tutorial/scripts/filelist.pl deleted file mode 100755 index 701fa46b27..0000000000 --- a/deal.II/doc/tutorial/scripts/filelist.pl +++ /dev/null @@ -1,66 +0,0 @@ -#!/usr/local/bin/perl - -# Takes table title as argument, traverses the files in . -# and writes to STDOUT a list of all files -# as a TeX-table, with modification date and revision number. -# Jan Schrage and others 1999 - -use File::Find; -use File::stat; -use Time::localtime; - -unless ($ARGV[0]) { $ttitle="{\tt deal.II} tutorial"; } -else { $ttitle=$ARGV[0];} - -@ignore=("CVS","/#.*#",".*~","^[./]*\$","\.#"); - -tablehead($ttitle); -find(\&process,"."); -tablefoot(); - -sub process { - local ($what=""); - local ($last_rev,$rev,$line,@parts,@cvsout); - - $what=$File::Find::dir."/".$_; - - foreach $i (@ignore) { - if ($what =~ $i) {return;} - } - - @cvsout=`cvs status $what`; - - $last_rev=ctime(stat($what)->mtime); - - - while ($line=shift(@cvsout)) - { - if ($line =~ "Working revision:" ) - { - @parts=split(/:\w*/,$line); - $rev=@parts[1]; - - print $what." &".$last_rev." &".$rev; - } - } - -} - -sub tablehead { - local ($what=$_); - - print -"%% Table compiled by filelist.pl -%% Jan Schrage 1999 -\\begin{table} -\\caption{Directory listing of $ttitle} -\\begin{tabular}[l r r] -File & Last change & Revision number \\\\ -\\hrule \n"; -} - - -sub tablefoot { - print "\\end{table} \n"; -} - diff --git a/deal.II/doc/tutorial/scripts/validate b/deal.II/doc/tutorial/scripts/validate deleted file mode 100755 index 5741b951a1..0000000000 --- a/deal.II/doc/tutorial/scripts/validate +++ /dev/null @@ -1,17 +0,0 @@ -#!/bin/sh - -# For HTML validation. Use as validate . -# nsgmls can at the time of this writing not handle URLS. Therefore we have -# to filter out the references to the DTDs. Unfortunately this means not -# all valid entities will be recognized. Errors regarding undefined -# entities can therefore most likely be ignored. -# -# Oh...and you might have to set the path to the DTD. This is just a -# quick hack anyway. -# -# Jan Schrage and others 1999 -# $Id$ - - -echo Validating $1 -cat $1 | sed -e 's/http:\/\/www.w3.org\/TR\/REC-html40\/strict.dtd//' -e 's/\"\"//' | nsgmls -s -m /home/people/schrage/lib/sgml/pubtext/HTML4.soc diff --git a/deal.II/doc/tutorial/templates/body.html b/deal.II/doc/tutorial/templates/body.html deleted file mode 100644 index defe52bff5..0000000000 --- a/deal.II/doc/tutorial/templates/body.html +++ /dev/null @@ -1,43 +0,0 @@ - - - - - -deal.II tutorial: INSERT_title - - - - - - - - - -

INSERT_title

- - -

- - - - - - - -

-INSERT_your_name

-Last modified: $Date$ -

- - diff --git a/deal.II/doc/tutorial/templates/example.html b/deal.II/doc/tutorial/templates/example.html deleted file mode 100644 index 5e26d87db8..0000000000 --- a/deal.II/doc/tutorial/templates/example.html +++ /dev/null @@ -1,8 +0,0 @@ -

-Example: -

- -

-
-
-

diff --git a/deal.II/doc/tutorial/templates/index.html b/deal.II/doc/tutorial/templates/index.html deleted file mode 100644 index e026910476..0000000000 --- a/deal.II/doc/tutorial/templates/index.html +++ /dev/null @@ -1,38 +0,0 @@ - - - - - -deal.II tutorial: INSERT_title - - - - - - - - - - - - - - - - - -<h1>The deal.II Tutorial</h1> -Your browser does not seem to understand frames. A version of this -tutorial that does not use frames can be found at -<a href="toc.html">http://www.dealii.org/doc/tutorial/INSERT_rest_of_the_url</a>. - - - - - - - - diff --git a/deal.II/doc/tutorial/templates/navbar.html b/deal.II/doc/tutorial/templates/navbar.html deleted file mode 100644 index dd3c0c98ac..0000000000 --- a/deal.II/doc/tutorial/templates/navbar.html +++ /dev/null @@ -1,43 +0,0 @@ - - - - - -deal.II tutorial: INSERT_title - - - - - - - -

-Table of contents -

- Long table of contents -

- INSERT_whatever_you_wish -

- -