Einstein Toolkit standards
Thorn ADMBase provides core infrastructure for thorns implementing general relativity on a 3D grid in the 3+1 formalism. It provides the basic variables (3-metric, extrinsic curvature, lapse and shift vector) for the 3+1 formalism, in addition to a set of parameters to regulate the methods used for their evolution. These variables are used to communicate between thorns providing initial data, evolution methods and analysis routines for the 3+1 formalism. In addition, the variables can be used as a mechanism to interact with alternative formalisms, as long as routines can be written to transform alternative variables into these 3+1 variables. (Taken from the ADMBase documentation)
The Einstein Toolkit uses this thorn for ensuring that different analysis and initial data thorns are able to communicate with evolution thorns, independently of the variables which are used for performing the Einstein evolution. Generally speaking, an initial data thorn will set the ADMBase variables (gxx, gxy, ..., kxx, kxy, ..., alp, betax, ...) to the required initial data. An evolution thorn will import the ADMBase variables into its evolution variables (e.g. for BSSN this might be phi, gammaTilde11, ...) and perform the evolution using these variables. On every time step, it will update the ADMBase variables from the evolved variables so that the ADMBase variables always contains the current solution. Analysis thorns such as those for horizon-finding or wave extraction then use the ADMBase variables, meaning that they can be used in simulations with any evolution thorn which uses the ADMBase mechanism.
See the ADMBase documentation for more information.
This thorn provides a repository for two-dimensional surfaces with spherical topology. This thorn does not actually do anything with these surfaces, but allows other thorns to store and retrieve the surfaces and some associated information. The exact interpretation of the stored quantities is up to the using thorns, but certain standard definitions are suggested. (Taken from the SphericalSurface documentation)
Spherical surfaces are numbered from 0 upwards. In the Einstein toolkit, spherical surfaces are used to communicate information about spherical surfaces (or sometimes just coordinate locations of, e.g. black holes or neutron stars) between thorns. One thorn can update a given spherical surface with information, and another thorn can read that information without having to know about the first thorn. Typically, the surface used will be controlled by a user-settable parameter. For example, the thorn AHFinderDirect has parameters to choose which surface to store apparent horizon information in. The thorn CarpetTracker has a parameter to tell it which spherical surfaces to use to choose mesh refinement grid locations. The centroid of the horizon can then be used to determine where to perform mesh refinement. Often thorns will use the spherical surface interface to store only a handful of values, which may not have anything to do with surfaces; for example CarpetTracker only looks at the centroid variables.
See the SphericalSurface documentation for more information.
HydroBase extends the CactusEinstein framework to include an interface for hydrodynamics to work within. HydroBase's main function is to store the primitive variables, common among hydrodynamic simulations, commonly needed parameters, and schedule groups for the main functions of a hydrodynamics code.
The idea behind this thorn is to create a slim, common set of variables, parameters and scheduling groups which can then be used by different hydrodynamics codes. It should contain the common concepts of different hydrodynamics codes, but at the same time it should be as slim as possible to remain as general as possible. HydroBase should not contain the actual source code of typical routines of hydrodynamics codes, it should merely provide a common setup in which hydrodynamics codes can put their routines.
Because there exist different formulations of the hydrodynamics equations and not all of them involve concepts like conserved variabled or treat them differently, which is the reason why these variables are not defined in HydroBase but this is left to the hydrodynamics codes. (Taken from the HydroBase documentation)
In order to facilitate these goals, thorns using HydroBase may assume that the quantities stored in HydroBase use geometrized units in which
- G = c = 1
- Msun= 1.
Expressed in terms of SI units the units of mass, distance, time, and magnetic field are
|[T]||=||[L] / c|
|[B]||=||1 / [L] / (ε0 G / c2)1/2,|
where the last equation serves to define the units of magnetic field strength.
Currently HydroBase defines the following variables:
- rest mass density in the frame comoving with the fluid
- gas pressure in the frame comoving with the fluid
- specific internal energy in the frame comoving with the fluid
- contravariant fluid three velocity as measured by the Eulerian observers: vi = ui / (α ut) + βi / α
The following variables are only allocated storage on request.
- the electron fraction
- temperature of fluid in MeV
- specific entropy per particle in kB/baryon
- contravariant magnetic field vector measured by the Eulerian observers, Bi = (4π)-1/2 nν F*νi
HydroBase also defines an excision mask hydro_excision_mask which can be used (eg. by GRHydro) to turn off the evolution of the hydrodanmic variables in certain domains (eg. inside the apparent horizon).
In analogy to ADMBase HydroBase defines parameters to select the type of initial data and how this initial data is to be evolved. Please see HydroBase's param.ccl file for details.