Adding initial data

Writing an Initial Data thorn for the Einstein Toolkit

This page explains how to write a new initial data thorn for the Einstein Toolkit. These initial data will set up ADMBase or HydroBase variables, so that they are usable for all other thorns that are based Einstein Toolkit.

Introduction

You need:

• a prescription or routine that actually generates the initial data,
• to decide whether this are initial data for the spacetime, for hydrodynamics, or both,
• these instructions.

Example

Let us assume, for the sake of simplicity, that we are going to set up initial data for the spacetime only. Let us pick a concrete example: the Kruskal coordinates. The Kruskal coordinates describe a single, static black hole (the Schwarzschild spacetime), and their advantage over many other coordinate systems is that they cover the whole, extended Schwarzschild spacetime (i.e. including both asymptotically flat ends, the worm hole, the black and white hole horizons), and that they do not introduce coordinate singularities. Of course there are curvature singularities inside the white and black holes, but there are no "artificial" singularities, e.g. at the horizons. The Krukal coordinates are beautifully described in Sean M. Carroll's "A No-Nonsense Introduction to General Relativity", 2001, at http://pancake.uchicago.edu/~carroll/notes/grtinypdf.pdf .

To make things a bit more interesting, we are also going to apply a coordinate transformation to the Kruskal coordinates, so that we can evaluate them on arbitrary slices. Of course that means that the actual coordinates are not the Kruskal coordinates. This means that the slicing can in principle be chosen arbitrarily within the extended Schwarzschild spacetime. Other coordinates (e.g. ingoing Eddington-Finkelstein coordinates) are regular only a in part of the spacetime. This will allow us to examine arbitrary slicings of Schwarzschild -- even slicings that are not spherically symmetric -- which is very interesting when one studies trapped surfaces or apparent horizons.

In particular, we want to implement the following slicings:

• Kruskal
• Schwarzschild
• the Wald-Iyer slicing introduced in Phys. Rev. D 44, R3719 (1991), "Trapped surfaces in the Schwarzschild geometry and cosmic censorship"

As described in this paper, this slicing has the property that it comes arbitrarily close to the (future) curvature singularity in the Schwarzschild spacetime, but does not contain any apparent horizons. We want to examine this numerically.

Kruskal Solution

As mentioned above, we begin by implementing a Fortran module that evaluates the Kruskal solution at a particular event (t,x,y,z). How to do this is outside the scope of this tutorial; one example implementation is here: File:kruskal.F90.

This module contains a routine that has as its input arguments 4 real numbers t, x, y, and z, describing the spacetime event where the four-metric needs to be evaluated. Its output arguments are alpha, beta^i, and g_ij, which this routine has to fill in. For convenience, this routine also sets the two arguments u and v to the Kruskal coordinates of this event, and two other arguments st and sr to its Schwarzschild coordinates. (Since the metric is spherically symmetric, angular coordinates can be omitted.)

Internally, the routine transforms the tuple (t,x,y,z) to (u,v) and (st,sr) according to the chosen slicing. In particular, the different slicings lead to:

• Kruskal: v = t
• Schwarzschild: v = u tanh (t / 4M)
• Wald-Iyer: v = t z/r

where M is the ADM mass and r is the Pythagorean of (x,y,z). Details do not matter for the tutorial here can be found in the source code. It should be mentioned that this coordinate transformation requires a non-linear root finding which is implemented with the help of the GSL (GNU Scientific Library).

This module is the heart of this initial data thorn, and most of the physical and numerical work has been invested here. What remains it to wrap this routine, so that the Einstein Toolkit understands it.

In many other cases, the initial data will be calculated not pointwise, but by an external solver on an auxiliary grid, and there will be an interpolation routine that evaluates the solution at arbitrary coordinates (t,x,y,z). It is sufficient if the solution is only known at t=0.

Loop over all grid points

The next step is to populate the ADMBase (and/or HydroBase) grid functions. This requires a routine which is scheduled in Cactus's INITIAL bin, and which iterates over all grid points, evaluating the solution there. The solution is evaluated by calling the Kruskal module described above.

The boilerplate form of such a routine is as follows:

#include "cctk.h"
#include "cctk_Arguments.h"
#include "cctk_Functions.h"
#include "cctk_Parameters.h"

subroutine Kruskal_InitialData (CCTK_ARGUMENTS)
  implicit none
  DECLARE_CCTK_ARGUMENTS
  DECLARE_CCTK_FUNCTIONS
  DECLARE_CCTK_PARAMETERS
  integer   :: i, j, k
  do k = 1, cctk_lsh(3)
     do j = 1, cctk_lsh(2)
        do i = 1, cctk_lsh(1)
           ! DO THE ACTUAL WORK
        end do
     end do
  end do
end subroutine Kruskal_InitialData

This routine has to fill in all ADMBase variables, which are:

• lapse alpha
• shift beta^i
• metric g_ij
• extrinsic curvature K_ij