]> https://gitweb.dealii.org/ - dealii.git/commitdiff
Have a way to escape expansion of step-xx in situations where we don't want to expand...
authorWolfgang Bangerth <bangerth@math.tamu.edu>
Wed, 7 Sep 2011 22:29:45 +0000 (22:29 +0000)
committerWolfgang Bangerth <bangerth@math.tamu.edu>
Wed, 7 Sep 2011 22:29:45 +0000 (22:29 +0000)
git-svn-id: https://svn.dealii.org/trunk@24280 0785d39b-7218-0410-832d-ea1e28bc413d

16 files changed:
deal.II/doc/doxygen/filter
deal.II/examples/step-18/doc/intro.dox
deal.II/examples/step-18/doc/results.dox
deal.II/examples/step-19/doc/results.dox
deal.II/examples/step-2/doc/results.dox
deal.II/examples/step-20/doc/results.dox
deal.II/examples/step-22/doc/results.dox
deal.II/examples/step-27/doc/results.dox
deal.II/examples/step-29/doc/results.dox
deal.II/examples/step-3/doc/results.dox
deal.II/examples/step-32/doc/results.dox
deal.II/examples/step-33/doc/results.dox
deal.II/examples/step-36/doc/results.dox
deal.II/examples/step-5/doc/results.dox
deal.II/examples/step-6/doc/results.dox
deal.II/examples/step-7/doc/results.dox

index d410c1385e84e7be746b480482426e0e8a529e2f..dac0d8814a9d8a8427622f3bd51e3663248fac15 100755 (executable)
@@ -22,18 +22,24 @@ s/(::)?dealii::/::/g;
 # this rule, we actually had to write this sequence out in our
 # documentation. Unfortunately, as a consequence, there are vestiges
 # of this style, so we can't substitute things that look like
-# "step-xx".
+# "step-xx". We therefore not substitute if step-xx is preceded or
+# followed by quotation marks, or if the text is explicitly
+# preceded by a backslash for escaping.
 #
-# There is other exceptions:
+# There are other exceptions:
 # - the scripts in doc/doxygen/tutorial produce files that have
 #   table of contents entries. We don't want these cross-linked
 #   to itself.
-# - things like step_12.solution.png that typically appear in
+# - things like step-12.solution.png that typically appear in
 #   @image commands.
 # - things in headings
-s/(?<!\")step-(\d+)(?!\")/\@ref step_\1 \"step-\1\"/gi
+s/(?<![\"\\])step-(\d+)(?!\")/\@ref step_\1 \"step-\1\"/gi
   if !m/(\@page|\@image|<h\d>)/i;
 
+# If step-xx was explicitly escaped with a backslash, remove the
+# latter
+s/\\(step-\d+)/\1/g;
+
 
 s#(static dealii::ExceptionBase\&)#\n//\! \@ingroup Exceptions\n \1#g;
 
index 55b7f40f231276c712d8c711676cf479220782dd..b9908c581397affedb081493e1653ef4e67cd6c3 100644 (file)
@@ -362,7 +362,7 @@ The next step is to convert this file or these files into whatever
 format you like. The program that does this is the step-19 tutorial program:
 for example, for the first time step, call it through
 @code
-    ../step-19/step-19 solution-0001.0000.*.d2 solution-0001.0000.gmv
+    ../\step-19/\step-19 solution-0001.0000.*.d2 solution-0001.0000.gmv
 @endcode
 to merge all the intermediate format files into a single file in GMV
 format. More details on the parameters of this program and what it can do for
index ce75daaef2c6e31e12bc7764a0151b2ed6531ea4..0c1ba3adaa454b1d1ec07776c2775cd904189520 100644 (file)
@@ -13,8 +13,8 @@ reduced significantly, to about 23 minutes, a much more reasonable time.
 If run, the program prints the following output, explaining what it is
 doing during all that time:
 @code
-examples/step-18> time make run
-============================ Running step-18
+examples/\step-18> time make run
+============================ Running \step-18
 Timestep 1 at time 1
   Cycle 0:
     Number of active cells:       3712 (by partition: 3712)
@@ -89,7 +89,7 @@ unknowns. Not a whole lot, but enough for a coupled three-dimensional
 problem to keep a computer busy for a while. At the end of the day,
 this is what we have for output:
 @code
-examples/step-18> ls -l *.d2
+examples/\step-18> ls -l *.d2
 -rw-r--r--  1 bangerth wheeler 8797414 May 25 09:10 solution-0001.0000.d2
 -rw-r--r--  1 bangerth wheeler 8788500 May 25 09:32 solution-0002.0000.d2
 -rw-r--r--  1 bangerth wheeler 8763718 May 25 09:55 solution-0003.0000.d2
@@ -104,17 +104,17 @@ examples/step-18> ls -l *.d2
 
 
 Let us convert these files in deal.II intermediate format to gmv
-format (this assumes that you have already compiled the 
+format (this assumes that you have already compiled the
 step-19 example program):
 @code
-examples/step-18> ../step-19/step-19
+examples/\step-18> ../\step-19/\step-19
 
 Converter from deal.II intermediate format to other graphics formats.
 
-Usage: ./step-19 [-p parameter_file] list_of_input_files [-x output_format] output_file
+Usage: ./\step-19 [-p parameter_file] list_of_input_files [-x output_format] output_file
 
-examples/step-18> ../step-19/step-19 solution-0001.0000.d2 -x gmv solution-0001.0000.gmv
-examples/step-18> ../step-19/step-19 solution-0002.0000.d2 -x gmv solution-0002.0000.gmv
+examples/\step-18> ../\step-19/\step-19 solution-0001.0000.d2 -x gmv solution-0001.0000.gmv
+examples/\step-18> ../\step-19/\step-19 solution-0002.0000.d2 -x gmv solution-0002.0000.gmv
 [...]
 @endcode
 Of course, since we have run the program only in sequential mode, we
@@ -233,7 +233,7 @@ Timestep 20 at time 10
 That's quite a good number of unknowns, given that we are in 3d. The output of
 this program are 16 files for each time step:
 @code
-examples/step-18> ls -l solution-0001.000*
+examples/\step-18> ls -l solution-0001.000*
 -rw-r--r--    1 bangerth mfw       4325219 Aug 11 09:44 solution-0001.0000-000.d2
 -rw-r--r--    1 bangerth mfw       4454460 Aug 11 09:44 solution-0001.0000-001.d2
 -rw-r--r--    1 bangerth mfw       4485242 Aug 11 09:43 solution-0001.0000-002.d2
@@ -252,14 +252,14 @@ examples/step-18> ls -l solution-0001.000*
 -rw-r--r--    1 bangerth mfw       4340488 Aug 11 09:44 solution-0001.0000-015.d2
 @endcode
 We merge and convert these 16 intermediate files into a single gmv file as
-follows: 
+follows:
 @code
-examples/step-18> time ../step-19/step-19 solution-0001.0000-* -x gmv -o solution-0001.0000.gmv
+examples/\step-18> time ../\step-19/\step-19 solution-0001.0000-* -x gmv -o solution-0001.0000.gmv
 
 real    0m45.929s
 user    0m41.290s
 sys     0m0.990s
-examples/step-18> ls -l solution-0001.0000.gmv
+examples/\step-18> ls -l solution-0001.0000.gmv
 -rw-r--r--    1 bangerth mfw      68925360 Aug 11 17:04 solution-0001.0000.gmv
 @endcode
 
@@ -349,7 +349,7 @@ what direction it may be extended:
  The most obvious extension is to use a more
 realistic material model for large-scale quasistatic deformation. The natural
 choice for this would be plasticity, in which a nonlinear relationship between
-stress and strain replaces equation <a href="#step-18.stress-strain">[stress-strain]</a>. Plasticity
+stress and strain replaces equation <a href="#step_18.stress-strain">[stress-strain]</a>. Plasticity
 models are usually rather complicated to program since the stress-strain
 dependence is generally non-smooth. The material can be thought of being able
 to withstand only a maximal stress (the yield stress) after which it starts to
@@ -379,7 +379,7 @@ elastoplasticity: I. Mixed displacement-pressure formulation&rdquo;
 pp. 3559-3586, 2004).
 
 
-<h5>Stabilization issues</h5> 
+<h5>Stabilization issues</h5>
 
 The formulation we have chosen, i.e. using
 piecewise (bi-, tri-)linear elements for all components of the displacement
@@ -412,19 +412,19 @@ elasticity&rdquo; (Computer Methods in Applied Mechanics and Engineering, vol. 1
 pp. 1093-1112, 2005).
 
 
-<h5>Refinement during timesteps</h5> 
+<h5>Refinement during timesteps</h5>
 
 In the present form, the program
 only refines the initial mesh a number of times, but then never again. For any
 kind of realistic simulation, one would want to extend this so that the mesh
 is refined and coarsened every few time steps instead. This is not hard to do,
 in fact, but has been left for future tutorial programs or as an exercise, if
-you wish. 
+you wish.
 
 The main complication one has to overcome is that one has to
 transfer the data that is stored in the quadrature points of the cells of the
 old mesh to the new mesh, preferably by some sort of projection scheme. The
-general approach to this would go like this: 
+general approach to this would go like this:
 
 - At the beginning, the data is only available in the quadrature points of
   individual cells, not as a finite element field that is defined everywhere.
@@ -440,30 +440,30 @@ general approach to this would go like this:
   for example, if you have a QGauss(2) quadrature formula (i.e. 4 points per
   cell in 2d, 8 points in 3d), then one would use a finite element of kind
   FE_DGQ(1), i.e. bi-/tri-linear functions as these have 4 degrees of freedom
-  per cell in 2d and 8 in 3d. 
+  per cell in 2d and 8 in 3d.
 
-- There are functions that can make this conversion from individual points to 
-  a global field simpler. The following piece of pseudo-code should help if 
-  you use a QGauss(2) quadrature formula. Note that the multiplication by the 
+- There are functions that can make this conversion from individual points to
+  a global field simpler. The following piece of pseudo-code should help if
+  you use a QGauss(2) quadrature formula. Note that the multiplication by the
   projection matrix below takes a vector of scalar components, i.e., we can only
   convert one set of scalars at a time from the quadrature points to the degrees
-  of freedom and vice versa. So we need to store each component of stress separately, 
+  of freedom and vice versa. So we need to store each component of stress separately,
   which requires <code>dim*dim</code> vectors. We'll store this set of vectors in a 2D array to
-  make it easier to read off components in the same way you would the stress tensor. 
+  make it easier to read off components in the same way you would the stress tensor.
   Thus, we'll loop over the components of stress on each cell and store
-  these values in the global history field. (The prefix <code>history_</code> 
-  indicates that we work with quantities related to the history variables defined 
-  in the quadrature points.)  
+  these values in the global history field. (The prefix <code>history_</code>
+  indicates that we work with quantities related to the history variables defined
+  in the quadrature points.)
   @code
     FE_DGQ<dim>     history_fe (1);
     DoFHandler<dim> history_dof_handler (triangulation);
     history_dof_handler.distribute_dofs (history_fe);
 
-    std::vector< std::vector< Vector<double> > > 
+    std::vector< std::vector< Vector<double> > >
                  history_field (dim, std::vector< Vector<double> >(dim)),
                  local_history_values_at_qpoints (dim, std::vector< Vector<double> >(dim)),
                  local_history_fe_values (dim, std::vector< Vector<double> >(dim));
-    
+
     for (unsigned int i=0; i<dim; i++)
       for (unsigned int j=0; j<dim; j++)
       {
@@ -479,7 +479,7 @@ general approach to this would go like this:
               quadrature, quadrature,
               qpoint_to_dof_matrix);
 
-    typename DoFHandler<dim>::active_cell_iterator cell = dof_handler.begin_active(),                                                   
+    typename DoFHandler<dim>::active_cell_iterator cell = dof_handler.begin_active(),
                                                    endc = dof_handler.end(),
                                                    dg_cell = history_dof_handler.begin_active();
 
@@ -488,7 +488,7 @@ general approach to this would go like this:
 
         PointHistory<dim> *local_quadrature_points_history
               = reinterpret_cast<PointHistory<dim> *>(cell->user_pointer());
-          
+
         Assert (local_quadrature_points_history >=
                     &quadrature_point_history.front(),
                    ExcInternalError());
@@ -498,11 +498,11 @@ general approach to this would go like this:
 
         for (unsigned int i=0; i<dim; i++)
           for (unsigned int j=0; j<dim; j++)
-          {    
+          {
             for (unsigned int q=0; q<quadrature.size(); ++q)
-              local_history_values_at_qpoints[i][j](q) 
+              local_history_values_at_qpoints[i][j](q)
                        = local_quadrature_points_history[q].old_stress[i][j];
+
             qpoint_to_dof_matrix.vmult (local_history_fe_values[i][j],
                                         local_history_values_at_qpoints[i][j]);
 
@@ -514,7 +514,7 @@ general approach to this would go like this:
 
 - Now that we have a global field, we can refine the mesh and transfer the
   history_field vector as usual using the SolutionTransfer class. This will
-  interpolate everything from the old to the new mesh. 
+  interpolate everything from the old to the new mesh.
 
 - In a final step, we have to get the data back from the now interpolated
   global field to the quadrature points on the new mesh. The following code
@@ -530,22 +530,22 @@ general approach to this would go like this:
     typename DoFHandler<dim>::active_cell_iterator cell = dof_handler.begin_active(),
                                                    endc = dof_handler.end(),
                                                    dg_cell = history_dof_handler.begin_active();
-  
+
     for (; cell != endc; ++cell, ++dg_cell)
     {
       PointHistory<dim> *local_quadrature_points_history
             = reinterpret_cast<PointHistory<dim> *>(cell->user_pointer());
-          
+
       Assert (local_quadrature_points_history >=
                   &quadrature_point_history.front(),
                  ExcInternalError());
       Assert (local_quadrature_points_history <
                   &quadrature_point_history.back(),
                  ExcInternalError());
-    
+
       for (unsigned int i=0; i<dim; i++)
         for (unsigned int j=0; j<dim; j++)
-        {      
+        {
           dg_cell->get_dof_values (history_field[i][j],
                                   local_history_fe_values[i][j]);
 
@@ -553,7 +553,7 @@ general approach to this would go like this:
                                       local_history_fe_values[i][j]);
 
           for (unsigned int q=0; q<quadrature.size(); ++q)
-            local_quadrature_points_history[q].old_stress[i][j] 
+            local_quadrature_points_history[q].old_stress[i][j]
                        = local_history_values_at_qpoints[i][j](q);
       }
   @endcode
index dedc4b17ac9f6d71d947ef31f33b77624be3eab1..18b18fabd3dae8ecab5597a87cd21ccf8e07b039 100644 (file)
@@ -4,12 +4,12 @@
 With all that above, here is first what we get if we just run the program
 without any parameters at all:
 @code
-examples/step-19> ./step-19 
+examples/\step-19> ./\step-19
 
 Converter from deal.II intermediate format to other graphics formats.
 
 Usage:
-    ./step-19 [-p parameter_file] list_of_input_files 
+    ./\step-19 [-p parameter_file] list_of_input_files
               [-x output_format] [-o output_file]
 
 Parameter sequences in brackets can be omitted if a parameter file is
@@ -26,7 +26,7 @@ file):
 set Dummy iterations = 42
 
 # The name of the output file to be generated
-set Output file      = 
+set Output file      =
 
 # A name for the output format to be used
 set Output format    = gnuplot
@@ -126,12 +126,12 @@ with their default values and documentations.
 
 Let us try to run this program on a set of input files generated by a modified
 step-18 run on 32 nodes of a
-cluster. The computation was rather big, with more 
+cluster. The computation was rather big, with more
 than 350,000 cells and some 1.2M unknowns. That makes for 32 rather big
 intermediate files that we will try to merge using the present program. Here is
 the list of files, totaling some 245MB of data:
 @code
-examples/step-19> ls -l *d2
+examples/\step-19> ls -l *d2
 -rw-r--r--  1 bangerth wheeler 7982085 Aug 12 10:11 solution-0005.0000-000.d2
 -rw-r--r--  1 bangerth wheeler 7888316 Aug 12 10:13 solution-0005.0000-001.d2
 -rw-r--r--  1 bangerth wheeler 7715984 Aug 12 10:09 solution-0005.0000-002.d2
@@ -167,14 +167,14 @@ examples/step-19> ls -l *d2
 @endcode
 
 So let's see what happens if we attempt to merge all these files into a single
-one: 
+one:
 @code
-examples/step-19> time ./step-19 solution-0005.0000-*.d2 -x gmv -o solution-0005.gmv  
+examples/\step-19> time ./\step-19 solution-0005.0000-*.d2 -x gmv -o solution-0005.gmv
 real    2m08.35s
 user    1m26.61s
 system  0m05.74s
 
-examples/step-19> ls -l solution-0005.gmv
+examples/\step-19> ls -l solution-0005.gmv
 -rw-r--r--  1 bangerth wheeler 240680494 Sep  9 11:53 solution-0005.gmv
 @endcode
 So in roughly two minutes we have merged 240MB of data. Counting reading and
@@ -182,12 +182,12 @@ writing, that averages a throughput of 3.8MB per second, not so bad.
 
 
 
-If visualized, the output looks very much like that shown for 
+If visualized, the output looks very much like that shown for
 step-18. But that's not quite as
 important for the moment, rather we are interested in showing how to use the
 parameter file. To this end, remember that if no parameter file is given, or if
 it is empty, all the default values listed above are used. However, whatever we
-specify in the parameter file is used, unless overridden again by 
+specify in the parameter file is used, unless overridden again by
 parameters found later on the command line.
 
 
@@ -201,9 +201,9 @@ If we run step-19 with it again, we obtain this (for simplicity, and because we
 don't want to visualize 240MB of data anyway, we only convert the one, the
 twelfth, intermediate file to gnuplot format):
 @code
-examples/step-19> ./step-19 solution-0005.0000-012.d2 -p solution-0005.prm -o solution-0005.gnuplot
+examples/\step-19> ./\step-19 solution-0005.0000-012.d2 -p solution-0005.prm -o solution-0005.gnuplot
 
-examples/step-19> ls -l solution-0005.gnuplot
+examples/\step-19> ls -l solution-0005.gnuplot
 -rw-r--r--  1 bangerth wheeler 20281669 Sep  9 12:15 solution-0005.gnuplot
 @endcode
 
@@ -236,7 +236,7 @@ following a hashmark (<code>#</code>) is considered a comment.
 
 If one runs step-19 with this input file, this is what is going to happen:
 @code
-examples/step-19> ./step-19 solution-0005.0000-012.d2 -p solution-0005.prm
+examples/\step-19> ./\step-19 solution-0005.0000-012.d2 -p solution-0005.prm
 Line 4:
     The entry value
         -13
index 6f209e32c06684ea49d698f843d9a6b3f7857530..1a8da2db93f47c1bef106f82313824e6191fd360 100644 (file)
@@ -6,7 +6,7 @@ href="http://www.gnuplot.info/">GNUPLOT</a> (one of the simpler visualization
 programs; maybe not the easiest to use since it is command line driven, but
 also universally available on all linux and other unix-like systems):
 @code
-examples/step-2> gnuplot
+examples/\step-2> gnuplot
 
         G N U P L O T
         Version 3.7 patchlevel 3
index 4ea4ae7634c8af3f897db769443986a1dfd4e214..d07e4c3df3ec69cbc7e0c09e7790670aa9dd694b 100644 (file)
@@ -5,11 +5,11 @@
 
 If we run the program as is, we get this output:
 @code
-examples/step-20> make run
+examples/\step-20> make run
 ============================ Remaking Makefile.dep
-==============debug========= step-20.cc
-============================ Linking step-20
-============================ Running step-20
+==============debug========= \step-20.cc
+============================ Linking \step-20
+============================ Running \step-20
 Number of active cells: 64
 Total number of cells: 85
 Number of degrees of freedom: 208 (144+64)
@@ -180,7 +180,7 @@ the behavior of fluids in sandstone: in most of the domain, the sandstone is
 homogenous and, while permeably to fluids, not overly so; on the other stone,
 the stone has cracked, or faulted, along one line, and the fluids flow much
 easier along this large crask. Here is how we could implement something like
-this: 
+this:
 @code
 template <int dim>
 void
@@ -196,12 +196,12 @@ KInverse<dim>::value_list (const std::vector<Point<dim> > &points,
 
       const double distance_to_flowline
         = std::fabs(points[p][1]-0.2*std::sin(10*points[p][0]));
-      
+
       const double permeability = std::max(std::exp(-(distance_to_flowline*
                                                       distance_to_flowline)
                                                     / (0.1 * 0.1)),
                                            0.001);
-      
+
       for (unsigned int d=0; d<dim; ++d)
        values[p][d][d] = 1./permeability;
     }
@@ -212,7 +212,7 @@ Remember that the function returns the inverse of the permeability tensor.
 
 
 With a significantly higher mesh resolution, we can visualize this, here with
-x- and y-velocity: 
+x- and y-velocity:
 
 
 @image html step-20.u-wiggle.png
@@ -237,7 +237,7 @@ class KInverse : public TensorFunction<2,dim>
 {
   public:
     KInverse ();
-    
+
     virtual void value_list (const std::vector<Point<dim> > &points,
                             std::vector<Tensor<2,dim> >    &values) const;
 
@@ -247,7 +247,7 @@ class KInverse : public TensorFunction<2,dim>
 
 
 template <int dim>
-KInverse<dim>::KInverse () 
+KInverse<dim>::KInverse ()
 {
   const unsigned int N = 40;
   centers.resize (N);
@@ -273,10 +273,10 @@ KInverse<dim>::value_list (const std::vector<Point<dim> > &points,
       for (unsigned int i=0; i<centers.size(); ++i)
         permeability += std::exp(-(points[p]-centers[i]).square()
                                  / (0.1 * 0.1));
-      
+
       const double normalized_permeability
         = std::max(permeability, 0.005);
-      
+
       for (unsigned int d=0; d<dim; ++d)
        values[p][d][d] = 1./normalized_permeability;
     }
index 6c934f8e5d4c5befcba0ce7090725c56812d1888..03cc5f6819fab6828efb6e4afa423ac67c0a5ddf 100644 (file)
@@ -9,11 +9,11 @@ Running the program with the space dimension set to 2 in <code>main()</code>
 yields the following output (when the flag is set to optimized in the
 Makefile):
 @code
-examples/step-22> make run
+examples/\step-22> make run
 ============================ Remaking Makefile.dep
-==============optimized===== step-22.cc
-============================ Linking step-22
-============================ Running step-22
+==============optimized===== \step-22.cc
+============================ Linking \step-22
+============================ Running \step-22
 Refinement cycle 0
    Number of active cells: 64
    Number of degrees of freedom: 679 (594+85)
@@ -186,7 +186,7 @@ We will address the question of how possibly to improve our solver <a
 href="#improved-solver">below</a>.
 
 As for the graphical output, the grids generated during the solution
-look as follow: 
+look as follow:
 
 <TABLE WIDTH="60%" ALIGN="center">
   <tr>
@@ -250,7 +250,7 @@ refinement in two dimensions:
 @image html step-22.2d.sparsity-nor.png
 
 In order to generate such a graph, you have to insert a piece of
-code like the following to the end of the setup step. 
+code like the following to the end of the setup step.
 @code
   {
     std::ofstream out ("sparsity_pattern.gpl");
@@ -284,7 +284,7 @@ look at a sparsity pattern in 3D. We show only the (0,0) block of the
 matrix, again after one adaptive refinement. Apart from the fact that the matrix
 size has increased, it is also visible that there are many more entries
 in the matrix. Moreover, even for the optimized renumbering, there will be a
-considerable amount of tentative fill-in elements. This illustrates why UMFPACK 
+considerable amount of tentative fill-in elements. This illustrates why UMFPACK
 is not a good choice in 3D - a full decomposition needs many new entries that
  eventually won't fit into the physical memory (RAM):
 
@@ -308,25 +308,25 @@ the 2D case where we precondition $A$ with a direct solver and the
 <code>vmult</code> operation of the inverse matrix structure will converge in
 one single CG step, but this changes in 3D where we only use an ILU
 preconditioner.  There, the number of required preconditioned CG steps to
-invert $A$ increases as the mesh is refined, and each <code>vmult</code> 
+invert $A$ increases as the mesh is refined, and each <code>vmult</code>
 operation involves on average approximately 14, 23, 36, 59, 75 and 101 inner
 CG iterations in the refinement steps shown above. (On the other hand,
 the number of iterations for applying the inverse pressure mass matrix is
-always around five, both in two and three dimensions.)  To summarize, most work 
+always around five, both in two and three dimensions.)  To summarize, most work
 is spent on solving linear systems with the same matrix $A$ over and over again.
-What makes this look even worse is the fact that we 
+What makes this look even worse is the fact that we
 actually invert a matrix that is about 95 precent the size of the total system
 matrix and stands for 85 precent of the non-zero entries in the sparsity
 pattern. Hence, the natural question is whether it is reasonable to solve a
-linear system with matrix $A$ for about 15 times when calculating the solution 
+linear system with matrix $A$ for about 15 times when calculating the solution
 to the block system.
-  
+
 The answer is, of course, that we can do that in a few other (most of the time
 better) ways.
 Nevertheless, it has to be remarked that an indefinite system as the one
 at hand puts indeed much higher
 demands on the linear algebra than standard elliptic problems as we have seen
-in the early tutorial programs. The improvements are still rather 
+in the early tutorial programs. The improvements are still rather
 unsatisfactory, if one compares with an elliptic problem of similar
 size. Either way, we will introduce below a number of improvements to the
 linear solver, a discussion that we will re-consider again with additional
@@ -341,10 +341,10 @@ already mentioned in the in-code comments. The DoFRenumbering namespace compares
 several choices for the renumbering of dofs for the Stokes equations. The best
 result regarding the computing time was found for the King ordering, which is
 accessed through the call DoFRenumbering::boost::king_ordering. With that
-program, the inner solver needs considerably less operations, e.g. about 62 
-inner CG iterations for the inversion of $A$ at cycle 4 compared to about 75 
-iterations with the standard Cuthill-McKee-algorithm. Also, the computing time 
-at cycle 4 decreased from about 17 to 11 minutes for the <code>solve()</code> 
+program, the inner solver needs considerably less operations, e.g. about 62
+inner CG iterations for the inversion of $A$ at cycle 4 compared to about 75
+iterations with the standard Cuthill-McKee-algorithm. Also, the computing time
+at cycle 4 decreased from about 17 to 11 minutes for the <code>solve()</code>
 call. However, the King ordering (and the orderings provided by the
 DoFRenumbering::boost namespace in general) has a serious drawback - it uses
 much more memory than the in-build deal versions, since it acts on abstract
@@ -354,17 +354,17 @@ infeasible algorithm for the last cycle in 3D with 1.2 million
 unknowns.
 
 <h5>Better preconditioner for the inner CG solver</h5>
-Another idea to improve the situation even more would be to choose a 
-preconditioner that makes CG for the (0,0) matrix $A$ converge in a 
+Another idea to improve the situation even more would be to choose a
+preconditioner that makes CG for the (0,0) matrix $A$ converge in a
 mesh-independent number of iterations, say 10 to 30. We have seen such a
 canditate in step-16: multigrid.
 
 <h5>Block Schur complement preconditioner</h5>
-Even with a good preconditioner for $A$, we still 
-need to solve of the same linear system repeatedly (with different 
-right hand sides, though) in order to make the Schur complement solve 
-converge. The approach we are going to discuss here is how inner iteration 
-and outer iteration can be combined. If we persist in calculating the Schur 
+Even with a good preconditioner for $A$, we still
+need to solve of the same linear system repeatedly (with different
+right hand sides, though) in order to make the Schur complement solve
+converge. The approach we are going to discuss here is how inner iteration
+and outer iteration can be combined. If we persist in calculating the Schur
 complement, there is no other possibility.
 
 The alternative is to attack the block system at once and use an approximate
@@ -379,7 +379,7 @@ is simple, then an iterative solver with that preconditioner will converge in a
 few iterations. Using the Schur complement $S = B A^{-1} B^T$, one finds that
 @f{eqnarray*}
   P^{-1}
-  = 
+  =
   \left(\begin{array}{cc}
     A^{-1} & 0 \\ S^{-1} B A^{-1} & -S^{-1}
   \end{array}\right)
@@ -388,14 +388,14 @@ would appear to be a good choice since
 @f{eqnarray*}
   P^{-1}\left(\begin{array}{cc}
     A & B^T \\ B & 0
-  \end{array}\right) 
-  = 
+  \end{array}\right)
+  =
   \left(\begin{array}{cc}
     A^{-1} & 0 \\ S^{-1} B A^{-1} & -S^{-1}
   \end{array}\right)\cdot \left(\begin{array}{cc}
     A & B^T \\ B & 0
-  \end{array}\right) 
-  = 
+  \end{array}\right)
+  =
   \left(\begin{array}{cc}
     I & A^{-1} B^T \\ 0 & I
   \end{array}\right).
@@ -409,7 +409,7 @@ method is bounded by the number of distinct eigenvalues). Below, we will
 discuss the choice of an adequate solver for this problem. First, we are
 going to have a closer look at the implementation of the preconditioner.
 
-Since $P$ is aimed to be a preconditioner only, we shall use approximations to 
+Since $P$ is aimed to be a preconditioner only, we shall use approximations to
 the inverse of the Schur complement $S$ and the matrix $A$. Hence, the Schur
 complement will be approximated by the pressure mass matrix $M_p$, and we use
 a preconditioner to $A$ (without an InverseMatrix class around it) for
@@ -433,10 +433,10 @@ class BlockSchurPreconditioner : public Subscriptor
 
   private:
     const SmartPointer<const BlockSparseMatrix<double> > system_matrix;
-    const SmartPointer<const InverseMatrix<SparseMatrix<double>, 
+    const SmartPointer<const InverseMatrix<SparseMatrix<double>,
                        PreconditionerMp > > m_inverse;
     const PreconditionerA &a_preconditioner;
-    
+
     mutable Vector<double> tmp;
 
 };
@@ -455,7 +455,7 @@ BlockSchurPreconditioner<PreconditionerA, PreconditionerMp>::BlockSchurPrecondit
 {}
 
         // Now the interesting function, the multiplication of
-        // the preconditioner with a BlockVector. 
+        // the preconditioner with a BlockVector.
 template <class PreconditionerA, class PreconditionerMp>
 void BlockSchurPreconditioner<PreconditionerA, PreconditionerMp>::vmult (
                                      BlockVector<double>       &dst,
@@ -463,13 +463,13 @@ void BlockSchurPreconditioner<PreconditionerA, PreconditionerMp>::vmult (
 {
         // Form u_new = A^{-1} u
   a_preconditioner.vmult (dst.block(0), src.block(0));
-        // Form tmp = - B u_new + p 
+        // Form tmp = - B u_new + p
         // (<code>SparseMatrix::residual</code>
         // does precisely this)
   system_matrix->block(1,0).residual(tmp, dst.block(0), src.block(1));
         // Change sign in tmp
   tmp *= -1;
-        // Multiply by approximate Schur complement 
+        // Multiply by approximate Schur complement
         // (i.e. a pressure mass matrix)
   m_inverse->vmult (dst.block(1), tmp);
 }
@@ -488,9 +488,9 @@ problem at hand. One choice is the solver @ref SolverBicgstab "BiCGStab", which
 was used for the solution of the unsymmetric advection problem in step-9. The
 second option, the one we are going to choose, is @ref SolverGMRES "GMRES"
 (generalized minimum residual). Both methods have their pros and cons - there
-are problems where one of the two candidates clearly outperforms the other, and 
+are problems where one of the two candidates clearly outperforms the other, and
 vice versa.
-<a href="http://en.wikipedia.org/wiki/GMRES#Comparison_with_other_solvers">Wikipedia</a>'s 
+<a href="http://en.wikipedia.org/wiki/GMRES#Comparison_with_other_solvers">Wikipedia</a>'s
 article on the GMRES method gives a comparative presentation.
 A more comprehensive and well-founded comparsion can be read e.g. in the book by
 J.W. Demmel (Applied Numerical Linear Algebra, SIAM, 1997, section 6.6.6).
@@ -499,17 +499,17 @@ For our specific problem with the ILU preconditioner for $A$, we certainly need
 to perform hundreds of iterations on the block system for large problem sizes
 (we won't beat CG!). Actually, this disfavors GMRES: During the GMRES
 iterations, a basis of Krylov vectors is successively built up and some
-operations are performed on these vectors. The more vectors are in this basis, 
+operations are performed on these vectors. The more vectors are in this basis,
 the more operations and memory will be needed. The number of operations scales
-as ${\cal O}(n + k^2)$ and memory as ${\cal O}(kn)$, where $k$ is the number of 
+as ${\cal O}(n + k^2)$ and memory as ${\cal O}(kn)$, where $k$ is the number of
 vectors in the Krylov basis and $n$ the size of the (block) matrix.
 To not let these demands grow excessively, deal.II limits the size $k$ of the
 basis to 30 vectors by default.
 Then, the basis is rebuilt. This implementation of the GMRES method is called
-GMRES(k), with default $k=30$. What we have gained by this restriction, 
+GMRES(k), with default $k=30$. What we have gained by this restriction,
 namely a bound on operations and memory requirements, will be compensated by
 the fact that we use an incomplete basis - this will increase the number of
-required iterations. 
+required iterations.
 
 BiCGStab, on the other hand, won't get slower when many iterations are needed
 (one iteration uses only results from one preceeding step and
@@ -519,25 +519,25 @@ CG or GMRES), there is one main reason which makes BiCGStab not appropriate for
 this problem: The preconditioner applies the inverse of the pressure
 mass matrix by using the InverseMatrix class. Since the application of the
 inverse matrix to a vector is done only in approximative way (an exact inverse
-is too expensive), this will also affect the solver. In the case of BiCGStab, 
+is too expensive), this will also affect the solver. In the case of BiCGStab,
 the Krylov vectors will not be orthogonal due to that perturbation. While
 this is uncritical for a small number of steps (up to about 50), it ruins the
 performance of the solver when these perturbations have grown to a significant
 magnitude in the coarse of iterations.
 
 We did some experiments with BiCGStab and found it to
-be faster than GMRES up to refinement cycle 3 (in 3D), but it became very slow 
+be faster than GMRES up to refinement cycle 3 (in 3D), but it became very slow
 for cycles 4 and 5 (even slower than the original Schur complement), so the
 solver is useless in this situation. Choosing a sharper tolerance for the
-inverse matrix class (<code>1e-10*src.l2_norm()</code> instead of 
-<code>1e-6*src.l2_norm()</code>) made BiCGStab perform well also for cycle 4, 
+inverse matrix class (<code>1e-10*src.l2_norm()</code> instead of
+<code>1e-6*src.l2_norm()</code>) made BiCGStab perform well also for cycle 4,
 but did not change the failure on the very large problems.
 
 GMRES is of course also effected by the approximate inverses, but it is not as
 sensitive to orthogonality and retains a relatively good performance also for
 large sizes, see the results below.
 
-With this said, we turn to the realization of the solver call with GMRES with 
+With this said, we turn to the realization of the solver call with GMRES with
 $k=100$ temporary vectors:
 
 @code
@@ -547,36 +547,36 @@ $k=100$ temporary vectors:
       system_matrix.block(1,1) = 0;
 
       SparseILU<double> pmass_preconditioner;
-      pmass_preconditioner.initialize (pressure_mass_matrix, 
+      pmass_preconditioner.initialize (pressure_mass_matrix,
         SparseILU<double>::AdditionalData());
-      
+
       InverseMatrix<SparseMatrix<double>,SparseILU<double> >
         m_inverse (pressure_mass_matrix, pmass_preconditioner);
 
       BlockSchurPreconditioner<typename InnerPreconditioner<dim>::type,
-                               SparseILU<double> > 
+                               SparseILU<double> >
         preconditioner (system_matrix, m_inverse, *A_preconditioner);
-      
+
       SolverControl solver_control (system_matrix.m(),
                                     1e-6*system_rhs.l2_norm());
       GrowingVectorMemory<BlockVector<double> > vector_memory;
       SolverGMRES<BlockVector<double> >::AdditionalData gmres_data;
       gmres_data.max_n_tmp_vectors = 100;
-      
+
       SolverGMRES<BlockVector<double> > gmres(solver_control, vector_memory,
                                               gmres_data);
-      
+
       gmres.solve(system_matrix, solution, system_rhs,
                   preconditioner);
-      
+
       constraints.distribute (solution);
-      
+
       std::cout << " "
                 << solver_control.last_step()
                 << " block GMRES iterations";
 @endcode
 
-Obviously, one needs to add the include file @ref SolverGMRES 
+Obviously, one needs to add the include file @ref SolverGMRES
 "<lac/solver_gmres.h>" in order to make this run.
 We call the solver with a BlockVector template in order to enable
 GMRES to operate on block vectors and matrices.
@@ -595,7 +595,7 @@ Let's first see the results in 2D:
 @code
 Refinement cycle 0
    Number of active cells: 64
-   Number of degrees of freedom: 679 (594+85) [0.005999 s] 
+   Number of degrees of freedom: 679 (594+85) [0.005999 s]
    Assembling... [0.002 s]
    Computing preconditioner... [0.003 s]
    Solving...
@@ -605,7 +605,7 @@ Refinement cycle 0
 
 Refinement cycle 1
    Number of active cells: 160
-   Number of degrees of freedom: 1683 (1482+201) [0.013998 s] 
+   Number of degrees of freedom: 1683 (1482+201) [0.013998 s]
    Assembling... [0.005999 s]
    Computing preconditioner... [0.012998 s]
    Solving...
@@ -615,7 +615,7 @@ Refinement cycle 1
 
 Refinement cycle 2
    Number of active cells: 376
-   Number of degrees of freedom: 3813 (3370+443) [0.031995 s] 
+   Number of degrees of freedom: 3813 (3370+443) [0.031995 s]
    Assembling... [0.014998 s]
    Computing preconditioner... [0.044994 s]
    Solving...
@@ -625,7 +625,7 @@ Refinement cycle 2
 
 Refinement cycle 3
    Number of active cells: 880
-   Number of degrees of freedom: 8723 (7722+1001) [0.074988 s] 
+   Number of degrees of freedom: 8723 (7722+1001) [0.074988 s]
    Assembling... [0.035995 s]
    Computing preconditioner... [0.110983 s]
    Solving...
@@ -635,7 +635,7 @@ Refinement cycle 3
 
 Refinement cycle 4
    Number of active cells: 2008
-   Number of degrees of freedom: 19383 (17186+2197) [0.180973 s] 
+   Number of degrees of freedom: 19383 (17186+2197) [0.180973 s]
    Assembling... [0.081987 s]
    Computing preconditioner... [0.315952 s]
    Solving...
@@ -645,7 +645,7 @@ Refinement cycle 4
 
 Refinement cycle 5
    Number of active cells: 4288
-   Number of degrees of freedom: 40855 (36250+4605) [0.386941 s] 
+   Number of degrees of freedom: 40855 (36250+4605) [0.386941 s]
    Assembling... [0.171974 s]
    Computing preconditioner... [0.766883 s]
    Solving...
@@ -666,7 +666,7 @@ The picture of course changes in 3D:
 @code
 Refinement cycle 0
    Number of active cells: 32
-   Number of degrees of freedom: 1356 (1275+81) [0.025996 s] 
+   Number of degrees of freedom: 1356 (1275+81) [0.025996 s]
    Assembling... [0.056992 s]
    Computing preconditioner... [0.027995 s]
    Solving...
@@ -676,7 +676,7 @@ Refinement cycle 0
 
 Refinement cycle 1
    Number of active cells: 144
-   Number of degrees of freedom: 5088 (4827+261) [0.102984 s] 
+   Number of degrees of freedom: 5088 (4827+261) [0.102984 s]
    Assembling... [0.254961 s]
    Computing preconditioner... [0.161976 s]
    Solving...
@@ -686,7 +686,7 @@ Refinement cycle 1
 
 Refinement cycle 2
    Number of active cells: 704
-   Number of degrees of freedom: 22406 (21351+1055) [0.52592 s] 
+   Number of degrees of freedom: 22406 (21351+1055) [0.52592 s]
    Assembling... [1.24481 s]
    Computing preconditioner... [0.948856 s]
    Solving...
@@ -696,7 +696,7 @@ Refinement cycle 2
 
 Refinement cycle 3
    Number of active cells: 3168
-   Number of degrees of freedom: 93176 (89043+4133) [2.66759 s] 
+   Number of degrees of freedom: 93176 (89043+4133) [2.66759 s]
    Assembling... [5.66014 s]
    Computing preconditioner... [4.69529 s]
    Solving...
@@ -706,7 +706,7 @@ Refinement cycle 3
 
 Refinement cycle 4
    Number of active cells: 11456
-   Number of degrees of freedom: 327808 (313659+14149) [12.0242 s] 
+   Number of degrees of freedom: 327808 (313659+14149) [12.0242 s]
    Assembling... [20.2669 s]
    Computing preconditioner... [17.3384 s]
    Solving...
@@ -716,7 +716,7 @@ Refinement cycle 4
 
 Refinement cycle 5
    Number of active cells: 45056
-   Number of degrees of freedom: 1254464 (1201371+53093) [89.8533 s] 
+   Number of degrees of freedom: 1254464 (1201371+53093) [89.8533 s]
    Assembling... [80.3588 s]
    Computing preconditioner... [73.0849 s]
    Solving...
@@ -731,8 +731,8 @@ because GMRES(k) scales worse with the problem size than CG, as we discussed
 above.  Nonetheless, the improvement by a factor of 3-5 for moderate problem
 sizes is quite impressive.
 
-<h5>Combining block preconditioner and multigrid</h5> 
-An ultimate linear solver for this problem could be imagined as a 
+<h5>Combining block preconditioner and multigrid</h5>
+An ultimate linear solver for this problem could be imagined as a
 combination of an optimal
 preconditioner for $A$ (e.g. multigrid) and the block preconditioner
 described above, which is the approach taken in the step-31
@@ -768,14 +768,14 @@ BoundaryValues<dim>::value (const Point<dim>  &p,
           ExcIndexRange (component, 0, this->n_components));
 
   const double x_offset = std::atan(p[1]*4)/3;
-                                                                   
+
   if (component == 0)
     return (p[0] < x_offset ? -1 : (p[0] > x_offset ? 1 : 0));
   return 0;
 }
 @endcode
 and the following way to generate the mesh as the domain
-$[-2,2]\times[-2,2]\times[-1,0]$ 
+$[-2,2]\times[-2,2]\times[-1,0]$
 @code
     std::vector<unsigned int> subdivisions (dim, 1);
     subdivisions[0] = 4;
@@ -788,7 +788,7 @@ $[-2,2]\times[-2,2]\times[-1,0]$
     const Point<dim> top_right   = (dim == 2 ?
                                     Point<dim>(2,0) :
                                     Point<dim>(2,2,0));
-    
+
     GridGenerator::subdivided_hyper_rectangle (triangulation,
                                                subdivisions,
                                                bottom_left,
index f25c22e9448908ae3a1c2f7d6a80ef1f4203c1a0..f9a9b4992cdae8415fe31ab2da167b25ec26c66f 100644 (file)
@@ -8,8 +8,8 @@ components of the program take, are given in the @ref hp_paper .
 When run, this is what the program produces:
 
 @code
-examples/step-27> make run
-============================ Running step-27
+examples/\step-27> make run
+============================ Running \step-27
 Cycle 0:
    Number of active cells:       768
    Number of degrees of freedom: 3264
index de9c44977a40b56e183be6b755da6f7ff6d42b7f..3274a41ee29f6effeedc0946ea6f30c65cb2547d 100644 (file)
@@ -2,7 +2,7 @@
 <h1>Results</h1>
 
 The current program reads its run-time parameters from an input file
-called <code>step-29.prm</code> that looks like this:
+called <code>\step-29.prm</code> that looks like this:
 @code
 subsection Mesh & geometry parameters
   # Distance of the focal point of the lens to the x-axis
@@ -43,8 +43,8 @@ parameters here and therefore stick with their default values.
 Here's the console output of the program in debug mode:
 
 @code
-examples/step-29> make run
-============================ Running step-29
+examples/\step-29> make run
+============================ Running \step-29
 DEAL::Generating grid... done (1.11607s)
 DEAL::  Number of active cells:  25600
 DEAL::Setting up system... done (1.10807s)
@@ -62,7 +62,7 @@ of the program run much faster whereas solving the linear system is
 hardly sped up at all:
 
 @code
-============================ Running step-29
+============================ Running \step-29
 DEAL::Generating grid... done (0.0280020s)
 DEAL::  Number of active cells:  25600
 DEAL::Setting up system... done (0.112007s)
index a1d89c152e3b198cd1504eca63c9a4b0381ef63b..06c1626db248990a46a0b68fff0e1c2af5692881 100644 (file)
@@ -24,7 +24,7 @@ Apart from the output shown above, the program generated the file
 viewed as follows: invoke GNUPLOT and enter the following sequence of
 commands at its prompt:
 @code
-examples/step-3> gnuplot
+examples/\step-3> gnuplot
 
         G N U P L O T
         Version 3.7 patchlevel 3
@@ -75,7 +75,7 @@ suggestions:
 </p>
 
 <ul>
-  <li> 
+  <li>
   Change the geometry and mesh: In the program, we have generated a square
   domain and mesh by using the <code>GridGenerator::hyper_cube</code>
   function. However, the <code>GridGenerator</code> has a good number of other
@@ -135,7 +135,7 @@ suggestions:
   VectorTools::interpolate_boundary_values (dof_handler,
                                            1,
                                            ConstantFunction<2>(1.),
-                                           boundary_values);    
+                                           boundary_values);
   @endcode
   If you have this call immediately after the first one to this function, then
   it will interpolate boundary values on faces with boundary indicator 1 to the
@@ -192,7 +192,7 @@ suggestions:
   the following code to <code>LaplaceProblem::output_results</code>:
   @code
     std::cout << "Mean value: "
-              << VectorTools::compute_mean_value (dof_handler, 
+              << VectorTools::compute_mean_value (dof_handler,
                                                  QGauss<2>(3),
                                                  solution,
                                                  0)
index 53536d0df8aac6fb512dc2bbee43e371791c285d..de1fac94dfc6f2c9589504104f600c70ab00692c 100644 (file)
@@ -4,7 +4,7 @@ When run, the program simulates convection in 3d in much the same way
 as step-31 did, though with an entirely different testcase.
 
 
-<h3>Comparison of results with step-31</h3>
+<h3>Comparison of results with \step-31</h3>
 
 Before we go to this testcase, however, let us show a few results from a
 slightly earlier version of this program that was solving exactly the
@@ -260,7 +260,7 @@ The last two images show the grid as well as the partitioning of the
 mesh for the last timestep shown into the 10 subdomains used for this
 computation. The full dynamics are really only visible by looking at
 an animation. <a
-href="http://www.math.tamu.edu/~bangerth/images/pictures/convection-outward/step-32.2d.convection.gif">At
+href="http://www.math.tamu.edu/~bangerth/images/pictures/convection-outward/\step-32.2d.convection.gif">At
 this site</a> is such an animation. Beware that this animation is
 about 20MB large, though it is well worth watching due to its almost
 artistic quality.
index b108a71dfcbbd36a5b465dd6dcc64706fb59b1d9..1d2d9a546704c401e5cab54e57a21197f5f168b8 100644 (file)
@@ -3,12 +3,12 @@
 
 We run the problem with the mesh <code>slide.inp</code> (this file is in the
 same directory as the source code for this program) and the following input
-deck (available as <code>input.prm</code> in the same directory): 
+deck (available as <code>input.prm</code> in the same directory):
 @verbatim
 # Listing of Parameters
 # ---------------------
 
-# The input grid 
+# The input grid
 set mesh = slide.inp
 
 # Stabilization parameter
@@ -202,15 +202,15 @@ T=8.32
 
 
 ----------------------------------------------------
-Exception on processing: 
+Exception on processing:
 --------------------------------------------------------
-An error occurred in line <3119> of file <step-33.cc> in function
+An error occurred in line <3119> of file <\step-33.cc> in function
     void ConservationLaw<dim>::run() [with int dim = 2]
-The violated condition was: 
+The violated condition was:
     nonlin_iter <= 10
 The name and call sequence of the exception was:
     ExcMessage ("No convergence in nonlinear solver")
-Additional Information: 
+Additional Information:
 No convergence in nonlinear solver
 --------------------------------------------------------
 
index 765ca4ebcd5c9939d0294997902e18c679e11b36..a24f0d6bab1be0700d2ee4e3ae1e70ba36d26bed 100644 (file)
@@ -2,7 +2,7 @@
 
 <h2>Running the problem</h2>
 
-The problem's input is parameterized by an input file <code>step-36.prm</code>
+The problem's input is parameterized by an input file <code>\step-36.prm</code>
 which could, for example, contain the following text:
 
 @code
@@ -17,8 +17,8 @@ $m,n\in{\mathbb N^+}$. Eigenfunctions are sines and cosines with $m$ and $n$
 periods in $x$ and $y$ directions. This matches the output our program
 generates:
 @code
-examples/step-36> make run
-============================ Running step-36
+examples/\step-36> make run
+============================ Running \step-36
    Number of active cells:       1024
    Number of degrees of freedom: 1089
 
@@ -66,7 +66,7 @@ look like this:
 It is always worth playing a few games in the playground! So here goes
 with a few suggestions:
 
-<ul> 
+<ul>
 
 <li> The potential used above (called the <i>infinite well</i> because
 it is a flat potential surrounded by infinitely high walls) is
@@ -75,14 +75,14 @@ from that, it is rather boring, however. That said, it is trivial to
 play around with the potential by just setting it to something
 different in the input file. For example, let us assume that we wanted
 to work with the following potential in
-2d: 
+2d:
 @f[
-  V(x,y) = \left\{ 
+  V(x,y) = \left\{
        \begin{array}{ll}
-         -100 & \text{if}\ \sqrt{x^2+y^2}<\frac 34 \ \text{and} 
+         -100 & \text{if}\ \sqrt{x^2+y^2}<\frac 34 \ \text{and}
                          \ xy>0
          \\
-         -5 & \text{if}\ \sqrt{x^2+y^2}<\frac 34 \ \text{and} 
+         -5 & \text{if}\ \sqrt{x^2+y^2}<\frac 34 \ \text{and}
                          \ xy\le 0
          \\
          0 & \text{otherwise}
@@ -95,10 +95,10 @@ this by using the following in the input file:
 set Potential = if (x^2 + y^2 < 0.75^2, if (x*y > 0, -100, -5), 0)
 @endcode
 If in addition we also increase the mesh refinement by one level, we get the
-following results: 
+following results:
 @code
-examples/step-36> make run
-============================ Running step-36
+examples/\step-36> make run
+============================ Running \step-36
    Number of active cells:       4096
    Number of degrees of freedom: 4225
 
index 4a2e30bd5c0f31ebe7cc7b7757d4655901c1a09e..171d21eb673c25529c69a65b1d9b7ac2bc238b5e 100644 (file)
@@ -35,7 +35,7 @@ Cycle 5:
    Number of degrees of freedom: 20609
    182 CG iterations needed to obtain convergence.
 --------------------------------------------------------
-An error occurred in line <273> of file <step-5.cc> in function
+An error occurred in line <273> of file <\step-5.cc> in function
     void Coefficient<dim>::value_list(const std::vector<Point<dim>, std::allocator<Point<dim> > >&, std::vector<double, std::allocator<double> >&, unsigned int)
  const [with int dim = 2]
 The violated condition was:
@@ -47,8 +47,8 @@ Dimension 1 not equal to 2
 
 Stacktrace:
 -----------
-#0  ./step-5: Coefficient<2>::value_list(std::vector<Point<2>, std::allocator<Point<2> > > const&, std::vector<double, std::allocator<double> >&, unsigned) const
-#1  ./step-5: main
+#0  ./\step-5: Coefficient<2>::value_list(std::vector<Point<2>, std::allocator<Point<2> > > const&, std::vector<double, std::allocator<double> >&, unsigned) const
+#1  ./\step-5: main
 --------------------------------------------------------
 make: *** [run] Aborted
 @endcode
@@ -107,7 +107,7 @@ example.
 As for the error &mdash; let's look at it again:
 @code
 --------------------------------------------------------
-An error occurred in line <273> of file <step-5.cc> in function
+An error occurred in line <273> of file <\step-5.cc> in function
     void Coefficient<dim>::value_list(const std::vector<Point<dim>, std::allocator<Point<dim> > >&, std::vector<double, std::allocator<double> >&, unsigned int)
  const [with int dim = 2]
 The violated condition was:
@@ -119,8 +119,8 @@ Dimension 1 not equal to 2
 
 Stacktrace:
 -----------
-#0  ./step-5: Coefficient<2>::value_list(std::vector<Point<2>, std::allocator<Point<2> > > const&, std::vector<double, std::allocator<double> >&, unsigned) const
-#1  ./step-5: main
+#0  ./\step-5: Coefficient<2>::value_list(std::vector<Point<2>, std::allocator<Point<2> > > const&, std::vector<double, std::allocator<double> >&, unsigned) const
+#1  ./\step-5: main
 --------------------------------------------------------
 make: *** [run] Aborted
 @endcode
index 2ed4ac63d4cca8c6e76ffd404a1d3b5258929db8..500c483c9e7b8076d64ac6ad37a3c3a1ed78e467 100644 (file)
@@ -130,10 +130,10 @@ Stacktrace:
 -----------
 #0  /u/bangerth/p/deal.II/1/deal.II/lib/libbase.g.so: Subscriptor::~Subscriptor()
 #1  /u/bangerth/p/deal.II/1/deal.II/lib/libdeal_II_2d.g.so: FiniteElement<2>::~FiniteElement()
-#2  ./step-6: FE_Poly<TensorProductPolynomials<2>, 2>::~FE_Poly()
-#3  ./step-6: FE_Q<2>::~FE_Q()
-#4  ./step-6: Step6<2>::~Step6()
-#5  ./step-6: main
+#2  ./\step-6: FE_Poly<TensorProductPolynomials<2>, 2>::~FE_Poly()
+#3  ./\step-6: FE_Q<2>::~FE_Q()
+#4  ./\step-6: Step6<2>::~Step6()
+#5  ./\step-6: main
 --------------------------------------------------------
 make: *** [run] Aborted
 @endcode
@@ -143,7 +143,7 @@ make: *** [run] Aborted
 From the above error message, we conclude that an object of type
 <code>10DoFHandlerILi2EE</code> is still using the object of type
 <code>4FE_QILi2EE</code>. These are of course <a
-href="http://en.wikipedia.org/wiki/Name_mangling">"mangled" names</a> for 
+href="http://en.wikipedia.org/wiki/Name_mangling">"mangled" names</a> for
 <code>DoFHandler</code> and <code>FE_Q</code>. The mangling works as
 follows: the first number indicates the number of characters of the
 template class, i.e. 10 for <code>DoFHandler</code> and 4
index c7b9712aa22e6bed8174dd61b16529c9c5b6680c..9a8ad4d4089f9792b75170a3f8d443fa66cd7105 100644 (file)
@@ -5,7 +5,7 @@ The program generates two kinds of output. The first are the output
 files <code>solution-adaptive-q1.gmv</code>,
 <code>solution-global-q1.gmv</code>, and
 <code>solution-global-q2.gmv</code>. We show the latter in a 3d view
-here: 
+here:
 
 
 @image html step-7.solution.png
@@ -18,8 +18,8 @@ screen while running:
 
 
 @code
-examples/step-7> make run
-============================ Running step-7
+examples/\step-7> make run
+============================ Running \step-7
 Solving with Q1 elements, adaptive refinement
 =============================================
 
@@ -45,14 +45,14 @@ Cycle 6:
    Number of active cells:       466
    Number of degrees of freedom: 543
 
-cycle cells dofs    L2        H1      Linfty   
-    0     4    9 1.198e+00 2.732e+00 1.383e+00 
-    1    13   22 8.795e-02 1.193e+00 1.816e-01 
-    2    31   46 8.147e-02 1.167e+00 1.654e-01 
-    3    64   87 7.702e-02 1.077e+00 1.310e-01 
-    4   127  160 4.643e-02 7.988e-01 6.745e-02 
-    5   244  297 2.470e-02 5.568e-01 3.668e-02 
-    6   466  543 1.622e-02 4.107e-01 2.966e-02 
+cycle cells dofs    L2        H1      Linfty
+    0     4    9 1.198e+00 2.732e+00 1.383e+00
+    1    13   22 8.795e-02 1.193e+00 1.816e-01
+    2    31   46 8.147e-02 1.167e+00 1.654e-01
+    3    64   87 7.702e-02 1.077e+00 1.310e-01
+    4   127  160 4.643e-02 7.988e-01 6.745e-02
+    5   244  297 2.470e-02 5.568e-01 3.668e-02
+    6   466  543 1.622e-02 4.107e-01 2.966e-02
 
 Solving with Q1 elements, global refinement
 ===========================================
@@ -79,23 +79,23 @@ Cycle 6:
    Number of active cells:       16384
    Number of degrees of freedom: 16641
 
-cycle cells dofs     L2        H1      Linfty   
-    0     4     9 1.198e+00 2.732e+00 1.383e+00 
-    1    16    25 8.281e-02 1.190e+00 1.808e-01 
-    2    64    81 8.142e-02 1.129e+00 1.294e-01 
-    3   256   289 2.113e-02 5.828e-01 4.917e-02 
-    4  1024  1089 5.319e-03 2.934e-01 1.359e-02 
-    5  4096  4225 1.332e-03 1.469e-01 3.482e-03 
-    6 16384 16641 3.332e-04 7.350e-02 8.758e-04 
-
-n cells  H1      L2     
-      0     4 2.732e+00    - 1.198e+00     -    - 
-      1    16 1.190e+00 1.20 8.281e-02 14.47 3.86 
-      2    64 1.129e+00 0.08 8.142e-02  1.02 0.02 
-      3   256 5.828e-01 0.95 2.113e-02  3.85 1.95 
-      4  1024 2.934e-01 0.99 5.319e-03  3.97 1.99 
-      5  4096 1.469e-01 1.00 1.332e-03  3.99 2.00 
-      6 16384 7.350e-02 1.00 3.332e-04  4.00 2.00 
+cycle cells dofs     L2        H1      Linfty
+    0     4     9 1.198e+00 2.732e+00 1.383e+00
+    1    16    25 8.281e-02 1.190e+00 1.808e-01
+    2    64    81 8.142e-02 1.129e+00 1.294e-01
+    3   256   289 2.113e-02 5.828e-01 4.917e-02
+    4  1024  1089 5.319e-03 2.934e-01 1.359e-02
+    5  4096  4225 1.332e-03 1.469e-01 3.482e-03
+    6 16384 16641 3.332e-04 7.350e-02 8.758e-04
+
+n cells  H1      L2
+      0     4 2.732e+00    - 1.198e+00     -    -
+      1    16 1.190e+00 1.20 8.281e-02 14.47 3.86
+      2    64 1.129e+00 0.08 8.142e-02  1.02 0.02
+      3   256 5.828e-01 0.95 2.113e-02  3.85 1.95
+      4  1024 2.934e-01 0.99 5.319e-03  3.97 1.99
+      5  4096 1.469e-01 1.00 1.332e-03  3.99 2.00
+      6 16384 7.350e-02 1.00 3.332e-04  4.00 2.00
 
 Solving with Q2 elements, global refinement
 ===========================================
@@ -122,23 +122,23 @@ Cycle 6:
    Number of active cells:       16384
    Number of degrees of freedom: 66049
 
-cycle cells dofs     L2        H1      Linfty   
-    0     4    25 1.433e+00 2.445e+00 1.286e+00 
-    1    16    81 7.912e-02 1.168e+00 1.728e-01 
-    2    64   289 7.755e-03 2.511e-01 1.991e-02 
-    3   256  1089 9.969e-04 6.235e-02 2.764e-03 
-    4  1024  4225 1.265e-04 1.571e-02 3.527e-04 
-    5  4096 16641 1.587e-05 3.937e-03 4.343e-05 
-    6 16384 66049 1.986e-06 9.847e-04 5.402e-06 
-
-n cells  H1      L2     
-      0     4 2.445e+00    - 1.433e+00     -    - 
-      1    16 1.168e+00 1.07 7.912e-02 18.11 4.18 
-      2    64 2.511e-01 2.22 7.755e-03 10.20 3.35 
-      3   256 6.235e-02 2.01 9.969e-04  7.78 2.96 
-      4  1024 1.571e-02 1.99 1.265e-04  7.88 2.98 
-      5  4096 3.937e-03 2.00 1.587e-05  7.97 2.99 
-      6 16384 9.847e-04 2.00 1.986e-06  7.99 3.00 
+cycle cells dofs     L2        H1      Linfty
+    0     4    25 1.433e+00 2.445e+00 1.286e+00
+    1    16    81 7.912e-02 1.168e+00 1.728e-01
+    2    64   289 7.755e-03 2.511e-01 1.991e-02
+    3   256  1089 9.969e-04 6.235e-02 2.764e-03
+    4  1024  4225 1.265e-04 1.571e-02 3.527e-04
+    5  4096 16641 1.587e-05 3.937e-03 4.343e-05
+    6 16384 66049 1.986e-06 9.847e-04 5.402e-06
+
+n cells  H1      L2
+      0     4 2.445e+00    - 1.433e+00     -    -
+      1    16 1.168e+00 1.07 7.912e-02 18.11 4.18
+      2    64 2.511e-01 2.22 7.755e-03 10.20 3.35
+      3   256 6.235e-02 2.01 9.969e-04  7.78 2.96
+      4  1024 1.571e-02 1.99 1.265e-04  7.88 2.98
+      5  4096 3.937e-03 2.00 1.587e-05  7.97 2.99
+      6 16384 9.847e-04 2.00 1.986e-06  7.99 3.00
 @endcode
 
 

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

Douglas Adams


Typeset in Trocchi and Trocchi Bold Sans Serif.