-
Notifications
You must be signed in to change notification settings - Fork 168
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!: Remove smoothing and extrapolation from core CKF #2722
refactor!: Remove smoothing and extrapolation from core CKF #2722
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #2722 +/- ##
==========================================
+ Coverage 48.99% 49.01% +0.02%
==========================================
Files 490 491 +1
Lines 28996 28886 -110
Branches 13743 13685 -58
==========================================
- Hits 14206 14159 -47
+ Misses 4951 4938 -13
+ Partials 9839 9789 -50 ☔ View full report in Codecov by Sentry. |
📊: Physics performance monitoring for 8e11c91physmon summary
|
…ndiwand/acts into remove-ckf-smoothing-and-extrapolation
Please add diff to description as discussed |
…ve-ckf-smoothing-and-extrapolation
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.
Let's go!
While working on the CKF I encountered the problem that track state components need to be created when the track state is created. Since the CKF will not smooth anymore after #2722 the user might want to add smoothed states to the existing track states without reallocating and copying all the existing states. In case of the vector implementation the components will not be next to each other in the memory.
Since the CKF is not responsible for smoothing anymore it should not allocate these components on the track state. #2722
…ct#3075) While working on the CKF I encountered the problem that track state components need to be created when the track state is created. Since the CKF will not smooth anymore after acts-project#2722 the user might want to add smoothed states to the existing track states without reallocating and copying all the existing states. In case of the vector implementation the components will not be next to each other in the memory.
…s-project#3086) Since the CKF is not responsible for smoothing anymore it should not allocate these components on the track state. acts-project#2722
…ject#2722) After acts-project#2539 I want to finally refactor the CKF and remove the smoothing and the reference surface targeting from the core algorithm in order to make it more composable and less complicated. Before the CKF was basically only usable with smoothing turned on otherwise we would not receive any tracks. Now it always runs without smoothing and the user can decide what and how to smooth. Afterwards the user can decide which track state they want to extrapolate to a reference surface if necessary. IMO this makes the algorithm flow much easier to comprehend and gives the user more flexibility. This also makes an implementation of a two way finding easier as discovered in acts-project#2717 blocked by - acts-project#2723 --- Users can smooth and extrapolate tracks after the CKF returns them. Extrapolation can be achieved using the `Propagator` while smoothing can be done by the `GainMatrixSmoother`. For convenience this PR also includes helper functions to smooth and extrapolate single tracks or a whole track container. Example of smoothing and extrapolating tracks after the CKF https://github.com/acts-project/acts/blob/98186891d4bdc5b211f6af3e96ca59ace7c315cc/Examples/Algorithms/TrackFinding/src/TrackFindingAlgorithm.cpp#L172-L189
…ct#3075) While working on the CKF I encountered the problem that track state components need to be created when the track state is created. Since the CKF will not smooth anymore after acts-project#2722 the user might want to add smoothed states to the existing track states without reallocating and copying all the existing states. In case of the vector implementation the components will not be next to each other in the memory.
…s-project#3086) Since the CKF is not responsible for smoothing anymore it should not allocate these components on the track state. acts-project#2722
…ject#2722) After acts-project#2539 I want to finally refactor the CKF and remove the smoothing and the reference surface targeting from the core algorithm in order to make it more composable and less complicated. Before the CKF was basically only usable with smoothing turned on otherwise we would not receive any tracks. Now it always runs without smoothing and the user can decide what and how to smooth. Afterwards the user can decide which track state they want to extrapolate to a reference surface if necessary. IMO this makes the algorithm flow much easier to comprehend and gives the user more flexibility. This also makes an implementation of a two way finding easier as discovered in acts-project#2717 blocked by - acts-project#2723 --- Users can smooth and extrapolate tracks after the CKF returns them. Extrapolation can be achieved using the `Propagator` while smoothing can be done by the `GainMatrixSmoother`. For convenience this PR also includes helper functions to smooth and extrapolate single tracks or a whole track container. Example of smoothing and extrapolating tracks after the CKF https://github.com/acts-project/acts/blob/98186891d4bdc5b211f6af3e96ca59ace7c315cc/Examples/Algorithms/TrackFinding/src/TrackFindingAlgorithm.cpp#L172-L189
…ct#3075) While working on the CKF I encountered the problem that track state components need to be created when the track state is created. Since the CKF will not smooth anymore after acts-project#2722 the user might want to add smoothed states to the existing track states without reallocating and copying all the existing states. In case of the vector implementation the components will not be next to each other in the memory.
…s-project#3086) Since the CKF is not responsible for smoothing anymore it should not allocate these components on the track state. acts-project#2722
After #2539 I want to finally refactor the CKF and remove the smoothing and the reference surface targeting from the core algorithm in order to make it more composable and less complicated.
Before the CKF was basically only usable with smoothing turned on otherwise we would not receive any tracks. Now it always runs without smoothing and the user can decide what and how to smooth. Afterwards the user can decide which track state they want to extrapolate to a reference surface if necessary.
IMO this makes the algorithm flow much easier to comprehend and gives the user more flexibility. This also makes an implementation of a two way finding easier as discovered in #2717
blocked by
MaterialInteractor
noise mode independent from direction #2723Users can smooth and extrapolate tracks after the CKF returns them. Extrapolation can be achieved using the
Propagator
while smoothing can be done by theGainMatrixSmoother
.For convenience this PR also includes helper functions to smooth and extrapolate single tracks or a whole track container.
Example of smoothing and extrapolating tracks after the CKF
acts/Examples/Algorithms/TrackFinding/src/TrackFindingAlgorithm.cpp
Lines 172 to 189 in 9818689