[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Getfem-commits] (no subject)
|
From: |
Tetsuo Koyama |
|
Subject: |
[Getfem-commits] (no subject) |
|
Date: |
Fri, 4 Jan 2019 12:45:58 -0500 (EST) |
branch: fixmisspell
commit 1de979b80da6fd0d3b6490fab7b43e73ec23fd5e
Author: Tetsuo Koyama <address@hidden>
Date: Sat Jan 5 02:43:29 2019 +0900
Fix typo in docs
---
doc/sphinx/source/gmm/noverif.rst | 2 +-
doc/sphinx/source/project/libdesc_cont.rst | 2 +-
doc/sphinx/source/project/libdesc_dal.rst | 2 +-
doc/sphinx/source/project/libdesc_event.rst | 2 +-
doc/sphinx/source/project/libdesc_fem.rst | 2 +-
doc/sphinx/source/project/libdesc_interface.rst | 14 +++++++-------
doc/sphinx/source/project/libdesc_levelset.rst | 4 ++--
doc/sphinx/source/project/libdesc_low_gen_assemb.rst | 6 +++---
doc/sphinx/source/project/libdesc_model.rst | 2 +-
doc/sphinx/source/screenshots/shots.rst | 2 +-
doc/sphinx/source/tutorial/install.rst | 2 +-
doc/sphinx/source/tutorial/thermo_coupling.rst | 2 +-
doc/sphinx/source/userdoc/gasm_low.rst | 2 +-
doc/sphinx/source/userdoc/model_Nitsche.rst | 16 ++++++++--------
.../source/userdoc/model_plasticity_small_strain.rst | 2 +-
doc/sphinx/source/whatsnew/1.7.rst | 2 +-
doc/sphinx/source/whatsnew/4.2.rst | 4 ++--
17 files changed, 34 insertions(+), 34 deletions(-)
diff --git a/doc/sphinx/source/gmm/noverif.rst
b/doc/sphinx/source/gmm/noverif.rst
index ecc810c..49b5049 100644
--- a/doc/sphinx/source/gmm/noverif.rst
+++ b/doc/sphinx/source/gmm/noverif.rst
@@ -11,5 +11,5 @@ How to disable verifications
============================
-On some type of matrices such as ``gmm::dense_matrix`` some verification are
made on the range of indices. This could deteriorate the performance of your
code but is satisfactory in the developpment stage. You can disable these
verifications adding a ``-dNDEBUG`` to the compiler options.
+On some type of matrices such as ``gmm::dense_matrix`` some verification are
made on the range of indices. This could deteriorate the performance of your
code but is satisfactory in the development stage. You can disable these
verifications adding a ``-dNDEBUG`` to the compiler options.
diff --git a/doc/sphinx/source/project/libdesc_cont.rst
b/doc/sphinx/source/project/libdesc_cont.rst
index 90b61a2..1e62f32 100644
--- a/doc/sphinx/source/project/libdesc_cont.rst
+++ b/doc/sphinx/source/project/libdesc_cont.rst
@@ -34,5 +34,5 @@ Have already generic and advanced functionalities.
Perspectives
^^^^^^^^^^^^
-Still in developpement.
+Still in developement.
diff --git a/doc/sphinx/source/project/libdesc_dal.rst
b/doc/sphinx/source/project/libdesc_dal.rst
index 611dd58..088cd1e 100644
--- a/doc/sphinx/source/project/libdesc_dal.rst
+++ b/doc/sphinx/source/project/libdesc_dal.rst
@@ -19,7 +19,7 @@ not available and the containers defined in the ``dal``
namespace was used
everywhere. Now, in |gf|, the S.T.L. containers are mainly used. The remaining
uses of ``dal`` containers are eather historical or due to the specificities of
these containers. It is however clear that this is not the aim of the |gf|
-project to developp new container concept. So, the use of the ``dal``
containers
+project to develop new container concept. So, the use of the ``dal`` containers
has to be as much as possible reduced.
Furthermore, ``dal`` contains a certain number of basic algorithms to deal
with static stored objects (description of finite element methods, intermediary
structures for auxiliary computations ...).
diff --git a/doc/sphinx/source/project/libdesc_event.rst
b/doc/sphinx/source/project/libdesc_event.rst
index e978401..a889a53 100644
--- a/doc/sphinx/source/project/libdesc_event.rst
+++ b/doc/sphinx/source/project/libdesc_event.rst
@@ -13,7 +13,7 @@ Events management
Description
^^^^^^^^^^^
-The ``mesh``, |mf|, |mim| and |mo| description are linkedtogether in the sense
+The ``mesh``, |mf|, |mim| and |mo| description are linked together in the sense
that there is some dependencies between them. For instance, when an element is
suppressed to a mesh, the |mf| object has to react.
diff --git a/doc/sphinx/source/project/libdesc_fem.rst
b/doc/sphinx/source/project/libdesc_fem.rst
index 6326e64..51fe177 100644
--- a/doc/sphinx/source/project/libdesc_fem.rst
+++ b/doc/sphinx/source/project/libdesc_fem.rst
@@ -33,7 +33,7 @@ Files
:file:`getfem_fem.h` and :file:`getfem_fem.cc` and
:file:`getfem_fem_composite.cc`, "Descriptors for finite element and a degree
of freedom. Polynomial finite elements are defined in :file:`getfem_fem.cc` and
piecewise polynomial finite elements in :file:`getfem_fem_composite.cc`"
:file:`getfem_fem_global_function.h` and
:file:`getfem_fem_global_function.cc`, "Defines a fem with base functions
defined as global functions given by the user. Useful for enrichment with
singular functions and for implementation of meshless methods."
:file:`getfem_projected_fem.h` and :file:`getfem_projected_fem.cc`,
"Defines a fem which is the projection of a finite element space (represented
by a mesh_fem) on a different mesh. Note that the high-generic assembly
language offers also this functionality by means of the interpolated
transformations."
- :file:`getfem_interpolated_fem.h` and :file:`getfem_interpolated_fem.cc`,
"Dsfines a fem which is the interpolation of a finite element space
(represented by a mesh_fem) on a different mesh. Note that the high-generic
assembly language offers also this functionality by means of the interpolated
transformations."
+ :file:`getfem_interpolated_fem.h` and :file:`getfem_interpolated_fem.cc`,
"Dfines a fem which is the interpolation of a finite element space (represented
by a mesh_fem) on a different mesh. Note that the high-generic assembly
language offers also this functionality by means of the interpolated
transformations."
diff --git a/doc/sphinx/source/project/libdesc_interface.rst
b/doc/sphinx/source/project/libdesc_interface.rst
index de012ad..426366c 100644
--- a/doc/sphinx/source/project/libdesc_interface.rst
+++ b/doc/sphinx/source/project/libdesc_interface.rst
@@ -118,7 +118,7 @@ Objects, methods and functions of the interface
The main concepts manipulated by the interface are a limited number of objects
(Fem, Mesh, MeshFem, Model ...), the associated methods and some functions
defined on these objects.
-A special effort has been done to facilitate the addition of new objects,
methods and functions to the interface without doing it separetaly for each
partsupported script language (Python, Scilab, Matlab).
+A special effort has been done to facilitate the addition of new objects,
methods and functions to the interface without doing it separately for each
part supported script language (Python, Scilab, Matlab).
All the information needed to build the interface for the different objects,
methods and functions is contained in the files `interface/src/gf*.cc`. A
python script (`bin/extract_doc`) produces all the necessary files from the
information it takes there. In particular, it produces the python file
getfem.py, the matlab m-files for the different functions and objects
(including subdirectories) and it also produces the automatic documentations.
@@ -135,7 +135,7 @@ To make all the things work automatically, a certain number
of rules have to be
- :file:`gf_objectname_set.cc` : contains the methods which transform the
object (if any).
* A list of function is defined by only one file :file:`gf_commandname.cc`
- it contains a list of sub-comands.
+ it contains a list of sub-commands.
* For each file, the main commentary on the list of functions or methods is
delimited by the tags '/address@hidden' and '@*/'. For a file corresponding to
the constructors of an object, the commentary should correspond to the
description of the object.
@@ -168,7 +168,7 @@ To make all the things work automatically, a certain number
of rules have to be
``INIT``, ``GET``, ``SET``, ``RDATTR`` or ``FUNC``. The keyword
``INIT`` means that
this is the description of a constructor of an object. ``RDATTR`` is for
- a short method allowing to get an attribut of an object. ``GET`` is for a
+ a short method allowing to get an attribute of an object. ``GET`` is for a
method of an object which does not modify it. ``SET`` is for a method which
modifies an object and ``FUNC`` is for the sub-command of a function list.
@@ -177,7 +177,7 @@ To make all the things work automatically, a certain number
of rules have to be
The parameters of the method/function are described. For a method, the
object itself is not mentionned. The first parameter should be the method
- or sub-command name between single quotes (a speical case is when
+ or sub-command name between single quotes (a special case is when
this name begins with a dot; this means that it corresponds to a
method/function where the command name is not required).
@@ -202,7 +202,7 @@ To make all the things work automatically, a certain number
of rules have to be
Moreover, address@hidden refers to an object defined by the interface.
For instance, ou can refer to address@hidden, address@hidden,
address@hidden, etc.
- There are some authorized abreviations:
+ There are some authorized abbreviations:
- address@hidden for address@hidden
- address@hidden for address@hidden
@@ -220,7 +220,7 @@ To make all the things work automatically, a certain number
of rules have to be
Three dots at the end of the parameter list (``...``) mean that
additional parameters are possible. Optional parameters can be described
with brackets. For instance ``/address@hidden v = ('name'[, @int i])``. But
- be carreful how it is interpreted by the :file:`extract_doc` script
+ be careful how it is interpreted by the :file:`extract_doc` script
to build the python interface.
The second to fifth parameters of the macro correspond respectively to
@@ -302,7 +302,7 @@ where "name" is the name of the object in the interface and
``object_class`` is
IMPORTANT: In order to be interfaced, a |gf| object has to derive from
``dal::static_stored_object``. However, if it is not the case, a wrapper class
can be defined such as the one for ``bgeot::base_poly`` (see the end of
:file:`getfemint.h`).
-The previous three functions have to be implemented at the end of
:file:`getfemint.cc`.It is possible to use one of the two macros defined in
:file:`getfemint.cc`. The firs macro is for a standard object and the second
one for an object which is manipulated in |gf| with a shared pointer.
+The previous three functions have to be implemented at the end of
:file:`getfemint.cc`.It is possible to use one of the two macros defined in
:file:`getfemint.cc`. The first macro is for a standard object and the second
one for an object which is manipulated in |gf| with a shared pointer.
You have also to complete functions ``name_of_getfemint_class_id`` and
``class_id_of_object`` at the end of :file:`getfemint.cc`.
diff --git a/doc/sphinx/source/project/libdesc_levelset.rst
b/doc/sphinx/source/project/libdesc_levelset.rst
index d75150e..f7f7604 100644
--- a/doc/sphinx/source/project/libdesc_levelset.rst
+++ b/doc/sphinx/source/project/libdesc_levelset.rst
@@ -25,7 +25,7 @@ Files
:file:`getfem_mesh_level_set.h` and :file:`getfem_mesh_level_set.cc`, "Cut
a mesh with respect to one or several level-sets."
:file:`getfem_fem_level_set.h` and :file:`getfem_fem_level_set.cc`, "Define
a special finite element method which depends on the element and which is cut
by one or several level-sets."
:file:`getfem_mesh_fem_level_set.h` and
:file:`getfem_mesh_fem_level_set.cc`, "Produces a mesh_fem object with shape
functions cut by one or several level-sets."
- :file:`getfem_mesh_im_level_set.h` and :file:`getfem_mesh_im_level_set.cc`,
"Produce a mesh_im representing an intergation method cut by the level set and
being on on side of level-set, the oter side, both or only on the levelset
itself."
+ :file:`getfem_mesh_im_level_set.h` and :file:`getfem_mesh_im_level_set.cc`,
"Produce a mesh_im representing an intergration method cut by the level set and
being on on side of level-set, the oter side, both or only on the levelset
itself."
:file:`getfem_level_set_contact.h` and :file:`getfem_level_set_contact.cc`,
"A level set based large sliding contact algorithm for an easy analysis of
implant positioning."
:file:`getfem_convect.h`, "Compute the convection of a quantity with
respect to a vector field. Used to computate the evolution of a level-set
function for instance. Galerkin characteristic method."
@@ -39,5 +39,5 @@ Stable.
Perspectives
^^^^^^^^^^^^
-Clarify the alorithm computing the different zones.
+Clarify the algorithm computing the different zones.
diff --git a/doc/sphinx/source/project/libdesc_low_gen_assemb.rst
b/doc/sphinx/source/project/libdesc_low_gen_assemb.rst
index 43976ef..a1a2b19 100644
--- a/doc/sphinx/source/project/libdesc_low_gen_assemb.rst
+++ b/doc/sphinx/source/project/libdesc_low_gen_assemb.rst
@@ -23,10 +23,10 @@ Files
:header: "File(s)", "Description"
:widths: 8, 15
- :file:`getfem_mat_elem_type.h` and:file:` getfem_mat_elem_type.cc, "Defines
bes type for components of an elementary matrix."
+ :file:`getfem_mat_elem_type.h` and:file:` getfem_mat_elem_type.cc, "Defines
base type for components of an elementary matrix."
:file:`getfem_mat_elem.h` and:file:` getfem_mat_elem.cc, "Describes an
compute elementary matrices."
:file:`getfem_assembling_tensors.h`
and:file:`getfem_assembling_tensors.cc`, "Performs the assembly."
- :file:`getfem_assembling.h`, "Various assembly terms (linear elasticity,
generix elliptic term, Dirichlet condition ..."
+ :file:`getfem_assembling.h`, "Various assembly terms (linear elasticity,
generic elliptic term, Dirichlet condition ..."
State
^^^^^
@@ -36,4 +36,4 @@ Stable.
Perspectives
^^^^^^^^^^^^
-Will not evolve since the efforts are now focused on the high-level generic
assembly.
\ No newline at end of file
+Will not evolve since the efforts are now focused on the high-level generic
assembly.
diff --git a/doc/sphinx/source/project/libdesc_model.rst
b/doc/sphinx/source/project/libdesc_model.rst
index b28b43d..b0e3e24 100644
--- a/doc/sphinx/source/project/libdesc_model.rst
+++ b/doc/sphinx/source/project/libdesc_model.rst
@@ -42,4 +42,4 @@ Constant evolution to includes nex models.
Perspectives
^^^^^^^^^^^^
-More plate, road and shell bricks, plasticity in large deformation, ...
\ No newline at end of file
+More plate, load and shell bricks, plasticity in large deformation, ...
diff --git a/doc/sphinx/source/screenshots/shots.rst
b/doc/sphinx/source/screenshots/shots.rst
index 611db87..33d365c 100644
--- a/doc/sphinx/source/screenshots/shots.rst
+++ b/doc/sphinx/source/screenshots/shots.rst
@@ -196,7 +196,7 @@ images correspond to a 3D case.
3D planetary gears
------------------
-This image comes from the application developped by Konstantinos Poulios
+This image comes from the application developed by Konstantinos Poulios
which is freely available at |link23|_. It is based on |gf| and is intended to
be a tool for easy, almost automatic, creation and calculation of gear
transmissions.
diff --git a/doc/sphinx/source/tutorial/install.rst
b/doc/sphinx/source/tutorial/install.rst
index 65d58a9..a3bbca0 100644
--- a/doc/sphinx/source/tutorial/install.rst
+++ b/doc/sphinx/source/tutorial/install.rst
@@ -9,7 +9,7 @@
How to install
==============
-Since |gf| is developped on linux (Ubuntu), the installation is simpler on
linux, especially on Debian-based distributions (Debian/Ubuntu/Mint). However,
|gf| can be installed also on other linux distributions, on Mac os X and
Windows. In order to compile |gf| from sources, you need a recent C++ complier
(supporting C++ 11 standard) and a recent version of python 2.
+Since |gf| is developed on linux (Ubuntu), the installation is simpler on
linux, especially on Debian-based distributions (Debian/Ubuntu/Mint). However,
|gf| can be installed also on other linux distributions, on Mac os X and
Windows. In order to compile |gf| from sources, you need a recent C++ complier
(supporting C++ 11 standard) and a recent version of python 2.
The main dependences of |Gf| on other libraries are
diff --git a/doc/sphinx/source/tutorial/thermo_coupling.rst
b/doc/sphinx/source/tutorial/thermo_coupling.rst
index 29ae155..df5c9ab 100644
--- a/doc/sphinx/source/tutorial/thermo_coupling.rst
+++ b/doc/sphinx/source/tutorial/thermo_coupling.rst
@@ -115,7 +115,7 @@ Let us now make a detailed presentation of the use of |gf|
to approximate the pr
Initialization
**************
-First, in C++, ones has to include a certain number of headers for the model
object, the generic assembly, the linear interface (Gmm++), the experimental
mesher and the export facilities. For Python, this is simpler, |gf| can be
imported globally (numpy has also to be imported). For Scilab, the library has
first to be loaded in the Scilab console (this is not described here) and for
Matlab, nothing is necessary, except a `gf_workspace('clear all')` which allows
to clear all |gf| variables.
+First, in C++, ones has to include a certain number of headers for the model
object, the generic assembly, the linear algebra interface (Gmm++), the
experimental mesher and the export facilities. For Python, this is simpler,
|gf| can be imported globally (numpy has also to be imported). For Scilab, the
library has first to be loaded in the Scilab console (this is not described
here) and for Matlab, nothing is necessary, except a `gf_workspace('clear
all')` which allows to clear all |gf| [...]
========== ================================================
diff --git a/doc/sphinx/source/userdoc/gasm_low.rst
b/doc/sphinx/source/userdoc/gasm_low.rst
index 3cb475a..8e0c35a 100644
--- a/doc/sphinx/source/userdoc/gasm_low.rst
+++ b/doc/sphinx/source/userdoc/gasm_low.rst
@@ -11,7 +11,7 @@
Compute arbitrary terms - low-level generic assembly procedures
===============================================================
-This section present the first version of generic assembly procedure which has
been implemented in |gf|. It allows to easily make the assembly of arbitrary
matrices in the linear case. In the nonlinear case, some special
"non_linear_term" object have to be implemented, which could be a bit tricky
and obliges to use very low-level internal tools of |gf|. The high-level
generic assembly has been developped to circumvent these difficulties (see
:ref:`ud-gasm-high`).
+This section present the first version of generic assembly procedure which has
been implemented in |gf|. It allows to easily make the assembly of arbitrary
matrices in the linear case. In the nonlinear case, some special
"non_linear_term" object have to be implemented, which could be a bit tricky
and obliges to use very low-level internal tools of |gf|. The high-level
generic assembly has been developed to circumvent these difficulties (see
:ref:`ud-gasm-high`).
As it can be seen in the file :file:`getfem/getfem_assembling.h`, all the
previous assembly procedures use a |gf_gasm| object and provide it an adequate
diff --git a/doc/sphinx/source/userdoc/model_Nitsche.rst
b/doc/sphinx/source/userdoc/model_Nitsche.rst
index e5c2039..7575ca5 100644
--- a/doc/sphinx/source/userdoc/model_Nitsche.rst
+++ b/doc/sphinx/source/userdoc/model_Nitsche.rst
@@ -89,9 +89,9 @@ described on a fem; scalar or vector valued, depending on the
variable
on which the Dirichlet condition is prescribed. `gamma0name` is the
Nitsche's method parameter. `theta` is a scalar value which can be
positive or negative. `theta = 1` corresponds to the standard symmetric
-method which is conditionnaly coercive for `gamma0` small.
+method which is conditionally coercive for `gamma0` small.
`theta = -1` corresponds to the skew-symmetric method which is
-inconditionnaly coercive. `theta = 0` is the simplest method
+inconditionally coercive. `theta = 0` is the simplest method
for which the second derivative of the Neumann term is not necessary
even for nonlinear problems. Returns the brick index in the model.
::
@@ -117,9 +117,9 @@ right hand side of the Dirichlet condition. It could be
constant or
described on a fem. `gamma0name` is the
Nitsche's method parameter. `theta` is a scalar value which can be
positive or negative. `theta = 1` corresponds to the standard symmetric
-method which is conditionnaly coercive for `gamma0` small.
+method which is conditionally coercive for `gamma0` small.
`theta = -1` corresponds to the skew-symmetric method which is
-inconditionnaly coercive. `theta = 0` is the simplest method
+inconditionally coercive. `theta = 0` is the simplest method
for which the second derivative of the Neumann term is not necessary
even for nonlinear problems. Returns the brick index in the model.
(This brick is not fully tested)
@@ -149,9 +149,9 @@ right hand side of the Dirichlet condition. It could be
constant or
described on a fem. `gamma0name` is the
Nitsche's method parameter. `theta` is a scalar value which can be
positive or negative. `theta = 1` corresponds to the standard symmetric
-method which is conditionnaly coercive for `gamma0` small.
+method which is conditionally coercive for `gamma0` small.
`theta = -1` corresponds to the skew-symmetric method which is
-inconditionnaly coercive. `theta = 0` is the simplest method
+inconditionally coercive. `theta = 0` is the simplest method
for which the second derivative of the Neumann term is not necessary
even for nonlinear problems. `Hname` is the data
corresponding to the matrix field `H`. It has to be a constant matrix
@@ -201,9 +201,9 @@ the obstacle (interpolated on a finite element method).
`gamma0name` is the Nitsche's method parameter.
`theta` is a scalar value which can be
positive or negative. `theta = 1` corresponds to the standard symmetric
-method which is conditionnaly coercive for `gamma0` small.
+method which is conditionally coercive for `gamma0` small.
`theta = -1` corresponds to the skew-symmetric method which is
-inconditionnaly coercive. `theta = 0` is the simplest method
+inconditionally coercive. `theta = 0` is the simplest method
for which the second derivative of the Neumann term is not necessary.
The optional parameter `dataexpr_friction_coeff` is the friction
coefficient which could be any expression of the weak form language.
diff --git a/doc/sphinx/source/userdoc/model_plasticity_small_strain.rst
b/doc/sphinx/source/userdoc/model_plasticity_small_strain.rst
index 72a6608..fb21127 100644
--- a/doc/sphinx/source/userdoc/model_plasticity_small_strain.rst
+++ b/doc/sphinx/source/userdoc/model_plasticity_small_strain.rst
@@ -142,7 +142,7 @@ with :math:`\eta_n, \zeta_{n}` the right hand side of
equations :eq:`thetascheme
This means in particular that :math:`(\varepsilon^p_{n+1}, \alpha_{n+1}) =
({\mathscr E}^p(u_{n+1}, \zeta_n, \eta_n), {\mathscr A}(u_{n+1}, \zeta_{n},
\eta_n))` is the solution to equations :eq:`thetascheme1` and
:eq:`thetascheme2`. Both these maps and their tangent moduli (usually called
consistent tangent moduli) are then used in the global solve of the problem
with a Newton method and for :math:`u_{n+1}` the unique remaining variable. The
advantage of the return mapping strategy is t [...]
-In |gf| we propose both the return mapping strategy and also an alternative
strategy developped below which is mainly inspired from [PO-NI2016]_,
[SE-PO-WO2015]_ and [HA-WO2009]_ and allow more simple tangent moduli. It
consists in keeping (a multiple of) :math:`\gamma_{n+1}` as an additional
unknown with respect to :math:`u_{n+1}`. As we will see, this will allow a more
generic treatment of the yield functions, the price for the simplicity being
this additional unknown scalar field.
+In |gf| we propose both the return mapping strategy and also an alternative
strategy developed below which is mainly inspired from [PO-NI2016]_,
[SE-PO-WO2015]_ and [HA-WO2009]_ and allow more simple tangent moduli. It
consists in keeping (a multiple of) :math:`\gamma_{n+1}` as an additional
unknown with respect to :math:`u_{n+1}`. As we will see, this will allow a more
generic treatment of the yield functions, the price for the simplicity being
this additional unknown scalar field.
First, we consider an additional (and optional) given function
:math:`\alpha(\sigma_{n+1}, A_{n+1}) > 0` whose interest will appear later on
(it will allow simple local inverses) and the new unknown scalar field
diff --git a/doc/sphinx/source/whatsnew/1.7.rst
b/doc/sphinx/source/whatsnew/1.7.rst
index 5c03fe7..111d253 100644
--- a/doc/sphinx/source/whatsnew/1.7.rst
+++ b/doc/sphinx/source/whatsnew/1.7.rst
@@ -36,7 +36,7 @@
* New preconditionner ILUTP.
- * A BFGS algorithm has been developped.
+ * A BFGS algorithm has been developed.
* Gmm++ now handles (valid) operations mixing complex and
scalars.
diff --git a/doc/sphinx/source/whatsnew/4.2.rst
b/doc/sphinx/source/whatsnew/4.2.rst
index 5b2d9bc..0a4fc47 100644
--- a/doc/sphinx/source/whatsnew/4.2.rst
+++ b/doc/sphinx/source/whatsnew/4.2.rst
@@ -4,7 +4,7 @@
What's New in |gf| 4.2
************************
-The New brick system is now mature and several coupling bricks has been
developped.
+The New brick system is now mature and several coupling bricks has been
developed.
Released version, 2012/08/02.
@@ -20,7 +20,7 @@ The main changes are:
* A complete tool to perform continuation of the solution to a model with
respect to one of its parameter and to detect bifurcation has been
- developped by Tomas Ligursky.
+ developed by Tomas Ligursky.
* Some additional model bricks : pointwise constraint brick (to prescribe
a constraint on a point eventually inside an element), basic nonlinear