AOT Block Design for AO Telemetry
- AOT Block Design is a standardized layout for adaptive optics telemetry within FITS files, organizing both metadata and large time-series arrays.
- It employs fixed-header binary table blocks and image extensions with UID cross-references to enable automated parsing and robust data linkage.
- The design supports advanced workflows such as atmospheric turbulence estimation and PSF reconstruction through precise time synchronization and standardized array dimensions.
An AOT (Adaptive Optics Telemetry) block design is a standardized, explicit block-structured layout for exchanging all metadata, configuration, and large time-series telemetry arrays generated by adaptive optics (AO) systems in visible/infrared astronomical observatories. Originating from the proposal and definition of the AOT format as a new data exchange standard, it encapsulates both high-level descriptive information and the primary telemetry signals within a single FITS file, using a fixed sequence of binary-table blocks (“HDUs”) followed by numerous named image extensions. The structuring of AOT blocks is optimized for unambiguous, automated parsing in research workflows targeting advanced performance analytics, including atmospheric turbulence parameter estimation and point-spread function (PSF) reconstruction (Gomes et al., 2023).
1. Fundamental File Structure and Block Sequence
AOT block design adopts the Flexible Image Transport System (FITS) as its container format, imposing a strict sequence of Header Data Units (HDUs) that partition file content into thematic blocks. The initial segment consists of one primary header (HDU 0), followed by a detailed chain of binary tables (HDU 1–17), each assigned a specific EXTNAME. These binary tables encode descriptive metadata, relational links, parameter lists, and row-referenced cross-indices.
Binary-table blocks are followed by a variable number of image extensions (HDU 18 onward), each containing a multi-dimensional array of telemetry or calibration data. These images are referenced by string keys from one or more table columns, providing logical indirection between metadata and bulk telemetry.
| HDU Index | Block (EXTNAME) | Role |
|---|---|---|
| 0 | Primary Header | File metadata, no array |
| 1–17 | BINTABLE HDUs (AOT_TIME, …, AOT_LOOPS_OFFLOAD) | Structured metadata, cross-refs |
| 18+ | IMAGE HDUs | Large arrays: pixel/frame/slopes |
Time-dependent signals (e.g., wavefront sensor arrays, actuator commands) are stored exclusively in IMAGE HDUs, indexed to the common timing block (AOT_TIME) (Gomes et al., 2023).
2. Block Roles and Data Linking Mechanisms
Each block in an AOT design supports a well-defined, schema-documented role. The binary-table blocks include descriptors for time axes, atmospheric parameters, telescope/instrument configuration, wavefront sensors/correctors, detectors, science sources, and various loop-control constructs.
Numerous columns in these tables serve as foreign keys, referencing both other table rows (typically via unique string “UID”) and image extensions (via the EXTNAME of the target IMAGE HDU). This indirection decouples large array storage from small relational descriptions and maintains referential clarity across a complex AO telemetry set.
Among the canonical blocks:
- AOT_TIME: global time axis, provides alignment for all time-series arrays; columns: UID, TIMESTAMPS, FRAME_NUMBERS.
- AOT_ATMOSPHERIC_PARAMETERS: stores r0, seeing, τ0, θ0, and per-layer profiles; references images for profiles and transformation matrices.
- AOT_WAVEFRONT_SENSORS/SHACK_HARTMANN/PYRAMID: WFS geometry, metadata, references MEASUREMENTS arrays.
- AOT_DETECTORS: camera geometry and hardware fields, links to pixel data in image arrays.
- AOT_LOOPS/CONTROL/OFFLOAD: links sensors/correctors to control matrices, commands, modal coefficients, interaction matrices, and relevant time axes.
Arrays within IMAGE HDUs always either represent single-valued metadata (e.g., masks) or time-series aligned to the AOT_TIME referenced time axis.
3. Array Dimensions and Sizing Conventions
Array sizing in AOT block design is standardized across all instrumentation. Each multi-dimensional array includes explicit dimension labels:
- : length of TIMESTAMPS in relevant AOT_TIME row
- : number of validated WFS subapertures
- : number of dimensions measured per subaperture (usually 2)
- : number of valid actuators on a DM
Representative array shapes:
- WFS MEASUREMENTS:
- DM COMMANDS:
- CONTROL_MATRIX:
- INFLUENCE_FUNCTION:
All time-dependent arrays are required to share for each logical group, enforced via the TIME_UID link. This uniformity facilitates programmatic telemetry mining and batch analysis (Gomes et al., 2023).
4. Read/Write Semantics and Logical Flow
AOT block design explicitly separates instrument metadata (geometry, configuration, static aberrations) and time-series telemetry (measured slopes, DM commands, etc.). Automated ingestion routines process the binary-table HDUs first, building an in-memory object model via UID references, and then dynamically load the required IMAGE HDUs by EXTNAME.
Pseudocode for readout:
1 2 3 4 5 6 7 |
open FITS file read HDU0 → primary_header for each BINTABLE in HDUs 1…17: parse and cross-ref UIDs, image-refs for each referenced IMAGE HDU: load multi-dim arrays bind to corresponding meta rows |
This approach guarantees that all time-series telemetry is directly accessible, with unambiguous synchronization to frame times and complete relational provenance. Metadata (e.g., camera layout, mask geometry) lives in small tables and single-frame image blocks; telemetry resides in large IMAGE HDUs indexed temporally.
5. Tailoring for Turbulence Estimation and PSF Reconstruction
The AOT block design is driven by the requirements of (1) atmospheric turbulence parameter estimation and (2) PSF-R. Turbulence diagnostics (e.g., , , layer wind speeds) are provided as either direct time-series in AOT_ATMOSPHERIC_PARAMETERS or back-computable from WFS and DM telemetry arrays with known control matrices and filters.
For PSF reconstruction:
- Modal and zonal representations are both supported via the presence of MODES/COEFFICIENTS and INFLUENCE_FUNCTION/COMMANDS arrays, respectively.
- Static and dynamic aberration terms are referenced uniquely by ABERRATION_UID and NCPA_UID, with clear cross-links.
- All necessary calibration (e.g., control, interaction, and transfer matrices) are stored in standardized shapes.
Time and configuration alignment for all block-structured content ensures algorithmic workflows—such as phase screen construction, open/closed-loop state analysis, or empirical PSF validation—are fully supported without reformatting or guessing array provenance (Gomes et al., 2023).
6. Design Principles and Scalability
AOT block design mandates:
- A fixed primary table chain for all files, guaranteeing every instrument and dataset adheres to a documented minimum schema, even if some tables are sparse.
- No assumptions about AO system specifics; supports natural/laser guide stars, Shack-Hartmann/Pyramid WFS, multiple DMs, and flexible calibration.
- All arrays in IMAGE HDUs named by EXTNAME, so generic FITS parsers function seamlessly across diverse datasets.
- Time synchronization enforced via explicit row-references—each time-varying IMAGE must be traceable to one AOT_TIME row by TIME_UID.
This approach achieves long-term interoperability, transparency, and efficient data mining for increasingly large-scale AO telemetry archives.
7. Use-Case-Driven Extensions and Logical Schematic
The logical representation of the AOT block design is as follows:
1 2 3 4 5 6 7 8 9 10 11 12 |
[Primary HDU]
↓
[AOT_TIME] ← anchors t
↓
[AOT_ATMOSPHERIC_PARAMETERS] → R0(t), … → image LAYERS_WEIGHT(layers)
↓
[... metadata tables ...]
↓
[AOT_LOOPS_CONTROL] → image MODAL_COEFFICIENTS(m×t)
CONTROL_MATRIX(s_v×d×a_v)
↓
[Images ... time-series ...] |
All control, configuration, and measurement blocks are discoverable and directly cross-referenced. This enables robust, lossless conversion of raw observatory data as well as derived products, maintaining full scientific traceability while simplifying the ingestion pipeline for complex analysis (Gomes et al., 2023).