Sistema di Trigger e di Acquisizione dati di CMS c 2008 by Antonio Pierro November 3, 2008

Transcript

1 Sistema di Trigger e di Acquisizione dati di CMS c 2008 by Antonio Pierro November 3, Introduzione Dal punto di vista del computing, il DAQ di CMS consiste in un grande ambiente di calcolo distribuito, con un centinaio di workstation UNIX connessi da reti d interconnessione ad alta performance (circa 10 Gigabit/secondo per ogni link), progettato in modo da equipaggiare l esperimento con uno strumento molto affidabile ed efficiente per la lettura dei dati e la selezione degli eventi. Il DAQ implementa tutto il sistema necessario al trasferimento dei segnali registrati dall esperimento verso le unità addette alle loro analisi, includendo meccanismi di filtraggio degli eventi, Trigger, prima dell archiviazione definitiva su disco. Esso include anche tutta la struttura informatica necessaria per gestire e controllare il funzionamento degli apparati elettronici. Il sistema di acquisizione suddivide l insieme dei rivelatori in diverse entità indipendenti: questo permette di acquisire dati in parallelo e effettuare su questi le opportune selezioni, in modo totalmente indipendente le une dalle altre. 2 Il sistema di Trigger in CMS Alla luminosità massima nominale di LHC il numero di eventi prodotti sarà 10 9 eventi al secondo, valore estremamente superiore alle capacità di archiviazione delle memorie di massa. È proprio in questo contesto che entra in gioco il TRIDAS (sistema di trigger e di acquisizione dati, Trigger and Data Acquisition System) che ha il compito di eseguire la selezione degli eventi interessanti e la riduzione del flusso dati a valori accessibili per le tecnologie oggigiorno disponibili [5]. In dettaglio, il sistema di Trigger e Acquisizione Dati di CMS è stato progettato per leggere il rivelatore alla piena frequenza di collisione dei protoni (40 MHz) e per selezionare non più di 100 eventi interessanti al secondo, da registrare su nastro. Il fattore di reiezione 10 5 è troppo grande per essere ottenuto in un singolo processo di filtro, soprattutto se si desidera mantenere una buona efficienza di selezione per il programma di fisica di CMS. 1

2 Figure 1: Diagramma a blocchi del sistema di trigger e acquisizione dati; Differentemente dello schema tradizionale del trigger con almeno altri due livelli dopo il primo, la scelta di CMS è con un unica struttura dopo il trigger di Livello 1. [6] I dati selezionati dell HLT vengono archiviati nelle memorie di masse pronti per essere analizzati attraverso la Grid. 2

3 Ed è per questo, che il processo completo di selezione è suddiviso in due passaggi (vedi figura1): il primo è svolto da un sistema hardware che ha il compito di accettare eventi con un rate che non superi i 100 KHz (Trigger di livello 1 ); il secondo è svolto da una certo numero di CPU su cui girano un insieme di algoritmi dedicati all ulteriore selezione degli eventi forniti dal trigger di livello 1 e che costituiscono l HLT (High Level Trigger ). Solo in questa fase entrano in gioco anche i dati del tracciatore. In conclusione, il rate finale di eventi selezionati deve essere inferiore a 100 Hz che è la frequenza con cui si registrano definitivamente gli eventi su nastro. Nel seguito viene descritto nel dettaglio l implementazione dei due sistemi. 3 Il Trigger Hardware o di Livello 1 Dal momento che la frequenza di interazione dei fasci di protoni ad LHC è di circa 40 MHz, ovvero un bunch crossing ogni 25 ns, il trigger di primo livello deve analizzare eventi ogni 25 ns. Questo intervallo di tempo è troppo piccolo per leggere dal rivelatore tutta l informazione completa sull evento e fornire la decisione del trigger. Pertanto i dati sono immagazzinati in pipe-line presenti sull elettronica di frontend per i 3.2 microsecondi successivi all incrocio dei fasci e solo le informazioni fornite dai sottorivelatori più veloci sono analizzate dall elettronica di Trigger. Infine, per evitare quanto più possibile il tempo morto del rivelatore, l elettronica di FrontEnd è a sua volta organizzata in pipe-line così da consentire la lettura dei dati ogni 25ns. Facendo quindi una stima del tempo necessario per processare i dati al trigger L1 e quello necessario allo scambio delle informazioni, ci si aspetta che il trigger L1 arrivi ad un fattore di riduzione del bunch crossing di 400, e quindi ad accettare un rate di 100 KHz. Questi vincoli impongono l utilizzo di algoritmi di selezione molto semplici. Infatti il fatto che ogni pezzo del processo di selezione non dura più di 25 ns preclude la possibilità di usare algoritmi iterativi. Ebbene notare come nel trigger di livello 1 vengono utilizzati solo le informazioni locali. In dettaglio, tutti i segnali raccolti dai sensori di un particolare sottorivelatore, si ottengono senza avere una visione di insieme dei dati acquisiti, cioè senza 3

4 un analisi dei dati che tenga conto che tutti i segnali acquisiti da ogni singolo sensore del sotto-rivelatore non sono altro che una parte di un unico evento e quindi di un unico processo fisico (compito dell HLT). In pratica, nel trigger di livello 1, ci si limita semplicemente a identificare, per ogni sensore di un sottorivelatore, gli oggetti di trigger di vario genere (muoni, elettroni, fotoni e jet di varia natura) aventi un impulso trasverso o energia trasversa superiore ad una soglia prefissata. In pratica, l elaborazione dei dati operata dal Trigger di livello 1 e completamente hardware, ovvero gli algoritmi impiegati per la riduzione del flusso di dati sono realizzati mediante reti logiche integrate sui componenti del sistema[1]. Il sistema di lettura (read-out) può memorizzare gli eventi in uscita dal Trigger di livello 1. Solo in seguito, attraverso l HLT, si deciderà se se tenere o rigettare gli eventi assemblati tramite l Event Builder. 4 Event Builder Per fornire la connettività tra il sistema di read-out e i computer della farm (dove viene memorizzato l evento assemblato ed è fatto il trigger di alto livello), è utilizzata una rete a commutazione 1. Tale rete deve essere in grado di sostenere un flusso di dati di circa 1 Tb/s. L insieme del sistema di read-out e la rete per la connettività neccessaria a assemblare l evento forma un grande ambiente di calcolo distribuito che rappresenta una sfida per le odierne tecnologie di calcolo. Le principali componenti del sistema che permettono di assemblare l evento sono: Front End Driver (FED), (talvolta indicato come DDU, Detector Dependent Unit) è il componente più vicino al rivelatore. Le informazioni provenienti da quest ultimo sono formattate all interno del FED mediante l aggiunta ai dati di un header 2, in cui sono contenute le informazioni necessarie per la ricostruzione dell evento. Trasporto dati in superficie (LINK). Le porzioni di evento, event fragments, raccolte da ciascun FED devono essere trasportate in superficie nella counting room. Tale collegamento ha una lunghezza dell ordine di 100 m e deve 1 La rete a commutazione consente lo svolgimento simultaneo di più comunicazioni fra nodi, massimizzando così l utilizzazione dei mezzi trasmissivi impiegati 2 L informazione formattata con l agginta dell header viene detta event fragment 4

5 sopportare un flusso di dati ad una velocità media di 200MB/s per porta con picchi che possono arrivare a 400MB/s per porta(vedi figura [2]). La tecnologia adottata è una soluzione completamente commerciale, vale a dire il link ottico Myrinet 3 proposto da Myricom. Esso ha una larghezza di banda di 2 Gb/s ed include un semplice protocollo con controllo del flusso per evitare la perdita di pacchetti di dati. L Unità di read-out (Read-out Unit, RU), è composta da tre blocchi: la Readout Unit Input (RUI), la Readout Unit Memory (RUM) e la Readout Unit Output (RUO). La RUI riceve le parti di evento dal LINK e le memorizza temporaneamente in un buffer(fu), a disposizione della RUM. Quest ultima legge le parti di evento provenienti dalla RUI e le memorizza, assieme al numero d identificazione del fascio (bunch-crossing ID). Alla richiesta, da parte dell event builder (v. sotto), di una lettura dati, le parti di evento interessate sono inviate alla RUO. Event Builder (vedi figura 4), è composto da due parti: la Builder Unit (BU) e la Filter Unit (FU). La BU assembla le porzioni di evento provenienti dalla RU attraverso una rete chiamata Barrel shifter (vedi figura 6 e 5) In seguito la BU memorizza l evento completo in un buffer. La FU è l elemento dove avviene l HLT. Un Event Manager (EVM) controlla il flusso dell evento lungo il sistema di lettura e di selezione, gestendo in modo centrale le risorse di read-out e ricostruzione. In questo contesto, l Event building è la procedura che compone l evento finale e permette di accedere ai dati il più rapidamente possibile, assicurandosi che l evento è coerente e completo Riassumnedo, dopo che un evento è stato accettato dal Trigger di Livello 1, un sistema di creazione degli eventi (EventBuilder) ha il compito di leggere da tutti i sottorivelatori i dati dell evento accettato. I dati raccolti (per ogni evento circa 1 MByte) vengono passati al trigger di alto livello (HLT). Poichè la frequenza massima del trigger di primo livello è di 100KHz il sistema di creazione degli eventi deve gestire circa 100 Gb/s. Per un traffico così intenso è necessario un certo numero di sistemi 3 Myrinet è una tecnologia per realizzare reti d interconnessione ad alta performance utilizzata per creare clusters di workstations o servers. E particolarmente adatta per calcoli paralleli strettamente connessi, dove sono necessari alti data-rate, basse latenze di trasferimento, e il rilevamento dinamico e l isolamento dei guasti. 5

6 Figure 2: Rete di interconnessione che permette la comunicazione contemporanea tra N coppie di unità logiche in un insieme di 2N unità. 6

7 Figure 3: Diagramma a blocchi del processo di presa dati.[1] 7

8 paralleli in grado ognuno di gestire un certo numero di eventi al secondo. (per i dettagli vedere le figure 2, 5, 6, 4) Figure 4: L Event Builder di CMS comprende le unità di read-out ROs, le unità di builder (builder units - BUs) e un gestore di eventi(evm), il tutto collegato da una rete (Builder Network)[1] costituita da cavi aventi una banda di 2 Gb/s ciascuno 5 Il Trigger Software o di Alto Livello Come detto, tramite l Event Builder ogni evento viene inoltrato alla farm di computer che implementa l HLT. L HLT è realizzato completamente via software. In questa fase di selezione degli eventi si possono utilizzare gli algoritmi di ricostruzione che permettono di ricostruire 8

9 Figure 5: Schema del traffico dei dati che si ha nel barrel shifter. Nel primo intervallo di tempo, solo la sorgente 1 (RU 1 ) manda dati al buffer di destinazione (BU 1 ). Nel secondo intervallo di tempo, la RU 1 manda dati alla BU 2 mentre la RU 2 anda dati alla BU 1. Durante l intevallo di tempo k-esimo la RU 1 manda dati alla BU k, la RU 2 alla BU k 1 e così via. Dopo N intervalli di tempo (dove N è il numero di sorgenti) tutte le sorgenti avranno mandato scambievolmente dati alle rispettive destinazioni [2]. 9

10 Figure 6: Nella seguente figura, si vuole mettere in evidenza come è possibile assemblare l evento. Ogni pezzettino avente un determinato colore corrisponde ad un event fragment. Pezzettini con lo stesso colore sono event fragment presenti in diversi sottorivelatori ma appartenenti allo stesso evento. Ogni sottorivelatore contiene memorizzati in una coda informazioni corrispondenti ad eventi diversi (pezzettini con diverso colore). Il processo di ricostruzione dell evento avviene nel seguente modo: ogni singolo buffer BU (ognuno con un diverso colore) riceve, con un ordine progressivo, diversi frammenti (ognuno estratto in maniera ciclica da un diverso sottorivelatore) corrispondente allo stesso evento (stesso colore). [1] 10

11 le tracce o di cercare vertici secondari. L HLT, al contrario del trigger di primo livello, dispone di tutti i dati di CMS inclusi tracciatore, preshower e risoluzione massima dei calorimetri. Gli algoritmi di ricostruzione sono sostanzialmente gli stessi utilizzati nell analisi off-line. Nella scelta degli eventi non è tuttavia necessaria la stessa precisione richiesta dall analisi off-line, quindi gli algoritmi di ricostruzione sono modificati in modo da essere più veloci anche se meno precisi. Ad esempio per misurare l impulso di una particella solitamente si utilizzano, durante la ricostruzione della traccia, tutti i punti disponibili nel tracciatore; la ricostruzione per l HLT può invece essere limitata ai primi N punti. Il trigger di alto livello passa eventi all HLT con una frequenza massima di 100 KHz: questo tempo è sufficiente a leggere i dati all elettronica di Front-End di tutti i sottorivelatori e scrivere le informazioni su memoria RAM. Per abbassare il rate di eventi dell ulteriore fattore 1000 richiesto, mantenendo un alta efficienza di selezione per i canali più interessanti per il programma di fisica, è necessario utilizzare tutte le informazioni del rivelatore, compreso il tracciatore, con la massima risoluzione e granularità ed utilizzare algoritmi di selezione sofisticati quasi quanto quelli dell analisi offline. Da una stima della velocità dei processori che saranno disponibili al momento dell installazione dell HLT, si ritiene che siano in media necessari 40 ms per analizzare un evento con punte di 1 secondo: questo implica una significativa capacità di buffering. A differenza di altri esperimenti di fisica delle alte energie l HLT di CMS è costituito da un solo livello (vedi figura1). Pur essendo una singola entità l HLT di CMS utilizza un approccio basato su più passaggi e gradi di analisi progressivamente più approfonditi. Dopo ciascun passaggio, alcuni criteri di selezione possono rigettare una significativa frazione di eventi accettati dal passaggio precedente; in questo modo il rate di eventi che deve essere processato dagli algoritmi rimanenti è ridotto e si ha un conseguente risparmio di CPU. I vari passaggi indicati precedentemente vengono convenzionalmente chiamati livelli di trigger (anche se questa distinzione non fa riferimento a sistemi di trigger fisicamente separati). Il livello 2 è costituito dagli algoritmi che utilizzano informazioni solo dai calorimetri e dalle camere a muoni: come il trigger di primo livello, ma questa volta con piena granularità e risoluzione. Il livello 2.5 utilizza un informazione parziale del tracciatore, come gli hit negli strati a pixel per fare una veloce distinzione tra gli elettroni e i fotoni. 11

12 (La ricostruzione delle tracce è parziale nel senso che si controllano solo i pixel che stanno nella direzione di volo di particelle già viste nel trigger L1). In dettaglio: Gli Elettroni e fotoni hanno bisogno di una ricostruzione rapida in quanto utilizzati come oggetti di trigger. La ricostruzione di elettroni e fotoni parte dall identificazione di depositi di energia nei calorimetri EM (fatto tramite algoritmi di clustering). La separazione tra elettroni e fotoni è basata sul matching tra tracce (traker) e cluster (calorimetro). Per avere una separazione rapida a livello di trigger è possibile utilizzare un set ridotto di informazioni. Ad esempio CMS sfrutta il matching con i primi layer del tracker per separare elettroni e fotoni. Gli elettroni lasciano tracce del loro passaggio nel rivelatore di tracce e depositi di energia (spesso molto grandi) nel calorimetro elettromagnetico (EM). I fotoni, come gli elettroni, rilasciano un deposito di energia nel calorimetro elettromagnetico (EM), ma poiché i fotoni sono particelle neutre non generano nessuna traccia nel rivelatore di tracce. Il livello 3 utilizza la piena informazione da tutto CMS. La strategia esposta può essere etichettata come Reconstruction on demand : viene raffinata la ricostruzione degli oggetti solo se necessario e quando il livello di ricostruzione precedente non ha già rigettato l evento. Un altro perno su cui si basa l analisi dell HLT è la Partial Reconstruction : la ricostruzione delle tracce nel tracciatore e nelle camere a muoni o dei cluster nei calorimetri avviene solo in limitate regioni del rivelatore, come ad esempio quelle in cui è indicata la presenza di particelle importate dal Trigger di primo livello. Tutto questo garantisce un elevato risparmio di CPU, ma può portare in alcuni casi alla perdita di eventi contenenti oggetti interessanti sfuggiti all L1-Trigger. Gli eventi così ricostruiti vengono inviati attraverso la rete locale al centro di calcolo del CERN, che provvede a salvarli temporaneamente su disco e creare una base di dati di riferimento (basata sul gestore di database ORACLE) per la successiva ricerca. L immagazzinamento definitivo delle informazioni (circa 3 TB di dati prodotti durante una giornata) viene effettuato su nastri di 120 GB l uno (nella figura 3 è schematizzata l intera catena di presa dati ). 12

13 6 Conclusione L ultimo livello di trigger normalmente agisce sull evento completo ed oltre ad eliminare eventi che non soddisfano le richieste di nessuno dei trigger può suddividere gli eventi accettati nei vari canali di fisica sotto studio. Il risultato di quest ultimo filtro permette di immagazzinare i dati su disco o nastro etichettati quali candidati di un particolare canale. A questo punto intervengono anche dei programmi di monitoraggio on-line che sia controllano il corretto funzionamento dei vari pezzi dell apparato, sia forniscono un display degli eventi candidati dei vari canali di fisica sotto studio (per un sottoinsieme di eventi). Inoltre un sottoinsieme di eventi è anche usato per calibrare o controllare la calibrazione dell apparato. Naturalmente non c è una chiara divisione fra il DAQ ed i trigger di livelli elevati. Quello che possiamo dire è che mentre i trigger sono (almeno i livelli più bassi) hardware, l acquisizione dati è essenzialmente un processo software. L acquisizione dati è nota come il processo di raccogliere e calibrare i dati rozzi provenienti dai vari pezzi dell apparato ed immagazzinarli per una successiva analisi offline. I dati rozzi vengono riuniti in parti logiche, chiamate eventi, che corrispondono ad una stessa interazione. Anche se una grossolana ricostruzione in osservabili fisiche può essere fatta dalla DAQ, spesso la ricostruzione degli eventi in osservabili quali impulso, energia, massa, tempo, ecc. è il compito principale dei programmi di ricostruzione offline[8]. Nel contesto di CMS il termine Trigger and Data AcQuisition (TDAQ) fa riferimento al sistema appena descritto. Oltre ai componenti hardware, il sistema di TDAQ comprende anche una serie di sistemi software, realizzati con lo scopo di fornire le funzionalità necessarie alla realizzazione di un sistema di monitoraggio: L attività di supervisione include tutte le operazioni di controllo che si occupano di verificare costantemente la messa a punto del sistema nelle sue varie componenti, segnalando eventuali malfunzionamenti o inconsistenze nel tempo più breve possibile, così da poter immediatamente provvedere alla correzione del difetto. Un monitoraggio veloce ed efficiente risulta quindi essenziale nel periodo di acquisizione, quando la qualità dei dati inviati alla memoria di massa deve essere costantemente sottoposta a controllo[4]. Col termine sistema di monitoraggio si intende quindi un insieme di applicazioni software dedicate alla supervisione sia della qualità dei dati provenienti dal rivelatore, sia dello stato dell hardware e del software dell esperimento. Il monitoraggio 13

14 dei dati in uscita può essere effettuato in due modalità distinte: offline e online: il monitoraggio offline viene effettuato sui soli eventi memorizzati in memoria permanente, mentre quello online viene effettuato analizzando un campione degli eventi in uscita dal rivelatore immediatamente dopo la sua produzione. Questa supervisione in tempo reale quindi risulta essere utile non tanto per la rivelazione di particelle sconosciute, quanto per effettuare gli opportuni controlli di calibrazione e di corretto funzionamento dei componenti di cui è costituito il rivelatore. Il sistema di supervisione si basa sull architettura fornita dal framework ROOT[7], una struttura di supporto che offre un insieme di strumenti utili per la formattazione dei dati ricevuti in un formato comune tra i diversi software dedicati al monitoraggio. References [1] The TriDAS Project - Technical Design Report, Volume 2: Data Acquisition and High-Level Trigger - disponibile al seguente indirizzo: cms/tdr/daq/daq.html [2] The CMS Event Builder - Computing in High-Energy and Nuclear Physics, La Jolla CA USA, March 24-28, 2003 [3] Generic DAQ pictures - disponibile al seguente indirizzo: ch/cms/tdr/daq/tdrweb/daqgenericjpg.htm [4] Data acquisition software for the CMS strip tracker - International Conference on Computing in High Energy and Nuclear Physics (CHEP.07) disponibile al seguente indirizzo: jpconf8_119_ pdf [5] Dott. Giovanni Polese et Prof. Crisostomo Sciacca - Progettazione e sviluppo di un sistema d acquisizione dati per il controllo e il monitoring dell apparato sperimentale per il trigger dei muoni di CMS. Università degli Studi di Napoli Federico II - Anno Accademico 2004/05 [6] Corso di Fisica protone-protone a LHC: Dr.ssa Anna Colaleo - Trigger and DAQ. Disponibile al seguente indirizzo: org/didattica/fisica/fisica_pp_lhc/. [7] ROOT - An Object Oriented Framework For Large Scale Data Analysis: http: //root.cern.ch/ 14

15 [8] La seguente relazione è disponibile al seguente indirizzo: altervista.org/didattica/fisica/fisica_pp_lhc/protone_lhc.php. Updated 27 Dicembre