GALAXY v0.7.0–v0.8.0: Barnes–Hut Self-Gravity, Parallel GPU Tree Construction, and Hardware Evidence Harness

Abstract

# GALAXY v0.7.0–v0.8.0 GALAXY v0.7.0–v0.8.0 records two consecutive milestones in the development of GALAXY's resident Barnes–Hut self-gravity execution family. Version v0.7.0 established the correctness-first Barnes–Hut self-gravity and GPU tree-construction foundation. It introduced deterministic resident N-body self-gravity, independent direct-force verification, Morton-ordered flat-tree representations, GPU force traversal, persistent multi-step GPU evolution, and GPU-side Barnes–Hut tree construction. Version v0.8.0 advances that foundation to the BH #2D parallel GPU tree-construction phase and adds a fail-closed framework for future real-hardware scaling evidence. It also promotes the planar Barnes–Hut N-body simulator to the default GALAXY browser experience while preserving the previous prescribed-field rotation-law instrument separately. ## v0.7.0 — Barnes–Hut Self-Gravity and GPU Tree Construction GALAXY v0.7.0 introduced a separate resident self-gravity execution family in which all bodies participate in the mutually coupled gravitational system. The implementation includes: - deterministic planar Barnes–Hut self-gravity;- classical Barnes–Hut opening control;- Plummer-style gravitational softening;- kick–drift–kick leapfrog evolution;- deterministic disc and collision fixtures;- an independent O(N²) direct-force oracle;- bounded deterministic direct-force probes;- recursive CPU Barnes–Hut reference execution;- a Morton-ordered flat f64 CPU representation;- stable spatial ordering;- deterministic topology checksums;- explicit GPU transfer records;- Vulkan/WGSL Barnes–Hut force traversal;- persistent GPU-resident position, velocity, mass and acceleration state;- multi-step GPU self-gravity evolution;- bounded full-trajectory comparison against the f64 CPU reference;- GPU-side tree construction for BH #2C;- zero host particle readbacks during BH #2C evolution steps;- zero CPU tree rebuilds during BH #2C evolution steps;- deterministic repeated-tree checksum validation. The BH #2C builder in v0.7.0 is deliberately correctness-first. Its control-heavy tree-construction stages establish the device-ownership and scientific-validation boundary required before scalable parallel tree construction and hardware benchmarking. ## v0.8.0 — Parallel GPU Barnes–Hut Construction GALAXY v0.8.0 implements BH #2D, a separate parallel GPU tree-construction path. The BH #2D builder includes: - workgroup-parallel root-bounds reduction;- parallel Morton-code generation;- eight stable 4-bit LSD radix passes;- deterministic sparse level-order cells;- parallel range construction;- parallel topology construction;- reverse-depth parallel mass and centre-of-mass aggregation;- resident workloads up to 65,536 bodies;- a separate `galaxy-bh-gpu-tree-parallel` executable and verifier. The frozen tree representation is declared as: **Ordering** ```textstable-lsd-radix-4bit-morton-code; resident body index retained for equal Morton keys``` **Layout** ```textsparse-level-order-slot=depth*N+group_start``` These declarations are validated as part of the receipt contract. ## Executable Correctness Ladder BH #2D retains the earlier implementations as executable reference surfaces rather than replacing them. The validation ladder includes: - BH #2A flat f64 CPU Barnes–Hut reference;- BH #2B2 host-built evolving GPU path;- BH #2C serialized GPU tree builder;- bounded exact direct-force probes;- full trajectory comparisons where workload limits permit them. Large workloads explicitly record bounded-oracle skips rather than hiding expensive CPU work inside GPU performance measurements. ## Real-Hardware Evidence Harness Version v0.8.0 adds a fail-closed hardware-evidence harness: ```textscripts/bench-bh2d-hardware.py``` Real evidence capture is launched through dedicated clean-environment wrappers. **POSIX** ```bashsh scripts/bench-bh2d-hardware-launch.sh``` **Windows** ```textscripts\bench-bh2d-hardware-launch.cmd``` The default resident-body sweep covers: - 512- 1,024- 2,048- 4,096- 8,192- 16,384- 32,768- 65,536 The harness executes the BH #2D verifier with `--require-hardware` and binds accepted evidence to: - one Git source revision;- one GPU adapter identity;- enumerated adapter count;- GPU backend and device type;- workload parameters;- Cargo identity;- rustc identity;- compiler and linker identities;- executable hashes;- Cargo configuration;- dependency-source tree hashes;- Python executable identity;- receipt SHA-256 hashes;- raw run-log SHA-256 hashes;- benchmark samples;- correctness invariants;- deterministic tree invariants. The hardware scaling manifest schema is: ```textgalaxy.bh2d-hardware-scaling-manifest.v1``` ## Provenance and Fail-Closed Validation The v0.8.0 evidence path was subjected to extensive adversarial review. The resulting contract includes: - clean-environment process launch;- isolated Python execution;- Linux-, macOS- and Windows-aware tool provenance;- recorded and hashed Cargo, rustc, compiler and linker binaries;- rejection of loader-injection environment variables;- rejection of Vulkan ICD, layer and driver overrides;- rejection of Cargo/Rust compiler and wrapper overrides;- source-revision binding;- explicit Git checkout binding;- disabled Git replacement objects;- raw tracked-byte validation against Git index blobs;- executable-mode validation;- Cargo configuration validation;- dependency-source tree hashing;- dependency file-type and permission-mode hashing;- registry/Git dependency hashing regardless of cache location;- strict UTF-8 JSON parsing;- rejection of duplicate JSON object keys;- rejection of non-standard NaN and infinity constants;- integer-type enforcement for execution counters;- hardware/software adapter classification checks;- adapter index/count consistency;- Rust-compatible numeric-versus-text adapter selection semantics;- allowed GPU backend validation;- frozen tree representation declarations;- topology fan-out checks;- bucket occupancy checks;- per-depth quadtree occupancy checks;- shared root-to-leaf path-capacity checks;- force-error consistency checks;- trajectory state-error consistency checks;- benchmark sample and median recomputation;- failure-manifest retention. Failed or unusable verifier runs retain cryptographically bound diagnostics. The manifest records the raw run-log path and SHA-256, and records the receipt path and SHA-256 whenever a receipt artifact exists. ## Browser N-Body Simulator Version v0.8.0 also makes the planar resident Barnes–Hut N-body simulator the default browser entrypoint. The default scene contains 768 mutually interacting bodies, with selectable resident populations from 128 to 2,048. The browser interface provides: - binary encounter preset;- rotating-disc preset;- cold-collapse preset;- pause and resume;- deterministic single-step;- seed control;- orbit and zoom controls;- Barnes–Hut tree overlay;- direct-force auditing;- glow sprites;- short trajectory-history trails;- reduced-motion handling;- hidden-tab suspension;- fixed-rate physics independent of monitor refresh rate. Physics uses a fixed 60 Hz schedule. Overload drops excess catch-up work rather than enlarging the physical timestep. The previous prescribed-field rotation-law application is preserved at: ```textrotation-lab.html``` The detailed Barnes–Hut laboratory remains available at: ```textbarnes-hut.html``` ## Validation The v0.7.0 and v0.8.0 implementation sequence was validated through repository CI and deterministic reference checks including: - Rust Barnes–Hut unit and integration tests;- CPU direct-force comparison;- CPU flat-tree verification;- GPU transfer ABI validation;- Vulkan/WGSL Barnes–Hut execution;- CUDA source/layout parity checks;- persistent-state GPU evolution;- GPU-side tree construction;- BH #2D parallel-tree contract tests;- source and dependency provenance tests;- clean-launch validation;- native Windows launcher failure propagation;- browser N-body integration tests;- refresh-rate invariance;- pause and single-step behavior;- visibility handling;- reduced-motion handling;- native CPU runtime validation;- retro CPU portability;- CPU memory-wall validation;- host-auto execution validation. Software Vulkan is used in CI as correctness and integration evidence only. ## Scientific and Performance Claim Boundary This joint record does not claim measured real-GPU performance or production-quality BH #2D scaling. In particular, it does not claim: - measured hardware GPU speedup;- production promotion of BH #2D;- multi-GPU Barnes–Hut partitioning;- distributed deterministic tree construction;- logical-u64 mutually interacting self-gravity;- hydrodynamics;- gas evolution;- star formation;- a complete evolving baryonic/dark-matter density model. A completed real-hardware BH #2D scaling manifest remains a separate evidence milestone. Future hardware-performance claims are intended to apply only to the source revision, host, toolchain, dependency tree, GPU adapter, workload and benchmark samples recorded in that manifest. ## Version Relationship This Zenodo record jointly documents the consecutive GALAXY v0.7.0 and v0.8.0 development milestones. **v0.7.0** establishes the GPU Barnes–Hut correctness and device-tree-construction baseline. **v0.8.0** extends that baseline with parallel GPU tree construction, a hardened hardware-evidence capture contract, and the default browser N-body simulator. ## Current Software Releases **GALAXY v0.7.0** https://github.com/QSOLKCB/GALAXY/releases/tag/v0.7.0 **GALAXY v0.8.0** https://github.com/QSOLKCB/GALAXY/releases/tag/v0.8.0 ## Source Repository https://github.com/QSOLKCB/GALAXY