correctly compute energy even after event data update (e.g. via quenc… #110
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I noticed a problem when computing observables such as energy deposition via the
TRestGeant4AnalysisProcessafter the geant4 event has been modified (for example via the quenching process). Even though the process updates the energy of each individual hit, the energy deposited is retrieved from a pre-computed store. This is done for efficiency but it can be problematic as processes that modify the event will also need to update these stores.On top of that, currently there are two stores that serve a similar purpose: one only for energy in volume, one newer that serves for everything and gets proyected into whatever the user requests (energy per particle, per process, etc.). The newer store is more computationally expensive but at the end both are fast enough not to be a problem. We should aim to remove this redundancy (I tried but it was very complex, it needs a deep revision).
In general the problem lies with the usage of volume ids (which can be active volume ids or just volume ids...) instead of just using the volume names (which would lower confusion). I think we should just use volume names everywhere possible unless there is a good reason not to.