OMTF emulator corresponding to the 2024 OMTF firmware #44893
Conversation
Changes to the OMTF algorithm that were introduced in the firmware after the previous OMTF emulator PR was merged. Mainly fixes related to the triggering on displaced muons. The firmware was deployed in the CMS on 19th March 2024. extrapolFactorsFilename added to the simOmtfDigis_cfi.py the simOmtfDigis_extrapolSimple_cfi.py is not needed now, so is deleted added L1Trigger/L1TMuonOverlapPhase2/python/fakeOmtfParamsPhase2_cff.py fix in GhostBusterPreferRefDt.cc customByRefLayer GhostBusterPreferRefDt::select - added a condition preventing eta overwriting in case the eta of the killed candidates is 121 OMTFProcessor<GoldenPatternType>::extrapolateDtPhiBFloatPoin and OMTFProcessor<GoldenPatternType>::extrapolateDtPhiBFixedPoint - extrFactor is now obtained from endcap stub r, and not eta. OmtfAngleConverter::getGlobalEta - stub r is now taken from the pure wire group, and not from the final_gp (global point) - matters for the extrapolation logic PatternGenerator::upadatePdfs() - deactivated (commented out) the process of code for setting the meanDistPhi to 0 if it is already small, as it seems it has no impact on the firmware occupancy PatternOptimizerBase: control histograms simMuEta and candEta OMTFProcessor<GoldenPatternType>::getFinalcandidatefix in setting hwPtw when ptAssignment is used in XDigiToStubsConverter::makeStubs, removed if (!dtPhDigis) return; if (!cscDigis) return; if (!rpcDigis) return; This is not needed as the DigiToStubsConverters are added dynamically to the vector digiToStubsConverters if given digis are configured to be used (parameter dropXXPrimitives is false in the config). But it was confusing: when the digi collection was not in the file, the job was still running without reporting the missing collection. PatternGenerator.cc - different DistPhiBitShift for phase-1 and phase-2 DataROOTDumper2.cc - rejecting events with more than one matchingResults (to clean the date for the NN training) cleanStubs - fasle, but filtering the matchingResults DataROOTDumper2.cc - dropping events with more than one matchingResults CandidateSimMuonMatcher.h - added method matchSimple() that matches simTracks and OMTF cands without propagation - it works well for the single muon samples. The problem with propagation is that it does not work for low pt muons (pt < ~3GeV). Added flag usePropagation to switch between matchSimple() and match() with propagation. - added phi folding for delta phi in ghostBust() (but it looks like it does not change the results) - in match() (version for the SimTrack), the MatchingResult is added also for the track for which the propagation failed. The changes should be still added to the match() version for the tracking particle. - fixed CandidateSimMuonMatcher::atStation2 - propagation to the RB1in culider bug fixes in StubResult and GoldenPatternResult, change finalise11() Omtf/AlgoMuon.h bug fix in AlgoMuon::getPatternNum() - checking if goldenPaternUnconstr, otherwise segmentation fault can be generated StubResult.h added method setPdfVal(), which is used in the GoldenPatternResult::finalise11() GoldenPatternResult.cc GoldenPatternResult::finalise11() - added penalty -63 for the phiB layers, if there was a hit but it does not fit the pdf operator<< - bug fix - checking if the pResult.omtfConfig is nullptr - this case occurs for the empty GoldenPatternResult L1Trigger/L1TMuonOverlapPhase1/test/expert/omtf/runMuonOverlap_PatsWithExtrapolation_efficiencyAnalyser.py - improved .py for running the emulator + analyzer Fixes in DataROOTDumper2 and CandidateSimMuonMatcher DataROOTDumper2 added flag usePropagation which if false turns on the filter on matchingResults.size() > 1 CandidateSimMuonMatcher::match() - threshold updated to be good for displaced muons in H2ll sample. There should be an automatic switch for this threshold added flags matchUsingPropagationInAnlyzer and matchUsingPropagationInDumper fixes of the candidate hwPt and HwPtUnconstrained Omtf/AlgoMuon.h - changed the value of getPtConstr and getPtUnconstr for an empty candidate from -1 to 0 (as it is in the interface note) OMTFConfiguration::etaBits2HwEta - added return 95 for bits == 0b111111111, as it is like that tin the FW OMTFProcessor<GoldenPatternType>::getFinalcandidates - hwPt is set to 1 if the constraint getPtConstr is 0 but getPtUnconstr > 0 L1Trigger/L1TMuonOverlapPhase1/src/Omtf/OMTFSorter.cc - bestGP is set to the golden pattern number 0 if getPdfSum() == 0 L1TMuonOverlapPhase1/src/Omtf/OMTFProcessor.cc - setting the output unconstrained pT to 1 when getPdfSumConstr. OMTFProcessor<GoldenPatternType>::getFinalcandidates - fixing the condition for the validity of the constrained pt XMLEventWriter.cc - removed constraints in the number of events that can be dumped to the xml
|
cms-bot internal usage |
|
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-44893/40159
|
|
A new Pull Request was created by @kbunkow for master. It involves the following packages:
@cmsbuild, @epalencia, @aloeliger 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-0ab10d/39219/summary.html Comparison SummarySummary:
|
|
Hi, I don't know enough to review this PR, but I have a couple of naive questions.
Is the plan to backport this to 14_0_X ? I guess the answer is 'yes', for the purpose of both online-dqm in 2024 and using the emulator corresponding to the 2024 firmware in the upcoming 2024 MC production in 14_0_X. At the same time, 14_0_X will also be used to make new "re-reco MC" samples for 2022 and 2023 conditions (link). Once this PR is integrated in 14_0_X, what guarantees that the 2022/23 MCs in 14_0_X will use the emulator corresponding to the 2022/23 OMTF firmware (while the 2024 MC in the same release, 14_0_X, will use the 2024 version of the emulator) ? |
|
Hi @missirol Yes, we plan to backport this PR to the 14_0_X, as we would like to have it in the online DQM a.s.a.p. I hope this backport PR will be opened tomorrow. The OMTF emulator is backward compatible, it is configured from the global tag to emulate the corresponding firmware version. I checked the codes in the PR on the data from 2023 (run 370774, dataset Run2023D/Muon0/RAW) by running the DQM - the data-to-emulator plots show 0.5% discrepancies - which is the expected level. |
|
Okay, thanks for the clarification, @kbunkow. |
|
+l1 |
cmsbuild
added
l1-approved
fully-signed
and removed
l1-pending
pending-signatures
labels
|
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. @sextonkennedy, @rappoccio, @antoniovilela (and backports should be raised in the release meeting by the corresponding L2) |
|
+1 |
PR description:
Changes to the OMTF algorithm which were introduced in the firmware after the previous OMTF emulator PR was merged.
Mainly fixes related to the triggering on the displaced muons. With this update, the OMTF data-to-emulator agreement in the online DQM should be at the level of 99.5%. The firmware was deployed in the CMS on 19th March 2024.
PR validation:
The version was checked by running the online DQM on the data from a collision run taken in April 2024.
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
This PR is not a backport