refactor: Remove duplicatedPredictor from CKFPerformanceWriter
#2964
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
@Corentin-Allaire did you add this? |
No that is not from me (I don't do duplicate predication anywhere). I do remember someone (a student?) working on that a very long time ago (I want to say with Moritz but I am not 100% sure) |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #2964 +/- ##
=======================================
Coverage 48.78% 48.78%
=======================================
Files 493 493
Lines 28914 28914
Branches 13752 13752
=======================================
Hits 14105 14105
Misses 4909 4909
Partials 9900 9900 ☔ View full report in Codecov by Sentry. |
📊: Physics performance monitoring for e136c71physmon summary
|
kodiakhq bot
pushed a commit
that referenced
this pull request
Mar 19, 2024
An attempt to move to a central truth matching in the Examples framework. Currently all our writers have a separate truth matching implementation with some amount of common code. I propose to move the truth matching to its own algorithm and then use the output as an input for the writers. This also allows for simple truth matching in case of truth tracking to be specialized and for a common mechanism for how we infer the truth information. E.g. some algorithms right now expect particles and tracks in a 1:1 correspondence in the input containers which is not achievable with CKF tracking. blocked by - #2964
EleniXoch
pushed a commit
to EleniXoch/acts
that referenced
this pull request
May 6, 2024
…cts-project#2964) This came to my attention while working on acts-project#2904. I do not see this used anywhere and too specific for a general purpose tracking performance writer. If we want to classify duplicated tracks we should do that before writing the performance in a specific deduplication algorithm (like the ambiguity resolution https://github.com/acts-project/acts/blob/84c039fd8bd7cf3a7a18d5d66b1e662aa5e2e9f3/Examples/Algorithms/AmbiguityResolution/include/ActsExamples/AmbiguityResolution/GreedyAmbiguityResolutionAlgorithm.hpp#L36).
EleniXoch
pushed a commit
to EleniXoch/acts
that referenced
this pull request
May 6, 2024
…#2904) An attempt to move to a central truth matching in the Examples framework. Currently all our writers have a separate truth matching implementation with some amount of common code. I propose to move the truth matching to its own algorithm and then use the output as an input for the writers. This also allows for simple truth matching in case of truth tracking to be specialized and for a common mechanism for how we infer the truth information. E.g. some algorithms right now expect particles and tracks in a 1:1 correspondence in the input containers which is not achievable with CKF tracking. blocked by - acts-project#2964
asalzburger
pushed a commit
to asalzburger/acts
that referenced
this pull request
May 21, 2024
…cts-project#2964) This came to my attention while working on acts-project#2904. I do not see this used anywhere and too specific for a general purpose tracking performance writer. If we want to classify duplicated tracks we should do that before writing the performance in a specific deduplication algorithm (like the ambiguity resolution https://github.com/acts-project/acts/blob/84c039fd8bd7cf3a7a18d5d66b1e662aa5e2e9f3/Examples/Algorithms/AmbiguityResolution/include/ActsExamples/AmbiguityResolution/GreedyAmbiguityResolutionAlgorithm.hpp#L36).
asalzburger
pushed a commit
to asalzburger/acts
that referenced
this pull request
May 21, 2024
…#2904) An attempt to move to a central truth matching in the Examples framework. Currently all our writers have a separate truth matching implementation with some amount of common code. I propose to move the truth matching to its own algorithm and then use the output as an input for the writers. This also allows for simple truth matching in case of truth tracking to be specialized and for a common mechanism for how we infer the truth information. E.g. some algorithms right now expect particles and tracks in a 1:1 correspondence in the input containers which is not achievable with CKF tracking. blocked by - acts-project#2964
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This came to my attention while working on #2904. I do not see this used anywhere and too specific for a general purpose tracking performance writer.
If we want to classify duplicated tracks we should do that before writing the performance in a specific deduplication algorithm (like the ambiguity resolution
acts/Examples/Algorithms/AmbiguityResolution/include/ActsExamples/AmbiguityResolution/GreedyAmbiguityResolutionAlgorithm.hpp
Line 36 in 84c039f