diff --git a/docs/CodingNorms.md b/docs/CodingNorms.md
index 4140c31e60fba267a798b99cef55d9ee6d153342..a41b3fa4cb14582179597fb9d351880a5773dc99 100644
--- a/docs/CodingNorms.md
+++ b/docs/CodingNorms.md
@@ -1,4 +1,4 @@
-# PHYEX developer documentation
+# PHYEX coding norms documentation
 
 ## ABOUT THIS DOCUMENT
 
@@ -9,7 +9,7 @@ This document is written using the markdown language. With pandoc, it can be con
 ## CODING NORMS
 
 ### Namelists
-We must be able to reproduce (binary comparison of the output files) the model results before and after code modifications. It means that every modification must be controled by a namelist key (with the exception of bug corrections).
+We must be able to reproduce (binary comparison of the output files) the model results before and after code modifications. It means that every modification must be controlled by a namelist key (with the exception of bug corrections).
 
 ### File names
 The fortran file names use a capital F letter (eg: foo.F90) except if working in a Meso-NH branch (mesonh\_\<commit\>) or in the folder (src/mesonh) specific to the Meso-NH model.
@@ -24,8 +24,8 @@ Names for the module:
 ### When using mode\_ or modi\_?
 When writing a new subroutine, should we put it in a module (in a mode\_ file) or should we write the subroutine in a file and write the interface bloc in another file (modi\_ file)?
 
-The answer depends on whether the routine is the 'main' routine of the parameterisation or not. If it is the 'main' routine, the interface bloc is declared apart, if not we can use a module.
-The idea behind is to break compilation dependency at the parameterisation level, and to isolate the interface declaration of the different routines that must be pluged in the hosting model.
+The answer depends on whether the routine is the 'main' routine of the parametrisation or not. If it is the 'main' routine, the interface bloc is declared apart, if not we can use a module.
+The idea behind is to break compilation dependency at the parametrisation level, and to isolate the interface declaration of the different routines that must be plugged in the hosting model.
 
 ### Norm
 Several constraints are imposed:
@@ -46,7 +46,7 @@ The variables are named according to the doctor norm:
 |Local         | I (not IS) | Z (not ZS) | G (not GS)  | Y (not YS, YP) | TZ               |
 |Loop control  | J (not JP) | -          | -           | -              | -                |
 
-Regarding array-syntax, code is written using array-syntax in the main branch and in mesonh specific branches based on the GPU branch, using array-syntax with mnh\_expand directives in the GPU branch, using DO loops in arome specific branches based on the GPU branch. If in doublt, check what is done in other routines in the brach you are working in.
+Regarding array-syntax, code is written using array-syntax in the main branch and in mesonh specific branches based on the GPU branch, using array-syntax with mnh\_expand directives in the GPU branch, using DO loops in arome specific branches based on the GPU branch. If in doubt, check what is done in other routines in the branch you are working in.
 Be carrefull when using the mnh\_expand directives, code must respect some constraints:
 
   - parenthesis after array variables are mandatory (no A=B+C, but A(:,:)=B(:,:)+C(:,:))
@@ -57,13 +57,13 @@ A tool (verify\_mnh\_expand.py) can help at checking the validity of the written
 
 For the GPU branch (and branches on GPU, including model specific branches):
 
-  - except variables declared with the PARAMETER attribute, no variable from modules can be used in the physics. Varaibles must be put in a type received by interface.
+  - except variables declared with the PARAMETER attribute, no variable from modules can be used in the physics. Variables must be put in a type received by interface.
   - subroutines or functions must not be called from within a loop on horizontal or vertical dimensions (see below for exception)
   - functions returning arrays must be rewritten as subroutine
 
 Call to external subroutine in loop on horizontal or vertical dimensions must be suppressed in the GPU version. If possible, the call must be put outside of the loop (acting on the full array as a whole) or the subroutine must be put in the CONTAINS part but, in this case, the included subroutine cannot use local array. There are 3 cases:
 
-  - the subroutine does't use local array: subroutine is put in an include file (with the .h extension) and included with the fortran INCLUDE statement.
+  - the subroutine doesn't use local array: subroutine is put in an include file (with the .h extension) and included with the fortran INCLUDE statement.
   - the subroutine use local arrays but it is called from only one place in the code: the source code of the subroutine is moved (no INCLUDE) in the CONTAINS part and the array declarations are moved in the main subroutine.
   - the subroutine use local arrays and is called from several places: the previous technique is not recommended. The source code is put in an include file (with the .h extension) and an extra argument is provided to the subroutine and is used as a buffer so there is no more need to declare local arrays in the called subroutine.
 
@@ -72,7 +72,7 @@ Call to external subroutine in loop on horizontal or vertical dimensions must be
 In Meso-NH, the budget can be used in two ways:
 
   - by giving to the budget machinery the tendency due to a given process
-  - by giving to the budget machinery the total tendency (S variable) before and after a given process. The budget machanism recomputes by difference the tendency only due to the given process.
+  - by giving to the budget machinery the total tendency (S variable) before and after a given process. The budget mechanism recomputes by difference the tendency only due to the given process.
 
 In AROME, we cannot provide the total tendency (S variable) before the process. This total tendency is stored internally by the machinery but cannot be set to a different value before doing a computation.
 
diff --git a/docs/Developer.md b/docs/Developer.md
index 2fe75f916e441441d84c08de93c0042096f55291..921825bec3f1476ffddf4c36073276ead256cee3 100644
--- a/docs/Developer.md
+++ b/docs/Developer.md
@@ -3,7 +3,7 @@
 ## ABOUT THIS DOCUMENT
 
 This document is intended for developers who want to contribute to the PHYEX package.
-Developer who is interested in plugging the physics in a new model can refere to the Plugging documentation.
+Developer who is interested in plugging the physics in a new model can refer to the Plugging documentation.
 The topics covered are as follows:
 
   - [Package organisation](#package-organisation)
@@ -18,13 +18,13 @@ This document is written using the markdown language. With pandoc, it can be con
 The package contains two kinds of branches:
 
   - generic branches which contain codes for all the models and applications (eg: main and GPU branches)
-  - model specific branches which are automaticaly derived from generic branches (eg: arome\_\<commit\_hash\>, mesonh\_\<commit\_hash\>)
+  - model specific branches which are automatically derived from generic branches (eg: arome\_\<commit\_hash\>, mesonh\_\<commit\_hash\>)
 
 The directories found in the package are different depending on the kind (generic or model specific) branches.
 
-For model specific branches, only the source code adapted for a given model is present (on directory per parameterization and an aux directory). No compilation engine or scripts are present in these branches. They are intended to be included directly in the compilation system of the hosting model.
+For model specific branches, only the source code adapted for a given model is present (on directory per parametrisation and an aux directory). No compilation engine or scripts are present in these branches. They are intended to be included directly in the compilation system of the hosting model.
 
-The generic branches contains the folowing directories:
+The generic branches contains the following directories:
 
   - docs: for documentation
   - build: an autonomous build system is included in the package. Its usage is covered in the [Offline documentation](./Offline.md)
@@ -43,11 +43,11 @@ Here is a short description of the different generic branches:
 
 The AROME build systems are evolving.
 Until cycle 49t1 (included), the physics source code is directly included in the source code tree.
-After cycle 49t1, the physics source code (as well as other model parts such as ectrans, fiat...) will be available through "boundles".
+After cycle 49t1, the physics source code (as well as other model parts such as ectrans, fiat...) will be available through "bundles".
 
 This evolution will impact the way to contribute to the PHYEX repository.
 
-But, whatever is the cycle, the AROME-HARMONIE developers only see codes comming from arome specific branches (branches named arome\_\<commit\_hash\>). This code is ready for inclusion (array-syntax already transformed into DO loops for instance).
+But, whatever is the cycle, the AROME-HARMONIE developers only see codes coming from arome specific branches (branches named arome\_\<commit\_hash\>). This code is ready for inclusion (array-syntax already transformed into DO loops for instance).
 
 Said differently, developers do not need to manipulate code transformation tools.
 
@@ -68,7 +68,7 @@ Workflow details (getting the source code in blue, pull request in red, integrat
 
 ## After cycle 49t1
 
-Workflow summary: after the cycle 49t1 (starting from 49t2?), HARMONIE/AROME will become a boudle. Il will be built with source codes coming from various places. One of these places will be the PHYEX repository. Pull requests must be send to each modified boundles.
+Workflow summary: after the cycle 49t1 (starting from 49t2?), HARMONIE/AROME will become a bundle. Il will be built with source codes coming from various places. One of these places will be the PHYEX repository. Pull requests must be send to each modified bundles.
 
 ![](./AROMEworkflow2.svg)
 
@@ -90,4 +90,4 @@ Pull requests concerning the physics continue to follow the same path as before
 
 ## CONTRIBUTION WORKFLOW FOR OTHER DEVELOPERS
 
-Other developers must work with source code comming directly from the GPU branch. They issue pull requests directly on this branch as usual with git repositories.
+Other developers must work with source code coming directly from the GPU branch. They issue pull requests directly on this branch as usual with git repositories.
diff --git a/docs/Integrator.md b/docs/Integrator.md
index 9faee4531b7b1f02442860adc873e58250c4237e..8210f137aa6f5c848b8648073d2dc477f474d55a 100644
--- a/docs/Integrator.md
+++ b/docs/Integrator.md
@@ -55,24 +55,23 @@ Integration details:
   - The Meso-NH integrator extracts, from the different pull requests, what concern the PHYEX repository and send a pull request on PHYEX based on a mesonh specific branch
   - The PHYEX administrator:
     - validates (see [below](#tests)) the contribution
-    - integrates the contribution in the arome branch and merges it in the GPU branch
+    - integrates the contribution in the mesonh branch and merges it in the GPU branch
     - regularly, he tags a new (minor) version of the GPU branch
-    - when asked by the IAL integrator, he builds a new arome specific branch (see [below](#code-preparation))
-    - when an arome specific branch is used in an official cycle, the arome specific branch is tagged accordingly
- puis teste les différents modèles et l'intègre dans la branche GPU (avec tag réguliers)
+    - when asked by the Meso-NH integrator, he builds a new mesonh specific branch (see [below](#code-preparation))
+    - when a mesonh specific branch is used in an official release, the mesonh specific branch is tagged accordingly
 
 ## NORMAL WORKFLOW FOR ANOTHER CONTRIBUTION
 
 Pull requests must be based on the GPU branch.
   - validates (see [below](#tests)) the contribution
-  - integrates the contribution in the arome branch and merges it in the GPU branch
+  - integrates the contribution in the GPU branch
   - regularly, he tags a new (minor) version of the GPU branch
 
 ## TESTS
 
 The source code must follow strict mnh\_expand directives (described in the [Coding Norms documentation](./CodingNorms.md)). The script verify\_mnh\_expand.py must be used to give an additional check.
 
-In addition to the scientific validation, the folowing tests must give the same results (with bit-reproducibility) in each of the model (arome, mesonh and testprogs):
+In addition to the scientific validation, the following tests must give the same results (with bit-reproducibility) in each of the model (arome, mesonh and testprogs):
 
   - compilation transforming the mnh\_expand directives in DO loop
   - compilation keeping the array-syntax
@@ -85,7 +84,7 @@ When possible, the new version of PHYEX must reproduce the old results (scientif
 The source code stored in the main and GPU branches must be usable by all the models. But these models can have contradictory constraints. To bypass this difficulty, the source code is preprocessed before being included in the compilation environment of each model.
 
 This preprocessing step can be done on the fly (in this case the preprocessing tools must be available aside of the compilation tools), or the result of the preprocessing can be stored in the PHYEX package (in this case, the preprocessing is done once and can be used by several users).
-This second possibility is usefull to historize the source code really used during the model compilation and enables contributions to the PHYEX package without the need of the preprocessing tools.
+This second possibility is useful to historize the source code really used during the model compilation and enables contributions to the PHYEX package without the need of the preprocessing tools.
 
 The preprocessed versions of the source code are put in branches named \<model\>\_\<commit\> where \<model\> is the name of the model for which the source code have been preprocessed and \<commit\> is the commit hash used as a basis.
 
diff --git a/docs/Offline.md b/docs/Offline.md
index 61f14b791610ba4a46174dec091b9d205288c723..e4f3ab77e0f5f0ca175fb5d85439a9d6a6412f19 100644
--- a/docs/Offline.md
+++ b/docs/Offline.md
@@ -16,7 +16,7 @@ This build system has two dependencies (installation is done automatically by th
   - [fiat](https://github.com/ecmwf-ifs/fiat)
 
 The script build/with\_fcm/make\_fcm.sh uses a configuration file and build the library and test programs.
-They can be found in the build/bin sudirectory in the architecture specific directory arch\_\<achitecture name\>.
+They can be found in the build/bin subdirectory in the architecture specific directory arch\_\<architecture name\>.
 
 Some more details can be found in [build/with\_fcm/README.md file](../build/with_fcm/README.md).
 
@@ -25,11 +25,11 @@ Some more details can be found in [build/with\_fcm/README.md file](../build/with
 ### Data generation
 
 The branch testprogs\_data contains modified source code for the AROME model to enable the generation of data samples.
-Using this branch, in the drivers of the different parameterisations (aro\_\* files), output can be enable for the AROME model.
+Using this branch, in the drivers of the different parametrisations (aro\_\* files), output can be enable for the AROME model.
 Running the AROME model with these modifications outputs files in the running directory.
 This must be done once by parametrisation (note that the check\_commit\_ial.sh script can be used to execute an AROME simulation).
 
-These files should be renamed with the folowing command:
+These files should be renamed with the following command:
 i=0; for file in ????_??_????????.dat; do mv $file `printf %08d $i`.dat; i=$((i+1)); done
 
 ### Usage directly with the testprogs executables
diff --git a/docs/PHYEX.md b/docs/PHYEX.md
index c0408ea211826179f747d12905588d33f7c5fc46..c209efd7140d1e1d1e0957dd709977969d7a068f 100644
--- a/docs/PHYEX.md
+++ b/docs/PHYEX.md
@@ -25,10 +25,10 @@ The last evolution was to extract the physics to build the independent PHYEX pac
 
 ## CONTENT
 
-The folowing paramerisations are included in the PHYEX package (see the MesoNH documentation for references):
+The following parametrisations are included in the PHYEX package (see the MesoNH documentation for references):
 
  - turbulence scheme
  - shallow convection scheme
  - microphysics schemes
 
-In addition to the parametrisatin source code, test programs and a library for python binding are also provided.
+In addition to the parametrisations source code, test programs and a library for python binding are also provided.
diff --git a/docs/Plugging.md b/docs/Plugging.md
index 79657aeb86730770741d1533ae429f711de16740..abd76b0d7f06d08dde0efe743130c578f961b2c1 100644
--- a/docs/Plugging.md
+++ b/docs/Plugging.md
@@ -2,7 +2,7 @@
 
 ## ABOUT THIS DOCUMENT
 
-The PHYEX parameterizations can be called from the Meso-NH and AROME models, from
+The PHYEX parametrisations can be called from the Meso-NH and AROME models, from
 test programs and from a driver.
 This document is intended for developers who want to plug in the physics in a new model or program.
 
diff --git a/docs/Tools.md b/docs/Tools.md
index 2f444c240dc243abc90e7b1c105f3e6d3335dcee..dd2232e9fb5c2a8ebbeb0814333a1c97348f3451 100644
--- a/docs/Tools.md
+++ b/docs/Tools.md
@@ -28,7 +28,7 @@ Before being usable, the AROME model must be installed following the [INSTALL\_p
 
 ### check\_commit\_mesonh.sh
 
-The check\_commit\_mesonhsh script compiles, runs a test case of the Meso-NH model and compares the results against a reference simulation.
+The check\_commit\_mesonh.sh script compiles, runs a test case of the Meso-NH model and compares the results against a reference simulation.
 
 Script options can be displayed with the -h option.
 
@@ -50,7 +50,7 @@ Script options can be displayed with the -h option.
 
 To be usable the check\_commit\_testprogs.sh script needs input data. The generation and installation of these data are described in the [INSTALL\_testprogs documentation](../tools/INSTALL_testprogs.md).
 
-The goal of the script is to compare outputs between two simulations (to check if bit-reproducibilty is achieved or not).
+The goal of the script is to compare outputs between two simulations (to check if bit-reproducibility is achieved or not).
 A reference simulation must be performed and save. This reference simulation is run the same way as the
 test experiment but cannot be compared to something else:
 check\_commit\_testprogs.sh -c -r <reference_commit>