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

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

Ilaria S., RPC/Trigger Meeting PLANS FOR RUNNING DQM AT MTCC DQM producers will run in the Filter Farm @ 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 F.F. @ 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

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

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

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

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

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 https://twiki.cern.ch/twiki/bin/view/CMS/DQMHistoricPlots_MTCC for further info on historical plots and discussion on DQM usage of databases. 1/17/2019 Ilaria S., RPC/Trigger Meeting

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

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

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

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

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

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

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

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