cms-sw
Bug on B->KJ/psi MC ?
Dear all,
We have noticed that there is an issue with several MC events. The issue is that we observe muons from J/psi decay to go first through photons [*]. The sample is /BuToJpsiK-JpsiToMuMu_Fil-MuPt2_TuneCP5_13p6TeV_pythia8-evtgen/RunIII2024Summer24MiniAODv6-150X_mcRun3_2024_realistic_v2-v2/MINIAODSIM. In 2022 2023 sample we do not have this problem. Some event numbers are shown in the print out.
Best, George
[*] evt 987550772 Muon pdg -13 mother 22 grandmother 443 Muon pdg 13 mother 22 grandmother 443 evt 987550784 Muon pdg -13 mother 22 grandmother 443 Muon pdg 13 mother 22 grandmother 443 evt 987551009 Muon pdg -13 mother 22 grandmother 411 Muon pdg -13 mother 22 grandmother 443 Muon pdg 13 mother 22 grandmother 443 evt 987551087 Muon pdg -13 mother 22 grandmother 443 Muon pdg 13 mother 22 grandmother 443 evt 987550884 Muon pdg -13 mother 22 grandmother 443 Muon pdg 13 mother 22 grandmother 443
A new Issue was created by @gkaratha.
@Dr15Jones, @ftenchini, @makortel, @mandrenguyen, @sextonkennedy, @smuzaffar can you please review it and eventually sign/assign? Thanks.
cms-bot commands are listed here
New categories assigned: generators
@lviliani,@mkirsano,@sensrcn,@theofil you have been requested to review this Pull request/Issue and eventually sign? Thanks
This should be addressed at the MCCM Wednesday meeting. Please review the BPH MC contacts and request a diff of the fragments used between the problematic sample and the previously healthy sample you referenced. We will need the two pre-IDs to efficiently pinpoint the issue.
I totally agree with @theofil.
In addition, the description in this issue is not helping at all.
- Is it really a bug or is it just a change on how the event history is saved (note that different Pythia8 versions are used in 24 and 22/23, i.e. 309 vs 306)?
- Do you see significant differences in the kinematic distributions between 22/23 and 24?
- How has the printout reported above been derived?
- Which are the 22/23 samples you are referring to?
Is it really a bug or is it just a change on how the event history is saved (note that different Pythia8 versions are used in 24 and 22/23, i.e. 309 vs 306)?
- We saw this in CMSSW 15. A different analysis using 2024 MC with cmssw 14 does not see it. I dont get the comment about history. This decay should not exist. It is not in our fragment, it wasnt there previously and should not be there now.
Do you see significant differences in the kinematic distributions between 22/23 and 24?
- No
How has the printout reported above been derived?
- With a code on the nano output
Which are the 22/23 samples you are referring to?
- 2023: /BuToJpsiK_BMuonFilter_SoftQCDnonD_TuneCP5_13p6TeV_pythia8-evtgen/Run3Summer23BPixMiniAODv4-130X_mcRun3_2023_realistic_postBPix_v2-v3/MINIAODSIM
- 2022: /BuToJpsiK_BMuonFilter_SoftQCDnonD_TuneCP5_13p6TeV_pythia8-evtgen/Run3Summer22EEMiniAODv4-130X_mcRun3_2022_realistic_postEE_v6-v2/MINIAODSIM
We saw this in CMSSW 15. A different analysis using 2024 MC with cmssw 14 does not see it. I dont get the comment about history. This decay should not exist. It is not in our fragment, it wasnt there previously and should not be there now.
Either these events are in 2024 dataset or they are not... I don't understand the point that you see them with CMSSW 15 but you don't see them with CMSSW 14. Unless the problem is not in the dataset itself but in the code you use to dump the event history (as I was mentioning before). Maybe these are just FSR photons emitted by the muons?
- 2023: /BuToJpsiK_BMuonFilter_SoftQCDnonD_TuneCP5_13p6TeV_pythia8-evtgen/Run3Summer23BPixMiniAODv4-130X_mcRun3_2023_realistic_postBPix_v2-v3/MINIAODSIM
- 2022: /BuToJpsiK_BMuonFilter_SoftQCDnonD_TuneCP5_13p6TeV_pythia8-evtgen/Run3Summer22EEMiniAODv4-130X_mcRun3_2022_realistic_postEE_v6-v2/MINIAODSIM
The fragments used in this samples are completely different from the one used in the 24 sample linked in the issue description.
Either these events are in 2024 dataset or they are not... I don't understand the point that you see them with CMSSW 15 but you don't see them with CMSSW 14. Unless the problem is not in the dataset itself but in the code you use to dump the event history (as I was mentioning before). Maybe these are just FSR photons emitted by the muons?
- It cannot be FSR. is in every single event in CMSSW 15 and only there. Also the mother of the photon is J/psi and the daughter is muon. Well this is why it is a bug, is not really logical... You should not see this decay at all because it does not exist :)
Hi all, we are the BPH MC contact. We're not completely sure these are the exact datasets you meant, but we checked the corresponding fragments for the following samples:
2022: /BuToJpsiK_JpsiToMuMu_MuFilter_Pt-2_TuneCP5_13p6TeV_pythia8-evtgen/Run3Summer22MiniAODv4-130X_mcRun3_2022_realistic_v5-v2/MINIAODSIM Request ID: BPH-Run3Summer22GS-00187
2024: /BuToJpsiK-JpsiToMuMu_Fil-MuPt2_TuneCP5_13p6TeV_pythia8-evtgen/RunIII2024Summer24MiniAODv6-150X_mcRun3_2024_realistic_v2-v2/MINIAODSIM Request ID: BPH-RunIII2024Summer24GS-00112
We compared the fragments used in both requests and found no differences.
Sorry, I just checked your earlier messages. If the 2022 dataset you are referring to is /BuToJpsiK_BMuonFilter_SoftQCDnonD_TuneCP5_13p6TeV_pythia8-evtgen/Run3Summer22EEMiniAODv4-130X_mcRun3_2022_realistic_postEE_v6-v2/MINIAODSIM, then it is a kind of different dataset from the one used in 2024, so there are many differences between their fragments. The corresponding 2022 request you refer to is BPH-Run3Summer22GS-00042.
It cannot be FSR. is in every single event in CMSSW 15 and only there. Also the mother of the photon is J/psi and the daughter is muon. Well this is why it is a bug, is not really logical... You should not see this decay at all because it does not exist :)
I opened a NanoAOD file of the 24 dataset and I didn't see any such kind of event. See an example below:
********************************************************************************************************************************************************************************************
* Row * Instance * GenPart_pdgId * GenPart_status * GenPart_genPartIdxMother * GenPart_pt * GenPart_eta *
********************************************************************************************************************************************************************************************
* 0 * 0 * 21 * 21 * -1 * 0 * 22784 *
* 0 * 1 * 21 * 21 * -1 * 0 * -22784 *
* 0 * 2 * 5 * 23 * 0 * 13.21875 * 0.501953125 *
* 0 * 3 * -5 * 23 * 0 * 13.21875 * 0.3359375 *
* 0 * 4 * 5 * 71 * 2 * 12.8125 * 0.5078125 *
* 0 * 5 * -523 * 2 * 4 * 12.15625 * 0.4462890625 *
* 0 * 6 * -5 * 71 * 3 * 13.75 * 0.2880859375 *
* 0 * 7 * 511 * 2 * 6 * 13 * 0.3251953125 *
* 0 * 8 * -521 * 2 * 5 * 11.9375 * 0.4482421875 *
* 0 * 9 * -4112 * 2 * 7 * 4.484375 * 0.4189453125 *
* 0 * 10 * -4122 * 2 * 9 * 4.140625 * 0.423828125 *
* 0 * 11 * 443 * 2 * 8 * 11.875 * 0.447265625 *
* 0 * 12 * -13 * 1 * 11 * 5.5 * 0.2841796875 *
* 0 * 13 * 13 * 1 * 11 * 5.9375 * 0.544921875 *
Therefore, I am not able to see any problem with this dataset at the moment and these photons are clearly not present in every event. As I said, the fact that you see different outputs based on the CMSSW release used to analyze the dataset points to an issue with your framework and not necessarily with the input dataset.
In case you have further proofs about a possible bug, please report it during a MccM or GEN meeting with all the necessary details describing the bug and how to reproduce it.
/store/mc/RunIII2024Summer24NanoAODv15/BuToJpsiK-JpsiToMuMu_Fil-MuPt2_TuneCP5_13p6TeV_pythia8-evtgen/NANOAODSIM/150X_mcRun3_2024_realistic_v2-v2/90000/deeb3e40-60d1-49f2-8f98-ba785bd0c173.root
But I also checked a few others. Not all the files though.
Could we please close this issue @gkaratha ? The CMSSW GitHub issue tracker is being misused here: it should not be abused for questions or topics unrelated to CMSSW or the generators code. As mentioned previously, the standard CMS practice is to bring such questions to the MccM Wednesday meetings
I would leave it as is until we have the time to confirm it. I saw these events in our mc . @abragagn you had the offending lines somewhere?
I would leave it as is until we have the time to confirm it. I saw these events in our mc . @abragagn you had the offending lines somewhere?
Thanks @theofil for following up. we did a ticket because PPD asked for it. If mcm is the correct forum next time we go there. We can present this as well in some reasonable time
I don't have permission to close it, I think you do as issue author, but for sure we are not in the right place :-)
Please verify with @YilinZhou0715 which are the correct 2 prep-ids we can use following up the
https://github.com/cms-sw/cmssw/issues/49359#issuecomment-3612070539
If you are unable to resolve the issue, please prepare a brief summary along with the code that reproduces both the healthy and the problematic outputs on two example files placed somewhere in EOS/public. We can then plan to discuss it in the next GEN meeting, scheduled for December 15th.
Thanks @theofil for following up. we did a ticket because PPD asked for it. If mcm is the correct forum next time we go there. We can present this as well in some reasonable time
I don't think we have asked to open a CMSSW GitHub issue for unrelated matters to CMSSW. The recommendation (not finding a trace for it) was certainly like "if this is a software related failure, please open a CMSSW GitHub issue".
I'm glad it is not then.
Hello all, I hope to shed some light on this. It's not an issue related to the datasets, it's an issue associated with CMSSW 15. From our digging, the behaviour mentioned by @gkaratha is caused by this particular commit.
https://github.com/cms-sw/cmssw/pull/44603/commits/5ff0cedaac57c8f37d780c40d0c27954697881a9
The code now checks for leptons whose mother was a pruned photon. When this happens, it creates a dummy photon with an extremely small momentum and inserts it as the new mother of the lepton, while also reconnecting the original mothers to this dummy photon. This is checked by lepton, and the fact that the pruned photon may be a common mother to multiple leptons is not handled. I guess that since the J/psi -> mumu decay goes through a virtual photon, it is affected by this change.
Prior to these changes, J/Psi GEN chains were clean physical
J/Psi -> mu
-> mu
now they appear as
J/Psi -> gamma -> mu
-> gamma -> mu
which is highly confusing and unnatural (sinche the two photons are separate non-existing entities).
We can safely reproduce this issue. Any dataset processed with CMSSW presents the phandom photons, any processed with CMSSW < 15 do not. I can provide example files, but you will just find what I just described.
This breaks GEN analysis code developed on CMSSW < 15 and requires ad-hoc fixes to handle the two cases. The behaviour is very bizarre and hard to spot as it is completely invisible up to the MINI -> NANO stage. Only one of the team members with vast experience with CMSSW GEN content (@elusiani, cannot find him here) was able to pinpoint the real cause, by digging in CMSSW commits.
I guess the commit solves some other issue (unknown to me), and this behaviour is unintended, but for BPH this handling of J/Psi is extremely counterintuitive.
EDIT: syntax, tone
I guess the commit solves some other issue (unknown to me), but for BPH this handling of J/Psi is extremely counterintuitive, not unnecessary, and annoying
That commit came from this PR #44603 which implies without it HepMC3 will crash. @mseidel42 any comments as you were the author of that PR?
Hello,
The MergedGenParticleProducer is optimized for Rivet consumption and is trying to detect pruned photons since CMSSW 12_6, mostly to avoid problems in some ttbar and DY analyses where their lepton daughters would otherwise show up as "prompt". The latest patch was not intended to change physics behavior but just make it compatible with HepMC3.
As the MergedGenParticleProducer is not run in MiniAod production, can you clarify what data tier you are looking at (BPH-specific Nano?) and how to reproduce it, please?
Please also check the Pythia+EvtGen content directly on the GEN (using https://github.com/cms-sw/cmssw/blob/master/PhysicsTools/HepMCCandAlgos/test/printTree.py) and let me know whether there is a non-dummy photon inserted in newer versions of Pytha+EvtGen or not.
If not we can probably avoid the bahavior by asking for !isDirectHadronDecayProduct in isLeptonFromPrunedPhoton().
Best, Markus
I realised my earlier comment may have sounded harsher than intended, so my apologies for that @gkaratha
At the time, the information suggested that the problem was directly visible at the MiniAOD level. Since we could not reproduce it there, we concluded too quickly that it was unrelated to CMSSW. It now seems the issue appears at the NANOAOD step and is not present in MiniAOD, which explains why our initial checks did not reveal it.
To avoid similar confusion in the future, it would be very helpful if issue reports included minimal code or clear instructions to reproduce the behaviour. High-level descriptions such as:
“there is an issue with several MC events… The sample is /BuToJpsiK-Jpsi.../MINIAODSIM ... I saw these events in our MC … I can provide example files, but you will just find what I described”
make it difficult for others to diagnose the problem efficiently. A small reproducible example usually allows us to converge much faster and with far less back-and-forth.
Any updates @gkaratha ?
Do you plan to provide code or a minimal example that reproduces the issue in CMSSW and centrally produced files ?