... | ... | @@ -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 |