0. Introduction and Scope

This document specifies the negative IndexDepth extension to the F5 data model. It enables the representation of data whose spatial coordinates are themselves derived from stored coefficients, rather than stored directly. The resolution of the resulting spatial representation is determined by the reader at runtime, not by the writer at file creation time.

This extension is implemented in the F5 reference library and has been applied to real scientific data since 1999. The concrete motivating case is the apparent horizon of merging black holes, represented via real spherical harmonic coefficients from which the horizon surface shape is reconstructed at any desired resolution.

Relationship to the core spec: All rules from F5_Layout.md apply. Negative IndexDepth is implicit in the core spec’s treatment of IndexDepth as an integer attribute — this document makes it explicit and defines its semantics.

Relationship to the type extension: This document introduces application-defined ChartDomains (SphericalChart2D, PolarChart3D, SphericalHarmonics) following the conventions of F5_Extension_1_NamedTypes.md. These are illustrative examples of the pattern, not exhaustive normative definitions.

1. Background: The Horizon Reconstruction Problem

The apparent horizon of a black hole is a 2D surface embedded in 3D space. For a nearly spherical surface, the shape is efficiently described by its spherical harmonic decomposition:

r(θ,φ) = Σ_{l=0}^{l_max} Σ_{m=-l}^{l}  a_lm · Y_lm(θ,φ)

where Y_lm are the real spherical harmonic basis functions, a_lm are the coefficients, and r(θ,φ) is the radial distance from the expansion center to the surface at angular position (θ,φ).

Storage economy: For l_max = 7 there are (l_max+1)² = 64 coefficients. These 64 numbers completely determine the surface shape. Storing the surface as an explicit vertex mesh at 201×201 resolution requires 40,401 coordinate triples — 630 times more data, at a fixed resolution chosen by the writer.

The F5 approach: Store the 64 coefficients. The reader reconstructs the surface at whatever resolution its visualization algorithm requires. The file does not contain vertices; it contains the recipe for producing them.

Historical note: The example data (mahf_coeff_0.alm, mahf_coeff_1.alm, mahf_coeff_2.alm, mahf_0.gauss, mahf_area_0.tl) are from the first full 3D numerical simulation of merging black holes (Cactus code, 1999), produced before F5 existed. They were read directly into the F5 in-memory fiber bundle model at the time. This extension specifies their normative F5 HDF5 representation. The three coefficient files describe three distinct apparent horizons at the same timeslice — two individual black holes and the common merged horizon — with expansion centers at:

Horizon 0 (merged):  xc = 0.000,  yc = 0.000,  zc =  0.000
Horizon 1 (BH 1):    xc = 0.000,  yc = 0.000,  zc = +1.570
Horizon 2 (BH 2):    xc = 0.000,  yc = 0.000,  zc = -1.430

The distinct centers make the three horizons structurally separate Grids within the same timeslice, each with its own local chart transformation rule.

2. Negative IndexDepth: Definition and Semantics

IndexDepth -2  →  IndexDepth -1  →  IndexDepth 0  →  IndexDepth 1
(meta-coeff)       (coeff)           (vertices)        (cells)

3. ChartDomains Introduced in This Extension

Three ChartDomains are required for the horizon example. All follow the conventions of F5_Extension_1_NamedTypes.md.

/Charts/SphericalChart2D/
    SinglePrecision/
        Point          struct { float theta, phi }
                         Attribute ChartDomain: "SphericalChart2D"
                         Attribute Dimensions:  2
    DoublePrecision/
        Point          struct { double theta, phi }
    Point              soft link -> SinglePrecision/Point

/Charts/PolarChart3D/
    SinglePrecision/
        Point          struct { float r, theta, phi }
                         Attribute ChartDomain: "PolarChart3D"
                         Attribute Dimensions:  3
    DoublePrecision/
        Point          struct { double r, theta, phi }
    Point              soft link -> SinglePrecision/Point

/Charts/SphericalHarmonics/
    SinglePrecision/
        Point          struct { int32 l, int32 m }
                         Attribute ChartDomain: "SphericalHarmonics"
                         Attribute Dimensions:  2
    DoublePrecision/
        Point          struct { int64 l, int64 m }
    Point              soft link -> SinglePrecision/Point

4. The Coordinate Transformation Chain

A reader that needs Cartesian coordinates for rendering follows this chain:

SphericalHarmonics (l,m) index space        [IndexDepth -1, stored]
    ↓  synthesis: r(θ,φ) = Σ a_lm · Y_lm(θ,φ)
SphericalChart2D (θ,φ) → PolarChart3D (r,θ,φ) [IndexDepth 0, angular stored]
    ↓  conversion: x = r sinθ cosφ + xc
                   y = r sinθ sinφ + yc
                   z = r cosθ     + zc
CartesianChart3D (x,y,z)                     [IndexDepth 0, reader-derived]

The angular (θ,φ) grid is stored at IndexDepth 0. The radial component r(θ,φ) is procedurally added by the reader using the harmonic coefficients. The Cartesian conversion uses the expansion center (xc, yc, zc) stored in the local Grid chart transformation rule.

The PolarChart3D appears in each Grid’s Charts group only as a named transformation subgroup within CartesianChart3D/ — it holds the origin attribute but carries no Positions dataset. Its presence as a named subgroup is the signal to a reader that the PolarChart3D → CartesianChart3D transformation is defined for this Grid.

5. Complete F5 Structure: Single Horizon

The following shows the complete layout for one apparent horizon (Horizon_0). The structure for Horizon_1 and Horizon_2 is identical except for the origin value.

/Charts/
    SphericalChart2D/                    (§3.1)
        DoublePrecision/Point   struct { double theta, phi }
        SinglePrecision/Point   struct { float  theta, phi }
        Point                   soft link -> SinglePrecision/Point

    PolarChart3D/                        (§3.2)
        DoublePrecision/Point   struct { double r, theta, phi }
        SinglePrecision/Point   struct { float  r, theta, phi }
        Point                   soft link -> SinglePrecision/Point

    SphericalHarmonics/                  (§3.3)
        DoublePrecision/Point   struct { int64 l, int64 m }
        SinglePrecision/Point   struct { int32 l, int32 m }
        Point                   soft link -> SinglePrecision/Point

    Cartesian3D/                         (standard, F5_Extension_1_NamedTypes.md)
        ...


/t=000000010.3580200000/

    Horizon_0/                           <- Grid

        Charts/
            SphericalChart2D/
                GlobalChart              -> /Charts/SphericalChart2D/

            CartesianChart3D/
                PolarChart3D/            <- transformation rule: PolarChart3D -> Cartesian
                    Attribute: origin    {0.0, 0.0, 0.0}   (double[3])
                    (no GlobalChart: PolarChart3D appears here only as
                     a named transformation step, not as a standalone chart object)


        Coefficients/                    <- Skeleton, IndexDepth = -1
            Attribute F5::SkeletonDimensionality   2   <- (l,m) is 2D
            Attribute F5::IndexDepth              -1
            Attribute F5::rank                     0

            SphericalHarmonics/          <- Representation in harmonic index space
                Positions                <- type: SphericalHarmonics/DoublePrecision/Point
                                         <- Dataset {64}: { int64 l, int64 m } per coeff
                                         <- stores which (l,m) each entry belongs to;
                                         <- ordering is arbitrary, determined by this array
                a_lm                     <- type: double scalar
                                         <- Dataset {64}: coefficient values
                                         <- indexed identically to Positions


        Points/                          <- Skeleton, IndexDepth = 0
            Attribute F5::SkeletonDimensionality   0
            Attribute F5::IndexDepth               0
            Attribute F5::rank                     0

            SphericalChart2D/            <- Representation in angular (theta,phi) space
                Positions                <- TypeInfo: DirectProduct
                                         <- encodes uniform angular sampling:
                                         <-   theta: UniformSampling [0, pi],  n=201
                                         <-   phi:   UniformSampling [0, 2pi], n=201
                                         <- angular grid ONLY — no r stored here;
                                         <- r is derived procedurally from Coefficients

                GaussianCurvature        <- type: double scalar per point
                                         <- TypeInfo: DirectProduct (same grid)
                                         <- Dataset {201, 201}
                                         <- stored at simulation resolution

                area                     <- type: double
                                         <- H5S_SCALAR HDF5 dataspace
                                         <- TypeInfo: Constant
                                         <- integrated surface area at this timeslice;
                                         <- constant over all surface points —
                                         <- a property of the whole surface, not vertices

6. The Three-Horizon Layout at One Timeslice

The three apparent horizons are three Grids within the same timeslice. Each uses the same global ChartDomains and the same Skeleton structure. The only differences are the stored coefficient values, the stored Gaussian curvature, and the expansion center in the local transformation rule.

/t=000000010.3580200000/

    Horizon_0/                           <- merged/common horizon
        Charts/
            SphericalChart2D/
                GlobalChart              -> /Charts/SphericalChart2D/
            CartesianChart3D/
                PolarChart3D/
                    Attribute: origin    {0.000, 0.000,  0.000}
        Coefficients/ ...                <- 64 a_lm for merged horizon
        Points/      ...                 <- GaussianCurvature, area for merged horizon

    Horizon_1/                           <- individual black hole 1
        Charts/
            SphericalChart2D/
                GlobalChart              -> /Charts/SphericalChart2D/
            CartesianChart3D/
                PolarChart3D/
                    Attribute: origin    {0.000, 0.000, +1.570}
        Coefficients/ ...                <- 64 a_lm for BH1
        Points/      ...                 <- GaussianCurvature, area for BH1

    Horizon_2/                           <- individual black hole 2
        Charts/
            SphericalChart2D/
                GlobalChart              -> /Charts/SphericalChart2D/
            CartesianChart3D/
                PolarChart3D/
                    Attribute: origin    {0.000, 0.000, -1.430}
        Coefficients/ ...                <- 64 a_lm for BH2
        Points/      ...                 <- GaussianCurvature, area for BH2

7. The Derivation Link: How a Reader Connects IndexDepth Levels

8. IndexDepth -2 and the General Chain

If the spherical harmonic coefficients a_lm are themselves derived from a higher-level set of meta-parameters (for example, a principal component expansion a_lm = Σ_n b_n · V_lm_n for some basis V), the chain extends to IndexDepth -2:

/t=.../Horizon_0/

    MetaCoefficients/            <- Skeleton, IndexDepth = -2
        Attribute F5::IndexDepth    -2
        SomeBasis/
            Positions            <- indices in meta-coefficient space
            b_n                  <- meta-coefficient values

    Coefficients/                <- Skeleton, IndexDepth = -1
        SomeBasis/               <- relative Representation: Coefficients -> MetaCoeff
            Positions            <- maps each a_lm to its meta-generator indices
        SphericalHarmonics/
            Positions            <- (l,m) pairs
            a_lm                 <- may be stored or marked as procedurally derivable

    Points/ ...                  <- IndexDepth 0, as before

The Maximal-Depth Principle (core spec §18.11.1) applies in the negative direction: if there is any possibility that coefficients may themselves be derived from a higher-level source, assign IndexDepth -2 (or lower) to the coefficient Skeleton now, preserving IndexDepth -1 for a potential intermediate level.

9. Reader Requirements

10. Summary of Normative Elements

11. Reader Derivation Strategy

A reader seeking to construct vertex coordinates from generator data scans the Grid’s Skeletons for any with IndexDepth < 0. If vertices at IndexDepth 0 already exist in the file at a suitable resolution, the reader uses them directly. If vertices are absent or a different resolution is required, the reader inspects the IndexDepth -1 Skeletons and applies whichever derivation rule it understands and finds computationally optimal.

Multiple derivation paths may coexist — coefficient synthesis, subsampling from another Skeleton, coordinate transformation from another Grid. The choice among them is a reader decision based on computational cost, numerical stability, and available implementations. F5 does not prescribe a preferred path: the optimal choice is context-dependent and the reader is best placed to make it. Ambiguity among derivation paths is acceptable and expected.

Complex harmonic coefficients (when needed) are stored using the existing TypeInfo=SeparatedCompound mechanism — one field for the real part, one for the imaginary part, both indexed identically to the Positions (l,m) array. No special treatment beyond the standard SeparatedCompound case is required.

12. Literature and Data Provenance

Example data provenance: Files mahf_coeff_0.alm, mahf_coeff_1.alm, mahf_coeff_2.alm, mahf_0.gauss, mahf_area_0.tl — output of the Cactus computational toolkit (1999), from the first full 3D numerical simulation of binary black hole merging. These data predate F5 and were read directly into the F5 in-memory fiber bundle model without HDF5 conversion.

Apparent horizon finding: Thornburg, J.: “A fast apparent-horizon finder for three-dimensional Cartesian grids in numerical relativity.” Classical and Quantum Gravity 21(2), pp. 743-766 (2004).

Cactus framework: Goodale, T., Allen, G., Lanfermann, G., Massó, J., Radke, T., Seidel, E., Shalf, J.: “The Cactus framework and toolkit: Design and applications.” VECPAR 2002, Lecture Notes in Computer Science, Springer, Berlin (2003).

F5 data model: Benger, W.: “Visualization of General Relativistic Tensor Fields via a Fiber Bundle Data Model.” PhD thesis, FU Berlin / ZIB, 2004. https://www.fiberbundle.net/papers/TensorFieldViz.pdf

End of Document