-
Notifications
You must be signed in to change notification settings - Fork 4.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix condition to add anti-particle to G4ParticleTable #42957
Conversation
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-42957/37106
|
A new Pull Request was created by @sarafiorendi for master. It involves the following packages:
@mdhildreth, @cmsbuild, @civanch can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
please test |
+1 Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-4fc8bf/35067/summary.html Comparison SummarySummary:
|
type bug |
+1 |
This pull request is fully signed and it will be integrated in one of the next master IBs (tests are also fine). This pull request will now be reviewed by the release team before it's merged. @rappoccio, @sextonkennedy, @antoniovilela (and backports should be raised in the release meeting by the corresponding L2) |
+1 |
PR description:
This PR is to fix the behaviour of the CustomParticleFactory class in order to correctly include the corresponding anti-particle each time a new particle is added to the list.
The correct behaviour was somehow broken with this commit which reverted the condition necessary to call the addCustomParticle() function (which should add the anti-particle to the particle table).
So in the current releases the function will be called only if the anti-particle is already there.
As an example, in my case I needed to add the stau and anti-stau particles, but only the stau was added, while the anti-stau was not, with a series of consequences in the following steps (e.g., charge was set to 0, anti-stau track non added to the SIM track collection, etc...)
FYI @civanch
PR validation:
Testing locally. For example, I was previously getting this printout when checking particle info here
and with the fix I get the expected behaviour
If this PR is a backport please specify the original PR and why you need to backport that PR. If this PR will be backported please specify to which release cycle the backport is meant for:
I think we need to backport this change also to other release cycles, for sure to 12_4_X used for Run3Summer22(EE) MC production.
The behaviour is correct in the 10_6_X cycle used for UL MC production (see here).