Update Code Architecture and Organization authored by Alain O' Miniussi's avatar Alain O' Miniussi
......@@ -100,7 +100,7 @@ note top of DiskPhysic
Configuration of the disk
physical properties (viscosity, radiation etc..)
and behavior.
Caracteristics of the planetary system...
Characteristics of the planetary system...
end note
Simulation o--> Disk
......@@ -115,20 +115,19 @@ Disk *--> ScalarField: pressure\n soundSpeed\n density\n viscosity
Disk "1"*-->"1" VectorField
VectorField *--> ScalarField: radial\n phi\n theta
```
## The ScalarField object.
## 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**[^2] 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.
This object only store the data as a [std::valarray<double>](http://www.cplusplus.com/reference/valarray/)[^4] object field, but also export it as an old fashioned C pointer[^3].
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].
## 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.
The "almost" is important, as in the short term, it will allow close to trivial implementation of multi-grid decomposition by providing one instance by sub-domain.
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.
* **DiskPhysic** provide the physical parameter of the disk. It is close to a direct mapping of the user provided property tree.
* **SystemPhysic** paly a similar role for the planetary system.
* **SystemPhysic** play a similar role for the planetary system.
* **GridDispatch** is . It describe discretisation of the (possibly flat) cylinder containing the gas. That include the grid points, 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.
## Boundaries Conditions
......@@ -141,6 +140,6 @@ Boundaries condition are implemented through **BoundariesHandler** [function obj
-------
[^1]: In particular, the diagram does not detail the configuration aspects in details.
[^3]: Mostly for backward compatibility/laziness/lack of time.
[^4]: Intel has [special optimizations](https://software.intel.com/en-us/articles/using-improved-stdvalarray-with-intelr-c-compiler) for `std::valarray`, has not been tested yet.
[^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