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 33c4e5dd907f769abbd800122312913260716365..bf8a2eb2f5ff587c25115557587b83e025bb8a3a 100644 (file)
--- 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 49b9131ee23af9836ba7cc7b847041d212c03621..306bdb67f6fb82bd6c66f423b4ad6ac8b3be05f3 100644 (file)
--- 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