Input and output formats

This section is the normative data-contract reference for Quantas. It defines what each workflow reads, which values are normalized before calculation, what is stored in native HDF5 files, and which information is preserved in reports and tabular exports.

The pages are organized in three groups.

Input contracts

Elasticity and SEISMIC text input describes the shared Elasticity/SEISMIC stiffness text format.
HA and QHA phonon YAML defines the normalized HA/QHA phonon YAML contract.
EOS text input and EOS batch specification separate EOS measurements from the fitting plan.
Thermoelastic input defines the normalized volume-dependent elastic series used by the quasi-static thermoelastic workflow.
Earth pressure-temperature profile specification defines tabulated and composed depth–pressure– temperature paths.

Native result contracts

Native HDF5 results defines the common Quantas envelope.
HA and QHA native HDF5 payloads documents HA and QHA payloads.
Elasticity and SEISMIC native HDF5 payloads documents Elasticity and SEISMIC payloads.
EOS native HDF5 archive documents the session-capable EOS archive.
Thermoelastic HDF5 payload documents calibration, grid, and profile payloads.
Inspecting and extracting native HDF5 data shows how to inspect and extract native files from Python without relying on terminal output.

Human-readable outputs

Tabular exports, reports, and plot files explains deterministic reports, CSV and text exports, plot files, units, missing values, and the distinction between stored precision and displayed precision.

General rules

File extensions are conveniences, not scientific type identifiers. Native HDF5 readers inspect metadata; text readers inspect the declared format.
Numerical input is normalized to float64 before scientific calculation.
Unit labels and normalization bases are part of the data contract and must be read together with numerical arrays.
Native HDF5 is the authoritative machine-readable result. Reports, CSV files, and figures are derived views.
Unknown schema versions or incompatible units must be rejected rather than guessed.
Historical pre-release files are read only through explicit migration paths implemented by the responsible module.