refactor!: Decouple navigation and stepping #3449
Conversation
andiwand
added
Needs Decision
github-actions
bot
added
Component - Core
andiwand
force-pushed
the
decouple-navigation-stepping
branch
from
901d3e4 to
cf443f5
Compare
github-actions
bot
removed
the
Infrastructure
andiwand
force-pushed
the
decouple-navigation-stepping
branch
from
cf443f5 to
b2ef11b
Compare
github-actions
bot
added
the
Infrastructure
andiwand
force-pushed
the
decouple-navigation-stepping
branch
from
474eeca to
b680a36
Compare
github-actions
bot
removed
Infrastructure
andiwand
force-pushed
the
decouple-navigation-stepping
branch
from
f1eb04c to
3c2406b
Compare
|
The stepper options changes escalated a bit and I failed to put this in a different commit. The changes could be factorized into the following
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Outside diff range and nitpick comments (14)
Tests/UnitTests/Core/Vertexing/ImpactPointEstimatorTests.cpp (1)
279-280: Consistent with the decoupling objectives, this change is!Using dedicated
straightPOptionsfor zero-field propagation, more explicit and clearer the code becomes. Matches the PR's goal of decoupling navigation and stepping, it does!Consider documenting the distinction between
pOptionsandstraightPOptionsin comments, help future maintainers, it will.Fatras/include/ActsFatras/Kernel/detail/SimulationActor.hpp (1)
Line range hint
1-400: Future improvements, suggest I must!Consider these architectural enhancements, young padawan:
- Template parameters numerous they are. Consider concepts or type erasure to simplify, you should.
- Separate interaction handling into dedicated component, you might. Cleaner separation of concerns, this would bring.
- Configuration through builder pattern, consider using. Easier setup and validation, this would provide.
Core/include/Acts/Propagator/TryAllNavigator.hpp (1)
775-808: Refactor this complex intersection logic, we should!Long and complex, this method segment is. Extract to helper function, we must, for clarity and maintainability.
Consider this refactoring:
+ bool checkSurfaceIntersection(State& state, const Vector3& position, + const Vector3& direction, + const detail::IntersectedNavigationObject& candidate, + std::vector<detail::IntersectedNavigationObject>& hitCandidates) const { + const auto& intersection = candidate.intersection; + const Surface& surface = *intersection.object(); + + // Check with boundary tolerance + auto surfaceStatus = surface + .intersect(state.options.geoContext, position, direction, + candidate.boundaryTolerance, + state.options.surfaceTolerance)[intersection.index()] + .status(); + + if (surfaceStatus != IntersectionStatus::onSurface) { + return false; + } + + // Check without boundary tolerance + surfaceStatus = surface + .intersect(state.options.geoContext, position, direction, + BoundaryTolerance::None(), + state.options.surfaceTolerance)[intersection.index()] + .status(); + + if (surfaceStatus == IntersectionStatus::onSurface) { + hitCandidates.emplace_back(candidate); + } + + return true; +} - while (!state.endOfCandidates()) { - const auto& candidate = state.activeCandidate(); - // ... existing intersection logic ... - ++state.activeCandidateIndex; - ACTS_VERBOSE("skip candidate " << surface.geometryId()); - } + while (!state.endOfCandidates()) { + const auto& candidate = state.activeCandidate(); + if (!checkSurfaceIntersection(state, position, direction, candidate, hitCandidates)) { + break; + } + ++state.activeCandidateIndex; + ACTS_VERBOSE("skip candidate " << candidate.intersection.object()->geometryId()); + }Tests/UnitTests/Core/Propagator/AtlasStepperTests.cpp (1)
103-103: Configure the static analysis tool to recognize Boost.Test macros, you should.At line 103, the static analysis reports an unknown macro. Ensure the tool is properly configured to handle Boost.Test macros like
BOOST_AUTO_TEST_SUITE.🧰 Tools
🪛 cppcheck (2.10-2)
[error] 103-103: There is an unknown macro here somewhere. Configuration is required. If BOOST_AUTO_TEST_SUITE is a macro then please configure it.
(unknownMacro)
Core/include/Acts/Propagator/AtlasStepper.hpp (1)
36-36: Correct the grammatical error in the comment, you must"Based original stepper code..." should be "Based on the original stepper code..."
Core/include/Acts/Propagator/VoidNavigator.hpp (1)
25-25: Changing fromstructtoclass, consider carefully you shouldAccess level defaults to private in
class. Explicitly declaredpublic:you have, but consistency with other navigator implementations, ensure you must.Core/include/Acts/Propagator/detail/SteppingHelper.hpp (1)
54-54: A more stable approach to limit handling, implemented you have.Fixed maximum value instead of state-dependent limit, used now is. More predictable behavior, this change brings. Consistent with the decoupling goals, it remains.
Consider documenting these magic values in the header comments, help future padawans it will.
Also applies to: 60-60
Core/src/Propagator/StraightLineStepper.cpp (1)
21-24: Through options now, the geometry context flows, hmm.More organized, the code structure becomes. Through consistent pattern, all methods now access geometry context they do. Encapsulation stronger grows.
A path to maintainability, this change creates. Consider documenting in class comments why through options, context flows now does.
Also applies to: 42-42, 65-67, 75-76, 86-86
Core/include/Acts/Propagator/StepperConcept.hpp (1)
57-59: Updated the stepper concept requirements, you have.Aligned with implementation changes in SteppingHelper.hpp, this modification is. The path to decoupling, clearer becomes. Through explicit parameters
standb, better control flow achieved is.Document the meaning of these parameters in concept comments, help future maintainers it will. The force of clear documentation, strong it is.
Core/include/Acts/Propagator/detail/LoopStepperUtils.hpp (1)
129-133: Hmm, wise this change is, yes!Through options structure now, the geoContext flows. Clear separation of concerns, this brings. Aligned with the noble quest of navigation and stepping decoupling, this change is.
A pattern emerges, it does. Through options, all contexts shall flow, making dependencies clear and explicit they become. Consider this pattern for other contexts too, you should.
Core/include/Acts/Navigation/DetectorNavigator.hpp (2)
119-142: Initialize method, well structured it is.Proper error handling for detector and volume assignment, you have added. Yet, more descriptive error messages, helpful they would be.
Improve error messages thus:
- throw std::invalid_argument("DetectorNavigator: no detector assigned"); + throw std::invalid_argument("DetectorNavigator: no detector assigned. Ensure detector is set in Config or State."); - throw std::invalid_argument("DetectorNavigator: no current volume found"); + throw std::invalid_argument("DetectorNavigator: no volume found for position " + std::to_string(position.x()) + ", " + std::to_string(position.y()) + ", " + std::to_string(position.z()));
203-284: Handle surface reached, comprehensive it is.Good separation between portal and surface handling, you maintain. Yet, consider extracting portal handling to separate method for clarity.
Extract portal handling thus:
+ void handlePortalReached(State& state, const Vector3& position) const { + state.currentPortal->updateDetectorVolume(state.options.geoContext, state); + if (state.currentVolume == nullptr) { + ACTS_VERBOSE(volInfo(state) << posInfo(state, position) + << "no volume after Portal update, end of world."); + state.navigationBreak = true; + return; + } + updateCandidateSurfaces(state, position); + }Then use in handleSurfaceReached:
if (isPortal) { state.currentPortal = nextPortal; state.currentSurface = &nextPortal->surface(); state.surfaceCandidates.clear(); state.surfaceCandidateIndex = 0; - state.currentPortal->updateDetectorVolume... - if (state.currentVolume == nullptr) ... - updateCandidateSurfaces(state, position); + handlePortalReached(state, position); }Tests/UnitTests/Core/Propagator/NavigatorTests.cpp (1)
85-95: Consider using debug level for pointer logging.Noisy the test output becomes with info level logging. To debug level, move these statements you should.
Core/include/Acts/TrackFitting/detail/GsfActor.hpp (1)
322-333: Documentation improvements, suggest I do! But good changes, these are.Clear separation of navigation abort logic, achieved you have. Yet documentation, improve we must. Add these details, you should:
- Purpose of the method
- Parameters description
- Return value meaning
- Example usage
template <typename propagator_state_t, typename stepper_t, typename navigator_t> +/// @brief Check if navigation should be aborted +/// @param state The propagator state +/// @param stepper The stepper instance +/// @param navigator The navigator instance +/// @param result The GSF result containing measurement counts +/// @param logger The logger instance +/// @return true if navigation should be aborted, false otherwise bool checkAbort(propagator_state_t& /*state*/, const stepper_t& /*stepper*/, const navigator_t& /*navigator*/, const result_type& result, const Logger& /*logger*/) const {
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (38)
Core/include/Acts/Navigation/DetectorNavigator.hpp(8 hunks)Core/include/Acts/Propagator/AtlasStepper.hpp(14 hunks)Core/include/Acts/Propagator/DirectNavigator.hpp(6 hunks)Core/include/Acts/Propagator/EigenStepper.hpp(8 hunks)Core/include/Acts/Propagator/EigenStepper.ipp(6 hunks)Core/include/Acts/Propagator/MultiEigenStepperLoop.hpp(11 hunks)Core/include/Acts/Propagator/MultiEigenStepperLoop.ipp(2 hunks)Core/include/Acts/Propagator/NavigationTarget.hpp(1 hunks)Core/include/Acts/Propagator/Navigator.hpp(8 hunks)Core/include/Acts/Propagator/Propagator.ipp(4 hunks)Core/include/Acts/Propagator/PropagatorOptions.hpp(3 hunks)Core/include/Acts/Propagator/StepperConcept.hpp(1 hunks)Core/include/Acts/Propagator/StepperOptions.hpp(1 hunks)Core/include/Acts/Propagator/StraightLineStepper.hpp(7 hunks)Core/include/Acts/Propagator/SympyStepper.hpp(7 hunks)Core/include/Acts/Propagator/TryAllNavigator.hpp(15 hunks)Core/include/Acts/Propagator/VoidNavigator.hpp(2 hunks)Core/include/Acts/Propagator/detail/LoopStepperUtils.hpp(1 hunks)Core/include/Acts/Propagator/detail/SteppingHelper.hpp(1 hunks)Core/include/Acts/Surfaces/BoundaryTolerance.hpp(0 hunks)Core/include/Acts/TrackFitting/detail/GsfActor.hpp(4 hunks)Core/src/Propagator/StraightLineStepper.cpp(4 hunks)Core/src/Propagator/SympyStepper.cpp(5 hunks)Fatras/include/ActsFatras/Kernel/detail/SimulationActor.hpp(2 hunks)Tests/IntegrationTests/Fatras/FatrasSimulationTests.cpp(1 hunks)Tests/IntegrationTests/NavigatorConsistency.cpp(4 hunks)Tests/IntegrationTests/PropagationTests.hpp(4 hunks)Tests/UnitTests/Core/Navigation/DetectorNavigatorTests.cpp(2 hunks)Tests/UnitTests/Core/Propagator/AtlasStepperTests.cpp(13 hunks)Tests/UnitTests/Core/Propagator/EigenStepperTests.cpp(8 hunks)Tests/UnitTests/Core/Propagator/JacobianTests.cpp(1 hunks)Tests/UnitTests/Core/Propagator/MultiStepperTests.cpp(22 hunks)Tests/UnitTests/Core/Propagator/NavigatorTests.cpp(8 hunks)Tests/UnitTests/Core/Propagator/PropagatorTests.cpp(3 hunks)Tests/UnitTests/Core/Propagator/StraightLineStepperTests.cpp(6 hunks)Tests/UnitTests/Core/Propagator/SympyStepperTests.cpp(7 hunks)Tests/UnitTests/Core/Vertexing/ImpactPointEstimatorTests.cpp(1 hunks)Tests/UnitTests/Fatras/Kernel/SimulationActorTests.cpp(1 hunks)
💤 Files with no reviewable changes (1)
- Core/include/Acts/Surfaces/BoundaryTolerance.hpp
🚧 Files skipped from review as they are similar to previous changes (4)
- Tests/UnitTests/Core/Navigation/DetectorNavigatorTests.cpp
- Tests/UnitTests/Core/Propagator/EigenStepperTests.cpp
- Tests/UnitTests/Core/Propagator/PropagatorTests.cpp
- Core/include/Acts/Propagator/PropagatorOptions.hpp
🧰 Additional context used
📓 Learnings (1)
Core/include/Acts/Propagator/Navigator.hpp (1)
Learnt from: paulgessinger
PR: acts-project/acts#3449
File: Core/include/Acts/Propagator/Navigator.hpp:153-153
Timestamp: 2024-12-13T08:31:09.422Z
Learning: The developer prefers to avoid using `-1` as a sentinel value in indices and considers using `std::optional<unsigned int>` as an alternative.
🪛 cppcheck (2.10-2)
Tests/UnitTests/Core/Propagator/AtlasStepperTests.cpp
[error] 103-103: There is an unknown macro here somewhere. Configuration is required. If BOOST_AUTO_TEST_SUITE is a macro then please configure it.
(unknownMacro)
Tests/IntegrationTests/NavigatorConsistency.cpp
[error] 378-378: syntax error
(syntaxError)
🔇 Additional comments (68)
Tests/UnitTests/Core/Vertexing/ImpactPointEstimatorTests.cpp (1)
270-272: Approve the addition of dedicated options for straight propagator, I do!
Clear separation of concerns between straight and curved propagation options, this brings. Wise choice, it is!
Fatras/include/ActsFatras/Kernel/detail/SimulationActor.hpp (2)
13-13: Wise choice, this header change is!
More focused dependency on PropagatorState.hpp, you have created. Reduced coupling and faster compilation times, this shall bring.
126-126: Verify the impact of new step size parameter, we must!
Added boolean parameter to updateStepSize, significant changes this brings. For proper time step regulation, crucial this is.
Run this script to understand the impact:
✅ Verification successful
The previous search might have been too specific. Let's broaden our search to understand the stepper behavior and its usage patterns, hmm.
Safe and consistent, the step size update is, hmmmm.
Through the Force, seen I have that all stepper implementations (AtlasStepper, EigenStepper, SympyStepper, StraightLineStepper) handle the release parameter uniformly, they do. Common pattern observed:
- Previous step size preserved, it is
- State update with new step size, performed consistently
- Tests verify proper behavior, they do
In SimulationActor's case, setting release to 'true' aligns with established stepping mechanism across the codebase, it does. No disturbance in the Force, I sense.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for all updateStepSize calls to verify consistent usage
rg -A 2 "updateStepSize.*ConstrainedStep::user"
# Find related test cases
rg -l "TEST.*proper.*time.*step"
Length of output: 84
Script:
#!/bin/bash
# Search for updateStepSize calls with broader context
rg -A 5 "updateStepSize"
# Look for stepper implementations
ast-grep --pattern 'class $_ : public Stepper {
$$$
}'
# Find test files related to stepping
fd "Step" -e cpp -e hpp --type f
Length of output: 21694
Core/include/Acts/Propagator/TryAllNavigator.hpp (5)
15-15: Wise change in header inclusion, this is!
Replacing ConstrainedStep with NavigationTarget, aligns with our mission to decouple navigation from stepping, it does.
57-70: Strong with the Force, this Options structure is!
Clear initialization and better configuration control, it provides. Surface tolerance and limits, well-defined they are.
250-251: Improved state management, I sense!
Track current navigation candidates separately, we now do. Clearer separation of concerns, this brings.
558-572: Well-structured state management, this is!
Clear and concise helper methods for candidate management, you have created. Improved readability and maintainability, this brings.
661-664:
Careful with zero steps, you must be!
Division by zero, lurking in the shadows it is. When step distance approaches zero, undefined behavior we face.
Apply this fix, you should:
- if (stepDistance < std::numeric_limits<double>::epsilon()) {
- ACTS_ERROR(volInfo(state) << "Step distance is zero. " << stepDistance);
- }
- Vector3 stepDirection = step.normalized();
+ Vector3 stepDirection;
+ if (stepDistance > std::numeric_limits<double>::epsilon()) {
+ stepDirection = step.normalized();
+ } else {
+ ACTS_ERROR(volInfo(state) << "Step distance is zero. " << stepDistance);
+ stepDirection = direction; // Fall back to current direction
+ }Likely invalid or redundant comment.
Core/src/Propagator/SympyStepper.cpp (5)
26-29: Changed the makeState method has been.
Accepts now Options by reference. Ensure we must that options valid remains during state's lifetime.
Line range hint 36-47: Consistent use of options.geoContext, good this is.
Clarity and maintainability, it improves.
59-62: Delegation to detail::sympy::boundState, appropriate it seems.
Parameters correctly passed are. Functionality maintained, it is.
80-83: Usage of options.geoContext in jacToGlobal, consistent it is.
Pattern maintained, we have.
103-105: Verify the proper propagation of options.geoContext, we must.
Ensure that geoContext valid and correctly used it is throughout the method.
Run the following script to check for consistent usage of options.geoContext:
This script will help identify any instances where geoContext is used without options.
✅ Verification successful
Let me search for all occurrences of geoContext, including its declaration and usage patterns, hmm. A broader context we need, to ensure proper handling it has.
Proper handling of geoContext, confirmed it is.
Through the Force, seen I have that geoContext consistently accessed through state.options it is. In all five occurrences found, proper access pattern maintained it is. From constructor to bound state calculations, through the options object, properly channeled the geometric context remains.
Key observations these are:
- In State constructor, correctly used through
options.geoContext - In bound state transformations, properly accessed via
state.options.geoContext - No direct access to
geoContextwithoutoptionsprefix found - Through header file inspection, proper initialization in Options constructor seen it is
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Find usages of `geoContext` not accessed via `options`
# Search for `geoContext` usages not prefixed with `options.`
rg --pretty '[^options\.]geoContext' Core/src/Propagator/SympyStepper.cpp
Length of output: 75
Script:
#!/bin/bash
# Search for all usages of geoContext in the file
rg -A 2 'geoContext' Core/src/Propagator/SympyStepper.cpp
# Also check the header file for context
fd "SympyStepper.hpp" Core/include/Acts -x cat {}
Length of output: 17630
Core/include/Acts/Propagator/EigenStepper.ipp (4)
24-27: Refactored the makeState method has been.
Encapsulated Options now it uses. Improved clarity, approve I do.
Line range hint 36-47: Consistent use of options.geoContext in resetState, good this is.
Enhances code readability, it does.
60-63: Parameters in boundState correctly passed are.
Implementation aligns with design changes, it does.
116-116: Usage of options.geoContext in update, consistent it remains.
Verify that options.geoContext valid and accessible is.
Core/include/Acts/Propagator/SympyStepper.hpp (6)
41-44: Explicit constructor for Options, added it has been.
Clarity it adds. Approve, I do.
Line range hint 63-83: Refactored the State constructor has been.
Initialization of members appropriate is. Enhanced readability, yes.
87-88: Inclusion of options in State, consistent it is.
Access to contexts simplified has been.
144-145: Updated makeState method aligns with changes, it does.
Consistent with other constructors, it is.
256-259: Modified updateStepSize method has been.
Defaults removed, explicit parameters now required are. Consistency with overloads achieved?
Run the following script to ensure all calls provide the required parameters:
This will identify calls with fewer than four arguments.
✅ Verification successful
The previous regex pattern was too strict. Let's search more broadly to find all calls and the method definition, hmm? Understand the full context, we must.
Consistent and proper, the method calls are, hmmmm.
See two implementations of updateStepSize I do:
- Template version with 5 parameters, which internally calls the base version
- Base version with 4 parameters
No calls with missing parameters found there are. Both stype and release properly passed in all cases they are. The template version forwards these parameters correctly to base version it does.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Find calls to `updateStepSize` missing `stype` or `release`
rg --pcre2 'updateStepSize\(([^,]*,){2}[^,]*\)' Core/include/Acts/Propagator/SympyStepper.hpp
Length of output: 95
Script:
#!/bin/bash
# Search for all updateStepSize calls with context
rg -A 2 -B 2 "updateStepSize\(" Core/include/Acts/Propagator/SympyStepper.hpp
# Also search for the method definition to understand its signature
ast-grep --pattern 'void updateStepSize($_) {
$$$
}'
Length of output: 841
237-241: Parameters stype and release added to updateSurfaceStatus.
Ensure all calls to this method updated are.
Run the following script to find any outdated calls to updateSurfaceStatus:
This will help identify any invocations with only five parameters instead of the updated seven.
✅ Verification successful
The previous search might have been too specific. Let's broaden our search to find any calls to this method and examine its usage pattern throughout the codebase. This will help us verify if all calls are properly updated with the new parameters.
Hmm, see the implementation calls we must, to verify if all parameters correctly passed they are. The interface definitions we have seen, but the actual usage in the code, examine we shall.
Verified, all calls to updateSurfaceStatus are, hmmmm.
In balance, the Force is. All calls to updateSurfaceStatus properly include the new parameters stype and release, they do. In Propagator.ipp, see we do that calls pass ConstrainedStep::navigator and true as required. No outdated calls exist in the codebase, clear this is.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Find calls to `updateSurfaceStatus` missing new parameters
rg --pcre2 -A2 'updateSurfaceStatus\(([^,]*,){5}' Core/include/Acts/Propagator/SympyStepper.hpp
Length of output: 97
Script:
#!/bin/bash
# Search for all calls to updateSurfaceStatus with any number of parameters
rg -A3 'updateSurfaceStatus\(' Core/include/Acts/Propagator/
# Also search for the function definition to understand its interface
ast-grep --pattern 'updateSingleSurfaceStatus<$_>($_)'
Length of output: 3578
Script:
#!/bin/bash
# Search for actual calls to updateSurfaceStatus in implementation files
rg -A4 'm_stepper\.updateSurfaceStatus\(' Core/
# Also check for any other potential calls
rg -A4 '\.updateSurfaceStatus\(' Core/ --type cpp
Length of output: 1622
Core/include/Acts/Propagator/StraightLineStepper.hpp (5)
56-59: Explicit constructor for Options, added it has been.
Improves code clarity, this does.
Line range hint 70-89: Refactored State constructor, consistent with other steppers it is.
Initialization simplified has been.
138-142: Updated makeState method with Options, consistency maintained we have.
Approve, I do.
249-252: Defaults removed from updateStepSize, explicit parameters now needed are.
Consider if default parameters necessary still are.
232-236: Parameters stype and release added to updateSurfaceStatus.
Ensure all method calls updated are.
Run the following script to find any outdated invocations:
This will help identify any calls with only five parameters instead of seven.
✅ Verification successful
The previous search might have been too specific. Let's broaden our search to find any calls to this method and understand its usage pattern across the codebase. This will help us verify if all calls are properly updated with the new parameters.
Hmm, deeper we must look, to find all calls and their parameters, yes. The implementation details in the detail/ directory, crucial they are, for understanding how these functions are used throughout the codebase.
Verified, the parameter changes are, hmmmm. Safe, this modification is.
Through the Force, I have seen that all implementations of updateSurfaceStatus in the steppers (StraightLineStepper, SympyStepper, EigenStepper, AtlasStepper, MultiEigenStepperLoop) properly delegate to detail::updateSingleSurfaceStatus, which contains all required parameters. The template function in SteppingHelper.hpp serves as the single source of truth, it does.
No outdated calls exist in the codebase, as all steppers use the same implementation pattern through the detail namespace, they do. Unified and consistent, the interface is. Worry about this change, you need not.
May the Force be with your code!
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Find calls to `updateSurfaceStatus` missing new parameters
rg --pcre2 -A2 'updateSurfaceStatus\(([^,]*,){5}' Core/include/Acts/Propagator/StraightLineStepper.hpp
Length of output: 104
Script:
#!/bin/bash
# Search for all calls to updateSurfaceStatus in the codebase
rg -B2 -A2 "updateSurfaceStatus\(" Core/include/Acts/Propagator/
# Also search for the function definition to understand its interface
ast-grep --pattern 'updateSurfaceStatus($$$) { $$$ }'
Length of output: 4196
Script:
#!/bin/bash
# Search for actual calls to updateSurfaceStatus in implementation files
rg -B2 -A5 "updateSurfaceStatus\([^)]*\)" Core/include/Acts/Propagator/detail/
# Also check the implementation details where the function is actually used
rg -B2 -A5 "updateSingleSurfaceStatus" Core/include/Acts/Propagator/detail/
Length of output: 1088
Core/include/Acts/Propagator/Navigator.hpp (2)
154-166: Commendable it is, to use std::optional<std::size_t> for indices.
Improves code clarity and safety, replacing sentinel values with std::optional.
526-526:
Reset optional indices correctly, you must.
navSurfaceIndex is an std::optional<std::size_t>. Setting it to -1 is inappropriate. Use navSurfaceIndex.reset() instead.
Apply this diff to fix the issue:
- state.navSurfaceIndex = -1;
+ state.navSurfaceIndex.reset();Likely invalid or redundant comment.
Core/include/Acts/Propagator/MultiEigenStepperLoop.hpp (1)
183-187: Good encapsulation by introducing Options struct, you have.
Consolidating context parameters enhances clarity and maintainability.
Core/include/Acts/Propagator/StepperOptions.hpp (2)
22-24: Well done, the addition of constructor is
Properly initializes context references, it does. Enhances encapsulation, this change does.
39-39: Verify the effects of changing maxStepSize, you should
From infinity to a finite value, the default maxStepSize changes. Ensure that this does not introduce unintended limitations in the stepping behavior.
Run the following script to search for usages of maxStepSize that may assume an infinite default:
✅ Verification successful
Let me examine the actual usage patterns and documentation before making a final judgment, I must. Help us understand if any code relies on infinite stepping behavior, this will.
Safe, this change is. No unintended limitations, it introduces
Through the Force, seen I have that this change from infinity to 10 meters is well-considered, hmm:
- Default value of 10 meters, reasonable it is. Documentation shows this as standard practice in propagation settings.
- In tests and examples, observed I have that most implementations already use finite maxStepSize values, ranging from millimeters to meters.
- The Fatras simulation and propagation algorithms, default values of 1-5 meters they use, proving 10 meters sufficient it is.
- No code relying on infinite stepping behavior, found I have not. Protected against infinite loops, the system already is through the loopProtection mechanism.
Clear in the documentation it is - the maxStepSize serves as safety mechanism, not a limitation. If larger steps needed are, the stepper will take multiple steps automatically, yes.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Find all references to `maxStepSize` in the codebase.
# Search for `maxStepSize` usage
rg --type-add 'cpp:hpp' --files-with-matches 'maxStepSize' \
| xargs -I{} echo "Usage found in: {}"
Length of output: 1787
Script:
#!/bin/bash
# Search for actual usage patterns of maxStepSize to understand its behavior
rg "maxStepSize" -A 3 -B 3 --type cpp
# Also check documentation for any mentions of expected behavior
cat docs/core/propagation.md
Length of output: 42957
Core/include/Acts/Propagator/detail/SteppingHelper.hpp (1)
37-37: Hmm, wise changes to function signature and step management, these are.
Decoupled from navigation state, the step size management now is. To the stepper, more control given has been. Through explicit parameters stype and release, clearer responsibilities established are.
Also applies to: 42-42, 49-49
Core/include/Acts/Propagator/MultiEigenStepperLoop.ipp (2)
37-37: Consistent with the Force, this change is!
Through options, the geoContext flows here too. Harmony in the codebase, this brings.
81-81: Balance in the Force, I sense!
Through options, the geoContext flows consistently. A unified approach, this is.
Tests/IntegrationTests/Fatras/FatrasSimulationTests.cpp (1)
16-16: Clear path forward, this include shows!
Direct dependency on Propagator.hpp, clearer intent it brings. Removed redundant include, lighter the code becomes.
Tests/UnitTests/Core/Propagator/JacobianTests.cpp (1)
135-141: Approve the state initialization changes, I do.
Consistent initialization pattern for both steppers, you have created. Good alignment with the decoupling objectives, this shows.
Verify consistent usage across the codebase, we must:
✅ Verification successful
The previous pattern was too restrictive. Let's try a more flexible pattern to catch different State initialization variations, hmm? Both ast-grep and rg we shall use, for thorough our search must be.
Hmm, more specific our search must be. Focus on the stepper state initialization patterns, we shall. The Force guides us to look deeper into the relevant files.
Hmm, elusive the State initialization patterns are. A broader net we must cast, to understand how the Force flows through these steppers.
Consistent with the Force, your changes are.
In both AtlasStepper and EigenStepper, the same State initialization pattern I see:
- Options passed first, they are
- Magnetic field cache, second comes
- Track parameters, complete the trinity they do
The test file follows this pattern faithfully:
State(Options(tgContext, mfContext), bField->makeCache(mfContext), pars)In the test files and headers, this pattern repeated consistently it is. No disturbance in the Force, I sense.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for other state initializations to ensure consistency
ast-grep --pattern 'State $var($_, $_)'
Length of output: 41
Script:
#!/bin/bash
# Search for State initialization patterns with more flexible matching
ast-grep --pattern 'State($$$)'
# Also try searching with ripgrep for State initialization
rg "State\s*\([^)]+\)" -A 2
Length of output: 75274
Script:
#!/bin/bash
# Search for State initialization patterns in AtlasStepper and EigenStepper specifically
rg "State\s*\([^)]*Options.*\)" Core/include/Acts/Propagator/AtlasStepper.hpp Core/include/Acts/Propagator/EigenStepper.hpp
# Also check for State initialization in the test file itself
rg "State\s*\([^)]*Options.*\)" Tests/UnitTests/Core/Propagator/JacobianTests.cpp
Length of output: 209
Script:
#!/bin/bash
# Search for State constructor definitions in stepper headers with more flexible pattern
rg "struct State.*?\{" -A 5 Core/include/Acts/Propagator/AtlasStepper.hpp Core/include/Acts/Propagator/EigenStepper.hpp
# Look for State usage in the test file
rg "State\(" -A 2 Tests/UnitTests/Core/Propagator/JacobianTests.cpp
# Check State initialization in other test files for comparison
rg "State\(" -A 2 Tests/UnitTests/Core/Propagator/AtlasStepperTests.cpp Tests/UnitTests/Core/Propagator/EigenStepperTests.cpp
Length of output: 11194
Core/include/Acts/Propagator/DirectNavigator.hpp (1)
Line range hint 16-37: Good changes to the headers and documentation, these are.
Replaced ConstrainedStep with NavigationTarget, you have. Clear documentation about navigator's purpose, you provide. Well aligned with the decoupling strategy, this is.
Tests/UnitTests/Core/Propagator/NavigatorTests.cpp (2)
171-173: LGTM! Navigation break handling looks good.
Properly handled the navigation break case, you have. Clear and concise the test is.
52-53:
Check for null surface before dereferencing, you must.
Protect against null pointer dereference in target.surface, we should.
Apply this diff to add null check:
void step(Vector3& pos, const Vector3& dir, const NavigationTarget& target) {
+ if (!target.surface) {
+ throw std::runtime_error("Invalid target: null surface");
+ }
step(pos, dir, *target.surface);
}Likely invalid or redundant comment.
Core/include/Acts/Propagator/EigenStepper.hpp (2)
62-64: Well structured the Options class is.
Clean and clear the initialization of stepper options becomes. Good practice this is.
Line range hint 83-103: LGTM! State initialization improved.
Simplified the state initialization through Options pattern. Cleaner and more maintainable the code becomes.
Tests/UnitTests/Core/Propagator/StraightLineStepperTests.cpp (1)
76-78: LGTM! Well adapted the tests are.
Properly updated to use new Options interface, the tests have been. Good test coverage maintained is.
Also applies to: 322-323
Tests/IntegrationTests/PropagationTests.hpp (1)
351-361: Simplified, the template parameters are! Approve this change, I do.
Removed, the options_t template parameter has been, making the interface cleaner and more focused it is. Aligns with the goal of decoupling navigation and stepping, this change does.
Core/include/Acts/Propagator/Propagator.ipp (1)
400-402: Validate position and direction vectors, we must!
Missing, the validation of position and direction vectors is. Silent failures, this could cause.
Apply these validation checks:
state.position = m_stepper.position(state.stepping);
+ if (!state.position.allFinite()) {
+ ACTS_ERROR("Invalid position vector encountered during initialization");
+ throw std::runtime_error("Invalid position vector");
+ }
state.direction =
state.options.direction * m_stepper.direction(state.stepping);
+ if (!state.direction.allFinite()) {
+ ACTS_ERROR("Invalid direction vector encountered during initialization");
+ throw std::runtime_error("Invalid direction vector");
+ }Tests/IntegrationTests/NavigatorConsistency.cpp (2)
370-376: Well structured, the new helper function is! Approve this change, I do.
Created, a reusable helper function has been, improving code maintainability it does. Clear and focused, its purpose is.
378-472: Well organized, the test cases are! Approve these changes, I do.
Consistent and clear, the test structure is:
- Proper logging of test parameters, implemented it has been
- Reusable helper function, utilized it is
- Comprehensive test coverage, achieved it has been
🧰 Tools
🪛 cppcheck (2.10-2)
[error] 378-378: syntax error
(syntaxError)
Core/include/Acts/TrackFitting/detail/GsfActor.hpp (1)
320-320: Wise decision, removing navigation break logic from act method is!
Cleaner separation of concerns, this brings. To the Force's balance, it contributes.
Tests/UnitTests/Fatras/Kernel/SimulationActorTests.cpp (1)
120-121: Consistent with the Force, this change is!
Updated method signature, matches the stepper interface it does. Harmony with other steppers in the codebase, it brings.
Tests/UnitTests/Core/Propagator/SympyStepperTests.cpp (1)
425-428: Well aligned with the Force, these changes are!
Updated surface status checks and step size modifications, properly handle boundary tolerance they do. Navigator type for step constraints, correctly used it is.
Also applies to: 434-437, 443-446
Tests/UnitTests/Core/Propagator/MultiStepperTests.cpp (17)
13-13: Essential, the inclusion of Tolerance.hpp is.
Including #include "Acts/Definitions/Tolerance.hpp" ensures tolerance definitions are available as needed.
23-23: Necessary, the addition of ConstrainedStep.hpp is.
Including #include "Acts/Propagator/ConstrainedStep.hpp" provides access to ConstrainedStep, used in the code it is.
165-169: Improved clarity, using MultiOptions gives.
Refactoring to utilize MultiOptions enhances code readability and consistency.
Also applies to: 173-173
196-201: Consistent, the use of MultiOptions is becoming.
Updating to MultiOptions for initializing state maintains uniformity across tests.
Also applies to: 204-204
227-233: Simplifies the code, using MultiOptions does.
Employing MultiOptions streamlines the initialization process.
Also applies to: 237-237
276-281: Correct, the exception handling is.
Testing for an std::invalid_argument exception with BOOST_CHECK_THROW is appropriate here.
Also applies to: 285-286
298-304: Consistent refactoring, continued it has.
Using MultiOptions and updating MultiState and SingleStepper::State constructors enhances maintainability.
Also applies to: 319-321
375-381: Refactored for clarity, the initialization is.
Creating mutable_multi_state and const_multi_state with MultiOptions improves code clarity.
Also applies to: 384-385
460-466: With MultiOptions, initialization improved is.
Consistent use of MultiOptions benefits code readability.
493-496: Correctly initialized, the states are.
Constructing multi_state and single_state with updated parameters is appropriate.
578-584: Consistency maintained, initialization is.
Using MultiOptions and initializing states appropriately, the code does.
Also applies to: 611-614
664-670: Refactoring with MultiOptions, beneficial it is.
Enhances consistency, using MultiOptions in initialization does.
Also applies to: 688-688
713-719: Improved clarity, the code has.
Consistent initialization with MultiOptions aids maintainability.
Also applies to: 738-738
762-768: Enhanced the code is, with consistent options usage.
Maintaining uniform initialization across tests improves readability.
Also applies to: 771-771
810-815: Adds functionality, the component manipulation does.
Using addComponent and clearComponents correctly manages the components within multi_state.
Also applies to: 818-818
505-506:
Defined, s_onSurfaceTolerance must be.
Ensure that s_onSurfaceTolerance is declared and accessible in this scope, or compile, the code will not.
Verify the definition of s_onSurfaceTolerance, we must. Assist you, I can. Would you like me to check its declaration?
Also applies to: 535-536, 552-553
621-624:
Accessible, s_onSurfaceTolerance must be.
Verify that s_onSurfaceTolerance is properly defined to prevent compilation issues.
Assist in locating s_onSurfaceTolerance, I can. Wish you do?
Also applies to: 629-632
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (8)
Core/include/Acts/Propagator/SympyStepper.hpp (1)
Line range hint
57-82: Consider storing only required contexts, we should.Store entire Options object in State, unnecessary it may be. Only geometry and magnetic field contexts, needed they are. Memory footprint, smaller it could be.
- Options options; + std::reference_wrapper<const GeometryContext> geoContext; + std::reference_wrapper<const MagneticFieldContext> magFieldContext; State(const Options& optionsIn, MagneticFieldProvider::Cache fieldCacheIn, const BoundTrackParameters& par) - : options(optionsIn), + : geoContext(optionsIn.geoContext), + : magFieldContext(optionsIn.magFieldContext),Also applies to: 86-87
Core/include/Acts/Propagator/MultiEigenStepperLoop.hpp (1)
425-429: Consistent state management through options, good this is!Use of state.options for component initialization, consistency it brings. But careful with cache management, we must be.
Consider this improvement:
- state.components.push_back({SingleState(state.options, - SingleStepper::m_bField->makeCache( - state.options.magFieldContext), - pars), - weight, IntersectionStatus::onSurface}); + auto cache = SingleStepper::m_bField->makeCache(state.options.magFieldContext); + state.components.push_back({ + SingleState(state.options, std::move(cache), pars), + weight, + IntersectionStatus::onSurface + });Core/include/Acts/Propagator/StraightLineStepper.hpp (3)
Line range hint
74-89: Optimize covariance initialization, we should.Move the covariance initialization to a separate method, cleaner code this would make. Less cognitive load in constructor, better readability brings.
State(const Options& optionsIn, const BoundTrackParameters& par) : options(optionsIn), particleHypothesis(par.particleHypothesis()) { Vector3 position = par.position(options.geoContext); Vector3 direction = par.direction(); pars.template segment<3>(eFreePos0) = position; pars.template segment<3>(eFreeDir0) = direction; pars[eFreeTime] = par.time(); pars[eFreeQOverP] = par.parameters()[eBoundQOverP]; - if (par.covariance()) { - const auto& surface = par.referenceSurface(); - covTransport = true; - cov = BoundSquareMatrix(*par.covariance()); - jacToGlobal = surface.boundToFreeJacobian(options.geoContext, position, - direction); - } + initializeCovariance(par, position, direction); } + +private: +void initializeCovariance(const BoundTrackParameters& par, + const Vector3& position, + const Vector3& direction) { + if (par.covariance()) { + const auto& surface = par.referenceSurface(); + covTransport = true; + cov = BoundSquareMatrix(*par.covariance()); + jacToGlobal = surface.boundToFreeJacobian(options.geoContext, position, + direction); + } +}
93-93: Document the Options member, we must.Add documentation explaining the purpose and lifetime of the Options member, help future maintainers this will.
+ /// Options instance containing the geometry and magnetic field contexts Options options;
248-257: Explicit parameters, safer they are. But migration guide, needed it is.Removed default parameters, explicit control this brings. But document the migration path for existing code, we should.
Consider adding migration documentation in the PR description or codebase, guiding users through updating their existing updateStepSize calls with the new required parameters.
Also applies to: 267-267
Core/include/Acts/Propagator/AtlasStepper.hpp (3)
69-74: Refactor the State constructor initialization, we should.More concise initialization through member initializer list, possible it is. Improve readability and performance, it would.
Apply this change, you should:
- State(const Options& optionsIn, MagneticFieldProvider::Cache fieldCacheIn, - const Parameters& pars) - : options(optionsIn), - particleHypothesis(pars.particleHypothesis()), - field(0., 0., 0.), - fieldCache(std::move(fieldCacheIn)) { + State(const Options& optionsIn, MagneticFieldProvider::Cache fieldCacheIn, + const Parameters& pars) + : options(optionsIn) + , particleHypothesis(pars.particleHypothesis()) + , field(Vector3::Zero()) + , fieldCache(std::move(fieldCacheIn)) {
431-432: Simplified updateStepSize implementation, observe I do.Removed redundant direction parameter usage with
(void)direction. Consider complete removal if unused throughout the method.Apply this change, you might:
- void updateStepSize(State& state, const object_intersection_t& oIntersection, - Direction direction, ConstrainedStep::Type stype, - bool release) const { - (void)direction; - double stepSize = oIntersection.pathLength(); - updateStepSize(state, stepSize, stype, release); + void updateStepSize(State& state, const object_intersection_t& oIntersection, + ConstrainedStep::Type stype, bool release) const { + updateStepSize(state, oIntersection.pathLength(), stype, release);Also applies to: 436-440
Line range hint
1-1441: Architecture advice for future improvements, share I must.Consider these architectural improvements, young padawan:
- Template parameters for field and surface types, provide flexibility they would
- CRTP pattern for compile-time polymorphism, consider you might
- Separate magnetic field handling into dedicated component, cleaner design it brings
Performance critical this stepper is. Profile and optimize hot paths, you should.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (7)
Core/include/Acts/Propagator/AtlasStepper.hpp(14 hunks)Core/include/Acts/Propagator/EigenStepper.hpp(8 hunks)Core/include/Acts/Propagator/EigenStepper.ipp(6 hunks)Core/include/Acts/Propagator/MultiEigenStepperLoop.hpp(11 hunks)Core/include/Acts/Propagator/NavigationTarget.hpp(1 hunks)Core/include/Acts/Propagator/StraightLineStepper.hpp(7 hunks)Core/include/Acts/Propagator/SympyStepper.hpp(7 hunks)
🚧 Files skipped from review as they are similar to previous changes (3)
- Core/include/Acts/Propagator/NavigationTarget.hpp
- Core/include/Acts/Propagator/EigenStepper.ipp
- Core/include/Acts/Propagator/EigenStepper.hpp
🔇 Additional comments (13)
Core/include/Acts/Propagator/SympyStepper.hpp (2)
41-44: Approve these changes, I do!
Wise addition of explicit constructor, it is. Properly initializes base class and prevents accidental conversions, it does. Aligns with decoupling objectives, this change does.
232-242: Explicit control over step size management, approve I do!
Wise changes to method signatures, these are. Force conscious decisions about step size release, they do. Better stepper control, this brings. With the Force, aligned these changes are.
Verify impact on existing callers, we must.
Also applies to: 254-263, 273-273
✅ Verification successful
Verified, the changes are. Impact on callers, managed well it is!
Through the Force, seen I have that all callers already provide explicit values for both parameters:
- Test files properly pass
stypeandreleaseparameters - Implementation files correctly handle the parameters
- No default values relied upon, they were
- Consistent usage across different stepper implementations, maintained it is
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for calls to updateStepSize and updateSurfaceStatus
rg -A 2 "updateStepSize|updateSurfaceStatus" --type cpp
Length of output: 15542
Core/include/Acts/Propagator/MultiEigenStepperLoop.hpp (5)
183-187: Improved inheritance hierarchy, hmm yes!
From StepperPlainOptions to SingleStepper::Options, the inheritance changed has. Better encapsulation and reuse of existing functionality, this brings. Approve this change, I do.
507-508: New parameters for step control, wisdom they bring!
Added stype and release parameters, better control over step size updates they provide. Clear and purposeful, this change is.
Also applies to: 513-513
585-586: Consistent step size management across components, unified it is!
Template and non-template updateStepSize methods, same parameters they now share. Harmonious design, this brings.
Also applies to: 590-591, 613-613
596-597: Access to geometry context through options, safer it is!
Through state.options.geoContext, the geometry context accessed is. More maintainable and consistent with the new design, this approach is.
Also applies to: 602-602
Line range hint 227-244: Simplified state initialization, but verify component initialization we must!
Changed the constructor has been, to use Options instead of separate contexts. Careful we must be, about component initialization in the loop.
Run this verification script, we shall:
✅ Verification successful
The first attempt failed, yes. A broader search strategy, we must employ! Look for State constructor implementations and related test files, we shall. Help us understand the component initialization patterns better, this will.
Hmm, deeper we must look! The tests and implementation file, reveal the truth they will. The Force guides us to examine how components are initialized in practice, yes.
Safe the component initialization is, young padawan!
Examined the implementation deeply, I have. The Force reveals that:
- Proper initialization of components occurs through the weight and single parameters
- The magnetic field cache correctly created for each component it is
- Empty components check at the start, prevents invalid states it does
- Implementation in the IPP file shows robust component handling throughout the lifecycle
Trust in the code we can, for balanced and well-guarded the component initialization is. May the Force be with this implementation!
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for potential component initialization patterns
ast-grep --pattern 'State($_, $_, $_) {
$$$
components.push_back($_)
$$$
}'
Length of output: 83
Script:
#!/bin/bash
# Search for State constructor implementations with components
rg -U "State.*\(.*\).*\{[\s\S]*?components\.push_back" --type cpp -A 10
# Find all usages of MultiEigenStepperLoop
rg "MultiEigenStepperLoop" --type cpp
# Look for related test files
fd "MultiEigenStepperLoop.*Test" --type f
Length of output: 1863
Script:
#!/bin/bash
# Examine the test implementation for component initialization
rg -U "TEST.*MultiStepperLoop.*\{[\s\S]*?\}" Tests/UnitTests/Core/Propagator/MultiStepperTests.cpp -A 50
# Look at the implementation details in the IPP file
cat Core/include/Acts/Propagator/MultiEigenStepperLoop.ipp
# Check GSF tests for component initialization patterns
rg -U "TEST.*Gsf.*\{[\s\S]*?components" Tests/UnitTests/Core/TrackFitting/GsfTests.cpp -A 20
Length of output: 8350
Core/include/Acts/Propagator/StraightLineStepper.hpp (2)
56-59: Explicit constructor, wisdom shows! Approve this change, I do.
Clear intention and proper inheritance from StepperPlainOptions, this shows. Prevent accidental conversions, the explicit keyword does.
228-238: Verify step type handling, we should.
New parameters for step type and release, crucial they are. Ensure proper validation in all call sites, we must.
✅ Verification successful
Validated, the step type handling is. Correct usage, I sense.
Through the Force, seen I have that all steppers - StraightLine, Eigen, Atlas, and others - properly implement updateSurfaceStatus with the new parameters. In test cases and propagator implementation, consistent usage of ConstrainedStep::navigator and release parameter observed is. Unified through detail::updateSingleSurfaceStatus, the implementation across all steppers remains.
- In Propagator.ipp, correctly used the parameters are, with
ConstrainedStep::navigatorandtruefor release - In test cases, proper validation of step size constraints after surface status updates, there is
- Across all stepper implementations, consistent parameter handling through detail::updateSingleSurfaceStatus, maintained is
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for updateSurfaceStatus calls to verify parameter usage
rg -A 2 "updateSurfaceStatus.*stype.*release"
Length of output: 47
Script:
#!/bin/bash
# Search for updateSurfaceStatus calls with broader context
rg -A 5 "updateSurfaceStatus"
# Also search for the implementation details
ast-grep --pattern 'IntersectionStatus updateSurfaceStatus($$$)'
Length of output: 10917
Script:
#!/bin/bash
# Search for detail::updateSingleSurfaceStatus usage
rg -A 5 "detail::updateSingleSurfaceStatus"
Length of output: 2626
Script:
#!/bin/bash
# Find all files containing StraightLineStepper
fd StraightLineStepper --type f --exec rg -l "class StraightLineStepper" {} \;
Length of output: 138
Core/include/Acts/Propagator/AtlasStepper.hpp (4)
50-52: Approve the Options constructor implementation, I do.
Clean and proper initialization of base class StepperPlainOptions, it provides. Good practice in C++ inheritance, this is.
310-314: Simplified interface through Options, I see. Good, this is.
Cleaner API design achieved by consolidating parameters into Options. Approve this change, I do.
626-627: Consistent usage of options.geoContext, I observe. Approve this pattern, I do.
Proper encapsulation of geometry context through Options, achieved it is. Maintains consistency across the codebase.
Also applies to: 987-989
411-412: Added release parameter to updateSurfaceStatus, hmm. Verify its usage, we must.
Critical parameter for step size management, this is. Ensure proper handling throughout the propagation chain, we should.
Also applies to: 417-417, 421-421
✅ Verification successful
Let me search for this method's implementation and usage patterns, I must. Failed, the previous search did, but with a broader scope, succeed we might.
Consistent usage of release parameter across all steppers, I see. Safe, this change is.
Through the Force, observed I have that the release parameter:
- In all stepper implementations, consistently used it is
- In the Propagator's navigation logic, always set to
trueit remains - Through
detail::updateSingleSurfaceStatus, handled uniformly across implementations it is
Part of the standard stepper interface this parameter has become, hmm. In the StepperConcept requirements, defined properly it is. Verified, the implementation chain has been.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for updateSurfaceStatus calls to verify release parameter usage
rg -A 2 "updateSurfaceStatus.*release"
Length of output: 40
Script:
#!/bin/bash
# Search for updateSurfaceStatus method definition and usage
ast-grep --pattern 'updateSurfaceStatus($_)'
# Also search with ripgrep for broader context
rg "updateSurfaceStatus" -B 2 -A 5
Length of output: 13872
Script:
#!/bin/bash
# Search specifically in the AtlasStepper class
ast-grep --pattern 'class AtlasStepper {
$$$
updateSurfaceStatus($$$) {
$$$
}
$$$
}'
Length of output: 98
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (1)
Tests/UnitTests/Core/Propagator/StraightLineStepperTests.cpp (1)
333-339: Repeated surface intersection logic, refactor we should!Duplicate code in surface intersection tests, I sense. Extract common logic into helper function, we must. Improve readability and maintainability, this will.
Consider this helper function, you should:
+ auto intersectSurface(const Surface& surface, const Vector3& pos, + const Vector3& dir, const GeometryContext& context) { + return surface.intersect(context, pos, dir, BoundaryTolerance::Infinite()) + .closest(); + } - sls.updateStepSize(slsState, - targetSurface - ->intersect(tgContext, sls.position(slsState), - navDir * sls.direction(slsState), - BoundaryTolerance::Infinite()) - .closest(), - navDir, ConstrainedStep::navigator, false); + sls.updateStepSize(slsState, + intersectSurface(*targetSurface, sls.position(slsState), + navDir * sls.direction(slsState), tgContext), + navDir, ConstrainedStep::navigator, false);Also applies to: 342-348
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
Tests/UnitTests/Core/Propagator/AtlasStepperTests.cpp(14 hunks)Tests/UnitTests/Core/Propagator/EigenStepperTests.cpp(9 hunks)Tests/UnitTests/Core/Propagator/StraightLineStepperTests.cpp(6 hunks)Tests/UnitTests/Core/Propagator/SympyStepperTests.cpp(8 hunks)
🚧 Files skipped from review as they are similar to previous changes (2)
- Tests/UnitTests/Core/Propagator/EigenStepperTests.cpp
- Tests/UnitTests/Core/Propagator/SympyStepperTests.cpp
🔇 Additional comments (8)
Tests/UnitTests/Core/Propagator/StraightLineStepperTests.cpp (2)
76-78: Approve the state construction changes, I do!
Improved encapsulation through Options object, these changes bring. Cleaner interface and better separation of concerns, they achieve. Align with the PR objectives to decouple navigation from stepping, they do.
Also applies to: 84-84, 104-104, 110-110, 135-137, 139-139
152-152: Changed step size handling, approve I do!
From actor to navigator, the responsibility moves. Clear separation between navigation and stepping concerns, this brings. Hmmmm... Yes, yes.
Also applies to: 156-156
Tests/UnitTests/Core/Propagator/AtlasStepperTests.cpp (6)
15-15: LGTM! Added tolerance definitions include.
Wise addition, this include is. For tolerance-related functionality, necessary it becomes.
110-112: Consistent initialization of Options across test cases, I see.
Uniform pattern of Options initialization, you have created. Good practices in test organization, this shows.
Stepper::Options options(geoCtx, magCtx);
options.maxStepSize = stepSize;Also applies to: 137-139, 164-166, 183-185, 230-232, 255-257, 284-286, 310-312, 347-349, 387-389
588-592: Updated step size management with navigator constraint, hmm.
Clear separation between navigation and stepping concerns, this change brings. The force is strong with this refactoring.
402-404: Consistent parameter construction pattern observed.
Parameters construction and state copying, uniform approach you maintain. Good for maintainability, this is.
Also applies to: 412-412
446-446: Test state management through copyState helper.
Wise approach to test state management, using helper function you have chosen. Clean and maintainable, your tests remain.
612-615: Surface status and step size updates, properly tested they are.
Comprehensive test coverage for surface interactions and step size modifications, you have achieved. Three scenarios tested:
- Surface status update with infinite boundary tolerance
- Step size update with surface intersection
- Step size update with pre-existing user step size
Yet, verify the boundary cases we must.
Also applies to: 618-624, 629-635
✅ Verification successful
Let me examine the test coverage in other stepper implementations, I shall. Wisdom in comprehensive verification lies.
Well tested, these changes are, young padawan.
Through the Force, seen I have that all stepper implementations - Atlas, Eigen, StraightLine, and Sympy - possess similar test patterns they do. Consistent coverage across the implementations, there is:
- Basic step size updates with validation of previous and new values
- Surface status updates with infinite boundary tolerance
- Step size modifications in context of surface intersections
- User-defined step size scenarios
Identical boundary cases in all stepper tests, already covered they are. No additional verification needed, hmm.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for other test cases that might be affected by these changes
rg -l "updateSurfaceStatus|updateStepSize" --type cpp
Length of output: 846
Script:
#!/bin/bash
# Check test coverage for surface status and step size updates in other stepper tests
for file in Tests/UnitTests/Core/Propagator/*StepperTests.cpp; do
echo "=== $file ==="
rg -B 2 -A 2 "updateSurfaceStatus|updateStepSize" "$file"
done
Length of output: 6265
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Outside diff range and nitpick comments (5)
Tests/UnitTests/Core/SpacePointFormation/SpacePointBuilderTests.cpp (2)
50-51: Enhance the documentation clarity, we must.More descriptive, the function documentation should be. Parameters and return value, explain you should.
-/// Construct initial track parameters. +/// Construct initial track parameters with given kinematics. +/// @param phi The azimuthal angle +/// @param theta The polar angle +/// @param p The momentum magnitude +/// @param q The charge +/// @return CurvilinearTrackParameters initialized at origin with given kinematics
Line range hint
269-279: Structure the test output better, we should.Raw output to console, not the Jedi way it is. Boost test macros or structured logging, use you should.
- for (auto& sp : spacePoints) { - std::cout << "space point (" << sp.x() << " " << sp.y() << " " << sp.z() - << ") var (r,z): " << sp.varianceR() << " " << sp.varianceZ() - << std::endl; - } - std::cout << "space points produced with bad strips:" << std::endl; - for (auto& sp : spacePoints_extra) { - std::cout << "space point (" << sp.x() << " " << sp.y() << " " << sp.z() - << ") var (r,z): " << sp.varianceR() << " " << sp.varianceZ() - << std::endl; + BOOST_TEST_MESSAGE("Regular space points:"); + for (const auto& sp : spacePoints) { + BOOST_TEST_MESSAGE("Position: (" << sp.x() << ", " << sp.y() << ", " << sp.z() + << "), Variances (r,z): (" << sp.varianceR() << ", " + << sp.varianceZ() << ")"); + } + BOOST_TEST_MESSAGE("\nSpace points from bad strips:"); + for (const auto& sp : spacePoints_extra) { + BOOST_TEST_MESSAGE("Position: (" << sp.x() << ", " << sp.y() << ", " << sp.z() + << "), Variances (r,z): (" << sp.varianceR() << ", " + << sp.varianceZ() << ")");Core/include/Acts/Propagator/Navigator.hpp (3)
367-438: Clearer state transitions, desire we do!Complex state machine logic, difficult to follow it is. Extract state transitions to dedicated methods, we should.
Consider extracting state transition logic to dedicated methods:
+private: + NavigationTarget handleSurfaceTargeting(State& state) const { + if (!state.navSurfaceIndex.has_value()) { + resolveSurfaces(state, position, direction); + state.navSurfaceIndex = 0; + } else { + ++state.navSurfaceIndex.value(); + } + if (state.navSurfaceIndex.value() < state.navSurfaces.size()) { + return NavigationTarget(*state.navSurface().object(), + state.navSurface().index(), + BoundaryTolerance::None()); + } + state.navigationStage = Stage::layerTarget; + return NavigationTarget::None(); + }
605-607: Optimize the path, we must!Sorting navigation candidates repeatedly, performance impact it may have. Consider pre-allocating and maintaining sorted order.
Consider using a priority queue for maintaining sorted order:
using SurfaceQueue = std::priority_queue< SurfaceIntersection, std::vector<SurfaceIntersection>, decltype([](const auto& a, const auto& b) { return !SurfaceIntersection::pathLengthOrder(a, b); })>;
717-732: Simplify the path to inactivity, we shall!Multiple conditions and returns, clarity they lack. Combine conditions, we must.
Simplify the inactive check:
bool inactive(const State& state) const { - // Void behavior in case no tracking geometry is present - if (m_cfg.trackingGeometry == nullptr) { - return true; - } - - // Turn the navigator into void when you are instructed to do nothing - if (!m_cfg.resolveSensitive && !m_cfg.resolveMaterial && - !m_cfg.resolvePassive) { - return true; - } - - if (state.navigationBreak) { - return true; - } - - return false; + return m_cfg.trackingGeometry == nullptr || + (!m_cfg.resolveSensitive && !m_cfg.resolveMaterial && + !m_cfg.resolvePassive) || + state.navigationBreak; }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
Core/include/Acts/Propagator/Navigator.hpp(8 hunks)Tests/UnitTests/Core/Propagator/NavigatorTests.cpp(8 hunks)Tests/UnitTests/Core/SpacePointFormation/SpacePointBuilderTests.cpp(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- Tests/UnitTests/Core/Propagator/NavigatorTests.cpp
🧰 Additional context used
📓 Learnings (1)
Core/include/Acts/Propagator/Navigator.hpp (1)
Learnt from: paulgessinger
PR: acts-project/acts#3449
File: Core/include/Acts/Propagator/Navigator.hpp:153-153
Timestamp: 2024-12-13T08:31:09.422Z
Learning: The developer prefers to avoid using `-1` as a sentinel value in indices and considers using `std::optional<unsigned int>` as an alternative.
🔇 Additional comments (2)
Tests/UnitTests/Core/SpacePointFormation/SpacePointBuilderTests.cpp (1)
Line range hint 51-71: Approve this implementation, I do.
Well structured the function is, with clear units and reasonable defaults it has. Strong with the Force, this code is.
Core/include/Acts/Propagator/Navigator.hpp (1)
154-166: Wise choice, using std::optional is!
Replacing sentinel values with std::optional, a path to safer code it is. Previous feedback heeded well, you have.
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Outside diff range and nitpick comments (9)
Tests/UnitTests/Core/Propagator/MultiStepperTests.cpp (3)
168-169: Reduce duplication in Options initialization, we must.Repeated initialization of MultiOptions with maxStepSize, I see. Create a helper function, we should.
+template <typename Options> +Options makeDefaultOptions() { + Options options(geoCtx, magCtx); + options.maxStepSize = defaultStepSize; + return options; +}Also applies to: 201-202, 235-236, 283-284, 308-309, 385-386
466-476: Documentation for test helpers, missing it is.Complex test functions without documentation, difficult to understand they are. Add documentation we must.
Example documentation for one function:
+/** + * Tests the surface status update functionality of the MultiStepper + * + * @tparam multi_stepper_t The type of MultiStepper to test + * + * Verifies: + * - Surface intersection status updates + * - Step size calculations + * - Component-wise status propagation + */ template <typename multi_stepper_t> void test_multi_stepper_surface_status_update() {Also applies to: 583-593, 668-677, 768-774, 816-821
Line range hint
371-373: Incomplete tests for MultiEigenStepperSIMD, concerning this is.Missing test coverage for stepsize accessors with MultiEigenStepperSIMD, implement we must.
Help you with implementing these tests, I can. Create GitHub issue to track this task, shall I?
Core/include/Acts/Propagator/EigenStepper.ipp (1)
24-49: Strong with the Force, these changes are.Properly implement the decoupling of navigation and stepping, they do. Clean and consistent throughout the implementation, the changes are.
A suggestion for future improvements, I have:
- Consider extracting common state initialization logic into a shared helper, you should.
- Reduce duplication between steppers, this would.
Also applies to: 58-59, 69-69, 82-85, 138-138, 164-167
Core/include/Acts/Propagator/Navigator.hpp (2)
273-276: Unused parameter 'propagationDirection', explain its purpose we must!Direction of propagation, ignored it is. Either remove or use it, you should.
Consider adding a comment explaining why this parameter exists if truly needed it is.
367-438: Refactor the state machine logic, we should!Large and complex, this lambda is. Extract state handling into separate methods, we must. Clearer intent and easier testing, this will bring.
Consider this structure:
- auto tryGetNextTarget = [&]() -> NavigationTarget { + NavigationTarget tryGetNextTarget(State& state, const Vector3& position, + const Vector3& direction) const { + return tryTargetSurfaces(state, position, direction) + .or_else([&]() { return tryTargetLayers(state, position, direction); }) + .or_else([&]() { return tryTargetBoundaries(state, position, direction); }) + .value_or(NavigationTarget::None()); + }Core/include/Acts/Propagator/StraightLineStepper.hpp (1)
Line range hint
172-175: Replace magic number with named constant, we must!A magic number
.000000000000001, I see. Clarity and maintainability, a named constant would bring.+ // Minimum allowed absolute value for charge over momentum + static constexpr double MIN_QOVERP = 1e-15; + if (std::abs(pVector[7]) < .000000000000001) { - pVector[7] < 0. ? pVector[7] = -.000000000000001 - : pVector[7] = .000000000000001; + pVector[7] < 0. ? pVector[7] = -MIN_QOVERP + : pVector[7] = MIN_QOVERP;Core/include/Acts/Propagator/AtlasStepper.hpp (2)
142-314: Document the coordinate transformations, we should!Complex coordinate transformation logic, this contains. Additional comments explaining the mathematical operations, helpful they would be.
Add documentation blocks explaining:
- The transformation between coordinate systems
- The meaning of each vector component
- The mathematical formulas used
987-989: Cache the surface center, we must!Multiple accesses to surface center, I see. Performance improvement, caching would bring.
+ const auto& center = surface.center(state.options.geoContext); - double x = P[0] - surface.center(state.options.geoContext).x(); - double y = P[1] - surface.center(state.options.geoContext).y(); - double z = P[2] - surface.center(state.options.geoContext).z(); + double x = P[0] - center.x(); + double y = P[1] - center.y(); + double z = P[2] - center.z();
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (14)
Core/include/Acts/Propagator/AtlasStepper.hpp(13 hunks)Core/include/Acts/Propagator/EigenStepper.hpp(7 hunks)Core/include/Acts/Propagator/EigenStepper.ipp(6 hunks)Core/include/Acts/Propagator/MultiEigenStepperLoop.hpp(10 hunks)Core/include/Acts/Propagator/Navigator.hpp(8 hunks)Core/include/Acts/Propagator/StraightLineStepper.hpp(6 hunks)Core/include/Acts/Propagator/SympyStepper.hpp(6 hunks)Core/src/Propagator/SympyStepper.cpp(5 hunks)Tests/UnitTests/Core/Propagator/AtlasStepperTests.cpp(14 hunks)Tests/UnitTests/Core/Propagator/EigenStepperTests.cpp(9 hunks)Tests/UnitTests/Core/Propagator/JacobianTests.cpp(1 hunks)Tests/UnitTests/Core/Propagator/MultiStepperTests.cpp(21 hunks)Tests/UnitTests/Core/Propagator/StraightLineStepperTests.cpp(7 hunks)Tests/UnitTests/Core/Propagator/SympyStepperTests.cpp(8 hunks)
🚧 Files skipped from review as they are similar to previous changes (3)
- Tests/UnitTests/Core/Propagator/EigenStepperTests.cpp
- Tests/UnitTests/Core/Propagator/SympyStepperTests.cpp
- Core/include/Acts/Propagator/MultiEigenStepperLoop.hpp
🧰 Additional context used
📓 Learnings (1)
Core/include/Acts/Propagator/Navigator.hpp (1)
Learnt from: paulgessinger
PR: acts-project/acts#3449
File: Core/include/Acts/Propagator/Navigator.hpp:153-153
Timestamp: 2024-12-13T08:31:09.422Z
Learning: The developer prefers to avoid using `-1` as a sentinel value in indices and considers using `std::optional<unsigned int>` as an alternative.
🔇 Additional comments (22)
Core/src/Propagator/SympyStepper.cpp (4)
26-49: Approve this change, I do.
Clean and well-structured, the implementation is. Follows the pattern of EigenStepper, it does, and aligns with decoupling objectives, it does.
58-59: Correct usage of options.geoContext, this is.
Consistent with the new approach, the change is. Maintains functionality while improving structure, it does.
82-85: Consistent with the pattern, this change is.
Properly uses state.options.geoContext, it does. Maintain functionality while improving structure, it does.
Line range hint 164-167: Follows the established pattern, this does.
Correctly uses state.options.geoContext, it does. Complete, the transformation to the new structure is.
Tests/UnitTests/Core/Propagator/JacobianTests.cpp (1)
135-141: Well-structured test changes, these are.
Properly test the new Options-based interface, they do. Maintain test coverage while adapting to new structure, they do.
Core/include/Acts/Propagator/SympyStepper.hpp (4)
41-43: LGTM! Proper initialization of base class, it has.
Clean and concise constructor implementation for Options struct, this is. Base class initialization with geometry and magnetic field contexts, it handles well.
61-62: LGTM! State constructor simplified and improved, it is.
Wise decision to use Options object and std::move for field cache, this is. Memory efficiency and cleaner interface, it brings.
210-220: LGTM! Surface status update method, improved it is.
Added parameters for step type and release control, better flexibility they provide. Consistent with other steppers in codebase, this implementation is.
232-241: LGTM! Step size update method, well structured it is.
Clear parameter handling and proper step size management, this implementation shows. Direction parameter properly handled through void cast, unnecessary warnings it prevents.
Core/include/Acts/Propagator/EigenStepper.hpp (2)
62-64: Similar to SympyStepper, this implementation is.
Options constructor and base class initialization, identical pattern they follow.
82-84: State constructor, mirrors SympyStepper it does.
Same pattern of using Options object and moving field cache, implemented here it is.
Tests/UnitTests/Core/Propagator/StraightLineStepperTests.cpp (3)
76-78: LGTM! Test setup properly adapted, it is.
Wise initialization of options with proper contexts and step size, this test shows.
326-329: LGTM! Surface status test coverage, complete it is.
Proper verification of surface status updates with new parameters, these tests provide. Step size constraints and navigation control, well tested they are.
332-347: LGTM! Step size updates, thoroughly tested they are.
Multiple scenarios for step size updates, covered well they are. Both with and without release flag, tested properly they become.
Core/include/Acts/Propagator/Navigator.hpp (2)
154-166: Wise choice, using std::optional for indices is!
A step in the right direction, this change is. But careful with unchecked access, we must be.
Previous review wisdom about guarding std::optional::value(), still applies it does.
570-607: 🛠️ Refactor suggestion
Validate input parameters, we must!
Direction vector, normalized it should be. Position vector, valid it must be.
Add validation at the start of resolution:
void resolveSurfaces(State& state, const Vector3& position,
const Vector3& direction) const {
+ if (!direction.isUnitary(1e-7)) {
+ throw std::invalid_argument(
+ "Direction vector must be normalized, received: " + toString(direction));
+ }
+
ACTS_VERBOSE(volInfo(state) << "Searching for compatible surfaces.");Likely invalid or redundant comment.
Core/include/Acts/Propagator/StraightLineStepper.hpp (3)
Line range hint 50-53: Approve the Options constructor, I do!
Proper initialization of the base class, this constructor ensures. Good practice in C++, this is.
65-72: Wise changes to the State struct, these are!
Improved encapsulation through Options storage and particle hypothesis support, we have achieved. Clear and maintainable, the code becomes.
Line range hint 411-440: Approve the method signature changes, I do!
Explicit parameters over implicit defaults, wisdom shows. Clearer API contract, this brings.
Tests/UnitTests/Core/Propagator/AtlasStepperTests.cpp (2)
Line range hint 105-140: Well-adapted test cases, these are!
Updated to reflect the new Options-based initialization, the test cases have been. Thorough testing of the changes, this ensures.
578-592: Approve the step size test changes, I do!
Adapted to use ConstrainedStep::navigator, the tests have been. Alignment with the new step size management approach, this shows.
Core/include/Acts/Propagator/AtlasStepper.hpp (1)
50-70: Consistent changes across steppers, these are!
Mirror the modifications in StraightLineStepper.hpp, these changes do. Uniformity in the codebase, this brings.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (1)
Core/src/Geometry/TrackingGeometry.cpp (1)
Line range hint
1-93: Broader refactoring vision, discuss we must!A step towards navigator independence, this change is. But remember these principles, you should:
- Surface candidates only, the navigator should provide
- Step size decisions, to the stepper they belong
- Clear boundaries between components, maintain we must
Strong in the Force, this refactoring path is. Template reduction and cleaner interfaces, bring it will.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
Core/src/Geometry/TrackingGeometry.cpp(2 hunks)
🔇 Additional comments (2)
Core/src/Geometry/TrackingGeometry.cpp (2)
11-11: Wise addition of tolerance header, this is!
Aligned with the decoupling efforts, this include is. Surface tolerance parameters, essential they have become, hmm.
41-41: Verify impact on navigation precision and performance, we must!
Changed, the surface tolerance propagation has. Through the geometry hierarchy, it now flows. But careful we must be, yes.
Run this verification, we shall:
Consider caching tolerance calculations if frequently accessed, you should. Performance impact, minimize we must.
✅ Verification successful
Hmm, clear now, the surface tolerance usage is! Verified, the changes are.
Through the Force, I sense:
- Used primarily in test cases for validation and surface intersection checks, the tolerance is
- In navigation components, properly propagated through the geometry hierarchy, it now flows
- No performance impact detected, as caching already exists in the navigation system
The change in TrackingGeometry.cpp follows established patterns across the codebase, maintaining consistency with other geometry components, yes.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Search for other usages of surface tolerance in navigation
# Search for surface tolerance usage patterns
rg -A 3 "s_onSurfaceTolerance"
# Look for related navigation tests
ast-grep --pattern 'TEST_CASE($_, "Navigation") {
$$$
}'
Length of output: 45053
|
Add navigator concept |
Currently the GSF actor communicates the abort flag via the navigation break which is not ideal. I want to remove setting this flag from outside in #3449. The GSF can carry this flag by itself and after the actor+aborter refactor we do not need a separate aborter anymore. pulled out of #3449 <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **New Features** - Introduced a new method to check if navigation should be aborted based on processed measurements. - **Improvements** - Updated navigation handling in the fitting process by removing the `NavigationBreakAborter` struct. - Refined geo context management in multiple methods for better clarity and consistency. <!-- end of auto-generated comment: release notes by coderabbit.ai -->
After a reset in the CKF we need to adjust the target limit again to make sure the next step picks it up. I don't think we hit this case yet but it is good to have it anyways. pulled out of #3449 <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **New Features** - Enhanced functionality for managing path limits and target surfaces in the filtering process. - Improved error handling and state management during track finding. - **Bug Fixes** - Refined logic for processing new track states and handling outlier states. - **Documentation** - Minor adjustments to comments and logging for improved clarity. <!-- end of auto-generated comment: release notes by coderabbit.ai -->
|
This is a proposal to decouple navigation from stepping by
Propagatorin 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
New Features
NavigationTargetstruct to encapsulate surface navigation information.Optionsstructure for configuration.maxTargetSkippingparameter to control target resolution behavior.ImpactPointEstimatorwith new checks for parameter compatibility.Options.SimulationActorto improve step size update logic.Bug Fixes
Documentation
Tests
ImpactPointEstimatorto validate parameter compatibility and propagation behavior.MultiStepperLoopto enhance configurability.Chores