-
Notifications
You must be signed in to change notification settings - Fork 52
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
Record track quality to the CKF tracks #844
Conversation
335392a
to
140e39a
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm generally on board. Code-wise I like how you did things.
But do you have some measurements to what it does to our runtime performance? I understand that the KF should become faster (not necessary?) after this. But do you have any quantitative numbers on that? 🤔
No this PR is not for performance improvement. |
Sorry if this is a stupid question, but do we have/plan to add a GPU ambi solver or is this a CPU-only development? |
If we end up running the ambiguity resolution between the CKF and the KF we will want to build a GPU ambiguity resolver. |
I will move the current cpu amisolver to between ckf and kf, and implement the gpu ambl-solver in a similar fasion |
Can I go with the PR? There are still some PRs left before I can move the ambiguity resolver between the CKF and KF. There is no big difference in performance. Anyway this PR itself is not for performance improvement Main
This PR
|
|
Undo some changes from #844
track quality is the struct for the NDF, chi2 and the number of holes.
This has been recorded in the KF but we can also calculate it for the CKF.
This will allow us to apply the ambiguity resolution to the CKF output directly, and reduce the KF time significantly.