Next: 20.5 Unit Tests Up: 20. Gravity Unit Previous: 20.3 Self-gravity Contents Index
To include the effects of gravity in your FLASH executable, include the option
-with-unit=physics/Gravityon your command line when you configure the code with setup. The default implementation is Constant, which can be overridden by including the entire path to the specific implementation in the command line or Config file. The other available implementations are Gravity/GravityMain/Planepar, Gravity/GravityMain/Pointmass and Gravity/GravityMain/Poisson. The Gravity unit provides accessor functions to get gravitational acceleration and potential. However, none of the external field implementations of Section Sec:GravityExternal explicitly compute the potential, hence they inherit the null implementation from the API for accessing potential. The gravitation acceleration can be obtained either on the whole domain, a single block or a single row at a time.
When building an application that solves the Possion equation for the gravitational potential, additional storage is needed in unk for holding the last, as well as (usually) the previous, gravitational potential field; and, depending on the Poisson solver used, additional variables may be needed. The variables GPOT_VAR and GPOT_VAR, and others as needed, will be automatically defined in Flash.h in those cases. See Gravity_potentialListOfBlocks for more information.
Calculation of gravitational potential can be enabled by compiling in this unit and setting the runtime parameter useGravity true. The constant of gravity can be set independently by runtime parameter grv_bhNewton; if it is not positive, the constant Newton from the FLASH PhysicalConstants database is used. If parameters gr_bhPhysMACTW or gr_bhPhysMACComm are set, the gravity unit MAC is used and it can be chosen by setting grv_bhMAC to either ApproxPartialErr or MaxPartialErr. If the first one is used, the order of the multipole approximation is given by grv_bhMPDegree.
The maximum allowed partial error in gravitational acceleration is set with the runtime parameter grv_bhAccErr. It has either the meaning of an error in absolute acceleration or in relative acceleration normalized by the acceleration from the previous time-step. The latter is used if grv_bhUseRelAccErr is set to True, and in this case the first call of the tree solver calculates the potential using purely geometrical MAC (because the acceleration from the previous time-step does not exist).
Boundary conditions are set by the runtime parameter grav_boundary_type and they can be isolated, periodic or mixed. In the case of mixed boundary conditions, runtime parameters grav_boundary_type_x, grav_boundary_type_y and grav_boundary_type_z specify along which coordinate boundary conditions are periodic and isolated (possible values are periodic or isolated). Arbitrary combination of these values is permitted, thus suitable for problems with planar resp. linear symmetry. It should work for computational domain with arbitrary dimensions. The highest accuracy is reached with blocks of cubic physical dimensions.
If runtime parameter grav_boundary_type is periodic or
mixed, then the Ewald field for appropriate symmetry is calculated at
the beginning of the simulation. Parameter grv_bhEwaldSeriesN controls the range of indices
in (eq. 20.13). There are two implementations of the
Ewald method: the new one (default) requires less memory and it should be faster
and of comparable accuracy as the old one. The default implementation computes
Ewald field minus the singular 
term and its partial derivatives on a
single cubic grid, and the Ewald field is then approximated by the first order
Taylor formula. Parameter grv_bhEwaldNPer controls number of grid points
in the 
direction in the case of periodic or in periodic
direction(s) in the case of mixed boundary conditions. Since an
elongated computational domain is often desired when grav_boundary_type
is mixed, the cubic grid would lead to a huge field of data. In this
case, the amount of necessary grid points is reduced by using an analytical
estimate to the Ewald field sufficiently far away of the symmetry plane or axis.
The old implementation (from Flash4.2) is still present and is enabled
by adding
bhtreeEwaldV42=1 on the setup command line.
The Ewald field is then stored
in a nested set of grids, the first of them corresponds in size to full
computational domain, and each following grid is half the size (in each
direction) of the previous grid. Number of nested grids is controlled by
runtime parameter grv_bhEwaldNRefV42. If grv_bhEwaldNRefV42 is too low to
cover origin (where is the Ewald field discontinuous), then the run is terminated.
Each grid is composed of grv_bhEwaldFieldNxV42 
grv_bhEwaldFieldNyV42 grv_bhEwaldFieldNzV42 points.
When evaluation of the Ewald Field at particular point is
needed at any time during a run, the field value is found by interpolation in a suitable level of the grid. Linear or
semi-quadratic interpolation can be chosen by runtime parameter
grv_bhLinearInterpolOnlyV42 (option true corresponds to linear
interpolation). Semi-quadratic interpolation is recommended only in the case
when there are periodic boundary conditions in two directions.
The external gravitational field can be switched on by setting grv_useExternalPotential true. The parameter grv_bhExtrnPotFile gives the name of the file with the external potential and grv_bhExtrnPotType specifies the field symmetry: spherical for the spherical symmetry and planez for the planar symmetry with field being a function of the z-coordinate. Parameters grv_bhExtrnPotCenterY, grv_bhExtrnPotCenterX and grv_bhExtrnPotCenterZ specify the position (in the simulation coordinate system) of the external field origin (the point where the radial or z-coordinate is zero).
Tree gravity unit parameters controlling the external gravitational field.
