Skip to content

Fix handling of MC truth for tracks undergoing nuclear reactions#539

Open
SeverinDiederichs wants to merge 2 commits intoapt-sim:masterfrom
SeverinDiederichs:fix_handling_of_nuclearreturns
Open

Fix handling of MC truth for tracks undergoing nuclear reactions#539
SeverinDiederichs wants to merge 2 commits intoapt-sim:masterfrom
SeverinDiederichs:fix_handling_of_nuclearreturns

Conversation

@SeverinDiederichs
Copy link
Copy Markdown
Collaborator

This PR is based on #583 and should be reviewed only after that one is merged.
This PR fixes #533.

Before, the tracks undergoing the nuclear reactions were sent back as a leaked track. However, additionally also a GPUHit was sent back (in most cases).

The GPUHit was used to call the UserActions and the SD code, which was executed first. The nuclear reaction was then done on the track, when the leaked tracks were handled. That means, that the SD code was called before the nuclear reaction was actually done, leading to missing secondaries or wrong direction / energy in the final state in case of lepton nuclear reactions.

This problem is fixed by instead only sending back a GPUHit and not a leaked track anymore for the nuclear reactions (the GPUHit contains all the necessary information). However, in order to have the same RNG and to be reproducible, the GPUHit must still be deferred and handled only at the very end. The deferred nuclear step also has a TrackData struct, such that the sorting can be done together with the returned tracks. This ensures the exact same RNG ordering as on the current master branch. Note that in principle it would not be needed, one could also just sort the deferred nuclear steps and the returned tracks individually and process them one by one.
However, that would change the RNG, so it should not be done in this PR, because currently, the edep_per_volume in the drift tests is untouched, only the expected MC truth histograms change, which were previously missing the secondaries that were not linked to the parents correctly.

Note:
The following change was required for lepton nuclear reactions: the hostTrackData of a dying lepton nuclear track can not be deleted, because the GPUHit of a possible lepton nuclear reaction might be deferred. I.e., the lepton nuclear track might die, delete the hostTrackData, and then the deferred GPUHit is calling the SD code with a dangling hostTrackData. Thus, a new flag of a pending nuclear reaction is added, in that case the HostTrackData should not be deleted.

This PR gives a slight run time improvement in the validation tests, as less data needs to be transferred back.
The PR does change the physics results, as it fixes the incorrect handling of the MC truth, however it does not change the energy deposition

It was verified that this PR

  • Changes physics results
  • Does not change physics results

@SeverinDiederichs SeverinDiederichs added the bug Type: Something isn't working label Apr 9, 2026
@phsft-bot
Copy link
Copy Markdown

Can one of the admins verify this patch?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Type: Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Inconsistency in track reconstruction for gamma/lepton nuclear

2 participants