initialize safety in InitTracks - #682
Conversation
|
@codex review |
|
/run-test |
|
Codex Review: Didn't find any major issues. Hooray! Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
|
Can one of the admins verify this patch? |
|
The failure in the CI is bad luck: We currently running 60k primaries with a threshold of rejection of 1% between the result of the PR and the high statistics result stored from G4HepEm.
Therefore, the number of primaries should be increased to make these failures appear less often |
As it was observed in #682 and explained in [this comment](#682 (comment)), the CI can fail due to bad luck on the seed. Increasing the number of primaries reduces the risk of those random failure
0d74a98 to
0a73d84
Compare
|
/run-test |
This PR implements the first step of #681:
When initializing the tracks that come from the CPU on the device asynchronously, their safety is already calculated, thus reducing the amount of safety calculation in HowFar. Note that in this initial approach in a bad case when the new calculated safety is still smaller than the physics limit, the safety would be calculated both in the InitTracks and HowFar, but as the init tracks is fully hidden, it is considered negligible for this first implementation, as this will be changed in the subsequent steps of #681.