xx NewRad

NewRad

Roland Haas <rhaas@ncsa.illinois.edu>

August 3 2018

Abstract

This thorn implements the radiative boundary condition originally introduced by the BSSNxMoL thorn.

1 Introduction This thorn provides routines to implement radiative boundary conditions as described in section VI ofx[1]: in its differential form where is the asymptotic propagation speed of the field and is its asymptotic value.

2 Physical System

Quotingx[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

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 conditionx(??) as it stands, but rather we use it in differential form:

Since our code is written in Cartesian coordinates, we transform the last condition to 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:

with a function of alone and some unknown power. This leads to the differential equation

or in Cartesian coordinates

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.

3 Numerical Implementation

The thorn implements to ingredients for the evolution.

the boundary conditionx(??), a routine to extrapolate the contracted Christoffel symbols (Xt1xXt3 in the code) into the outer boundaries at .

3.1 Extrapolation

At outer boundary points, as determined by GenericFD’s routine GenericFDxGetBoundaryInfo 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.

3.2 Radiative boundary condition

The derivatives appearing in (??) are approximated as 2nd order accurate finite difference expressions using centred expressions and one sided expressions 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.xCoulomb 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.

4 Using This Thorn

The thorn exports two aliased functions ExtrapolateGammas and NewRadxApply that should be used in INITIAL and MoLxCalcRHS respectively to extrapolate the contracted Christoffel symbols and apply radiative boundary conditions to evolved variables respectively.

There call signatures are:

CCTK_INTxFUNCTIONxxxxxxxxxxxxxxxxxxxxxxxxx\
xxxxExtrapolateGammasxxxxxxxxxxxxxxxxxxxxx\
xxxxxxxx(CCTK_POINTER_TO_CONSTxINxcctkGH,x\
xxxxxxxxxCCTK_REALxARRAYxINOUTxvar)
CCTK_INTxFUNCTIONxxxxxxxxxxxxxxxxxxxxxxxxx\
xxxxNewRad_Applyxxxxxxxxxxxxxxxxxxxxxxxxxx\
xxxxxxxx(CCTK_POINTER_TO_CONSTxINxcctkGH,x\
xxxxxxxxxCCTK_REALxARRAYxINxvar,xxxxxxxxxx\
xxxxxxxxxCCTK_REALxARRAYxINOUTxrhs,xxxxxxx\
xxxxxxxxxCCTK_REALxINxvar0,xxxxxxxxxxxxxxx\
xxxxxxxxxCCTK_REALxINxv0,xxxxxxxxxxxxxxxxx\
xxxxxxxxxCCTK_INTxINxradpower)

where var0 corresponds to , v0 is and radpower is the assumed decay exponent .

4.1 Obtaining This Thorn

The thorn is part of the EinsteinEvolve arrangement available on bitbucket.

gitxclonexgit@bitbucket.org:einsteintoolkit/einsteinevolve.git

4.2 Basic Usage 4.3 Special Behaviour If the parameter zxisxradial is set it assumes that the direction is a radial direction and uses this to evaluate the radial derivative in (??). This is the case for the multi-patch coordinate systems provided by the Llamax[3] infrastructure. 4.4 Interaction With Other Thorns This thorn requires thorn GenericFD which is part of Krancx[2]. 4.5 Examples The best example is likely to inspect the source code MLxBSSN and MLxBSSNxHelper, namely:

<interface.ccl>
CCTK_INTxFUNCTIONxxxxxxxxxxxxxxxxxxxxxxxxx\
xxxxNewRad_Applyxxxxxxxxxxxxxxxxxxxxxxxxxx\
xxxxxxxx(CCTK_POINTER_TO_CONSTxINxcctkGH,x\
xxxxxxxxxCCTK_REALxARRAYxINxvar,xxxxxxxxxx\
xxxxxxxxxCCTK_REALxARRAYxINOUTxrhs,xxxxxxx\
xxxxxxxxxCCTK_REALxINxvar0,xxxxxxxxxxxxxxx\
xxxxxxxxxCCTK_REALxINxv0,xxxxxxxxxxxxxxxxx\
xxxxxxxxxCCTK_INTxINxradpower)
USESxFUNCTIONxNewRad_Apply

<schedule.ccl>
SCHEDULExML_BSSN_NewRadxINxMoL_CalcRHSxAFTERxML_BSSN_EvolutionInterior
{
xxLANG:xC
xx#xNoxneedxtoxsyncxherex--xthexRHSxvariablesxarexneverxsynced
}x"ApplyxNewRadxboundaryxconditionsxtoxRHS"

<NewRad.cc>
#includex"cctk_Arguments.h"
#includex"cctk_Functions.h"
voidxML_BSSN_NewRad(CCTK_ARGUMENTS)
{
xxDECLARE_CCTK_ARGUMENTS;
xxconstxintxradpowerx=x2;x//xforxexample
xxNewRad_Apply(cctkGH,xgt12,xgt12rhs,x0.0,x1.0,xradpower);
}

4.6 Support and Feedback

Please use the Einstein Toolkit mailing list users@einsteintoolkit.org to report issues and ask for help.

5 History

5.1 Thorn Source Code Initial version of method likely by Miguel Alcubierre Current version of code by Erik Schnetter

5.2 Thorn Documentation

Initial version by Roland Haas using text by Miguel, Erik.

5.3 Acknowledgements This documentation copies text from comments in the source code as well as the paperx[1].

References

[1]xxxM.xAlcubierre, B.xBruegmann, P.xDiener, M.xKoppitz, D.xPollney, E.xSeidel and R.xTakahashi, “Gauge conditions for long term numerical black hole evolutions without excision,” Phys.xRev.xD 67, 084023 (2003) doi:10.1103/PhysRevD.67.084023 [gr-qc/0206072].

[2]xxx“Kranc: Kranc assembles numerical code“, http://kranccode.org/.

 [3]xxx“The Llama code“, https://llamacode.bitbucket.io/.

6 Parameters

11zxisxradial 10Scope: privatex01  BOOLEAN

11Description: Consider the local z direction to be the radial one; use with Llama

11        10  x01  Default: no

11

7 Interfaces

General Implements: newrad

Uses header: GenericFD.h

Provides: ExtrapolateGammas to NewRadxApply to

8 Schedule This section lists all the variables which are assigned storage by thorn EinsteinEvolve/NewRad. Storage can either last for the duration of the run (Always means that if this thorn is activated storage will be assigned, Conditional means that if this thorn is activated storage will be assigned for the duration of the run if some condition is met), or can be turned on for the duration of a schedule function.

Storage NONE