- Improve handling of phase-space generation for cases of decays having e+e- pair to make RareLbToLll model useable.
- Some code modernization of RareLbToLll to make things const where they are constant and pass const references instead of raw pointers in most places.
Details
Tested locally that nothing changes for Lz mu mu final state. In case of Lb --> Lz e+ e-, without this change model is effectively unuseable as maximum probability gets too high and accept-reject fails to find working configuration in 1000 trials. After change code can generate 1M events without any issue and gives expected q2 distribution. I'm not adding test as I will do this directly to new framework.
Diff Detail
- Repository
- rEVTGEN evtgen
- Branch
- lb_lee_improvement
- Lint
No Lint Coverage - Unit
No Test Coverage - Build Status
Buildable 221 Build 221: arc lint + arc unit
Event Timeline
Changes look OK. It is good to see unnecessary pointers being removed. Just have a few minor suggestions.
EvtGenModels/EvtRareLbToLll.hh | ||
---|---|---|
63 | Need to run clang-formatting to have extra space inside braces? | |
src/EvtGenModels/EvtRareLbToLll.cpp | ||
287 | Should we remove the static here? Hopefully there are no other statics used in this model? | |
src/EvtGenModels/EvtRareLbToLllFFlQCD.cpp | ||
119 | This could be const as well. |
Thanks Michal, this indeed looks like a good set of clean-ups as well as the actual physics improvement.
Just a few inline suggestions for further small clean-ups, fixes, etc.
EvtGenBase/EvtParticle.hh | ||
---|---|---|
174 | A const member function should not return a non-const pointer to a member since it allows the client to subsequently modify the internal state. As such it is better to have two versions of the function, a const function that returns a const pointer and a non-const function that returns a non-const pointer. | |
src/EvtGenBase/EvtParticle.cpp | ||
91 | As per comment on the header, we need two versions of the function for const-correctness reasons. | |
src/EvtGenModels/EvtRareLbToLll.cpp | ||
133–134 | Would be good to at least initialise these to 0 here, or better move their declarations to where they are first used so they are initialised there. | |
142 | These loop counters should be declared in the loop init-statement not here. |