2008-04-07

Abstract

Provide grid functions for the stress-energy tensor ${T}_{\mu \nu}$, and schedule when these grid functions are calculated. This allows diﬀerent thorns to cooperate without explicitly depending on each other. This thorn is compatible with the CalcTmumu.inc interface, in the sense that thorns using this interface will work correctly with TmunuBase. Thorn TmunuBase is for the stress-energy tensor what thorn ADMBase is for the metric tensor.

Thorn TmunuBase provides core infrastructure for thorns implementing some kind of energy or matter in general relativity, for example general relativistic hydrodynamics formulations. It provides the basic variables, i.e., the stress-energy tensor ${T}_{\mu \nu}$, in addition to a set of parameters to regulate their use. These variables are used to communicate between (possibly multiple) thorns contributing to the stress-energy content of the spacetime, and thorns needing to evaluate the stress-energy tensor such as spacetime evolution methods. It also provides schedule groups to manage when ${T}_{\mu \nu}$ is calculated and when it is ready for access.

TmunuBase weakly assumes (but does not require) that the spacetime is described in terms of a $3+1$ decomposition. The variables provided by TmunuBase are:

- The “scalar” part of ${T}_{\mu \nu}$, its time-time component: eTtt
- The “vector” part of ${T}_{\mu \nu}$, its time-space components: eTtx, eTty, eTtz
- The “tensor” part of ${T}_{\mu \nu}$, its space-space components: eTxx, eTxy, eTxz, eTyy, eTyz, eTzz

These components have the preﬁx e to avoid naming conﬂicts with existing variables. Many thorns dealing with matter already use variable names such as Ttt.

These variables have up to three time levels.

By default, the TmunuBase variables have no storage, and TmunuBase is inactive. This makes it possible to add a matter interface to existing vacuum spacetime methods without changing their behaviour.

Several parameters choose how TmunuBase behaves at run time:

- The parameter stress_energy_storage activates storage for ${T}_{\mu \nu}$ and enables the schedule groups which calculate it.
- The parameter stress_energy_at_RHS moves calculating the ${T}_{\mu \nu}$
from the evol bin into the MoL_PostStep group. This increases the order of accuracy of the
spacetime–matter coupling, but is only possible when thorn MoL is used.
^{1}Generally, this parameter should be set when MoL is used. - The parameter timelevels chooses the number of time levels for ${T}_{\mu \nu}$. The default is a single time level, which is suﬃcient for unigrid simulation. Mesh reﬁnement simulation may require several time levels if mesh reﬁnement boundaries require correct values.
- The parameter prolongation_type deﬁnes the prolongation operator for mesh reﬁnement boundaries. The default is Lagrange interpolation.

The grid scalar stress_energy_state describes whether the ${T}_{\mu \nu}$ variables have storage.

There may be multiple thorns contributing to ${T}_{\mu \nu}$. Therefore, thorn TmunuBase initialises ${T}_{\mu \nu}$ to zero, and each thorn has to add to the existing values in ${T}_{\mu \nu}$. The corresponding routine should be scheduled in the bin AddToTmunu. Note: Do not schedule anything in the schedule bin SetTmunu.

Since the values of ${T}_{\mu \nu}$ change at each time step, or – if a thorn like MoL is used – at each substep, ${T}_{\mu \nu}$ needs to be recalculated frequently. This happens either in the schedule bin evol or in the schedule group MoL_PostStep. ${T}_{\mu \nu}$ may only be accessed after it has been calculated, e.g. IN MoL_PostStep AFTER SetTmunu. ${T}_{\mu \nu}$ can be freely accessed at other times, e.g. in MoL_CalcRHS or at poststep or analyisis.

Cactus provides another interface for contributing to the stress-energy tensor, called CalcTmunu. This alternative interface (which is described in thorn ADMCoupling) requires writing routines in ﬁxed-format Fortran 77 and inserting lines of code into a ﬁle CalcTmunu.inc. We suggest to use exactly one of these two interface and not to mix them.

Thorn TmunuBase takes contributions from the CalcTmunu interface automatically into account as well. It also collects the values which are added to its ${T}_{\mu \nu}$ and provides these to other thorns which use the CalcTmunu.inc interface. That is, thorn TmunuBase is fully backwards compatible.

The CalcTmunu interface and this thorn TmunuBase make diﬀerent space/performance tradeoﬀs. CalcTmunu does not store any components of the stress-energy tensor, which saves memory and is also more eﬃcient if its components can be quickly calculated from other variables (presumably the state vector of a hydrodynamics thorn).

TmunuBase requires explicit storage for ${T}_{\mu \nu}$. This is necessary if ${T}_{\mu \nu}$ needs to be interpolated e.g. for dynamical horizon calculations. Compared to the overall number of grid function in a typical simulation the number of additional variables is tolerable (typical numbers are 10 additional variables with 200 existing variables). With the exception of the parts ensuring compatibility to CalcTmunu, TmunuBase is also a much simpler and more ﬂexible mechanism.