From 15beb9b5f0c02bddf45ec009c8841fc58c1721a3 Mon Sep 17 00:00:00 2001 From: bangerth Date: Tue, 21 Aug 2007 15:20:46 +0000 Subject: [PATCH] Use @code...@endcode instead of 
...
so that we get doxygen's nice styles for code snippets. git-svn-id: https://svn.dealii.org/trunk@15003 0785d39b-7218-0410-832d-ea1e28bc413d --- deal.II/examples/step-18/doc/intro.dox | 6 +-- deal.II/examples/step-21/doc/results.dox | 18 +++------ deal.II/examples/step-23/doc/results.dox | 6 +-- deal.II/examples/step-27/doc/intro.dox | 48 ++++++++---------------- deal.II/examples/step-27/doc/results.dox | 6 +-- deal.II/examples/step-3/doc/results.dox | 5 ++- deal.II/examples/step-6/doc/results.dox | 4 +- 7 files changed, 33 insertions(+), 60 deletions(-) diff --git a/deal.II/examples/step-18/doc/intro.dox b/deal.II/examples/step-18/doc/intro.dox index 8d44637c0b..b8d7f85878 100644 --- a/deal.II/examples/step-18/doc/intro.dox +++ b/deal.II/examples/step-18/doc/intro.dox @@ -359,11 +359,9 @@ been generated, and NNN 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 -
-
+@code
     ../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 you can be found in the documentation of the @ref step_19 "step-19" tutorial program. diff --git a/deal.II/examples/step-21/doc/results.dox b/deal.II/examples/step-21/doc/results.dox index 3e46d87170..302d13128d 100644 --- a/deal.II/examples/step-21/doc/results.dox +++ b/deal.II/examples/step-21/doc/results.dox @@ -1,8 +1,7 @@

Results

If we run the program, we get the following kind of output: -
-
+@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.
 
 ...
-
-
+@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 -
-
+@code
       TwoPhaseFlowProblem<2> two_phase_flow_problem(0);
-
-
+@endcode in the main function to -
-
+@code
       TwoPhaseFlowProblem<3> two_phase_flow_problem(0);
-
-
+@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 diff --git a/deal.II/examples/step-23/doc/results.dox b/deal.II/examples/step-23/doc/results.dox index bffa727292..205a2cc6eb 100644 --- a/deal.II/examples/step-23/doc/results.dox +++ b/deal.II/examples/step-23/doc/results.dox @@ -2,8 +2,7 @@

Results

When the program is run, it produces the following output: -
-
+@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
-
-
+@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 diff --git a/deal.II/examples/step-27/doc/intro.dox b/deal.II/examples/step-27/doc/intro.dox index 2ecf726f52..d89cf30e7f 100644 --- a/deal.II/examples/step-27/doc/intro.dox +++ b/deal.II/examples/step-27/doc/intro.dox @@ -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
   hp::FECollection fe_collection;
   for (unsigned int degree=2; degree<=max_degree; ++degree)
     fe_collection.push_back (FE_Q(degree));
-
- +@endcode @@ -149,16 +147,14 @@ index 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
   hp::DoFHandler dof_handler (triangulation);
   for (typename hp::DoFHandler::active_cell_iterator
          cell = dof_handler.begin_active();
        cell != dof_handler.end(); ++cell)
     cell->set_active_fe_index (...);
   dof_handler.distribute_dofs (fe_collection);
-
- +@endcode Dots in the call to set_active_fe_index() 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
   ConstraintMatrix constraints;
   DoFTools::make_hanging_node_constraints (dof_handler,
 					   constraints);
-
- +@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
   hp::FEValues 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
     }
-
- +@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
   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);
-
- +@endcode we now use the following: - -
+@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);
-
- +@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
   typename hp::DoFHandler::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);
-
- +@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
   typename hp::DoFHandler::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);
     }
-
- +@endcode Essentially, what the hanging_node_constraints.distribute_local_to_global calls do is to implement the same loop as before, but whenever we hit a constrained degree diff --git a/deal.II/examples/step-27/doc/results.dox b/deal.II/examples/step-27/doc/results.dox index 731f847474..241694aa16 100644 --- a/deal.II/examples/step-27/doc/results.dox +++ b/deal.II/examples/step-27/doc/results.dox @@ -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
 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
-
- +@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 diff --git a/deal.II/examples/step-3/doc/results.dox b/deal.II/examples/step-3/doc/results.dox index db822b3212..1ee4829f54 100644 --- a/deal.II/examples/step-3/doc/results.dox +++ b/deal.II/examples/step-3/doc/results.dox @@ -103,9 +103,10 @@ suggestions: indicator zero.

We can change this behavior if we assign parts of the boundary different indicators. For example, try this immediately after calling GridGenerator::hyper_cube: - 

+  @code
   triangulation.begin_active()->face(0)->set_boundary_indicator(1);
-
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 diff --git a/deal.II/examples/step-6/doc/results.dox b/deal.II/examples/step-6/doc/results.dox index 95700f9299..a46f75a24f 100644 --- a/deal.II/examples/step-6/doc/results.dox +++ b/deal.II/examples/step-6/doc/results.dox @@ -3,7 +3,7 @@ The output of the program looks as follows: -

+@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
-
+@endcode -- 2.39.5