1. Status of RPC DQM for Global DAQ in CMSSW
RPC/Trigger Meeting
10/05/2006
Ilaria Segoni
CERN

2. Ilaria S., RPC/Trigger Meeting
DESIGN OF DQM IN CMSSW
(Emilio M. Christos L.)
The DQM structure is made of three type of applications:
Producer
“DQM PRODUCERS”: applications that process
the (event) data and produce the “monitorable”
(collection of histograms, scalars, messages)
“DQM CLIENTS”: applications that retrieve and process the information produced by the sources, (e.g. displaying, running quality tests).
“DQM COLLECTORS”: applications that perfom source-client connection tasks:
Tell Clients which information is available
Receive the requests for information from clients
Transfer the requested information from sources and send it to clients
1/17/2019
Ilaria S., RPC/Trigger Meeting

3. Ilaria S., RPC/Trigger Meeting
PLANS FOR RUNNING DQM AT MTCC
DQM producers will run in the Filter IP5 (but if available selection algorithms
will be given priority)
One collector node will ship the monitorable to the CERN network
Client application(s) will run in the CERN network with the following tasks:
running quality tests on the histograms
producing a web interface through which data will be available
to remote sites
All detector groups must implement a standard a state machine client => all processes
configurable and controllable through run control
IP5
CERN NETWORK
Web Interface
and/or local
graphical user
interface
Outside CERN:
Web interface
IP5-CERN node
Node analyzing
histograms and
shipping them
downstream
DCC
DQM “snapshots”: the product of DQM consist in the entire DQM information at a given time
(e.g. the description of the RPC detector status at the end of a run).
The snapshots will be also treated as normal event data
=> it will be saved to mass storage in root files (with a DB containing indices to
catalog the data)
=> it will be shipped to remote sites.
1/17/2019
Ilaria S., RPC/Trigger Meeting

4. RPC-specific code: The DQM-producers
The analysis is for both Barrel and Endcap, it consists of different CMSSW
packages (Marcello M., Ilaria S.)
There are two analysis modules that run at DQM production level (names could change in the future):
DQM/RPCMonitorModule: a service to the unpacker
DQM/RPCMonitorDigi: an edm::EDAnalyzer
RPCRawToDigi
RPCMonitorDigi
RAW
DATA
RPCMonitorModule
Analyzes the RPCDigi
collection committed to the
event by RPCRawToDigi
Analyzes the information on the raw data saved by the unpacker (EventFilter/RPCRawToDigi) in a transient object (RPCEventData).
The two modules consume information produced by the raw data “unpacking” module,
RPCRawToDigi
1/17/2019
Ilaria S., RPC/Trigger Meeting

5. RPCMonitorModule
RPCMonitorModule carries out data integrity check and basic detector functioning tasks
The histograms are organized in folders corresponding to the hardware read-out organization
DCC ->RMB -> Channel -> LB
Data Concentrator Card
Splitters:
1 to 2
or 1 to 4
PAC GB
&
Sorter
RMB
TC GB &
18 Optical links,
data distributed to
4 PAC & one RMB
Slave LB
Master LB
RPC Chambers
Filter Farm
DCC-level histograms:
DCC header and trailer
intergity
L1A increment
CRC
BXN
#of events with DCC discarded
#RMB with data
RMB with Data
1/17/2019
Ilaria S., RPC/Trigger Meeting

6. Ilaria S., RPC/Trigger Meeting
DCC/RMB-level histograms:
# of Channels with data
Channels with data
DCC/RMB/CHANNEL-level histograms:
# of LB with data
LB with data
DCC/RMB/CHANNEL/LB-level histograms:
Data truncated flag
# of bits with signal
Bits with signal
Partition number
Half Partition
Chamber Data
LB number
1/17/2019
Ilaria S., RPC/Trigger Meeting

7. Ilaria S., RPC/Trigger Meeting
RPCMonitorDigi
RPCMonitorDigi:
uses the digi produced by the unpacker (i.e. for each h-partition the collection
strip with signal and the BX ) to perform chamber performance checks:
histograms are organized in folders corresponding to the description of the RPC geometry
In CMSSW. The granularity is given by h-partitions (or rolls)
5 histograms are produced for each h-partition (~300 histograms for MTCC, 12K for entire
CMS geometry) :
BXN
# of digi
Occupancy
Cluster multiplicity
Cluster size
We need to introduce two new types of histogram: noise and efficiency (using stubs
from DT and CSC)
1/17/2019
Ilaria S., RPC/Trigger Meeting

8. Ilaria S., RPC/Trigger Meeting
Historical Plots
OBJECTIVE:
Histograms representing the evolution over time of relevant quantities will be produced
The variables that will be plot versus time are the average of:
cluster size (muons)/roll
cluster size (noise)/roll
number of clusters/roll
efficiency/roll
occupancy/roll
noise/roll
noise/roll masking hot channels
We’ll include also information on fraction of events with corrupted data
Estimate on number of variables:
For MTCC geometry: 7 X 60 rolls = 420
For geometry at CMS startup: 7 X 2316 rolls ~ 16K
Time granularity for X-axis bin: run
Given the large number of variables to save at every run the offline DB will be used for storage
and retrivial (the application that calculates such quantities is the client running at CERN)
See for further info
on historical plots and discussion on DQM usage of databases.
1/17/2019
Ilaria S., RPC/Trigger Meeting

9. Ilaria S., RPC/Trigger Meeting
The “data”
Still no real detector data taken with the proper format is available
I am analyzing dummy data taken in November2005 when testing the DCC
Correct data format
1/17/2019
Ilaria S., RPC/Trigger Meeting

10. The Client Application
Producer
CLIENT: any application that consumes the monitorable
available from the collector and processes it (e.g.
displaying it, running quality tests on histograms, producing
the web page(s) …)
The central CMSSW-DQM services provide two type of client applications:
Local IGUANA-GUI: provided entirely by DQM central systems (Giulio E., Andrea C.)
State machine client with web interface: base class with standard functionalities provided
by DQM central system (Emilio M., Dimitrios T., for configuration Ilaria S.), to be customized
by detector groups
=> for muon systems (RPC, CSC, DT) I am customizing it in the package
DQM/RPCMonitorClient (name must be changed).
1/17/2019
Ilaria S., RPC/Trigger Meeting

11. Ilaria S., RPC/Trigger Meeting
The IGUANA GUI
The root tree structure in which the
Monitoring elements are organized
is visible on the left.
The user can browse this list and
choose on the fly what to display.
The plots have the interactivity of
a root canvas
Plots are automatically refreshed
at each update
Soon it will be possible to configure through Xml file the layout of displayed histograms
1/17/2019
Ilaria S., RPC/Trigger Meeting

12. The State Machine Client with Web Interface
Monitoring information subscription list is configured through xml file at run time
(but can be changed through drop down menu, see below)
Quality tests are configured through xml file at run time
What we have now for muon customization of this type of client:
Buttons for controlling the state
of the application
Drop-down menu for (un)subscribing
to new monitoring information
on the fly
Drop-down menu to select and
visualize histograms
Buttons to start(stop) checking the
Result of automated quality tests
semi-predefined* plots with the information for a summary
description of the state (detector state or quality of data).
*not necessarily hard coded, could be a configurable list
basic reference plots
Two additional displays
are in the page
1/17/2019
Ilaria S., RPC/Trigger Meeting

13. Ilaria S., RPC/Trigger Meeting
The Quality Tests
The central DQM services provide a set of quality tests that can be run on the histograms:
Comparison to reference (based on c2 test)
Comparison to reference (based on Kolmogorov test)
Contents within X-range
Contents within Y-range
Identical contents
Mean value within expected range
Check for dead channels
Check for noisy channels
Contents along diagonal
The quality tests are configured at run time through an xml file
Alarms are the product of the quality tests
Processing alarms: at the moment I just print them out (by clicking on the quality test related
buttons). But: too many alarms => impossible to get a comprehensive picture like this
Wee need some kind of graphical representation of the detector chambers and readout hardare
with color codes summarizing the status of quality tests for each chamber and interactive
(in order to see the plots, print the alarms…). The Tracker has a well developed tool that
performs all these actions, the design for RPC could follow that path.
1/17/2019
Ilaria S., RPC/Trigger Meeting

14. Ilaria S., RPC/Trigger Meeting
Summary
The RPC-specific components of the DQM structure in CMSSW
are well under development and tested on dummy data with proper
Global DAQ format.
The development now must focus on three issues:
Monitoring of higher level objects (stubs, tracks) and of chamber
efficiency/noise (using CSC and DT stubs)
Production of historical plots, with interface to off-line DB
Efficient processing of alarms produced by the quality tests,
the most reasonable solution being a graphical representation of
the entire RPC readout hardware and geometry, with color coding,
interactivity….
1/17/2019
Ilaria S., RPC/Trigger Meeting

15. Ilaria S., RPC/Trigger Meeting
BACK UP SLIDES
1/17/2019
Ilaria S., RPC/Trigger Meeting

16. Ilaria S., RPC/Trigger Meeting
The TrackerMap used by the Tracker DQM client:
1/17/2019
Ilaria S., RPC/Trigger Meeting