-
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
improve HLTMuonValidator
and HLTMuonPlotter
(no UB, consider only HLTFilter
modules)
#40753
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Review comments with further details on this PR.
@cms-sw/dqm-l2, please consider notifying the experts of this DQM plugin and/or the HLT-MUO validators, so they can contribute to the review.
|
||
vector<string> HLTMuonValidator::moduleLabels(string path) { | ||
vector<string> modules = hltConfig_.moduleLabels(path); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
moduleLabels
is not sufficient in this case, as there are modules called *Filtered*
(in muon-related triggers of the HLT menu) which do not produce any TriggerObjects
for TriggerEventWithRefs
(see for example the module hltIter0IterL3MuonPixelSeedsFromPixelTracksFiltered
); such extra modules would be taken into account by HLTMuonPlotter
, fail the matching to GEN/RECO objects (because they return no HLT candidates), and thus cause the following HLT steps to fail the matching (even if one of the following HLT filters does have valid HLT candidates).
saveTagsModules
(see above in green) should be a better choice (saveTags
is a parameter present for all the modules in the HLT menu which are HLTFilter
s, which do save the TriggerObjects
).
vector<string> modules = hltConfig_.moduleLabels(path); | ||
vector<string>::iterator iter = modules.begin(); | ||
auto const step_label = stepLabel(module); | ||
if (step_label.empty() or std::find(stepLabels.begin(), stepLabels.end(), step_label) != stepLabels.end()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This requires that there are no duplicates in the stepLabels
vector. Afaiu, having duplicates could cause histograms of a certain type, e.g. _L3
, to be filled more often than histograms of type _All
(no matching requirements), and this could spoil the efficiency plots (numerator with more entries than denominator).
return; | ||
} | ||
|
||
if (stepLabels[0] != "L1" and std::find(stepLabels.begin(), stepLabels.end(), "L1") != stepLabels.end()) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This forbids cases where "L1"
is present in stepLabels
, but is not the first module found by HLTMuonValidator
in the HLT Path (the case where "L1"
is not present in stepLabels
remains supported).
edm::LogError("HLTMuonPlotter") << "Invalid inputs: 'moduleLabels_' is empty." | ||
<< "\nMonitorElements for HLT path '" << hltPath_ << "' will not be produced."; | ||
isInvalid_ = true; | ||
} else if (stepLabels_.size() != moduleLabels_.size() + 1) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This enforces the requirement that stepLabels_.size() == moduleLabels_.size() + 1
(the difference being the first entry of stepLabels_
, which is "All"
, i.e. no trigger-matching requirements). This, stepLabels_.size() == moduleLabels_.size() + 1
is guaranteed by HLTMuonValidator::fillLabels
.
auto const moduleLabelStripped = | ||
edm::path_configuration::removeSchedulingTokensFromModuleLabel(moduleLabels_[idx]); | ||
auto const iTag = edm::InputTag(moduleLabelStripped, "", hltProcessName_); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The module 'label' here (i.e. moduleLabels_[idx]
) can contain special characters to denote how the module/filter was used in the configuration (e.g. moduleLabels_[idx] == "-hltModule"
if the result of the filter was ignored, because used with cms.ignore( hltModule )
). In order to find the corresponding trigger objects, the InputTag needs to be built with the 'stripped' version of the module label (meaning, without special characters).
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-40753/34170
|
A new Pull Request was created by @missirol (Marino Missiroli) for master. It involves the following packages:
@emanueleusai, @cmsbuild, @syuvivida, @rvenditti, @micsucmed, @pmandrik can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
please test |
type bugfix |
@@ -6,10 +6,10 @@ | |||
|
|||
hltProcessName = cms.string("HLT"), | |||
hltPathsToCheck = cms.vstring( | |||
"HLT_(L[12])?(Iso)?(Tk)?Mu[0-9]*(Open)?(_NoVertex)?(_eta2p1)?(_v[0-9]*)?$", | |||
"HLT_(HighPt)?(L[12])?(Iso)?(Tk)?Mu[0-9]*(Open)?(_NoVertex)?(_eta2p1)?(_v[0-9]*)?$", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
CMSHLT-2277 renamed HLT_TkMu100
to HLT_HighPtTkMu100
, and this change adds monitoring for the latter.
please abort Unrelated error in unit test |
please test |
+1 Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-4366cc/30608/summary.html Comparison SummarySummary:
|
@missirol do I understand correctly that HLTMuonValidator is responsible for producing all HLT_Mu* and HLT_IsoMu* plots in their respective folders? (e.g. /HLT/Muon/Distributions/HLT_Mu15) |
@emanueleusai , yes (or at least, that's my understanding). |
@JanFSchulte @khaosmos93 Could you please help reviewing this PR? (couldn't find the guthub handle of the other HLT Mu DQM/Validation experts) |
@cms-sw/dqm-l2 What's the ETA for the review of this bugfix ? Do you (eventually) plan/want to have this backported to 13_0_X ? |
I was waiting for HLT Mu DQM/Validation expert feedback, but it looks like they're not interested in contributing to this. |
And, yes, we need the 13_0 backport as this is the release to be used for data taking. |
+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. @perrotta, @dpiparo, @rappoccio (and backports should be raised in the release meeting by the corresponding L2) |
Thanks, @emanueleusai . Okay, I'll go ahead and open the backport. |
+1 |
PR description:
This PR aims to improve the plugin
HLTMuonValidator
, and its utilityHLTMuonPlotter
.This update was triggered by #40708 (comment), where it was noticed that
HLTMuonPlotter
has a bug that can lead to undefined behaviour [1].Further checks showed other shortcomings of
HLTMuonValidator
/HLTMuonPlotter
(see review comments for more details); these shortcomings can lead to the DQM outputs ofHLTMuonValidator
being filled incorrectly in the current implementation. This PR tries to fix this (on top of fixing the original UB issue).LogTrace
calls are added to ease debugging. In addition, technical changes to modernise both classes are applied (e.g.const
correctness).Expect changes in the DQM outputs of
HLTMuonValidator
(and nowhere else).[1]
The value of
hltStep
becomes(size_t) -1
whenstep == 2
andnSteps == 6
, leading to undefined behaviour incmssw/HLTriggerOffline/Muon/src/HLTMuonPlotter.cc
Line 221 in 6f5b833
This was originally reported in #12056, but apparently not fixed back then.
PR validation:
Private tests.
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:
To be backported to
CMSSW_13_0_X
if merged.