Abstract
This thorn implements the radiative boundary condition originally introduced by the BSSN_MoL thorn.
This thorn provides routines to implement radiative boundary conditions as described in section VI of [1]:
(1) |
in its differential form
(2) |
where is the asymptotic propagation speed of the field and is its asymptotic value.
Quoting [1]:
At the outer boundary we use a radiation (Sommerfeld) boundary condition. We start from the assumption that near the boundary all fields behave as spherical waves, namely we impose the condition
(3) |
Where is the asymptotic value of a given dynamical variable (typically 1 for the lapse and diagonal metric components, and zero for everything else), and is some wave speed. If our boundary is sufficiently far away one can safely assume that the speed of light is 1, so for most fields. However, the gauge variables can easily propagate with a different speed implying a different value of .
In practice, we do not use the boundary condition (3) as it stands, but rather we use it in differential form:
(4) |
Since our code is written in Cartesian coordinates, we transform the last condition to
(5) |
We finite difference this condition consistently to second order in both space and time and apply it to all dynamic variables (with possible different values of and ) at all boundaries.
There is a final subtlety in our boundary treatment. Wave propagation is not the only reason why fields evolve near a boundary. Simple infall of the coordinate observers will cause some small evolution as well, and such evolution is poorly modeled by a propagating wave. This is particularly important at early times, when the radiative boundary condition introduces a bad transient effect. In order to minimize the error at our boundaries introduced by such non-wavelike evolution, we allow for boundary behavior of the form:
(6) |
with a function of alone and some unknown power. This leads to the differential equation
or in Cartesian coordinates
(8) |
This expression still contains the unknown function . Having chosen a value of , one can evaluate the above expression one point away from the boundary to solve for , and then use this value at the boundary itself. Empirically, we have found that taking almost completely eliminates the bad transient caused by the radiative boundary condition on its own.
The thorn implements to ingredients for the evolution.
At outer boundary points, as determined by GenericFD’s routine GenericFD_GetBoundaryInfo we use cubic polynomials along the normal of the boundary to extrapolate data from the interior into the boundary region. Due to the use of cubic polynomial we require at least four (4) points of valid data to be available for the extrapolation. This includes ghost zones, which are assumed to contain valid data in the interior of the domain.
The derivatives appearing in (8) are approximated as 2nd order accurate finite difference expressions using centred expressions
(9) |
and one sided expressions
(10) |
for boundaries around the coordinate direction.
Finally we try to extrapolate for the part of the boundary that does not behave as a pure wave (i.e. Coulomb type terms caused by infall of the coordinate lines).
This we do by comparing the source term one grid point away from the boundary (which we already have), to what we would have obtained if we had used the boundary condition there. The difference gives us an idea of the missing part and we extrapolate that to the boundary assuming a power-law decay.
The thorn exports two aliased functions ExtrapolateGammas and NewRad_Apply that should be used in INITIAL and MoL_CalcRHS respectively to extrapolate the contracted Christoffel symbols and apply radiative boundary conditions to evolved variables respectively.
There call signatures are:
where var0 corresponds to , v0 is and radpower is the assumed decay exponent .
The thorn is part of the EinsteinEvolve arrangement available on bitbucket.
If the parameter z_is_radial is set it assumes that the direction is a radial direction and uses this to evaluate the radial derivative in (8). This is the case for the multi-patch coordinate systems provided by the Llama [3] infrastructure.
This thorn requires thorn GenericFD which is part of Kranc [2].
The best example is likely to inspect the source code ML_BSSN and ML_BSSN_Helper, namely:
Please use the Einstein Toolkit mailing list users@einsteintoolkit.org to report issues and ask for help.
This documentation copies text from comments in the source code as well as the paper [1].
[1] M. Alcubierre, B. Bruegmann, P. Diener, M. Koppitz, D. Pollney, E. Seidel and R. Takahashi, “Gauge conditions for long term numerical black hole evolutions without excision,” Phys. Rev. D 67, 084023 (2003) doi:10.1103/PhysRevD.67.084023 [gr-qc/0206072].
[2] “Kranc: Kranc assembles numerical code“, http://kranccode.org/.
[3] “The Llama code“, https://llamacode.bitbucket.io/.