Merge branch 'fix-docs-typos' into 'master'

Tutorials and documentation maintenance

See merge request walberla/walberla!444

apps/benchmarks/FluidParticleCoupling/MotionSettlingSphere.cpp

@@ -606,7 +606,7 @@ private:
 /*
  * This extensive, physical test case simulates a single, heavy sphere in ambient fluid flow.
  * It is based on the benchmark proposed in
- * Uhlman, Dusek - "The motion of a single heavy sphere in ambient fluid: A benchmark for interface-resolved
+ * Uhlmann, Dusek - "The motion of a single heavy sphere in ambient fluid: A benchmark for interface-resolved
  *                  particulate flow simulations with significant relative velocities" IJMF (2014),
  *                  doi: 10.1016/j.ijmultiphaseflow.2013.10.010
  * Results for LBM done with waLBerla are published in

apps/benchmarks/MotionSingleHeavySphere/MotionSingleHeavySphere.cpp

@@ -615,7 +615,7 @@ private:
 /*
  * This extensive, physical test case simulates a single, heavy sphere in ambient fluid flow.
  * It is based on the benchmark proposed in
- * Uhlman, Dusek - "The motion of a single heavy sphere in ambient fluid: A benchmark for interface-resolved
+ * Uhlmann, Dusek - "The motion of a single heavy sphere in ambient fluid: A benchmark for interface-resolved
  *                  particulate flow simulations with significant relative velocities" IJMF (2014),
  *                  doi: 10.1016/j.ijmultiphaseflow.2013.10.010
  * Results for LBM done with waLBerla are published in
@@ -634,9 +634,9 @@ private:
  *    - solid collision operator variant: 1, 2, or 3
  *    - weighting factor variant: 1, or 2
  *
- * The results obtained by this benchmark should be compared to the reference spectral method results from Uhlman & Dusek.
+ * The results obtained by this benchmark should be compared to the reference spectral method results from Uhlmann & Dusek.
  * Furthermore, comparisons to the CFD-IBM (classical Navier-Stokes solver with immersed boundary method)
- * results from Uhlman & Dusek are available in their paper.
+ * results from Uhlmann & Dusek are available in their paper.
  * New coupling algorithms or algorithmic changes to the exiting approaches should also be cross-checked with the
  * values in Rettinger & Ruede.
  *

apps/showcases/BidisperseFluidizedBed/BidisperseFluidizedBedDPM.cpp

@@ -860,7 +860,7 @@ int main( int argc, char **argv ) {
                                  (real_t(1) - lnDryResCoeff * lnDryResCoeff / (math::pi * math::pi + lnDryResCoeff * lnDryResCoeff)));
    const real_t dampingCoeff = -real_t(2) * std::sqrt(Mij * stiffnessCoeff) *
                                (std::log(restitutionCoeff) / std::sqrt(math::pi * math::pi + (std::log(restitutionCoeff) * std::log(restitutionCoeff))));
-   const real_t contactDuration = real_t(2) * math::pi * Mij / (std::sqrt(real_t(4) * Mij * stiffnessCoeff - dampingCoeff * dampingCoeff)); //formula from Uhlman
+   const real_t contactDuration = real_t(2) * math::pi * Mij / (std::sqrt(real_t(4) * Mij * stiffnessCoeff - dampingCoeff * dampingCoeff)); //formula from Uhlmann
 
    WALBERLA_LOG_INFO_ON_ROOT("Created particle material with:\n"
                                    << " - coefficient of restitution = " << restitutionCoeff << "\n"

apps/tutorials/basics/01_BlocksAndFields.dox

@@ -19,7 +19,7 @@ In waLBerla, the domain is first partitioned into blocks, where each block holds
 This has the advantage that the domain can easily be distributed to multiple processes,
 where every process can have one or more local blocks.
 
-The following snippet shows how to create a simple domain decompositon that results in a uniform block grid: 
+The following snippet shows how to create a simple domain decomposition that results in a uniform block grid: 
 
 \code
 #include "core/Environment.h"
@@ -56,7 +56,7 @@ The last three parameters determine if the domain is periodic in x, y, or z dire
 There are a lot more ways for initializing the block decomposition of the simulation space in waLBerla. For this tutorial, we just use
 a very simple form of decomposition. In later tutorials, we will see that the domain decomposition can also be controlled via a configuration
 file that is passed to the application. Also, in general, you can have an arbitrary number of blocks on each process. This can be important
-for balancing work load. For load balancning, there exist many different algorithms: some make use of METIS, others are based on space filling curves.
+for balancing work load. For load balancing, there exist many different algorithms: some make use of METIS, others are based on space filling curves.
 It is even possible to decompose the simulation space into a set of octrees, resulting in a distributed forest of octrees data structure that
 contains blocks of different sizes. This form of decomposition can be used for simulations that require some form of grid refinement. 
 For now, however, we stick to a simple, uniform block decomposition.

apps/tutorials/basics/02_Sweeps.dox

@@ -13,7 +13,7 @@ A function that takes a single block as argument and operates on the block data
 
 For demonstrating how to write a sweep, let us implement the following "algorithm":
 - Initialize the scalar field with random values.
-- In each time step, double the value in the field if it is bigger than some limit, otherwise half the value.
+- In each time step, double the value in the field if it is bigger than some limit, otherwise halve the value.
 
 \section tut02_initialize Initializing the Field
 

apps/tutorials/basics/03_GameOfLife.dox

@@ -252,7 +252,7 @@ while( fieldIter != field->end() )
 Calling Field::clone() returns a pointer to a field that is newly allocated. We immediately
 catch this pointer with a shared_ptr. When the shared_ptr is destroyed at the end of the function,
 the dynamically allocated memory for the field is automatically freed and we don't have to take
-care of freeing the memory ourselves. Not freeing the memory would evantually cause the application to crash,
+care of freeing the memory ourselves. Not freeing the memory would eventually cause the application to crash,
 since this algorithm is called many times and each time the memory usage of our application would grow.
 
 As you can see, we now have to iterate two fields at the same time: `field` and `copy`. 

apps/tutorials/mesa_pd/01_MESAPD.dox

@@ -4,8 +4,8 @@ namespace mesa_pd {
 /**
 \page tutorial_mesapd_01 Tutorial - Confined Gas:  Setting up a simple MESA-PD simulation
 
-This tutorial will help you to setup up a simple simulation using the MESA-PD module.
-The scenario for this tutorial a is particle gas (spheres) confined by solid walls.
+This tutorial will help you to set up a simple simulation using the MESA-PD module.
+The scenario for this tutorial is a particle gas (spheres) confined by solid walls.
 
 For this tutorial only a few waLBerla includes are needed, namely:
 \snippet 01_MESAPD.cpp walberlaIncludes
@@ -31,9 +31,9 @@ You can choose the number of blocks you want to have in each direction. In a par
 
 \snippet 01_MESAPD.cpp BlockForest
 
-Next, we initialize all data structures that we need for the simulation. The data::ParticleStorage is the data container for all particles. The data::ShapeStorage stores information about the shape of the particles. This information is separated from the particle due to that fact that most of the time there are many similar particles in on simulation. With this approach you do not need to store the information for every particle but only once.
+Next, we initialize all data structures that we need for the simulation. The data::ParticleStorage is the data container for all particles. The data::ShapeStorage stores information about the shape of the particles. This information is separated from the particle due to that fact that most of the time there are many similar particles in one simulation. With this approach you do not need to store the information for every particle but only once.
 
-Since all kernels are written against an abstract interface to access the particle properties we also need a intermediate accessor class. This class is in most cases is the data::ParticleAccessorWithShape.
+Since all kernels are written against an abstract interface to access the particle properties we also need an intermediate accessor class. This class is in most cases data::ParticleAccessorWithShape.
 
 Finally, to improve the complexity of the collision detection step, we need a data::LinkedCells acceleration data structure.
 
@@ -53,7 +53,7 @@ The gas particles are generated with the help of grid generators. These generato
 
 Before we can run the simulation we have to set up all kernels that we will use.
 \snippet 01_MESAPD.cpp Kernels
-In this example we will use the explicit euler integration method. We further need a kernel which updates our LinkedCell data structure and an interaction kernel. For the collision detection we select the analytic functions available within the framework. Together with all synchronization kernels we can now run the simulation.
+In this example we will use the explicit Euler integration method. We further need a kernel which updates our LinkedCell data structure and an interaction kernel. For the collision detection we select the analytic functions available within the framework. Together with all synchronization kernels we can now run the simulation.
 
 \attention Before you start the simulation loop you should synchronize once to make sure everything is in place.
 

apps/tutorials/pde/01_SolvingPDE.dox

@@ -34,7 +34,7 @@ which yields the following discretized equation, valid for a Cartesian grid with
 \f]
 
 The resulting linear system of equations (\f$\mathbf{A}x=b\f$) can be solved with either a direct or an iterative solver. 
-Probably the simplest variant of latter is the Jacobi method which applies a splitting of the system matrix in its diagonal and off-diagonal parts
+Probably the simplest variant of the latter is the Jacobi method which applies a splitting of the system matrix in its diagonal and off-diagonal parts
 to come up with an iterative solution procedure. This finally allows to write the method in a matrix-free version, given by:
 \f[
    u_{i,j}^{(n+1)} = \left(\frac{2}{(\Delta x)^2} + \frac{2}{(\Delta y)^2} + 4\pi^2\right)^{-1}\left[ f_{i,j} + \frac{1}{(\Delta x)^2}\left(u_{i+1,j}^{(n)} + 
@@ -44,7 +44,7 @@ to come up with an iterative solution procedure. This finally allows to write th
 \section implementationJacobiSweep Implementation of the Jacobi Sweep
 
 Coming back to the concepts of waLBerla, this is a perfectly suitable example for a sweep. 
-It requires to sum up weighted values of the neighboring cells together with the function value of the right-hand side, 
+It requires summing up weighted values of the neighboring cells together with the function value of the right-hand side, 
 which is then divided by the weight of the center cell. 
 To avoid data dependencies, i.e., reading neighboring data that has already been updated in a previous step, 
 two fields (source and destination) are used like in \ref tutorial03. 
@@ -81,8 +81,8 @@ void JacobiSweep::operator()( IBlock * const block )
 
 This is already the entire implementation of the Jacobi method! 
 As always, there are of course various other ways to achieve this. 
-The stencil concept utilized by waLBerla allows a very convenient since flexible and also faster implementation with the help of neighborhood iterators and stencil weights.
-The performance problem of above implementation lies in the fact that the prefactors are recomputed for each step and each cell. 
+The stencil concept utilized by waLBerla allows a very convenient (since flexible) and also faster implementation with the help of neighborhood iterators and stencil weights.
+The performance problem of the above implementation lies in the fact that the prefactors are recomputed for each step and each cell. 
 Since they are constant, it is a better idea to precalculate them and store them in a `weights` vector.
 
 \code
@@ -150,7 +150,7 @@ dst->get(x,y,z) *= weights_[ Stencil_T::idx[ stencil::C ] ];
 Despite being faster, the implementation using the stencil concept is more flexible than the hard coded variant from the beginning 
 since it can be used for different stencil layouts.
 Say you use a different, probably higher-order, discretization of the PDE and come up with a D2Q9 stencil.
-Then, simply change the typedef to `typedef stencil::D2Q9 Stencil_T` and change and add the weight values in the `weights` vector accordingly. 
+Then, simply change the typedef to `typedef stencil::D2Q9 Stencil_T` and add the new weight values in the `weights` vector accordingly. 
 The implementation of the JacobiSweepStencil class stays untouched and the simulations can readily be carried out.
 
 

apps/tutorials/pde/02_HeatEquation.dox

@@ -25,7 +25,7 @@ and the initial distribution of \f$u\f$ inside the domain is given by the initia
 \f]
 
 For the numerical solution, we not only have to discretize in space but also in time. 
-Latter is done via an implicit Euler method with a time step length \f$\Delta t\f$ here, resulting in the following formulation: 
+The latter is done via an implicit Euler method with a time step \f$\Delta t\f$, resulting in the following formulation: 
 \f[
    \frac{u^{new} - u^{old}}{\Delta t} = \kappa \left( \frac{\partial^2 u^{new}}{\partial x^2} + \frac{\partial^2 u^{new}}{\partial y^2}\right)
 \f]
@@ -162,7 +162,7 @@ void Reinitialize::operator()( IBlock * block )
 \endcode 
 
 On a side note, this means that the starting solution for the Jacobi method is the former right-hand side.
-This is advantageous to setting it always to zero (which could be done via `src->set( real_c(0) )`) as it is probably already quite close to the converged solution,
+This is more advantageous compared to setting it always to zero (which could be done via `src->set( real_c(0) )`) as it is probably already quite close to the converged solution,
 i.e., the Jacobi method will converge faster.
 
 This functor is now registered as a sweep in the time loop in the known fashion:
@@ -292,7 +292,7 @@ The one that computes the total number of cells inside the domain and stores it
 \code
 void JacobiIterationResidual::init()
 {
-   // temporal storage
+   // temporary storage
    uint_t cells( uint_c(0) );
 
    // iterate all blocks
@@ -323,7 +323,7 @@ real_t JacobiIterationResidual::residualNorm()
       auto u   = block->getData< ScalarField >( srcID_ );
       auto rhs = block->getData< ScalarField >( rhsID_ );
 
-      // temporal storage
+      // temporary storage
       real_t residual( real_c(0) );
 
       // iterate all cells inside the block

apps/tutorials/pde/03_HeatEquation_Extensions.cpp

@@ -161,7 +161,7 @@ void JacobiIterationResidual::operator()()
 
 void JacobiIterationResidual::init()
 {
-   // temporal storage
+   // temporary storage
    uint_t cells( uint_c(0) );
 
    // iterate all blocks
@@ -189,7 +189,7 @@ real_t JacobiIterationResidual::residualNorm()
       auto u   = block->getData< ScalarField >( srcID_ );
       auto rhs = block->getData< ScalarField >( rhsID_ );
 
-      // temporal storage
+      // temporary storage
       real_t residual( real_c(0) );
 
       // iterate all cells inside the block

apps/tutorials/pe/01_ConfinedGas.dox

@@ -4,7 +4,7 @@ namespace pe {
 /**
 \page tutorial_pe_01 Tutorial - Confined Gas:  Setting up a simple pe simulation
 
-This tutorial will help you to setup up a simple pe simulation. The scenario for this tutorial a is particle
+This tutorial will help you to set up a simple pe simulation. The scenario for this tutorial is a particle
 gas (spheres) confined by solid walls.
 
 For this tutorial only a few includes are needed, namely:
@@ -79,7 +79,7 @@ access their properties.
 \snippet 01_ConfinedGas.cpp PostProcessing
 
 Congratulation! You successfully created your first rigid body simulation.
-In the next tutorial we will look at possible extensions which can make your live easier.
+In the next tutorial we will look at possible extensions which can make your life easier.
 
 */
 

apps/tutorials/pe/02_ConfinedGasExtended.dox

@@ -4,7 +4,7 @@ namespace pe {
 /**
 \page tutorial_pe_02 Tutorial - Useful Features
 
-This tutorial will introduce some useful features of the waLBerla framework which can make your live easier.
+This tutorial will introduce some useful features of the waLBerla framework which can make your life easier.
 
 \section tutorial_pe_02_checkpointing Checkpointing
 You can checkpoint the current state of your rigid body dynamics simulation at any point to restore it afterwards.
@@ -51,7 +51,7 @@ Environment::config() function. You can access subblocks of the config with conf
 \snippet LoadFromConfig.cpp Load Config
 To get values from the config call config::Config::getParameter():
 \snippet LoadFromConfig.cpp Config Get Parameter
-Certain task already have predefined loading functions. You can for example directly create a BlockForest
+Certain tasks already have predefined loading functions. You can for example directly create a BlockForest
 from the config file.
 \snippet LoadFromConfig.cpp Config BlockForest
 The corresponding block in the config file looks like:
@@ -73,18 +73,18 @@ globalLinearAcceleration < 1, -2, 3 >;
 \endcode
 
 \section tutorial_pe_02_timing Timing
-To get additional information where you application spends its time you can use the WcTimingTree.
-It will give you a hirarchical view of the time used.
+To get additional information where your application spends its time you can use the WcTimingTree.
+It will give you a hierarchical view of the time used.
 Usage example:
 \snippet 02_ConfinedGasExtended.cpp TT Example
 Before you output the information you should collect all the information from all the processes if you are running
 in parallel.
 \snippet 02_ConfinedGasExtended.cpp TT Log
-Many build-in functions like solver or synchronization methods come with an additional parameter where you can
+Many built-in functions like solver or synchronization methods come with an additional parameter where you can
 specify your timing tree. They will then include detailed information in your timing tree.
 
 \section tutorial_pe_02_sqlite SQLite Output
-waLBerla also supports SQLite database for simulation data output. This can come in handy in parallel simulations
+waLBerla also supports SQLite databases for simulation data output. This can come in handy in parallel simulations
 as well as in data analysis. To store information in a SQLite database you have to fill three property maps
 depending on the type of information you want to store.
 \snippet 02_ConfinedGasExtended.cpp SQLProperties

src/blockforest/BlockForest.h

@@ -382,7 +382,7 @@ public:
    //         e.g. diffusive or space filling curve strategy
    // 4) data migration / refinement / coarsening
 
-   /// Triggeres AMR Pipeline
+   /// Triggers AMR Pipeline
    void refresh();
 
    /// Functor that calls refresh with given frequency

src/blockforest/BlockNeighborhoodConstruction.cpp

@@ -219,4 +219,4 @@ void constructNeighborhoodSectionBlockCenters( uint_t sectionIndex, const AABB&
 
 
 } // namespace blockforest
-} // namespace walblera
+} // namespace walberla

src/blockforest/Initialization.cpp

@@ -85,7 +85,7 @@ shared_ptr< StructuredBlockForest > createUniformBlockGridFromConfig( const shar
 \endverbatim
 *          An optional config parameter 'cartesianSetup' is available. Its default, true, causes one block to be
 *          assigned to each process. Setting it to false allows multiple blocks to be assigned to each process.
-*          If the number of blocks is not divisble by the number of processes, the loadbalancer tries to assign
+*          If the number of blocks is not divisible by the number of processes, the loadbalancer tries to assign
 *          the blocks to processes as evenly as possible.
 *    2) Using the number of global cells, #blocks = #processes, if this does not fit, extend the domain
 \verbatim

src/blockforest/communication/DirectionBasedReduceScheme.h

@@ -147,7 +147,7 @@ template< stencil::Direction dir_ >
 void DirectionBasedReduceScheme<dir_>::init()
 {
    if( !blockForest_->containsGlobalBlockInformation() )
-      WALBERLA_ABORT( "For this communication scheme global block information is neeeded" );
+      WALBERLA_ABORT( "For this communication scheme global block information is needed" );
 
    //  -------------------  Block Loop ------------------------------------------------
    uint_t x,y,z;

src/blockforest/loadbalancing/DynamicCurve.h

@@ -208,7 +208,7 @@ bool DynamicCurveBalance< PhantomData_T >::operator()( std::vector< std::pair< c
                                                                 std::set< uint_t > & processesToRecvFrom,
                                                                 const PhantomBlockForest & phantomForest, const uint_t ) const
 {
-   // Do not change or modifiy this check.
+   // Do not change or modify this check.
    // The Hilbert curve construction relies on "std::numeric_limits< idx_t >::max()" being an invalid number of blocks for a process
    WALBERLA_CHECK_LESS( targetProcess.size(), std::numeric_limits< idx_t >::max() );
    

src/communication/doc/walberlaCommunication.dox

@@ -70,7 +70,7 @@ Gatherv.h , Reduce.h and Broadcast.h
    to implement the communication logic. It consists of communication schemes, the most prominent
    is walberla::blockforest::communication::UniformBufferedScheme . It exchanges information with all neighboring blocks, where the
    data extraction and insertion is handled by the registered PackInfos. There are other more specialized schemes available,
-   as an example have a look at walberla::blockforest::communciation::DirectionBasedReduceScheme.
+   as an example have a look at walberla::blockforest::communication::DirectionBasedReduceScheme.
 
 
 \section direct_comm Direct Communication

src/core/UniqueID.h

@@ -46,7 +46,7 @@ namespace walberla {
  * \ingroup core
  *
  * The UniqueID class is responsible for the generation of unique system IDs even during an MPI
- * parallel execution. The unqiue ID is composed from the number of locally generated objects
+ * parallel execution. The unique ID is composed from the number of locally generated objects
  * of type \a T and the rank of the local MPI process.
  */
 template< typename T >

src/core/cell/Cell.h

@@ -121,7 +121,7 @@ inline Cell::Cell( const uint_t _x, const uint_t _y, const uint_t _z )
 /*******************************************************************************************************************//**
  * \brief   Less-than comparison operator for Cells.
  *
- * Compares a cell's coordinates lexicographically (first x, than eventualy y and (if necessary) finally z).
+ * Compares a cell's coordinates lexicographically (first x, then eventually y and (if necessary) finally z).
  *
  * \param [in] rhs  the cell compared to *this.
  *
@@ -138,7 +138,7 @@ inline bool Cell::operator<( const Cell & rhs ) const
  /******************************************************************************************************************//**
  * \brief   Equal comparison operator for Cells.
  *
- * Compares a cell's coordinates for equality (first x, then eventualy y and (if necessary) finally z).
+ * Compares a cell's coordinates for equality (first x, then eventually y and (if necessary) finally z).
  *
  * \param [in] rhs  The cell compared to *this.
  *