]> https://gitweb.dealii.org/ - dealii-svn.git/commitdiff
Various fixes. Doxygenize step-7
authorwolf <wolf@0785d39b-7218-0410-832d-ea1e28bc413d>
Tue, 28 Mar 2006 05:45:56 +0000 (05:45 +0000)
committerwolf <wolf@0785d39b-7218-0410-832d-ea1e28bc413d>
Tue, 28 Mar 2006 05:45:56 +0000 (05:45 +0000)
git-svn-id: https://svn.dealii.org/trunk@12705 0785d39b-7218-0410-832d-ea1e28bc413d

deal.II/doc/tutorial/chapter-2.step-by-step/step-1.data/results.dox
deal.II/doc/tutorial/chapter-2.step-by-step/step-4.data/intro.dox [moved from deal.II/doc/tutorial/chapter-2.step-by-step/step-4.data/intro.html with 74% similarity]
deal.II/doc/tutorial/chapter-2.step-by-step/step-5.data/intro.dox [moved from deal.II/doc/tutorial/chapter-2.step-by-step/step-5.data/intro.html with 99% similarity]
deal.II/doc/tutorial/chapter-2.step-by-step/step-5.data/results.dox
deal.II/doc/tutorial/chapter-2.step-by-step/step-6.data/intro.dox [moved from deal.II/doc/tutorial/chapter-2.step-by-step/step-6.data/intro.html with 83% similarity]
deal.II/doc/tutorial/chapter-2.step-by-step/step-6.data/results.dox
deal.II/doc/tutorial/chapter-2.step-by-step/step-7.data/results.dox [moved from deal.II/doc/tutorial/chapter-2.step-by-step/step-7.data/results.html with 94% similarity]
deal.II/doc/tutorial/chapter-2.step-by-step/step-7.data/solution-3d.jpg [deleted file]
deal.II/doc/tutorial/chapter-2.step-by-step/step-7.data/step-7.solution.png [new file with mode: 0644]

index 754418b3c27066040746bc0b4a96efa4f87d478d..60cb962c79cf78a419fb422b4d25025c47029efb 100644 (file)
@@ -7,11 +7,11 @@ like this:
 <TABLE WIDTH="60%" ALIGN="center">
   <tr>
     <td ALIGN="center">
-      @image html step-1.grid-1.jpg
+      @image html step-1.grid-1.png
     </td>
 
     <td ALIGN="center">
-      @image html step-1.grid-2.jpg
+      @image html step-1.grid-2.png
     </td>
   </tr>
 </table>
similarity index 74%
rename from deal.II/doc/tutorial/chapter-2.step-by-step/step-4.data/intro.html
rename to deal.II/doc/tutorial/chapter-2.step-by-step/step-4.data/intro.dox
index a7e72aaac74d0c3a140eb4f1002fc05bb1a4e1ca..e282d9e2b62a0c423429d9b20b21daafbcbe9879 100644 (file)
@@ -1,16 +1,16 @@
 <a name="Intro"></a>
 <h1>Introduction</h1>
 
-<p>
-<acronym>deal.II</acronym> has a unique feature which we call
+
+deal.II has a unique feature which we call
 ``dimension independent programming''. You may have noticed in the
 previous examples that many classes had a number in angle brackets
 suffixed to them. This is to indicate that for example the
 triangulation in two and three space dimensions are different, but
 related data types. We could as well have called them 
 <code>Triangulation2d</code> and <code>Triangulation3d</code> instead
-of <code>Triangulation&lt;2&gt;</code> and
-<code>Triangulation&lt;3&gt;</code> to name the two classes, but this
+of <code>Triangulation@<2@></code> and
+<code>Triangulation@<3@></code> to name the two classes, but this
 has an important drawback: assume you have a function which does
 exactly the same functionality, but on 2d or 3d triangulations,
 depending on which dimension we would like to solve the equation in
@@ -22,11 +22,11 @@ working on <code>Triangulation2d</code> and once working with a
 <code>Triangulation3d</code>. This is an unnecessary obstacle in
 programming and leads to a nuisance to keep the two function in synch
 (at best) or difficult to find errors if the two versions get out of
-synch (at worst; this would probably the more common case).
-</p>
+sync (at worst; this would probably the more common case).
+
+
 
 
-<p>
 Such obstacles can be circumvented by using some template magic as
 provided by the C++ language: templatized classes and functions are
 not really classes or functions but only a pattern depending on an
@@ -37,97 +37,97 @@ it with the information that is needed for that. Of course, parts of
 the template can depend on the template parameters, and they will be
 resolved at the time of compilation for a specific template
 parameter. For example, consider the following piece of code:
-<pre><code>
-  template &lt;int dim&gt;
-  void make_grid (Triangulation&lt;dim&gt; &amp;triangulation)
+@code
+  template <int dim>
+  void make_grid (Triangulation<dim> &amp;triangulation)
   {
     GridGenerator::hyper_cube (triangulation, -1, 1);
   };
-</code></pre>
-</p>
+@endcode
+
+
 
-<p>
 At the point where the compiler sees this function, it does not know
-anything about the actual value of ``dim''. The only thing the compiler has is
+anything about the actual value of <code>dim</code>. The only thing the compiler has is
 a template, i.e. a blueprint, to generate
 functions <code>make_grid</code> if given a particular value of
-``dim''. Since ``dim'' has an unknown value, there is no
+<code>dim</code>. Since <code>dim</code> has an unknown value, there is no
 code the compiler can generate for the moment.
-</p>
 
-<p>
+
+
 However, if later down the compiler would encounter code that looks, for
 example, like this,
-<pre><code>
-  Triangulation&lt;2&gt; triangulation;
+@code
+  Triangulation<2> triangulation;
   make_grid (triangulation);
-</code></pre>
+@endcode
 then the compiler will deduce that the function <code>make_grid</code> for
 <code>dim==2</code> was 
 requested and will compile the template above into a function with dim replaced
 by 2 everywhere, i.e. it will compile the function as if it were defined
 as
-<pre><code>
-  void make_grid (Triangulation&lt;2&gt; &amp;triangulation)
+@code
+  void make_grid (Triangulation<2> &amp;triangulation)
   {
     GridGenerator::hyper_cube (triangulation, -1, 1);
   };
-</code></pre>
-</p>
+@endcode
+
+
 
-<p>
 However, it is worth to note that the function
 <code>GridGenerator::hyper_cube</code> depends on the dimension as
 well, so in this case, the compiler will call the function
-<code>GridGenerator::hyper_cube&lt;2&gt;</code> while if dim were 3,
-it would call <code>GridGenerator::hyper_cube&lt;3&gt;</code> which
+<code>GridGenerator::hyper_cube@<2@></code> while if dim were 3,
+it would call <code>GridGenerator::hyper_cube@<3@></code> which
 might be (and actually is) a totally unrelated  function.
-</p>
 
-<p>
+
+
 The same can be done with member variables. Consider the following
 function, which might in turn call the above one:
-<pre><code>
-  template &lt;int dim&gt;
-  void make_grid_and_dofs (Triangulation&lt;dim&gt; &amp;triangulation)
+@code
+  template <int dim>
+  void make_grid_and_dofs (Triangulation<dim> &amp;triangulation)
   {
     make_grid (triangulation);
 
-    DoFHandler&lt;dim&gt; dof_handler(triangulation);
+    DoFHandler<dim> dof_handler(triangulation);
     ...
   };
-</code></pre>
+@endcode
 This function has a member variable of type
-<code>DoFHandler&lt;dim&gt;</code>. Again, the compiler can't
+<code>DoFHandler@<dim@></code>. Again, the compiler can't
 compile this function until it knows for which dimension. If you call
 this function for a specific dimension as above, the compiler will
 take the template, replace all occurences of dim by the dimension for
 which it was called, and compile it. If you call the function several
 times for different dimensions, it will compile it several times, each
-time calling the right ``make_grid'' function and reserving the right
+time calling the right <code>make_grid</code> function and reserving the right
 amount of memory for the member variable; note that the size of a
 <code>DoFHandler</code> might, and indeed does, depend on the space dimension.
-</p>
 
-<p>
-The <acronym>deal.II</acronym> library is build around this concept
+
+
+The deal.II library is build around this concept
 of dimension-independent programming, and therefore allows you to program in
 a way that will not need to 
 distinguish between the space dimensions. It should be noted that in
 only a very few places is it necessary to actually compare the
-dimension using ``if''s or ``switch''es. However, since the compiler
+dimension using <code>if</code>s or <code>switch</code>es. However, since the compiler
 has to compile each function for each dimension separately, even there
-it knows the value of ``dim'' at the time of compilation and will
-therefore be able to optimize away the ``if'' statement along with the
+it knows the value of <code>dim</code> at the time of compilation and will
+therefore be able to optimize away the <code>if</code> statement along with the
 unused branch.
-</p>
 
-<p>
+
+
 In this example program, we will show how to program dimension
 independently (which in fact is even simpler than if you had to take
 care about the dimension) and we will extend the Laplace problem of
 the last example to a program that runs in two and three space
 dimensions at the same time. Other extensions are the use of a
 non-constant right hand side function and of non-zero boundary values.
-</p>
+
 
similarity index 99%
rename from deal.II/doc/tutorial/chapter-2.step-by-step/step-5.data/intro.html
rename to deal.II/doc/tutorial/chapter-2.step-by-step/step-5.data/intro.dox
index 2de8f398a9e527f47db659f171dc6884ee36ac14..43e24bfd9717eea1cec27e71a4b36cd9f4a4bb55 100644 (file)
@@ -1,7 +1,7 @@
 <a name="Intro"></a>
 <h1>Introduction</h1>
 
-<p>
+
 This example does not show revolutionary new things, but it shows many
 small improvements over the previous examples, and also many small
 things that can usually be found in finite element programs. Among
@@ -35,4 +35,3 @@ them are:
        preconditioned iterative solvers for the linear systems of
        equations.
 </ul>
-</p>
index 44c133c8ba76fd06f5ad78967d07d15371bf05b6..3cd03c5bb01f776d6084795da8650dc6222228c2 100644 (file)
@@ -36,8 +36,8 @@ Cycle 5:
    Number of degrees of freedom: 20609
    182 CG iterations needed to obtain convergence.
 --------------------------------------------------------
-An error occurred in line &lt;273&gt; of file &lt;step-5.cc&gt; in function
-    void Coefficient&lt;dim&gt;::value_list(const std::vector&lt;Point&lt;dim&gt;, std::allocator&lt;Point&lt;dim&gt; &gt; &gt;&, std::vector&lt;double, std::allocator&lt;double&gt; &gt;&, unsigned int)
+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: 
     values.size() == points.size()
@@ -48,7 +48,7 @@ Dimension 1 not equal to 2
 
 Stacktrace:
 -----------
-#0  ./step-5: Coefficient&lt;2&gt;::value_list(std::vector&lt;Point&lt;2&gt;, std::allocator&lt;Point&lt;2&gt; &gt; &gt; const&, std::vector&lt;double, std::allocator&lt;double&gt; &gt;&, unsigned) const
+#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
@@ -108,8 +108,8 @@ example.
 As for the error &mdash; let's look at it again:
 @code
 --------------------------------------------------------
-An error occurred in line &lt;273&gt; of file &lt;step-5.cc&gt; in function
-    void Coefficient&lt;dim&gt;::value_list(const std::vector&lt;Point&lt;dim&gt;, std::allocator&lt;Point&lt;dim&gt; &gt; &gt;&, std::vector&lt;double, std::allocator&lt;double&gt; &gt;&, unsigned int)
+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: 
     values.size() == points.size()
@@ -120,7 +120,7 @@ Dimension 1 not equal to 2
 
 Stacktrace:
 -----------
-#0  ./step-5: Coefficient&lt;2&gt;::value_list(std::vector&lt;Point&lt;2&gt;, std::allocator&lt;Point&lt;2&gt; &gt; &gt; const&, std::vector&lt;double, std::allocator&lt;double&gt; &gt;&, unsigned) const
+#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
similarity index 83%
rename from deal.II/doc/tutorial/chapter-2.step-by-step/step-6.data/intro.html
rename to deal.II/doc/tutorial/chapter-2.step-by-step/step-6.data/intro.dox
index c3288d7b89fd42c1b8faa26bfeb817fbcc82f79e..990220acd0d2b503d0037c240eeea4253bf25a7d 100644 (file)
@@ -1,24 +1,24 @@
 <a name="Intro"></a>
 <h1>Introduction</h1>
 
-<p>
+
 The main emphasis in this example is the handling of locally refined
 grids. The approach to adaptivity chosen in deal.II us to use grids in which
 neighboring cells may be refined a different number of times. This then
 results in nodes on the interfaces of cells which belong to one
 side, but are unbalanced on the other. The common term for these is
-&#8220;hanging nodes&#8221;.
-</p>
+&ldquo;hanging nodes&rdquo;.
+
+
 
-<p>
 To guarantee that the global solution is continuous at these nodes as
 well, we have to state some additional constraints on the values of
 the solution at these nodes. In the program below, we will show how we
 can get these constraints from the library, and how to use them in the
 solution of the linear system of equations.
-</p>
 
-<p>
+
+
 The locally refined grids are produced using an error estimator class
 which estimates the energy error with respect to the Laplace
 operator. This error estimator, although developed for Laplace's
@@ -28,30 +28,30 @@ problems. Although it will create non-optimal meshes for other
 equations, it is often a good way to quickly produce meshes that are
 well adapted to the features of solutions, such as regions of great
 variation or discontinuities. Since it was developed by Kelly and
-co-workers, we often refer to it as the &#8220;Kelly refinement
-indicator&#8221; in the library, documentation, and mailing list. The
+co-workers, we often refer to it as the &ldquo;Kelly refinement
+indicator&rdquo; in the library, documentation, and mailing list. The
 class that implements it is called
-&#8220;KellyErrorEstimator&#8221;. Although the error estimator (and
+<code>KellyErrorEstimator</code>. Although the error estimator (and
 its
 implementation in the deal.II library) is capable of handling variable
 coefficients in the equation, we will not use this feature since we
 are only interested in a quick and simple way to generate locally
 refined grids.
-</p>
 
-<p>
+
+
 Since the concepts used for locally refined grids are so important,
 we do not show much additional new stuff in this example. The most
 important exception is that we show how to use biquadratic elements
 instead of the bilinear ones which we have used in all previous
 examples. In fact, The use of higher order elements is accomplished by
 only replacing three lines of the program, namely the declaration of
-the ``fe'' variable, and the use of an appropriate quadrature formula
+the <code>fe</code> variable, and the use of an appropriate quadrature formula
 in two places. The rest of the program is unchanged.
-</p>
 
-<p>
+
+
 The only other new thing is a method to catch exceptions in the
-&#8220;main&#8221; function in order to output some information in case the
+<code>main</code> function in order to output some information in case the
 program crashes for some reason.
-</p>
+
index eae75e870743d433d5bbda5322a3e742693d431c..95700f9299bd9cdbed09d2e7cb6661b8b67d3398 100644 (file)
@@ -117,12 +117,12 @@ from this example.
 
 @code
 --------------------------------------------------------
-An error occurred in line &lt;79&gt; of file &lt;source/subscriptor.cc&gt; in function
+An error occurred in line <79> of file <source/subscriptor.cc> in function
     virtual Subscriptor::~Subscriptor()
 The violated condition was: 
     counter == 0
 The name and call sequence of the exception was:
-    ExcInUse(counter, object_info-&gt;name(), infostring)
+    ExcInUse(counter, object_info->name(), infostring)
 Additional Information: 
 Object of class 4FE_QILi2EE is still used by 1 other objects.
   from Subscriber 10DoFHandlerILi2EE
@@ -130,10 +130,10 @@ Object of class 4FE_QILi2EE is still used by 1 other objects.
 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&lt;2&gt;::~FiniteElement()
-#2  ./step-6: FE_Poly&lt;TensorProductPolynomials&lt;2&gt;, 2&gt;::~FE_Poly()
-#3  ./step-6: FE_Q&lt;2&gt;::~FE_Q()
-#4  ./step-6: LaplaceProblem&lt;2&gt;::~LaplaceProblem()
+#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: LaplaceProblem<2>::~LaplaceProblem()
 #5  ./step-6: main
 --------------------------------------------------------
 make: *** [run] Aborted
similarity index 94%
rename from deal.II/doc/tutorial/chapter-2.step-by-step/step-7.data/results.html
rename to deal.II/doc/tutorial/chapter-2.step-by-step/step-7.data/results.dox
index 4c2205fdfc4a463452c74d07fde2e96943e386c7..cbed6604effd68a290422eca6cb68e1810fe1055 100644 (file)
@@ -1,26 +1,24 @@
 <a name="Results"></a>
 <h1>Results</h1>
 
-<p>
+
 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: 
-</p>
 
-<p align="center">
-  <img src="step-7.data/solution-3d.jpg" alt="solution" width="75%">
-</p>
+
+@image html step-7.solution.png
+
+
 
 
-<p>
 Secondly, the program writes tables not only to disk, but also to the
 screen while running:
-</p>
 
-<pre>
-<code>
+
+@code
 examples/step-7> make run
 ============================ Running step-7
 Solving with Q1 elements, adaptive refinement
@@ -142,29 +140,26 @@ n cells  H1      L2
       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 
-</code>
-</pre>
+@endcode
 
 
-<p>
 One can see the error reduction upon grid refinement, and for the
 cases where global refinement was performed, also the convergence
 rates can be seen. The linear and quadratic convergence rates of Q1
-and Q2 elements in the H<sup>1</sup> norm can clearly be seen, as
-are the quadratic and cubic rates in the L<sub>2</sub> norm.
-</p>
+and Q2 elements in the $H^1$ norm can clearly be seen, as
+are the quadratic and cubic rates in the $L_2$ norm.
+
+
 
 
-<p>
 Finally, the program generated various LaTeX tables. We show here
 the convergence table of the Q2 element with global refinement, after
 converting the format to HTML:
-</p>
 
 
-<DIV ALIGN="CENTER">
+
 <TABLE CELLPADDING=3 BORDER="1" ALIGN="CENTER">
-<TR><TD ALIGN="CENTER" COLSPAN=2><P>
+<TR><TD ALIGN="CENTER" COLSPAN=2>
 n cells</TD>
 <TD ALIGN="CENTER" COLSPAN=2><I>H</I><SUP>1</SUP>-error</TD>
 <TD ALIGN="CENTER" COLSPAN=3><I>L</I><SUP>2</SUP>-error</TD>
@@ -225,5 +220,5 @@ n cells</TD>
 <TD ALIGN="CENTER">7.99</TD>
 <TD ALIGN="CENTER">3.00</TD>
 </TR>
-</TABLE></DIV>
-<BR>
+</TABLE>
+
diff --git a/deal.II/doc/tutorial/chapter-2.step-by-step/step-7.data/solution-3d.jpg b/deal.II/doc/tutorial/chapter-2.step-by-step/step-7.data/solution-3d.jpg
deleted file mode 100644 (file)
index c925435..0000000
Binary files a/deal.II/doc/tutorial/chapter-2.step-by-step/step-7.data/solution-3d.jpg and /dev/null differ
diff --git a/deal.II/doc/tutorial/chapter-2.step-by-step/step-7.data/step-7.solution.png b/deal.II/doc/tutorial/chapter-2.step-by-step/step-7.data/step-7.solution.png
new file mode 100644 (file)
index 0000000..eec6a4f
Binary files /dev/null and b/deal.II/doc/tutorial/chapter-2.step-by-step/step-7.data/step-7.solution.png differ

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.