test: Seeding benchmarks on the synthetic event - #5808
Draft
andiwand wants to merge 4 commits into
Draft
Conversation
github-actions
Bot
added
Component - Fatras
Contributor
andiwand
force-pushed
the
test-fatras-synthetic-seeding-benchmarks
branch
3 times, most recently
from
August 1, 2026 06:27
69f2017 to
47aa377
Compare
Contributor
Public API surface diff+194 added, 0 breaking. ➕ Added public APINew types / aliases / enums / variables / concepts (27)
New call signatures (incl. defaulted-arg overloads) (42)
New public data members (125)
|
andiwand
force-pushed
the
test-fatras-synthetic-seeding-benchmarks
branch
6 times, most recently
from
August 5, 2026 09:11
6c96fe8 to
aa6b150
Compare
andiwand
force-pushed
the
test-fatras-synthetic-seeding-benchmarks
branch
3 times, most recently
from
August 6, 2026 13:16
27423c3 to
f98e36d
Compare
`ActsFatras::Synthetic` is a second, much smaller fast simulation that shares none of the Fatras machinery: no tracking geometry, no propagator, no input data. It fills an `Acts::SpacePointContainer` directly and makes an ATLAS-like pile-up of 200 in tens of milliseconds, which is what a seeding benchmark needs and what the propagator-based simulation cannot provide. Space points carry the layer and the particle they came from, so a caller needs no truth matching. The geometry is cylinders at a fixed radius and discs at a fixed z as plain structs, so a helix crosses every surface in closed form. The restriction is on the shape alone: every cylinder has its own half-length and every disc its own rings, so a real endcap is described as the staggered discs and rings it is. Surfaces carry the material their detector's map reports, banded along the coordinate they extend in, and that material is the whole of the physics model: `x/X0` scatters and makes electrons, `x/L0` makes nuclear products, and the slab takes the energy. Nothing is fitted on top of it. Both material effects displace the *measured* position of a hit and leave the trajectory a nominal helix -- a scatter by the angle times the lever arm, energy loss by half the curvature change times that lever arm squared -- which is what gives a seed the spread a seeder cuts on at a fraction of the cost of stepping. It is deliberately coarse: a tool for throughput and combinatorics studies rather than for physics performance. The Generic pixel description ships with it; the descriptions of real detectors and the configurations fitted to them follow. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CMdYgLmPKFybPzSr8wZxhd
The ATLAS ITk pixels transcribed from the ITKLayouts constants, there being no ACTS ITk geometry to reduce: seventy-five staggered discs carrying ninety-five rings, the material each surface holds banded along it, and the supports the layers are carried on. With it the configuration fitted against a GNN4ITk ttbar dump at a pile-up of 200, on one half of the sample and checked on the other. What it reproduces is in the group documentation. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CMdYgLmPKFybPzSr8wZxhd
The Open Data Detector pixels read off the geometry ACTS builds and kept here so that the layout is available without DD4hep. Positions are of the sensitive silicon rather than of the layers the ODD declares, a module carrying its sensor 1.8 mm inside the nominal radius, and each of the seven endcap layers is two staggered single-ring discs rather than one disc of two rings. With it the configuration fitted against ColliderML at a pile-up of 200, on one half of the sample and checked on the other. Where it falls short -- the secondary momentum, the |d0| reach and the forward production -- is in the group documentation. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CMdYgLmPKFybPzSr8wZxhd
Four benchmarks on a generated event rather than on a recorded one: the generator itself, and the grid triplet, orthogonal triplet and GBTS seeders on what it makes. They share `SyntheticEventOptions`, so a run of one is the same event as a run of another and the three seeders are comparable. Each reports what it found against the generator truth -- seeds, true seeds and matched primaries above a momentum threshold -- so a change in throughput can be read next to what it cost in efficiency. The layout, the pile-up, the secondary rates and the module granularity are all on the command line, which is what makes the combinatorial load a knob rather than a property of a fixed sample. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CMdYgLmPKFybPzSr8wZxhd
andiwand
force-pushed
the
test-fatras-synthetic-seeding-benchmarks
branch
from
August 7, 2026 14:38
f98e36d to
f6aed53
Compare
|
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
1 participant
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.
Four benchmarks on a generated event rather than on a recorded one: the
generator itself, and the grid triplet, orthogonal triplet and GBTS seeders on
what it makes. They share
SyntheticEventOptions, so a run of one is the sameevent as a run of another and the three seeders are comparable.
Each reports what it found against the generator truth -- seeds, true seeds and
matched primaries above a momentum threshold -- so a change in throughput can be
read next to what it cost in efficiency. The layout, the pile-up, the secondary
rates and the module granularity are all on the command line, which is what
makes the combinatorial load a knob rather than a property of a fixed sample.
--- END COMMIT MESSAGE ---
Fifth in the stack described in #5806; it sits on
feat-fatras-synthetic-odd-layoutand includes everything below it, so its diffhere shows those commits too. It is independent of #5807.
Its own change is 2255 lines across 8 files, of which 1728 are the three seeder
benchmarks and 315 the options and triplet cuts they share.
What the benchmarks say today
--layout itk-pixel, pile-up 200, 239k space points, 1376 seedable primaries,single threaded on a laptop
RelWithDebInfobuild:Generating the event costs 120 ms, so the generator is not what any of these
measure.
Notes for review
Efficiency is a weak measure here and the four points between GBTS and the
k-d tree should not be read as a ranking. It counts a primary as found when one
seed of it survives, and a primary that crosses every layer of the pixels offers
a seeder many chances at that. Read the times and the candidate pair counts, which each
benchmark reports so that a tuning run can be read without a profiler, and use a
harder measure than "at least one true seed" if efficiency is the question.
A seed counts as true when three of its space points come from one primary,
not when all of them do. The distinction is invisible for the triplet seeders,
whose seeds are always three space points, but GBTS returns four to eleven, and
scoring it on every space point matching costs it four points of efficiency that
say nothing about the seeder.
The GBTS connection table here is written for these layouts, not trained on
them, so its efficiency is not a statement about GBTS as ATLAS runs it. What it
loses sits at the barrel-endcap transition, which is where a hand-written table is
weakest. The cuts themselves are Athena's:
ActsTrk::GbtsSeedingTooloverridesonly the connector file, the ML lookup table and
minPt, and its remainingdefaults agree with the ACTS ones property by property.
The spherical grid has no ATLAS counterpart to copy from. Its middle-axis
numbers were scanned on this event and each is at the point where efficiency stops
paying for the time it costs; the reasoning is in
SphericalGridConfig.These are benchmarks rather than tests: they are built by
ACTS_BUILD_BENCHMARKSand not run in CI.