Sistema di Data Quality Monitor di CMS e trigger locale delle DT

Transcript

1 Sistema di Data Quality Monitor di CMS e trigger locale delle DT Carlo Battilana & Stefano Marcellini Bologna CMS meeting, 21 Gennaio 2008

2 Outline 1. Introduzione al DQM di CMS e alla GUI (Obiettivi, Componenti e Infrastruttura) 2. Sistema di DQM delle DT al commissioning 3. DQM del trigger locale delle DT (Funzionalità, Analisi del trigger online ed offline, Piani per il futuro) 2

3 Introduzione al DQM di CMS 3

4 Caratteristiche del DQM L'obiettivo principale del DQM è quello di controllare, mostrare ed archiviare informazioni sulla qualità dei dati rendendole facilmente accessibili e consultabili (localmente ed in remoto) sia online che offline. Esso deve essere in grado di gestire grande quantità di informazioni (O istogrammi), sintetizzarla in un insieme ridotto di osservabili (plots, grandezze numeriche...) e fornire all'utente un riscontro rapido di eventuali anomalie (quality flags, alarms, warnings). Il sistema dev'essere il più possibile modulare (personalizzabile per i singoli sottosistemi) ma nel contempo deve fornire un'interfaccia uniforme e deve operare in maniera centralizzata ed automatica. Infine dev'essere robusto, affidabile e di facile utilizzo. 4

5 Architettura online DQM e Global DAQ Monitor Element (ME) : osservabile di qualsiasi tipo (Istogrammi, valori numerici, bool...) DQM Producer : modulo CMSSW che produce MEs a partire dai dati contenuti nell'evento DQM Client : modulo CMSSW che genera osservabili di riepilogo e opera test di qualità a partire da altri monitor elements (eseguiti al termine dei luminosity block). Graphical User Interface (da Marco Zanetti Muon Barrel Workshop) HLT reco/filters HLT reco/filters HLT+ reco/filter + DQM Producers + DQM Producers DQM Producers events MEs Storage Manager (Proxy Server) DQM Producers + DQM Clients events MEs event rate del livello 1 (100 khz) utilizzano una piccola frazione di CPU e banda devono essere stabili! DQM Clients Store Histograms (root files) event rate ridotto (~5-10 Hz) completamente svincolati dalla farm di HLT indipendenti tra i vari sottosistemi codice più facilmente aggiornabile 5

6 Architettura DQM al GREN (Andreas B. Meyer) 6

7 Infrastruttura della GUI del DQM La GUI fornisce un interfaccia uniforme e di facile consultazione agli istogrammi dei diversi sottosistemi (e alle informazioni di sommario) e permette una personalizzazione dei layouts di visualizzazione e delle opzioni di rendering (RenderPlugins) visdqmcollector/dqmcollector Web Browser DQM Client DQM Client DQM DQM Client && Client DQM Client & && DQMProducer DQMProducer DQMProducer DQMProducer DQMProducer Sistema di gestione dei MEs che ascolta Clients e Producers memorizzando gli osservabili in una cache e permette accesso agli stessi da parte di altre applicazioni visdqmgui visdqmserve web server che ascolta le richieste del browser ed interagisce col rendering backend (visdqmserve) sistema di renderizzazione che dialoga col sistema di gestione dei MEs e produce immagini su richiesta 7

8 Esempio di di visualizzazione al GREN Navigazione Istogrammi Sommario RUN Allarme di fallimento test 8

9 DQM delle DT al commissioning 9

10 Infrastruttura DQM delle DT Allo stato attuale DQM delle DT opera sui file acquisiti tramite il sistema di DAQ locale, si interfaccia a diversi RDBMS (sqlite files, ORCON/ORCOFF), ed è possibile che non siano disponibili calibrazioni (ttrig e noise) corrette o non siano necessarie. Inoltre è necessario che i layout di visualizzazione siano prodotti dinamicamente in base alle caratteristiche di presa dati. Per soddisfare queste necessità sono utilizzati scripts che automatizzino l'esecuzione delle sorgenti del DQM e configurino la GUI a seconda delle esigenze dello shifter. Ultimamente inoltre la vecchia versione di CMSSW (1_4_5) è stata rimossa e il sistema di visualizzazione ha subito cambiamenti radicali (e con esso gli stessi scripts). GUI DB Info: mapping, t0, ttrig, noise DAQ spy events File events DQM Producers + DQM Clients Store Histograms (root files) 10

11 Status DQM delle DT a P5 La nuova versione degli scripts relativi al DT-DQM (basata su CMSSW_1_7_4) è stata installata su alcune macchine della control room (usc55ucr ) e comincia ad essere utilizzata: i comandi di base e la sintassi sono simili a quelli dei vecchi scripts (manca runiguana al suo posto bisogna aprire un browser sulla pagina della WebGUI) il sistema è stato in parte adattato per poter essere eseguito su più ruote contemporaneamente (c'è ancora la dipendenza da DB sqlite per wheel) i vari moduli di DQM sono stati aggiornati (osservabili e test aggiuntivi, bugfix) è possibile utilizzare, per ora solo DB sqlite (non è possibile collegarsi ad ORCON/ORCOFF) eseguire l'intera suite di scripts (+GUI + Collector) su una singola macchina rallenta molto il processamento, pertanto è consigliabile non abilitare la ricostruzione dei segmenti se non è necessaria (possibile divisione del carico su più macchine o utilizzo di minidaq) per ora sono stati implementati solo parte degli scripts (setdqm, rundqm e runvisual) e altri sono in fase di aggiornamento 11

12 DT DQM & GUI al commissioning 12

13 DQM del Trigger Locale delle DT 13

14 Caratteristiche, osservabili, e test Caratteristiche DQMProducer del trigger locale delle DT (eseguito ad ogni evento): processa dati provenienti da diversi tipi di sorgenti (DCC e DDU) e li compara con i risultati provenienti dalla ricostruzione dei segmenti (se presenti). utilizza l'informazione di BX, qualità, e 1st/2nd track flag e (per dati dalla DCC) angolo radiale e angolo curvatura. è in grado di discriminare i risultati in funzione del sottosistema/i coinvolto/i nel processo di trigger (DT only, DT also, No DT) Caratteristiche del DQMClient del trigger locale delle DT luminosity block): (eseguito a multipli di produce istogrammi di riepilogo (efficienze rispetto ai segmenti, frazione di correlati, frazione di seconde tracce) a varie granularità (camera, settore, ruota) effettua test di qualità sugli istogrammi precedenti e sulla consistenza delle LUT. L'analisi, dove possibile si applica sia nella vista phi che in quella theta. Il sistema viene utilizzato sia in fase di presa dati che durante l'analisi offline (Talk Stefano del 18/12/2007). 14

15 Plots e analisi Offline (1) Risultati dal run (ruota 1 settore 4) : Eff. vs Posizione : Eff. vs angolo d'incidenza : 15

16 Plots e analisi Offline (2) Efficienza (Posizione vs Angolo) : BX vs Qualità : no theta view in MB4 16

17 DQM del Trigger Online 17

18 Istogrammi di sommario e tests Producer: Distribuzione di qualità per singola stazione Client: Frazione di correlati per settore (test di qualità) corretto funzionamento errore warning Client: Frazione di correlati per ruota (plot di sommario) qui viene segnalato un errore I Test vengono effettuati con granularità di settore poiché, allo stato attuale è possibile che vengano presi dati utilizzando solo parte dell'inera ruota. 18

19 Analisi dati al GREN (1) Trigger data read from DTTF DCC during GREN contains more information than data coming from DDU used during local DT commissioning. Beside the usual BX, Quality and 1st/2nd track flag is also possible to obtain information about the position and the direction of the incoming muon that caused the trigger. This kind of analysis is performed for the first time on real data (using DQM infrastructure). Quality vs position and quality vs angle of incidence plots for wheel 0 sector 11 station 4 : Angular distribution of triggers for wheel 0 sector 4 station 4 : Absence of uncorrelated L triggers due to NoSingleLow minicrate configuration. 19

20 Analisi dat al GREN (2) Comparison between local reconstructed (2D) segments position (cm) and direction (deg) versus Trigger radial angle and bending angle information for wheel 0 sector 11: Position plot shifted for MB2 No bending angle information in HW for MB3 stations Some direction plots resulted anticorrelated. Summary plots an quality tests on slope and intercept of the correlation plots have been implemented in order to spot these problems. 20

21 Analisi dati al GREN (3) BX versus Quality plots comparison between data coming DCC and DDU for wheel 0 sector 11 station 4: Quality correlation plot (DDU vs DCC) for wheel 0 sector 11 station 4: Good correspondence between DDU and DCC data, small differences expected due to the different BX range. Events with DDC data but no DDU data also understood (known DDU HW feature ). 21

22 DQM del trigger ed emulatore E' possibile sostituire ai dati nel formato ufficiale (provenienti dalla DCC) le informazioni ottenute utilizzando l'emulatore del DT-TPG e confrontare dati reali ed emulati utilizzando il DQM, una tale configurazione potrebbe essere già possibile nelle future fasi di commissioning (utilizzando minidaq) La natura asincrona dei cosmici causa problemi di sincronizzazione dell'emulatore pertanto il confronto può essere solo statistico ed approssimato. Commissioning trigger data (DDU) Commissioning trigger emulation (DCC) Nonostante ciò la corrispondenza coi dati reali è notevole. La possibilità di utilizzare l'emulatore come strumento di validazione è ancora limitata ma diventerà più concreta in futuro ed è importante sviluppare gli strumenti. Trigger Quality 22

23 Conclusioni e piani di sviluppo Il sistema di DQM del trigger locale delle DT è uno strumento stabile e ampiamente utilizzato ma tuttora in fase di sviluppo: l'esperienza del GREN ha dimostrato che è necessaria una semplificazione dei parametri di configurazione la struttura del codice (booking dinamico dei singoli istogrammi) va semplificata ed è opportuno separare i clienti per tipologia di test (efficienze, controllo delle LUT...) vanno aggiunte osservabili che permettano di valutare la sincronizzazione (prima coi cosmici, poi in run con fascio) ed eventualmente forniscano una base per automatizzarne il processo va introdotto un sistema di flag di qualità che sintetizzi ulteriormente lo stato di funzionamento del trigger (nell'ambito del DQM delle DT) è necessario aggiungere nuovi istogrammi (es. confronto con le RPC o con l'emulatore) man mano che si mostreranno necessari e rimuovere quelli di scarsa utilità i test di qualità devono essere calibrati in maniera ottimale e se ne devono introdurre di nuovi in seguito all'aumento del numero di osservabili 23