-
Notifications
You must be signed in to change notification settings - Fork 4.4k
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
possibility of configuring the OMTF emulator directly from XMLs #45032
possibility of configuring the OMTF emulator directly from XMLs #45032
Conversation
OMTFReconstruction.h and OMTFReconstruction.cc The possibility of configuring the OMTF emulator directly from the config XML is added. When both patternsXMLFile and configXMLFile are given from the python config of the simOmtfDigis or simOmtfPhase2Digis, the L1TMuonOverlapParams are read directly from these files, and the L1TMuonOverlapPhase1ParamsESProducer is not needed. Otherwise, the L1TMuonOverlapParams are obtained from the eventSetup (so from the DB, or from the L1TMuonOverlapPhase1ParamsESProducer - if it is defined). L1Trigger/L1TMuonOverlapPhase2/python/fakeOmtfParamsPhase2_cff.py is removed, as when it is used, the L1TMuonOverlapPhase1 gets this config as well. L1Trigger/L1TMuonOverlapPhase2/python/simOmtfPhase2Digis_extrapol_cfi.py is moved to simOmtfPhase2Digis_cfi.py, as this is the default configuration (besides, there should be only one cfi for a given module). L1Trigger/L1TMuonOverlapPhase1/src/Omtf/OMTFProcessor.cc line trackAddr[3] = myCand->getGpResultUnconstr().getPdfSumUnconstr(); is removed, as uGMT expects 3 entries in the TrackAddress (when there were 4, uGMT was generating a warning). L1Trigger/L1TMuonOverlapPhase2/test - runMuonOverlap*.py are corrected
cms-bot internal usage |
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-45032/40324
|
A new Pull Request was created by @kbunkow for master. It involves the following packages:
@aloeliger, @epalencia, @srimanob, @subirsarkar, @cmsbuild 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-6a0d5a/39512/summary.html Comparison SummarySummary:
|
Interestingly, this PR now also shows some differences in the Run3 |
The difference in the L1T_L1TStage2uGMT_OMTFoutput_vs_uGMTinput plots is due to a change in the This line was added by #43687, but it turned out it is not needed, and moreover, uGMT was generating this warning message when the fourth trackAddr was added:
The track address map is checked only by the plots L1T_L1TStage2uGMT_OMTFoutput_vs_uGMTinput , therefore the differences are visible only in these plots. So the fix in this PR in the OMTFProcessor.cc is OK, as well as the changes in the L1T_L1TStage2uGMT_OMTFoutput_vs_uGMTinput plots. Karol |
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-45032/40399
|
Pull request #45032 was updated. @epalencia, @subirsarkar, @aloeliger, @srimanob, @cmsbuild can you please check and sign again. |
please test |
+1 Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-6a0d5a/39600/summary.html Comparison SummarySummary:
|
+l1 |
Note to @cms-sw/l1-l2 for later fix PR src/L1Trigger/L1TMuonOverlapPhase1/src/Tools/CandidateSimMuonMatcher.cc:444:12: warning: Value stored to 'treshold' during its initialization is never read [deadcode.DeadStores] |
+Upgrade |
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, @antoniovilela, @rappoccio (and backports should be raised in the release meeting by the corresponding L2) |
+1 |
ping bot |
PR description:
This PR adds the possibility of configuring the OMTF emulator directly from the config XML, without using the L1TMuonOverlapPhase1ParamsESProducer. It should allow to avoid problems with the OMTF emulator that appeared in the #44498 - as discussed in the #44498 (comment).
PR validation:
The PR was validated with the workflow 141.044 (
runTheMatrix.py -l 141.044 -i all --ibeos
). The OMTF plots look good.This PR is not a backport.
Details of changes:
OMTFReconstruction.h and OMTFReconstruction.cc
The possibility of configuring the OMTF emulator directly from the config XML is added. When both patternsXMLFile and configXMLFile are given from the python config of the simOmtfDigis or simOmtfPhase2Digis, the L1TMuonOverlapParams are read directly from these files, and the L1TMuonOverlapPhase1ParamsESProducer is not needed. Otherwise, the L1TMuonOverlapParams are obtained from the eventSetup (so from the DB, or from the L1TMuonOverlapPhase1ParamsESProducer - if it is defined).
L1Trigger/L1TMuonOverlapPhase2/python/fakeOmtfParamsPhase2_cff.py is removed, as when it is used, the L1TMuonOverlapPhase1 gets this config as well.
L1Trigger/L1TMuonOverlapPhase2/python/simOmtfPhase2Digis_extrapol_cfi.py is moved to
simOmtfPhase2Digis_cfi.py, as this is the default configuration (besides, there should be only one cfi for a given module).
L1Trigger/L1TMuonOverlapPhase1/src/Omtf/OMTFProcessor.cc line
trackAddr[3] = myCand->getGpResultUnconstr().getPdfSumUnconstr(); is removed, as uGMT expects 3 entries in the TrackAddress (when there were 4, uGMT was generating a warning).
L1Trigger/L1TMuonOverlapPhase2/test - runMuonOverlap*.py are corrected