Feature/user doc

doc/userdoc.org

@@ -639,7 +639,7 @@ This may sound strange but there are few reasons for that.
     defining a mesh in dimension $d$ are elements of $\mathbb{R}^d$,
   - or that a velocity or a displacement are also defined as
     $\mathbb{R}^d$ values.
-  Thus using ~R^1~ in dimension $1$ for this kind data precise their
+  Thus using ~R^1~ in dimension $1$ for this kind of data precise their
   nature in some sense .
 #+END_note
 
@@ -737,7 +737,7 @@ in the modification of the stored value. There is no copy.
 Actually, this is not really important from the user point of
 view. One just have to keep in mind that, as it will be depicted
 after, high-level variables *are not mutable*: their values can be
-*replaced* by a new ones but *cannot be modified*.
+*replaced* by new ones but *cannot be modified*.
 
 *** Implicit type conversions<<implicit-conversion>>
 
@@ -1287,30 +1287,30 @@ This code produces
 **** Binary operators
 
 Syntax for binary operators follows again a classical structure: if
-~exp1~ and ~exp2~ denotes two expressions and if ~op~ denotes a binary
+~exp1~ and ~exp2~ denote two expressions and if ~op~ denotes a binary
 operator, one simply writes ~exp1 op exp2~.
 
 Here is the list of binary operators
-| keyword | operator              |
-|---------+-----------------------|
-| ~and~     | logic and             |
-| ~or~      | logic or              |
-| ~xor~     | logic exclusive or    |
-|---------+-----------------------|
-| ~==~      | equality              |
-| ~!=~      | non-equality          |
-| ~<~       | lower than            |
-| ~<=~      | lower or equal than   |
-| ~>~       | greater than          |
-| ~>=~      | greater or equal than |
-|---------+-----------------------|
-| ~<<~      | shift left            |
-| ~>>~      | shift right           |
-|---------+-----------------------|
-| ~+~       | sum                   |
-| ~-~       | difference            |
-| ~*~       | product               |
-| ~/~       | division              |
+| keyword | operator                 |
+|---------+--------------------------|
+| ~and~     | logic and                |
+| ~or~      | logic or                 |
+| ~xor~     | logic exclusive or       |
+|---------+--------------------------|
+| ~==~      | equality                 |
+| ~!=~      | non-equality             |
+| ~<~       | lower than               |
+| ~<=~      | lower than or equal to   |
+| ~>~       | greater than             |
+| ~>=~      | greater than or equal to |
+|---------+--------------------------|
+| ~<<~      | shift left               |
+| ~>>~      | shift right              |
+|---------+--------------------------|
+| ~+~       | sum                      |
+| ~-~       | difference               |
+| ~*~       | product                  |
+| ~/~       | division                 |
 
 Binary operators can be defined for high-level types. For basic types,
 they follow a few rules.
@@ -1329,7 +1329,7 @@ they follow a few rules.
     \end{equation*}
   #+end_src
 - Comparison operators ~==~, ~!=~, ~<~, ~<=~, ~>~ and ~>=~ are defined for all
-  basic scalar type and return a boolean value.
+  basic scalar types and return a boolean value.
   #+begin_src latex :results drawer :exports results
     \begin{equation*}
       \forall \mathbb{S}_1, \mathbb{S}_2 \in \{\mathbb{B},\mathbb{N},\mathbb{Z},\mathbb{R}\},
@@ -1386,7 +1386,7 @@ they follow a few rules.
   combinations of basic types. We classify them by their returned
   types.
 
-  - Their is no arithmetic operation that returns a boolean ~B~.
+  - There are no arithmetic operations that return a boolean ~B~.
 
   - Operators that return a natural integer ~N~.
     #+begin_src latex :results drawer :exports results
@@ -1528,7 +1528,7 @@ they follow a few rules.
 To avoid confusions, the operators precedence in ~pugs~ language follows
 the same rules as in ~C++~.
 
-This is summarized in the following table, where ~a~ and ~b~ denotes two
+This is summarized in the following table, where ~a~ and ~b~ denote two
 expressions.
 | Precedence | Operator |
 |------------+----------|
@@ -1610,7 +1610,7 @@ script).
 The second difference is that data of these types are *constant*. More
 precisely, the content of high-level variables can be replaced by a
 new one *but* it cannot be modified. For this reason, the following
-operators can never be applied to variables of this kind
+operators can never be applied to variables of these kinds
 | forbidden operators | description                 |
 |---------------------+-----------------------------|
 | ~++~                  | pre/post increment operator |
@@ -1650,10 +1650,10 @@ In this example, we are dealing with 3 ~mesh~ variables.
   duplication of the mesh in memory.
 - Then, the variable ~m3~ is defined to refer to a *new* mesh (called
   $\mathcal{M}_b$. It is /similar/ to $\mathcal{M}_a$, but it is *not* the
-  same one! When ~m3~ is defined two meshes $\mathcal{M}_a$ and
+  same one! When ~m3~ is defined, two meshes $\mathcal{M}_a$ and
   $\mathcal{M}_b$ (and two distinct connectivities) are resident in
   memory.
-- Finally, the last instruction (~m3 = m1;~) sets ~m3~ to also refer
+- Finally, the last instruction (~m3 = m1;~) sets ~m3~ to also refer to
   $\mathcal{M}_a$. Since no other variable refers to $\mathcal{M}_b$,
   this mesh is destroyed (memory is freed). At the end of the program,
   all the variables ~m1~, ~m2~ and ~m3~ are referring to $\mathcal{M}_a$
@@ -1755,9 +1755,9 @@ is the operator ~=~.
 **** Use of compound types
 
 Actually using compound types the way it is presented in this
-paragraph is not recommend. The purpose of compounds types and
-compound affectations is related to functions. As one will see in
-section [[functions]], functions can return compound values, thus compound
+paragraph is not recommend. The purpose of compound types and compound
+affectations is related to functions. As one will see in section
+[[functions]], functions can return compound values, thus compound
 affectations (or definitions) are needed to get returned values in
 that case.
 
@@ -1801,7 +1801,7 @@ Observe that the special value ~0~ is used there.
 
 **** Tuple purpose
 
-Tuples variables are just lists of data of the same type. In the ~pugs~
+Tuple variables are just lists of data of the same type. In the ~pugs~
 language, one cannot access to a specific value of the list nor alter
 one of them. This is not something that should ever change. Tuples are
 not arrays! The ~pugs~ language is not meant to allow low-level
@@ -1816,10 +1816,10 @@ boundary conditions to a method.
 The ~pugs~ language supports classical statements to control the data
 flow. For simplicity, these statements syntax follow their ~C++~
 counterpart. The only statement that is not implemented in ~pugs~ is the
-~switch...case~. This may change but in the one hand, up to now it was
-never necessary (up to now, we did not encountered the need to chain
-~if...else~ statements), and on the other hand, keeping the language as
-simple as possible remains the policy in ~pugs~ development.
+~switch...case~. This may change but in the one hand, up to now it has
+never been necessary (up to now, we did not encountered the need to
+chain ~if...else~ statements), and on the other hand, keeping the
+language as simple as possible remains the policy in ~pugs~ development.
 
 *** ~if...else~ statement
 
@@ -1902,11 +1902,11 @@ are optional. The ~condition~ argument, if it is present, *must* be a
 boolean value (type ~B~). If it is absent, the default value ~true~ is
 used.
 
-- The ~declarationinstruction~ is execute only *once* /before/ the beginning
+- The ~declarationinstruction~ is executed only *once* /before/ the beginning
   of the loop. The lifetime of the variable declared here is defined
   by the ~for~ instruction itself.
 
-- The ~condition~ is evaluate /before/ each loop.
+- The ~condition~ is evaluated /before/ each loop.
 
 - The ~postinstruction~ is executed /after/ each loop.
 
@@ -1986,7 +1986,7 @@ The ~statement~ is either a single instruction or a block of
 instructions. The ~condition~ is an expression of boolean value (type
 ~B~).
 
-This time is the ~condition~ is not satisfied (~false~ when reaching the
+This time if the ~condition~ is not satisfied (~false~ when reaching the
 ~while~ instruction), the ~statment~ is never executed.
 
 An example of the ~while~ loop is the following.
@@ -2167,10 +2167,10 @@ Using compound types as input and output, one can write
 This meaningless example produces the following result.
 #+results: R22-R-string-to-R-string-function
 
-**** Lifetime of functions arguments
+**** Lifetime of functions' arguments
 
-The arguments used to define a function are *local* variables that
-exists only during the evaluation of the function.
+The arguments used to define a function are *local* variables that exist
+only during the evaluation of the function.
 
 Let us consider the following example
 #+NAME: lifetime-of-function-args
@@ -2187,7 +2187,7 @@ This gives the expected result: the value of the variable ~a~ is
 unchanged.
 #+results: lifetime-of-function-args
 
-**** Non-arguments variables in function expressions
+**** Non-argument variables in function expressions
 
 Here we discuss rapidly of using variables (which are not arguments)
 in function expressions.
@@ -2210,7 +2210,7 @@ Running the example, one gets
 #+results: non-arg-variables-in-functions
 While the function itself is a constant object, one sees that since
 the value of ~a~ is changed, the value function is implicitly
-modified. /This is a dangerous feature and should be avoid!/
+modified. /This is a dangerous feature and should be avoided!/
 
 Since functions themselves are variables one can use functions in
 function expressions.
@@ -2287,7 +2287,7 @@ functions. They differ from user-defined functions in three points.
 - Builtin functions can have no parameter or no returned value.
 - Builtin functions are polymorphic. More precisely, this means that
   the signature of a builtin function is also defined by its expected
-  arguments types.
+  argument types.
 - Builtin functions can take user-defined functions as parameters.
   - user-defined functions cannot take functions as parameters
   - builtin functions cannot take builtin functions as parameters
@@ -2339,15 +2339,14 @@ One can access to the list of available modules inside the language.
 #+END_SRC
 The output lists all available modules
 #+RESULTS: get-available-modules
-Let us comment a bit this output. One notices that there are two kind
+Let us comment a bit this output. One notices that there are two kinds
 of modules. Modules that are automatically imported (tagged with a ~*~)
 and the other ones.
 
 In this section we will not describe exhaustively the whole module
-contents but will give the basic information that should allow the
-user to find his way. To do so, it is important to examine carefully
-the content of the ~core~ module, since it contains some helper
-functions.
+content but will give the basic information that should allow the user
+to find his way. To do so, it is important to examine carefully the
+content of the ~core~ module, since it contains some helper functions.
 
 *** The ~core~ module
 
@@ -2475,8 +2474,8 @@ Running this example gives
 
 ***** ~ofstream: string -> ostream~
 
-This function is used to create an ~ostream~ that actually write to the
-file which name is given by the ~string~ argument. One should notice
+This function is used to create an ~ostream~ that actually writes to the
+file whose name is given by the ~string~ argument. One should notice
 that the file is *created* at the function call. If a file with the same
 name existed, it is *erased*.
 #+NAME: ofstream-example
@@ -2566,7 +2565,7 @@ as ${(x^y)}^z$. Thus, using the ~pow~ function avoids any confusion.
 
 *** The ~mesh~ module
 
-This is an important module. It provides mesh utilities tools.
+This is an important module. It provides mesh utility tools.
 #+NAME: get-module-info-mesh
 #+BEGIN_SRC pugs :exports both :results output
   cout << getModuleInfo("mesh") << "\n";
@@ -2586,7 +2585,7 @@ A ~boundary~ can designate a set of nodes, edges or faces. The ~boundary~
 
 #+BEGIN_warning
 A ~boundary~ *cannot* be used to refer to an interface (/ie/ an inner set of
-items)..
+items).
 #+END_warning
 
 ***** ~zone~
@@ -2598,7 +2597,7 @@ precised when it is associated with a ~mesh~.
 ***** ~mesh~
 
 The type ~mesh~ is an *abstract* type that is used to store meshes. A
-variable of that type can refer for instance unstructured meshes of
+variable of that type can refer for instance to unstructured meshes of
 dimension 1, 2 or 3.
 
 The following binary operator is provided.
@@ -2634,7 +2633,7 @@ This type is used to designate kinds of items (cell, face, edge or node).
 
 The type ~item_value~ is an abstract type use to designate arrays of
 values defined on the entities of a ~mesh~. Actually, these values are
-not associated to the mesh itself but on the *connectivity*. The values
+not associated to the mesh itself but to the *connectivity*. The values
 on the entities can be of type ~B~, ~N~, ~Z~, ~R~, ~R^1~, ~R^2~, ~R^3~, ~R^1x1~, ~R^2x2~
 and ~R^3x3~. Entities themselves can be cells, faces, edges or nodes.
 
@@ -2645,17 +2644,16 @@ By now, no mathematical operation is defined on ~item_value~ variables.
 #+END_warning
 
 Moreover, ~item_value~ variables can be post processed. Observe that
-edges or faces values cannot be post processed since neither ~VTK~ nor
+edge or face values cannot be post processed since neither ~VTK~ nor
 ~Gnuplot~ can handle these data.
 
 ***** ~sub_item_value~
 
-This abstract type is handle values defined on the sub items of the
+This abstract type handles values defined on the sub items of the
 items of a ~mesh~. Similarly these values are attached to a *connectivity*
-and not to a mesh. Values can bed of type The values on the entities
-can be of type ~B~, ~N~, ~Z~, ~R~, ~R^1~, ~R^2~ or ~R^3~. An example of
-~sub_item_value~ is the $\mathbf{C}_{jr}$ vectors which are defined at each
-node of each cell.
+and not to a mesh. The values associated to the sub items can be of
+type ~B~, ~N~, ~Z~, ~R~, ~R^1~, ~R^2~ or ~R^3~. An example of ~sub_item_value~ is the
+$\mathbf{C}_{jr}$ vectors which are defined at each node of each cell.
 
 These variables are used to pass data from one function to
 another. They cannot be post processed.
@@ -2695,7 +2693,7 @@ Creates a zone descriptor from a ~string~ name
 
 ****** ~zoneTag: Z -> zone~
 
-Associates a zone descriptor from zone tag
+Associates a zone descriptor from a zone tag
 #+BEGIN_SRC pugs :exports both :results none
   import mesh;
 
@@ -2707,9 +2705,10 @@ Associates a zone descriptor from zone tag
 Creates a cartesian mesh of dimension $d\in\{1, 2, 3\}$. The produced
 cartesian grid is aligned with the axis and made of identical cells.
 
-The two first arguments are two opposite corners of the box (or
+The first two arguments are two opposite corners of the box (or of the
 segment in 1d) and the list of natural integers (type ~(N)~) sets the
-number of *cells* in each direction. Thus size of the list of ~N~ is $d$.
+number of *cells* in each direction. Thus the size of the list of ~N~ is
+$d$.
 
 For instance one can write:
 #+BEGIN_SRC pugs :exports both :results none
@@ -2866,8 +2865,8 @@ The ~mesh~ is represented in Figure [[fig:gmsh-hybrid-2d]].
 #+RESULTS: diamond-dual-img
 
 #+BEGIN_note
-The mesh storage mechanisms in ~pugs~ is such that the diamond dual mesh
-is built only once. This means that is one writes for instance
+The mesh storage mechanism in ~pugs~ is such that the diamond dual mesh
+is built only once. This means that if one writes for instance
 #+BEGIN_SRC pugs :exports both :results none
   import mesh;
 
@@ -2931,7 +2930,9 @@ available in parallel
 #+END_warning
 
 ***** Item types
-The following functions are used to refer to ~item_type~
+
+\\
+The following functions are used to designate a specific ~item_type~
 - ~cell: void -> item_type~
 - ~face: void -> item_type~
 - ~edge: void -> item_type~
@@ -2964,8 +2965,8 @@ In this example, we set three arrays defined at all nodes, all the
 This function allows to compute a new mesh as the transformation of a
 given mesh by displacing its nodes through a user defined function.
 
-For a mesh of dimension $d$, the mesh must be a function $\mathbb{R}^d
-\to\mathbb{R}^d$.
+For a mesh of dimension $d$, the transformation must be a function
+$\mathbb{R}^d \to\mathbb{R}^d$.
 
 #+BEGIN_SRC pugs :exports both :results none
 import mesh;
@@ -3067,10 +3068,10 @@ different meshes produced in this example are displayed in Figure
   unset ytics
   set square
   set terminal png truecolor enhanced size 640,640
-  plot '<(sed "" $PUGS_SOURCE_DIR/doc/relax_example_m0.gnu)' lt rgb "green" w l, '<(sed "" $PUGS_SOURCE_DIR/doc/relax_example_m1.gnu)' lt rgb "blue"  w l, '<(sed "" $PUGS_SOURCE_DIR/doc/relax_example_m2.gnu)' lt rgb "black" w l
+  plot '<(sed "" $PUGS_SOURCE_DIR/doc/relax_example_m0.gnu)' lt rgb "black" w l, '<(sed "" $PUGS_SOURCE_DIR/doc/relax_example_m1.gnu)' lt rgb "blue"  w l, '<(sed "" $PUGS_SOURCE_DIR/doc/relax_example_m2.gnu)' lw 2 lt rgb "red" w l
 #+END_SRC
 
-#+CAPTION: Example of meshes relaxation. The relaxed mesh $\mathcal{M}_2$ (black) and the original meshes in green ($\mathcal{M}_0$) and blue ($\mathcal{M}_1$).
+#+CAPTION: Example of meshes relaxation. The relaxed mesh $\mathcal{M}_2$ (red) and the original meshes in black ($\mathcal{M}_0$) and blue ($\mathcal{M}_1$).
 #+NAME: fig:relax
 #+ATTR_LATEX: :width 0.38\textwidth
 #+ATTR_HTML: :width 300px;
@@ -3373,7 +3374,7 @@ data.
 
 ****** ~interpolate: mesh*Vh_type*(function) -> Vh~
 
-This functions takes a ~mesh~, a type of discrete function (~Vh_type~) and
+This function takes a ~mesh~, a type of discrete function (~Vh_type~) and
 a list of user functions as arguments. It returns a $\mathbb{P}_0$
 function defined at the mesh.
 
@@ -3449,8 +3450,8 @@ dimension 3.
 ****** ~interpolate: mesh*(zone)*Vh_type*(function) -> Vh~
 
 This function works exactly the same as the previous function. The
-additional parameter, the ~zone~ lists is used to define the cells where
-the user function (or the user function list) is interpolate. For
+additional parameter, the ~zone~ list is used to define the cells where
+the user function (or the user function list) is interpolated. For
 cells that are not in the ~zone~ list, the discrete function is set to
 the value $0$.
 
@@ -3493,7 +3494,7 @@ dimension 3.
 ****** ~integrate: mesh*quadrature*function -> Vh~ <<integrate-classic>>
 
 This function integrates the given user function in each cell of a
-~mesh~ using a prescribed ~quadrature~. The result is of type as
+~mesh~ using a prescribed ~quadrature~. The result is of type
 $\mathbb{P}_0(\mathbb{R})$, $\mathbb{P}_0(\mathbb{R}^1)$,
 $\mathbb{P}_0(\mathbb{R}^2)$, $\mathbb{P}_0(\mathbb{R}^3)$,
 $\mathbb{P}_0(\mathbb{R}^{1\times1})$, $\mathbb{P}_0(\mathbb{R}^{2\times2})$
@@ -3653,9 +3654,9 @@ sets of cells where to integrate the list of user functions.
 
 For numerical tests purpose, it is often useful to create meshes with
 random vertices positions. This is the aim of the functions that are
-described in this section. These function share some properties.
-- The generate mesh is always suitable for calculations in the sense
-  that cells volumes are warrantied to be positive.
+described in this section. These functions share some properties.
+- The generated mesh is always suitable for calculations in the sense
+  that cell volumes are warrantied to be positive.
 - Generated cells can be non-convex.
 - One has to specify boundary conditions to drive the mesh
   displacement on boundaries.
@@ -3825,7 +3826,7 @@ made
 - of sets of edges, or
 - of sets of faces.
 
-In dimension 1, nodes, edges and faces denotes the same entities. In
+In dimension 1, nodes, edges and faces denote the same entities. In
 dimension 2, edges and faces refer the same entities.
 #+END_note
 
@@ -3850,7 +3851,7 @@ that the given boundary is actually *straight* or *planar*.
 ~pugs~ checks that boundaries do not contain /inner/ items.
 #+END_note
 
-We regroup the boundary condition descriptors functions according to
+We regroup the boundary condition descriptor functions according to
 their arguments
 ****** ~boundary -> boundary_condition~
 - ~axis: boundary -> boundary_condition~\\
@@ -4105,7 +4106,7 @@ The following constructions are allowed for ~*~ operator.
   \end{equation*}
 #+end_src
 Obviously, if $\mathbb{S}=\mathbb{R}^{d\times d}$, for $d\in\{1,2,3\}$,
-the right operand must be have a compatible type, for instance
+the right operand must have a compatible type, for instance
 $\mathbb{P}_0(\mathbb{R}^{d\times d})$ or $\mathbb{P}_0(\mathbb{R}^d)$.
 
 Additionally these operators are defined
@@ -4151,8 +4152,8 @@ An important function is
 
 ****** ~getLSAvailable: void -> string~
 
-This shows the available options or libraries that are available. It
-depends on the compilation options of the code.
+This shows the available options or libraries. It depends on the
+compilation options of the code.
 
 #+NAME: get-ls-available-example
 #+BEGIN_SRC pugs :exports both :results output
@@ -4232,7 +4233,7 @@ period for time-dependent post processing.
 
 ***** ~name_output: Vh*string -> output~
 
-This function give a name to a discrete function.
+This function gives a name to a discrete function.
 
 #+BEGIN_SRC pugs :exports both :results none
   import mesh;
@@ -4359,7 +4360,7 @@ of ~fh~.
 
 ***** ~name_output: item_value*string -> output~
 
-This function give a name to an ~item_value~.
+This function gives a name to an ~item_value~.
 
 #+BEGIN_SRC pugs :exports both :results none
   import mesh;
@@ -4395,14 +4396,14 @@ This function give a name to an ~item_value~.
 
 #+BEGIN_warning
 One observes that we supplied a mesh to the writer function. The
-reason for that is that ~item_value~ refers a connectivity. It requires
+reason for that is that ~item_value~ refers to a connectivity. It requires
 a ~mesh~ with the same connectivity to be written.
 
-However, is a discrete function (of type ~Vh~) build on the same
+However, if a discrete function (of type ~Vh~) build on the same
 connectivity is provided, there is no need to specify the ~mesh~.
 #+END_warning
 
-Let us illustrate it by an important second example.
+Let us give an example.
 
 #+BEGIN_SRC pugs :exports both :results none
   import mesh;
@@ -4456,8 +4457,8 @@ dimension 1 and 2 (~gnuplot_writer~).
 Both of these writers can be used for single output or time series
 outputs. In the case of single output, the filename is completed by
 adding the extension ~.gnu~, in the case of time series, the filename is
-extending by adding ~.abcd.gnu~, where ~abcd~ is the number of the output
-in the series.
+extending by adding ~.abcd.gnu~, where ~abcd~ is the number in the output
+series.
 
 #+BEGIN_note
 The ~gnuplot~ writers are implemented in parallel.
@@ -4487,7 +4488,7 @@ Here is an example of preamble of a produced ~gnuplot~ file.
 
 ****** ~gnuplot_1d_writer~ functions
 
-This writer family make only sense in 1d.
+This writer family makes only sense in 1d.
 
 #+BEGIN_note
 In parallel, as soon as the saved data themselves are the same, the
@@ -4613,8 +4614,8 @@ Running this example produces the following files
 #+END_SRC
 #+RESULTS: ls-produced-gp-1d-series
 
-Each of these file contains the numerical solution at following saving
-times:
+Each of these files contains the numerical solution at following
+saving times:
 #+NAME: times-in-gp-1d-series
 #+BEGIN_SRC shell :exports results :results output
   grep -n "# time = " gp_1d_exp_sin.*.gnu | cut -d '=' -f 2
@@ -4665,7 +4666,7 @@ Figure [[fig:writer-gp-sin]].
   plot '<(sed "" $PUGS_SOURCE_DIR/doc/gp_sin.gnu)' lw 2 w lp
 #+END_SRC
 
-#+CAPTION: Example of produced gnuplot results from the ~gnuplot_writer~. One can compare ths produced result to the one of the ~gnuplot_1d_writer~ given in Figure [[fig:writer-gp-1d-sin]]
+#+CAPTION: Example of produced gnuplot results from the ~gnuplot_writer~. One can compare the produced result to the one of the ~gnuplot_1d_writer~ given in Figure [[fig:writer-gp-1d-sin]]
 #+NAME: fig:writer-gp-sin
 #+ATTR_LATEX: :width 0.38\textwidth
 #+ATTR_HTML: :width 300px;
@@ -4722,7 +4723,7 @@ outputs.
 
 The used format is one file in the ~vtu~ format for each parallel domain
 (and eventually each time). The output is done using binary data for
-performance reasons. For each time step a ~pvtu~ file is generate to
+performance reasons. For each time step a ~pvtu~ file is generated to
 handle parallelism. And for a complete time series, a ~pvd~ file is
 produced. This is the file that should be loaded.
 
@@ -4755,9 +4756,9 @@ effectively generate the post processing files.
 
 ****** ~write: writer*(output) -> void~
 
-As parameters, it takes a ~writer~ that is not a time series one and a
-list of ~output~ (which are named discrete functions that are defined on
-the *same* mesh).
+As parameters, it takes a ~writer~ (that is not a time series writer)
+and a list of ~output~ (which are named discrete functions that are
+defined on the *same* mesh).
 
 We have already shown a lot of examples of use of the ~write~
 function. So let us focus on improper calls.