Status of RPC DQM for Global DAQ in CMSSW

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

2. Producer Producer Producer Producer Producer Producer Producer Producer DESIGN OF DQM IN CMSSW (Emilio M. Christos L.) The DQM structure is made of three type of applications: • “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 Ilaria S., RPC/Trigger Meeting

3. CERN NETWORK IP5-CERN node Node analyzing histograms and shipping them downstream F.F. @ IP5 Web Interface and/or local graphical user interface DCC Outside CERN: Web interface 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 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. Ilaria S., RPC/Trigger Meeting

4. RPC-specific code: The DQM-producers Analyzes the RPCDigi collection committed to the event by RPCRawToDigi RAW DATA RPCMonitorDigi RPCRawToDigi RPCMonitorModule 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 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 Ilaria S., RPC/Trigger Meeting

5. RPCMonitorModule Slave LB TC GB& Sorter Master LB Splitters: 1 to 2 or 1 to 4 PAC RPC Chambers Slave LB GB & Sorter PAC PAC PAC • DCC-level histograms: • DCC header and trailer • intergity • L1A increment • CRC • BXN • #of events with DCC discarded • #RMB with data • RMB with Data RMB 18 Optical links, data distributed to 4 PAC & one RMB Data Concentrator Card Filter Farm 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 Ilaria S., RPC/Trigger Meeting

6. LB number • 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 Ilaria S., RPC/Trigger Meeting

7. 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) Ilaria S., RPC/Trigger Meeting

8. 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. Ilaria S., RPC/Trigger Meeting

9. 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 Ilaria S., RPC/Trigger Meeting

10. The Client Application Producer Producer Producer Producer Producer Producer Producer 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). Ilaria S., RPC/Trigger Meeting

11. 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 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 Ilaria S., RPC/Trigger Meeting

13. 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. Ilaria S., RPC/Trigger Meeting

14. 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…. Ilaria S., RPC/Trigger Meeting

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

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