--- # **F5 EXTENSION SPECIFICATION PART 1: Named Chart Types and Algebraic Meta-Information** --- # 0. Introduction and Scope This document is Part 1 of the F5 extension specification series. It extends the F5 Master Specification (F5Layout.md, hereafter "the core spec") with normative conventions for: - the structure of **ChartDomain groups** (chart types) and their associated named HDF5 compound types - the structure of **chart object groups** within a ChartDomain - a **component naming scheme** encoding topological and algebraic structure - an **optional set of algebraic meta-information attributes** on named types - the distinction between **chart types** (ChartDomains) and **chart objects** This extension is strictly additive. All constructs are layered on top of the core spec without modifying any existing rules. A reader implementing only the core spec MUST correctly ignore unknown attributes on named types. The guiding principle is: *keep things as simple as possible, but not simpler.* Attributes are added only where they resolve genuine ambiguity. The covariance attribute, for example, is absent from scalar types — its absence is informative. **Part 2** (F5_Extension_CombMaps.md) extends this document with combinatorial map and half-edge structures. --- # 1. Relationship to the Core Specification All rules from F5Layout.md apply without modification. Key sections extended here: - §6.1 (Charts and coordinate representations) — extended by §3, §4, §5 - §7.1 (Field identification by datatype) — extended by §5 - §8.5 (TypeInfo) — clarified in §7 ## 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. The Mathematical Nature of Charts in F5 ## 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. ChartDomain and Chart Object Structure ## 3.1 ChartDomain structure A ChartDomain group contains named HDF5 types and chart object subgroups: ``` /Charts// / Point <- committed HDF5 named type ... <- additional precision variants (any number) Point <- HDF5 soft link -> /Point / <- chart object subgroup ... / <- chart object subgroup (optional) ... ``` `` 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/// Coordinates <- soft link -> /Charts/ / <- 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: ``` //Charts// GlobalChart <- soft link -> /Charts// ``` 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. Component Naming: Coordinate Types ## 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: | Coordinate system | Component names | Note | |--------------------|----------------------|-----------------------------------| | Cartesian 2D | x, y | | | Cartesian 3D | x, y, z | | | Cartesian 4D | t, x, y, z | | | Cylindrical 3D | r, phi, z | or r, φ, z with UTF-8 | | Spherical 3D | r, theta, phi | or r, θ, φ | 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. Component Naming: Algebraic Types ## 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: | Type | Dim | Component names | |-------------------------|-----|---------------------------------| | Tangential vector | 3 | Dx, Dy, Dz | | Co-vector | 3 | dx, dy, dz | | Bivector (Dx^Dy basis) | 3 | Dx^Dy, Dy^Dz, Dz^Dx | | Bi-co-vector (dx^dy) | 3 | dx^dy, dy^dz, dz^dx | | Mixed (Dx^dy) | 3 | Dx^dy, Dy^dz, Dz^dx | | Trivector | 3 | Dx^Dy^Dz | | Pseudo-co-scalar | 3 | dx^dy^dz | 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: | Component | Name | |-------------------|-------| | g_{xx} | dxdx | | g_{xy} = g_{yx} | dxdy | | g_{xz} = g_{zx} | dxdz | | g_{yy} | dydy | | g_{yz} = g_{zy} | dydz | | g_{zz} | dzdz | 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}: | Simplex | k | Members | Count | |--------------|---|-----------------------------------|-------| | edge | 1 | i, j | 2 | | triangle | 2 | ii, ij, jj | 3 | | tetrahedron | 3 | iii, iij, ijj, jjj | 4 | | 4-simplex | 4 | iiii, iiij, iijj, ijjj, jjjj | 5 | | n-simplex | n | all length-n strings over {i,j} | n+1 | 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. Algebraic Meta-Information Attributes ## 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 ### ChartDomain - **Type**: null-terminated ASCII or UTF-8 string - **Value**: the name of the ChartDomain group (chart type) this committed type belongs to - **Status**: REQUIRED for all committed named types in F5 files `ChartDomain` is a back-reference from the named type to its ChartDomain group. It enables O(1) lookup: a reader that opens a dataset, reads its type, and reads the `ChartDomain` attribute immediately knows the chart type — no group traversal needed. Without this attribute, a reader would need to scan the entire `/Charts/` hierarchy to find which ChartDomain group contains the type in question. Example from an actual F5 file: ``` /Charts/Cartesian3D/SinglePrecision/Point Type Attribute: ChartDomain "Cartesian3D" Type: struct { "x" +0 native float "y" +4 native float "z" +8 native float } 12 bytes ``` ### Dimensions - **Type**: int scalar - **Value**: dimensionality of the manifold. For coordinate types: embedding dimension. For connectivity types: cell dimension (1=edge, 2=triangle, 3=tetrahedron). - **Status**: RECOMMENDED ### rank - **Type**: int scalar - **Value**: total number of tensor indices (0=scalar, 1=vector-like, 2=matrix-representable, n=nth-order tensor) - **Status**: OPTIONAL ### grade - **Type**: int scalar - **Value**: the grade k of a k-vector in geometric algebra. Grade 0 = scalar; grade 1 = tangential vector or co-vector; grade 2 = bivector or bi-co-vector; grade n = n-vector (volume form in n dimensions). Required when grade differs from rank — e.g., a bivector has rank 1 but grade 2. - **Status**: OPTIONAL; REQUIRED when grade != rank to avoid ambiguity ### covariance - **Type**: int array of length = rank - **Value**: per-index variance using Einstein notation: - `+1`: upper index (contravariant, partial_mu basis) - `-1`: lower index (covariant, dx^mu basis) For scalars (rank = 0): the `covariance` attribute is **absent**. HDF5 cannot store a zero-length array; absence of `covariance` is the normative signal for a scalar type. This is a deliberate encoding choice: the existence of the attribute carries semantic meaning (the type has at least one tensor index), not just its value. Values with |value| > 1 are reserved for future use. A possible application is encoding non-tensorial objects such as Christoffel symbols, which transform with an inhomogeneous additional term and are rank-3 but not tensors in the standard sense. Whether covariance values of ±2 are appropriate for this purpose is left open; it is noted here as a potential direction. - **Status**: OPTIONAL for scalars (absent); RECOMMENDED for all tensor and vector types From the F5 reference implementation (F5Bchart.c): ```c 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 */ ``` Mixed tensor (one upper, one lower index): `covariance[] = {+1, -1}`. ### Description - **Type**: null-terminated UTF-8 string - **Value**: human/AI-readable description of the coordinate system, type, or object - **Placement**: MAY appear on the ChartDomain group, on any chart object subgroup, or on any committed named type - **Status**: NON-NORMATIVE; advisory only; RECOMMENDED for coordinate systems whose physical meaning might be ambiguous from component names alone --- # 7. TypeInfo TypeInfo (core spec §8.5) remains necessary and is not superseded by the named type attributes of §6. It serves a distinct purpose. TypeInfo MUST be an attribute on the named datatype associated with a Field. It identifies how to interpret a Field whose data may not be in a simple contiguous dataset. In particular: - For **separated compound fields** (core spec §8.3), there is no single named datatype covering the whole compound — TypeInfo on each component's type identifies the field type that the component belongs to - For fields with **partial coverage**, TypeInfo MAY provide a default value or interpretation for uncovered regions - For **performance**: identifying a Field from its TypeInfo attribute is faster than scanning datasets; TypeInfo SHOULD therefore always be present even when it could theoretically be inferred TypeInfo MAY be omitted only when a Field consists entirely of contiguous datasets whose named type already unambiguously identifies the field. Even then, its presence is recommended. TypeInfo MUST be consistent with the named type of the Field. Inconsistency SHOULD produce a warning from validators. --- # 8. Symmetry Tables (Reserved, Encoding TBD) For symmetric and antisymmetric tensors, only a subset of components need be stored. Two attribute names are reserved for the description of which components are stored and how the rest are derived: **`symmetry_stored`**: identifies which components are stored (as indices into the full component list for the unreduced tensor). **`symmetry_derivation`**: for each component of the full tensor, a prescription for deriving it from stored components — typically `+stored[k]`, `-stored[k]`, or `0`. Symmetric 3x3 metric tensor (6 stored of 9 total): ``` Stored: [0]=dxdx [1]=dxdy [2]=dxdz [3]=dydy [4]=dydz [5]=dzdz Full 9: dxdx=+[0] dxdy=+[1] dxdz=+[2] dydx=+[1] dydy=+[3] dydz=+[4] dzdx=+[2] dzdy=+[4] dzdz=+[5] ``` Antisymmetric 3x3 bivector (3 stored of 9 total): ``` Stored: [0]=Dx^Dy [1]=Dx^Dz [2]=Dy^Dz Full 9: Dx^Dx= 0 Dx^Dy=+[0] Dx^Dz=+[1] Dy^Dx=-[0] Dy^Dy= 0 Dy^Dz=+[2] Dz^Dx=-[1] Dz^Dy=-[2] Dz^Dz= 0 ``` These attribute names are RESERVED. Their HDF5 encoding format is not yet normatively defined. Implementations MUST NOT use these attribute names for other purposes. A future sub-extension will define the encoding. --- # 9. Type Examples These examples illustrate the naming and attribute pattern. They do not constitute a catalogue — F5 Charts are open-ended (§2.1). ## 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. --- # 10. Open Questions and Future Work **Christoffel symbols and non-tensorial objects:** Christoffel symbols are rank-3 objects that do not transform as tensors (they acquire an inhomogeneous term under coordinate changes). The current attribute scheme does not accommodate this. A possible direction is to use covariance values with |value| > 1 as a signal for non-tensorial transformation behaviour. This is explicitly left open for future work. **Newman-Penrose pseudo-scalars:** The five complex NP scalars (psi_0 through psi_4) characterizing gravitational waves carry spin weight and boost weight. These are pseudo-scalar quantities with specific algebraic properties under the NP tetrad transformations. It is believed that the current attribute scheme (rank, grade, covariance) is sufficient to model these quantities within the F5 framework, but this has not yet been worked out in detail. It is not claimed that NP scalars cannot be expressed — rather, their precise encoding within this scheme is an open derivation. **Transformation rule encoding:** The covariance array determines the *form* of the transformation rule (Jacobian or inverse Jacobian). The *content* — specific matrices for linear charts, trigonometric functions for curvilinear charts — is not yet normatively encoded in chart objects. This is the most significant gap for applications requiring cross-chart field evaluation. **Symmetry attribute encoding:** The conceptual framework of §8 is defined; the HDF5 encoding format is reserved for a future sub-extension. --- # 11. Summary of Normative Elements | Element | Status | |----------------------------------------------------------|-----------------| | ChartDomain group with precision subgroups (§3.1) | Normative | | Point soft link at ChartDomain level (§3.1) | Normative | | Chart object subgroup with Coordinates link (§3.2) | Normative | | Local chart object GlobalChart link (core spec §6.1.2) | Normative | | Minimalism: only used types committed (§2.2) | SHOULD | | Coordinate member names: simple convention (§4.2) | Recommended | | Dx/dx naming for tangential/co-vector types (§5.1) | Recommended | | ^ separator in exterior product names (§5.2) | Required | | dxdy for symmetric metric, dx^dy for bivector (§5.2/5.3) | Required | | Simplex barycentric naming {ii, ij, jj...} (§5.4) | Recommended | | ChartDomain attribute on committed types (§6.3) | REQUIRED | | Dimensions attribute (§6.3) | Recommended | | rank attribute (§6.3) | Optional | | grade attribute (§6.3) | Required when grade != rank | | covariance int array {+1/-1} (§6.3) | Absent=scalar; Recommended for tensor types | | Description advisory string (§6.3) | Non-normative | | TypeInfo on named datatypes (§7) | SHOULD always be present | | symmetry_stored attribute name (§8) | Reserved | | symmetry_derivation attribute name (§8) | Reserved | --- # 12. Literature and Conceptual Background **GraVisMa 2009 (primary reference for §6):** Benger, W., Hamilton, A., Folk, M., Koziol, Q., Su, S., Schnetter, E., Ritter, M., Ritter, G.: "Using Geometric Algebra for Navigation in Riemannian and Hard Disc Space." In: Skala, V., Hildenbrand, D. (eds.) *GraVisMa 2009 — Computer Graphics, Vision and Mathematics for Scientific Computing*, pp. 80–89. UNION Agency, Na Mazinach 9, CZ-322 00 Plzen, Czech Republic, 2010. Conference: University of West Bohemia, Plzen (Pilsen), Czech Republic, September 2–4, 2009. Proceedings PDF: http://gravisma.zcu.cz/GraVisMa-2009/Papers_2009/!_2009_GraVisMa_proceedings-FINAL.pdf Section §5 of that paper defines the meta-information properties implemented here: multiplicity, rank, grade, dimensions, coordinatename, covariance. **PhD thesis (foundational F5 data model):** Benger, W.: "Visualization of General Relativistic Tensor Fields via a Fiber Bundle Data Model." Dissertation, Fachbereich Mathematik und Informatik, Freie Universität Berlin / Zuse-Institut Berlin (ZIB), August 2004. Published: Berlin, Lehmanns Media-LOB.de, 2005. ISBN 3-86541-108-8. Supervisor: Prof. Dr. Peter Deuflhard. https://www.fiberbundle.net/papers/TensorFieldViz.pdf **Reference implementation:** F5Bchart.c, FiberBundleHDF5 library (FiberLib v2). https://www.fiberbundle.net/doc/F5Bchart_8c_source.html The covariance array encoding {+1/-1} and the `F5B_init_tangential_types` function establish the actual committed type structure implemented in HDF5. **Original fiber-bundle data model concept:** Butler, D.M., Bryson, S.: "Vector Bundle Classes make Powerful Tool for Scientific Visualization." *Computers in Physics* 6(6), pp. 576–584 (1992). Implemented in IBM Data Explorer / OpenDX. The simplex naming scheme (§5.4) and the Dx/dx convention (§5.1) are original contributions of this specification. --- # **End of Part 1** ---