DQM for the RPC subdetector

DQM for the RPC subdetector

M. Maggi and P. Paolucci

DQM workshop - 28 feb 072


Outlook

RPC DQM requirementsevent Data DQM – what we have done and learned during the MTCCwe need more “sophisticated” DQM tools to access online database (non event data)guidelines and open issuesDQM group compositionconclusions



RPC DQM requirements

DQM has to monitor the RPC detector/trigger behavior and measure and summarize their performances:

Fast online DQM few histo/plot/result and summary results for central DQM shifter

“quasi” online DQM producing more and more info for RPC shifter and expert

offline DQM full analysis for expert



RPC DQM requirements

We need two different kind of DQM analysis data:1. Fast and “low” statistics analysis:

BXN # of digi Occupancy Cluster multiplicity Cluster size……………….

2. Slower and high statistics analysis:Chamber efficiencyStrip efficiencyEfficiency Map or chamber radiography (10 cm2)Calibration (eff .v.s HV)DCS – DQM – XDAQ Correlation



DQM Modes of Operation I

Online in Filter FarmInput rate: up to 100 kHzEvent Building: YesCPU: 10-0% of HLT CPUBw: 5-0% of total bw (1 GB/s)Delay: 0

Online in Event ConsumerInput rate: 1-10 Hz aggregateEvent Building: YesCPU: subsystem CPUsBw: consistent with experiment networkDelay: seconds

EXP. NETWORKMUST USE CMSSWMUST USE RCLIMITED ACCESS TO DBDCS: NODAQmon: NO

EXP. OR CAMPUS NETWORKMUST USE CMSSWCAN USE RCFREE ACCESS TO DB (EXP)DCS: via PSX or DBDAQmon: via DB



DQM Modes of Operation IIQuasi-online processing local file from SM

Input rate: O(10) Hz aggregate

Event Building: Yes

CPU: subsystem CPUs

Bw: consistent with experiment network

Delay: minutes

Offline processingInput rate: virtually all data stored (O(100Hz))

Event Building: Yes

CPU: batch farm

Bw: consistent with campus network

Delay: ~ 1 hour

EXP. OR CAMPUS NETWORKMUST USE CMSSWCAN USE RCFREE ACCESS TO DB (EXP)DCS: via DBDAQmon: via DB

GRIDMUST USE CMSSWCANNOT USE RCACCESS TO OFFLINE DB ONLYDCS: indirectly via condDBDAQmon: NO



What DQM do we need ? I

Online monitoring in Filter Farm:Rate of 100 KHz is perfect for high statistics analysis (calibration - efficiency)

pre-scaled subset of LV1 muon events (rate ?)

Can we effort a delay of 0 sec ?

Can we run high statistics analysis on CMS CPUs ?

No use of DCS and limited access to CondDB

Online monitoring in event consumer: Rate of 10 Hz is not enough for high statistics analysis

Full use of DCS and XDAQ data via DB

RPC CPUs (to design)

delay of seconds is OK for our goal



What DQM do we need ? II

Quasi-online DQM: Rate of 10 Hz is not enough for high statistics analysisLV1 muon eventsDCS and XDAQ access via CondDB (free access)RPC CPUsdelay of minutes is OK

Offline monitoring:for RPC experts to have a full analysis including reco tools and muon track or physics object (J/psi, Z…)Using full events and reconstruction toolsfree access to the DBsCMS CPusdelay of hours is OK



Can we do high statistics analysis ?

To achieve high statistics analysis (efficiency and calibration) we need: high rate of muon LV1A trigger (DT-CSC and/or RPC) CPUs and delay of minutes ≈ 1K (chamber) + 100 K (strip) + 1 M (area) bins (non so much

compared with CMS). At 1KHz 3.6 Mtrack/hour 21 Mhit/hour. 1 min for Effchamb – 1 hour for Effstrip – 100 hours for Effarea Full use of DCS and DBs ??

Ask for a special RPC calibration stream (size ?) including: RPC data + some DT and CSC data Store RPC stream on disk and use them for online and offline DQM (disk space ??)



Event Data monitoring STATUS I

DQM-analysis packages developed for RPC in CMSSW and test during the MTCC:

EventFilter/RPCRawToDigi (Segoni - Maggi): It drives the raw data unpacking and produces the RPCDigi collection committed to the event.

DQM/RPCMonitorModule (Segoni – Maggi): it carries out data integrity check and basic detector functioning tasks

POOLSource

Raw Data Digi

UnpackerDAQ

Clusters/RecHits

Local Muon Reconstruction RPCMonitorDigi

RPCMonitorModule

Event



Event Data monitoring STATUS II DQM/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:

BXN # of digi Occupancy Cluster multiplicity Cluster size

Sync: Specific trigger studies

Chamber efficiency is produced by extrapolating DT segments to the RPC mounted on the same DT chamber and looking for matching hits



Guidelines answers

YES, we need history/trendig plots (efficiency, occupancy, cluster size…)YES, we need correlation trendsYES, we need tools to extract complex info from condition DB and repositoryYES, we are using IGUANA to present DQM resultsMORE, we have to work on how make histo/result persistentMORE, we developed a first prototype of a synoptic view YES, we have a clear hierarchical view of the plotsNO, automatic analysis procedures, for the moment YES, we can converge on a run quality flags but we have to work on



RPC synoptic view

We have to work onThe synoptic view of RPC system with interactive features, alarm, warning and errorSimilar to the DCS one and to the other CMS subsystems



Do we need .. More .. Tools ? YES

For RPC it is CRUCIAL to correlate event data DQM info with PVSS and XDAQ non event data:

Chamber efficiency .vs. Noise (XDAQ) Chamber efficiency .vs. Current (PVSS) Noise (XDAQ) .vs. Temperature (PVSS) Cluster size .vs Temperature (PVSS) …………………………………………..

To let understand the behavior of the RPC system we need: few summary plots for the DQM shifter (online) more plots for RPC shifter (quasi-online) a complete way to analyze data for the RPC expert (offline)



Do we need .. More .. Tools ? YES

For MTCC data we developed the following tool CAT

For data tacking we want to integrate it in the DQM but we need to take some decisions:

1. How access online at the Condition DB: direct access to the DB or to a replication of the DB ??

2. Which and how many plots we want to store permanently ??

3. Do we need reference plots also for correlated data ??4. Can we show/store in the DQM full DCS and XDAQ

histograms/results too ??

Analysis tools

Online DB Root files

DB query

histograms

DB replication



Histos example …. for MTCC

RMS distribution of the 23 chambers for a 4 days period with magnet ON and stable conditions

Having 480 chambers only in the barrel it was very useful to have summary plot from DCS (retrieving data from cond. db). We need to think about more summary plots from DQM–DCS–XDAQ

RMS = 0.5 A

Chamber to check using more info from DCS-DQM-XDAQ for RPC expert



A way to use in a safe way condDB

OMDS@IP5 ORCON@IP5ORCOFF@T0

HLT-CMSSW application Reconstruction-CMSSW application

read/writeread/write objects

read/write read/write objects

Transformation (O2O)

DCS/DQM

Application

DQM/Offline

Application



RPC DQM group composition

The group works in the DPG under the supervision of M. Maggi and myself and in contact with Muon DPG people.

detector DQM:Bari – 4 people sharing with Offline/DQM

Napoli – 5 people sharing with DCS

Pavia –2 people sharing with Reco & Ev Displ.

trigger DQM: Warsaw group sharing with trigger activities

We need people from the endcap groups



Conclusions

The RPC-specific components of the DQM structure in CMSSW are under development to test on MTCC data with proper Global DAQ format.The development now must focus now on:

Quantify high statistics analysis (RPC stream or FF analysis or both ?) Study the way to Interface DQM with DCS-XDAQ and with CondDB Select a few number of “smart” summary histo/plot/tables Study how produce RPC system flag Develop: detector visualization and web interface, quality test producing warning, error and alarm with a tree-like structure

Documents

DQM for the RPC subdetector