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
Trigger Object Tag and Probe DQM source #24319
Conversation
The code-checks are being triggered in jenkins. |
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-24319/6066 |
A new Pull Request was created by @Sam-Harper (Sam Harper) for master. It involves the following packages: DQM/HLTEvF @cmsbuild, @andrius-k, @kmaeshima, @schneiml, @Martin-Grunewald, @silviodonato, @jfernan2, @fwyzard can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
please test |
The tests are being triggered in jenkins. |
Comparison job queued. |
Comparison is ready Comparison Summary:
|
+1 |
The tests are being triggered in jenkins. |
Comparison job queued. |
Comparison is ready There are some workflows for which there are errors in the baseline: Comparison Summary:
|
+1 |
+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. @davidlange6, @slava77, @smuzaffar, @fabiocos (and backports should be raised in the release meeting by the corresponding L2) |
+1 |
@@ -32,6 +32,7 @@ | |||
<use name="MagneticField/Records"/> | |||
<use name="MagneticField/Engine"/> | |||
<use name="TrackingTools/TrajectoryState"/> | |||
<use name="DQMOffline/Trigger"/> |
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.
Linking to this library is causing plugin load problems in the IB
https://cmssdt.cern.ch/SDT/cgi-bin/logreader/slc7_amd64_gcc700/CMSSW_10_3_X_2018-08-24-2300/pyRelValMatrixLogs/run/136.7802_RunHLTPhy2017B_AODextra+RunHLTPhy2017B_AODextra+DQMHLTonAODextra_2017+HARVESTDQMHLTonAOD_2017/step2_RunHLTPhy2017B_AODextra+RunHLTPhy2017B_AODextra+DQMHLTonAODextra_2017+HARVESTDQMHLTonAOD_2017.log#/
The problem is DQMOffline/Trigger should only be a plug-in, not a shared library.
@@ -31,4 +31,6 @@ | |||
|
|||
<use name="root"/> | |||
<use name="boost"/> | |||
<flags EDM_PLUGIN="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 is the change that is breaking the IBs
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.
To make things work, DQMOffline/Trigger/src/SealModule.cc would have to move to the plugins directory. Even better, all the modules used in that file would also move to that directory.
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.
sorry about that! Fixed now. All plugins are now in plugins dir
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.
#24390, its the same branch with the fix
Dear All,
This PR adds a DQM module which aims to monitor trigger efficiencies using only information calculated by the trigger. In principle it is completely agnostic of the particle type, in practice it is probably only applicable to electrons.
It is intended that this module is run as part of the HLT job, hence why its not include in any "DQM" sequence. Running in the HLT was seen as the optimal solution as
This module just provides the source histograms. The client will be run outside of the CMSSW framework and will be maintained in a separate git repo. The client will acquire the histograms via the DQM gui api.
The goal of this DQM is to allow fast feedback of current E/gamma data taking efficiency with a latency of ~30-60mins from the fill ending.
Finally, it is reasonable to ask, why bother? Two reasons. I am still paranoid about possible pixel issues causing efficiency losses and this will reduce the latency of finding them from <1 week> to <1 day>. More importantly, I want this up and running before the end of the Run so it doesn't get forgotten about for the start of RunIII where it will be extremely useful.
We will need this running at P5 so expect backports to 10_2 and 10_1.
@Martin-Grunewald @silviodonato