[Getfem-commits] (no subject)

[Tetsuo Koyama]

branch: fixmisspell
commit 41d588bbad1cf49018d7269c8a160c6972ef8040
Author: Tetsuo Koyama <address@hidden>
Date:   Sun Aug 25 17:08:17 2019 +0900

    Fix typo in docs
---
 doc/sphinx/source/gmm/iter.rst                                     | 2 +-
 doc/sphinx/source/userdoc/gasm_high.rst                            | 6 +++---
 doc/sphinx/source/userdoc/model_bilaplacian.rst                    | 2 +-
 doc/sphinx/source/userdoc/model_contact_friction.rst               | 4 ++--
 doc/sphinx/source/userdoc/model_contact_friction_large_sliding.rst | 2 +-
 doc/sphinx/source/whatsnew/1.7.rst                                 | 2 +-
 doc/sphinx/source/whatsnew/4.0.rst                                 | 2 +-
 doc/sphinx/source/whatsnew/4.2.rst                                 | 4 ++--
 doc/sphinx/source/whatsnew/4.3.rst                                 | 2 +-
 9 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/doc/sphinx/source/gmm/iter.rst b/doc/sphinx/source/gmm/iter.rst
index 67eabee..290d1d5 100644
--- a/doc/sphinx/source/gmm/iter.rst
+++ b/doc/sphinx/source/gmm/iter.rst
@@ -104,7 +104,7 @@ The following preconditioners, to be used with linear 
solvers, are available::
   gmm::ilutp_precond<matrix_type> P(SM, k, threshold);
 
 
-Except ``ildltt\_precond``, all these precontionners come from ITL. 
``ilut_precond`` has been optimized and simplified and ``cholesky_precond`` has 
been corrected and transformed in an incomplete LDLT preconditionner for 
stability reasons (similarly, we add ``choleskyt_precond`` which is in fact an 
incomplete LDLT with threshold preconditionner). Of course, ``ildlt\_precond`` 
and ``ildltt_precond`` are designed for symmetric real or hermitian complex 
matrices to be use principaly with cg.
+Except ``ildltt\_precond``, all these precontionners come from ITL. 
``ilut_precond`` has been optimized and simplified and ``cholesky_precond`` has 
been corrected and transformed in an incomplete LDLT preconditioner for 
stability reasons (similarly, we add ``choleskyt_precond`` which is in fact an 
incomplete LDLT with threshold preconditioner). Of course, ``ildlt\_precond`` 
and ``ildltt_precond`` are designed for symmetric real or hermitian complex 
matrices to be use principaly with cg.
 
 Additive Schwarz method
 -----------------------
diff --git a/doc/sphinx/source/userdoc/gasm_high.rst 
b/doc/sphinx/source/userdoc/gasm_high.rst
index 718ef78..39e82bf 100644
--- a/doc/sphinx/source/userdoc/gasm_high.rst
+++ b/doc/sphinx/source/userdoc/gasm_high.rst
@@ -70,7 +70,7 @@ A specific weak form language has been developed to describe 
the weak formulatio
 
   - ``Interpolate(variable, transformation)``: Powerful operation which allows 
to interpolate the variables, or test functions either on the same mesh on 
other elements or on another mesh. ``transformation`` is an object stored by 
the workspace or model object which describes the map from the current point to 
the point where to perform the interpolation. This functionality can be used 
for instance to prescribe periodic conditions or to compute mortar matrices for 
two finite element space [...]
 
-  - ``Elementary_transformation(variable, transformation)``: Allow a linear 
tranformation defined at the element level (i.e. not possible to define at the 
gauss point level). This feature has been added mostly for defining a reduction 
for plate elements (projection onto low-level vector element such as rotated 
RT0). ``transformation`` is an object stored by the workspace or model object 
which describes the trasformation for a particular element.
+  - ``Elementary_transformation(variable, transformation)``: Allow a linear 
transformation defined at the element level (i.e. not possible to define at the 
gauss point level). This feature has been added mostly for defining a reduction 
for plate elements (projection onto low-level vector element such as rotated 
RT0). ``transformation`` is an object stored by the workspace or model object 
which describes the trasformation for a particular element.
 
   - Possibility of integration on the direct product of two-domains for double 
integral computation or coupling of two variables with a Kernel / convolution / 
exchange integral. This allows terms like 
:math:`\displaystyle\int_{\Omega_1}\int_{\Omega_2}k(x,y)u(x)v(y)dydx` with 
:math:`\Omega_1` and :math:`\Omega_2` two domains, different or not, having 
their own meshes, integration methods and with :math:`u` a variable defined on 
:math:`\Omega_1` and :math:`v` a variable defined on :math:`\ [...]
 
@@ -654,7 +654,7 @@ The macros are expanded inline at the lexical analysis 
phase. Note that a the co
 
 Explicit Differentiation
 ------------------------
-The workspace object automatically differentiate terms that are of lower 
deriation order. However, it is also allowed to explicitely differentiate an 
expression with respect to a variable. One interest is that the automatic 
differentiation performs a derivative with respect to all the declared 
variables of model/workspace but this is not necessarily the expected behavior 
when using a potential energy, for instance. The syntax is::
+The workspace object automatically differentiate terms that are of lower 
deriation order. However, it is also allowed to explicitly differentiate an 
expression with respect to a variable. One interest is that the automatic 
differentiation performs a derivative with respect to all the declared 
variables of model/workspace but this is not necessarily the expected behavior 
when using a potential energy, for instance. The syntax is::
 
   Diff(expression, variable)
 
@@ -764,7 +764,7 @@ For instance, the assembly expression to prescribe the 
equality of a variable ``
 
 (see :file:`demo\_periodic\_laplacian.m` in :file:`interface/tests/matlab` 
directory).
 
-In some situations, the interpolation of a point may fail if the transformed 
point is outside the target mesh. Both in order to treat this case and to allow 
the transformation to differentiate some other cases (see 
:ref:`ud-model-contact-friction_raytrace_inter_trans` for the differentiation 
between rigid bodies and deformable ones in the 
Raytracing_interpolate_transformation) the tranformation returns an integer 
identifier to the weak form language. A value 0 of this identifier means th 
[...]
+In some situations, the interpolation of a point may fail if the transformed 
point is outside the target mesh. Both in order to treat this case and to allow 
the transformation to differentiate some other cases (see 
:ref:`ud-model-contact-friction_raytrace_inter_trans` for the differentiation 
between rigid bodies and deformable ones in the 
Raytracing_interpolate_transformation) the transformation returns an integer 
identifier to the weak form language. A value 0 of this identifier means t [...]
 
   Interpolate_filter(transname, expr, i)
 
diff --git a/doc/sphinx/source/userdoc/model_bilaplacian.rst 
b/doc/sphinx/source/userdoc/model_bilaplacian.rst
index e8128ce..d307530 100644
--- a/doc/sphinx/source/userdoc/model_bilaplacian.rst
+++ b/doc/sphinx/source/userdoc/model_bilaplacian.rst
@@ -67,7 +67,7 @@ And a Dirichlet condition on the normal derivative can be 
prescribed thanks to t
        R_must_be_derivated = false);
 
 These bricks add a Dirichlet condition on the normal derivative of the variable
-`varname` and on the mesh region `region` (which should be a boundary.
+`varname` and on the mesh region `region` (which should be a boundary).
 The general form is :math:`\int \partial_n u(x)v(x) = \int r(x)v(x) \forall v`
 where :math:`r(x)` is the right hand side for the Dirichlet condition (0 for
 homogeneous conditions) and :math:`v` is in a space of multipliers
diff --git a/doc/sphinx/source/userdoc/model_contact_friction.rst 
b/doc/sphinx/source/userdoc/model_contact_friction.rst
index eb83042..5360062 100644
--- a/doc/sphinx/source/userdoc/model_contact_friction.rst
+++ b/doc/sphinx/source/userdoc/model_contact_friction.rst
@@ -430,7 +430,7 @@ to `varname_u2`. `multname_n` should be a fixed size 
variable whose size
 is the number of degrees of freedom on those regions among the ones
 defined in `rg1` and `rg2` which are characterized as "slaves". It
 represents the contact equivalent nodal forces. The augmentation
-parameter `r` should be chosen in a range of acceptabe values (close to
+parameter `r` should be chosen in a range of acceptable values (close to
 the Young modulus of the elastic body, see Getfem user documentation).
 The optional parameters `slave1` and `slave2` declare if the regions
 defined in `rg1` and `rg2` are correspondingly considered as "slaves".
@@ -471,7 +471,7 @@ represents the contact equivalent nodal normal forces. 
`multname_t`
 should be a fixed size variable whose size corresponds to the size of
 `multname_n` multiplied by qdim - 1 . It represents the contact
 equivalent nodal tangent (frictional) forces. The augmentation parameter
-`r` should be chosen in a range of acceptabe values (close to the Young
+`r` should be chosen in a range of acceptable values (close to the Young
 modulus of the elastic body, see Getfem user documentation). The friction
 coefficient stored in the parameter `friction_coeff` is either a single
 value or a vector of the same size as `multname_n`. The optional
diff --git a/doc/sphinx/source/userdoc/model_contact_friction_large_sliding.rst 
b/doc/sphinx/source/userdoc/model_contact_friction_large_sliding.rst
index 170a6ba..ff67172 100644
--- a/doc/sphinx/source/userdoc/model_contact_friction_large_sliding.rst
+++ b/doc/sphinx/source/userdoc/model_contact_friction_large_sliding.rst
@@ -20,7 +20,7 @@ Of course, the computational cost of large sliding/large 
deformation contact alg
 Raytracing interpolate transformation
 *************************************
 
-In order to incorporate the contact detection in the high-level generic 
assembly, a specific interpolate transformation has been defined (see 
:ref:`ud-gasm-high-transf` for more explanations on interpolate 
tranformations). It is based on a raytracing contact detection has described in 
[KO-RE2014]_ and uses the criteria described below. The interpolate 
transformation stores the different potential contact surfaces. On most of 
methods, potential contact surface are classified into two cate [...]
+In order to incorporate the contact detection in the high-level generic 
assembly, a specific interpolate transformation has been defined (see 
:ref:`ud-gasm-high-transf` for more explanations on interpolate 
transformations). It is based on a raytracing contact detection has described 
in [KO-RE2014]_ and uses the criteria described below. The interpolate 
transformation stores the different potential contact surfaces. On most of 
methods, potential contact surface are classified into two cat [...]
 
 .. _ud-fig-masterslave:
 
diff --git a/doc/sphinx/source/whatsnew/1.7.rst 
b/doc/sphinx/source/whatsnew/1.7.rst
index 9376c38..970df55 100644
--- a/doc/sphinx/source/whatsnew/1.7.rst
+++ b/doc/sphinx/source/whatsnew/1.7.rst
@@ -34,7 +34,7 @@
 
    * Major changes in Gmm++ 1.7:
 
-     * New preconditionner ILUTP.
+     * New preconditioner ILUTP.
 
      * A BFGS algorithm has been developed.
 
diff --git a/doc/sphinx/source/whatsnew/4.0.rst 
b/doc/sphinx/source/whatsnew/4.0.rst
index e7383cb..b36d7f2 100644
--- a/doc/sphinx/source/whatsnew/4.0.rst
+++ b/doc/sphinx/source/whatsnew/4.0.rst
@@ -15,7 +15,7 @@ deprecated. The main changes are:
      possible to perform linear combination of degrees of freedom in
      order to describe some special finite element spaces. The main
      application is to obtain a finite element space reduced on a
-     boundary or a curve. But it can be used also to prescibe directly
+     boundary or a curve. But it can be used also to prescribe directly
      some matching condition. The main change in the use of the mesh_fem
      object is the introduction of "basic" and "reduced" dofs. See the
      documentation.
diff --git a/doc/sphinx/source/whatsnew/4.2.rst 
b/doc/sphinx/source/whatsnew/4.2.rst
index 21a5f12..df07304 100644
--- a/doc/sphinx/source/whatsnew/4.2.rst
+++ b/doc/sphinx/source/whatsnew/4.2.rst
@@ -13,7 +13,7 @@ The main changes are:
    * The license of |gf| has moved to LGPL 3 with GCC Runtime Exception
      allowing commercial codes to use Getfem.
 
-   * Contact/friction bricks has been extented to non-matching meshes and
+   * Contact/friction bricks has been extended to non-matching meshes and
      to integral contact condition with different augmentations (Alart Curnier,
      De Saxce projection, augmented multipliers) (work of Konstantinos Poulios
      and Yves Renard). A large sliding contact brick is in progress.
@@ -31,7 +31,7 @@ The main changes are:
    * The experimental mesher of Getfem is now (partially) interfaced with
      python/scilab/matlab.
 
-   * Some tools to verify the consistence (tangent term) of a brick or
+   * Some tools to verify the consistency (tangent term) of a brick or
      the whole model has been added.
 
    * Many bug fixes.
diff --git a/doc/sphinx/source/whatsnew/4.3.rst 
b/doc/sphinx/source/whatsnew/4.3.rst
index 9fa0d8b..8b8c476 100644
--- a/doc/sphinx/source/whatsnew/4.3.rst
+++ b/doc/sphinx/source/whatsnew/4.3.rst
@@ -25,7 +25,7 @@ The main changes are:
    * A support for Nitsche type method for Dirichlet and contact conditions.   
     the corresponding model bricks will certainly evolve to incorporate the
      use of the high-level generic assembly.
 
-   * A torus_mesh_fem object allowing to easily tranform 3D problems into
+   * A torus_mesh_fem object allowing to easily transform 3D problems into
      axi-symmetric ones (work of Lim Liang Jin).
 
    * New im_data objects to store and interpolate data on Gauss points