From: Timo Heister <timo.heister@gmail.com>
Date: Fri, 2 Aug 2013 16:43:55 +0000 (+0000)
Subject: documentation patch by Oleh Krehel
X-Git-Tag: v8.1.0~1152
X-Git-Url: https://gitweb.dealii.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=81d1bb60e63e6756023577c32c3802f9afab5203;p=dealii.git

documentation patch by Oleh Krehel

git-svn-id: https://svn.dealii.org/trunk@30218 0785d39b-7218-0410-832d-ea1e28bc413d
---

diff --git a/deal.II/examples/step-16/step-16.cc b/deal.II/examples/step-16/step-16.cc
index fd0caadd6c..f5e657493e 100644
--- a/deal.II/examples/step-16/step-16.cc
+++ b/deal.II/examples/step-16/step-16.cc
@@ -99,7 +99,7 @@ namespace Step16
   class LaplaceProblem
   {
   public:
-    LaplaceProblem (const unsigned int deg);
+    LaplaceProblem (const unsigned int degree);
     void run ();
 
   private:
@@ -130,7 +130,7 @@ namespace Step16
     const unsigned int degree;
 
     // The following four objects are the only additional member variables,
-    // compared to step-6. They first three represent the operators that act
+    // compared to step-6. The first three represent the operators that act
     // on individual levels of the multilevel hierarchy, rather than on the
     // finest mesh as do the objects above while the last object stores
     // information about the boundary indices on each level and information
@@ -351,7 +351,7 @@ namespace Step16
 
   // @sect4{LaplaceProblem::assemble_system}
 
-  // The following function assembles the linear system on the finesh level of
+  // The following function assembles the linear system on the finest level of
   // the mesh. It is almost exactly the same as in step-6, with the exception
   // that we don't eliminate hanging nodes and boundary values after
   // assembling, but while copying local contributions into the global
@@ -472,9 +472,9 @@ namespace Step16
     // The indices just identified will later be used to decide where the
     // assembled value has to be added into on each level.  On the other hand,
     // we also have to impose zero boundary conditions on the external
-    // boundary of each level. But this the <code>MGConstraints</code> knows
-    // it. So we simply ask for them by calling <code>get_boundary_indices
-    // ()</code>.  The third step is to construct constraints on all those
+    // boundary of each level. But this the <code>MGConstraints</code> knows.
+    // So we simply ask for them by calling <code>get_boundary_indices()</code>.
+    // The third step is to construct constraints on all those
     // degrees of freedom: their value should be zero after each application
     // of the level operators. To this end, we construct ConstraintMatrix
     // objects for each level, and add to each of these constraints for each
diff --git a/deal.II/examples/step-17/step-17.cc b/deal.II/examples/step-17/step-17.cc
index 26ae4e5c0d..0b9499c848 100644
--- a/deal.II/examples/step-17/step-17.cc
+++ b/deal.II/examples/step-17/step-17.cc
@@ -245,10 +245,11 @@ namespace Step17
   // communicator object that only links a subset of all processes), and call
   // the Utilities helper functions to determine the number of processes and
   // where the present one fits into this picture. In addition, we make sure
-  // that output is only generated by the (globally) first process. As,
-  // this_mpi_process is determined after creation of pcout, we cannot set the
-  // condition through the constructor, i.e. by pcout(std::cout,
-  // this_mpi_process==0), but set the condition separately.
+  // that output is only generated by the (globally) first process. As
+  // <code>this_mpi_process</code> is determined after creation of pcout, we
+  // cannot set the condition through the constructor, i.e. by
+  // <code>pcout(std::cout, this_mpi_process==0)</code>, but set the
+  // condition separately.
   template <int dim>
   ElasticProblem<dim>::ElasticProblem ()
     :
@@ -537,7 +538,7 @@ namespace Step17
     // The last argument to the call just performed allows for some
     // optimizations. It controls whether we should also delete the column
     // corresponding to a boundary node, or keep it (and passing
-    // <code>true</code> as above means: yes, do eliminate the column). If we
+    // <code>true</code> means: yes, do eliminate the column). If we
     // do, then the resulting matrix will be symmetric again if it was before;
     // if we don't, then it won't. The solution of the resulting system should
     // be the same, though. The only reason why we may want to make the system