fixed some typos

Author: brownbaerchen

pySDC/tutorial/step_1/README.rst

@@ -21,7 +21,7 @@ Important things to note:
    structure
 -  A quick peak into ``HeatEquation_1D_FD`` reveals that the ``init``
    and the ``params.nvars`` attribute contain the same values (namely
-   ``nvars``). Yet, sometime the one or the other is used here (and
+   ``nvars``). Yet, sometimes one or the other is used here (and
    throughout the code). The reason is this: the data structure
    (``mesh`` in this case) needs some form of standard initialization.
    For this, pySDC uses the ``init`` attribute each problem class has.

pySDC/tutorial/step_2/README.rst

@@ -12,7 +12,7 @@ the ``step``. It represents a single time step with whatever hierarchy
 we prescribe (more on that later). The relevant data (e.g. the solution
 and right-hand side vectors as well as the problem instances and so on)
 are all part of a ``level`` and a set of levels make a ``step``
-(together with transfer operators, see teh following tutorials). In this
+(together with transfer operators, see the following tutorials). In this
 first example, we simply create a step and test the problem instance of
 its only level. This is the same test we ran
 `here <../step_1/A_spatial_problem_setup.py>`__.
@@ -32,17 +32,17 @@ Part B: My first sweeper
 ------------------------
 
 Since we know how to create a step, we now create our first SDC
-iteration (by hand, this time). The make use of the IMEX SDC sweeper
+iteration (by hand, this time). We make use of the IMEX SDC sweeper
 ``imex_1st_order`` and of the problem class
 ``HeatEquation_1D_FD_forced``. Also, the data structure for the
 right-hand side is now ``rhs_imex_mesh``, since we need implicit and
 explicit parts of the right-hand side. The rest is rather
 straightforward: we set initial values and times, start by spreading the
-data and tehn do the iteration until the maximum number of iterastions
+data and then do the iteration until the maximum number of iterations
 is reached or until the residual is small enough. Yet, this example
 sheds light on the key functionalities of the sweeper:
 ``compute_residual``, ``update_nodes`` and ``compute_end_point``. Also,
-the ``step`` and ``level`` structures are explores a bit more deeply,
+the ``step`` and ``level`` structures are explored a bit more deeply,
 since we make use of parameters and status objects here.
 
 Important things to note:
@@ -51,9 +51,9 @@ Important things to note:
    do not have to deal with the internal data structures, see Part C
    below.
 -  Note the difference between status and parameter objects: parameters
-   are user-defined flags created using the dicitionaries (e.g.
+   are user-defined flags created using the dictionaries (e.g.
    ``maxiter`` as part of the ``step_params`` in this example), while
-   status objects are internal control objects which reflects the
+   status objects are internal control objects which reflect the
    current status of a level or a step (e.g. ``iter`` or ``time``).
 -  The logic required to implement an SDC iteration is simple but also
    rather tedious. This will get worse if you want to deal with more
@@ -77,8 +77,11 @@ Important things to note:
 -  By using one of the controllers, the whole code relevant for the user
    is reduced to setting up the ``description`` dictionary, some pre-
    and some post-processing.
--  During initializtion, the parameters used for the run are printed out. Also, user-defined/-changed parameters are indicated. This can be surpressed by setting the controller parameter ``dump_setup`` to False.
--  We make use of ``controller_parameters`` in order to provide logging to file capabilities.
+-  During initialization, the parameters used for the run are printed out.
+   Also, user-defined/-changed parameters are indicated. This can be
+   suppressed by setting the controller parameter ``dump_setup`` to False.
+-  We make use of ``controller_parameters`` in order to provide logging to
+   file capabilities.
 -  In contrast to Part B, we do not have direct access to residuals or
    iteration counts for now. We will deal with these later.
 -  This example is the prototype for a user to work with pySDC. Most of

pySDC/tutorial/step_3/README.rst

@@ -21,7 +21,7 @@ all residuals logged during time 0.1 (i.e. for all iterations in the
 first time step). Analogously, we could ask for all residuals at the
 final iteration of each step by calling
 ``filter_stats(stats, iter=-1, type='residual')``. The second helper
-routine converts the filtered or non-filtered dictionary to a listof
+routine converts the filtered or non-filtered dictionary to a list of
 tuples, where the first part is the item defined by the parameter
 ``sortby`` and the second part is the value. Here, we would like to have
 a list of iterations and residuals to see how SDC converged over the

pySDC/tutorial/step_4/README.rst

@@ -7,9 +7,9 @@ how MLSDC can be run and tested.
 Part A: Spatial transfer operators
 ----------------------------------
 
-For a mjltilevel hierarchy, we need transfer operators. The user, having
+For a multilevel hierarchy, we need transfer operators. The user, having
 knowledge of the data types, will have to provide a
-``space_transfer_class`` which deals with restriciton and interpolation
+``space_transfer_class`` which deals with restriction and interpolation
 in the spatial dimension. In this part, we simply set up two problems
 with two different resolutions and check the order of interpolation (4
 in this case).
@@ -36,15 +36,15 @@ collocation-based coarsening, we simply replace the ``num_nodes``
 parameter by a list, where the first entry corresponds to the finest
 level. For spatial coarsening, the problem parameter ``nvars`` is
 replaced by a list, too. During the step setup, these dictionaries with
-lists entries are transformed into lists of dictionaries corresponding
+list entries are transformed into lists of dictionaries corresponding
 to the levels (3 in this case). A third generic way of creating multiple
-levels is to replace an entry in the dscription by a list, e.g. a list
+levels is to replace an entry in the description by a list, e.g. a list
 of problem classes. The first entry of each list will always belong to
 the finest level.
 
 Important things to note:
 
--  Not all lists must habe the same length: The longest list defines the
+-  Not all lists must have the same length: The longest list defines the
    number of levels and if other lists are shorter, the levels get the
    last entry in these lists (3 nodes on level 1 and 2 in this example).
 -  As for most other parameters, ``space_transfer_class`` and
@@ -69,7 +69,8 @@ Important things to note:
 -  In this case, the number of iterations is halved when using MLSDC.
    This is the best case and in many situations, this cannot be
    achieved. In particular, the interpolation order is crucial.
--  Using the controller parameter ``predict``, we can turn the coarse level predictor on (default) or off in the case of MLSDC or PFASST.
+-  Using the controller parameter ``predict``, we can turn the coarse
+   level predictor on (default) or off in the case of MLSDC or PFASST.
 -  While MLSDC looks less expensive, the number of evaluations of the
    right-hand side of the ODE is basically the same: This is due to the
    fact that after each coarse grid correction (i.e. after the
@@ -94,10 +95,10 @@ replace the problem class by a simpler version: the coarse evaluation of
 the forces omits the particle-particle interaction and only takes
 external forces into account. This is done simply by replacing the
 problem class by a list of two problem classes in the description. In
-the rsults, we can see that all versions produce more or less the same
+the results, we can see that all versions produce more or less the same
 energies, where MLSDC without f-interpolation takes about half as many
 iterations and with f-interpolation slightly more. We also check the
-timings of the three runs: although MLSDC requires much less iterations,
+timings of the three runs: although MLSDC requires much fewer iterations,
 it takes longer to run. This is due to the fact that the right-hand side
 of the ODE (i.e. the costly force evaluation) is required after each
 interpolation! To this end, we also use f-interpolation, which increases

pySDC/tutorial/step_5/README.rst

@@ -7,14 +7,14 @@ Part A: Multistep multilevel hierarchy
 --------------------------------------
 
 In this first part, we create a controller and demonstrate how pySDC's data structures represent multiple time-steps.
-While for SDC the ``step`` data structure is the key part, we now habe simply a list of steps, bundled in the ``MS`` attribute of the controller.
+While for SDC the ``step`` data structure is the key part, we now have simply a list of steps, bundled in the ``MS`` attribute of the controller.
 The nice thing about going form MLSDC to PFASST is that only the number of processes in the ``num_procs`` variable has to be changed.
 This way the controller knows that multiple steps have to be computed in parallel.
 
 Important things to note:
 
 - To avoid the tedious installation of mpi4py and to have full access to all data at all times, the controllers with the ``_nonMPI`` suffix only emulate parallelism.
-  The algorithm is the same, but the steps are performed serially. Using ``MPI`` controllers allow for real parallelism and should yield the same results (see next tutorial step).
+  The algorithm is the same, but the steps are performed serially. Using ``MPI`` controllers allows for real parallelism and should yield the same results (see next tutorial step).
 - While in principle all steps can have a different number of levels, the controllers implemented so far assume that the number of levels is constant.
   Also, the instantiation of (the list of) steps via the controllers is implemented only for this case. Yet, pySDC's data structures in principle allow for different approaches.
 
@@ -25,9 +25,9 @@ Part B: My first PFASST run
 
 After we have created our multistep-multilevel hierarchy, we are now ready to run PFASST.
 We choose the simple heat equation for our first test.
-One of the most important characteristic of a parallel-in-time algorithm is its behavior for increasing number of parallel time-steps for a given problem (i.e. with ``dt`` and ``Tend`` fixed).
-Therefore, we loop over the number of parallel time-steps in this eample to see how PFASST performs for 1, 2, ..., 16 parallel steps.
-We compute and check the error as well as multiple statistical quantaties, e.g. the mean number of iterations, the range of iterations counts and so on.
+One of the most important characteristics of a parallel-in-time algorithm is its behavior for increasing number of parallel time-steps for a given problem (i.e. with ``dt`` and ``Tend`` fixed).
+Therefore, we loop over the number of parallel time-steps in this example to see how PFASST performs for 1, 2, ..., 16 parallel steps.
+We compute and check the error as well as multiple statistical quantities, e.g. the mean number of iterations, the range of iteration counts and so on.
 We see that PFASST performs very well in this case, the iteration counts do not increase significantly.
 
 Important things to note:
@@ -42,15 +42,15 @@ Part C: Advection and PFASST
 ----------------------------
 
 We saw in the last part that PFASST does perform very well for certain parabolic problems. Now, we test PFASST for an advection test case to see how things go then.
-The basic set up is the same, but now using only an implicit sweeper and periodic boundary conditions.
+The basic setup is the same, but now using only an implicit sweeper and periodic boundary conditions.
 To make things more interesting, we choose two different sweepers: the LU-trick as well as the implicit Euler and check how these are performing for this kind of problem.
 We see that in contrast to the parabolic problem, the iteration counts actually increase significantly, if more parallel time-steps are computed.
 Again, this heavily depends on the actual problem under consideration, but it is a typical behavior of parallel-in-time algorithms of this type.
 
 Important things to note:
 
 - The setup is actually periodic in time as well! At ``Tend = 1`` the exact solution looks exactly like the initial condition.
-- Like the standard IME sweeper, the ``generic_implicit`` sweeper allows the user to change the preconditioner, named ``QI``.
+- Like the standard IMEX sweeper, the ``generic_implicit`` sweeper allows the user to change the preconditioner, named ``QI``.
   To get the standard implicit Euler scheme, choose ``IE``, while for the LU-trick, choose ``LU``.
   More choices have been implemented in ``pySDC.plugins.sweeper_helper.get_Qd``.
 

pySDC/tutorial/step_6/README.rst

@@ -1,7 +1,7 @@
 Step-6: Advanced PFASST controllers
 ===================================
 
-We discuss controller implementations, features and parallelization of PFASST controller in this step.
+We discuss controller implementations, features and parallelization of PFASST controllers in this step.
 
 Part A: The nonMPI controller
 ------------------------------------------
@@ -39,14 +39,14 @@ To do this, pySDC comes with the MPI-parallelized controller, namely ``controlle
 It is supposed to yield the same results as the non-MPI counterpart and this is what we are demonstrating here (at least for one particular example).
 The actual code of this part is rather short, since the only task is to call another snippet (``playground_parallelization.py``) with different number of parallel processes.
 This is realized using Python's ``subprocess`` library and we check at the end if each call returned normally.
-Now, the snippet called by the example is the basically the same code as use by Parts A and B.
+Now, the snippet called by the example is basically the same code as used by Parts A and B.
 We can use the results of Parts A and B to compare with and we expect the same number of iterations, the same accuracy and the same difference between the two flavors as in Part A (up to machine precision).
 
 Important things to note:
 
 - The additional Python script ``playground_parallelization.py`` contains the code to run the MPI-parallel controller. To this end, we import the routine ``set_parameters`` from Part A to ensure that we use the same set of parameters for all runs.
 - This example also shows how the statistics of multiple MPI processes can be gathered and processed by rank 0, see ``playground_parallelization.py``.
-- The controller need a working installation of ``mpi4py``. Since this is not always easy to achieve and since debugging a parallel program can cause a lot of headaches, the non-MPI controller performs the same operations in serial.
+- The controller needs a working installation of ``mpi4py``. Since this is not always easy to achieve and since debugging a parallel program can cause a lot of headaches, the non-MPI controller performs the same operations in serial.
 - The somewhat weird notation with the current working directory ``cwd`` is due to the corresponding test, which, run by nosetests, has a different working directory than the tutorial.
 
 .. include:: doc_step_6_C.rst

pySDC/tutorial/step_7/README.rst

@@ -25,7 +25,7 @@ Part B: mpi4py-fft for parallel Fourier transforms
 
 The most prominent parallel solver is, probably, the FFT.
 While many implementations or wrappers for Python exist, we decided to use `mpi4py-fft <https://mpi4py-fft.readthedocs.io/en/latest/>`_, which provided the easiest installation, a simple API and good parallel scaling.
-As an example we here test the nonlinear Schrödinger equation, using the IMEX sweeper to treat the nonlinear parts explicitly.
+As an example, we here test the nonlinear Schrödinger equation, using the IMEX sweeper to treat the nonlinear parts explicitly.
 The code allows to work both in real and spectral space, while the latter is usually faster.
 This example tests SDC, MLSDC and PFASST.
 
@@ -48,6 +48,6 @@ See `implementations/datatype_classes/petsc_dmda_grid.py` and `implementations/p
 Important things to note:
 
 - We need processors in space and time, which can be achieved by `comm.Split` and coloring. The space-communicator is then passed to the problem class.
-- Below we run the code 3 times: with 1 and 2 processors in space as well as 4 processors (2 in time and 2 in space). Do not expect scaling due to the CI environment.
+- Below, we run the code 3 times: with 1 and 2 processors in space as well as 4 processors (2 in time and 2 in space). Do not expect scaling due to the CI environment.
 
 .. include:: doc_step_7_C.rst

pySDC/tutorial/step_8/README.rst

@@ -29,7 +29,7 @@ To prevent this, information can be sent forward immediately, but then this is n
 
 Important things to note:
 
-- Use the controller parameter ``mssdc_jac`` to controll whether the method should be "parallel" (Jacobi-like) or "serial" (Gauss-like).
+- Use the controller parameter ``mssdc_jac`` to control whether the method should be "parallel" (Jacobi-like) or "serial" (Gauss-like).
 - We increased the logging value here again, (safely) ignoring the warnings for multi-step SDC.
 
 .. include:: doc_step_8_B.rst
@@ -53,4 +53,4 @@ Important things to note:
 Part X: To be continued...
 --------------------------
 
-We shall see what comes next...
+We shall see what comes next...