3.1 La visualizzazione del rivelatore e degli eventi

Transcript

1 Chapter 3 La Visualizzazione 3.1 La visualizzazione del rivelatore e degli eventi L Event Display Gli esperimenti di fisica delle alte energie investigano le reazioni tra le particelle elementari che collidono in un acceleratore. Per questo scopo i segnali delle particelle prodotte vengono registrati in grandi rivelatori e immagazzinati in forma digitale. L insieme di dati registrati per collisione prende il nome di evento. Per ogni evento i rivelatori dell apparato sperimentale registrano le traiettorie (tracce) percorse dalle particelle cariche come una sequenza di punti, denominati hit, o registrano sciami (shower) di particelle come energia depositata in un insieme di celle [?]. Gli eventi sono le unità basilari per ogni ulteriore elaborazione, che generalmente vien fatta dai programmi di analisi. I primi rivelatori di particelle registravano i dati direttamente sotto forma di tracce su pellicole fotografiche, attraverso le quali si sono sviluppati metodi di indagine. Con il passaggio ai rivelatori elettronici i fisici hanno continuato ad avere l esigenza di visualizzare le tracce, così hanno sviluppato il software di visualizzazione, l event display. La memorizzazione dei dati in formato digitale, l uso di software per la visualizzazione dell evento, ha permesso delle applicazioni ulteriori rispetto alla semplice rappresentazione fotografica dell evento consentendo all utente di scegliere come dovrebbero essere rappresentati i dati. Con opportune forme, curve e colori vengono rappresentare le traiettorie delle particelle, il tipo, la loro energia e molte altre proprietà. Ad esempio, per dare un idea di distribuzione di energia tra particelle, un programma può assegnare lo stesso colore alle traiettorie di particelle che 34

2 cadono all interno di un certo intervallo di energia. Puntando ad un oggetto si possono ricavare le informazioni specifiche di quell oggetto. Una caratteristica molto importante è la possibilità di rappresentare un evento in due o tre dimensioni (2D o 3D); l utente può selezionare la prospettiva che più gli conviene o che meglio gli rappresenta le informazioni cercate. Negli ultimi anni si è visto che i programmi di event display hanno aiutato molto la comunità dei fisici a identificare e risolvere problemi nelle componenti del rivelatore. Durante i run iniziali del rivelatore, i programmi occasionalmente producono immagini che mostrano l inconsistenza tra i dati e le leggi fisiche. Queste inconsistenze possono sorgere a causa di un malfunzionamento in una parte del rivelatore, nel sistema di acquisizione dei dati o nel software di analisi dei dati. I rivelatori, come tutti i meccanismi complessi sono inclini a problemi, e spesso alcune regioni del rivelatore possono fallire ripetutamente. Saperlo è importante per una accurata analisi dei dati. L event display serve anche come strumento per scoprire indizi di nuova fisica, permette ai fisici di fare ipotesi sulla natura dell evento e di trovare correlazioni tra traiettorie ed energie depositate sui calorimetri. Per un esperimento come CMS, in cui i rivelatori risultano molto complessi, come ad esempio il sistema di tracciamento, è necessaria una rappresentazione grafica dell apparato che permetta in modo semplice di guardare sezioni sempre più piccole dell apparato, fino al limite del singolo modulo, con dettagli via via crescenti, fino al limite del singolo canale di lettura. Lo strumento di rappresentazione grafica deve essere in grado di mostrare anche le caratteristiche dell evento dopo la ricostruzione, dal livello del singolo hit nel modulo fino alla rappresentazione delle tracce e dei vertici primari e secondari La visualizzazione di altri tipi di informazione Gli eventi non sono i soli tipi di dati collegati agli apparati sperimentali che hanno bisogno di essere visualizzati. Un apparato sperimentale della fisica delle alte energie genera, durante la sua vita, che può essere anche di decine di anni, altri dati che vanno elaborati e visualizzati per controllare il suo corretto funzionamento. Nella fase iniziale di costruzione ed in quella successiva alla installazione del rivelatore nell area sperimentale (commissioning), ogni parte del rivelatore deve essere controllata e i dati relativi ai test devono essere memorizzati. Nella fase di normale funzionamento (running) il rivelatore richiede delle operazioni periodiche di manutenzione (per es. calibrazioni) e un monitoraggio continuo per evidenziare malfunzionamenti. Tutte queste operazioni generano quantità enormi di dati che ormai sono gestiti da sistemi di controllo con l aiuto di database: database di costruzione 35

3 e di gestione (collegato al DCS). Ma i soli sistemi di controllo non sono sufficienti a gestire l apparato, l impossibilità del programma di prevedere tutte le condizioni di malfunzionamento, comporta che l operatore deve essere informato costantemente delle condizioni dell apparato in modo da poter intervenire in caso di necessità. Per esempio, come si è visto nel capitolo 1, il sistema di tracciamento è un sistema dotato di un grandissimo numero di canali di lettura, per cui saranno necessari degli strumenti e dei metodi per sintetizzarli e mostrarli in modo che il funzionamento dell intero apparato possa essere monitorato in modo semplice mentre, un eventuale comportamento anomalo non rilevabile in maniera automatica, possa essere messo in evidenza. Inoltre sebbene il tracciatore sia solo una parte di CMS, alla sua realizzazione e alla sua manutenzione lavorano e lavoreranno centinaia di persone per una decina di anni. Sono necessari strumenti di visualizzazione che siano accessibili e comprensibili a tutti. 3.2 La visualizzazione nell ambiente LHC L ambiente di LHC impone nuove richieste nell ambito della visualizzazione. I dati relativi all evento e i rivelatori risultano essere molto più complessi dei precedenti esperimenti di fisica delle alte energie: il numero dei canali di lettura aumenta di uno o due ordini di grandezza, gli eventi di interesse sono estremamente rari ( solo in un evento su si può osservare un decadimento del bosone di Higgs). Questo comporta immagini dei rivelatori e degli eventi molto complesse e che possono a volte essere incomprensibili; le rappresentazioni convenzionali possono non essere sufficienti e chiare. La visualizzazione di altri tipi di informazione che in passato si poteva fare solo con istogrammi e simili rappresentazioni statistiche, al momento attuale, dato l enorme numero di canali richiede nuovi modi di rappresentare e soprattutto condensare l informazione, in modo che rimanga a un livello maneggiabile da parte del singolo operatore. Ad esempio il monitoraggio dei 70 milioni di canali del tracciatore richiede almeno istogrammi: uno per modulo. È fuori discussione che un operatore li possa guardare tutti. Ma è possibile condensare la loro informazione in una mappa dove ogni singolo modulo è rappresentato da un gruppo di pixel colorati a seconda dei risultati dell istogramma. Una singola immagine di pixel può così rappresentare tutti i canali in maniera condensata ed essere analizzata in maniera quasi istantanea dall operatore che può rilevare cambiamenti nel comportamento del rivelatore. Pertanto si cerca di sviluppare software di visualizzazione che da un 36

4 lato si integrano nel toolkit di analisi dell esperimento e dall altro propongono nuove rappresentazioni visuali che possono migliorare la capacità di percezione dell uomo. CMS, quale esperimento LHC, per affrontare le problematiche su esposte, ha scelto di sviluppare un pacchetto software di grafica in 3D denominato IGUANA [?] (Interactive Graphical User ANAlysis) che mira a fornire una infrastruttura software e gli stumenti per le applicazioni di grafica interattiva, in particolare per: una presentazione e analisi interattiva dei dati; una visualizzazione interattiva dell evento e del rivelatore; un interfaccia grafica per l utente (GUI), da usare in molti campi, come per il software offline di ricostruzione e simulazione, per l analisi dei dati, e in ambiente di test beam. Il mio lavoro di tesi rientra in questo progetto, e consiste nello sviluppo e nell implementazione in IGUANA di nuovi strumenti di visualizzazione per il sistema di tracciamento. Prima di inquadrare il problema della visualizzazione del Tracker si farà nel prossimo paragrafo una introduzione su IGUANA e sul suo utilizzo. 3.3 Il software di visualizzazione di CMS IGUANA è un progetto atto a fornire un framework di visualizzazione basato su plug-in 1 e una serie di toolkit per la grafica interattiva in 2D e 3D, con particolare riguardo verso l event display e la visualizzazione interattiva della simulazione del rivelatore. Il software di IGUANA non si presenta come un programma monolitico, piuttosto come un toolkit modulare in C++. Gli sviluppatori scelgono dal toolkit solo quelle parti che sono rilevanti per il loro caso specifico. A tal fine IGUANA prevede l uso di un numero consistente di pacchetti software (Figura 3.1) già esistenti: pacchetti e librerie di grafica in 2D e 3D commerciali e non (Qt[?], SoQt[?], OpenInventor[?], OpenGL[?],...), stumenti di analisi di dati, come AIDA (Abstract Interface for Data Analysis). Il progetto IGUANA è parte integrante del software offline di CMS (CO- BRA, GEANT, OSCAR, ORCA), pertanto le scelte tecnologiche e di design 1 Questo termine si riferisce ad un tipo di programma che si integra saldamente ad una applicazione più grande per fornire a quest ultima speciali capacità. 37

5 Figure 3.1: I pacchetti software di IGUANA. son fatte in concomitanza con gli altri gruppi software per avere una mutua compatibilità. Il codice è scritto in C++ ed è supportato da Linux e Solaris. Attualmente IGUANA è principalmente sviluppato tenendo conto delle necessità dell esperimento CMS, ma risulta indipendente da esso, nel senso che può essere usato anche da altri esperimenti. Nel progetto software di IGUANA l interfaccia grafica utenti è basata sul paradigma Modello Vista Controllo (Model View Controller) 2 [?], in cui la visualizzazione è divisa in tre parti indipendenti che descriviamo a seguito. Il modello Il modello è formato dai dati sottostanti da visualizzare: questo comporta la necessità di leggere e visualizzare la geometria del rivelatore di CMS; 2 Il paradigma MVC è stato introdotto da Trygve Reenskaug in Smalltalk (uno dei primi linguaggi ad oggetto) nella prima metà degli anni 80. Da allora viene usato come base per lo sviluppo di interfacce grafiche utente (GUI). 38

6 i dati transienti e persistenti attraverso COBRA, quindi i dati simulati e quelli successivamente ricostruiti da ORCA, in particolare gli hit simulati (SimHit) e ricostruiti (RecHit), e le tracce simulate (SimTrack) e ricostruite (RecTrack). La vista La vista è la rappresentazione dei dati sullo schermo. IGUANA offre una rappresentazione in 3D ed una in 2D. In particolare usa le librerie X11 e OpenGL per un basso livello di grafica rispettivamente in 2D e 3D; Qt e OpenInventor per un alto livello di grafica in 2D e 3D. Il modello su cui si basa lo sviluppo di applicazioni 3D in OpenInventor è quello di creare una scena grafica mettendo insieme una serie di nodi. Un nodo può rappresentare una forma, un attributo, una trasformazione e altro. Ogni modifica alla scena grafica in memoria comporta un immediata variazione dell immagine sullo schermo del computer. Una volta che i nodi sono stati raggruppati in una struttura gerarchica per formare una o più scene, è possibile applicare azioni come ad esempio la selezione (picking) sia al singolo nodo che a intere scene. Una vista 2D si ottiene da una normale vista 3D con operazioni di proiezione e tagli. Con il mio lavoro di tesi è iniziato lo sviluppo di una diversa visualizzazione in 2D. Dall altra parte IGUANA contiene come parte integrante il pacchetto Qt che permette una grafica 2D ad alto livello. Questo pacchetto viene usato al momento attuale come sistema di gestione delle finestre e dell interazione con l utente. La gestione di questa interazione è fatta col sistema slot/segnale. Ogni oggetto può rispondere ad azioni dell utente attraverso slot pubbliche, cioè particolari metodi che possono essere eseguiti ogni qualvolta un altro oggetto emette un segnale connesso a quella slot. Così quando l utente ad esempio preme un tasto clear il segnale buttonpressed può essere collegato ad una slot di un altro oggetto grafico che provvede a ripulire la finestra. Le possibilità grafiche 2D di Qt sono state usate per costruire i prototipi che son serviti per realizzare gli oggetti grafici proposti in questo lavoro di tesi. Il controllo Il controllo si riferisce alle interazioni tra l utente e le prime due parti (modello e vista). Il controllo interattivo della vista include per esempio le seguenti operazioni: le rotazioni intorno agli assi, gli zoom, le traslazioni nel piano dello schermo ed altre ancora. Invece il controllo del modello prevede le 39

7 possibilità di saltare da un evento all altro e di controllare la visibilità di parti dell evento e del rivelatore Applicazioni del software di visualizzazione Il progetto software IGUANA viene utilizzato per la visualizzazione dei rivelatori di CMS, ed in particolare: per una verifica della geometria di simulazione e ricostruzione, cioè la visualizzazione del database di descrizione del rivelatore (DDD); per il display degli eventi anche in ambiente di test beam; per il monitoraggio durante la fase di costruzione; per la verifica del corretto funzionamento del rivelatore durante la fase di installazione e di commissioning. Gli sviluppatori del software di IGUANA hanno realizzato due plug-in uno per il programma di simulazione (OSCAR) ed uno per il programma di ricostruzione ed analisi (ORCA) le cui interfacce utente sono illustrate rispettivamente nelle Figure 3.2 e 3.3 e servono per fornire un programma di display per i dati di simulazione e ricostruzione di CMS in ORCA e per il controllo della descrizione del rivelatore in OSCAR. In entrambi i casi il rivelatore o gli eventi sono visualizzati come scena di OpenInventor (finestra a sinistra). Un albero di controllo della scena permette di selezionare le parti da visualizzare ed infine una finestra, in basso a destra, permette di visualizzare le informazioni dell oggetto selezionato [?]. All inizio la finestra 3D di OpenInventor è vuota, solo in seguito ad una selezione nell albero di controllo apparirà nella finestra 3D l oggetto selezionato. In OSCAR, il progetto IGUANA attualmente permette di visualizzare la descrizione del rivelatore in termini di geometria e di materiali. Si tratta di una completa descrizione che include oltre agli elementi sensibili anche il sistema di supporto, tensione, gas, calibrazione, cavi... Infatti in Figura 3.2 si può notare che l albero include tutti gli elementi che costituiscono una ruota del barrel del calorimetro elettromagnetico. La finestra delle informazioni è stata omessa proprio per rendere l idea del livello di dettagli che si possono avere nell albero di OSCAR. In ORCA invece oltre alle parti sensibili del rivelatore si possono visualizzare, con IGUANA, anche gli eventi simulati e ricostruiti con particolare riguardo agli hit e alle tracce. I dati degli eventi simulati e ricostruiti sono richiesti a COBRA che a seconda dei casi provvede ad accedere al database 40

8 Figure 3.2: La visualizzazione in OSCAR utilizzando IGUANA. Le due frecce indicano da un lato la voce selezionata all interno dell albero di controllo della scena, dall altro una parte della ruota del barrel del calorimetro elettromagnetico visualizzata nella finestra di OpenInventor. ad oggetti Objectivity che li contiene o a calcolarseli su richiesta. Nessun processo è eseguito per un oggetto finchè l utente non ha richiesto di vederlo sullo schermo. Non appena vien fatta una richiesta, viene effettuato l accesso ai dati e/o vengono eseguiti i calcoli. In Figura 3.3 è messa in evidenza una delle tante funzioni permesse con IGUANA, quella ad esempio di fare lo zoom delle parti interessanti. La zona del rivelatore che è stata ingrandita è visualizzabile in un altra finestra di OpenInventor. 3.4 La visualizzazione del Tracker All interno di ORCA il Tracker viene descritto come una scena OpenInventor consistente di scatole ognuna delle quali corrisponde ad un singolo sensore. La Figura 3.4 illustra l intero Tracker, ottenuto selezionando nella finestra dell albero di controllo, sotto il ramo Detector, le voci relative Pixels e Silicon sia per il barrel che per l endcap. Attualmente non è possibile selezionare solo un cilindro o un anello del 41

9 Figure 3.3: La visualizzazione in ORCA utilizzando IGUANA. La finestra in alto a sinistra è una ulteriore finestra OpenInventor in cui è stato fatto lo zoom della parte interna del rivelatore mostrato nella figura iniziale in basso a sinistra. barrel o un disco del forward (cioè l endcap); si può selezionare separatamente solo la parte barrel o la parte forward. La stessa cosa vale per le voci relative agli hit simulati, ovvero ai SimHit sotto il ramo Event. Se si seleziona la voce SimHit compaiono gli hit dell intero rivelatore senza poterli selezionare per le singole parti (disco, anello, cilindro e modulo). La Figura 3.5 mostra una rappresentazione in 3D di un evento simulato. Il segnale simulato è rappresentato nel rivelatore da un insieme di punti nello spazio. L evento in questione è pp -> H -> eeµµ senza pile-up. La figura mostra le tracce simulate con momento trasverso maggiore di 3 GeV, il che spiega la presenza di poche tracce simulate rispetto agli hit simulati. Nella Figura 3.6 si mostra lo stesso evento in presenza del primo strato del TIB. Questa figura non si può ottenere al momento con IGUANA per quanto detto prima, ma è stata fatta con uno dei prototipi che son serviti per la realizzazione degli oggetti grafici come verrà specificato nel capitolo 42

10 Figure 3.4: Esempio che mostra una visione dell intero Tracker di CMS. successivo. Lo scopo di mostrare una figura di questo tipo è quello di mettere in evidenza che cercare di rappresentare tracce, hit e rivelatore in modo da capire per quali hit passa una traccia, o a quale modulo essi appartengono è particolarmente difficile in 3D anche in presenza di un solo layer; per individuare una corrispondenza hit-traccia-modulo è indispensabile aver la possibilità di visualizzare il singolo modulo. In passato per trovare la corrispondenza hit-traccia si era soliti rappresentare i dati in 2D utilizzando le coordinate x,y,z con relative proiezioni. Le rappresentazioni in Figura 3.7 mostrano l evento rispettivamente nel piano y-x, in cui sono presenti solo gli hit del barrel, e nel piano y-z. Ma anche in questo caso l identificazione può risultare confusa, manca la possibilità di distinguere gli hit delle singole parti o di selezionare solo una parte di hit. In passato una rappresentazione alternativa particolarmente utile a questo scopo e non presente attualmente in IGUANA era quella che utilizzava le coordinate polari ρ, θ e φ. Queste permettono rappresentazioni come il V-Plot [?] inventato da Hans Drevermann che permette di riconoscere le tracce o un cluster di tracce, ovvero di stabilire se degli hit formano o no una traccia, e di conseguenza scartare quegli hit che non appartengono ad una parte interessante dell evento. 43

11 Figure 3.5: Rappresentazione in 3D dell evento simulato pp -> H -> eeµµ in assenza di pile-up. Quindi il software di visualizzazione sotto ORCA ha al momento le seguenti limitazioni: è impossibile selezionare un solo strato o anello, un singolo modulo, hit o tracce relativi ad una parte del rivelatore; manca una rappresentazione in θ/φ e in ρ/z dei dati; il tempo per processare ogni singolo evento è molto lungo; la visualizzazione di tutti i moduli rallenta il programma, la descrizione del rivelatore richiede molte risorse (80 MB di memoria centrale), questo significa che introdurre altri dettagli nella descrizione in 3D rallenterebbe ulteriormente il programma. D altra parte semplificare la rappresentazione 3D usando per esempio cilindri non ci permetterebbe più di effettuare un controllo accurato delle posizioni. 44

12 Figure 3.6: Rappresentazione in 3D dello stesso evento di Figura 3.5 in presenza del primo cilindro del TIB, ottenuta con un prototipo messo a punto durante il lavoro di questa tesi. Allo scopo di superare le suddette limitazioni ho realizzato degli oggetti grafici in 2D che servono per: poter selezionare ogni singola componente del rivelatore (anello, disco, modulo,...); poter selezionare i soli hit delle componenti del rivelatore selezionate; realizzare una rappresentazione in θ/φ dei dati. Nel prossimo capitolo parleremo del loro sviluppo. 45

13 Figure 3.7: Proiezioni nel piano y-x e y-z dell evento simulato. 46