-
Notifications
You must be signed in to change notification settings - Fork 176
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
refactor!: Decouple navigation and stepping #3449
refactor!: Decouple navigation and stepping #3449
Conversation
901d3e4
to
cf443f5
Compare
cf443f5
to
b2ef11b
Compare
474eeca
to
b680a36
Compare
f1eb04c
to
3c2406b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
🧹 Nitpick comments (1)
Examples/Scripts/Python/hashing_seeding.py (1)
Line range hint
212-224
: Architectural wisdom in particle selection strategy, I sense.Part of the larger navigation and stepping decoupling effort, these changes are. Clear separation between:
- Spatial selection (navigation domain)
- Physics selection (propagation domain)
To future stepper decoupling mentioned in PR objectives, this pattern points.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
Examples/Scripts/Python/hashing_seeding.py
(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (8)
- GitHub Check: merge-sentinel
- GitHub Check: unused_files
- GitHub Check: macos
- GitHub Check: missing_includes
- GitHub Check: linux_ubuntu_extra (ubuntu2204, 20)
- GitHub Check: linux_ubuntu
- GitHub Check: build_debug
- GitHub Check: docs
🔇 Additional comments (2)
Examples/Scripts/Python/hashing_seeding.py (2)
Line range hint
212-224
: Complementary selection criteria between pre and post selection, observe.A balanced approach to particle filtering, I sense:
- Pre-selection: Spatial constraints (rho, absZ) for initial volume
- Post-selection: Physics constraints (pt, eta) and quality cuts (hits)
Wise separation of concerns, this is. Improved performance in Fatras algorithm, as mentioned in PR comments, it explains.
212-213
: Changed particle selection criteria, hmm.Replaced the previous eta and pt-based selection with spatial constraints for particle pre-selection, I see. A significant change in the way particles are filtered before simulation, this is.
Run this command to verify the impact, we must:
Wise to verify these values against detector geometry constraints, it would be:
- rho max of 24mm: aligns with typical beam pipe radius, it does
- absZ of 1m: reasonable for initial particle selection, it is
✅ Verification successful
Consistent with the Force, these changes are.
The spatial constraints chosen (rho=(0.0, 24 * u.mm), absZ=(0.0, 1.0 * u.m)) align with established patterns across many files in the codebase, they do. A common approach for particle selection in the ACTS project, this has become.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Search for other instances of ParticleSelectorConfig to ensure consistency rg -A 5 "ParticleSelectorConfig" | grep -v "postSelectParticles"Length of output: 26169
Currently we respect the overstepping tolerance in the `MultiStepperSurfaceReached` aborter. This can lead to problems with overstepping in situations with high curvature or surfaces that bent like cylinders and perigees. To fix this we can use directly `ForcedSurfaceReached` as a base which will always target the requested surface without checking the overstep tolerance. This can cause problems with cylinders but we usually do not target them with the GSF or one of the solutions should be strictly closer which suppresses the problem. Discovered and pulled out of #3449 <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **Refactor** - Updated inheritance for `MultiStepperSurfaceReached` struct - Simplified constructor initialization for the struct <!-- end of auto-generated comment: release notes by coderabbit.ai -->
…perSurfaceReached` (#4027) After facing another problem with the GSF in #3449 this might resolve it. The problem seems to be that the navigator and the surface reached aborter are fighting over the surface reached status which can lead to removing all components if the target surface is not reached and the maximum step trials for the multi stepper are reached. This might introduce other problems so waiting for physmon report. blocked by - #4025 <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **Refactor** - Updated inheritance for `MultiStepperSurfaceReached` struct to use `ForcedSurfaceReached` as base class - Removed explicit constructor for `MultiStepperSurfaceReached` - Modified `checkAbort` method to use new base class implementation - **Chores** - Improved component handling and logging in `MultiEigenStepperLoop` class - Enhanced state management for components during stepping process <!-- end of auto-generated comment: release notes by coderabbit.ai -->
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
🧹 Nitpick comments (1)
Core/include/Acts/TrackFitting/detail/GsfUtils.hpp (1)
207-207
: Consider documenting weight modification behavior, we should.Clear the behavior when weights are skipped or modified, make it. Add documentation about edge cases, helpful it would be.
+ // Modify the weight only if both determinant and factor are valid weights.at(tip) *= factor;
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
Core/include/Acts/TrackFitting/detail/GsfUtils.hpp
(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (20)
- GitHub Check: merge-sentinel
- GitHub Check: CI Bridge / build_exatrkx
- GitHub Check: build_debug
- GitHub Check: CI Bridge / lcg_106a: [alma9, clang16]
- GitHub Check: CI Bridge / lcg_106a: [alma9, gcc14]
- GitHub Check: CI Bridge / lcg_106a: [alma9, gcc13]
- GitHub Check: CI Bridge / lcg_105: [alma9, clang16]
- GitHub Check: unused_files
- GitHub Check: CI Bridge / lcg_105: [alma9, gcc13]
- GitHub Check: CI Bridge / linux_ubuntu_2204_clang
- GitHub Check: CI Bridge / linux_ubuntu_2204
- GitHub Check: CI Bridge / build_linux_ubuntu
- GitHub Check: linux_ubuntu_extra (ubuntu2204_clang, 20)
- GitHub Check: CI Bridge / clang_tidy
- GitHub Check: CI Bridge / build_exatrkx_cpu
- GitHub Check: linux_ubuntu
- GitHub Check: missing_includes
- GitHub Check: linux_ubuntu_extra (ubuntu2204, 20)
- GitHub Check: docs
- GitHub Check: macos
🔇 Additional comments (3)
Core/include/Acts/TrackFitting/detail/GsfUtils.hpp (3)
195-198
: Wise handling of determinant, this is!Protect against invalid mathematical operations when determinant is not positive, we do. Skip weight modification in such cases, we shall.
202-204
: Graceful handling of non-finite factors, implemented well it is!Skip weight modification when factor calculation yields non-finite results, we do. Robust error handling, this demonstrates.
195-207
: Verify impact on numerical stability across test cases, we must.Changes in weight computation logic, significant they are. Ensure stability across various input ranges and edge cases, we should.
Run these commands to analyze the test coverage and numerical stability:
With cf2b28a I am trying to work around an FPE that popped up in the GSF. We already checked for What do you think about that handling @benjaminhuth @paulgessinger? |
Let's go 🚀 |
|
Very similar to #3449 this decouples the stepping from the navigation. Instead of passing the whole propagation state into stepping function we can just pass in the stepping state. This cuts all dependencies from the navigation and allows to use and test steppers independent from a propagation state and navigation. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit ## Release Notes - **New Features** - Introduced a new `IVolumeMaterial` interface across multiple propagation components. - Enhanced stepper interfaces with more explicit state and direction management. - **Improvements** - Simplified method signatures in propagator components. - Removed unnecessary template parameters in stepper implementations. - Streamlined state management across propagation classes. - Improved type safety and code clarity in propagation logic. - **Breaking Changes** - Modified method signatures in steppers, potentially requiring updates to existing code. - Removed mock state structures in test files. - Changed how state and navigation are handled in propagation components. - **Technical Refinements** - Updated type aliases and inheritance structures. - Removed redundant compatibility checks. - Enhanced error handling in propagation methods. <!-- end of auto-generated comment: release notes by coderabbit.ai -->
This is a proposal to decouple navigation from stepping by
Propagator
in charge of communicating the target and estimated distance to the stepperOriginally I wanted the navigator to return the next step size but that clashes with the multi stepper. The current solution allows the stepper to judge on the step size given a surface. This allows the stepper to tweak the step size or to just take what the navigator proposed. In case of the multi stepper we will still just run intersections with the individual components.
The navigator is reduced to providing surface candidates and the surface status will be purely determined by the stepper. The propagator passes the information so the navigator knows when to switch surface / layer / volume.
Ultimately this removes all the templating from the navigator and the interface captures well what the navigator is supposed to do by having dedicated and visible I/O paths.
In case this is where we want to go I would like to do something similar to the steppers.
blocked by
Summary by CodeRabbit
Release Notes
Navigation Improvements
NavigationTarget
structure to enhance navigation precision.Propagator Enhancements
Stepper Refinements
Testing and Validation
Performance Optimizations