]> https://gitweb.dealii.org/ - dealii.git/commitdiff
Fix numerous doxygen markup problems. 40/head
authorWolfgang Bangerth <bangerth@math.tamu.edu>
Tue, 29 Jul 2014 20:02:15 +0000 (15:02 -0500)
committerWolfgang Bangerth <bangerth@math.tamu.edu>
Tue, 29 Jul 2014 20:02:15 +0000 (15:02 -0500)
Doxygen got bent all out of shape in various places because formulas were opened
but not closed, and a number of other markup problems as well.

doc/news/3.1.0-vs-3.2.0.h
doc/news/5.2.0-vs-6.0.0.h
examples/step-32/doc/results.dox
examples/step-42/doc/intro.dox
examples/step-52/step-52.cc
examples/step-53/step-53.cc
include/deal.II/dofs/dof_tools.h

index 20a2fa00aad12512a1becfdfec095446100431e6..a13caa7ec6297b9cd7d07d81e23177b96e33b1e5 100644 (file)
@@ -57,7 +57,7 @@ All entries are signed with the names of the author.
 
   <li> <p>
        Changed: If in multithreaded mode, the ACE library is now
-       automatically added to the <code>$(LIBS)</code> Makefile
+       automatically added to the <code>\$(LIBS)</code> Makefile
        variable. There is no need anymore for a special clause in your
        Makefile.
        <br>
index d92a0c0bdb9f70743c09387b877ddde834662aac..605e4b6c2934d8b3cc9ee1184c6b796c3f2a3bed 100644 (file)
@@ -46,10 +46,8 @@ inconvenience this causes.
    (GK 2007/08/22)
    </p>
 
-  <li> <p>Changed: Implementing gradients for the class <code
-  class="class">FunctionDerivative</code>, it became evident that its enums for
-  difference formulas clashed with those of <code
-  class="class">AutoDerivativeFunction</code>. Therefore, only the latter
+  <li> <p>Changed: Implementing gradients for the class <code>FunctionDerivative</code>, it became evident that its enums for
+  difference formulas clashed with those of <code>AutoDerivativeFunction</code>. Therefore, only the latter
   survived.
   <br>
   (GK 2007/08/02)
@@ -86,28 +84,15 @@ inconvenience this causes.
 
   <li> <p>
        Changed: Lower dimensional objects have been removed from the
-       hierarchical structure of levels in <code
-       class="class">TriaLevel</code>. Faces, i.e. lines in 2D and
+       hierarchical structure of levels in <code>TriaLevel</code>. Faces, i.e. lines in 2D and
        lines and quads in 3D, have no associated level
        anymore. Therefore, the level argument of some iterator
-       functions have been removed. The affected functions are <code
-       class="class">Triangulation</code>:: <code
-       class="member">begin_raw_face</code>, <code
-       class="member">begin_face</code>, <code
-       class="member">begin_active_face</code> and all <code
-       class="member">last_*_face</code> or <code
-       class="member">end_*_face</code> functions, no matter whether
+       functions have been removed. The affected functions are <code>Triangulation::begin_raw_face</code>, <code>begin_face</code>, <code>begin_active_face</code> and all <code>last_*_face</code> or <code>end_*_face</code> functions, no matter whether
        raw, used or active. Also effected are the direct iterator
-       functions which are related to faces like <code
-       class="member">begin_line</code> in 2D and 3D or <code
-       class="member">begin_quad</code> in 3D. Again, the same applies
-       to <code>last_*</code> and <code
-       class="member">end_*</code>.
-       <br>
-       The respective functions in <code
-       class="class">DoFHandler</code>, <code
-       class="class">hp::DoFHandler</code> and <code
-       class="class">MGDoFHandler</code> have been changed
+       functions which are related to faces like <code>begin_line</code> in 2D and 3D or <code>begin_quad</code> in 3D. Again, the same applies
+       to <code>last_*</code> and <code>end_*</code>.
+       <br>
+       The respective functions in <code>DoFHandler</code>, <code>hp::DoFHandler</code> and <code>MGDoFHandler</code> have been changed
        accordingly.
        <br>
        Nested loops with an outer loop over all levels and an inner
@@ -120,8 +105,7 @@ inconvenience this causes.
 
   <li> <p>
        Changed: In order to facilitate the implementation of hp finite
-       elements, the ordering of boundary DoFs returned by <code 
-       class="member">DoFTools::map_dof_to_boundary_indices</code> has been
+       elements, the ordering of boundary DoFs returned by <code>DoFTools::map_dof_to_boundary_indices</code> has been
        changed. Fortunately, this is a rarely used function so that the effect
        should be limited to only a few programs.
        <br> 
@@ -129,8 +113,7 @@ inconvenience this causes.
        </p>
 
   <li> <p>
-       Changed: The <code
-       class="member">distribute_local_to_global</code> functions have
+       Changed: The <code>distribute_local_to_global</code> functions have
        been moved from the classes implementing accessors to arbitrary
        objects in the triangulation to the cell accessors, to
        facilitate the implementation of hp methods. That means
@@ -142,12 +125,9 @@ inconvenience this causes.
        </p>
 
   <li> <p>
-       Changed: The template argument of the <code
-       class="class">InterGridMap</code> class has been changed. Code
-       like e.g. <code
-       class="class">InterGridMap&lt;DoFHandler,2&gt;</code> must be
-       replaced by <code
-       class="class">InterGridMap&lt;DoFHandler&lt;2&gt; &gt;</code>.
+       Changed: The template argument of the <code>InterGridMap</code> class has been changed. Code
+       like e.g. <code>InterGridMap&lt;DoFHandler,2&gt;</code> must be
+       replaced by <code>InterGridMap&lt;DoFHandler&lt;2&gt; &gt;</code>.
        <br> 
        (RH 2006/02/27)
        </p>
@@ -209,17 +189,13 @@ inconvenience this causes.
        possible. For more information on the new numbering scheme, see
        the <a
        href="http://ganymed.iwr.uni-heidelberg.de/pipermail/dealii/2005/000827.html">announcement</a>
-       on the mailing list.  <br> The ordering of vertices in <code
-       class="class">CellData</code> given to the <code
-       class="member">Triangulation::create_triangulation</code>
+       on the mailing list.  <br> The ordering of vertices in <code>CellData</code> given to the <code>Triangulation::create_triangulation</code>
        function has been changed accordingly. For backward
-       compatibility there is now a new <code
-       class="member">Triangulation::create_triangulation_compatibility</code>
+       compatibility there is now a new <code>Triangulation::create_triangulation_compatibility</code>
        function which takes <code>CellData</code> in the
        old vertex ordering. However, as this function might not be
        supported forever users are advised to change their code to the
-       new numbering scheme and to use the <code
-       class="member">Triangulation::create_triangulation</code>
+       new numbering scheme and to use the <code>Triangulation::create_triangulation</code>
        function.  
        <br> 
        (RH 2005/11/02)
@@ -325,10 +301,8 @@ inconvenience this causes.
        (WB 2006/08/09)
        </p> 
 
-  <li> <p> Changed: The default number of subdivisions in the <code
-       class="member">build_patches</code> functions of the DataOut classes is
-       now part of the parameters read by <code
-       class="member">parse_parameters</code>. This default value is used
+  <li> <p> Changed: The default number of subdivisions in the <code>build_patches</code> functions of the DataOut classes is
+       now part of the parameters read by <code>parse_parameters</code>. This default value is used
        whenever patches with zero subdivisions are being built.
        <br>
        (GK 2006/06/18)
@@ -633,8 +607,7 @@ inconvenience this causes.
        (Ralf B. Schulz 2006/05/10)
        </p>
 
-  <li> <p> Improved: <code>DataOutBase</code>::<code
-       class="member">OutputFormat</code> has a new value <tt>none</tt>,
+  <li> <p> Improved: <code>DataOutBase</code>::<code>OutputFormat</code> has a new value <tt>none</tt>,
        writing no output at all. This way, the writing of output files can be
        controlled more easily from parameter files.
        <br>
@@ -655,8 +628,7 @@ inconvenience this causes.
        (WB 2006/03/24)
        </p>
 
-  <li> <p> New: The new <code
-       class="member">deal_II_numbers::is_finite</code> function can
+  <li> <p> New: The new <code>deal_II_numbers::is_finite</code> function can
        be used to check whether a floating point number is finite,
        i.e. neither plus or minus infinite nor NaN (not a number);
        it is in the new include file <tt>base/numbers.h</tt>, which will
@@ -671,15 +643,13 @@ inconvenience this causes.
        (WB 2006/03/14)
        </p>
 
-  <li> <p> Improved: The function <code>Subscriptor</code>::<code
-       class="member">list_subscribers</code> logs all current subscribers of an
+  <li> <p> Improved: The function <code>Subscriptor</code>::<code>list_subscribers</code> logs all current subscribers of an
        object to <tt>deallog</tt>.
        <br>
        (GK 2006/03/08)
        </p>
 
-  <li> <p>Fixed: Writing a denormal "NaN" through <code
-       class="class">LogStream</code> objects such as 
+  <li> <p>Fixed: Writing a denormal "NaN" through <code>LogStream</code> objects such as 
        <code>deallog</code> erroneously printed zero, rather
        than "nan". This is now fixed.
        <br>
@@ -730,8 +700,7 @@ inconvenience this causes.
        (WB 2006/02/12)
        </p>
 
-  <li> <p>Improved: A new function <code>TableBase</code>::<code
-       class="member">fill</code>, filling the whole table with the same
+  <li> <p>Improved: A new function <code>TableBase</code>::<code>fill</code>, filling the whole table with the same
        element has been introduced.
        <br>
        (GK 2006/01/18)
@@ -761,16 +730,14 @@ inconvenience this causes.
 
   <li> <p>
        Fixed: The computation of <code>HMIN</code> and
-       <code>HMAX</code> in <code
-       class="member">DataOutBase::write_povray</code> has been
+       <code>HMAX</code> in <code>DataOutBase::write_povray</code> has been
        wrong. This is now fixed.
        <br>
        (RH 2005/11/02)
        </p>
 
   <li> <p>
-       Fixed: <code
-       class="member">DataOutBase&lt;2,3&gt;::write_tecplot_binary</code>
+       Fixed: <code>DataOutBase&lt;2,3&gt;::write_tecplot_binary</code>
        did not write the <code>z</code> coordinates. This is now
        fixed.
        <br>
@@ -778,21 +745,15 @@ inconvenience this causes.
        </p>
 
   <li> <p>
-       Fixed: The <tt>tecplot_binary</tt> <code
-       class="class">OutputFormat</code> has been added to <code
-       class="member">DataOutBase::get_output_format_names</code>. Now
-       an exception will be raised if <code
-       class="member">write_tecplot_binary</code> is invoked without
-       specifying the filename through the <code
-       class="class">DataOutBase::TecplotFlags</code> interface.
+       Fixed: The <tt>tecplot_binary</tt> <code>OutputFormat</code> has been added to <code>DataOutBase::get_output_format_names</code>. Now
+       an exception will be raised if <code>write_tecplot_binary</code> is invoked without
+       specifying the filename through the <code>DataOutBase::TecplotFlags</code> interface.
        <br> 
        (RH 2005/09/23)
        </p>
 
   <li> <p>
-       New: There are now new <code
-       class="member">get_n_mpi_processes</code> and <code
-       class="member">get_this_mpi_process</code> functions in the
+       New: There are now new <code>get_n_mpi_processes</code> and <code>get_this_mpi_process</code> functions in the
        <code>Utilities::System</code> namespace. In case
        of a code not running in parallel, they simply return 1 and 0,
        respectively.
@@ -807,8 +768,7 @@ inconvenience this causes.
 <h3>lac</h3>
 
 <ol>
-  <li> <p>Changed: The <code
-       class="class">CompressedBlockSparsityPattern</code> has been renamed to
+  <li> <p>Changed: The <code>CompressedBlockSparsityPattern</code> has been renamed to
        <code>BlockCompressedSparsityPattern</code> to be
        consistent, since the "block" part builds on the "compressed sparsity
        pattern", not the other way around. The old name remains as a typedef,
@@ -818,11 +778,9 @@ inconvenience this causes.
        </p>
 
   <li> <p>New: The <code>CompressedSetSparsityPattern</code>
-       class is an alternative to the <code
-       class="class">CompressedSparsityPattern</code> class that appears to be
+       class is an alternative to the <code>CompressedSparsityPattern</code> class that appears to be
        better suited for problems that have many entries per row. There is also
-       a block version, <code
-       class="class">BlockCompressedSetSparsityPattern</code>. The two new
+       a block version, <code>BlockCompressedSetSparsityPattern</code>. The two new
        classes can used in all places where a regular compressed sparsity
        pattern can also be used.
        <br>
@@ -840,8 +798,7 @@ inconvenience this causes.
        to run the sparse direct solver as a separate program (the
        <code>detached_ma27</code> program) rather than as part of the current
        program in order to be able to run several instances of it in parallel
-       during multithreaded computations. However, the destructor of the <code
-       class="member">SparseDirectMA27</code> class had a bug that when using
+       during multithreaded computations. However, the destructor of the <code>SparseDirectMA27</code> class had a bug that when using
        this detached mode led to a segmentation fault. This is now fixed.
        <br>
        (WB 2007/02/09)
@@ -869,8 +826,7 @@ inconvenience this causes.
        (Florian Prill 2006/12/18)
        </p>
 
-  <li> <p>Improved: The <code
-       class="class">SparsityPattern</code> class would produce
+  <li> <p>Improved: The <code>SparsityPattern</code> class would produce
        segmentation faults if one tried to allocate a matrix with more
        than about 4.2 billion elements (i.e. the number that one can
        store in a 32-bit unsigned integer). This is now fixed: if you
@@ -887,18 +843,15 @@ inconvenience this causes.
        (WB 2006/12/14)
        </p>
 
-  <li> <p>New: The class <code
-       class="class">PointerMatrixVector</code> implements the functions
-       <code>vmult</code> and <code
-       class="member">Tvmult</code> for a <i>1xn</i>-matrix represented by
+  <li> <p>New: The class <code>PointerMatrixVector</code> implements the functions
+       <code>vmult</code> and <code>Tvmult</code> for a <i>1xn</i>-matrix represented by
        a single vector.
        <br>
        (GK 2006/09/17)
        </p>
 
   <li> <p>Improved: The class <code>SolverCG</code> can
-       now estimate the condition number of the linear system using <code
-       class="class">TridiagonalMatrix</code> and LAPACK.
+       now estimate the condition number of the linear system using <code>TridiagonalMatrix</code> and LAPACK.
        <br>
        (GK 2006/09/06)
        </p>  
@@ -924,22 +877,19 @@ inconvenience this causes.
        (GK 2006/07/07)
        </p>  
 
-  <li> <p>New: There is now a function <code
-       class="member">FullMatrix::trace</code> that does what its name suggests
+  <li> <p>New: There is now a function <code>FullMatrix::trace</code> that does what its name suggests
        it does.
        <br>
        (WB 2006/06/16)
        </p>
   
   <li> <p>Improved: <code>PointerMatrixAux</code> now has a
-       default constructor and a function for setting the <code
-       class="class">VectorMemory</code> object.
+       default constructor and a function for setting the <code>VectorMemory</code> object.
        <br>
        (GK 2006/06/14)
        </p>
   
-  <li> <p>Fixed: <code
-       class="member">FullMatrix::print</code> would yield a link error
+  <li> <p>Fixed: <code>FullMatrix::print</code> would yield a link error
        when used with <code>std::ofstream</code> since an explicit
        instantiation was missing. The function has now been moved to
        the header file and made inline so that it is always visible,
@@ -948,24 +898,21 @@ inconvenience this causes.
        (WB 2006/06/07)
        </p>
   
-  <li> <p> Improved: The <code
-       class="class">SparseDirectUMFPACK</code> solver can now also be
+  <li> <p> Improved: The <code>SparseDirectUMFPACK</code> solver can now also be
        used with sparse matrices with elements of type float, as well
        as with block matrices with types float and double.
        <br> 
        (WB 2006/04/25)
        </p>
 
-  <li> <p> New: The function <code
-       class="member">BlockSparsityPattern::row_length</code> adds up
+  <li> <p> New: The function <code>BlockSparsityPattern::row_length</code> adds up
        the row lengths of the individual blocks of a block matrix for
        a given row.
        <br> 
        (WB 2006/04/25)
        </p>
   
-  <li> <p> New: There is a new class <code
-       class="class">IdentityMatrix</code> that represents an
+  <li> <p> New: There is a new class <code>IdentityMatrix</code> that represents an
        efficient version of the matrix with ones on the diagonal and
        zeros everywhere else. The main usefulness of this matrix lies
        in the fact that most other important matrix classes have
@@ -976,17 +923,14 @@ inconvenience this causes.
        (WB 2006/04/24)
        </p>
   
-  <li> <p> New: There are now assignment operators from <code
-       class="class">BlockVector</code> to <code
-       class="class">Vector</code> and back.
+  <li> <p> New: There are now assignment operators from <code>BlockVector</code> to <code>Vector</code> and back.
        <br>
        (WB 2006/03/30)
        </p>
 
   <li> <p> Improved: <code>BlockSparsityPattern</code> can be
        initialized directly using the vector generated by
-       <code>DoFTools</code>::<code
-       class="member">compute_row_length_vector</code>.
+       <code>DoFTools</code>::<code>compute_row_length_vector</code>.
        <br>
        (GK 2006/03/30)
        </p>
@@ -1002,20 +946,16 @@ inconvenience this causes.
        </p>  
 
   <li> <p>
-       Changed: There are new <code
-       class="class">FullMatrix</code>::<code
-       class="member">equ</code> functions which assign <tt>this</tt>
+       Changed: There are new <code>FullMatrix</code>::<code>equ</code> functions which assign <tt>this</tt>
        matrix to the linear combination of one, two or three
-       matrices. Also there is now a new <code
-       class="class">Vector</code>::<code>equ</code>
+       matrices. Also there is now a new <code>Vector</code>::<code>equ</code>
        function for three vectors.
        <br>
        (RH 2006/02/21)
        </p>  
 
   <li> <p>
-       Fixed: The <code
-       class="class">SolverMinRes</code> class did not work
+       Fixed: The <code>SolverMinRes</code> class did not work
        with the <code>BlockVector</code> class.
        This is now fixed.
        <br>
@@ -1023,32 +963,21 @@ inconvenience this causes.
        </p>  
 
   <li> <p>
-       Changed: There are now new <code
-       class="class">FullMatrix</code>::<code
-       class="member">add</code> functions which add two and three
+       Changed: There are now new <code>FullMatrix</code>::<code>add</code> functions which add two and three
        scaled matrices.
        <br>
        (RH 2006/02/16)
        </p>  
 
   <li> <p>
-       Changed: The matrix classes <code
-       class="class">FullMatrix</code>, <code
-       class="class">SparseMatrix</code>, <code
-       class="class">SparseMatrixEZ</code> and <code
-       class="class">BlockMatrixBase</code> now have an <code
-       class="member">add</code> function analogous to the <code
-       class="member">add</code> of vector classes. The old <code
-       class="member">add_scaled</code> functions are now deprecated.
+       Changed: The matrix classes <code>FullMatrix</code>, <code>SparseMatrix</code>, <code>SparseMatrixEZ</code> and <code>BlockMatrixBase</code> now have an <code>add</code> function analogous to the <code>add</code> of vector classes. The old <code>add_scaled</code> functions are now deprecated.
        <br>
        (RH 2006/02/16)
        </p>  
 
   <li> <p>       
-       Improved: <code>BlockMatrixArray</code>::<code
-       class="member">enter_aux</code> allows using matrices without
-       adding vector multiplication by using <code
-       class="class">PointerMatrixAux</code>.
+       Improved: <code>BlockMatrixArray</code>::<code>enter_aux</code> allows using matrices without
+       adding vector multiplication by using <code>PointerMatrixAux</code>.
        <br>
        (GK 2006/02/02)
        </p>  
@@ -1074,8 +1003,7 @@ inconvenience this causes.
        </p>
 
   <li> <p>
-       New: All solver classes took an argument of type <code
-       class="class">VectorMemory</code> which they use to allocate
+       New: All solver classes took an argument of type <code>VectorMemory</code> which they use to allocate
        memory for temporary vectors. A clever implementation of this
        class might allow reusing temporary vectors, and thus reduce
        the overhead of repeatedly allocating and freeing
@@ -1190,9 +1118,7 @@ inconvenience this causes.
        (Luca Heltai 2007/05/15)
        </p>
 
-  <li> <p>New: The classes <code
-  class="class">MGTransferBlockSelect</code> and <code
-  class="class">MGTransferBlock</code> allow for transfer of multigrid
+  <li> <p>New: The classes <code>MGTransferBlockSelect</code> and <code>MGTransferBlock</code> allow for transfer of multigrid
   vectors for single blocks of a system and for several blocks.
   <br>
   (GK 2007/04/26)
@@ -1255,16 +1181,14 @@ inconvenience this causes.
        (WB 2007/02/20)
        </p>
 
-   <li> <p>New: Added function <code>GridGenerator</code>::<code 
-        class="member">hyper_cube_with_cylindrical_hole</code> that produces 
+   <li> <p>New: Added function <code>GridGenerator</code>::<code >hyper_cube_with_cylindrical_hole</code> that produces 
        a square with a circular hole in the middle in 2d, and extrudes it
        along the z-direction between 0 and L. 
         <br>
         (Luca Heltai 2007/02/15)
         </p>
 
-   <li> <p>Workaround: The class <code>GridOut</code>::<code 
-        class="member">write_msh</code> produces a mesh which can be visualized
+   <li> <p>Workaround: The class <code>GridOut</code>::<code >write_msh</code> produces a mesh which can be visualized
        in the Gmsh reader. A bug in Gmsh prevented the boundary indicator to
        be properly visualized. The boundary indicator was added to the
        material flag of the faces (which is ignored when reading back the
@@ -1275,8 +1199,7 @@ inconvenience this causes.
         </p>
 
 
-   <li> <p>Fixed: The function <code>DoFTools</code>::<code 
-       class="member">distribute_cell_to_dof_vector</code> produced
+   <li> <p>Fixed: The function <code>DoFTools</code>::<code >distribute_cell_to_dof_vector</code> produced
        wrong results if the vector into which the result is to be
        stored contained nonzero values. This is now fixed.
        <br>
@@ -1291,8 +1214,7 @@ inconvenience this causes.
        (WB 2007/02/09)
        </p>
 
-   <li> <p>Fixed: <code>MatrixCreator</code>::<code 
-       class="member">create_mass_matrix</code> and <code>
+   <li> <p>Fixed: <code>MatrixCreator</code>::<code >create_mass_matrix</code> and <code>
        create_laplace_matrix</code> computed wrong values for the right 
        hand sides. This has been fixed. 
        <br>
@@ -1304,19 +1226,13 @@ inconvenience this causes.
        defaults to <tt>false</tt>. It is set to <tt>true</tt> if the
        coordinates of the points defining the subdivision of a patch
        are appended to the <tt>data</tt> table contained in a
-       <code>Patch</code>. This way, <code
-       class="class">DataOut</code>::<code
-       class="member">build_patches()</code> can use a <code
-       class="class">Mapping</code> to represent curved boundaries,
+       <code>Patch</code>. This way, <code>DataOut</code>::<code>build_patches()</code> can use a <code>Mapping</code> to represent curved boundaries,
        especially for higher order elements. This change corresponds
        to an extension of the intermediate format for graphics.
        <br>
        Fixed: Using the given <code>Mapping</code> to
-       obtain function values in <code
-       class="class">DataOut</code>::<code
-       class="member">build_patches()</code> also fixes a bug for
-       <code>FE_RaviartThomas</code> and <code
-       class="class">FE_ABF</code>elements, which need to evaluate the
+       obtain function values in <code>DataOut</code>::<code>build_patches()</code> also fixes a bug for
+       <code>FE_RaviartThomas</code> and <code>FE_ABF</code>elements, which need to evaluate the
        function values on the real (mapped) cell.
        <br>
        (Tobias Leicht 2007/01/30)
@@ -1325,16 +1241,14 @@ inconvenience this causes.
   <li> <p> Fixed: On faces with wrong <code>face_orientation</code> the dofs
        have to reordered in order to be combined with the correct shape
        functions. This is only relevant for continuous elements in 3D. At least for
-       <code>FE_Q</code> and systems of <code
-       class="class">FE_Q</code> this works now, for other finite elements the
+       <code>FE_Q</code> and systems of <code>FE_Q</code> this works now, for other finite elements the
        reordering vector still has to be implemented.
        <br>
        (Tobias Leicht, 2007/01/17)
        </p>
 
   <li> <p>
-       Fixed: The <code>Triangulation</code>::<code
-       class="member">execute_coarsening_and_refinement</code> function has to
+       Fixed: The <code>Triangulation</code>::<code>execute_coarsening_and_refinement</code> function has to
        discard coarsening flags in 2d and 3d if a neighbor of a flagged cell is
        refined or will be refined, in order to avoid that we end up with
        neighboring cells that differ in refinement by two levels. The function
@@ -1376,9 +1290,7 @@ inconvenience this causes.
        </p>
 
   <li> <p>
-       Extended: So far, the <code
-       class="class">GridReordering</code>::<code
-       class="member">invert_all_cells_of_negative_grid</code>
+       Extended: So far, the <code>GridReordering</code>::<code>invert_all_cells_of_negative_grid</code>
        function did nothing in 2d. Now, it inverts cells from
        clockwise to counterclockwise sense (in the old numbering
        scheme).
@@ -1387,9 +1299,7 @@ inconvenience this causes.
        </p>
 
   <li> <p>
-       New: There is now a function <code
-       class="class">GridTools</code>::<code
-       class="member">delete_duplicated_vertices</code> that deletes
+       New: There is now a function <code>GridTools</code>::<code>delete_duplicated_vertices</code> that deletes
        duplicate vertices which can occur if structured grids are read
        into deal.II, leading to unwanted interior
        boundaries. In order to reduce the effort of the quadratic
@@ -1400,9 +1310,7 @@ inconvenience this causes.
        </p>
 
   <li> <p>
-       New: There are now two new functions <code
-       class="class">GridGenerator</code>::<code
-       class="member">subdivided_hyper_rectangle</code> that produces
+       New: There are now two new functions <code>GridGenerator</code>::<code>subdivided_hyper_rectangle</code> that produces
        a non-uniformly subdivided rectangle, ideally suited for graded
        meshes. One of these functions is able to create meshes with holes. 
        <br>
@@ -1416,12 +1324,8 @@ inconvenience this causes.
        (Florian Prill 2006/10/31)
        </p>
 
-  <li> <p> Improved: The lookup mechanism in <code
-       class="class">FETools</code>::<code
-       class="member">get_fe_from_name</code> has been changed, so
-       additional custom finite elements can be added using <code
-       class="class">FETools</code>::<code
-       class="member">add_fe_name</code>. In the course of this
+  <li> <p> Improved: The lookup mechanism in <code>FETools</code>::<code>get_fe_from_name</code> has been changed, so
+       additional custom finite elements can be added using <code>FETools</code>::<code>add_fe_name</code>. In the course of this
        change, the implementation of the lookup mechanism has been
        simplified.
        <br>
@@ -1429,9 +1333,7 @@ inconvenience this causes.
        </p>
 
   <li> <p>
-       New: There is a new functions <code
-       class="class">GridTools</code>::<code
-       class="member">create_union_triangulation</code>
+       New: There is a new functions <code>GridTools</code>::<code>create_union_triangulation</code>
        that generates a triangulation that contains the respectively
        finest cells of two input triangulations.
        <br> 
@@ -1451,21 +1353,16 @@ inconvenience this causes.
        </p>
 
   <li> <p>
-       New: There are new functions <code
-       class="member">GridTools::minimal_cell_diameter</code> and <code
-       class="member">GridTools::maximal_cell_diameter</code>, with obvious
+       New: There are new functions <code>GridTools::minimal_cell_diameter</code> and <code>GridTools::maximal_cell_diameter</code>, with obvious
        functionality. 
        <br> 
        (WB 2006/09/06)
        </p>
 
   <li> <p>
-       Changed: The functions <code
-       class="member">FETools::compute_embedding_matrices</code>,
-       <code
-       class="member">FETools::compute_face_embedding_matrices</code>, and
-       <code
-       class="member">FETools::compute_projection_matrices</code>
+       Changed: The functions <code>FETools::compute_embedding_matrices</code>,
+       <code>FETools::compute_face_embedding_matrices</code>, and
+       <code>FETools::compute_projection_matrices</code>
        (mostly used in internal computations in setting up finite
        element objects) previously took pointers to the first element
        of an array of matrices as arguments. This isn't type-safe, and
@@ -1484,26 +1381,18 @@ inconvenience this causes.
        </p>
 
   <li> <p>
-       Extended: <code 
-                class="class">DerivativeApproximation</code> now offers access to the
+       Extended: <code >DerivativeApproximation</code> now offers access to the
        full tensor of derivatives of orders one, two and three. This
-       information can be requested for a single cell by means of the <code 
-                class="class">DerivativeApproximation</code><code
-       class="member">::approximate_derivative_tensor</code> function. If the
-       norm of this tensor is required later on, the new <code 
-                class="class">DerivativeApproximation</code><code
-       class="member">::derivative_norm</code> function can be used. Note, that
+       information can be requested for a single cell by means of the <code>DerivativeApproximation</code><code>::approximate_derivative_tensor</code> function. If the
+       norm of this tensor is required later on, the new <code >DerivativeApproximation</code><code>::derivative_norm</code> function can be used. Note, that
        for second order derivatives, this returns the largest eigenvalue
-       instead of the Frobenius norm, which is returned by the <code 
-                class="class">Tensor&lt;rank_,dim&gt;</code><code
-       class="member">::norm</code> function.
+       instead of the Frobenius norm, which is returned by the <code >Tensor&lt;rank_,dim&gt;</code><code>::norm</code> function.
        <br> 
        (Tobias Leicht 2006/08/03)
        </p>
 
   <li> <p>
-       Fixed: <code 
-                class="class">DerivativeApproximation</code> offers approximated
+       Fixed: <code >DerivativeApproximation</code> offers approximated
        derivatives of a discrete function. The symmetrization of the derivative
        tensor is now done at the right place, i.e. the derivative itself is
        symmetrized instead of an intermediate tensor. This should improve the
@@ -1514,8 +1403,7 @@ inconvenience this causes.
        </p>
 
   <li> <p>
-       Fixed: The <code 
-                class="member">DataOut::build_patches</code> and similar
+       Fixed: The <code >DataOut::build_patches</code> and similar
        functions in the related <code>DataOut*</code> classes allowed to pass
        zero as the second argument (denoting the number of threads to use if
        multithreading is enabled). This led to no output being created at
@@ -1525,8 +1413,7 @@ inconvenience this causes.
        </p>
 
   <li> <p>
-       New: The new function <code>FiniteElementBase</code>::<code
-       class="member">n_dofs_per_object</code> returns either
+       New: The new function <code>FiniteElementBase</code>::<code>n_dofs_per_object</code> returns either
        <code>dofs_per_vertex</code>, <code>dofs_per_line</code>,
        <code>dofs_per_quad</code>, ..., depending on the explicitly
        specified function template argument. This is often useful for
@@ -1536,8 +1423,7 @@ inconvenience this causes.
        </p>
 
   <li> <p>
-       Fixed: <code 
-                class="member">Triangulation&lt;dim&gt;::fix_coarsen_flags</code>
+       Fixed: <code >Triangulation&lt;dim&gt;::fix_coarsen_flags</code>
        has been modified to allow coarsening in all possible cases. Up
        to now, coarsening was forbidden, if the neighbor cell was not refined
        but had the <code>refine_flag</code> set, whereas it was allowed, if
@@ -1550,11 +1436,7 @@ inconvenience this causes.
        </p>
 
   <li> <p>
-       New: There are now new internal <code
-       class="class">TriaObjectAccessor&lt;1,dim&gt;</code>::<code
-       class="member">lines()</code> and <code
-       class="class">TriaObjectAccessor&lt;2,dim&gt;</code>::<code
-       class="member">quads()</code> functions. By using these
+       New: There are now new internal <code>TriaObjectAccessor&lt;1,dim&gt;</code>::<code>lines()</code> and <code>TriaObjectAccessor&lt;2,dim&gt;</code>::<code>quads()</code> functions. By using these
        functions, 30 function specializations could be removed,
        significantly reducing code duplication.
        <br>
@@ -1562,8 +1444,7 @@ inconvenience this causes.
        </p>
 
   <li> <p>
-       New: Function <code>VectorTools</code>::<code
-       class="member">create_point_source_vector</code> to calculate the projection
+       New: Function <code>VectorTools</code>::<code>create_point_source_vector</code> to calculate the projection
        of a Dirac pulse on the base functions. This models a point source as
        used in the calculations of Green's functions and can also be used to
        extract the value of a finite element solution in a single point.
@@ -1572,11 +1453,7 @@ inconvenience this causes.
        </p>
 
   <li> <p>
-       Changed: Functions <code
-       class="class">VectorTools</code>::<code
-       class="member">point_value</code> and <code
-       class="class">VectorTools</code>::<code
-       class="member">point_difference</code> using the old interface
+       Changed: Functions <code>VectorTools</code>::<code>point_value</code> and <code>VectorTools</code>::<code>point_difference</code> using the old interface
        without boundary mapping were replaced by wrapper functions
        calling the new versions.
        <br> 
@@ -1584,8 +1461,7 @@ inconvenience this causes.
        </p>
 
   <li> <p>
-       Changed: The old version of <code>GridTools</code>::<code
-       class="member">find_active_cell_around_point</code> has been replaced
+       Changed: The old version of <code>GridTools</code>::<code>find_active_cell_around_point</code> has been replaced
        by a wrapper function for backward compatibility. The wrapper calls the
        new version of this function, and it is highly recommended to use the new
        version as it automatically delivers also the local coordinate of the
@@ -1596,11 +1472,8 @@ inconvenience this causes.
        </p>
 
   <li> <p>
-       Improved: The functions <code>VectorTools</code>::<code
-       class="member">point_value</code> and <code>VectorTools</code>::<code
-       class="member">point_difference</code> now can also use arbitrary
-       mappings, using the new <code>GridTools</code>::<code
-       class="member">find_active_cell_around_point</code> algorithm.
+       Improved: The functions <code>VectorTools</code>::<code>point_value</code> and <code>VectorTools</code>::<code>point_difference</code> now can also use arbitrary
+       mappings, using the new <code>GridTools</code>::<code>find_active_cell_around_point</code> algorithm.
        <br> 
        (Ralf B. Schulz, 2006/05/11)
        </p>
@@ -1634,8 +1507,7 @@ inconvenience this causes.
        (WB 2006/05/01)
        </p>
   
-  <li> <p> Fixed: second derivatives where not computed correctly in <code
-       class="class">FEFaceValuesBase</code>, i.e. when evaluating
+  <li> <p> Fixed: second derivatives where not computed correctly in <code>FEFaceValuesBase</code>, i.e. when evaluating
        second derivatives on faces of cells. This is now fixed. Using
        second derivatives evaluated at quadrature points within a cell
        was not affected by this problem.
@@ -1699,8 +1571,7 @@ inconvenience this causes.
        </p>
 
   <li> <p>
-       New: There is a new function <code>FiniteElement</code>::<code
-       class="member">face_to_equivalent_cell_index</code> that can
+       New: There is a new function <code>FiniteElement</code>::<code>face_to_equivalent_cell_index</code> that can
        convert a face index of a degree of freedom into a
        corresponding cell index.
        <br> 
@@ -1708,91 +1579,60 @@ inconvenience this causes.
        </p>
 
   <li> <p>
-       New: There are now functions <code>VectorTools</code>::<code
-       class="member">point_value</code> that evaluate the value of a
+       New: There are now functions <code>VectorTools</code>::<code>point_value</code> that evaluate the value of a
        finite element function at a given point inside the domain.
        <br> 
        (WB 2006/03/06)
        </p>
 
   <li> <p> Improved: <code>GridOut</code> now has functions for
-       declaring and parsing parameters in a <code
-       class="class">ParameterHandler</code>, like used in <code
-       class="class">DataOut_Interface</code> for a long time.
+       declaring and parsing parameters in a <code>ParameterHandler</code>, like used in <code>DataOut_Interface</code> for a long time.
        <br>
        (GK 2006/03/06)
        </p>
 
   <li> <p>
-       Improved: The <code>Triangulation</code>, <code
-       class="class">PersistentTriangulation</code>, <code
-       class="class">DoFHandler</code>, <code
-       class="class">hp::DoFHandler</code> and <code
-       class="class">MGDoFHandler</code> classes now all have a <code
-       class="member">dimension</code> variable which allows to ask
+       Improved: The <code>Triangulation</code>, <code>PersistentTriangulation</code>, <code>DoFHandler</code>, <code>hp::DoFHandler</code> and <code>MGDoFHandler</code> classes now all have a <code>dimension</code> variable which allows to ask
        the template argument <tt>dim</tt> by
-       <class="class">SomeClass</code>::<code
-       class="member">dimension</code>.
+       <code>SomeClass::dimension</code>.
        <br> 
        (RH 2006/02/27)
        </p>
 
   <li> <p>
-       Fixed: When used, the copy constructor of <code
-       class="class">MappingQ</code> would lead to memory
+       Fixed: When used, the copy constructor of <code>MappingQ</code> would lead to memory
        corruption. This is now fixed.
        <br> 
        (RH 2006/02/23)
        </p>
 
   <li> <p>
-       New: There is now a <code
-       class="class">StaticMappingQ1</code>::<code
-       class="member">mapping</code> object of type <code
-       class="class">MappingQ1</code> which is used in several parts
-       of the library. This way multiple creation and storage of <code
-       class="class">MappingQ1</code> objects can be avoided.
+       New: There is now a <code>StaticMappingQ1</code>::<code>mapping</code> object of type <code>MappingQ1</code> which is used in several parts
+       of the library. This way multiple creation and storage of <code>MappingQ1</code> objects can be avoided.
        <br>
-       Similar to <code>StaticMappingQ1</code>::<code
-       class="member">mapping</code> there is now also an object <code
-       class="class">hp::StaticMappingQ1</code>::<code
-       class="member">mapping_collection</code> of type <code
-       class="class">MappingCollection</code>.
+       Similar to <code>StaticMappingQ1</code>::<code>mapping</code> there is now also an object <code>hp::StaticMappingQ1</code>::<code>mapping_collection</code> of type <code>MappingCollection</code>.
        <br>
        (RH 2006/02/21)
        </p>
 
   <li> <p>
-       New: There is now a <code>GridOut</code>::<code
-       class="member">write_gmsh</code> function to write in the gmsh 
+       New: There is now a <code>GridOut</code>::<code>write_gmsh</code> function to write in the gmsh 
        format. It has the same features of the write_ucd one. 
        <br> 
        (Luca Heltai 2006/02/17)
        </p>
 
   <li> <p>
-       Changed: The <code>hp::FECollection</code>::<code
-       class="member">get_fe</code>, <code
-       class="class">hp::QCollection</code>::<code
-       class="member">get_quadrature</code> and <code
-       class="class">hp::MappingCollection</code>::<code
-       class="member">get_mapping</code> functions are now renamed to
+       Changed: The <code>hp::FECollection</code>::<code>get_fe</code>, <code>hp::QCollection</code>::<code>get_quadrature</code> and <code>hp::MappingCollection</code>::<code>get_mapping</code> functions are now renamed to
        the standard <code>operator[]</code>
-       function. Similarly, the <code
-       class="class">FECollection</code>::<code
-       class="member">n_finite_elements</code>, <code
-       class="class">QCollection</code>::<code
-       class="member">n_quadratures</code> and <code
-       class="class">MappingCollection</code>::<code
-       class="member">n_mappings</code> functions are now renamed to
+       function. Similarly, the <code>FECollection</code>::<code>n_finite_elements</code>, <code>QCollection</code>::<code>n_quadratures</code> and <code>MappingCollection</code>::<code>n_mappings</code> functions are now renamed to
        the standard <code>size()</code> function.
        <br> 
        (RH 2006/02/10)
        </p>
 
   <li> <p>
-       Improved: <code>GridGenerator</code>::<code
-       class="member">half_hyper_ball</code> now is implemented also 
+       Improved: <code>GridGenerator</code>::<code>half_hyper_ball</code> now is implemented also 
        in three dimensions, and the boundary now is colored with 0 and one 
        respectively on the curved and plane.
        <br> 
@@ -1809,9 +1649,7 @@ inconvenience this causes.
        </p>
 
   <li> <p>
-       Fixed: The <code>MGDoFHandler</code>::<code
-       class="member">distribute_dofs</code> and <code
-       class="member">renumber</code> functions could not handle
+       Fixed: The <code>MGDoFHandler</code>::<code>distribute_dofs</code> and <code>renumber</code> functions could not handle
        coarsened grids (unused vertices, faces and cells). This is now
        fixed.
        <br> 
@@ -1836,8 +1674,7 @@ inconvenience this causes.
 
   <li> <p>
        Improved: A new <code>TriaAccessor::ExcCellHasNoChildren</code>
-       exception will be raised if the <code
-       class="member">TriaObjectAccessor::child_index</code> function
+       exception will be raised if the <code>TriaObjectAccessor::child_index</code> function
        is invoked for cells without children.
        <br> 
        (RH 2005/12/09)
@@ -1854,26 +1691,22 @@ inconvenience this causes.
        </p>
 
   <li> <p>
-       New: There is now a new <code
-       class="member">Triangulation::get_boundary_indicators</code>
+       New: There is now a new <code>Triangulation::get_boundary_indicators</code>
        function.
        <br> 
        (RH 2005/09/30)
        </p>
 
   <li> <p>
-       New: There is now a new <code
-       class="member">GridTools::delete_unused_vertices</code>
-       function. Previously a <tt>private</tt> function in <code
-       class="class">GridIn</code> it has now been moved to and made
+       New: There is now a new <code>GridTools::delete_unused_vertices</code>
+       function. Previously a <tt>private</tt> function in <code>GridIn</code> it has now been moved to and made
        <tt>public</tt> in <code>GridTools</code>.
        <br> 
        (RH 2005/09/28)
        </p>
 
   <li> <p>
-       New: The <code
-       class="member">GridIn&lt;dim&gt;::read_netcdf(string
+       New: The <code>GridIn&lt;dim&gt;::read_netcdf(string
        &filename)</code> function reads grids from NetCDF files. The
        only data format currently supported is the <tt>TAU grid
        format</tt>.
@@ -1882,8 +1715,7 @@ inconvenience this causes.
        </p>
 
   <li> <p>
-       Fixed: The <code
-       class="member">GridIn&lt;dim&gt;::read(filename, format)</code>
+       Fixed: The <code>GridIn&lt;dim&gt;::read(filename, format)</code>
        function ran into an exception when called with
        <tt>Default</tt> format and a filename which does not include
        <tt>/</tt>. This is now fixed.
index d26392b17de9d08c03f34bdbcadc9740b0976941..7538e540f06e5e4427cf1384752b7eb0ce4c4c3d 100644 (file)
@@ -44,7 +44,7 @@ the default):
 
 <code>
 <pre>
-$ mpirun -n 50 ./step-32
+\$ mpirun -np 50 ./step-32
 </pre>
 </code>
 
index 62168896d138fa82dc181969fdd66b19addaaf12..4137876e701ea849f7d67a5f363aeb1407eb0a01 100644 (file)
@@ -10,7 +10,6 @@ in the following paper:
 <br>
   J. Frohne, T. Heister, W. Bangerth: <b>Efficient numerical methods for the large-scale, parallel
                   solution of elastoplastic contact problems</b>. Submitted, 2013.
-</em>
 </i>
 
 
index ba3266b27e2fdde85586a7108caaa3b52cd7d9dc..8011c4b5fc8e938246723e076a35dd4288b80beb 100644 (file)
@@ -335,7 +335,7 @@ namespace Step52
 
 
 
-  // @sect5{<code>Diffusion::output_results}
+  // @sect5{<code>Diffusion::output_results</code>}
   //
   // We output the solution in vtu files.
   void Diffusion::output_results(unsigned int time_step,TimeStepping::runge_kutta_method method) const
index ed19329fa05f3ace0ac128866c233629b10275cf..d30105ceaeaf5b1ef5f714286e71991387629d39 100644 (file)
@@ -219,8 +219,8 @@ SphereGeometry<3>::average (const std_cxx1x::array<double,3> (&array)[N])
   }
 
   // finally for the polar angle. the difficulty here is that we have, for
-  // example, two points at (r,phi,theta) and (r,phi+pi,\pm pi/2), then we want
-  // to average these to (r,*,pi) where the equatorial angle does not matter
+  // example, two points at $(r,\phi,\theta)$ and $(r,\phi+\pi,\pm \pi/2)$, then we want
+  // to average these to $(r,\ast,\pi)$ where the equatorial angle does not matter
   {
     //??? not sure how exactly to do this
   }
index 5bf78154ba4b26751155067c165493d5de4af224..1638d35b7aa57910d3cc838bf69d55ae39e9b144 100644 (file)
@@ -748,7 +748,7 @@ namespace DoFTools
    * grid. The finite element used for the respective components on the two
    * grids needs to be the same. An example may clarify this: consider an
    * optimization problem with controls $q$ discretized on a coarse mesh and a
-   * state variable $u$ (and corresponding Lagrange multiplier $\lambda)
+   * state variable $u$ (and corresponding Lagrange multiplier $\lambda$)
    * discretized on the fine mesh. These are discretized using piecewise
    * constant discontinuous, continuous linear, and continuous linear
    * elements, respectively. Only the parameter $q$ is represented on the

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.