GALAXY v0.8.0 — Parallel GPU Barnes–Hut Construction and Hardware Evidence Harness

GALAXY v0.8.0 advances the resident Barnes–Hut self-gravity programme from the correctness-first GPU tree builder frozen in v0.7.0 to a parallel BH #2D construction path, while adding a fail-closed framework for capturing future real-hardware scaling evidence.

This release also promotes the browser’s planar Barnes–Hut N-body simulator to the default GALAXY landing experience while preserving the original rotation-law instrument separately.

Release identity

Version:          v0.8.0
Source commit:    e051324b1263f20ebb88d0e585992c7c1838504a
Previous release: v0.7.0
Previous commit:  7fe4dc63d40bb4afbb93f51c07d05b49f21e9756
Merged PR:        #24

v0.8.0 contains 107 commits beyond the v0.7.0 release boundary.

BH #2D — Parallel GPU tree construction

The principal compute milestone is a new parallel GPU Barnes–Hut tree builder.

Added:

• workgroup-parallel root-bounds reduction;
• parallel Morton-code generation;
• eight stable 4-bit LSD radix passes;
• deterministic sparse level-order cells;
• parallel range and topology construction;
• reverse-depth parallel mass and centre-of-mass aggregation;
• a separate galaxy-bh-gpu-tree-parallel verifier;
• resident workloads up to 65,536 bodies for the BH #2D path.

The frozen tree representation uses:

ordering:
stable-lsd-radix-4bit-morton-code;
resident body index retained for equal Morton keys

layout:
sparse-level-order-slot=depth*N+group_start

Those representation declarations are now validated as part of the evidence contract rather than treated as descriptive metadata.

Existing Barnes–Hut paths remain executable oracles

BH #2D does not replace the earlier correctness ladder.

The release retains:

• BH #2A flat f64 CPU reference;
• BH #2B2 host-built evolving GPU path;
• BH #2C serialized device-side tree builder;
• bounded exact direct-force probes.

For workloads within the configured oracle limits, the parallel builder is checked against these frozen reference surfaces.

Large workloads explicitly record oracle skips rather than hiding expensive CPU work inside benchmark measurements.

Real-hardware evidence harness

Added:

scripts/bench-bh2d-hardware.py

The harness performs a source-pinned resident-body scaling sweep through the BH #2D executable using --require-hardware.

The default sweep covers:

512
1024
2048
4096
8192
16384
32768
65536

Each accepted run is bound to:

• one Git revision;
• one selected GPU identity;
• the enumerated adapter count;
• GPU backend and device type;
• Cargo and rustc identities;
• compiler/linker/tool hashes;
• Cargo configuration;
• dependency-source hashes;
• workload parameters;
• receipt hashes;
• raw run-log hashes;
• benchmark samples;
• correctness and topology invariants.

The resulting manifest schema is:

galaxy.bh2d-hardware-scaling-manifest.v1

Fail-closed provenance hardening

The hardware-evidence path received extensive adversarial review and now fails closed across source, build, loader, receipt and topology boundaries.

Clean launch boundary

Real evidence capture must begin through a dedicated clean launcher.

POSIX:

sh scripts/bench-bh2d-hardware-launch.sh \
  --output runs/bh2d-hardware-sweep \
  --adapter 0

Native Windows:

scripts\bench-bh2d-hardware-launch.cmd ...

The POSIX launcher starts isolated Python through a newly constructed environment rather than trusting loader variables visible after Python has already started.

Direct evidence capture through the Python file is rejected.

The manifest records the Python executable and its SHA-256 together with:

launch_boundary = clean-environment-launcher-v1

Platform-aware toolchain provenance

The earlier Unix-only tool assumption has been replaced by platform-specific tooling.

Linux and macOS record their native compiler/linker/Git tools.

Windows supports the active MSVC/LLVM environment without requiring a POSIX cc, while selected tools are resolved, hashed and used to construct the narrowed build PATH.

Native Windows CI also verifies that launcher failures propagate the Python process exit status correctly.

Build-environment isolation

Evidence capture rejects or removes build-affecting environment controls including:

• LD_* loader injection;
• the DYLD_* namespace;
• Vulkan ICD, driver and layer overrides;
• additive Vulkan driver/layer paths;
• Vulkan loader enable/disable selectors;
• Rust and Cargo compiler/wrapper overrides;
• target-specific linker/runner flags;
• Cargo profile overrides;
• C/C++ compiler and linker flags.

Dependency-source binding

Cargo dependency trees are fingerprinted independently of their physical cache location.

Registry and Git dependencies remain hashed even if CARGO_HOME is located beneath the repository checkout.

Dependency fingerprints include:

• relative path;
• file type;
• permission/mode bits;
• file contents.

Executable-bit changes therefore alter the dependency tree fingerprint.

Git and source-tree provenance

The harness:

• binds Git operations to the explicit checkout;
• disables replacement objects;
• rejects index flags that could conceal changes;
• compares raw tracked bytes against index blobs;
• detects executable-mode changes;
• rejects unexpected compiler-affecting files;
• validates effective Cargo configuration;
• checks source and toolchain provenance throughout the sweep.

Strict receipt validation

BH #2D receipts now undergo substantially stronger structural validation.

Checks include:

• strict UTF-8 JSON;
• rejection of NaN and infinity constants;
• rejection of duplicate JSON object names;
• integer-type enforcement for counters;
• workload binding;
• hardware measurement classification;
• adapter index/count consistency;
• numeric and textual adapter selector parity with the Rust producer;
• allowed backend set: Vulkan, Metal or DX12;
• software-adapter detection;
• driver provenance;
• zero host tree rebuilds;
• zero host particle readbacks during evolution;
• force-solve and tree-build counts;
• tree checksums;
• frozen ordering and layout declarations;
• leaf/internal-cell fanout constraints;
• per-depth occupancy constraints;
• bucket-size constraints;
• shared root-to-leaf path capacity;
• force-error RMS/max consistency;
• state-error zero/nonzero consistency;
• benchmark sample and median recomputation;
• BH #2C comparison/skip boundaries;
• exact BH #2D allocation formula.

Failed verifier runs retain cryptographically bound diagnostics.

A failed manifest records the run log path and SHA-256, and when an unusable receipt exists its path and hash are retained as well.

This also applies when the verifier exits successfully but emits a missing, malformed or validator-rejected receipt.

Browser N-body home page

index.html is now the default interactive planar Barnes–Hut N-body simulator.

The default scene uses 768 mutually interacting resident bodies, with selectable populations from 128 to 2,048.

The browser experience includes:

• binary encounter, rotating-disc and cold-collapse presets;
• pause and resume;
• deterministic single-step;
• seed control;
• orbit and zoom controls;
• Barnes–Hut tree overlay;
• direct-force auditing;
• glow sprites and short trajectory trails;
• reduced-motion handling;
• hidden-tab suspension;
• refresh-rate-independent physics.

Physics advances on a fixed 60 Hz schedule rather than using display refresh as the simulation clock.

Overload drops excess catch-up work instead of enlarging the physical timestep.

Preserved browser instruments

The previous prescribed-field rotation-law application remains available at:

rotation-lab.html

The detailed Barnes–Hut laboratory remains at:

barnes-hut.html

This keeps the historical rotation-law interface available while allowing the resident N-body simulator to become GALAXY’s default browser entrypoint.

Validation

The merged implementation passed the relevant repository validation surfaces, including:

• native Rust runtime tests;
• Barnes–Hut CPU and GPU reference validation;
• BH #2D host-side contract tests;
• clean-launch dry-run validation;
• native Windows launcher failure propagation;
• Python 3.13 and 3.14 runner checks;
• browser N-body integration tests;
• refresh-rate invariance;
• pause/single-step behavior;
• visibility and reduced-motion timing;
• static Pages distribution checks;
• native CPU runtime;
• CPU host-auto promotion;
• retro CPU portability;
• CPU memory-wall validation.

The Native GPU CI path also executes the Barnes–Hut stack through software Vulkan for correctness validation.

Evidence boundary

This release does not claim measured hardware GPU speedup.

Software Vulkan remains correctness and integration evidence only.

The new harness establishes the machinery required to collect defensible real-GPU evidence, but a completed real-hardware manifest has not yet been produced as part of this release.

Therefore:

• BH #2D parallel construction is implemented;
• its correctness/provenance contract is frozen;
• real-hardware scaling evidence remains pending;
• BH #2E production promotion remains a separate decision.

A completed future hardware manifest will support claims only for its recorded:

• source revision;
• host;
• toolchain;
• dependency tree;
• adapter;
• workload;
• benchmark samples.

What remains deliberately deferred

This release does not claim:

• production-quality BH #2D performance;
• measured real-GPU speedup;
• multi-GPU Barnes–Hut partitioning;
• deterministic distributed tree construction;
• logical-u64 mutually interacting self-gravity;
• hydrodynamics;
• gas evolution;
• star formation;
• a full evolving baryonic/dark-matter density model.

The historical prescribed-field PE #15 deferred programme also remains separate from the resident Barnes–Hut line.

Next phase

The next evidence milestone is to execute the frozen BH #2D harness on real GPU hardware and retain the resulting scaling manifest.

That evidence can then support BH #2E evaluation without changing the already-reviewed capture contract.

The governing rule remains:

correctness and provenance first; performance claims only after the measured implementation earns them.