]> https://gitweb.dealii.org/ - dealii-svn.git/commitdiff
Use @code...@endcode instead of <pre><code>...</code></pre> so that we get doxygen...
authorbangerth <bangerth@0785d39b-7218-0410-832d-ea1e28bc413d>
Tue, 21 Aug 2007 15:20:46 +0000 (15:20 +0000)
committerbangerth <bangerth@0785d39b-7218-0410-832d-ea1e28bc413d>
Tue, 21 Aug 2007 15:20:46 +0000 (15:20 +0000)
git-svn-id: https://svn.dealii.org/trunk@15003 0785d39b-7218-0410-832d-ea1e28bc413d

deal.II/examples/step-18/doc/intro.dox
deal.II/examples/step-21/doc/results.dox
deal.II/examples/step-23/doc/results.dox
deal.II/examples/step-27/doc/intro.dox
deal.II/examples/step-27/doc/results.dox
deal.II/examples/step-3/doc/results.dox
deal.II/examples/step-6/doc/results.dox

index 8d44637c0b5829d5be32a502de170d1291e9ed79..b8d7f858788c2f51db9cbaf529dad41d4cbbe4ca 100644 (file)
@@ -359,11 +359,9 @@ been generated, and <code>NNN</code> the number of the MPI process that did this
 The next step is to convert this file or these files into whatever
 format you like. The program that does this is the @ref step_19 "step-19" tutorial program:
 for example, for the first time step, call it through
-<pre>
-<code>
+@code
     ../step-19/step-19 solution-0001.0000.*.d2 solution-0001.0000.gmv
-</code>
-</pre>
+@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
 you can be found in the documentation of the @ref step_19 "step-19" tutorial program.
index 3e46d87170c369c05fb7588f3b97ef28962ad026..302d13128daaf17210c2f545f6f0737321b5a517 100644 (file)
@@ -1,8 +1,7 @@
 <a name="Results"></a> <h1>Results</h1>
 
 If we run the program, we get the following kind of output:
-<pre>
-<code>
+@code
 Number of active cells: 1024
 Number of degrees of freedom: 4160 (2112+1024+1024)
 
@@ -22,8 +21,7 @@ Timestep 3
    Now at t=0.0980651, dt=0.0326836.
 
 ...
-</code>
-</pre>
+@endcode
 As we can see, the time step is pretty much constant right from the start,
 which indicates that the velocities in the domain are not strongly dependent
 on changes in saturation, although they certainly are through the factor
@@ -78,17 +76,13 @@ and 167,000 degrees of freedom:
 @image html step-21.random3d.gif
 
 To repeat these computations, all you have to do is to change the line
-<pre>
-<code>
+@code
       TwoPhaseFlowProblem<2> two_phase_flow_problem(0);
-</code>
-</pre>
+@endcode
 in the main function to
-<pre>
-<code>
+@code
       TwoPhaseFlowProblem<3> two_phase_flow_problem(0);
-</code>
-</pre>
+@endcode
 The visualization uses a cloud technique, where the saturation is indicated by
 colored but transparent clouds for each cell. This way, one can also see
 somewhat what happens deep inside the domain. A different way of visualizing
index bffa7272928fb5a8bae45d5213e0073b34e5310b..205a2cc6ebf1ac5c66da66928c00f4cf58e86135 100644 (file)
@@ -2,8 +2,7 @@
 <h1>Results</h1>
 
 When the program is run, it produces the following output:
-<pre>
-<code>
+@code
 Number of active cells: 16384
 Number of degrees of freedom: 16641
 
@@ -57,8 +56,7 @@ Time step 320 at t=5
    u-equation: 7 CG iterations.
    v-equation: 21 CG iterations.
   Total energy: 23.2328
-</code>
-</pre>
+@endcode
 
 What we see immediately is that the energy is a constant at least after
 $t=\frac 12$ (until which the boundary source term $g$ is nonzero, injecting
index 2ecf726f52dce1efeaf007c3b5d1c99b4ca0bf3f..d89cf30e7fcf82b8f4210020a8caa0a8f5a98db1 100644 (file)
@@ -111,13 +111,11 @@ described in the @ref hpcollection overview.
 In this tutorial program, we will use continuous Lagrange elements of
 orders 2 through 7 (in 2d) or 2 through 5 (in 3d). The collection of
 used elements can then be created as follows:
-<code>
-<pre>
+@code
   hp::FECollection<dim> fe_collection;
   for (unsigned int degree=2; degree<=max_degree; ++degree)
     fe_collection.push_back (FE_Q<dim>(degree));
-</pre>
-</code>
+@endcode
 
 
 
@@ -149,16 +147,14 @@ index</i> to indicate that this is the finite element that is active
 on this cell, whereas all the other elements of the collection are
 inactive on it. The general outline of this reads like this:
 
-<code>
-<pre>
+@code
   hp::DoFHandler<dim> dof_handler (triangulation);
   for (typename hp::DoFHandler<dim>::active_cell_iterator
          cell = dof_handler.begin_active();
        cell != dof_handler.end(); ++cell)
     cell->set_active_fe_index (...);
   dof_handler.distribute_dofs (fe_collection);
-</pre>
-</code>
+@endcode
 
 Dots in the call to <code>set_active_fe_index()</code> indicate that
 we will have to have some sort of strategy later on to decide which
@@ -174,13 +170,11 @@ a Q3 element) then we have to compute additional constraints on the
 finite element field to ensure that it is continuous. This is
 conceptually very similar to how we compute hanging node constraints,
 and in fact the code looks exactly the same:
-<code>
-<pre>
+@code
   ConstraintMatrix constraints;
   DoFTools::make_hanging_node_constraints (dof_handler,
                                           constraints);
-</pre>
-</code>
+@endcode
 In other words, the DoFTools::make_hanging_node_constraints deals not
 only with hanging node constraints, but also with $hp$ constraints at
 the same time.
@@ -217,8 +211,7 @@ single finite element, quadrature formula, and mapping, it takes collections
 of these objects. It's use is very much like the regular FEValues class,
 i.e. the interesting part of the loop over all cells would look like this:
 
-<code>
-<pre>
+@code
   hp::FEValues<dim> hp_fe_values (mapping_collection,
                                   fe_collection,
                                  quadrature_collection, 
@@ -239,8 +232,7 @@ i.e. the interesting part of the loop over all cells would look like this:
 
       ...  // assemble local contributions and copy them into global object
     }
-</pre>
-</code>
+@endcode
 
 In this tutorial program, we will always use a Q1 mapping, so the mapping
 collection argument to the hp::FEValues construction will be omitted. Inside
@@ -703,33 +695,28 @@ time of creating the sparsity pattern, or while copying local contributions
 into the global matrix object (or global vector).
 
 So, instead of the code snippet (taken from @ref step_6 "step-6")
-<code>
-<pre>
+@code
   DoFTools::make_hanging_node_constraints (dof_handler,
                                           hanging_node_constraints);
   hanging_node_constraints.close ();
 
   DoFTools::make_sparsity_pattern (dof_handler, sparsity_pattern);
   hanging_node_constraints.condense (sparsity_pattern);
-</pre>
-</code>
+@endcode
 we now use the following:
-<code>
-<pre>
+@code
   DoFTools::make_hanging_node_constraints (dof_handler,
                                           hanging_node_constraints);
   hanging_node_constraints.close ();
 
   DoFTools::make_sparsity_pattern (dof_handler, sparsity_pattern,
                                    hanging_node_constraints);
-</pre>
-</code>
+@endcode
 
 In a similar vein, we have to slightly modify the way we copy local
 contributions into global matrices and vectors. In previous tutorial programs,
 we have always used a process like this:
-<code>
-<pre>
+@code
   typename hp::DoFHandler<dim>::active_cell_iterator
     cell = dof_handler.begin_active(),
     endc = dof_handler.end();
@@ -750,12 +737,10 @@ we have always used a process like this:
 
   hanging_node_constraints.condense (system_matrix);
   hanging_node_constraints.condense (system_rhs);
-</pre>
-</code>
+@endcode
 We now replace copying and later condensing into one step, as already shown in
 @ref step_17 "step-17" and @ref step_18 "step-18":
-<code>
-<pre>
+@code
   typename hp::DoFHandler<dim>::active_cell_iterator
     cell = dof_handler.begin_active(),
     endc = dof_handler.end();
@@ -775,8 +760,7 @@ We now replace copying and later condensing into one step, as already shown in
                                     local_dof_indices,
                                     system_rhs);
     }
-</pre>
-</code>
+@endcode
 Essentially, what the
 <code>hanging_node_constraints.distribute_local_to_global</code> calls do is
 to implement the same loop as before, but whenever we hit a constrained degree
index 731f84747447fa9b11384087fde9b8d5845ca9ee..241694aa166cff168d3f2bfbd55c22b8c89b54de 100644 (file)
@@ -8,8 +8,7 @@ components of the program take, are given in the @ref hp_paper .
 
 When run, this is what the program produces:
 
-<code>
-<pre>
+@code
 examples/step-27> make run
 ============================ Running step-27
 Cycle 0:
@@ -36,8 +35,7 @@ Cycle 5:
    Number of active cells:       2577
    Number of degrees of freedom: 26936
    Number of constraints       : 6196
-</pre>
-</code>
+@endcode
 
 The first thing we learn from this is that the number of constrained
 degrees of freedom is on the order of 20-25% of the total number of
index db822b3212d9975706ac638a9f7ae0b1b3b289ff..1ee4829f54dc219c05a2d7a0499d2ecce980e642 100644 (file)
@@ -103,9 +103,10 @@ suggestions:
   indicator zero.  <p> We can change this behavior if we assign parts
   of the boundary different indicators. For example, try this
   immediately after calling <code>GridGenerator::hyper_cube</code>:
-  <code><pre>
+  @code
   triangulation.begin_active()->face(0)->set_boundary_indicator(1);
-  </pre></code> What this does is it first asks the triangulation to
+  @endcode
+  What this does is it first asks the triangulation to
   return an iterator that points to the first active cell. Of course,
   this being the coarse mesh for the triangulation of a square, the
   triangulation has only a single cell at this moment, and it is
index 95700f9299bd9cdbed09d2e7cb6661b8b67d3398..a46f75a24f2466486707dcc30082c3ad88a1209b 100644 (file)
@@ -3,7 +3,7 @@
 
 
 The output of the program looks as follows:
-<pre><code>
+@code
 Cycle 0:
    Number of active cells:       20
    Number of degrees of freedom: 89
@@ -28,7 +28,7 @@ Cycle 6:
 Cycle 7:
    Number of active cells:       3884
    Number of degrees of freedom: 18401
-</code></pre>
+@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.