Fix the set of typos reported by Alexiane

doc/userdoc.org

@@ -56,7 +56,7 @@ of some [[https:github.com/kokkos/kokkos][Kokkos]] mechanisms.
 The philosophy of ~pugs~ is to provide "simple" numerical tools that are
 assembled together through a high-level language (a DSL[fn:DSL-def]
 close to the mathematics) to build more complex solvers. This approach
-is inspired by the success of [[http://freefem.org][FreeFEM]], which use a similar approach.
+is inspired by the success of [[http://freefem.org][FreeFEM]], which uses a similar approach.
 
 Before detailing the leading concepts and choices that we have made to
 develop ~pugs~, we give a simple example.
@@ -118,7 +118,7 @@ The example is quite easy to read.
   allow* the modifications of values of variables of *non-basic*
   types. This is discussed in the section [[high-level-types]].
 - Finally, the last block consists in saving the obtained mesh in a
-  ~gnuplot~ file. The result is shown on Figure [[fig:intro-example]].
+  ~gnuplot~ file. The result is shown in Figure [[fig:intro-example]].
 
 #+NAME: intro-transform-mesh-img
 #+BEGIN_SRC gnuplot :exports results :file (substitute-in-file-name "${PUGS_SOURCE_DIR}/doc/intro-transform-mesh.png")
@@ -144,10 +144,10 @@ already be discussed.
 - There is no predefined constant in ~pugs~. Here a value is provided
   for ~pi~.
 - There are two kinds of variable in ~pugs~: variables of basic types
-  and variable of high-level types. This two kinds of variable behave
+  and variables of high-level types. This two kinds of variable behave
   almost the same but one must know their differences to understand
   better the underlying mechanisms and choices that we made. See
-  section [[basic-types]] and [[high-level-types]] for details.
+  sections [[basic-types]] and [[high-level-types]] for details.
 - Also, there are two types of functions: *user-defined* functions and
   *builtin* functions. In this example, ~theta~, ~M~ and ~T~ are user-defined
   functions. All other functions (~cos~, ~cartesianMesh~,...) are
@@ -168,9 +168,9 @@ calculations,...
 
 *** A C++ toolbox driven by a user friendly language
 
-Numerical simulation packages are software of a particular
+Numerical simulation packages are softwares of a particular
 kind. Generally, in order to run a calculation, one has to define a
-set of data and parameters. This can simply be definition of a
+set of data and parameters. This can simply be the definition of a
 discretization parameter such as the mesh size. One can also specify
 boundary conditions, equations of state, source terms for a specific
 model. Choosing a numerical method or even more, setting the model
@@ -195,11 +195,11 @@ There are lots of reasons not to use data files. By data file, we
 refer to a set of options that describe physical models, numerical
 methods or their settings.
 
-- Data files are not flexible. This implies in then one hand that
+- Data files are not flexible. This implies in the one hand that
   application scenarios must be known somehow precisely to reflect
   possible option combinations and in the other hand even defining a
   specific initial data may require the creation of a new option and
-  the associated code (in ~C++~ for instance). \\
+  its associated code (in ~C++~ for instance). \\
   Usually, the last point is addressed by adding a local interpreter
   to evaluate user functions.
 - Data files may contain irrelevant information. Actually, it is quite
@@ -226,7 +226,7 @@ to write the code can be tempting. It has the advantage that no
 particular treatment is necessary to build a parser (to read data
 files or a script), but it presents several drawbacks.
 
-- The first one is probably that it allows to much freedom. While
+- The first one is probably that it allows too much freedom. While
   defining the model and numerical options, the user has generally
   access to the whole code and can change almost everything, even
   things that should not be changed.
@@ -238,7 +238,7 @@ files or a script), but it presents several drawbacks.
   coupled physics.
 - Another difficulty is related to the fact that code's internal API
   is likely to change permanently in a research code. Thus valid
-  constructions or setting may become rapidly obsolete.  In other
+  constructions or settings may become rapidly obsolete.  In other
   words keeping up to date embedded "data file" might be difficult.
 - Finally it requires recompilation of pieces of code (which can be
   large in some cases) even if one is just changing a simple
@@ -294,7 +294,7 @@ writing of new methods.
   *new functions in the language*. Moreover, if a new method is close to
   an existing one, it is generally *better* to use completely new
   underlying ~C++~ code than to patch existing methods. Starting from a
-  *copy* of the existing code ~C++~ is *encouraged* for developments. This
+  *copy* of the existing ~C++~ code is *encouraged* for developments. This
   may sound weird since classical development guidelines encourage
   inheritance or early redesign. Actually, this policy is the result
   of the following discussion.
@@ -306,7 +306,7 @@ writing of new methods.
     corrections.
   - It is much more difficult to introduce bugs in existing methods,
     since previously validated methods are unchanged!
-  - For the same reason, existing methods performances are naturally
+  - For the same reason, existing method performances are naturally
     unchanged by new developments.
   - Also, when comparing methods, it is better to compare to the
     original existing code.
@@ -338,7 +338,7 @@ writing of new methods.
 ***** Why not python or any other scripting language?
 
 As it was already pointed out above, general purpose languages offer
-to much freedom: it is not easy to protect data. For instance in the
+too much freedom: it is not easy to protect data. For instance in the
 ~pugs~ DSL, non basic variables are constant (see paragraph
 [[high-level-types]]). It is important since it prevents the user from
 modifying data in inconsistent ways. Also, one must keep in mind that
@@ -2775,7 +2775,7 @@ gmsh -2 hybrid-2d.geo -format msh2
   write_mesh(gnuplot_writer("hybrid-2d"),m);
 #+END_SRC
 
-The ~mesh~ is represented on Figure [[fig:gmsh-hybrid-2d]].
+The ~mesh~ is represented in Figure [[fig:gmsh-hybrid-2d]].
 
 #+NAME: gmsh-hybrid-2d-img
 #+BEGIN_SRC gnuplot :exports results :file (substitute-in-file-name "${PUGS_SOURCE_DIR}/doc/gmsh-hybrid-2d.png")
@@ -2810,7 +2810,7 @@ This function creates the diamond dual ~mesh~ of a primal ~mesh~.
 The diamond dual mesh is defined by joining the nodes of the faces to
 the center of the adjacent cells of the primal mesh.
 
-The ~mesh~ is represented on Figure [[fig:gmsh-hybrid-2d]].
+The ~mesh~ is represented in Figure [[fig:gmsh-hybrid-2d]].
 
 #+NAME: diamond-dual-img
 #+BEGIN_SRC gnuplot :exports results :file (substitute-in-file-name "${PUGS_SOURCE_DIR}/doc/diamond-dual.png")
@@ -2863,7 +2863,7 @@ This function creates the median dual ~mesh~ of a primal ~mesh~.
 The median dual mesh is defined by joining the centers of the faces to
 the centers of the adjacent cells of the primal mesh.
 
-The ~mesh~ is represented on Figure [[fig:gmsh-hybrid-2d]].
+The ~mesh~ is represented in Figure [[fig:gmsh-hybrid-2d]].
 
 #+NAME: median-dual-img
 #+BEGIN_SRC gnuplot :exports results :file (substitute-in-file-name "${PUGS_SOURCE_DIR}/doc/median-dual.png")
@@ -2924,7 +2924,7 @@ that in ~pugs~ internals, there is only one connectivity object for
 these two meshes.
 #+END_note
 
-The result of the previous script is given on Figure
+The result of the previous script is given in Figure
 [[fig:transformed]]. They all share the same connectivity in memory.
 
 #+NAME: transformed-img
@@ -2990,7 +2990,7 @@ write_mesh(gnuplot_writer("relax_example_m2"), m2);
 #+END_SRC
 
 In this example, the relaxation parameter is set to $\theta=0.3$.  The
-different meshes produced in this example are displayed on Figure
+different meshes produced in this example are displayed in Figure
 [[fig:relax]].
 
 #+NAME: relax-img
@@ -3538,7 +3538,7 @@ In this example, the ~mesh~ provided in the file ~zones-1d.msh~ is a 1d
 ~mesh~ of $]-1,1[$ made of $200$ cells that is partitioned into 3
 connected subdomains. The zones corresponding to these 3 subdomains
 are named ~LEFT~ for $]-1,-0.3[$, ~MIDDLE~ for $]-0.3, 0.3[$ and ~RIGHT~ for
-$]0.3,1[$. The result is displayed on Figure [[fig:zone-integrate-1d]]. In
+$]0.3,1[$. The result is displayed in Figure [[fig:zone-integrate-1d]]. In
 the ~MIDDLE~ region, cell values are set to 0.
 
 #+NAME: zone-integrate-1d-img
@@ -3632,7 +3632,7 @@ Let us consider a simple example
   write_mesh(gnuplot_writer("random-mesh"), m);
 #+END_SRC
 
-Running this script one gets the ~mesh~ displayed on Figure
+Running this script one gets the ~mesh~ displayed in Figure
 [[fig:random-mesh]]. To reduce the vertices displacement, one can use the
 ~relax~ function, see section [[relax-function]].
 
@@ -3692,7 +3692,7 @@ displacement is allowed for $x<2y$.
   write_mesh(gnuplot_writer("random-mesh-chi"), m);
 #+END_SRC
 
-Running this script one gets the ~mesh~ displayed on Figure
+Running this script one gets the ~mesh~ displayed in Figure
 [[fig:random-mesh-chi]].
 
 #+NAME: random-mesh-chi-img
@@ -4228,10 +4228,10 @@ Let us illustrate it by an important second example.
   write(gnuplot_writer("writer-example2-2"), output_list);
 #+END_SRC
 
-Running this code produces the gnuplot file displayed on Figure
+Running this code produces the gnuplot file displayed in Figure
 [[fig:writer-example2]]. One sees that ~f~ is the $\mathbb{P}_0(\mathbb{R})$
 function corresponding to the function $x \to x$ and not to the function
-$x -> |\cos(\pi x)|$. This later function is plotted on Figure
+$x -> |\cos(\pi x)|$. This later function is plotted in Figure
 [[fig:writer-example2-2]] since ~output_list~ is set with the updated value
 of ~fh~.
 
@@ -4491,7 +4491,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 on Figure [[fig:writer-gp-1d-sin]]
+#+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]]
 #+NAME: fig:writer-gp-sin
 #+ATTR_LATEX: :width 0.38\textwidth
 #+ATTR_HTML: :width 300px;