L1T DQM Task Force
Subsystem Personnel
Subsystem |
Developer |
Documentation |
Expert Contacts |
CaloLayer1 |
Nick Smith |
Nick Smith |
Nick Smith, Bhawna Gomber, Laura Dodd |
CaloLayer2 |
Jing-Yu Zhang |
? |
Alex Tapper |
BMTF |
Esmaeel Eskandari |
? |
Giannis Flouris, Evangelos Paradas |
OMTF |
Esmaeel Eskandari |
? |
Karol Bunkowski |
EMTF |
Nicholas Haubrich, Vivan Nguyen, Sean-Jiun Wang |
Nicholas Haubrich |
Andrew Brinkerhoff |
uGMT |
Esmaeel Eskandari, Sean-Jiun Wang |
? |
Thomas Reis |
uGT |
Mateusz Zarucki |
? |
Manfred Jeitler |
Important links
Here are some links to instructions for the consumers of L1 DQM, to get an idea what we need to provide.
DQM Shift histogram instructions:
https://twiki.cern.ch/twiki/bin/view/CMS/DQMShiftHistograms
Trigger Shift histogram instructions: ?
Trigger Shift reference plots:
https://twiki.cern.ch/twiki/bin/view/CMS/CMSOlineWBTriggerDQMReference
Offline Shift instructions:
https://twiki.cern.ch/twiki/bin/view/CMS/OfflineTriggerShifterGuide#Checks_related_to_L1_trigger_inf
Pages open at P5 at all times:
https://twiki.cern.ch/twiki/bin/view/CMS/TriggerShifterGuideUsefulLinks
Where's the code?
CMSSW Paths
For
$subsys
(as named in table above), we have
File pattern |
Folder |
Purpose |
L1TStage2$subsys.cc |
DQM/L1TMonitor/src |
DQMEDAnalyzer that reads in digis and produces occupancy / physics distributions |
L1TdeStage2$subsys.cc |
DQM/L1TMonitor/src |
DQMEDAnalyzer that reads in data and emulator digis (hence 'de') and compares them, produces relevant plots |
L1T(de)Stage2$subsys.h |
DQM/L1TMonitor/interface |
Header files for the above sources |
L1T(de)Stage2$subsys_cfi.py |
DQM/L1TMonitor/python |
Python config file include (cfi) that provides a default configuration for the above producers |
L1TStage2$subsysQualityTests.xml |
DQM/L1TMonitorClient/data |
XML file that defines Quality Tests for subsystem, these define the coloring in the SummaryMap |
L1TStage2$subsysQualityTests_cfi.py |
DQM/L1TMonitorClient/python |
Configuration file for quality testers defined in XML file |
For some subsystems, the data-emulator comparison consists of running the same data analyzer on the two collections (*Digis and val*Digis) and dividing all histograms.
In this case, the Quality Tests could be object comparisons (e.g.
L1EmulatorObj*QualityTests.xml)
The configurations for each subsystem are brought together in the following files:
File |
Purpose |
DQM/L1TMonitor/python/L1TStage2_cff.py |
This config file fragment (cff) should reference each subsystem L1TStage2$subsys_cfi |
DQM/L1TMonitor/python/L1TStage2Emulator_cff.py |
This config file fragment (cff) should reference each subsystem L1TdeStage2$subsys_cfi (or if same-analyzer subsystem, the L1TStage2$subsys_cfi file, and then modify the InputTag as appropriate |
DQM/L1TMonitor/python/L1TStage2_cff.py |
This config file fragment (cff) should reference each subsystem L1TStage2$subsys_cfi |
DQM/L1TMonitorClient/python/L1TStage2EventInfoClient_cfi.py |
This generates the famous reportSummaryMap, each subsystem and object quality test (as named in the xml file) should be listed here |
DQM/L1TMonitorClient/python/L1TStage2QualityTests_cff.py |
This fragment defines the sequence of quality tests (one entry for each L1TStage2$subsysQualityTests_cfi, plus the object quality tests) |
DQM/L1TMonitorClient/python/L1TStage2MonitorClient_cff.py |
This fragment defines the sequence to process all quality tests, the data/emulator division client (for relevant subsystems) and the event info client |
Lastly, the DQM source clients:
DQM/Integration/python/clients/l1t_dqm_sourceclient-live_cfg.py |
Currently out of date, will become the client that references L1TStage2Monitor_cff |
DQM/Integration/python/clients/l1temulator_dqm_sourceclient-live_cfg.py |
Currently out of date, will become the client that references L1TStage2EmulatorMonitor_cff |
DMWM Paths
In dmwm/deployment/dqmgui/style, we have the following render plugins:
In dmwm/deployment/dqmgui/layouts, we have the following layouts:
File |
Purpose |
l1t-layouts.py |
TBD |
l1t_overview_layouts.py |
TBD |
l1temulator-layouts.py |
TBD |
shift_l1t_layout.py |
TBD |
shift_l1temulator_layout.py |
TBD |
There are also T0 layouts (offline shifter I presume?)
CMSSW Workflow
Development Branches
l1t-dqm-CMSSW_8_0_3
Pull Requests
Deployment Workflow
Development Branches
Pull Requests
Subsytem Feedback and Requests
BMTF
OMTF
EMTF
uGMT
For checking the uGMT cancel out it would be useful to have plots like
ugmtMuonPhi, but only for tfMuonIndex 0-17 + 90-107, 18-35 + 72-89, and
36-71 (the EMTF, OMTF and BMTF inputs) respectively.
We would like to have the following options:
colz
All 2D plots
text
ugmtMuonBXvshwCharge
ugmtMuonBXvshwChargeValid
ugmtMuonBXvshwIso
log y:
pT plots
log z:
2D plots with pT
uGT
April 13th Organizational Meeting Minutes
The presentation is attached
here.
The minutes are organized by slide number and ordered chronologically.
Slide 3
- There should be a single RenderPlugin for L1T DQM, as opposed to plugins for each subsystem. The plugin must be fast and efficient.
Slide 4
- Esmaeel remarked that details such as the axis ranges and binning are something that subsystem experts need to communicate. This led to the suggestion that, since the DQM modules' code is operational and documented, the subsystem experts could be the ones responsible for adding and changing monitor elements as they see fit, either with or without the help of the DQM developer depending on how comfortable they are with the code.
- Also, since the outputs of OMTF are being monitored by way of the uGMT input monitor elements, would a dedicated OMTF DQM module be redundant?
Slide 5
- In the old data-emulator comparison system, DQM EDAnalyzers which read in both data and re-emulated data and compared them. The resulting plots would be visible from the L1TEMU layout of the L1T workspace in the DQM GUI.
- There is a crucial distinction between "sim" and "val" digis. The "sim" digis are passed through the entire simulation chain. The same is true of "val" digis, except that at each step in the simulation chain, the inputs to that step are checked for errors. Such "val" digis were used by the old data-emulator comparison system.
- The subsystem's DQM module must interface with the subsystem's emulator to achieve this. The workflow for this is in early stages of progress.
- Jing-Yu linked code
which has been merged but is still under development. It uses a different method than the old data-emulator comparison.
Slide 6
- In the DQMOffline/L1Trigger package, we are responsible for the configuration of the offline DQM sequence for L1T. We can make use of the customisation for eras to handle old and new data.
- Consult with DPG on their need for this.
- Consult Michael Mulhearn (I forgot to write down about what exactly, but it pertains to offline DQM)
Slide 7
- As long as documentation is unavailable, a subsystem is essentially responsible for monitoring itself.
- The main shifter will look at the Summary workspace, which is a selection of the most important monitor elements. The "L1T: L1 Trigger Data Report Summary Map" and the "L1T: L1 Trigger Emulator vs Data Report Summary Map" must be updated.
Slide 10
- The trigger shifter will look at the L1T and L1TEMU workspaces. The quick collection, comprised of one to two important plots as chosen by each subsystem, must be updated.
Slide 11
- There are summary layouts with plots geared towards subsystem experts in the L1T workspace. Something similar could be made for L1T2016.
Slide 12
- "Are your DQM applications (online/offline) ready?" No
- "Are your instructions for the central (online/offline) DQM shifters ready?" No
- "Do you plan any more requests for patches in the coming weeks:
- "For the online production applications?" Yes, Set upper bound on how many, Determined when
- "For the online GUI layouts or render plugins?" Yes, Set upper bound on how many, Determine when
Slide 13
- For subsystems using MP7, fat events are available. Nick Smith has a working HLT filter for such events. Subsystems which do not use such events should be configured separately from those which do. Which subsystems would like to use the fat events?
- The prompt feedback group (PFG) would be using offline DQM, but in its absence is relying on expert feedback. It was mentioned to consult Vladimir about this?
- Release validation (RelVal) needs working packers from each subsystem.
- There exists an AlCaReco stream which can be used for data-emulator comparison.
--
SeanJiunWang - 2016-04-14