From 0ec711f5f892d41350f7df649196205af4cd0bd6 Mon Sep 17 00:00:00 2001 From: Wolfgang Bangerth Date: Mon, 24 Sep 2001 08:25:31 +0000 Subject: [PATCH] Fix spelling. git-svn-id: https://svn.dealii.org/trunk@5033 0785d39b-7218-0410-832d-ea1e28bc413d --- deal.II/examples/step-1/step-1.cc | 4 ++-- deal.II/examples/step-10/step-10.cc | 12 ++++++------ deal.II/examples/step-11/step-11.cc | 8 ++++---- deal.II/examples/step-2/step-2.cc | 2 +- deal.II/examples/step-6/step-6.cc | 22 ++++++++++++---------- deal.II/examples/step-9/step-9.cc | 14 +++++++------- 6 files changed, 32 insertions(+), 30 deletions(-) diff --git a/deal.II/examples/step-1/step-1.cc b/deal.II/examples/step-1/step-1.cc index 9250c7de89..de2971101d 100644 --- a/deal.II/examples/step-1/step-1.cc +++ b/deal.II/examples/step-1/step-1.cc @@ -94,7 +94,7 @@ void second_grid () // center of the ring shall be the // point (1,0), and inner and outer // radius shall be 0.5 and 1. The - // number of circumferentical cells + // number of circumferential cells // could be adjusted automatically // by this function, but we choose // to set it explicitely as the @@ -111,7 +111,7 @@ void second_grid () // of the coarse grid (which we // just created). Here, however, we // would like to have a curved - // boundary. Furtunately, some good + // boundary. Fortunately, some good // soul implemented an object which // describes the boundary of a ring // domain; it only needs the center diff --git a/deal.II/examples/step-10/step-10.cc b/deal.II/examples/step-10/step-10.cc index d597be3be9..7062c8d6b3 100644 --- a/deal.II/examples/step-10/step-10.cc +++ b/deal.II/examples/step-10/step-10.cc @@ -95,7 +95,7 @@ void gnuplot_output() // the mesh refinement in the loop // header, which might be uncommon // but nevertheless works. Also it - // is strangly consistent with + // is strangely consistent with // incrementing the loop index // denoting the refinement level. for (unsigned int refinement=0; refinement<2; @@ -165,7 +165,7 @@ void gnuplot_output() // does so significantly // faster. ``MappingQ1'' is // also the class that is - // implicitely used + // implicitly used // throughout the library // in many functions and // classes if you do not @@ -360,13 +360,13 @@ void compute_pi_by_area () const FE_Q dummy_fe (1); // Likewise, we need to create - // a DofHandler object. We do + // a DoFHandler object. We do // not actually use it, but it // will provide us with // `active_cell_iterators' that - // are needed to reinit the - // FEValues object on each cell - // of the triangulation. + // are needed to reinitialize + // the FEValues object on each + // cell of the triangulation. DoFHandler dof_handler (triangulation); // Now we set up the FEValues diff --git a/deal.II/examples/step-11/step-11.cc b/deal.II/examples/step-11/step-11.cc index e2d56563a0..b2343e34c8 100644 --- a/deal.II/examples/step-11/step-11.cc +++ b/deal.II/examples/step-11/step-11.cc @@ -397,7 +397,7 @@ void LaplaceProblem::assemble_and_solve () // the ``MatrixCreator'' and // ``MatrixTools'' // classes. Whenever you need a - // slighly different version of + // slightly different version of // these functions than the ones // called above, it is certainly // worthwhile to take a look at the @@ -439,7 +439,7 @@ void LaplaceProblem::assemble_and_solve () // fixed R, but it also provides // quadrature rules of higher // degree which are no longer - // hardcoded in the library. + // hard-coded in the library. // Since the generation of the body // force contributions to the right @@ -508,7 +508,7 @@ void LaplaceProblem::assemble_and_solve () // Finally, evaluate what we got as // solution. As stated in the // introduction, we are interested - // in the H1 seminorm of the + // in the H1 semi-norm of the // solution. Here, as well, we have // a function in the library that // does this, although in a @@ -529,7 +529,7 @@ void LaplaceProblem::assemble_and_solve () // (which we make us of here), and // the one which we have used in // previous examples which - // implicitely uses ``MappingQ1''. + // implicitly uses ``MappingQ1''. // Also note that we take a // quadrature formula of one degree // higher, in order to avoid diff --git a/deal.II/examples/step-2/step-2.cc b/deal.II/examples/step-2/step-2.cc index 357553d9ea..c78868998d 100644 --- a/deal.II/examples/step-2/step-2.cc +++ b/deal.II/examples/step-2/step-2.cc @@ -74,7 +74,7 @@ void make_grid (Triangulation<2> &triangulation) center, inner_radius, outer_radius, 10); // This is the single difference to - // the respetive function in the + // the respective function in the // previous program: since we want // to export the triangulation // through this function's diff --git a/deal.II/examples/step-6/step-6.cc b/deal.II/examples/step-6/step-6.cc index e44207b5b0..26c77d6609 100644 --- a/deal.II/examples/step-6/step-6.cc +++ b/deal.II/examples/step-6/step-6.cc @@ -254,11 +254,13 @@ LaplaceProblem::LaplaceProblem () : // usually abort upon the attempt to // destroy the finite element. // - // As a sidenote, we remark that - // these exception are not - // particularly popular among - // programmers, since they only tell - // us that some other object is still + // As a side-note, we remark that + // this exception about still used + // objects are not particularly + // popular among programmers using + // deal.II, since they only tell us + // that something is wrong, namely + // that some other object is still // using the object that is presently // destructed, but not which one. It // is therefore often rather @@ -281,7 +283,7 @@ LaplaceProblem::LaplaceProblem () : // situation, if we did not write // this destructor, the compiler will // generate code that triggers - // exactly the behaviour sketched + // exactly the behavior sketched // above. The reason is that member // variables of the // ``LaplaceProblem'' class are @@ -600,7 +602,7 @@ void LaplaceProblem::solve () preconditioner); // To set the constrained nodes to - // resonable values, you have to + // reasonable values, you have to // use the following function. It // computes the values of these // nodes from the values of the @@ -788,7 +790,7 @@ void LaplaceProblem::refine_grid () // class that implements // several different algorithms to // refine a triangulation based on - // cellwise error indicators. + // cell-wise error indicators. GridRefinement::refine_and_coarsen_fixed_number (triangulation, estimated_error_per_cell, 0.3, 0.03); @@ -960,7 +962,7 @@ void LaplaceProblem::run () // switched off in optimized mode, in // contrast to the ``Assert'' macro // which we have used to test against - // programming errors. If uncought, + // programming errors. If uncaught, // these exceptions propagate the // call tree up to the ``main'' // function, and if they are not @@ -1060,7 +1062,7 @@ int main () // If we got to this point, there // was no exception which // propagated up to the main - // functino (maybe there were some, + // function (maybe there were some, // but they were caught somewhere // in the program or the // library). Therefore, the program diff --git a/deal.II/examples/step-9/step-9.cc b/deal.II/examples/step-9/step-9.cc index 5ee4440065..e2f811f86e 100644 --- a/deal.II/examples/step-9/step-9.cc +++ b/deal.II/examples/step-9/step-9.cc @@ -33,7 +33,7 @@ // The following two files provide // classes and information for - // multithreaded programs. In the + // multi-threaded programs. In the // first one, the classes and // functions are declared which we // need to start new threads and to @@ -145,7 +145,7 @@ class AdvectionProblem // When assembling the matrix in // parallel, we have to - // synchronise when several + // synchronize when several // threads attempt to write the // local contributions of a cell // to the global matrix at the @@ -176,7 +176,7 @@ class AdvectionProblem // course, since if only one // thread is running at a time, // there is no need to - // synchronise with other + // synchronize with other // threads. Threads::ThreadMutex assembler_lock; }; @@ -1261,7 +1261,7 @@ assemble_system_interval (const typename DoFHandler::active_cell_iterator & // multi-threading, then there // can't be parallel threads // and there is no need to - // synchronise. Thus, the + // synchronize. Thus, the // ``lock'' and ``release'' // functions are no-ops, // i.e. they return without @@ -1540,7 +1540,7 @@ GradientEstimation::estimate (const DoFHandler &dof_handler, // principle, an optimized // implementation would find // neighbors and the quantities - // dependening on them in one step, + // depending on them in one step, // rather than first building a list // of neighbors and in a second step // their contributions. @@ -1592,7 +1592,7 @@ GradientEstimation::estimate_interval (const DoFHandler &dof_handler, // cell and advancing them using // the given start and end // index. Note that we can use the - // ``advance'' functino of the + // ``advance'' function of the // standard C++ library, but that // we have to cast the distance by // which the iterator is to be @@ -1879,7 +1879,7 @@ GradientEstimation::estimate_interval (const DoFHandler &dof_handler, // computation on each of // them. First we do some // preliminaries: find out - // about the center iof the + // about the center of the // present cell and the // solution at this point. The // latter is obtained as a -- 2.39.5