Based on online/offline DQM and DAQ information. DQM Quality Flag

1. Data Quality Monitoring for the CMS Resistive Plate Chamber DetectorAnna Cimmino etc etc etc Università degli Studi di Napoli “ Federico II ” & INFN of Naples Resistive Plate Chamber System Data Quality Monitoring Framework RPCs confer robustness and redundancy to the muon trigger. • Tools for the creation, filling, storage, and visualization of histograms and scalar elements and standardized algorithms for performing statistical tests and automated certification. Double gap design - 2mm gaps - Common pick-up aluminum strips between the gaps - Bakelite resistivity 1010 Ωcm - Operated in avalanche mode (Operating HV = 9.3-9.4 kV) - Used gas mixture: 96.2% C2H2F4 ,3.5% i−C4H10, 0.3% SF6. Online DQM • Monitors detector, trigger and DAQ hardware status • Runs during data taking on special stream of events containing detector and trigger raw data, Level 1 and High Level Trigger (HLT) summary results and HLT by-products essential for monitoring trigger algorithms performance. Resistive Plate Chambers (RPCs), with their excellent time resolution (~ ns), were chosen as dedicated muon trigger detectors for the CMS experiment. RPCs fulfill the job of muon identification, estimate the momentum and unambiguously assign bunch crossing. The critical tasks of monitoring detector performances, debugging hardware, and certifying recorded data are carried out by the Data Quality Monitoring (DQM) system. The CMS DQM framework provides tools for creation, filling, storage, and visualization of histograms and scalar elements. It also offers standardized algorithms for performing statistical tests and automated data certification. Within this framework, the RPC DQM system was developed. The later is composed by a set of user defined algorithms and is intended to be used both online, during data taking, and offline, during the reconstruction stage at Tier-0 and re-reconstruction at the Tier-1s. Run by run, the system measures detector level and physics quantities which are subsequently stored in a dedicate database. Examples of monitored quantities are; occupancy, cluster size, synchronization, efficiency, and data integrity. We here describe the structure, functionalities, and performances of the DQM applications for the CMS RPC detector. Efficiency > 95% Time resolution ≤ 3 ns Average cluster size ≤2 strips Rate capability ≥ 1 kHz/cm2 Power consumption < 2-3 W/m2 Operation plateau > 300 V # Streamers < 10% Offline DQM CMS Operation Requirements • Certify the quality of reconstructed data and validate calibration results, software releases, and simulated data. • Run as part of the offline reconstruction task • 2 Step Process • Histograms are created and filled event by event. Monitored information is stored in normal event data files. • (Harvesting) – Histograms and monitoring information produced in step one are extracted and merged into the full statistics. Quality tests are performed along with specific analyses. Summary histograms of relevant quantities are also produced here. RPC DQM Principles and Architecture • Debug hardware, monitor detector performance and assess data quality. • Histograms are organized in a hierarchical tree-like folder structure reproducing detector geometry RPC  Barrel/Endcap  Wheel/Disk  Sector Layer  Roll • Special layouts containing only summary histograms are prepared for both RPC and central DQM shifters. • Quality tests: Fraction of dead channels, range of average, synchronization, and Front End Detector (FED) errors. The tests are repeated every periodically during run • Monitoring Needs • Occupancy. • Multiplicity • Number of signal hits • Cluster size • Number of clusters • Data integrity • Synchronization • Data time spread • Efficiency (only in offline) • DQM output, as histograms, certification results, and quality test results are saved into a ROOT file and then uploaded to a central GUI web server. 12° Topical Seminar on Innovative Particle and Radiation Detectors (IPRD10) 7° - 10° June 2010 Siena, Italy RPC Data Certification • Based on online/offline DQM and DAQ information. • DQM Quality Flag • Standard quality test applied to the occupancy distributions of each η-partition. • The fraction of alive channels, weighed by geometrical considerations • DAQ Quality Flag • Percentage of allocated Front End Detectors (FEDs). • Fatal errors (i.e. wrong FED IDs or inconsistent data size) the system immediately flagged as bad. • RPC Data State Machine • 7 allowed states: Good, Off,Dead, Partially Dead, Noisy Strips, Noisy Roll, Bad Occupancy Shape. [1] The CMS Collaboration, “The Compact Muon Solenoid Technical Proposal” (CERN/LHCC-94-38), CERN, 1994. [2] M. Abbrescia et al., “The RPC system for the CMS experiment at the LHC”, Nucl. Instrum. Methods A 508 (2003) 137-141. [3] L. Tuura, A.B. Meyer, I. Segoni and G. Della Ricca “CMS data quality monitoring: systems and experiences”, Proc. CHEP09, Computing in High Energy Physics, (Prague, Czech Republic). [4] CMS Collaboration, Commissioning of the CMS High-Level Trigger with cosmic rays, arXiv:0911.4889 [physics.ins-det] [5] CMS Collaboration, CMS: The computing project. Technical design report,. CERN-LHCC-2005-023. [6] ROOT - A data analysis framework, 2009, http://root.cern.ch. [7] L.Tuura, L. Eulisse, A.Meyer, “CMS Data Quality monitoring web service”, Proc. CHEP09, Computing in High Energy Physics (Prague, Czech Republic) 2009. [8] CMS Collaboration “CMS Data Processing Workflows during an Extended Cosmic Ray Run“, arXiv:0911.4842v2 [physics.ins-det]. [9] A. Afaq et al., “The CMS Dataset Bookkeeping Service”, Journal of Physics: Conference Series 119 (2008) 072001.