Monitoring online - dove monitoriamo, - su quali e quanti eventi (Callot ) - con quali strumenti -cosavogliamo monitorare (timing, efficienza, allineamenti ) - su quali oggetti monitoriamo (tutti gli hit, hit mu, tracce mu) # Cosa ci serve nella fase di commissioning e cosa pensiamo di monitorare sempre durante il data taking - quando / con che frequenza (una tantum, a inizio run, in continuazione) - Abbiamo bisogno di Run speciali? # schedula temporale per scrivere il software di monitoring # suddivisione del lavoro / responsabilita` Roma 04-04-06
Dove come - su quali eventi # Nel Frontend (40 MHz) nelle ODE monitor ECS # Nel TELL1 (1 MHz) Noi abbiamo tools nell elettronica che ci permettono di fare monitoring che altri pensano di fare su eventi triggerati. Occorre studiare (perche da una parte e` utile avere ridondanze ma bisogna evitare sprechi) # Nella farm EFF (~2000 CPU) L1-HLT (1MHz 2 khz) Il monitor richiede risorse costose (non tanto per gli algoritmi ma per l accesso e la somma di istogrammi da 2000 nodi.) da evitare a meno che non sia necessario monitorare dati non disponibili piu` tardi. # Nella EFF- Calibration - Parte della Event Filter Farm dedicata al processamento di eventi speciali di calibrazione in genere da non scrivere su storage (calibrazione continua della risposta del Calorimetro) Noi non pensiamo di utilizzare questa possibilita` (??) (- Calibration pulse ciclati sui canali fisici. - Empty events..)
# Su gli eventi selezionati per il DAQ (2 khz) quando sono pronti per essere inviati a un writer. (~ 200 Hz del main stream fully reconstructed + 1800 Hz di altri stream che overall contengono ~1500 Hz di Muoni selezionati con gli algoritmi di HLT) Task semplici di alta priorita` (event size, rates..) si possono effettuare su tutti gli eventi (nei server che li mandano ai writer?) Un monitoring server spedisce una frazione di questi eventi ad una Monitoring Farm MF (~~ 50 CPU) La MF sta in baracca con la EFF ma non e` connessa al readout network. Non c e` un output evento per evento. L output sono solo statistica e istogrammi. La MF deve poter leggere eventi da file per test fuori data taking, ma il suo main input sono i dati online. L input di ogni nodo puo` essere al livello di ~100Hz. Per diminuire il carico sulla rete (a prezzo di sviluppo di software dedicato) si puo` anche mandare solo parte di un evento
Alcuni nodi della MF saranno dedicati esclusivamente al rivelatore Mu. (~ 5? dipende anche da quanto vogliamo pagare). Qui possiamo fare quello che ci pare, per esempio se vogliamo idividuare quali hit sono associati a muoni, si possono effettuare algoritmi tipo fast tracking mu in HLT (il risultato del tracking gia` fatto e` andato perduto). Per il monitor del timing si puo` ragionevole pensare a ~ 500 Hz di eventi in totale che dovrebbero essere divisi tra diverse CPU. Warning di Callot: In case of need, the same code could run on several nodes, provided each node gets different events. This complicates the handling of events, and of histograms from this task: they have to be summed before being used. Our idea is to try to avoid this complication as much as possible Se si vogliono eventi ricostruiti (full tracking, PID ) si puo` contare su 10-50 Hz in tutto (mu e non mu) che possono essere mandati alla MF. Probabilmente questi eventi saranno anche salvati temporaneamente sui dischi online (dell ordine del milione di eventi al giorno )
ISTOGRAMMI Histograms produced spontaneously by the monitoring tasks are processed in the general computing infrastructure, where anomalies are detected and alarms generated for the Shift Crew. Histograms are also accessible online by the histogram system, for presentation. PVSS is not the appropriate tool to handle histograms An activity to produce a histogram handling system should be started in the collaboration, well integrated with the Online and Computing projects - FORMAT ROOT - ACCESS using DIM protocol (access mechanism should perform an automatic addition of the histograms) - Histograms produced in electronics boards will have to be converted to the ROOT framework by the access system. This should be implemented in the CCPC or Control PC. - PRESENTER : Fitting, superimposing, addition of plots, efficiency computation from raw counters, are all useful features. ROOT? (layout, histogram scale should not be modified by every person on shift). - ANALYSIS code will be SD specific, but based on common tools, and should be integrated in the common histogramming framework.
Cosa vogliamo monitorare Occupancy Per evidenziare canali morti o inefficienti e canali rumorosi. (+ rough check of the system stability, efficiency) Questo tipo di monitoring puo` anche essere fatto con maggiore statistica sui contatori del DIALOG che sono accessibili via ECS (per di piu sui canali fisici ) Bisogna vedere come si puo` monitorare via ECS e decidere (se/) come farlo anche online. Esempio M5: sul DIALOG abbiamo ~10 MHz x 5 hit / 20.000 fis.ch. ~ 2500 hit/sec per canale in media Gli istogrammi si riempiono rapidissimamente (overflow stop a tutti i canali trasferimento azzeramento) Ogni quanto si interrogano gli istogrammi? Banda di trasf. disponibile? La occupancy misurata con ECS nei canali poco popolati contiene piu` noise della occupancy misurata online sugli eventi triggerati (soprattutto all inizio se si lavora a bassa luminosita`)
occupancy ON LINE Histogrammi di illuminazione dei canali logici (26k) Se consideriamo 500 Hz (di eventi selezionati per il DAQ inviati a ~ 5 CPU della MF) ~1.5x10 4-6x10 4 hit/ora per canale. in M2 ~3x10 3 1.3x10 4 in M3 Ci basterebbero ~ 100Hz? Bisogna fare delle slice intelligenti delle regioni accorpando opportunamente i canali per evidenziare buchi (canali morti o inefficienti) e picchi (canali rumorosi). Su ciascun istogramma cosi' costruito andranno segnalati quei canali che si distaccano troppo dal comportamento medio tipico della regione/stazione, con un taglio a N sigma o cose simili
Cluster size Monitoring del Cross-Talk (non si puo` fare via ECS) Il cluster size CS locale (average n. of adjacent hits fired per logical channel hit) puo` essere fatto su tutti gli hit. Con Xtalk 10% ~300 1000 eventi /canale ora in M3 Se si vuole fare una misura piu precisa del xtalk si possono selezionare hit di mu (per i quali si possono anche ragionevolmente sottrarre effetti di geometria e valutare il xtalk capacitivo). Misura da fare per calibrare la simulazione Pero` un monitor sugli hit di mu canale per canale sarebbe lento. Un monitor rapido si puo` fare sul CS integrato della camera (utile test di buon funzionamento insieme con l efficienza) Con xtalk 10% camera per camera in M3 su tutti gli hit > ~ 7x10 3 eventi/ora su gli hit mu > ~ 500 eventi/ora
Fine Timing Non si puo` fare via ECS Misura del TDC per gli hit assegnati ad una traccia Mu (bisogna fare un tracking nella MF) (gli hit di fondo hanno una distribuzione piu` larga e con massimi spostati nelle varie stazioni e regioni mentre gli hit di Mu hanno una distribuzione stretta e omogenea) # Operazione da fare nella fase di commissioning (fine tuning della sincronizzazione dei canali) # durante il data taking monitor continuo del lavoro delle camere Average time and RMS for each logical channel. - The average allows to check that the channel is well time-aligned inside the 25 ns. - The RMS (must be ~4 ns) is a good monitor of the correct MWPC working. Considerando una rate di 500 Hz di eventi Mu In 1 ora ~ 1.8 million muon hits per station (in M2, M3 ~ 5000 logical channels ~~ 200-700 hit/chan).
efficienza Bisogna tenere una mappa di efficienza del rivelatore Mu da aggiornare continuamente La efficienza locale del rivelatore e` in qualche modo gia` monitorata dai tool considerati - canali morti. (occupancy, eventualmente sistema di impulsaggio). - camere (timing e crosstalk) Non farei misure vere e proprie di efficienza di tracking online Bisogna studiare altri indicatori utili - stabilita` di trigger rate destra sinistra, in zone del detector. - rapporti di occupancy integrata in stazioni, regioni, camere
Debugging e test Nella monitoring farm sara` bene preparare anche toolings software che non saranno necessariamente usati nel monitor del rivelatore a regime ma che serviranno per debugging iniziale e test. Probabilmente lo stesso manpower che prepara una cosa e` adatto a preparare l altra. In particolare le CPU della MF sembrano il luogo ideale per test che richiederanno la acquisizione di eventi. Ci vuole una comunicazione tra i nostri PC di controllo dell ECS e le nostre CPU della MF?
Allineamento All inizio durante il commissioning si avra` probabilmente molto a lungo il magnete Off. Per di piu sarebbe bene poter essere non dipendenti dal OT che potrebbe non essere tunato. Se si potesse fare un allineamento senza campo magnetico (ed eventualmente senza OT) sarebbe probabilmente molto utile. In seguito l allineamento si potra` fare meglio con l OT e con il campo magnetico On. Quindi entrambe le procedure (allineamento con e senza campo magnetico) dovrebbero essere studiate e previste (se l allineamento senza campo magnetico risulta significativo). Oltre a verificare se l allineamento hardware e` adeguato (~1 mm in R1 altrimenti va rifatto), dobbiamo decidere se vale la pena di fare un allineamento software per HLT???. In questo caso bisognerebbe prevedere un Run iniziale ogni volta che si e` aperto il detector Mu, dopo il quale si aggiornano i parametri della posizione delle camere. Per il VELO un Run speciale iniziale e` previsto dopo ogni fill (Oppure selezione di eventi tipo Velo Alignment dal readout supervisor ODIN, oppure uso di Nodi dedicati alla Farm)
# schedula temporale per scrivere il software di monitoring Non credo sia necessario fare del lavoro di sviluppo software urgentemente visto che sia il frame generale in cui si deve lavorare sia alcuni tool comuni non sono ancora pronti e neanche del tutto decisi. Pero` Sarebbe bene seguire da vicino gli orientamenti che si stanno formando e i progressi che si fanno nel gruppo commissioning e online. Sarebbe opportuno trovare qualcuno che possa fare lavoro vero a partire probabilmente da Settembre. # suddivisione del lavoro / responsabilita`