Allow kaon physics to be configurable at runtime by the user - #108
Conversation
bryngemark
left a comment
There was a problem hiding this comment.
Overall looks like a great, clear implementation of changing kaon properties. I just have the one neutral kaons comment.
| * produced in the simulation, in particular setting their lifetime and | ||
| * branching ratios | ||
| * | ||
| * @note Only affects charged kaons, but similar changes could be added for the |
There was a problem hiding this comment.
Right here, or in a separate class? Would it make sense to add neutrals while we're at it? If not, should we call this ChargedKaonPhysics? I'm trying to make sure future me is not confused by this and I can imagine several ways. My preference would be to deal with all kaons here if it is easy enough, and just toggle which kaons one would like to modify with a configuration parameter.
There was a problem hiding this comment.
Right, that's a good point. It won't be as "clean" with the neutral kaons since they don't have symmetric decay channels like the charged ones do but it is straight forward to do
There was a problem hiding this comment.
Should be there now!
tomeichlersmith
left a comment
There was a problem hiding this comment.
This is so cool! Thank you for looking into this so quickly :) I am very excited that we can move this specialization into runtime from compile-time.
Most of my comments are just thoughts and not really necessary changes.
|
Ok after some minor bugs in the updated python config, I've tested and it handles all the edge cases well (e.g. BR sum > 1, BR sum << 1, negative lifetimes and whatnot) and the upKaons call works! |
This PR adds the ability to change the kaon physics at runtime by modifying the properties of the
G4KaonMinusandG4KaonPlusparticle definitions rather than doing it manually in the Geant4 sources. This should significantly simplify the study of challenging kaon backgrounds, especially together with techniques like https://ldmx-software.github.io/Alternative-Photo-Nuclear-Models.htmlI also add "Decay" as one of the processes registered in the ProcessMap so that you can tell that a daughter particle came from a decay.
To verify that this works, I used a configuration like the following and some checks in the SimObjects DQM code to check basic things like "if I force only one decay type, I always get daughter particles of that type" etc
This resolves #106 and part of #107