FE-1546: Stream range sweeps as one stochastic simulation - #9419
Draft
kube wants to merge 2 commits into
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
1 Skipped Deployment
|
This was referenced Aug 28, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
🌟 What is the purpose of this PR?
A sweep's range selection sharded the region into quantized grid points and computed one small batch per point — slow (a scenario compile and batch per point, breadth-first leveling) and not what a range means. A range selection now runs as one stochastic simulation over the ranges: every run draws its own value per ranged parameter, the whole worker pool computes it, and the metric distribution over the region streams from the first frames.
🔗 Related links
🔍 What does this change?
sweep-session.tsrebuilt around selections: a point runs at its value (ladder, GPU-eligible, unchanged); a range emits one batch per ladder rung whoserunscarry per-run parameter values (sweepRangeRuns) — drawn continuously inside the selected value interval (the slider's quantized positions bound the interval, they do not grid it), low-discrepancy per axis and prefix-stable in the global run index, so a rung extends the exact sequence earlier rungs drew and the cache never goes stale. The cache keys whole selections; a point is a degenerate range, so the surface's per-point sampling shares it.ExperimentRequest.runs: per-run overrides now flow through the backend layer; the simulator, the experiment runtime, and per-shard slicing already supported them. The worker-pool backend forwards them; the WebGPU backend explicitly refuses requests with per-run values (its shader bakes parameters in) with a clear blocker.14 sweep-session tests pin the new contract: one batch per rung with drawn runs inside the value bounds, prefix stability across rungs, point selections sending no per-run values, range revisits resuming mid-ladder with the identical drawn sequence, and distinct selections caching apart.
Pre-Merge Checklist 🚀
🚢 Has this modified a publishable library?
This PR:
@hashintel/petrinaut,@hashintel/petrinaut-core; patch changeset included)📜 Does this require a change to the docs?
The changes in this PR:
🕸️ Does this require a change to the Turbo Graph?
The changes in this PR:
🤖 Generated with Claude Code