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?


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:
File Purpose
L1TRenderPlugin.cc Old render plugin
L1TdeRCTRenderPlugin.cc Old RCT-specific render plugin
L1TRPCTFRenderPlugin.cc Old RPC-specific render plugin
L1TEMURenderPlugin.cc Old render plugin
L1T2016Layer1RenderPlugin.cc New render plugin specific to CaloLayer1, may be renamed

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


Pull Requests

Deployment Workflow

Development Branches

Pull Requests

Subsytem Feedback and Requests







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


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

Topic attachments
I Attachment History Action Size Date Who Comment
PDFpdf L1T_DQM_Meeting.pdf r1 manage 4112.0 K 2016-04-14 - 01:32 SeanJiunWang  
Edit | Attach | Watch | Print version | History: r9 | r7 < r6 < r5 < r4 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r5 - 2016-04-15 - NicholasCharlesSmith1
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    Sandbox All webs login

  • Edit
  • Attach
This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2021 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
or Ideas, requests, problems regarding TWiki? use Discourse or Send feedback