From: Martin Kronbichler <kronbichler@lnm.mw.tum.de>
Date: Fri, 4 Sep 2009 13:56:38 +0000 (+0000)
Subject: Language fixes.
X-Git-Tag: v8.0.0~7180
X-Git-Url: https://gitweb.dealii.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=2470a6200fff28bc6b0b68b63c8660ccce0ae869;p=dealii.git

Language fixes.

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

diff --git a/deal.II/examples/step-37/doc/intro.dox b/deal.II/examples/step-37/doc/intro.dox
index 33c4e5dd90..bf8a2eb2f5 100644
--- a/deal.II/examples/step-37/doc/intro.dox
+++ b/deal.II/examples/step-37/doc/intro.dox
@@ -22,7 +22,7 @@ the sparse matrix (assembling) and in performing some matrix-vector products
 (possibly together with some substitutions like in SSOR preconditioners) in
 an iterative Krylov method. This is a general concept in finite element
 programs. Depending on the quality of the linear solver and the complexity
-of the equation to be solved, between 40 and 95 precent of the computational
+of the equation to be solved, between 40 and 95 per cent of the computational
 time is spent in performing sparse matrix-vector products.
 
 Let us briefly look at a simplified version of code for the matrix-vector
diff --git a/deal.II/examples/step-37/step-37.cc b/deal.II/examples/step-37/step-37.cc
index 49b9131ee2..306bdb67f6 100644
--- a/deal.II/examples/step-37/step-37.cc
+++ b/deal.II/examples/step-37/step-37.cc
@@ -765,10 +765,10 @@ MatrixFree<number,Transformation>::calculate_diagonal() const
 				 // constraints, the small matrix and of the
 				 // local variables. Just as a remark: In 2D
 				 // and with data type <code>double</code>,
-				 // about 80 precent of the memory
+				 // about 80 per cent of the memory
 				 // consumption is due to the
 				 // <code>derivatives</code> array, in 3D
-				 // even 85 precent.
+				 // even 85 per cent.
 template <typename number, class Transformation>
 std::size_t MatrixFree<number,Transformation>::memory_consumption () const
 {
@@ -1267,7 +1267,7 @@ void LaplaceProblem<dim>::assemble_multigrid ()
 
 				 // The solution process again looks like
 				 // step-16. We now use a Chebyshev smoother
-				 // instead of SSOR (SSOR would very
+				 // instead of SOR (SOR would very
 				 // difficult to implement because we do not
 				 // have the matrix elements explicitly
 				 // available, and it is difficult to make