Developer's-corner/Code-Architecture-and-Organization.md

@@ -125,7 +125,7 @@ SimulationTracker o--> Simulation
 
 ## Source code organization
 
-The code is mostly an Objet Oriented[^2] library. Two two small programs, *fargoInit* (in [mainInit.cpp](https://gitlab.oca.eu/DISC/fargOCA/-/blob/master/mainInit.cpp)) and *fargOCA* (in [mainOCA.cpp](https://gitlab.oca.eu/DISC/fargOCA/-/blob/master/mainOCA.cpp)), are provided to initialize the simulation and to run it, respectivelly.
+The code is mostly an Objet Oriented[^2] library. Two small programs, *fargoInit* (in [mainInit.cpp](https://gitlab.oca.eu/DISC/fargOCA/-/blob/master/mainInit.cpp)) and *fargOCA* (in [mainOCA.cpp](https://gitlab.oca.eu/DISC/fargOCA/-/blob/master/mainOCA.cpp)), are provided to initialize the simulation and to run it, respectivelly.
 
 The code of the class **ClassName** is usually dispatched between a header file in *include/className.hpp* and a source file in *src/className.cpp*.
 
@@ -137,19 +137,19 @@ In order importance, which is subjective.
 ### [ScalarField](https://disc.pages.oca.eu/fargOCA/public/doxy/classfargOCA_1_1ScalarField.html)
 
 The most part of the program is spent manipulating **ScalarField** instances. A scalar field is basically a 3D field of continuous floating point data organized on a grid with as `[nr radial][ni layer][ns sector]` (if we use $`nr*ni*ns`$ grids) dispatched other an MPI communicator. 2D fields are just flat 3D fields ($`ni == 1`$).
-This object store the data as a [std::valarray<double>](http://www.cplusplus.com/reference/valarray/) object field, but also export it as an old fashioned C pointer[^3].
+This object stores the data as a [std::valarray<double>](http://www.cplusplus.com/reference/valarray/) object field, but also exports it as an old fashioned C pointer[^3].
 
 **ScalarField** are use to represent any kind of gas properties like density, energy, temperature etc..
 
 ### [VectorField](https://disc.pages.oca.eu/fargOCA/public/doxy/classfargOCA_1_1VectorField.html)
 
-Used to represent think la velocities, they are mostly a triplet of **[ScalarField](#scalarfield)**.
+Used to represent things like velocities, they are mostly a triplet of **[ScalarField](#scalarfield)**.
 
 ### [Disk](https://disc.pages.oca.eu/fargOCA/public/doxy/classfargOCA_1_1Disk.html)
 
-A **Disk** object represent the state of the system. It keep track of the gas state through a set of **ScalarField**s representing the density, energy, temperature, velocity etc... of the gas. 
+A **Disk** object represents the state of the system. It keeps track of the gas state through a set of **ScalarField**s representing the density, energy, temperature, velocity etc... of the gas. 
 
-Part of this description is optional and will only exists if required by the physic considered in a given simulation.
+Part of this description is optional and will only exist if required by the physics considered in a given simulation.
 
 ### [PlanetarySystem](https://disc.pages.oca.eu/fargOCA/public/doxy/classfargOCA_1_1PlanetarySystem.html)
 
@@ -157,28 +157,28 @@ Mostly a set of named planets with position, velocity, mass state.
 
 ### [DiskPhysic](https://disc.pages.oca.eu/fargOCA/public/doxy/structfargOCA_1_1DiskPhysic.html)
 
-This is a read only object representing the physical characteristic of the simulation. There is typically only one instance in the whole program (since all the actors are considering the same physic... for now). 
-It mimic quite closely the configuration file provided by the user. 
+This is a read only object representing the physical characteristics of the simulation. There is typically only one instance in the whole program (since all the actors are considering the same physics... for now). 
+It mimics quite closely the configuration file provided by the user. 
 
-To check that the radiative part of the physic has been requested, we will use a piece of code like (note that as radiative is a special case of adiabatic, we fist check that adiabatic physic is also requested):
+As an example, to check that the radiative part of the physics has been requested, we will use a piece of code like (note that as radiative is a special case of adiabatic, we fist check that adiabatic physic is also requested):
 ```
   if (physic().adiabatic && physic().adiabatic->radiative) {
     if (physic().adiabatic->radiative->opacityLaw == OL_CONSTANT) {
-      ... do what need to be done  
+      ... do what needs to be done  
     }  
   } 
 ```
 
 ### [Simulation](https://disc.pages.oca.eu/fargOCA/public/doxy/classfargOCA_1_1Simulation.html)
 
-This is the "engine" of the simulation. It know how to perform a single step of the simulation, each step will be splitted into substeps (`velocityStep`, `adiabaticStep` etc..) called in the right order. That's the entry point to the simulation processing.
+This is the "engine" of the simulation. It knows how to perform a single step of the simulation, each step will be splitted into substeps (`velocityStep`, `adiabaticStep` etc..) called in the right order. That's the entry point to the simulation processing.
 
-The disk geometry and physic configuration are described through a set of classes that are almost (almost) a [Singleton](https://en.wikipedia.org/wiki/Singleton_pattern) (because we do not need many of them). All object that need to have access to those information do so by referencing the appropriate instances.
+The disk geometry and physics configuration are described through a set of classes that are almost (almost) a [Singleton](https://en.wikipedia.org/wiki/Singleton_pattern) (because we do not need many of them). All objects that need to have access to those pieces of information do so by referencing the appropriate instances.
 
 The "almost" is important, as in the mid/long term, it will allow close to trivial implementation of multi-grid decomposition by providing one instance by sub-domain.
 
 ### [GridDispatch](https://disc.pages.oca.eu/fargOCA/public/doxy/classfargOCA_1_1GridDispatch.html) 
-It describe the discretisation of the (possibly flat) cylinder containing the gas. That include the grid points (stored in **GridCoords**) aperture, etc.. and some useful pre computed values. More than one **GridDispatch** object exist when the grid resolution is modified and a polar grid need to be re-mapped.
+It describes the discretisation of the (possibly flat) cylinder containing the gas. That includes the grid points (stored in **GridCoords**) aperture, etc.. and some useful pre computed values. More than one **GridDispatch** object exists when the grid resolution is modified and a polar grid needs to be re-mapped.
 
 ### [GridCoords](https://disc.pages.oca.eu/fargOCA/public/doxy/classfargOCA_1_1GridCoords.html)
 
@@ -186,16 +186,16 @@ The grid coordinates.
 
 ### [SimulationTracker](https://disc.pages.oca.eu/fargOCA/public/doxy/classfargOCA_1_1SimulationTracker.html)
 
-The [Simulation](#simulation) object job is to keep the simulation running. But the user probably want to collect some information along the way. In order to keep both issues separated, all information will be collected through **SimulationTracker**s. 
+The [Simulation](#simulation) object's job is to keep the simulation running. But the user probably wants to collect some information along the way. In order to keep both issues separated, all information will be collected through **SimulationTracker**s. 
 
 Simulation trackers have a [section on their own](Developer's-corner/Simulation Trackers) in the developer's corner.
 
-## Boundaries Conditions
+## Boundary Conditions
 
-Boundaries condition are implemented through **BoundariesHandler** [function objects](https://en.wikipedia.org/wiki/Command_pattern)[^5]. 
+Boundary conditions are implemented through **BoundariesHandler** [function objects](https://en.wikipedia.org/wiki/Command_pattern)[^5]. 
   * All available handlers are registered by name in the application (user can add their own). 
-  * In the configuration file, the user indicate the names of the requested handler. 
-  * The application then bind those handler to the **GasDisk** object.
+  * In the configuration file, the user indicates the names of the requested handler. 
+  * The application then binds those handler to the **GasDisk** object.
   * The **SimulationDriver** object will then trigger them when required.
 
 -------