Un sistema di visualizzazione On-Line dei dati acquisiti ... · ed elaborare in tempo reale una...

Alma Mater Studiorum · Universita di Bologna

FACOLTA DI SCIENZE MATEMATICHE, FISICHE E NATURALI

Corso di Laurea Triennale in Informatica

Un sistema di visualizzazione On-Line

dei dati acquisiti con l’esperimento

NEMO

Relatore:Prof. Maurizio Spurio

Correlatore:Dr. Tommaso Chiarusi

Tesi di laurea di:Alessio Riccardo

Sessione IIAnno Accademico 2008/2009

Alla mia famiglia.

Indice

1 Introduzione 1

1.1 Astrofisica con Neutrini . . . . . . . . . . . . . . . . . . . . . 2

1.2 Sorgenti astrofisiche di neutrini . . . . . . . . . . . . . . . . . 4

1.3 Telescopi di neutrini . . . . . . . . . . . . . . . . . . . . . . . 6

2 Il telescopio sottomarino NEMO 11

2.1 Struttura del rilevatore . . . . . . . . . . . . . . . . . . . . . . 12

2.2 Il progetto NEMO fase 1 e 2 . . . . . . . . . . . . . . . . . . . 13

2.3 Il sistema di acquisizione dati per NEMO fase-2 . . . . . . . . 14

3 Tecnologie utilizzate 21

3.1 Linguaggio C++ . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.2 La libreria Qt . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.3 Il framework ROOT . . . . . . . . . . . . . . . . . . . . . . . 23

3.4 Il dispatcher ControlHost . . . . . . . . . . . . . . . . . . . . . 24

3.5 XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4 Software Event Display 29

4.1 Introduzione al funzionamento . . . . . . . . . . . . . . . . . . 29

4.2 Utilizzo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.2.1 Event Display in modalita Online . . . . . . . . . . . . 30

4.2.2 PlotGraph in dettaglio . . . . . . . . . . . . . . . . . . 33

4.2.3 GraphStat in dettaglio . . . . . . . . . . . . . . . . . . 34

4.2.4 Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . 37

i

ii INDICE

4.2.5 Plot . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

5 Architettura 41

5.1 HitPlotting . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5.2 Statistiche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

5.3 Connection Settings . . . . . . . . . . . . . . . . . . . . . . . . 51

5.4 Preparazione e compilazione del software . . . . . . . . . . . . 51

A Strutture dati 55

Bibliografia 61

Elenco delle figure

1.1 Illustrazione artistica di un Microquasar . . . . . . . . . . . . 5

1.2 Gamma Ray Burst . . . . . . . . . . . . . . . . . . . . . . . . 6

2.1 Rappresentazione schematica del telescopio NEMO. . . . . . . 13

2.2 Rappresentazione di come funziona un PMT. . . . . . . . . . . 16

2.3 Schema delle macchine usate dal sistema di acquisizione dati. . 18

2.4 Sistema di Trigger. . . . . . . . . . . . . . . . . . . . . . . . . 19

3.1 File XML per configurazione di PlotOn . . . . . . . . . . . . . 26

4.1 Pannello Visualizer. . . . . . . . . . . . . . . . . . . . . . . . . 31

4.2 Pannello PlotOn. . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.3 Esempio di PlotGraph. . . . . . . . . . . . . . . . . . . . . . . 34

4.4 Hits Graph. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.5 ADC Graph. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.6 Wave Form Graph. . . . . . . . . . . . . . . . . . . . . . . . . 36

4.7 Pannello Statistics. . . . . . . . . . . . . . . . . . . . . . . . . 37

4.8 Pannello Plot. . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5.1 Diagramma delle classi dell’Eevent Display. . . . . . . . . . . . 42

5.2 Classi per il plotting. . . . . . . . . . . . . . . . . . . . . . . . 44

5.3 Esempio di funzionamento di Go To. . . . . . . . . . . . . . . 45

5.4 Esempio di funzionamento di Forward. . . . . . . . . . . . . . . 46

5.5 Classi per le statistiche. . . . . . . . . . . . . . . . . . . . . . 49

iii

iv ELENCO DELLE FIGURE

A.1 Struttura del file PostTrigger. . . . . . . . . . . . . . . . . . . 60

Capitolo 1

Introduzione

In questa tesi si presenta lo sviluppo di un software per il monitoraggio

dei dati acquisiti dall’esperimento NEMO.

NEMO (NEutrino Mediterranean Observatory) e un progetto dell’Isti-

tuto Nazionale di Fisica Nucleare per la definizione delle tecniche necessarie

alla costruzione di un telescopio di neutrini delle dimensioni di 1 km3 nelle

profondita abissali del Mar Mediterraneo. La rivelazione di neutrini astrofisi-

ci estendera le conoscenze dell’Universo in modo complementare all’Astrono-

mia tradizionale che si basa sull’osservazione del Cosmo tramite la radiazione

elettromagnetica. Un esperimento di tale novita si inserisce percio in un con-

testo di frontiera della ricerca. Alla fine del 2006, dopo circa otto anni di

intensa attivita di ricerca e sviluppo, la Collaborazione NEMO ha depositato

e messo in opera al largo di Catania, in Sicilia, un prototipo in scala ridotta

dell’elemento chiave del telescopio, la Torre di fotomoltiplicatori. Entro la

meta del 2009, una Torre completa nella configurazione finale per il km3 sara

posizionata e messa in funzione in un secondo sito abi ssale al largo di Capo

Passero, sempre in Sicilia. La realizzazione del sistema per l’acquisizione dei

dati (Data AcQuisition DAQ) di tale Torre e attualmente in corso d’opera.

Tale sistema di DAQ e assai complesso: presenta a mare un apparato hard-

ware costituito da numerosi fotomoltiplicatori che spedisce a terra un elevato

e continuo flusso di dati. Tale flusso dati viene raccolto ed analizzato da una

1

2 Capitolo 1. Introduzione

batteria di computer che, grazie ad un apposito software, dovra selezionare

ed elaborare in tempo reale una mole di dati dell’ordine delle decine di TB

al giorno.

Nel primo capitolo della tesi vengono introdotte le ragioni scientifiche per

lo studio dei neutrini astrofisici, discutendo la loro origine ed il ruolo chiave

che essi hanno nell’Astrofisica delle Alte energie. Il secondo capitolo descrive

l’esperimento NEMO, la struttura del telescopio sottomarino, le fasi di pro-

totipazione svolte e il sistema di acquisizione dati. Nel terzo capitolo vengono

presentate le tecnologie utilizzate. Il quarto capitolo espone il software, il suo

ruolo all’interno del sistema di DAQ, la sua interfaccia e il suo funzionamento;

mentre nel quinto e trattata la descrizione completa dello sviluppo dell’Event

Display, l’architettura del software e le classi che lo compongono.

1.1 Astrofisica con Neutrini

L’Astrofisica con i neutrini rappresenta un campo di ricerca di frontiera

per espandere la nostra conoscenza dell’Universo, basata attualmente sul-

l’osservazione del Cosmo utilizzando come vettori di informazione la radi-

azione elettromagnetica (e.m) ed i Raggi Cosmici (RC). I fotoni (dalle onde

radio ai raggi gamma) rappresentano tradizionalmente la sonda piu utiliz-

zata in Astronomia. I fotoni conservano generalmente la loro direzione di

provenienza, ed e pertanto possibile studiare in modo diretto le sorgenti che

li hanno generati. Infatti, essendo elettricamente neutra, la radiazione e.m.

non subisce deflessioni da parte dei campi magnetici presenti nello spazio in-

terstellare o intergalattico. Tuttavia, i fotoni di energia E > 100 TeV (raggi

gamma) non possono attraversare distanze maggiori di 10 Mpc perche sono

assorbiti nell’interazione con la radiazione di fondo dell’Universo. Questo pre-

clude il loro uso nello studio di fenomeni altamente energetici che avvengono

all’in terno di sorgenti astrofisiche compatte a distanze cosmologiche.

I raggi Cosmici sono un flusso costante di particelle di origine extrasolare

con uno spetro molto ampio di energia; i RC sono composti per la maggior

1.1 Astrofisica con Neutrini 3

parte da protoni e nuclei di elio, da una piccola frazione di nuclei pesanti

e da elettroni. La loro origine e molto varia: sono sintetizzati nelle stelle

ed espulsi da queste tramite il vento solare, in fenomeni energetici come le

esposioni delle supernovae, ed in oggetti remoti come Quasar ed altri Nuclei

Galattici Attivi (AGN). Poiche le tipologie e lo stato energetico di tali par-

ticelle riflettono le caratteristiche delle loro sorgenti, i RC sono utilizzati per

inferire, in modo complementare all’Astronomia tradizionale, dati sui proces-

si di base che costituiscono gli oggetti celesti. D’altra parte, i raggi cosmici

che giungono sulla Terra, essendo particelle cariche, hanno perso la direzione

di partenza a causa dei campi magnetici galattici o extra-galattici che hanno

deviato le loro traiettorie, e non puntano piu alla loro sorgente di origine. In-

oltre anche per i RC di altissima energia e previsto un limite di propagazione

simile a quello gia discusso per i raggi gamma: tali RC, prodotti solamente

nei fenomeni piu violenti del cosmo, come gli AGN che si trovano ben lontani

dal gruppo locale cui appartiene la nostra Galassia, vengono fermati dalla

radiazione di fondo cosmica dopo circa 100 Mpc di cammino. Questo limite,

denominato limite GZK dai nomi dei fisici Ginzburg, Zatsepin e Kuzmin

che lo hanno teorizzato, definisce l’orizzonte dell’Universo entro cui possono

essere studiati i fenomeni tramite radiazione cosmica di altissima energia [1].

La necessita di superare tali orizzonti sta alla base dell’idea di utilizzare i

neutrini come una nuova sonda cosmica. I neutrini sono particelle elementari

con una massa estremamente piccola (stimata essere almeno 500 milla volte

piu piccola di quella dell’elettrone). L’uso dei neutrini dell’astrofisica presen-

ta diversi vantaggi. I neutrini non hanno carica elettrica, di conseguenza non

sono deflessi da campi elettrici o magnetici presenti ad esempio nei bracci a

spirale delle galassie, o nello spazio tra le galassie stesse, e la loro direzione di

arrivo sulla Terra punta direttamente alla sorgente di provenienza. Una loro

ulteriore caratteristica d’importanza primaria e data dal fatto che i neutrini

interagiscono solo tramite l’interazione debole, al contrario dei fotoni e dei

RC ordinari che possono interagire con la materia anche tramite la forza elet-

tromagnetica. Per questo motivo i neutrini possono cosı attraversare grandi

4 Capitolo 1. Introduzione

distanze, senza interagire con il mezzo inter stellare o intergalattico e senza

venirne assorbiti. In sostanza i neutrini astrofisici arrivano indisturbati di-

rettamente dal cuore delle proprie sorgenti, che in alcuni casi possono essere

gli oggetti astrofisici piu distanti e ancora sconosciuti.

1.2 Sorgenti astrofisiche di neutrini

Le sorgenti di neutrini astrofisici possono essere sia galattiche, come le

supernovae, i resti di supernovae ed i microquasar (rappresentato in Figura

1.1), che extragalattiche, come gli AGN ed i Gamma Ray Bursts (vedi Figura

1.2).

Le supernovae sono esplosioni di stelle causate dalla rottura dell’equilibrio

tra forza gravitazionale e la pressione di radiazione dovuta all’energia liberata

durante i processi di fusione dell’idrogeno e dell’elio. Durante le fasi che

precedono l’esplosione e prodotto un forte flusso di neutrini con energie di

alcuni MeV che potrebbero essere rivelati da rivelatori di neutrini. Qando

avviene l’esplosione, i materiali che formano gli strati esterni della stella sono

espulsi formando cosı una struttura nota come Relitto di Supernova(SNR,

SuperNova Remnant). I SNR sembrano essere le maggiori sorgenti galattiche

di raggi cosmici ad energie al di sotto di 1012eV e, secondo alcuni modelli

potrebbero quindi essere anche sorgenti di neutrini.

I microquasar sono sistemi binari costituiti da un oggetto compatto (stella

di neutroni o buco nero) e da una stella compagna che trasferisce materia

all’oggetto compatto. Essi presentano caratterisctiche simili al quasar come

emissioni radio forti e variabili e un disco di accrescimento che circonda

l’oggetto compatto. Alcuni microquasar presentano jet relativistici, dove

l’intrazione tra protoni fortemente accelerati al loro interno e fotoni darebbe

luogo a raggi gamma e a neutrini di alta energia. Il centro della nostra

Galassia, molto ricco di sorgenti di raggi gamma [2], sembra essere uno dei

siti favoriti dove e possibile supporre l’esistenza di microquasar e quindi di

neutrini astrofisici.

1.1 Astrofisica con Neutrini 5

Figura 1.1: Illustrazione artistica di un Microquasar

I Gamma Ray Bursts, sono i fenomeni piu violenti dell’Universo, in cui

viene liberato il maggior flusso di energia. I Gamma Ray Bursts sono intensi

lampi di raggi gamma della durata generalmente di pochi secondi; la loro

origine e ancora oggi fonte di discussione: su suppone che essi provengano

dall’ultimo stadio di coalescenza di un sistema binario di buchi neri compatti

o di un buco nero compatto e di una stella di neutroni con la conseguente for-

mazione di un oggetto di grande massa ed alta temperatura. Questo oggetto

e detto fireball e, secondo alcuni modelli, prevede la produzione di neutrini.

Gli AGN sono oggetti nei quali la produzione energetica avviene a spese di

un buco nero supermassivo centrale che si “nutre” del gas che gli cade dentro

dal nucleo della galassia madre o di galassie vicine interagenti. Fanno parte

della categoria degli AGN le Galassie di Seyfert, galassie a spirale con un nu-

cleo brillante di apparenza stellare o semistellare, le Radiogalassie, galassie

generalmente ellittiche con forte emissione nella banda radio, e Quasar, ogget-

ti astronomici estremamente luminosi che emettono la stessa quantita di ra-

6 Capitolo 1. Astrofisica con Neutrini

diazione in quasi tutto lo spettro elettromagnetico. Gli AGN hanno ricevuto

considerevole attenzione come possibili sorgenti di neutrini ad alta energia

perche il loro rilascio di energia elettromagnetica in tutte le lunghezze d’onda

eccede quello di ogni altro oggetto astronomico.

Figura 1.2: Gamma Ray Burst

1.3 Telescopi di neutrini

Un rilevatore di neutrini astrofisici e pensato per identificare oggetti ce-

lesti che sono anche sorgenti di neutrini; per tale ragione viene chiamato

telescopio di neutrini.

La costruzione di telescopi di neutrini pone diverse sfide. Innanzitutto

non e possibile condurre delle misure dirette dei neutrini a causa della loro

carica neutra. Tale misura viene effettuata tramite la rilevazione di particelle

secondarie generate dai neutrini di materia. Queste possono essere di vario

genere: leptoni o adroni. La particella piu facile da rilevare con un telescopio

di neutrini e un leptone detto muone, ovvero una particella elementare simile

ad un elettrone ma 200 volte piu massiva. Rispetto ad altri leptoni, come gli

elettroni o i tauoni, o agli adroni stessi, i muoni sono candidati piu appetibili

1.2 Telescopi di neutrini 7

in virtu della loro maggiore sopravvivenza nel mezzo di propagazione. Grazie

alla loro carica elettromagnetica, del tutto identica a quella di un elettrone,

i muoni con una velocita v superiore alla velocita della luce in un mezzo

diverso dal vuoto (c/n < v, con c la velocita della luce nel vuoto e n l’ind

ice di rifrazione del mezzo) emettono fotoni per un fenomeno detto effetto

Cherenkov (si noti che questo e vero per qualsiasi particella carica). Poiche

la radiazione Cherenkov, in un dato mezzo, e emessa sempre ad un certo

angolo, non e difficile ricavare delle relazioni geometriche particolari tra la

direzione del muone ed i tempi di arrivo dei fotoni Cherenkov raccolti da un

apposito apparato sperimentale. Nel caso dei telescopi di neutrini, tale appa-

rato consiste in una enorme griglia di fotomoltiplicatori (Photon MulTiplier,

PMT ).

I PMT sono rivelatori attivi (ovvero alimentati da una data potenza elet-

trica) che convertono il fotone incidente sulla propria superficie sensibile in un

elettrone. Tale elettrone e denominato foto-elettrone. All’interno del PMT,

il foto-elettrone viene convogliato in un apparato preposto alla generazione

di una cascata elettronica che amplifica il segnale elettrico: si passa cioe dal

singolo foto-elettrone originato dalla conversione del fotone Cherenkov in-

cidente sulla superficie del PMT, ad un vero e proprio impulso amplificato

di corrente elettrica contenente circa 108 elettroni secondari. Tale impulso

elettrico viene campionato da opportuni sistemi elettronici posti alla base dei

PMT e viene poi spedito verso il sistema di DAQ del telescopio.

La misura indiretta dei neutrini astrofisici consiste quindi nella rivelazione

dei fotoni Cherenkov emessi dalle loro particelle secondarie, generalmente

muoni, che incidono su una griglia tridimensionale di PMT. Oltre una certa

energia (100 GeV) la traiettoria dei muoni e praticamente la continuazione

di quella dei neutrini originali, e basta ricostruire la traiettoria di tali muoni

per risalire alla direzione di provenienza dei neutrini. Una prima ovvia con-

siderazione e che la trasparenza del mezzo in cui si trova il telescopio risulta

fondamentale per la propagazione dei fotoni Cherenkov. Inoltre, per quanto

gia accennato circa la caratteristica dei neutrini di interagire esclusivamente

8 Capitolo 1. Astrofisica con Neutrini

tramite la Forza Debole, per compensare sia la loro scarsa interazione con la

materia che gli esigui flussi di neutrini astrofisici di alta energia, e necessario

costruire rivelatori di grandi dimensioni. E stato calcolato che il volume ot-

timale entro cui disporre la grigli di PMT di un t elescopio di neutrini non

puo scendere sotto il km3 di estensione. Come conseguenza, per la ragione

economica di procurarsi ingenti quantita di mezzo trasparente, i telescopi

per neutrini sono collocati in siti marini (ANTARES, NESTOR, NEMO),

nei laghi (BAIKAL) o nel ghiaccio in Antartide (AMANDA o ICECUBE). A

queste considerazioni va aggiunto che l’ingente numero dei cosiddetti muoni

atmosferici, ovvero i muoni prodotti dall’impatto dei RC negli strati dell’at-

mosfera, rappresentano un fondo sovrastante il flusso dei muoni generati dai

neutrini astrofisici. Per questo motivo i telescopi di neutrini devono essere

collocati nelle profondita dei siti abissali marini o del permafrost dell’An-

tartide. In questo modo e possibile avvalersi di una sufficiente schermatura

naturale che riduce significativamente i muoni atmosferici.

A questo punto, occorre menzionare che il segnale Cherenkov indotto dai

muoni secondari e comunque trascurabile rispetto al bagno di fotoni solari

che si avrebbe posizionando il rilevatore a basse profondita. Al passagio di

un muone indotto da neutrino, i PMT colpiti dalla radiazione Cherenkov si

devono confrontare con non piu di qualche fotone per volta; la luce solare che

penetra le prime centinaia di metro sotto il levello del amre o nel permafrost e

invece ordini di grandezza piu intensa, ed PMT, calibrati per la rivelazione di

pochi fotoni, verrebbero danneggiati irreparabilmente. Ne segue che la scelta

di siti estremamente profondi, avvolti dal buio degli abissi, e una condizione

essenziale per la misura di fotoni Cherenkov (al di la delle ragioni esposte

per ridurre il fondo dei muoni atmosferici).

In mare, un’ulteriore giustificazione dei siti abissali per i telescopi di neu-

trini, deriva infine dalla necessita di ridurre il fondo ottico legato al decadi-

mento del 40K (presente in sali disciolti in acqua) e per annullare l’effetto

della bioluminescenza di particolari organismi marini. Sebbene oltre i 2500m

di profondita non e prevista alcuna bioluminescenza, nel mare non e possibile

1.2 Telescopi di neutrini 9

eliminare totalmente il fondo dei cosiddetti fotoni del 40K. Tuttavia i segnali

di tali fotoni sui PMT sono totalmente scorrelati l’uno dall’altro, e possono

essere eliminati ponendo delle condizioni di casualita tra i segnali registrati.

Tali condizioni devono essere invece soddisfate dai segnali generati dai fotoni

Cherenkov, essendo questi emessi in successione dal muone nel suo incedere

lungo la sua traiettoria.

La conversione dei neutrini astrofisici in muoni avviene tanto piu fre-

quentemente quanto piu e alta la densita del mezzo di propagazione dei neu-

trini, ovvero quando diventa piu probabile un’interazione neutrino-materia.

Sulla Terra questo accade quando i neutrini si propagano dentro la roccia.

Per questo un telescopio di neutrini, posto in mare o in un lago o sotto

i ghiacci dell’Antartide, ha come principale segnature di neutrini astrofisi-

ci quei muoni che provengono dal basso, ovvero che sono stati prodotti e

non assorbiti nella roccia sottostante il revelatore. Per questo motivo, un

telescopio di neutrini viene generalmente progettato con i PMT orientati in

modo da osservare prevalentemente la zona loro sottostante, divenendo cosı

sufficientemente cieco ai segnali provenienti dall’alto.

Capitolo 2

Il telescopio sottomarino

NEMO

NEMO (NEutrino Mediterranean Observatory) e un programma di ricer-

ca e sviluppo che ha come obiettivo lo studio della tecnologia necessaria per

la realizzazione di un telescopio sottomarino delle dimensioni di 1 km3 nel

Mar Mediterraneo. Dopo piu di venti campagne in mare condotte dalla Col-

laborazione NEMO fin dal 1998, e stato identificato il sito abissale ottimale:

esso si trova a circa 100 km al largo di Portopalo di Capo Passero, in Sicilia,

ad una profondita di circa 3500 metri. Tale sito offre caratteristiche eccel-

lenti per accogliere un telescopio di neutrini: le impurita dell’acqua come i

particolati in sospensione sono assai limitate, tanto da garantire un ridotto

assorbimento ed una bassa diffusione della luce Cherenkov (e stata misura-

ta una lunghezza di attenuazione Latt 70 m); gli effetti dei sedimenti o la

crescita di biofilm che possono oscurare i moduli ottici che ospitano i PMT

hanno effetti trascurabili stimati fino a oltre i 10 anni previsti per la presa

dati del telescopio; inoltre, sotto i 2500 metri di profondita non e aspettata

alcuna bioluminescenza e sul sito prescelto e stato misurato un bassissimo

fondo da 40K. Infine il sito scelto e posto non troppo lontano dalla costa

della Sicilia dove sono state realizzate apposite infrastrutture scientifiche che

accoglieranno il sistema di DAQ a terra ed il centro di controllo dell’esperi-

11

12 Capitolo 2. Il telescopio sottomarino NEMO

mento. Un’ultima caratteristica non secondaria di tale sito, essendo questo

nel Mar Mediterraneo, e rappresentata dalla sua collocazione nell’emisfero

Nord terrestre: tenendo conto che un telescopio di neutrini e ottimizzato per

la misura dei neutrini dal basso, il sito di NEMO si affaccia in modo priv-

ilegiato sul Centro Galattico, posto agli antipodi terrestri, da cui come gia

accennato, in correlazione alle molte sorgenti di raggi gamma scoperte, ci si

aspetta un significativo flusso di neutrini astrofisici. La realizzazione di un

telescopio di neutrini nel Mediterraneo trova un’ulteriore motivazione nella

costruzione di un simile strumento che la Collaborazione di ICECUBE sta

completando in questi anni agli antipodi terrestri, in Antartide. L’accoppi-

amento dei telescopi nei due emisferi terrestri garantira la totale copertura

del cielo.

2.1 Struttura del rilevatore

Secondo il progetto sviluppato dalla Collaborazione NEMO, il telescopio

e costituito da Torri semirigide (le strutture di supporto per i PMT) ancorate

sul fondale marino che si estendono per un’altezza di circa 700 metri grazie a

dei galleggianti posti sulla loro sommita. Ogni Torre e costituita da 16 piani

distanziati gli uni gli altri 40 metri. L’ultimo progetto della Torre prevede

che ogni piano sia formato da una trave lunga 12 metri con due PMT ad ogni

estremita (uno rivolto verso il basso e uno lungo la direzione orizzontale). I 16

piani sono mantenuti in trazione da quattro cavi di sospensione, due per ogni

lato, e ognuno e ruotato rispetto ai vicini di 90◦ lungo l’asse verticale della

Torre. Questa soluzione assicura un certo grado di rigidita e al contempo

limita i movimenti dei fotomoltiplicatori. E altresı possibile conoscere la

posizione dei singoli PMT utilizzando triangolazioni di segnali acustici che

vengono spediti e raccolti da opportuni apparecchi montati direttamente su

ciascun piano e su apposite basi collocate attorno al rivelatore. Su ogni piano,

oltre ai sensori ottici, sono poi disposti altri strumenti per la rivelazione

dell’effettiva posizione dei fotomoltiplicatori, come bussole ed inclinometri.

2.2 Il progetto NEMO fase 1 e 2 13

Figura 2.1: Rappresentazione schematica del telescopio NEMO.

L’intero telescopio consiste in una griglia di Torri spaziate l’un l’altra 130

metri. Sono stati valutati diversi progetti per la disposizione delle Torri nella

griglia, la piu accreditata e mostrata in Figura 2.1. La griglia ha una forma

esagonale, ed e suddivisa in 3 macro settori, ciascuno composto di 6 moduli

di 4 torri. Il numero complessivo di torri e pari a 90. Ciascuna Torre di

ogni modulo e collegata alla medesima Junction Box di modulo, ovvero una

struttura che fornisce al modulo la necessaria potenza elettrica e distribuisce

le linee di collegamento su fibra ottica per la trasmissione dei dati. Infine,

una Junction Box primaria funge da raccordo tra i vari moduli e convoglia

su un cavo elettro-ottico di lunghezza pari a 100 km tutte le linee elettriche

di potenza ed in fibra per la comunicazione dei dati da e verso terra.

2.2 Il progetto NEMO fase 1 e 2

La realizzazione di un apparato cosı complesso deve necessariamente pas-

sare attraverso fasi intermedie. Dopo lo studio di fattibilita e la localizzazione

del sito, la collaborazione NEMO ha realizzato un prototipo su cui montare


la maggior parte degli elementi critici previsti. Il progetto chiamato NEMO

Fase-1 [3] ha permesso la prima validazione delle simulazioni e delle soluzioni

tecnologiche proposte. Nel dicembre del 2006, una Junction Box e una ver-

sione ridotta di Torre, chiamata Minitorre, sono state depositate presso il

sito sottomarino di test dei Laboratori Nazionali del Sud di Catania, ad una

profondita di 2000 metri, e collegate attraverso un cavo elettro-ottico di 28

chilometri alla stazione di terra. La Minitorre e stata equipaggiata con sedi-

ci PMT posti su quattro piani. L’acquisizione della Minitorre e continuata

fino a tutto maggio 2007. La Fase-1 ha fornito un test fondamentale per le

tecnologie proposte per la realizzazione del rivelatore; con la fase successiva,

NEMO Fase-2, esse saranno finalmente validate alla profondita prevista per

il rivelatore km3 La Fase-2 prevede l’installazione di una Torre intera di 16

piani, a 3500 metri di profondita sul sito designato di Capo Passero. La

Torre e attualmente in costruzione e sara installata e resa operativa nel 2010.

Nel frattempo, la stazione di terra, situata nell’area portuale di Portopalo di

Capo Passero, e stata completata alla fine del 2008. Nel 2007 e stato deposi-

tato il cavo elettro-ottico che collega le profondita marine e la stazione di

terra. Sia il cavo che il design della Torre sono stati modificati leggermente

in accordo con le esperienze ottenute dalla Fase-1.

2.3 Il sistema di acquisizione dati per NEMO

fase-2

NEMO Fase-2 presenta un complesso sistema di acquisizione dati (DAQ,

dall’inglese Data AcQuisition) [4] nel quale i dati vengono raccolti dalla Torre

completa di 16 piani, trasportati verso la stazione di terra ed elaborati in

modo da ottenere informazioni sugli eventi registrati dal telescopio.

I dati vengono raccolti dai fotomoltiplicatori e trasmessi alla stazione

a terra tramite cavi a fibre ottiche. Delle schede elettroniche particolari,

chiamate Floor Control Modul (FCM), sono poste nel centro di controllo nel

porto a Portopalo e gestiscono la comunicazione con la Torre sottomarina.

2.3 Il sistema di acquisizione dati per NEMO Fase-2 15

Ogni FCM riceve i dati relativi a tutti i PMT di un unico piano e si interfaccia

via ethernet con il sistema di Trigger.

Il sistema di Trigger si occupa di raffinare e selezionare i dati rilevati. Una

stima cautelativa indica che il flusso dei dati che giunge da una Torre e pari a

256 MBps, in un giorno quindi vengono inviati verso la stazione oltre 20 TB.

Immagazzinare tutta questa mole di dati sarebbe un problema non banale,

visto anche in ottica del completamento delle 90 torri previste per il telesco-

pio finale; e da notare pero che i dati interessanti, cioe quelli che contengono

informazioni su eventi di carattere astrofisico, sono soltanto una piccola per-

centuale. Lo scopo del Trigger e proprio quello di selezionare questi dati. Il

sistema di Trigger e composto da varie unita server, ognuna con un compito

ben preciso, che lavorano sinergicamente per ridurre la quantita di dati di

oltre il 99%, consentendo un accumulo giornaliero per Torre non superiore ai

100 GB. Di seguito vengono illustrati gli elementi che compongono il Trigger

ed il percorso che i dati grezzi seguono all’interno di esso.

La Torre e suddivisa in settori logici in cui i piani vengono raggruppati

4 a 4, poiche una scheda FCM si occupa di un solo piano, un settore fa

riferimento a quattro FCM. Ogni gruppo di schede e collegato tramite un

GigaBit Switch a un server denominato Hit Manager (HM).

Poiche il presente lavoro sviluppa proprio il trattamento dei dati acquisiti,

e necessaria una digressione su come tali dati vengono prodotti dai PMT.

Si parla di hit (“colpo” in inglese) intendendo il risultato della misura di

un fotone che incide su un PMT. Si faccia riferimento alla Figura 2.2: un

fotomoltiplicatore “illuminato” da uno o piu fotoni traduce il segnale ottico

in entrata in una cascata di elettroni che, procedendo verso gli stadi finali del

PMT, si ingrandisce (il numero degli elettroni si moltiplica fino a circa 5×107

elettroni). L’impulso elettrico amplificato che risulta in uscita al PMT ha

l’andamento temporale mostrato in Figura 2.2 in basso a sinistra; esso viene

introdotto su una scheda elettronica di interfaccia al PMT che permette la

lettura e l’elaborazione di tale segnale.

Su tale scheda, il campionamento del segnale in uscita al PMT e operato


Figura 2.2: Rappresentazione di come funziona un PMT.

da un Convertitore Analogico a Digitale (ADC) che di fatto quantizza l’inten-

sita dell’impulso elettrico, convertendolo in valori che seguono una scala in

unita di misura arbitraria (ADC units). Il risultato di questa operazione e la

trasformazione dell’impulso in una sequenza di informazioni digitali, i “cam-

pionamenti” (che sono indcati nella Figura 2.2 da pallini rossi), ciascuno dei

quali e ottenuto con una cadenza di 5 ns, ed ha una rappresentazione numeri-

ca ad 1 byte. Un “hit” e dunque l’insieme dei campionamenti che descrivono

l’impulso elettrico indotto da uno o piu fotoni che colpiscono il PMT. A

causa della memoria limitata riservata alla FIFO che accoglie i campiona-

menti dopo l’ADC, quando la lunghezza temporale di un impulso eccede 315

ns (che corrispondono a 64 campionamenti, ciascuno di 1 byte) la sequenza

dei campionamenti viene spezzata. Si definisce “DataFrame” il raggruppa-

mento di al massimo 64 campionamenti. Quindi, un “hit” e formato da uno

o piu DataFrame. Vi veda l’Appendice A per il dettaglio della struttura dati

DataFrame.


Illustriamo brevemente il sistema di trigger cosı come rappresentato in

Figura 2.3. Gli Hit Manager bufferizzano i dati grezzi (“rawdata” in inglese)

raccolti dal telescopio sottomarino che le schede FCM passano loro. Dopo

di che, gli HM raggruppano gli hit scansionati nei rawdata provenienti dai

PMT di un settore per intervalli temporali denominati Time Slices (TS);

l’insieme degli hit di un settore della Torre racchiuso entro una TS viene

denominato Sector Time Slices (STS). Un HM ha anche il compito di creare

sequenze ordinate temporalmente di STS. Gli HM quindi inviano queste STS

alle Trigger CPU (TCPU) attraverso un Gigabit Switch. Le TCPU hanno

il compito di selezionare i dati delle STS che contengono eventi interessanti

attraverso degli algoritmi dedicati. Poiche non c’e una corrispondenza uno ad

uno tra macchine TCPU e HM, e stato definito un protocollo per la gestione

della comunicazione tra i due elementi del sistema, che si avvale del modello

denominato Barrell Shift Paradigm [5]. Esso implica che, a rotazione, gli

HM parlino con una sola TCPU per volta. Una TCPU attende di raccogliere

tutti i dati di una STS da tutti gli HM prima di iniziare la loro elaborazione.

Per costruire un evento vengono utilizzati i seguenti criteri di selezione

chiamati semi di trigger :

1. coincidenza semplice (hit quasi simultanei, entro pochi nanosecondi,

tra due PMT vicini);

2. coincidenza di piano (una Coincidenza Semplice tra due PMT vicini

piu un hit in un PMT dello stesso piano ma opposto alla coppia che ha

dato la coincidenza semplice);

3. superamento di una soglia in carica di un singolo hit,

4. random trigger, una scelta casuale periodica di hit su tutti i PMT

che occorrono in una finestra temporale prefissata (in genere 1 ms);

questo seme serve acquisire un sufficiente set di dati, per monitorare il

funzionamento su lungo periodo dei PMT, ma non per cercare eventi

di fisica.


A seguito del verificarsi di una o piu condizioni di trigger viene definita

un’opportuna finestra temporale entro cui ricadono gli hit che hanno dato i

semi di trigger piu gli altri hit che vi ricadono perche temporalmente compresi

entro tale finestra. La finestra di trigger viene etichettata con un’opportuna

flag che identifica le condizioni di trigger che hanno causato la definizione di

questa finestra temporale. Definito l’evento, la TCPU lo spedisce all’Event

Manager. L’Event Manager (EM) raccoglie i dati selezionati dalle TCPU e

riordina temporalmente gli eventi che va accumulando.

Figura 2.3: Schema delle macchine usate dal sistema di acquisizione dati.

Questo e necessario perche le TCPU operano su Time Slice diverse in

modo asincrono. Una volta riordinati, gli eventi vengono scritti in file di

opportune dimensioni (mai eccedenti i 100MB) denominati file PostTrigger.

Questi sono inviati dall’EM attraverso un socket TCP/IP a un sistema di

storage che li memorizza permanentemente. A supervisionare tutta la catena

di trattamento dei dati e posto il Trigger System Controller (TSC): esso


controlla e configura il Sistema di Trigger, e responsabile della gestione dei

problemi che potrebbero avere i vari server, ed e il punto di contatto tra il

sistema di Trigger e la Console del RUN CONTROL (ovvero l’interfaccia sulla

quale gli utenti operano) per la gestione dell’acquisizione dell’esperimento.

Figura 2.4: Schema degli elementi del sistema di Trigger per il monitoraggio

dei parametri di interesse.

L’intero sistema puo essere controllato attraverso il monitoraggio di al-

cuni parametri particolarmente indicativi di ogni fase del trattamento dei

dati acquisiti (si veda la Figura 2.4). Un esempio di questi dati puo essere

l’hit rate, cioe la quantita di dati raccolti in un intervallo di tempo dagli

Hit Manager, il trigger rate, la quantita di eventi giudicati interessanti dalle

TCPU, l’event rate, il numero di eventi riordinati dall’Event Manager, e tutte

le misure riguardanti lo stato di “salute” di ogni server, come lo stato delle

connessioni di rete, la percentuale di uso dei processori ed altri parametri sig-

nificativi. A tale scopo e prevista un server dedicato, il PCMonitor, collegato

al sistema di Trigger tramite la rete, in modo da raccogliere informazioni e

redistribuirle a dei programmi di visualizzazione.


In questo contesto, e fondamentale disporre periodicamente, con una fre-

quenza scelta dall’operatore (ad es. 1 s−1), di un intero set di dati relativo ad

un evento selezionato dalla TCPU (rappresentato dalla freccia gialla centrale

in Figura 2.4). Per mezzo degli applicativi sviluppati per questo lavoro di

tesi, l’utente puo anche analizzare in tempo reale tutti gli hit che contribuis-

cono all’evento, e puo visualizzare la loro disposizione temporale attraverso

la struttura del rivelatore.

Capitolo 3

Tecnologie utilizzate

3.1 Linguaggio C++

Event Display e stato realizzato in C++ [6][7]. Il C++ e un linguaggio

di programmazione largamente usato nell’industria. E stato sviluppato (in

origine col nome di “C con classi”) da Bjarne Stroustrup ai Bell Labs nel

1983 come un miglioramento del linguaggio C: ad esso sono stati aggiunti il

supporto alla programmazione ad oggetti, la gestione delle eccezioni, l’over-

loading degli operatori, la programmazione generica ed altre caratteristiche

che lo rendono adatto allo sviluppo di applicazioni software su larga scala.

Il linguaggio C++ e molto versatile e presenta elementi sia di alto livello,

cioe fornisce strumenti per astrarre dai dettagli della macchina, che di basso

livello, mettendo a disposizione dei costrutti considerati “vicini all’hardware”

come la manipolazione diretta di indirizzi di memoria attraverso i puntatori

e la possibilita di scrivere segmenti di codice assembly all’interno di codice

C++. E anche uno tra i linguaggi piu veloci in circolazione. Tutte queste

caratteristiche lo hanno reso adatto per la costruzione di un gran numero di

applicazioni anche molto differenti tra loro che vanno dai database agli ap-

plicativi per l’ufficio, dai kernel di sistemi operativi ai videogiochi, dai server

web ai compilatori. Il C++ non implementa alcune funzionalita come il

supporto al multithreading, la programmazione di rete e lo sviluppo di inter-

21

22 Capitolo 3. Tecnologie utilizzate

facce grafiche che pero sono fornite da molte librerie disponibili per questo

linguaggio. Di seguito vengono descritte le librerie impiegate per l’Event

Display.

3.2 La libreria Qt

Per l’interfaccia grafica sono state utilizzate le librerie Qt versione 4.4.

Qt e un framework open source largamente usato per lo sviluppo di pro-

grammi con GUI (Graphical User Interface) realizzato dall’azienda norveg-

ese Trolltech [8]. Qt e soprattutto utilizzato nell’ambiente desktop KDE per

sistemi Unix ma, essendo multipiattaforma, puo essere impiegato anche in

Windows, Mac e nei sistemi embedded (PDA, smartphone) tramite Qtopia.

Qt non e usato soltanto per la costruzione di interfacce grafiche ma anche

per lo sviluppo di applicazioni console e server grazie ad una serie di API

(Application Programming Interface) di generica utilita e non strettamente

legate all’interazione con l’utente come contenitori, astrazione per la concor-

renza, programmazione di rete, accesso a database SQL e supporto al formato

XML. Il framework Qt non fornisce soltanto delle librerie ma, attraverso il

Meta-Object System [9] estende il linguaggio C++ e lo munisce di alcune

caratteristiche interessanti come il sistema Signal/Slot, introspezione e chia-

mate asincrone a funzioni. Il Meta-Object System e basato su tre elementi:

una classe chiamata QObject, la classe base per gli oggetti che vogliono ben-

eficiare del Meta-Object System, una macro chiamata Q OBJECT da porre

all’interno della sezione privata della dichiarazione di una classe che vuole

avvalersi di questa caratteristica, e il MOC (Meta-Objetc Compiler), uno

strumento che legge un file sorgente C++ e, quando trova dichiarazioni di

classe che contengono la macro Q OBJECT, produce un altro file sorgente

C++ che poi sara il codice effettivamente compilato. Grazie al precompila-

tore MOC, la sintassi del C++ puo essere modificata e adattata alle esigenze

di Qt. La miglioria piu interessante apportata dal Meta-Object System e

il sistema Signal/Slot. Esso e usato per la comunicazione tra oggetti. Un

3.3 Il framework ROOT 23

Signal e un segnale che puo essere emesso da un oggetto quando raggiunge

uno stato particolare o avvengono determinati eventi. Uno slot e una fun-

zione che viene chiamata in risposta a questi eventi. Il meccanismo funziona

in questo modo: gli oggetti che sono interessati ad un certo tipo di evento

devono dichiarare uno slot attraverso il metodo connect() fornito da Qt;

quando un oggetto emette un segnale (con una sintassi simile a quella di una

chiama a funzione: emit nomeSegnale(parametri) ) tutti gli oggetti che

si erano registrati precedentemente recepiscono la notifica chiamando lo slot

specificato con gli stessi parametri del segnale appena emesso. Tale sistema

e particolarmente conveniente in un interfaccia grafica quando a determinate

azioni dell’utente si vuole rispondere con determinate azioni da parte del pro-

gramma. Questo meccanismo e completamente type safe, cioe la segnatura

del segnale deve corrispondere necessariamente alla segnatura dello slot asso-

ciato. E un’alternativa alla tecnica delle callback, che consiste nel passare ai

generatori di eventi un puntatore alla funzione (chiamata appunto callback)

che si vuole sia richiamata all’occorrenza di un evento. Le callback hanno lo

svantaggio di accoppiare fortemente gli oggetti responsabili degli eventi e gli

oggetti che devono rispondere a questi e di non essere type safe.

3.3 Il framework ROOT

ROOT [10], un framework per l’analisi dei dati ad alte energie sviluppa-

to dal CERN (European Organization for Nuclear Research), e stato usato

per la creazione e visualizzazione dei grafici. ROOT puo essere usato at-

traverso un interprete C++ chiamato CINT, cosı da avere un sistema di

rapida prototipazione, oppure compilato se sono necessarie le massime per-

formance. ROOT e un framework molto vasto che include funzionalita utili

nel campo della fisica sperimentale come generatori pseudocasuali di eventi,

acquisizione e analisi di dati, ed anche strumenti di utilita generale come

classi per la costruzione di interfacce grafiche. Quest’ultima caratteristica e

stata usata in un primo momento nello sviluppo di Event Display per poi


passare alla libreria piu specifica Qt. Oggetti grafici Qt e ROOT comunque

possono convivere nella stessa applicazione grazie ad una patch sviluppata

dal Brookhaven National Laboratory [11]: in questo modo vengono integrati

grafici ROOT nell’applicazione Event Display, che e basata su Qt.

3.4 Il dispatcher ControlHost

Per quanto riguarda la comunicazione di rete, non sono state usate di-

rettamente le Berkeley sockets API, ovvero quell’interfaccia controllata dal

sistema operativo (originariamente creata nel 1983 per il sistema operativo

4.2BSD, ma oramai supportata da quasi tutti i sistemi operativi) che per-

mette a processi diversi di comunicare, ma un sistema particolare chiamato

ControlHost. ControlHost e stato sviluppato dal CASPUR (Inter-University

Computing Consortium) [12] con lo scopo di fornire un sistema che ottimizza

e snellisce lo scambio di messaggi tra processi in esecuzione su piu macchine

interconnesse via internet. ControlHost lavora al livello applicazioni nel mod-

ello TCP/IP. I processi possono essere divisi in due insiemi: processi che

generano dati e processi che ricevono dati. Naturalmente questi due insiemi

possono intersecarsi, cioe un processo puo generare e ricevere dati allo stesso

tempo. Quando una certa quantita di byte deve essere spedita, il pacchetto e

etichettato c on una piccola stringa dimensionata fino a 8 caratteri detta tag,

i dati cosı ordinati vengono chiamati Tagged Data. I generatori non inviano

i messaggi direttamente ad un destinatario finale, piuttosto essi vengono im-

messi nella rete attraverso un server particolare: il dispatcher. Il dispatcher

e un processo indipendente che puo essere posto in qualsiasi macchia, il suo

ruolo e quello di ridistribuire i Tagged Data a tutti i processi ricevitori che

hanno dichiarato di essere interessati ai messaggi etichettati con tag specifici.

Il dispatcher puo agire anche da generatore: esso spedisce delle stringhe in-

formative ai peer della rete quando dei nuovi processi si uniscono o lasciano

il network; queste informazioni possono essere utili per il monitoring dei pro-

cessi. Inoltre, se necessario, i messaggi possono essere consegnati in modo

3.5 XML 25

sincrono: il dispatcher consegna una porzione di Tagged Data soltanto se

tutti i processi destinatari hanno completato le oper azioni sulla porzione di

dati precedente. Nel caso di Event Display, ControlHost e stato molto utile

perche ha permesso di separare con poco sforzo chi genera le informazioni

da monitorare (il sistema di DAQ) e il visualizzatore di queste informazioni

(l’interfaccia grafica Event Display). Uno scenario possibile consiste nella

presenza di piu istanze di Event Display in esecuzione contemporaneamente:

in questo caso il trasferimento a piu estremi di comunicazione e la dupli-

cazione dei dati sono completamente trasparenti al sistema di DAQ che non

ha bisogno nemmeno di sapere a quanti o a quali host devono essere spediti

i dati.

3.5 XML

XML [13] (acronimo di eXtensible Markup Language) e un metalinguag-

gio di markup, ovvero un linguaggio marcatore che definisce un meccanismo

sintattico che consente di estendere o controllare il significato di altri lin-

guaggi marcatori, proprio come SGML1, di cui e principalmente una versione

semplificata. Un linguaggio di markup puo essere definito come un insieme di

convenzioni capaci di rendere esplicita una particolare interpretazione di un

testo. La nascita di XML risale alla seconda meta degli anni ‘90, nel contesto

della famosa guerra dei browser, quando cresceva la necessita di un linguaggio

di markup che offrisse maggiore liberta nella definizione dei tag (marcatori)

pur rimanendo nell’ambito del rispetto di uno standard. Nel 1998 il W3C

(World Wide Web Consortium) pubblica ufficialmente la versione 1.0 di XML

come Recommendation, ovvero come proposta ufficiale e stabile. Tuttavia,

anche se gli obiettivi iniziali della nascita di XML erano rivolti alla soluzione

di un problema di standard per il Web, ben presto ci si accorse che XML

non era limitato al solo contesto Web. Esso risulta essere abbastanza gen-

erale per poter essere utilizzato nei piu disparati contesti: dalla definizione

1Standard Generalized Markup Language


della struttura di documenti allo scambio di informazioni tra sistemi diversi,

dalla rappresentazione di immagini alla definizione di formati di dati. Come

gia accennato le librerie Qt supportano il formato XML, fornendo un modu-

lo chiamato QtXml pensato principalmente come stream reader e writer su

documenti XML. Questo modulo e stato utilizzato in questo lavoro di tesi

per la gestione del caricamento e salvataggio della configurazione del mod-

ulo PlotOn (un esempio di file di configurazione e riportato in Figura 3.1),

utilizzato da Event Display (si veda paragrafo 4.2.1).

Figura 3.1: Esempio di file in formato XML di settings per il modulo PlotOn,

discusso nel paragrafo 4.2.1.

3.5 XML 27

Purtroppo pero il modulo QtXml della versione 4.4 delle librerie Qt non

supporta ancora l’XML Schema, che e un documento XML capace di validare

un altro documento XML, ovvero di verificare che i suoi elementi siano in ac-

cordo con la descrizione in linguaggio XML Schema. L’integrazione di questa

funzionalita e prevista per la versione 4.6 delle librerie Qt che al momento

della scrittura di questa tesi sono ancora in fase di sviluppo. La mancanza

del supporto XML Schema non permette all’Event Display di controllare se

la struttura del documento XML caricato rispetta cio che il programma si

attende. Per questo scopo viene fornito assieme al programma un file XML

Schema appositamente creato, che potra essere utilizzato, in qualche software

che da la possibilita di validare documenti XML, oppure in validatori on-line,

per poter verificare la correttezza del file secondo la grammatica dell’XML

Schema fornito. Questo problema non si presenta nella fase di salvataggio

delle impostazi oni, in quanto il modulo PlotOn e stato sviluppato per salvare

queste impostazioni secondo lo schema corretto. Di seguito si riporta l’XML

Schema per validare il file di configurazione.

<?xml version="1.0" encoding="utf-16"?>

<xsd:schema attributeFormDefault="unqualified"

elementFormDefault="qualified" version="1.0"

xmlns:xsd="http://www.w3.org/2001/XMLSchema">

<xsd:element name="settings">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="plane" type="xsd:int" />

<xsd:element name="pmt_plane" type="xsd:int" />

<xsd:element name="delta_window" type="xsd:int" />

<xsd:element name="delco" type="xsd:int" />

<xsd:element name="run_num" type="xsd:int" />

<xsd:element name="gps_start_time" type="xsd:int" />

<xsd:element maxOccurs="unbounded"

name="lutt_toff" type="xsd:int" />


<xsd:element maxOccurs="unbounded"

name="lutt_ped" type="xsd:int" />

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:schema>

Capitolo 4

Software Event Display

4.1 Introduzione al funzionamento

Il software prodotto per questo lavoro di tesi e chiamato Event Display.

Il suo scopo e il monitoring e l’analisi dei dati inerenti agli eventi selezionati

dal sistema di Trigger dell’esperimento NEMO. Esso puo essere utilizzato

contestualmente all’acquisizione in tempo reale dell’esperimento oppure per

elaborare i dati registrati dall’Event Manager nei file PostTrigger. Event

Display e sviluppato per l’uso in sistemi Unix, su cui si basa il software del-

la DAQ dell’esperimento NEMO. L’Event Display e composto da 4 moduli:

Statistics, Visualizer, Plot e PlotOn. Statistics e Visualizer permettono di vi-

sualizzare statistiche relative agli eventi, mentre Plot e PlotOn consentono il

monitoraggio grafico degli eventi sulle torri. Event Display e stato realizzato

in due versioni: online ed offline. La versione online include i moduli Visuliz-

er e PlotOn, ovviamente tale versione del programma richiede un accesso

alla rete per poter ricevere i dati necessari al suo funzionamento; mentre la

versione offline, composta dai moduli Statistics e Plot, richiede soltanto un

file contenente dati organizzati secondo le strutture gia descritte al capitolo

2. Come supporto alla versione online dell’Event Display, per simulare le

condizioni di acquisizione dell’esperimento, e stata sviluppata una semplice

applicazione denominata Parser che permette la scansione di dati da file ed il

29

30 Capitolo 4. Software Event Display

successivo invio di questi, tramite il sistema ControlHost discusso in sezione

3.4, alle istanze di Event Display che ne richiedono la ricezione. Il software

Event Display si avvale di un’interfaccia grafica per l’utente, opportunamente

sviluppata, in cui ogni suo modulo e accedibile attraverso pannelli specifici.

4.2 Utilizzo

Una volta compilato il sorgente, Event Display puo essere avviato da linea

di comando specificando la versione:

• ./eventdisplay online;

• ./eventdisplay offline;

• ./eventdisplay parser.

Ciascun comando corrisponde alla relativa versione del programma: se la

sintassi non e conforme ai 3 casi elencati, un messaggio di errore avvertira

l’utente e riassumera i comandi possibili. Tutte le versioni del programma

contengono alla base della finestra una label di aiuto che guidera l’utente

durante l’utilizzo.

4.2.1 Event Display in modalita Online

Eseguendo l’Event Display in versione online si vedra apparire una fines-

tra con due tab corrispondenti ai moduli Visualizer e PlotOn. Dato che la

versione online dell’Event Display richiede un flusso di dati da rete, e neces-

sario specificare il nome univoco dei dati, cioe il tag, che vogliamo ricevere

dal dispatcher: nella sezione Connection Settings occorre specificare il tag

dei dati in ingresso e l’indirizzo IP del dispatcher. Ciascuno dei 2 moduli

dell’Event Display in modalita online, Visualizer e PlotOn, ha un suo flusso

di dati separato, questo vuol dire che e possibile utilizzare contemporanea-

mente le funzionalita di Visualizer e di PlotOn sia sullo stesso flusso di dati

4.2.1 Event Display in modalita Online 31

(andando a inserire lo stesso tag e dispatcher in entrambi) sia da flussi di

dati indipendenti.

Pannello Visualizer

Il pannello Visualizer, mostrato in Figura 4.1, permette una visualiz-

zazione di statistiche condotte sui dati e rappresentate con istogrammi de-

nominati collettivamente GraphStat (si veda la sezione 4.2.3). Le statistiche

si riferiscono a tre categorie d’indagine da scegliere nel box Graphs: la pri-

ma categoria riguarda la distribuzione del numero degli hit negli eventi, la

seconda categoria descrive la distribuzione di carica totale (espressa in ADC

units) degli hit e la terza categoria raffigura la distribuzione temporale dei

campionamenti di ogni hit.

Figura 4.1: Pannello Visualizer.

Nel pannello di Visualizer, in basso, e visibile una box Connection Settings

attraverso la quale l’utente inserisce tag dei dati e l’indirizzo del dispatcher.

Un thread specializzato si mette in attesa dei dati, non bloccando cosı l’intera

applicazione, nel momento in cui i dati sono disponibili i grafici verranno

riempiti. L’aggiornamento dei grafici avviene circa ogni 0.1 s permettendo


cosı una quasi simultaneita tra la ricezione dei dati e l’aggiornamento dei

grafici.

Pannello PlotOn

PlotOn (Figura 4.2) e la funzionalita piu caratteristica dell’Event Dis-

play. Con PlotOn si puo vedere come gli hit si sono manifestati lungo una

Torre del rivelatore. Questo avviene disegnando un semplice schema grafico

chiamato PlotGraph, descritto in sezione 4.2.2. Nel PlotGraph, ciascun hit

di ciascun PMT compreso in un evento e rappresentato su una linea tem-

porale propria del PMT e raffrontato con gli hit raccolti dagli altri PMT

della Torre. Per rappresentare con chiarezza gli hit dei vari piani e possibile

graficare separatamente ogni settore della Torre in piu PlotGraph dedicati,

ognuno contenuto in una particolare finestra grafica. PlotOn, come Visual-

izer, ha bisogno di una connessione con un dispatcher che gli inoltri i dati da

visualizzare.

Figura 4.2: Pannello PlotOn.

La configurazione del PlotOn puo avvenire online oppure caricata da file.

La configurazione di PlotOn richiede, oltre all’impostazione Plane per win-

4.2.2 PlotGraph 33

dow, che setta il numero di piani in ogni finestra di PlotGraph, una serie di

informazioni necessarie alla buona resa visuale dei grafici, che in Plot vengono

lette insieme ai dati degli eventi dal file dei campionamenti.

Se queste configurazioni non vengono caricate da file devono essere rice-

vute assieme ai dati. PlotOn e stato sviluppato in modo da controllare

periodicamente se tali configurazioni sono state inviate in modo da rendere il

tutto trasparente all’utente che non deve richiedere queste impostazioni. Se

invece si ha intenzione di caricare la configurazione da file questo deve essere

fatto prima della connessione, cliccando su Load Conf. Una volta ottenuta la

configurazione e possibile salvarla (premendo Save Conf) per scopi futuri,

come una successiva ricezione di dati con la stessa configurazione oppure in

caso in cui per qualche motivo la connessione venga interrotta e non fosse

piu possibile far ripartire l’invio dei dati dall’inizio.

4.2.2 PlotGraph in dettaglio

Il PlotGraph e il grafico utilizzato da Plot e PlotOn per simulare la config-

urazione degli hit sulle torri al momento della rilevazione di un evento. Come

si puo vedere in Figura 4.3, ogni riga tratteggiata rappresenta un PMT e og-

ni raggruppamento di PMT e un piano. Se l’impostazione Plane per window

e inferiore al numero di piani totali allora verranno creati automaticamente

tanti PlotGraph, ognuno per ogni settore, suddividendoli equamente tra le

finestre. Un settore e l’insieme di piani di ogni finestra ed in ogni PlotGraph

l’indicatore del settore e presente in alto a sinistra. Un evento sara raffigu-

rato nel grafico da una serie di marcatori simboleggianti un hit, sulla linea

tratteggiata relativa al PMT che ha generato l’hit.

La barra verticale di colore rosso corrisponde ad un tempo pari a 0 ns,

assunto come riferimento per il grafico, cioe quello in cui e avvenuto il pri-

mo seme di trigger dell’evento. I tempi di ciascun hit dell’evento vengono

rapportati ad esso. L’asse delle ascisse rappresenta quindi la finestra tempo-

rale che contiene l’evento e permette di raffigurare in che ordine temporale


Figura 4.3: Esempio di PlotGraph con una configurazione di hit.

gli hit dell’evento sono stati misurati, mentre l’asse delle ordinate riporta la

numerazione assoluta dei PMT.

Ogni volta che si passa da un evento all’altro si vedra variare la config-

urazione dei marcatori in base alla nuova disposizione temporale degli hit

rispetto al seme di trigger. Durante l’utilizzo del PlotGraph si vedra crescere

dalla base un istogramma di colore azzurro. Esso segna per ogni hit che viene

visualizzato la propria posizione temporale rispetto al seme di trigger. Tale

istogramma e utile per studiare eventuali correlazioni tra il seme di trigger e

gli hit che lo precedono e/o succedono.

4.2.3 GraphStat in dettaglio

Il tipo di grafico GraphStat e a seconda dei casi un istogramma monodi-

mensionale o bidimensionale. E monodimensionale quando si mostrano le

distribuzioni del numero di hit per evento e della carica per hit; e bidimen-

4.2.3 GraphStat 35

sionale quando si mostra il grafico Wave Form. Ogni grafico presenta alla

base alcune informazioni: nel riquadro Graphic Stat sono contenute infor-

mazioni come il numero di Entries, cioe di dati che hanno contribuito alla

formazione dell’istogramma, la media dei valori inseriti (Mean), e un in-

dice di dispersione dal valore medio chiamato Root Mean Square (RMS). Se

le dimensioni dell’istogramma non sono ottimizzate sui valori inseriti, l’is-

togramma stesso puo essere ridimensionato facilmente attraverso le text box

nella cornice Graphic Settings. Basta inserire i valori numerici di minimo,

massimo e numero di bin e premere il bottone Resize. Se uno o piu text

box vengono lasciate in bianco il programma mantiene i valori attuali per

quelle informazioni. Il bottone Set Log y serve a settare la scala logarit-

mica nell’istogramma lungo l’asse delle ordinate; premendolo nuovamente si

torna alla visualizzazione lineare. I grafici sono di tre tipi:

Figura 4.4: Hits Graph.

• Hits Graph (Figura 4.4) raffigura la distribuzione degli hit negli even-

ti; l’asse delle ascisse rappresenta il numero di hit mentre l’asse delle

ordinate il numero di eventi che contengono un tale quantita di hit.

• ADC Graph (Figura 4.5) mostra invece la distribuzione di carica in

unita ADC negli hit; in ascissa e riportata la carica di ogni hit in ADC

units, mentre nell’ordinata il numero di hit aventi tale carica.


Figura 4.5: ADC Graph.

• Wave Form (Figura 4.6) mostra la distribuzione temporale dei cam-

pionamenti registrati per ogni evento. Un hit infatti puo durare diverse

decine di ns ed il campionamento della sua carica avviene ogni 5 ns.

Nel grafico le zone piu dense di punti delineano la forma piu ricorrente

dell’impulso rilasciato dal segnale di un PMT.

Figura 4.6: Wave Form Graph.

4.2.4 Statistics 37

4.2.4 Statistics

Il pannello Statistics, si veda Figura 4.7, ha lo stesso scopo di Visualizer

della versione online, ma a differenza di esso i dati da elaborare non devono

essere ricevuti tramite rete con il meccanismo ControlHost ma devono essere

disponibili in locale.

Figura 4.7: Pannello Statistics.

Statistics e di semplice utilizzo: per prima cosa e necessario caricare il

file di dati PostTrigger da file system mediante il tasto Load File. Succes-

sivamente, e possibile raffinare le statistiche scegliendo di visualizzare solo

informazioni riguardanti un certo sotto insieme dei tipi di trigger rilevati nel

box Trigger types. Viene aggiunta in Statistics, rispetto a Visualizer, la pos-

sibilita di scegliere un intervallo di eventi da considerare; nel box From To,

infatti, si possono inserire i numeri iniziale e finale dell’intervallo di eventi


(inserire lo stesso numero fara visualizzare le statistiche di un singolo even-

to). A questo punto l’utente non deve fare altro che premere sul bottone

Get Stat e aspettare che il file venga scansionato completamente (o l’inter-

vallo scelto). A fine scansione i grafici saranno visualizzati automaticamente,

mentre nella text box al centro si vedranno informazioni generali sul file. Ne

citiamo qui le piu rilevanti:

• il percorso del file,

• il General Tag,

• numero di ogni Trigger types rilevato,

• meta ampiezza della finestra temporale in unita di 10 ns,

• numero di eventi scansionati.

Ogni volta che vogliamo cambiare statistiche da visualizzare non serve

ricaricare il file ma basta premere nuovamente su Get Stat.

4.2.5 Plot

Come Statistics, anche Plot (in Figura 4.8) non necessita di una con-

nessione di rete con un dispatcher per analizzare i dati; e necessario che essi

siano disponibili sulla stessa macchina che esegue l’Event Display sotto forma

di file PostTrigger. L’utilizzo di Plot e configurabile tramite l’impostazione

Plane per window, che corrisponde a quella di PlotOn, ed i box Automatic

Parsing, Go to Event e Forward Rewind. Con Automatic Parsing si puo far par-

tire un parsing automatico che scorre gli eventi uno ad uno alla velocita in

secondi specificata nel text box Speed in Sec, il valore di default e 1 secondo

(si possono inserire anche tempi con decimali, per esempio 0,5 corrisponde

a mezzo secondo, il punto o la virgola per separare la parte intera da quella

decimale sono equivalenti). Go to Event fa saltare all’evento specificato dal-

l’utente mentre Forward Rewind consente di spostarsi in avanti/indietro dalla

4.2.5 Plot 39

posizione attuale di tanti eventi quanti vengono inseriti dall’utente, il valore

di default e 1 evento.

Per utilizzare il modulo Plot occorre quindi impostare il numero di Plane

per window, caricare un file di campionamenti cliccando su Load File, e

scegliere se utilizzare l’Automatic Parsing o quello manuale (Forward Rewind)

per spostarsi tra gli eventi. In automatico si apriranno le finestre dei Plot-

Graph.

Figura 4.8: Pannello Plot.

Capitolo 5

Architettura

L’architettura dell’Event Display mostrato in Figura 5.1, si organizza in

3 gruppi di classi:

• le classi per la visualizzazione degl hit della Torre, denominate classi di

HitPlotting, implementano i moduli Plot, PlotOn, e i grafici PlotGraph;

• le classi per le statistiche implementano i moduli Statistics, Visualizer

e GraphStat;

• le classi per le Connection Settings implementano un’interfaccia (Con-

figWidget) per caricare e salvare i Settings.

La classe che si occupa di creare la finestra principale e MyMainFrame,

essa accetta come parametro la versione del programma passata da riga di co-

mando ed a seconda di essa istanzia i moduli. MyMainFrame contiene come

campi privati puntatori agli oggetti che istanziano i moduli, questa relazione

di aggregazione e stata necessaria perche al momento dell’avvio del program-

ma la creazione degli oggetti e subordinata alla versione online/offline che

viene specificata come opzione nella riga di comando.

41

42 Capitolo 5. Architettura

Figura 5.1: Diagramma delle classi dell’Eevent Display.

5.1 HitPlotting

Le classi dedicate alla visualizzazione degli hit sono Plot, PlotOn, PlotOff

e PlotGraph. PlotOn e PlotOff ereditano Plot, vedi Figura 5.2. L’utilita di

Plot e quella di contenere i campi e le funzioni comuni sia a PlotOn che a

PlotOff, queste estendono Plot definendo ognuna campi e funzioni utili solo

nel loro ambito. L’utilizzo del PlotGraph e lo stesso sia in PlotOn che in

PlotOff, quest’oggetto e una finestra indipendente realizzata come QWid-

get (classe base di tutti gli oggetti ad interfaccia grafica Qt). Tale finestra

contiene al suo interno un oggetto di tipo TQtWidget che puo essere usato

come un regolare QWidget per creare GUI Qt-based con oggetti di ROOT

denominati TCanvas (riquadro per disegnare istogrammi e grafici) incorpo-

rati. In pratica si utilizza una classe di ROOT che permette di disegnare

istogrammi e grafici come fosse una GUI basata sulle librerie Qt, permet-

tendo di sfruttare le potenzialita di entrambe le tecnologie con una difficolta

minima. I PlotGraph utilizzati da PlotOn e PlotOff sono dichiarati in Plot

come puntatore ad un puntatore, in questo modo PlotOn e PlotOff possono

5.1 Plotting 43

istanziare un numero di PlotGraph che dipende dall’impostazione Plane per

window gia descritta.

Applicativi Offline

Il funzionamento della classe PlotOff parte dal caricamento di un file

PostTrigger, mendiante la funzione load file(); essa non fa altro che leggere

interamente il file, trasferirlo in una variabile buffer sufficientemente grande

(per rendere le successive letture performanti) e salvarsi dei puntatori agli

indirizzi corrispondenti all’Header Generale, alla DataCard (vedi Appendice

A per informazioni su Header Generale e DataCard) e all’inizio del buffer.

Questo permette in seguito di recuperare informazioni come numero di eventi

totali, numero di PMT per ogni piano, numero di piani ecc... Inoltre, grazie a

queste informazioni PlotOff e in grado di istanziare gli oggetti che andranno

a comporre la finestra del PlotGraph.

Il passo successivo e la configurazione della finestra per il PlotGraph.

Sull’oggetto TQtWidget devono essere disegnati:

• un numero di istogrammi e linee orizzontali tratteggiate, che rappre-

sentano i singoli PMT, pari numero totale dei PMT della Torre,

• indicatori del numero assoluto del PMT sull’asse delle ordinate,

• una linea verticale rossa posta al centro della finestra che rappresenta

l’istante 0,

• un ulteriore istogramma che tiene traccia della posizione temporale

degli hit che non siano il seme di trigger rispetto ad esso.

A questo punto il PlotOff e pronto per graficare gli eventi. A grandi linee

un evento e composto da vari hit e ogni hit da vari campionamenti. Un pun-

tatore pblock viene usato per mantenere la posizione all’inizio di ogni evento

e per spostarsi tra gli hit e i campionamenti, tutto questo avviene utilizzando

il buffer contenente il file salvato con la load file(). Le modalita di sposta-

mento tra gli eventi nel PlotOff sono tre: Automatic Parsing, Go To Event e


Figura 5.2: Classi per il plotting, PlotOn e PlotOff estendono Plot con una

generalizzazione.

Forward Rewind. Le funzioni che implementano queste funzionalita si basano

sull’utilizzo del pblock come riferimento alla posizione corrente. Per quanto

riguarda l’Automatic Parsing viene creato un thread di tipo TThread (una

classe di ROOT che e stata usata per creare ogni thread nel programma),

che ad intervalli di tempo regolari specificati dal campo Speed in Sec nell’in-

terfaccia grafica, si sposta in avanti di un evento aggiornando il puntatore

pblock. Spostarsi in avanti di un evento e molto facile in quanto le strutture

dati che compongono un evento contengono l’informazione di quanti byte

esso occupa, e quindi sufficiente incrementare il pblock dei byte dell’evento

corrente, per trovarsi all’inizio dell’evento successivo. Per fermare il thread

basta premere il bottone Stop dell’interfaccia grafica, la funzione chiamata

settera una variabile automatic on a 0, questa variabile viene controllata

ad ogni ciclo dal thread durante la sua esecuzione, e quando questo la trova

a 0 sa di doversi fermare. Per evitare problemi di concorrenza durante la

lettura/scrittura della variabile automatic on tali istruzioni vengono poste

tra due chiamate TThread::Lock() e TThread::UnLock(); esse garantiscono

la sicurezza degli assegnamenti e delle letture della variabile stessa. Queste

sono funzioni statiche che bloccano il mutex principale, impedendo che piu

task paralleli accedano contemporaneamente ai dati in memoria o ad altre

risorse soggette a race condition. Le race condition sono delle situazioni che si

5.1 Plotting 45

verificano quando due o piu processi stanno leggendo o scrivendo un qualche

dato condiviso e il risultato finale dipende dall’ordine in cui essi accedono a

tali dati.

Figura 5.3: Esempio di come Go To parte dall’inizio del buffer fino ad arrivare

all’evento scelto.

La funzionalita Go To, rappresentata in Figura 5.3, grazie ad un puntatore

che viene settato all’inizio del buffer gia in fase di caricamento, permette

di posizionarsi in maniera assoluta all’inizio di un evento, sia esso in una

posizione precedente o successiva alla corrente, con lo stesso meccanismo di

aggiornamento del pblock di Automatic Parsing, stavolta partendo dall’inizio

del buffer e non dalla posizione corrente. Questo meccanismo e necessario


poiche l’informazione sulla lunghezza di ogni evento si trova all’inizio dello

stesso, ma se l’evento su cui ci si vuole posizionare e gia passato, questa

informazione non e raggiungibile attraverso il pblock dato che dal pblock

non riusciamo a saltare all’evento precedente non sapendo la sua lunghezza. Il

Forward agisce esattamente come l’Automatic Parsing, pero non e automatico:

ogni volta che tale pulsante e premuto viene letto il numero di eventi da

saltare, per esempio si puo avanzare di un evento alla volta o due, o dieci

ecc...

Figura 5.4: Esempio di Forward: in questo caso la posizione corrente e l’inizio

del buffer e viene fatto il Forward di un evento alla volta.

Ogni volta ci si posizionera sull’evento che dista esattamente n eventi

5.1 Plotting 47

dopo il precedente. Infine Rewind e l’opposto di Forward, serve per tornare

indietro di n eventi arbitrari dalla posizione corrente, per farlo pero, come

Go To, parte la scansione dall’inizio del buffer fino ad arrivare alla posizione

corrente - n eventi.

Applicativi Online

La classe PlotOn estende Plot aggiungendo la funzionalita di ricevere i

dati sugli eventi via connessione internet attraverso il gia citato meccanis-

mo del ControlHost. Dato che il PlotOn non ha a disposizione l’intero file

di campionamenti da analizzare, certe informazioni necessarie alla configu-

razione della finestra e alla rappresentazione grafica, contenute negli Header

di questo file, devono essere recuperate in altro modo. I modi sono due:

• acquisire queste informazioni come flusso di dati all’inizio o durante la

ricezione,

• caricare queste informazioni da un file precedentemente salvato.

Se vuole caricare le informazioni da file, l’utente deve cliccare il pulsante

Load. Il caricamento del file avviene utilizzando il formato XML, i moduli

QtXML delle librerie Qt si sono rivelati molto utili e di facile utilizzo: un

elemento QDomDocument viene creato e assegnato al file scelto dall’utente,

successivamente si procede alla scansione degli elementi che compongono il

file chiamati QDomElement. Ciascun elemento viene poi associato ad un

campo di una struttura chiamata FlushInfo, utilizzata poi in PlotOn per

gestire questi dati. Il salvataggio ripercorre gli stessi passi in verso opposto:

partendo da un oggetto di tipo FlushInfo che il PlotOn stava utilizzando,

vengono estratti uno ad uno i suoi campi e assegnati a oggetti QDomEle-

ment. Questi, infine, vanno a comporre il QDomDocument che viene salvato

di nuovo su file. In questo modo la configurazione attuale del PlotOn viene

salvata su file per renderne possibile il riutilizzo in un momento successivo.

Se le informazioni di configurazione della finestra non vengono caricate da


file il PlotOn aspetta di riceverle dal dispatcher; regolarmente viene control-

lata la disponibilita di questi dati e, se essi sono disponibili, vengo utilizzati

immediatamente per la configurazione del PlotGraph. Dopo che l’utente

ha stabilito la connessione con il ControlHost, la ricezione dei dati avviene

evento per evento. Il PlotOn si aspetta di ricevere regolarmente blocchi di

dati contenenti un evento alla volta. Anche in PlotOn viene utilizzato il

puntatore all’evento pblock ma in questo caso il pblock viene settato ogni

volta all’inizio del blocco di dati ricevuto essendo questo un singolo evento,

riuscendo poi a processarlo come se fosse stato letto da file proprio come

fa PlotOff. Stabilita la connessione il PlotOn crea un oggetto di tipo Con-

trolHost, mettendosi in “lista” per ricevere flussi di dati con tag uguale a

quello inserito. Un thread viene quindi creato per mettersi regolarmente in

attesa dei dati; non appena un blocco di dati viene ricevuto si aggiorna il

pblock all’inizio del buffer in cui questi dati sono stati copiati e l’analisi puo

cominciare. Utilizzando un thread separato per mettersi in attesa dei dati

(evitando cosı di bloccare l’applicazione durante l’attesa) il processo PlotOn

non puo sapere esattamente quando sono disponibili i dati da processare. Per

risolvere il problema e stata molto utile la classe QTimer, ovvero un timer

che ad intervalli regolari genera segnali che possono essere catturati da slot

definiti precedentemente. In questo caso il PlotOn utilizzando la funzione

connect() di cui si e parlato nel capitolo 3.2, associa il segnale del timer alla

funzione che elabora i dati sull’evento appena ricevuto. Si puo modificare

a piacimento la durata dell’intervallo del timer, il box Speed in Sec nella

finestra del PlotOn serve proprio per modificare questo valore.

5.2 Statistiche

Le classi Stat, StatOff, StatOn e GraphStat (in Figura 5.5) fanno parte del

gruppo di classi che implementano i moduli Statistics, Visualizer. StatOff e

StatOn ereditano Stat, che dichiara campi e funzioni comuni alle due classi.

GraphStat ha una complessita maggiore di PlotGraph, dato che permette di

5.2 Statistiche 49

personalizzare il grafico; come gia descritto in sezione 4.2.3 in esso e possibile:

impostare valori di massimo e minimo per gli assi, settare la scala logaritmica

e tenere statistiche come numero e media di valori inseriti. Inoltre GraphStat

accoglie due tipi di grafici forniti da ROOT:

• TH1F, istogrammi monodimensionali utilizzati Hits Graph e ADC

Graph;

• TH2F, istogrammi bidimensionali nei quali si puo specificare sia il

valore delle ascisse che quello delle ordinate per disegni piu sofisticati,

utilizzati per il Wave Form.

Figura 5.5: Classi per le statistiche, StatOn e StatOff ereditano Stat, Stat

a sua volta include oggetti GraphStat che verranno utilizzati da StatOn e

StatOff

La classe GraphStat mette a disposizione alle altre classi funzioni denom-

inate getter/setter, ovvero funzioni che permettono di restituire o settare

i campi privati del grafico senza pero sapere come questi sono chiamati

o definiti. Il vantaggio di questa architettura e chiamato incapsulamento,

ovvero nascondere le parti interne di un componente presentando all’esterno


solo metodi della classe che sanno come gestirle. Un altro vantaggio dell’in-

capsulamento e quello di limitare gli effetti derivanti dalle modifiche ad un

sistema software. Infatti, se in futuro sara necessario andare a modificare il

comportamento interno della classe GraphStat, non si dovranno apportare

modifiche ai moduli che utilizzano le sue API, in quanto la loro interfaccia

rimarra a stessa, cambiera solo la loro implementazione. Sia in StatOn che

in StatOff sono utilizzati esattamente 3 GraphStat, uno per ogni grafico di

statistiche. In Stat sono dichiarati quindi 3 oggetti GraphStat che le classi

StatOn e StatOff istanzieranno nei loro costruttori. I GraphStat vengono

creati passandogli come parametro un puntatore all’istogramma che dovran-

no contenere. Gli istogrammi vengono creati assieme a StatOn e StatOff e

passati a GraphStat perche solo in GraphStat esiste la TCanvas dove poterli

disegnare. Si viene a creare un’architettura in cui i moduli StatOn e StatOff

sono padroni degli istogrammi, dato che la lettura dei dati da cui creare

le statistiche avviene in essi, ma delegano la gestione della visualizzazione

e dell’aggiornamento al GraphStat. Il funzionamento di StatOn e simile al

PlotOn: attraverso una connessione di rete con un dispatcher che gli inoltra

i dati un thread dedicato elabora un evento alla volta estraendo da esso

le informazioni necessarie a creare le varie statistiche. Una volta ottenute

queste informazioni StatOn le inserisce negli istogrammi. Questi vengono

aggiornati regolarmente tramite chiamate a funzioni dei GraphStat, conte-

nenti ogni istogramma utilizzato. La classe StatOff non ha bisogno di un

thread dedicato che si metta in attesa dei dati. Essa contiene una funzione

che carica un file PostTrigger dal file system, lo copia in una variabile buffer

che successivamente verra scansionata interamente prima di produrre ogni

grafico di statistiche, similmente a quanto descritto per PlotOff nella sezione

sugli Applicativi Offline.

5.4 Preparazione e compilazione del software 51

5.3 Connection Settings

Tutti i moduli che richiedono una connessione con il meccanismo del Con-

trolHost includono nei loro pannelli una sezione chiamata Connection Settings.

Questa sezione e un oggetto della classe ConfigWidget autonomo che viene

creato dai moduli per permettere l’inserimento all’utente del tag dei dati e

l’indirizzo del dispatcher. Una classe chiamata Settings accoglie queste in-

formazioni, e provvede funzioni per accedere ad esse e per modificarle. Come

e gia stato detto, i moduli online possono avere flussi di dati indipendenti,

infatti ogni modulo crea un oggetto Settings i cui campi tag e dispatcher

vengono impostati ai valori inseriti nelle textbox della sezione Connection

Settings nel momento in cui l’utente preme il bottone Connection. L’ogget-

to ConfigWidget nel momento della sua creazione riceve come parametro un

puntatore all’oggetto Settings creato dal modulo corrente: attraverso questo

puntatore ConfigWidget e in grado di leggere e modificare i suoi campi.

5.4 Preparazione e compilazione del software

Particolare attenzione e stata posta alla preparazione delle macchine sulle

quali Event Display deve essere eseguito. Event Display puo essere eseguito

solo su macchine Unix che dispongono delle librerie necessarie. Queste librerie

sono ROOT, Qt 4 e QtRoot, il modulo per far lavorare in una stessa finestra

grafica componenti Qt e ROOT. Non e necessario che la libreria ControlHost

sia presente nel sistema in quanto viene compilata staticamente ed e fornita

con il codice sorgente di Event Display. Di seguito sono illustrate le operazioni

da eseguire su di un computer con sistema operativo Linux.

Installazione librerie Qt

Per prima cosa, installare il framework Qt con una versione uguale o

superiore a 4.4. In questa fase la variabile di ambiente $QTDIR deve essere


inizializzata alla locazione dove la libreria e stata posta; essa sara necessaria

successivamente per la compilazione di QtRoot.

Installazione ROOT framework

Il secondo passo e l’installazione di ROOT. ROOT dovra supportare le

estensioni QtRoot, quindi deve essere compilato con l’opzione –enable-qt che

abilita il backend grafico per Qt. L’albero di directory creato con la com-

pilazione puo essere posto in qualsiasi locazione nel file system; le variabili

di ambiente $PATH, $LD LIRARY PATH e $ROOTSYS devono pero essere

impostate in modo da contenere il percorso della cartella dove ROOT e sta-

to installato, cosıcche i programmi che useranno il framework troveranno il

percorso della libreria dinamica attraverso le variabili di ambiente.

Installazione patch QtRoot

Il passo successivo e l’installazione della patch QtRoot. Si imposta la

variabile $QTROOTSYSDIR alla locazione dove si vuole installare QtRoot e

si compila il codice sorgente attraverso i classici comandi make e make install.

Se $QTROOTSYSDIR non corrisponde a $ROOTSYS $QTROOTSYSDIR

dovra essere inserita nella variabile $PATH per le stesse motivazioni del passo

precedente.

A questo punto la macchina e pronta per la compilazione di Event Display.

Il framework Qt mette a disposizione qmake [14], uno strumento semplice che

genera dei makefile [15] per un progetto, evitandone la scrittura diretta da

parte dello sviluppatore; questo tool e stato usato per automatizzare il pro-

cesso di compilazione di Event Display. La libreria ControlHost, tuttavia,

deve essere costruita a partire dal codice sorgente, per fare cio essa e for-

nita di una serie di makefile che pero lo strumento qmake non puo usare

direttamente. Per questo motivo e stato scritto un piccolo script Bash [16],

make.sh, che in una prima fase compila ControlHost e successivamente Event

Display; esso, se eseguito con il parametro “clean”, pulisce tutte le directory

dal risultato di una compilazione precedente. Event Display e stato testato

5.4 Preparazione e compilazione del software 53

su macchine Ubuntu 8.04 e Scientific Linux versione 5. Per la compilazione

e stato utilizzato gcc 4.2.3, le librerie usate sono ROOT 5.22 e Qt 4.4.

Appendice A

Strutture dati

La sequenza di byte che formano i campionamenti di un DataFrame sono

accompagnati da uno specifico header di grandezza costante pari a 12 byte, in

cui sono registrati i parametri sensibili che caratterizzano il DataFrame stes-

so: ad esempio e registrato il tempo di occorrenza del primo campionamento,

il numero identificativo (ID) del PMT e della Torre cui il PMT appartiene.

La seguente struttura riporta il dettaglio delle informazioni contenute in

un DataFrame. Si noti che spesso, nel testo che segue, si fa riferimento a

gruppi di 4 byte (32 bit) con il termine DWORD:

struct DataFrameHeader{

unsigned int TimeNs: 16; // Tempo relativo in unita di 10ns

unsigned int PMTID: 4; // ID PMT

unsigned int PlaneID: 5; // ID Piano

unsigned int TowerID: 7; // ID Torre

unsigned int TimeUs: 32; // Tempo assoluto in unita di 500us

unsigned int NDataSample: 6; // Incrementato di 1 e il

numero di campioni nelle DWORD che seguono l’header

unsigned int Dummy: 2; // Non usato

unsigned int Charge: 21; // Flag di saturazione PMT

unsigned int ParityFlag: 1; // Flag Parita

unsigned int FragFlag: 1; // Flag di frammentazione dell’Hit

55

56 Appendice A

in piu DataFrame

unsigned int ZipFlag: 1; // Flag di compressione

};

A tale Header seguono i campionamenti organizzati in DWORD, il che

significa che se NDataSample non e multiplo di 4, alcuni byte dell’ultima

DWORD possono non avere significato.

Quando la TCPU trova un trigger nei dati che analizza, essa determina

l’insieme di hit che formano il candidato evento. In pratica raggruppa tutti i

DataFrame di tutti gli hit dell’evento in una struttura unica, anch’essa dotata

di un header di evento (HeaderE) composto da 8 DWORD:

struct HeaderE{

unsigned int EventTag: 32; // Tag per l’HeaderE = 12081972

unsigned int RecID: 32; // Identificativo univoco e

progressivo dell’evento

unsigned int RecL: 32; // Lunghezza totale dell’evento

in byte

unsigned int NHits: 32; // Numero totale di hits salvati

unsigned int NFrames: 32; // N. di DataFrame che compongono

tutti gli hit

unsigned int TimeUs: 32; // Tempo primo seme in unita’ di

500 us

unsigned int TimeNs: 32; // Tempo primo seme in unita’ di

10 ns

unsigned int PMTon: 16; // Status word dei 16 PMT

unsigned int NTSeed: 16; // Numero di semi di trigger

soddisfatti in questa finestra

};

Prima della sequenza dei DataFrame che compongono l’evento, lo HeaderE

e seguito da tante strutture denominate “TRStatus”, in numero pari a NTSeed.

Ciascuna struttura TRStatus porta in se le informazioni sulle tipologie di

57

di trigger occorsi, e su quali PMT e coinvolto nel seme di trigger. Essa

corrisponde ad 1 DWORD ed e cosı formata:

struct TRStatus{

unsigned int TriggerType: 16; // Codifica del tipo di trigger:

// Coincidenza semplice = 1,

// Coincidenza di Piano = 2,

// ChargeOverThreshold = 3,

// RandomTrigger = 4

unsigned int PMTin: 16; // Status word (bitmask) dei 16 PMT,

da dx->sx (0=NON coinvolto, 1=coinvolto)

};

Tutti gli eventi che l’EventManager organizza in un solo output file sono

preceduti da un header Generale (HeaderG). Esso racchiude in se, oltre ad al-

cune informazioni che descrivono gli eventi registrati nel file, tutti i parametri

sensibili relativi allo status dell’esperimento al momento dell’acquisizione e

a cui corrispondono gli eventi registrati.

La struttura dell’HeaderG e la seguente:

typedef struct HeaderG{

unsigned int HGenTag: 32; // Tag per l’Header Generale

unsigned int HGenL: 32; // size totale dell’HeaderG in bytes

unsigned int nidFile: 32; // ID progressivo del file

PostTrigger prodotto

unsigned int nRecords: 32; // numero di Eventi contenuti

nel file

unsigned int nWrapSinceRunStart: 32; // numero di wrap di

TimeUs [500 us] da inizio run

unsigned int firstFrameTimeUs: 32; // Tempo assoluto del

primo DataFrame in unita di 500 us.

unsigned int fileDuration: 32; // Lasso temporale in cui

occorrono gli eventi nel file in unita di ms

58 Appendice A

DataCard datacard; // Struttura con i parametri sensibili che

identificano lo status dell’acquisizione.

};

Il dettaglio della struttura “DataCard” e riportato di seguito:

typedef struct DataCard{

unsigned int npt: 32; // numero massimo di pmt

unsigned int npmtfl: 32; // numero di pmt per piano

unsigned int floorMASK: 32; // maschera binaria dei piani

(1 attivo,0 non attivo)

unsigned int pmtMASK: 32; // idem per i pmt

(in numerazione assoluta)

unsigned int DUMMY0: 32; // non usato







unsigned int RTP: 32; // ricorrenza del Random Trigger

Period [500us]

unsigned int RTDTA: 32; // durata del Random Trigger [10ns]

unsigned int DTA: 32; // minima meta larghezza della finestra

temporale [10ns]

unsigned int DELCO: 32; // ritardo massimo per coincidenze

semplici [10ns]

unsigned int DELCP: 32; // ritardo massimo per coincidenze

di piano [10ns]

unsigned int NQFRAMES: 32;

59

unsigned int TQ[NMAXPMT]; // PMT Q Threshold * 1000

unsigned int PED[NMAXPMT]; // PMT pedestal * 1000

unsigned int TOFF[NMAXPMT]; // PMT Time offset * 1000

unsigned int run_number: 32; // numero iniziale di file

unsigned int runGPS_startTime: 32; // tempo d’inizio del run

(approssimativo) formato ymmddhhpp

unsigned int DUMMY7 :32; // non usato

unsigned int ofile_size :32; // massima dimensione del file di

output [byte]

unsigned int Qhitmin :32; // soglia minima di accettazione per

un hit per partecipare ad un trigger [adc units]

unsigned int DUMMY8:32; // non usato

unsigned int StartGPSPartH:32; // byte piu significativi

(i primi 4) del tempo GPS in [500us] dell’inizio acquisizione

unsigned int StartGPSPartL:32; // byte meno significativi

(gli ultimi 4) del tempo GPS dell’inizio acquisizione

};

La struttura del file PostTrigger prodotto dall’Event Manager e schematica-

mente riportata nella Figura A.1:

60 Appendice A

Figura A.1: Struttura del file PostTrigger.

Bibliografia

[1] Angela V. Olinto, Highest Energy Cosmic Rays, Astro-ph / 0410685v1,

2004

[2] Christopher Van Eldik, The H.E.S.S. view of the galactic Centre

Region, Nucl. Instr. and Math A 588 (2008) 72-75

[3] Tommaso Chiarusi, Status Report of the NEMO experiment, 2008

[4] Tommaso Chiarusi, Architettura di Trigger per NEMO-Fase2, 2008

[5] M. F. Letheren, “Switching techniques in data acquisition systems for

future experiments”, 1995 CERN School of Computing

[6] Bjarne Stroustrup, The C++ Programming Language,

Addison-Wesley, 1986

[7] Bruce Eckel, Thinking in C++, 2nd Edition, 2003

[8] Qt Cross-Platform Application Framework,

http://trolltech.com/products/qt

[9] Meta-Object System, http://doc.trolltech.com/4.3/metaobjects.html

[10] ROOT an Object-Oriented Data Analysis Framework,

http://root.cern.ch

[11] Qt-based ROOT implementation for Unix,

http://root.bnl.gov/QtRoot/QtRoot.html

61

62 BIBLIOGRAFIA

[12] V. Maslennikov et al. CASPUR,

http://afs.caspur.it/temp/ControlHost.pdf

[13] W3C, http://www.w3.org/XML/

[14] qmake manual, http://doc.trolltech.com/4.3/qmake-manual.html

[15] GNU Make, http://www.gnu.org/software/make/

[16] Mendel Cooper, Advanced Bash Scripting Guide, The Linux

Documentation Project, 2007

Conclusioni e sviluppi futuri

L’obiettivo di questa tesi e stato quello di sviluppare un sistema di vi-

sualizzazione degli eventi raccolti in tempo reale o scritti su file dal sistema

di acquisizione dati (DAQ) dell’esperimento NEMO. Lo scopo e stato rag-

giunto attraverso la produzione del software Event Display. Esso offre una

duplice funzionalita: puo essere utilizzato offline per analizzare i dati salvati

sui cosiddetti file PostTrigger, producendo statistiche e disegnando grafici

riassuntivi dei dati acquisiti, in modo da caratterizzare qualitativamente e

quantitativamente i comportamento del rivelatore in un determinato perio-

do di funzionamento; in modalita online, Event Display consente la visualiz-

zazione delle stesse informazioni mostrate offline ma questa volta ogni evento

singolarmente, via via che il sistema di acquisizione li seleziona e li trasmette

tramite rete.

Event Display e un programma desktop dotato di un’interfaccia grafica,

disegnata per essere la piu semplice possibile. Questo e un aspetto molto

importante, in quanto il programma sara usato sia da utenti esperti, i re-

sponsabili dell’acquisizione dati dell’esperimento, ma anche da personale non

specializzato, gli shifter, che dovranno controllare continuamente il telescopio

durante i turni in sala controllo.

Event Display si e gia rilevato uno strumento efficace per analizzare i

rawdata acquisiti durante NEMO Fase-1. Questi stessi, opportunamente

manipolati, sono anche stati utilizzati per testare le funzionalita di Event

Display online, in attesa del completamento del sistema di DAQ per NEMO

Fase-2.

63

64 BIBLIOGRAFIA

Un aspetto importante dell’architettura su cui si basa Event Display e la

sua modularita. Questo permette la facile integrazione di ulteriori moduli

dedicati all’analisi dei dati, qualora fossero necessarie nuove elaborazioni per

la produzione di statistiche supplementari. Ad esempio, per raffinare ulte-

riormente i dati acquisiti, potrebbero essere integrati opportuni moduli di

Event Display per l’applicazione di algoritmi di trigger di livello successivo

a quelli gia implementati nel sistema di acquisizione online. Inoltre sarebbe

possibile implementare un modulo per una prima ricostruzione approssima-

tiva delle quantita fisiche rilevanti in un evento selezionato, come la direzione

e l’energia associate a una traccia.

Ringraziamenti

Un sistema di visualizzazione On-Line dei dati acquisiti ... · ed elaborare in tempo reale una...

Documents

Transcript of Un sistema di visualizzazione On-Line dei dati acquisiti ... · ed elaborare in tempo reale una...