1.1 The Chart-as-Type-Registry Pattern

The core spec defines Charts as the authority for coordinate system semantics (§6.1). This extension makes explicit what the implementation established: ChartDomain groups are also the type registry. Named HDF5 compound types are committed as objects inside the ChartDomain group that defines their semantics. This co-location ensures that algebraic type information (stored in attributes on the committed type) and coordinate system information (expressed by the group structure) are always found together.

2.1 Charts as atlas elements — open-ended by design

In differential geometry, an atlas is a collection of charts covering a manifold. Each chart is a homeomorphism from an open set of the manifold to R^n. F5 adopts this structure directly. The set of possible Charts is not closed. This extension defines the structural pattern that any Chart MUST follow; it does not enumerate all charts. Any coordinate system describable by a named compound type and optional transformation rules is a valid F5 Chart.

F5 is agnostic to the physical interpretation of a Chart. What “Schwarzschild coordinates” or “body-fixed frame” means physically is left to the application.

2.2 ChartDomains (chart types) versus chart objects

A ChartDomain is defined by its component names — it represents a chart type. The component names x, y, z define the “Cartesian 3D” chart type.

A chart object is a specific instance of a chart type. A file may contain multiple chart objects of the same type — for example, two overlapping coordinate patches of the same chart type, with transformation rules between them.

The ChartDomain group contains: - the named HDF5 compound types used by all chart objects of that type - all chart object subgroups

Named datatypes are committed at the ChartDomain level, not at individual chart object level. This means they are shared across all chart objects of that type.

Consequence for validators: A Representation group is bound to a specific chart object. All datasets in that Representation MUST use named types whose ChartDomain attribute matches the chart type of that Representation. A Representation must never contain datasets from a different chart type. This consistency rule SHOULD be checked by conforming validators.

Minimalism: The ChartDomain SHOULD contain only the named datatypes that are actually used in Fields throughout the file. Defining types in advance that are never used by any dataset is discouraged. An empty ChartDomain (no named types, no chart objects) is meaningless and SHOULD NOT appear in a valid file.

2.3 Component names define chart type

The member names of the named HDF5 compound type are the coordinate function names x^u : M -> R of the chart. They are the axioms from which all other names in the chart are derived (tangential vector names, co-vector names, tensor component names). Within a ChartDomain, they MUST be used consistently.

F5 does not normatively specify relationships between chart types. Whether the chart type with members {x, y} is a “subset” of the chart type with members {x, y, z} is not a statement F5 makes. What F5 does guarantee is that HDF5 compound subsetting works: a reader requesting only {x, y} from an {x, y, z} dataset gets exactly those components via HDF5’s native type conversion, without any code changes. This is a consequence of HDF5 mechanics, not an F5 semantic claim.

Similarly, the component name r in Schwarzschild coordinates and the component name r in Kruskal-Szekeres coordinates are not the same quantity. A correct implementation SHOULD use distinct component names (e.g., r vs. r_K) and distinct ChartDomains for coordinate systems whose quantities differ physically. Using identical component names for physically distinct quantities is permitted but removes a safety check that F5 would otherwise provide. Whether to enforce this distinction is an application-level design decision; F5 RECOMMENDS distinct names when physical interpretation differs.

2.4 Automatic embedding via HDF5 compound subsetting

A compound type with members {x, y, z} permits reading only {x, y} via HDF5 native type conversion. This embedding extends to tensor types: a symmetric 2-tensor with {xx, xy, yy} can be read as a subset of one with {xx, xy, xz, yy, yz, zz}.

Storing coordinates as a plain float array is explicitly discouraged. Named compound members make this automatic embedding available without code changes. A plain float[3] forces the reader to handle dimensionality explicitly and defeats HDF5’s native subsetting capability.

2.5 Global and local charts

Global ChartDomains under /Charts/ are valid across the entire file.

Local chart objects under //Charts/ reference the global ChartDomain via a GlobalChart soft link and MAY carry additional local information:

• time-dependent transformation rules (a Grid is associated with a specific Timeslice)
• spatially varying transformation matrices specified as datasets at each vertex

In tangential space, the coordinate transformation rule is always a matrix — either the Jacobian (for tangential vectors) or its inverse (for co-vectors). This is one more reason to store different algebraic types with explicitly different component names: a reader that confuses a tangential vector for a co-vector applies the wrong transformation matrix silently.

The specific encoding of transformation data in local chart objects is not yet normatively defined. The structural pattern (global ChartDomain + local object with GlobalChart back-reference) is fixed; transformation content is left to a future extension.

3.1 ChartDomain structure

A ChartDomain group contains named HDF5 types and chart object subgroups:

/Charts/<ChartDomainName>/
    <PrecisionName>/
        Point          <- committed HDF5 named type
    ...                <- additional precision variants (any number)
    Point              <- HDF5 soft link -> <default_precision>/Point
    <ChartObject1>/    <- chart object subgroup
        ...
    <ChartObject2>/    <- chart object subgroup (optional)
        ...

<ChartDomainName> is a human-readable identifier. It has no normative F5 meaning — the normative content is in the type structure and attributes.

Precision variants are named subgroups, each containing a Point committed type. The naming of precision subgroups is not fixed — common names include SinglePrecision, DoublePrecision, HalfPrecision, QuadPrecision, but any consistent naming is valid. Integer types, user-defined precision types, and any other HDF5 primitive type are also permitted. There is no requirement to provide exactly two precision variants; a ChartDomain may contain as many or as few as the application requires.

The Point soft link at the ChartDomain level provides a precision-independent default reference to the “primary” type for that chart. It SHOULD point to the precision variant most commonly used in the file.

A ChartDomain MUST contain at least one chart object. A ChartDomain without any chart object has no operational purpose and SHOULD NOT appear in a valid file.

HDF5 performs automatic conversion between compatible compound types of different precision. A dataset written with a DoublePrecision/Point type can be read using SinglePrecision/Point type definition without additional reader code.

3.2 Chart object structure

A chart object is a subgroup of a ChartDomain. It represents a specific instance of the chart type and MAY contain transformation rules to other chart objects:

/Charts/<ChartDomainName>/<ChartObjectName>/
    Coordinates        <- soft link -> /Charts/<ChartDomainName>
    <TransformTo>/     <- subgroup for transformation to another chart object
        ...

The Coordinates self-referential link connects the chart object back to its parent ChartDomain. This is the link referenced by local Grid charts:

<Timeslice>/<Grid>/Charts/<ChartObjectName>/
    GlobalChart        <- soft link -> /Charts/<ChartDomainName>/<ChartObjectName>

The naming Coordinates for the back-reference link is conventional. It mirrors the pattern visible in existing F5 files (e.g., /Charts/triangular/Points/Coordinates).

Example from an actual F5 file:

/Charts/Cartesian3D/
    DoublePrecision/Point    Type
    SinglePrecision/Point    Type
    Point                    Soft Link {SinglePrecision/Point}
    StandardCartesianChart3D/
        Coordinates          Soft Link -> /Charts/Cartesian3D

/Charts/triangular/
    SinglePrecision/Point    Type
    DoublePrecision/Point    Type
    Point                    Soft Link {SinglePrecision/Point}
    Points/
        Coordinates          Soft Link -> /Charts/triangular

4.1 Principle

Component member names in an HDF5 compound type are the coordinate function names of the chart. They are the starting axioms. Within a ChartDomain they MUST be used consistently; across different ChartDomains there is no constraint.

Member names SHOULD use simple, conventional notation — the same names used in standard mathematical or physics literature for the coordinate functions. For example, a coordinate along the x-axis is named x, not Dx or dx (those are reserved for derived algebraic types; see §5). Using derivative or differential notation for coordinate names would create confusion with the naming scheme of §5.

Member names MAY use UTF-8 encoding. Greek letters (theta, phi, or the actual characters θ, φ) are permitted. The choice between ASCII approximations and Unicode is an application convention.

4.2 Coordinate component names — examples

The following are representative examples. They do not constitute a catalogue; F5 does not enumerate or standardise chart types:

F5 does not assert that “Cartesian 2D is a subset of Cartesian 3D.” The embedding {x, y} ⊂ {x, y, z} is available mechanically via HDF5 compound subsetting, but it is not a normative F5 claim. A chart with members {x, z} is also an HDF5 subset of one with {x, y, z}, but physically it represents a different 2D slice.

Component names carry semantic weight across ChartDomains. A component named r in one chart and r in another chart implies those quantities are the same — readers and downstream tools may treat them as such. For coordinate systems where a shared name would be misleading (e.g., the radial coordinate in Schwarzschild vs. Kruskal coordinates), distinct names SHOULD be used.

5.1 The Dx/dx naming convention for tensorial types

Tangential vectors and co-vectors share identical memory layout but transform differently under coordinate changes. In standard graphics code (e.g., GLSL vec3), both are represented identically — a known source of errors under non-isotropic transformations, because applying a vector transformation to a co-vector (or vice versa) produces silently wrong results.

F5 resolves this at the type level using component names derived from mathematical notation:

• Tangential vectors (contravariant, partial_mu basis): uppercase D prefix — Dx, Dy, Dz — representing partial_x, partial_y, partial_z
• Co-vectors (covariant, dx^mu basis): lowercase d prefix — dx, dy, dz — representing the differential forms dx, dy, dz

With this scheme, a reader cannot accidentally treat a tangential vector as a co-vector while staying within F5’s type system. Doing so requires deliberately misreading {Dx, Dy, Dz} as {dx, dy, dz}, which is an active choice, not a silent default.

5.2 Exterior products — the ^ notation is required, not optional

Exterior products of basis elements use the ^ separator:

The ^ separator is required in these component names, not merely preferred. The reason is that dxdy already has a defined meaning in this scheme: it is the component gxy of a metric tensor (see §5.3). A bivector component cannot be named dxdy — it MUST be named dx^dy to avoid collision. The ^ notation thus resolves a genuine naming conflict, not just a stylistic preference.

The ^ character is valid in HDF5 member names, which are arbitrary strings. Tools that require alphanumeric identifiers must transform these names; that responsibility lies with the tool, not with F5.

Grade and dimension: In 3D, a grade-2 bivector has 3 components, the same count as a grade-1 co-vector. In 4D, a grade-2 bivector has 6 components while a co-vector has 4. Component names and the grade attribute (§6.3) together provide dimension-independent type identification. Avoid reasoning that relies on 3D-specific coincidences.

5.3 Metric and symmetric tensor types

Metric tensor components are named from the product of the coordinate function names, using lowercase d (covariant) notation since a metric has two lower indices:

For a symmetric metric tensor g_{ij} = g_{ji} in 3D Cartesian coordinates:

Note that dxdy here (a metric component, symmetric product) is distinct from dx^dy (a bivector component, antisymmetric exterior product). This is why the ^ is required in exterior product names: dxdy is already taken.

For the contravariant co-metric g^{uv}: DxDx, DxDy, DxDz, DyDy, DyDz, DzDz.

5.4 Connectivity component names — the simplex scheme

For connectivity types in relative Representations (indexing into vertex Skeletons), member names SHOULD use the simplex barycentric scheme: degree-n symmetric monomials in symbols {i, j}:

This generates exactly n+1 names for an n-simplex without enumeration, and the simplex dimension is recoverable from member count. For non-simplex polytopes a third symbol k is introduced (ii, ij, ji, jj for quads; etc.).

6.1 Placement

Algebraic meta-information attributes are placed on the committed named type object inside the ChartDomain group — for example, on /Charts/Cartesian3D/SinglePrecision/Point. They are NOT placed on individual dataset instances. They are declared once per type and shared by all datasets using that type.

Named datatypes are committed on the ChartDomain group (chart type). They are thus available for all chart objects of that type. This sharing is precisely why the ChartDomain attribute (§6.2) must exist: it allows a reader that has a reference to a named type to immediately identify the chart type without traversing the group hierarchy.

6.2 Principle: attributes are optional; absence has semantic meaning

All attributes in this section are OPTIONAL unless otherwise stated.

• Absent covariance: the type is scalar — no tensor indices
• Absent grade: grade equals rank (a simple non-k-vector type)
• Absent attributes entirely: the type is a raw array of numbers, interpreted by the reader’s own conventions

A reader that does not understand these attributes MUST treat the type as a raw array and MUST NOT reject a file because they are present.

6.3 Attribute definitions

/Charts/Cartesian3D/SinglePrecision/Point  Type
    Attribute: ChartDomain  "Cartesian3D"
    Type: struct {
        "x"  +0   native float
        "y"  +4   native float
        "z"  +8   native float
    } 12 bytes

int covariance[] = {+1};       /* Tangential vector:  one upper index        */
int covariance[] = {-1};       /* Co-vector:          one lower index        */
int covariance[] = {+1, +1};   /* Bivector:           two upper indices      */
int covariance[] = {-1, -1};   /* Bi-co-vector:       two lower indices      */
int covariance[] = {-1, -1};   /* Metric tensor:      two lower indices      */
int covariance[] = {+1, +1};   /* Co-metric tensor:   two upper indices      */

9.1 Cartesian 3D — coordinate Point (minimal, no tensor attributes needed)

/Charts/Cartesian3D/
    SinglePrecision/
        Point          struct { float x, y, z }
                         Attribute ChartDomain: "Cartesian3D"
    DoublePrecision/
        Point          struct { double x, y, z }
                         Attribute ChartDomain: "Cartesian3D"
    Point              soft link -> SinglePrecision/Point
    StandardCartesianChart3D/
        Coordinates    soft link -> /Charts/Cartesian3D

No covariance — coordinates are not tensors.

9.2 Tangential vector type

/Charts/Cartesian3D/
    Tangent/
        SinglePrecision/
            Point      struct { float Dx, Dy, Dz }
                         Attribute ChartDomain: "Cartesian3D"
                         Attribute rank:        1
                         Attribute covariance:  [+1]

9.3 Co-vector type

/Charts/Cartesian3D/
    Cotangent/
        SinglePrecision/
            Point      struct { float dx, dy, dz }
                         Attribute ChartDomain: "Cartesian3D"
                         Attribute rank:        1
                         Attribute covariance:  [-1]

9.4 Bivector type

/Charts/Cartesian3D/
    Bivector/
        SinglePrecision/
            Point      struct { float Dx^Dy, Dy^Dz, Dz^Dx }
                         Attribute ChartDomain: "Cartesian3D"
                         Attribute rank:        1
                         Attribute grade:       2
                         Attribute covariance:  [+1, +1]

grade=2 with rank=1 distinguishes this from a co-vector (rank=1, grade=1). In 4D a bivector has 6 components, a co-vector has 4 — they diverge. The grade attribute is the reliable discriminator across dimensions.

9.5 Symmetric metric tensor

/Charts/Cartesian3D/
    Metric/
        DoublePrecision/
            Point      struct { double dxdx, dxdy, dxdz, dydy, dydz, dzdz }
                         Attribute ChartDomain: "Cartesian3D"
                         Attribute rank:        2
                         Attribute covariance:  [-1, -1]

9.6 Triangle connectivity chart

/Charts/triangular/
    SinglePrecision/
        Point          struct { int32 ii, ij, jj }
                         Attribute ChartDomain: "triangular"
    DoublePrecision/
        Point          struct { int64 ii, ij, jj }
    Point              soft link -> SinglePrecision/Point
    Points/
        Coordinates    soft link -> /Charts/triangular

No covariance — integer connectivity arrays are not tensors.