From: wolf Date: Mon, 12 Apr 2004 14:28:59 +0000 (+0000) Subject: Remove the old chapter 1 of the tutorial, which was hopelessly outdated anyway. Fix... X-Git-Url: https://gitweb.dealii.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=644cb78209ff510a1618da625d2c48c5b7d1cb5d;p=dealii-svn.git Remove the old chapter 1 of the tutorial, which was hopelessly outdated anyway. Fix all the links that still pointed to it. Remove a great number of other files as well, that were created sometime in 1999 and probably never used ever since. git-svn-id: https://svn.dealii.org/trunk@8986 0785d39b-7218-0410-832d-ea1e28bc413d --- diff --git a/deal.II/doc/documentation.html b/deal.II/doc/documentation.html index 75547fadb7..1912968d23 100644 --- a/deal.II/doc/documentation.html +++ b/deal.II/doc/documentation.html @@ -31,13 +31,11 @@

Tutorials

- The tutorial: + The tutorial: for new users of the library. It explains the basic elements of finite element programs based on the library, and provides small example programs. - Another chapter of the tutorial gives an overview of information - classified by subject. This is more for reference than to learn - about the library the first time.

@@ -73,7 +71,7 @@

- As for the tutorials, the API docs need to be generated first, + Just as for the tutorials, the API docs need to be generated first, if you download deal.II. Please follow the instructions in the ReadMe file on how to do diff --git a/deal.II/doc/navbar.html b/deal.II/doc/navbar.html index 54899c31e1..a234aebaba 100644 --- a/deal.II/doc/navbar.html +++ b/deal.II/doc/navbar.html @@ -42,7 +42,7 @@


- + Tutorial

diff --git a/deal.II/doc/tutorial/Makefile b/deal.II/doc/tutorial/Makefile index 06ab483bf0..71a62e9b19 100644 --- a/deal.II/doc/tutorial/Makefile +++ b/deal.II/doc/tutorial/Makefile @@ -4,9 +4,7 @@ step-by-step: cd chapter-2.step-by-step ; $(MAKE) validate-xrefs: - cd chapter-1.elements ; $(MAKE) validate-xrefs cd chapter-2.step-by-step ; $(MAKE) validate-xrefs - cd chapter-3.laplace ; $(MAKE) validate-xrefs clean: cd chapter-2.step-by-step ; $(MAKE) clean diff --git a/deal.II/doc/tutorial/chapter-1.elements/Makefile b/deal.II/doc/tutorial/chapter-1.elements/Makefile deleted file mode 100644 index 9d7bf2c49c..0000000000 --- a/deal.II/doc/tutorial/chapter-1.elements/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-1.elements/adaptivity.html b/deal.II/doc/tutorial/chapter-1.elements/adaptivity.html deleted file mode 100644 index 7ad93c5a1e..0000000000 --- a/deal.II/doc/tutorial/chapter-1.elements/adaptivity.html +++ /dev/null @@ -1,242 +0,0 @@ - - - - - -deal.II tutorial: Error Estimate and Adaptivity - - - - - - - - - -

Error Estimate and Adaptivity

- -

In this chapter we shall discuss

- - - -

How to use error estimates for adaptive refinement

- -

-The basic principles of using error estimates for adaptive refinement -are rather simple. First, you get an error estimate for each cell. -Second, each cell is refined according to this estimate, i.e. the -cells with largest error estimate are refined and those with the least -one are coarsened. -

-

-The implementation of deal.II handles this principle -exactly the same way: First, you call an error estimator that returns -a vector containing the error estimates for each cell. Second, -you pass this vector on to a function doing the refinement. -

-

-What we have not told yet is that actually constructing an error -estimator is nontrivial and in particular dependent on the equation -you are presently solving. Since this is so, the library can not do it -for you, but can only aid you in doing so. -

-

-However, the library contains an error estimator for one equation, the -Laplace equation, which is the standard equation in numerical -analysis. Since it is so common, an error estimator for it was once -implemented. It was later moved into the library, since besides being -an estimator for Laplace's equation, it proved an almost universal -tool if you want something to refine your grid based on local -smoothness of your solution. This, in fact, is the principle from -which the error estimator was constructed: it computes an -approximation to the second derivative of the solution on each cell, -and these values can then be used to control refinement of the grid -for a wide class of equations. Almost all projects using -deal.II have used this criterion in its early -stages, to get a quick way to local mesh refinement, before -problem-adapted error estimators were written for the particular -equation later. Since the class has thus proven universal -functionality, we will discuss it in this section and show how to use -it to control mesh refinement. - -

Error Estimators in deal.II

- -

-In deal.II there is exactly on standard error estimator: -the error estimator by Kelly, Gago, Zienkiewicz and Babuska that -tries to approximate the error per cell by integration of the jump of the -gradient of the solution along the faces of each cell. -In theory this error estimator has quite a number of limitations. These -limitations as well as its implementation are described in - -the documentation for the class KellyErrorEstimator. -In daily use, however, this error estimator has shown itself to behave -rather like Hamlet: It is laden with theoretical woes and sorrows, -but at the end of the day all practical problems are... gone. -

- -

-In order to use an error estimator you need the following information -and objects respectively: -

- -

-The Kelly error estimator is then used the following way: -

-
    -
  1. Include the include file:
    - #include <numerics/error_estimator.h> -
  2. - -
  3. Define an error estimator for dim dimensions:
    - KellyErrorEstimator<dim> error_estimate; -
  4. - -
  5. Make the error estimator estimate each cell's error:
    -
    -      
    - void error_estimate::estimate (const DoFHandler<dim> &dof_handler,
    -                                const Quadrature<dim-1> &quadrature,
    -                                const FunctionMap &neumann_bc, 
    -                                const Vector<double> &solution,
    -                                Vector<float> &error_per_cell, 
    -                                ... // coefficients, etc.
    -                               ); 
    -      
    -      
    -
  6. -
- -

Adaptive Refinement

- -

-All the functions for refinement (and coarsening) are contained -within the Triangulation class. -Refinement and coarsening take place by first flagging the cells -for coarsening or refinement using the functions described below -and then actually executing the refinement using -void execute_coarsening_and_refinement(). -There are several ways of refining or coarsening your grid using -the output from an error estimator: -

- -

-Remember: In order to actually execute the refinement or coarsening -you have to call void execute_coarsening_and_refinement(). - - -

Example

- -The following is a code snippet taken from some example programs: -
-
-                     // use the Simpson rule for integration on the faces
-  QSimpson face_quadrature;
-                     // estimate error with no Neumann boundary conditions
-  KellyErrorEstimator::estimate (*dof, face_quadrature,
-			              KellyErrorEstimator::FunctionMap(),
-				      solution,
-				      estimated_error_per_cell);
-
-                     // flag some cells for refinement or coarsening
-  tria->refine_and_coarsen_fixed_number (estimated_error_per_cell,
-				         0.3,
-				         0.05);
-  tria->execute_coarsening_and_refinement ();
-
-
- - - -
- - - - - - - -
-
-The deal.II group
-

- -

- - 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. - - - -


- - - - - - - -
-
-The deal.II group
-

- -

- - 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: -

    -
  1. 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(). -
  2. -
  3. -Create a global sparsity pattern (as described in the chapter on -matrix structure) using -void DoFTools::make_sparsity_pattern(const DoFHandler<dim> &, - SparsityPattern &). -
  4. -
  5. -Create the constraints on the hanging nodes using -void DoFHandler::make_constraint_matrix(ConstraintMatrix &). -
  6. -
  7. 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. -
  8. -
  9. Finally, condense the hanging nodes into the matrix structure -using ConstraintMatrix::condense(SparsityPattern &). -
  10. -
- -

-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. - - - - - -


- - - - - - - -
-
-The deal.II group
-

- -

- - 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. - - - -


- - - - - - - -
-
-The deal.II group
-

- -

- - 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
- Hypercubes -
- -

-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
- Hyperballs -
- -

-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 2dimension-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) -
- Hyper-L -
- -

-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 -

    -
  1. vertices
  2. -
  3. cells
  4. -
  5. boundaries
  6. -
  7. create a triangulation from this information
  8. -
-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);
-
-
- - -
- - - - - - - - -
-
-The deal.II group
-

- -

- - - 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
-Hanging Nodes -
- -

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
-
-  CTACy = CTf
-
-or, taking
-
-  ~A := CTAC, b := CTf 
-  ~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. -

- -
- - - - - - - -
-
-The deal.II group
-

- -

- - 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: -

- - -

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: -

- - - -

-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()2. -

-
-
-#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. - - -
- - - - - - - -
-
-The deal.II group
-

- -

- - 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: -

- -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 deal.II group
-

- -

- - - 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 -

    -
  • - -
  • -

    - The Problem Matrix and the Right Hand Side -

    -
  • - -
  • -

    - Boundary Conditions -

    -
  • - -
  • -

    - Condensing the Hanging Nodes -

    -
  • - -
  • -

    - Solving the Problem -

    -
  • - -
  • -

    - Postprocessing -

    -
  • - -
  • -

    - Error Estimation and Adaptivity -

    -
  • - -
  • -

    - Parameter Input -

    -
  • - -
  • -

    - Grid and Data Output -

    -
  • -
    -

    - Back to the tutorial index -

    - -

    - 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

    -

    -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: -

    - - - -

    GridOut graphics formats

    -

    -The graphics formats available in GridOut are: -

    - - -
    -
    - -

    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. -

    - - -

    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. -

    - - - -

    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, -vi 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 -

    - - -

    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: -

    - -

    -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. -

    - - - - - - -
    - - - - - - -
    -
    -The deal.II group
    -

    - -

    - - 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: -

    - - -

    -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. -

    - - -
    - - - - - - - -
    -
    -The deal.II group
    -

    - -

    - - 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. -

    - - - -
    - - - - - - - -
    -
    -The deal.II group
    -

    - -

    - - 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: -

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

    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 -

    - - -
    -
    -  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. - - - -
    - - - - - - - -
    -
    -The deal.II group
    -

    - -

    - - - - 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: -

    - - -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: -

    -

    - -

    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 -

    - -

    -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);
    -
    -
    - - -
    - - - - - - - -
    -
    -The deal.II group
    -

    - -

    - - 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. -

    - -

    Table of contents

    - -
      -
    1. -

      - Creation of a grid -

      -

      dealing with grid creation, grid input from a file and grid - refinement. - The various kinds of grid are also discussed. -

      -
    2. - -
    3. -

      - Degrees of Freedom -

      -

      where degrees of freedom are distributed and numbered.

      -
    4. - -
    5. -

      - Hanging Nodes -

      -

      where locally refined grids are discussed.

      -
    6. - -
    7. -

      - Matrix Structure -

      -

      where efficient structures for sparse matrices are discussed.

      -
    8. - -
    9. -

      - Matrix and Vector Generation -

      -

      where the different kinds of matrices and vectors are discussed.

      -
    10. - -
    11. -

      - The Problem Matrix and the Right Hand Side -

      -

      which shows how to implement a particular problem.

      -
    12. - -
    13. -

      - Boundary Conditions -

      -

      which shows how to set boundary conditions in deal.II.

      -
    14. - -
    15. -

      - Condensing the Hanging Nodes -

      -

      which shows how, when and why to condense hanging nodes.

      -
    16. - -
    17. -

      - Solving the Problem -

      -

      explaining the different solvers available and how to use them.

      -
    18. - -
    19. -

      - Postprocessing -

      -

      where the data is postprocessed and stored and the error - is calculated. -

      -
    20. - -
    21. -

      - Error Estimate and Adaptivity -

      -

      explaining how to use adaptive refinement with error estimates.

      -
    22. - -
    23. -

      - Parameter Input -

      -

      explaining how to use a parameter file for configuring - your program. -

      -
    24. - -
    25. -

      - Grid and Data Output -

      -

      explaining how to get output of your data, with an emphasis on - different graphic formats. -

      -
    26. -
    - -
    - - - - - - - -
    -
    -The deal.II group
    -

    - -

    - - - - - - - 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 tutorial index -

    -

    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:
    - - - - - -
    The deal.II group
    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: -

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

    ...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 -

    - - -
    -
    -  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: -

    - -

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

    -
      -
    1. 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. -
    2. -
    3. 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. -
    4. -
    - - -
    - - - - - - - - - -
    -
    The deal.II group
    -

    -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();
    -};
    -
    -
    - -
    - - - - - - - - - -
    - -
    The deal.II group
    - - -

    -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: -

    - -
      -
    1. Inclusion of the necessary headers and variable - definitions. -
    2. -
    3. - Instantiation of the C++ class Laplace - dealing with the problem. -
    4. -
    5. Calling the Laplace methods for assemblage and solution of the - problem. -
    6. -
    7. - Writing out of the output data and termination. -
    8. -
    - -

    -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 -

    -
  • -
  • -

    -Assembling the problem matrix -

    -
  • -
  • -

    -Solving the problem -

    -
  • -
  • -

    -The source code -

    -
  • -
    - -

    - Back to the tutorial index -

    -
    -

    - 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);
    -
    -}
    -
    - -
    - - - - - - - - - -
    -
    The deal.II group
    - -

    -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.

      -
    • -
    - -
    - - - - - - - - -
    -
    -The deal.II group
    -

    -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: -

    - -

    - 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 -
    • -
    - - -
    - - - - - - - - - -
    -
    The deal.II group
    - -

    -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:

    -
      -
    1. -Program structure -

      -where the overall design of the program and its classes are discussed

      -
    2. -
    3. -The main program -

      -where we take a look at how deal.II is used

      -
    4. -
    5. -The class Laplace -

      -where some of the details of the problem generation and solution are -discussed

      -
    6. -
    7. -Generating a triangulation -

      where a triangulation is generated and degrees of freedom are discussed

      -
    8. -
    9. -Assembling the problem matrix -

      -where the matrices describing the problem is assembled -and the boundary conditions are set -

      -
    10. -
    11. -Solving the problem -

      -where the problem is solved -

      -
    12. -
    13. -The source code -

      -contains link to all the source files. -

      -
    14. -
    -
    - - -
    -
    -The deal.II group
    -

    -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);
    - }
    -
    -
    - -
    - - - - - - - - - -
    - -
    The deal.II group
    - -

    -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 - -

    - -

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

    - -
    - -

    - 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 -

    -
  • -
    -

    - Back to the tutorial index -

    - - - - - - - - - diff --git a/deal.II/doc/tutorial/templates/title.html b/deal.II/doc/tutorial/templates/title.html deleted file mode 100644 index 96169d3778..0000000000 --- a/deal.II/doc/tutorial/templates/title.html +++ /dev/null @@ -1,33 +0,0 @@ - - - - - -deal.II tutorial: chapter title - - - - - - - - - - - -

    The deal.II tutorial - Chapter INSERT_number - INSERT_chapter_title

    - - - - - - - - - - - - diff --git a/deal.II/doc/tutorial/templates/toc.html b/deal.II/doc/tutorial/templates/toc.html deleted file mode 100644 index 219565521c..0000000000 --- a/deal.II/doc/tutorial/templates/toc.html +++ /dev/null @@ -1,61 +0,0 @@ - - - - - -deal.II tutorial: INSERT_title - - - - - - - -

    INSERT_title

    - -

    About this tutorial

    -

    -INSERT_some_introductory_text -

    - -

    Table of contents

    - -
      -
    1. -

      - INSERT_topic -

      -

      dealing with INSERT_description_of_aforementioned_topic -

      -
    2. - -
    - -
    - - - - - - - -
    -
    -INSERT_your_name
    -

    -Last modified: $Date$ -

    - - - - - - - diff --git a/deal.II/doc/tutorial/tex/report-july-1999.tex b/deal.II/doc/tutorial/tex/report-july-1999.tex deleted file mode 100644 index 2820e614cd..0000000000 --- a/deal.II/doc/tutorial/tex/report-july-1999.tex +++ /dev/null @@ -1,278 +0,0 @@ -%% $Id$ - -\documentclass[a4paper]{article} -\usepackage[latin1]{inputenc} - -\newcommand{\dealii}{{\em deal.II\/}} - -\title{Report on the \dealii{} tutorial} -\author{Jan Schrage\footnote{Universität Heidelberg, Institut für theoretische Astrophysik \& SFB 359}} - - -\begin{document} -\maketitle - -\begin{abstract} -We will describe the \dealii{} tutorial, its purpose, -its state at the time of this writing, the standards employed -in writing it and the means to extend it. -\end{abstract} - -\clearpage - -\tableofcontents - -\clearpage - -\section{\dealii} -\label{sec:dealii} - -\dealii{} is a C++ class library for the solution of systems -of differential equations with finite element methods. - -\section{Purpose of the tutorial} -\label{sec:purpose} -There are about one thousand pages of documentation of the \dealii{} -classes. However, there was not introductory documentation -nor instructions on the use of \dealii{} before the start of this -project. The purpose of this tutorial is to enable students or -other persons interested in \dealii{} to get an overview of the -methods employed and the use of the C++ classes. One should also -be able to use it as a quick reference to look up concepts of \dealii{}. -It should provide a background for a closer inspection -of the existing class documentation. Its purpose is not to replace -the class documentation but to complement it. - -We have chosen to write the tutorial for viewing on the world wide web -in order to make it easily usable and -easily adaptable to the rapid changes in \dealii{}. - -\section{State of the tutorial} -\label{sec:state} - -There are at the time of this writing two main parts of the tutorial: -\begin{itemize} -\item A general overview of the structure of a finite element program. - This is the most crucial part laying the background for working with - \dealii{}; it explains how and when to use what methods in a finite - element program. This part is up--to--date. -\item The Laplace problem. This part gives a detailed explanation of - the source code of a program solving the stationary Laplace problem - with \dealii{}. Due to the rapid changes in \dealii{} the source - code of this part is not compatible with the current - version of \dealii{} any more. -\end{itemize} -Other parts can easily be added as needed following the steps -in appendix~\ref{sec:steps}. - - -\section{Standards employed} -\label{sec:standards} - -The \dealii{} tutorial makes use of HTML4 including frames and CSS1. -None of its pages contain dynamic content, in particular they do not -contain JavaScript\footnote{JavaScript is a registered trademark -of Sun Microsystems, inc.} -and they do not require server--side preprocessing. - -\subsection{HTML4 and CSS} -\label{sec:html4} - -The tutorial makes use of HTML4\footnote{c.f. \cite{html4,htmlhelp4,niederst:webdesign}} -including frames -and Cascading Style Sheets (CSS) Level 1. -\footnote{c.f. \cite{css1,htmlhelpcss,niederst:webdesign}} -Even though -not all web browsers currently support CSS we expect this technology -to gain more widespread support in the near future. The browsers -currently at use in the IWR support a large part of the -specifications of CSS1 and HTML4. - -All the web pages has been validated against the HTML4 Document Type -Definition (DTD)\footnote{c.f. \cite{html4dtd}} and are guaranteed to be -syntactically correct. - - -\subsection{Practical implications} -\label{sec:standards:implications} - - -\subsubsection{Usability by third parties} - -\begin{list}{Frames}{} -\item[{\bf Frames:}] Frames are supported by most web browsers, even older versions. - It is possible to view the tutorial without frames if a browser does not - support them. -\item[{\bf HTML4:}] HTML4 to its full extent is supported by almost no browser; - Netscape Navigator 4 (NN4) and Microsoft Internet Explorer 4 (MSIE4) - support a large - subset of HTML4 and even older browsers can render most of it. We have - taken care to use a subset of HTML4 mostly - compatible with older versions of HTML. Browsers that do not - support HTML4 will render small parts of the web pages incorrectly. -\item[{\bf CSS:}] Cascading Style Sheets Level 1 to their full extent are not - supported - by any browser currently available. Again, NN4 and MSIE4 support a large - subset of CSS1. Browsers that do not support CSS1 will render the - web pages differently but still in a way that leaves them usable. -\end{list} -The browsers in use at the IWR render all the web pages correctly. - -The use of CSS makes it possible to use different style sheets -for different media types, i.e. paper or audio for the -blind. In the long and even medium run the usability of the tutorial -is thereby very much increased. Currently the tutorial uses -style sheets for screen, print and audio. The screen and print style -sheets are identical at the moment, the audio style sheet merely -offers access to all the classes in use, as we are not aware of any -audio applications with the ability to parse style sheets. - -\subsubsection{Writers} - -The practical implications for writers are more eminent: -The use of CSS allows the separation of the page design from its content. -Any writer extending the tutorial only needs to include the -appropriate CSSs in order to produce a web page with the same -design as the rest of the tutorial suitable for use with -different media. - - -\section{Use of templates} -\label{sec:templates} - -In order to facilitate the extension of the tutorial there -are a number of template files for recurring elements. -Anybody who wishes to use such an element only needs to include -and adapt the appropriate template. Where replacements -are needed in a template they are prefixed with ``INSERT\_'' -to ease the adaption to any specific case. - -A more detailed explanation is provided in appendix~\ref{sec:steps}. - - -\section{A question of style} -\label{sec:style} - -Within the \dealii{} tutorial style and content are (with very few -exceptions) strictly separated. This makes the design easily changeable -and adaptable to different needs. It also helps to keep the design -and style consistent throughout the tutorial. -We have used abstract HTML markup, defining classes for different -element types. The visual (or aural) markup of each class for different media -is defined in the style sheets. - -We have taken care to ensure easy and consistent means of navigation -throughout the tutorial; we have also tried to suit the needs of the -users and not those of the programmers of \dealii{}. - -In the bibliography we list a few references on good HTML style, like -\cite{galactus:style,fleming:webnavigation}. - -\section{Feedback so far} -\label{sec:feedback} - -Feedback on the tutorial so far has been positive. -The methods of navigation and the general look and feel of the -\dealii{} tutorial have met with agreement, as have the contents. - -The most eminent wish by students was that more examples in the -way of working programs should be provided to complement the -tutorial. At the time of this writing the examples provided -are stripped of all the program code that is not strictly necessary -to develop an understanding of the principles. In particular, -there are usually no compilable and runnable programs provided. - -\clearpage - -\appendix - -\section{Directory structure} -\label{sec:directories} - -All the relevant files and directories are contained in the directory -{\tt doc/tutorial} in the \dealii{} directory structure. -At the moment the following subdirectories and files exist on the top -level: -\par -\vspace{0.5cm} -\begin{tabular}[H]{l|r|p{6cm}} -Name & Revision number & Description \\ -\hline -index.html & 1.10 & tutorial entry page \\ -screen.css & 1.1 & CSS1 style sheet, media: screen \\ -print.css & 1.1 & CSS1 style sheet, media: print media \\ -audio.css & 1.1 & CSS1 style sheet, media: aural media \\ -templates/ & --- & template directory \\ -figures/ & --- & figures in {\tt eps} or {\tt fig} format\\ -images/ & --- & figures in {\tt gif} format for the web pages\\ -glossary/ & --- & glossary explaining the terms used \\ -scripts/ & --- & scripts for maintenance and validation\\ -tex/ & --- & reports \\ -00.fe\_structure/ & --- & Chapter 0: Structure of a finite element program \\ -01.laplace/ & --- & Chapter 1: The Laplace problem\\ -\end{tabular} - -\section{CSS1--classes in use} -\label{sec:css-classes} - -Below we show the CSS1--classes currently in use and the -structural elements to which they should be applied, i.e. -which elements should have the attribute ``class=...'' set. -\par -\vspace{0.5cm} -\begin{tabular}[H]{l|p{6cm}} -Class & Corresponding Elements \\ -\hline -figure & figures, subtitles to figures \\ -pagetoc & small table of contents for only one (long) page \\ -chapter\_title & title of a chapter, used in the appropriate templates\\ -parhead & paragraph heading \\ -example & examples, used in the appropriate template \\ -navbar & navigation bar at the page bottom\\ -\end{tabular} -\par -\vspace{0.5cm} -In addition to this we have defined some properties common to -all elements of a particular type, like background colour for the -page body etc. - - -\section{Extending the tutorial -- step by step} -\label{sec:steps} - -\begin{enumerate} -\item Create a directory with the number and name of the new - chapter like ``02.newchapter''. -\item Copy the following files from the directory ``templates'' - into your new directory: - {\tt - \begin{itemize} - \item toc.html - \item index.html - \item navbar.html - \item title.html - \item logo.html - \end{itemize} - } -\item Adapt these files according to your needs. {\tt toc.html} contains - the long table of contents with explanations, {\tt navbar.html} the - brief table of contents that can be seen on the left, {\tt index.html} - puts the layout of the frameset together and {\tt title.html} contains - the large chapter title on top. Take care to replace all the ``INSERT\_'' - tags with sensible content. {\tt logo.html} contains a link - to the \dealii{} logo. -\item Create your web pages using {\tt body.html} from the template - directory. Again replace all ``INSERT\_'' tags with sensible content. -\item For code examples within a web page - use {\tt example.html} from the template - directory. This particular template can be inserted into any - web page. -\item Create a link to your {\tt index.html} from the tutorial's - entry page. -\end{enumerate} - -\clearpage -\bibliographystyle{alpha} -\bibliography{tutorial} - -\end{document} diff --git a/deal.II/doc/tutorial/tex/tutorial.bib b/deal.II/doc/tutorial/tex/tutorial.bib deleted file mode 100644 index 5240b7b86e..0000000000 --- a/deal.II/doc/tutorial/tex/tutorial.bib +++ /dev/null @@ -1,68 +0,0 @@ - -@Book{fleming:webnavigation, - author = "J. Fleming", - title = "Web Navigation", - publisher = "O'Reilly", - year = 1998 -} - -@Book{niederst:webdesign, - author = "J. Niederst", - title = "Web Design in a Nutshell", - publisher = "O'Reilly", - year = 1999 -} - - -@TechReport{css1, - author = "H. Wium Lie and B. Bos", - title = "Cascading Style Sheets, level 1", - institution = "W3C", - year = 1997, - note = "http://www.w3.org/TR/REC-CSS1" -} - -@TechReport{html4, - author = "D. Raggett and A. Le Hors and I. Jacobs", - title = "HTML 4.0", - institution = "W3C", - year = 1997, - note = "http://www.w3.org/TR/REC-html40" -} - -@TechReport{html4dtd, - author = "D. Raggett and A. Le Hors and I. Jacobs", - title = "HTML 4.0 strict DTD", - institution = "W3C", - year = 1997, - note = "http://www.w3.org/TR/REC-html40/strict.dtd" -} - - -@Manual{galactus:style, - author = "A. Engelfriet", - title = "Style guide for online hypertext", - note = "http://www.htmlhelp.org/design/style", - year = 1997, - organization = "Web Design Group" -} - - -@Manual{htmlhelp4, - author = "L. Quinn", - title = "HTML 4.0 Reference", - note = "http://www.htmlhelp.org/reference/html40", - year = 1998, - organization = "Web Design Group" -} - -@Manual{htmlhelpcss, - title = "Cascading Style Sheets", - author = "J. Pozadzides and L. Quinn", - year = 1998, - organization = "Web Design Group", - note = "http://www.htmlhelp.org/reference/css" -} - - - diff --git a/deal.II/doc/tutorial/title.html b/deal.II/doc/tutorial/title.html deleted file mode 100644 index ee3e518e40..0000000000 --- a/deal.II/doc/tutorial/title.html +++ /dev/null @@ -1,34 +0,0 @@ - - - - - -deal.II tutorial: Chapter title - - - - - - - - - - - -

    -The deal.II tutorial -

    - - - - - - - - - - - diff --git a/deal.II/doc/tutorial/toc.html b/deal.II/doc/tutorial/toc.html deleted file mode 100644 index 2b5ebf1e87..0000000000 --- a/deal.II/doc/tutorial/toc.html +++ /dev/null @@ -1,83 +0,0 @@ - - - - - - The deal.II Tutorial - - - - - -

    The deal.II Tutorial

    - -

    - This is the tutorial for the deal.II - library. It is divided into several parts, covering different - aspects of a reference manual: -

    - -
      -
    • -

      - The first chapter contains a - - series of small programs which are meant to provide a - step-by-step introduction of a new user to programming with - deal.II. The examples start on a very - basic level and demonstrate successively more complex parts - of a finite element program. -

      - -

      - This part is targeted at new users of the library that want - to learn how to use it and to program with it. It may also - be used by people who know about the mathematics of finite - elements, but have never written a finite element program - themselves. Finally, the programs may also serve as starting - point for own projects. -

      - -
    • -

      - The second chapter gives a - survey - of the tools that deal.II provides - for several important - parts of finite element programs, for example grid creation, - creation of matrices, boundary conditions, etc. The sections - of the chapter contain small code snippets which demonstrate - the use of the techniques under discussion, but no actual - programs. -

      - -

      - This part is probably better suited for more - experienced users of the library, if you seek for specific - information on a certain topic. Note that we do not keep - this section up to date any more, so the library often - provides more than what this section might suggest. -

      -
    - - - -

    Comments and Suggestions

    -

    - Comments and suggestions on this tutorial are welcome and should be - addressed to the deal.II mailing list: -

    -
    - The deal.II mailing list -
    -
    -
    - -
    - The deal.II mailing list
    - - - -