-
Notifications
You must be signed in to change notification settings - Fork 173
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!: Disambiguate surface intersection solutions #2336
refactor!: Disambiguate surface intersection solutions #2336
Conversation
Codecov Report
@@ Coverage Diff @@
## main #2336 +/- ##
==========================================
+ Coverage 49.81% 49.88% +0.06%
==========================================
Files 466 466
Lines 26190 26232 +42
Branches 12009 12014 +5
==========================================
+ Hits 13047 13086 +39
+ Misses 4620 4614 -6
- Partials 8523 8532 +9
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
…ambiguate-intersection
…ambiguate-intersection
this is causing navigation failure in the |
this seems to work now - even tho I am not super happy with the fix but I don't see an alternative |
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.
these are the new changes in question
Is this why the physmon still shows differences? |
I just didn't update the reference yet because I was unsure if this one or #2470 should go in first |
This does break compilation in the material track writer in Athena. |
reopened #2318 after #2321 The CKF did not pick up the material in-between the first surface and the target surface. This PR is trying to fix that. Note: I had to use a not so nice hack and call the navigation pre step routine before we step towards the target. I don't see an easy way around that. blocked by - #2336
…2336) Currently our intersection call can give an alternative solution but it is not clear which one is to be preferred in which situation and the results are unstable meaning that it could be swapped depending on where you are on the ray. Here I try to make the interface cleaner and the intersection order stable. blocked by - acts-project#2366 - acts-project#2368 --------- Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com> Co-authored-by: Benjamin Huth <37871400+benjaminhuth@users.noreply.github.com> Co-authored-by: Benjamin Huth <benjamin.huth@physik.uni-regensburg.de> Co-authored-by: Paul Gessinger <hello@paulgessinger.com>
reopened acts-project#2318 after acts-project#2321 The CKF did not pick up the material in-between the first surface and the target surface. This PR is trying to fix that. Note: I had to use a not so nice hack and call the navigation pre step routine before we step towards the target. I don't see an easy way around that. blocked by - acts-project#2336
Currently our intersection call can give an alternative solution but it is not clear which one is to be preferred in which situation and the results are unstable meaning that it could be swapped depending on where you are on the ray.
Here I try to make the interface cleaner and the intersection order stable.
blocked by