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

@@ -5,7 +5,7 @@ The main purpose of a fargo3D simulation is to track the evolution of a planetar
 
 That simulation is driven by an instance of the **Simulation** class (currently implementing a simple [Command pattern](https://en.wikipedia.org/wiki/Command_pattern), but might evolve into a [Template Method](https://en.wikipedia.org/wiki/Template_method_pattern). It behave like a function object with perform one step of the simulation at each call.
 
-The simulation configuration is done through a property tree.
+From the user's perspective, the simulation is configured through a property tree from wich is extracted a description of the physic (stored in a **DiskPhysic** object) a grid (in **GridDispatch** and **GridCoords** objetct) and a set of tracker (stored in a set of **SimulationTrackers**) that will extract the information were interested in during the run.
 
 The main sequence diagram can be seen as follow:
 
@@ -115,11 +115,27 @@ Disk *--> ScalarField: pressure\n soundSpeed\n density\n viscosity
 Disk "1"*-->"1" VectorField
 VectorField *--> ScalarField: radial\n phi\n theta
 ```
-## The [ScalarField](https://disc.pages.oca.eu/fargOCA/public/doxy/classfargOCA_1_1ScalarField.html) objects.
+
+## 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 of the class **ClassName** is usually dispatched between a header file in *src/className.hpp* and a source file in *src/className.cpp*.
+
+Utilities are in the *utils* directory.
+
+## Main classes
+In order inportance, which is subjective.
+
+### The [ScalarField](https://disc.pages.oca.eu/fargOCA/public/doxy/classfargOCA_1_1ScalarField.html) objects.
 
 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 \equal 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].
 
+### [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)**.
+
 ## The disk description 
 
 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.
@@ -139,7 +155,8 @@ Boundaries condition are implemented through **BoundariesHandler** [function obj
   * The **SimulationDriver** object will then trigger them when required.
 
 ------- 
-[^1]: In particular, the diagram does not detail the configuration aspects in details.
+[^1]: In particular, the diagram does not detail the configuration aspects in details.[
+[^2]: Mostly Object Based actually, if you're into that kind of nuance.
 [^3]: Mostly for backward compatibility/laziness/lack of time. Should be used as a last resort.
 [^4]: Intel has [special optimizations](https://software.intel.com/en-us/articles/using-improved-stdvalarray-with-intelr-c-compiler) for `std::valarray` that our build system activate when available.
 [^5]: Also called "callback".
\ No newline at end of file