2007-03-06

Abstract

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 deﬁnitions are suggested.

Many thorns work on manifolds that are two-dimensional, closed surfaces. Examples are apparent and event horizons, or the surfaces on which gravitational waves are extracted. Other such surfaces might be excision or outer boundaries (although these are currently not treated as such). There is a need to have a common representation for such surfaces, so that the surface-ﬁnding thorns and the thorns working with these surfaces can be independent. A common representation will also facilitate visualisation. This thorn SphericalSurface provides just such a common representation.

This thorn is not meant to do anything else but be a “repository” for surfaces. It is up to the surface-ﬁnding and surface-using thorns to agree on the details of the information stored. Of course, standard deﬁnitions for the stored quantities are suggested. (For example, there is no exact deﬁnition of the quadrupole moment, because this deﬁnition will depend on the kind of surface that is stored. However, it is speciﬁed that the quadrupole moment should be calculate with respect to the centroid, and that it should not be trace-free.)

This thorn provides storage for several independent surfaces, identiﬁed by an index. It is up to the user to specify, probably in the parameter ﬁle, which thorns use what surfaces for what purpose.

This thorn provides, for each surface, a two-dimensional grid array sf_radius and grid scalars sf_origin_x, sf_origin_y, and sf_origin_z. The number of surfaces is determined by the parameter nsurfaces, which has to be set in the parameter ﬁle.

sf_radius should contain the radius of the surface as measured from its origin, where the arrays indices vary in the $\mathit{\theta}$ and $\varphi $ direction, respectively. Both the radius array and the surface origin are supposed to be set when a surface is stored.

The coordinates on the surface, i.e. the grid origin and spacing in the $\mathit{\theta}$ and $\varphi $ directions, is available from the grid scalars sf_origin_theta, sf_origin_phi, sf_delta_theta, and sf_delta_phi. These grid scalars are set by the thorn SphericalSurface in the basegrid bin, and are meant to be read-only for other thorns.

A relatively new addition to Cactus (in November 2003) are vector grid variables. These are essentially arrays of grid variables. Thorn SphericalSurface makes use of these by storing the surfaces in such arrays. That means that in order to access data from a single surface, on has to use the corresponding surface index as array index. In a similar manner, thorn SurfaceIndex uses array parameters for its parameters (except certain global ones).

This should be kept in mind when writing source code. C has the unfortunate property of converting arrays into meaningless integers if an array subscript is accidentally omitted. Fortran knows whole-array expressions, meaning that it would act on all surfaces instead of a single one if an array subscript is accidentally omitted.

Each element of a vector grid function is a grid function. (The term “grid function vector” might have been more appropriate.) As such, it has a name, which can be used e.g. for output. The name consists of the vector grid function name to which the surface index in square brackets has been appended.

In many cases, only some abstract information about the surface is of interest, such as its mean radius or its quadrupole moment. For that purpose there are additional grid scalars that carry this information. These grid scalars are also supposed to be set when a surface is stored. These grid scalars are

- sf_mean_radius
- Mean of the surface radius. This should be the arithmetic mean where the radii have been weighted with $sin\mathit{\theta}$, or a suitable generalisation thereof. This quantity is also supposed to be a measure of the surface’s monopole moment. One suggested expression is $M=\sqrt{A}$ with $A={\int}_{S}d\Omega \phantom{\rule{0.3em}{0ex}}{r}^{2}\u2215{\int}_{S}d\Omega $.
- sf_min_radius, sf_max_radius
- Minimum and maximum of the surface radius.
- sf_centroid_x, sf_centroid_y, sf_centroid_z
- The centre of the surface. While the quantities sf_origin_* denote the point from which the radius of the surface is measured, the quantities sf_centroid_* should contain the point which is “logically” the centre of the surface. This quantity is supposed to be a measure of the dipole moment of the surface. One suggested expression is ${D}^{i}={\int}_{S}d\Omega \phantom{\rule{0.3em}{0ex}}{x}^{i}\u2215A$.
- sf_quadrupole_xx, sf_quadrupole_xy, sf_quadrupole_xz, sf_quadrupole_yy, sf_quadrupole_yz, sf_quadrupole_zz
- The quadrupole moment of the surface. This should be the full quadrupole moment and not a trace-free quantity. One suggested expression is ${Q}^{ij}={\int}_{S}d\Omega \phantom{\rule{0.3em}{0ex}}{y}^{i}{y}^{j}\u2215A$ with ${y}^{i}={x}^{i}-{D}^{i}$.
- sf_min_x, sf_min_y, sf_min_z, sf_max_x, sf_max_y, sf_max_z
- The bounding box of the surface.

Note that the integral expressions are only suggestions which should be adapted to whatever is natural for the stored surface. The suggested integral expressions also depend on the metric which is used; this should be a “natural” metric for the surface. E.g. for apparent horizons, this might be the induced two-metric ${q}_{ij}$ from the projection of the ADM three-metric ${\gamma}_{ij}$.

There is also an integer ﬂag valid available. Its deﬁnition is up to the surface-providing thorn. The following interpretations are suggested:

- zero:
- No surface is provided at this time step.
- negative:
- No surface could be found at this time step.
- positive:
- The surface data are valid.

Note that, if this ﬂag is used, it is necessary to set this ﬂag at every iteration. This ﬂag is not automatically reset to zero.

The number of grid points in the radius array sf_radius is determined by the parameters ntheta and nphi. These arrays exist for each surface. (Internally, thorn SphericalSurface stores all surfaces with the same array shape maxntheta and maxnphi, so that the parameters ntheta and nphi must not be used for index calculations. Use the surfaces lsh instead.) The surface array shape includes ghost or boundary zones at the array edges. These ghost zones have the same size for all surfaces.

Note that because the radius arrays are stored with larger size $\mathtt{\text{maxntheta}}\times \mathtt{\text{maxnphi}}$, the actual radius data (of size $\mathtt{\text{ntheta[surface\_number]}}\times \mathtt{\text{nphi[surface\_number]}}$ elements) is in general not contiguous in memory. If you want to interpolate a SphericalSurface surface radius, you need to either copy the radius data to a contiguous 2-D array of size $\mathtt{\text{ntheta[surface\_number]}}\times \mathtt{\text{nphi[surface\_number]}}$, or use an interpolator which supports such non-contiguous input arrays. The AEIThorns/AEILocalInterp local interpolation thorn supports these via the input_array_strides parameter-table option. See the AEILocalInterp thorn guide for details.