-
Notifications
You must be signed in to change notification settings - Fork 171
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
test: Check if we end up in the expected volume in Gen1 Navigator
#3442
test: Check if we end up in the expected volume in Gen1 Navigator
#3442
Conversation
I really like the idea to have this (conditionally) be a hard failure. One alternative to the On another note: we force-enable |
Problem with the GSF and GX2F can be observed here @benjaminhuth @AJPfleger |
I did not really think of the CI. We have to see how bad it is. But I would trade some performance for this because otherwise we might just not end up checking this at all |
…eck-inside-volume
physmon ttbar changes because we now cut on different particles |
Quality Gate passedIssues Measures |
I might have fixed the gx2f issue with ready to update? :) |
@AJPfleger it is now failing inside the unit test
|
…eck-inside-volume
This is not blocked by #3481. |
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.
Looks good in general :)
…cts into navigator-check-inside-volume
Quality Gate passedIssues Measures |
I think this is one of the big navigation pitfalls. If we end up in the wrong volume the navigation is practically lost. This is too expensive to check in production so I opted for an
assert
.Not sure if that is a great solution since users might try to measure performance with non release build by accident. But that was the only way I could think of.
blocked by
nullptr
if outside tracking geometry inTrackingGeometry::lowestTrackingVolume
#3481