Package architecture¶
Project overview · Python API · Development
The CLI and Python entrypoints share the same generation, reading, validation, and publication functions.
flowchart TD
A["CLI and Python API"] --> G["Generation and finalization"]
A --> V["Reading and validation"]
A --> H["Hugging Face publishing"]
G --> S["Building simulation"]
G --> F["Filesystem and provenance"]
V --> F
H --> V
H --> F
Module responsibilities¶
Module |
Responsibility |
|---|---|
|
Validated immutable parameters and planning arithmetic |
|
Indexed random streams and split assignment |
|
Building dynamics, sensing, action assignment and potential outcomes |
|
Arrow schemas, units and feature roles |
|
Streaming file hashes and atomic writes |
|
Source/runtime fingerprints and run configuration |
|
File paths, expected counts and shard completion checks |
|
Shared generation and exclusive snapshot leases |
|
Bounded worker scheduling, shard writing and finalization |
|
Manifest verification and paired batch iteration |
|
Identity, trajectory, logging, domain and outcome checks |
|
Validation reports, scan coordination and replay |
|
Dataset metadata and packaged documentation |
|
Publication intent, upload, remote verification and completion |
|
Clustered one-step policy estimates |
|
Temperature-model training and evaluation |
|
Trusted Python notebook execution and saved outputs |
|
Command-line interface and package version |
Generation lifecycle¶
Initialization commits the configuration and schema documents. Generation assigns whole building ranges to shards, simulates bounded batches, and writes the logged and oracle partitions. A per-shard state file is committed after all files are closed, flushed, renamed, and hashed. Finalization verifies every expected shard and creates the manifest and completion marker.
At most twice the worker count is queued in the process pool. A rank with no assigned shards returns an empty summary. Worker count is capped by assigned work. Child processes initialize their own Arrow pools and maintain a generation lease for the duration of each write.
Reading and validation¶
Manifest checks establish expected paths, counts, schemas, sizes, and hashes. Paired readers then iterate matching Parquet files in numeric shard order. Record checks are grouped by identity, trajectory continuity, logging policy, physical parameter domains, and outcomes. Only the final row of the previous batch is kept for continuity checks.
Validation records a running status before scanning and writes the final result atomically. Exact replay regenerates one building at a time. Validation acquires one exclusive lease for the entire operation; internal helpers operate under that lease.
Publication lifecycle¶
The publisher validates a stable local release, binds publication intent to its metadata hashes, uploads the payload, verifies the immutable remote file tree, and commits the completion marker. Retries use the same repository, branch, and release binding. Parent-commit checks protect publication steps from branch changes.
Repository layout¶
Directory |
Contents |
|---|---|
|
Installable package |
|
Small clients for loading, prediction and policy evaluation |
|
Scientific, integrity, recovery, publication and CLI tests |
|
Operations and API guides plus the column reference |
|
Executed sample walkthrough |
|
Documentation, notebook and distribution checks |
|
Reproducible measurement commands |
|
Ready-to-load sample release |
The package version is defined in _version.py and read by the build backend.
Source distributions include package code, tests, examples, guides, and notebooks.
The sample is included in the repository but excluded from built distributions.
Runtime environments, caches, experiment reports, and build outputs are also
excluded from the source archive.