UNIVERSITA’ DEGLI STUDI DI BOLOGNA

Facoltà di Scienze Matematiche, Fisiche e Naturali Corso di Laurea Specialistica in Fisica

STUDIO DEGLI EFFETTI DEL RUMORE CORRELATO SUL

TRIGGER PER MUONI A GRANDE ANGOLO

NELL’ESPERIMENTO CMS

Autore: Dott. Daniele Fasanella

Relatore: Chiar.mo Prof. Antonio Maria Rossi Correlatori: Dott.ssa Francesca Romana Cavallo Dott. Riccardo Travaglini

Anno Accademico 2006-2007 III Sessione

2

Indice Introduzione................................................................................................................. 1 CAPITOLO 1 L’esperimento CMS a LHC........................................................................................ 3

1.1 Il Large Hadron Collider......................................................................................................3 1.2 La Fisica a LHC ...................................................................................................................4

1.2.1 Sezioni d’urto e rates....................................................................................................5 1.2.2 Il bosone di Higgs del Modello Standard.....................................................................6

1.3 L’esperimento CMS.............................................................................................................9 1.3.1 I Rivelatori in CMS....................................................................................................10 1.3.2 Le camere di tubi a deriva del Barrel.........................................................................12

CAPITOLO 2 Sistema di Trigger e Acquisizione Dati ................................................................... 16

2.1 Introduzione .......................................................................................................................16 2.1.1 Il sistema di Trigger ...................................................................................................16 2.1.2 Sistema di Acquisizione Dati.....................................................................................18

2.2 Sistema di Trigger e Acquisizione dati per le DT.............................................................19 2.3 Il Trigger locale per le camere a deriva (DTBX)...............................................................20

2.3.1 Il Bunch and Track Identifier.....................................................................................21 2.3.2 Il Track Correlator .....................................................................................................22 2.3.3 Il sistema Trigger Server............................................................................................23

2.4 Il sistema di Trigger regionale per i tubi a deriva ..............................................................24 2.4.1 Il Sector Collector ......................................................................................................24 2.4.2 Drift Tube Track Finder.............................................................................................25 2.4.3 Drift Tubes Muon Sorters ..........................................................................................27

2.5 Sistema di Read-Out per le DT..........................................................................................27 2.5.1 Read-Out Board .........................................................................................................27 2.5.2 Dispositivi Read-Out Server ......................................................................................29

CAPITOLO 3 Analisi del rumore correlato nei dati acquisiti durante il Commissioning.......... 30

3.1 Introduzione .......................................................................................................................30 3.2 Attività di Commissioning .................................................................................................31 3.3 Run di cosmici e Technical Trigger...................................................................................32 3.4 Software di simulazione, ricostruzione e selezione di CMS..............................................35 3.5 Caratteristiche dei dati utilizzati ........................................................................................36 3.6 Proprietà spaziali e temporali del rumore per singolo settore............................................37 3.7 Correlazioni spaziali negli eventi di rumore per il singolo settore ....................................46 3.8 Tipologie di eventi e relativi rates......................................................................................49 3.9 Il rumore in più settori .......................................................................................................52

3

CAPITOLO 4 Comportamento del Trigger in presenza di rumore.............................................. 55

4.1 Descrizione delle variabili analizzate e loro distribuzioni per eventi in assenza di rumore 55 4.2 I dati di Trigger negli eventi di rumore..............................................................................59

4.2.1 Run 15278 Settore 12 Wheel 0 ..................................................................................59 4.2.2 Run 17819 settore 4 wheel 1......................................................................................62 4.2.3 Run sul Settore 12 Wheel -1 ......................................................................................65 4.2.4 Osservazioni Generali sui dati di Trigger ..................................................................66

4.4. Emulazione e rumore .........................................................................................................67 4.5 Ricostruzione di “tracce” di Trigger ..................................................................................70 4.7 Ipotesi sull’origine del rumore correlato............................................................................74

Conclusioni................................................................................................................. 76 Indice delle Figure ..................................................................................................... 78 Indice delle Tabelle.................................................................................................... 80 Bibliografia................................................................................................................. 82

4

Introduzione Il Large Hadron Collider (LHC) è il nuovo acceleratore adronico realizzato presso il CERN di Ginevra che produrrà collisioni protone-protone con energia nel centro di massa di 14 TeV. Ciò renderà possibile indagare una nuova scala di energia, ricercando sia una verifica sperimentale dell’esistenza del bosone di Higgs previsto dal Modello Standard delle interazioni elettrodeboli, sia processi originati da nuova fisica. LHC entrerà in funzione per una prima fase di test nel Giugno del 2008 e i primi risultati sperimentali sono previsti nel corso del 2009. Il rivelatore CMS (Compact Muon Solenoid) è appositamente progettato per la ricerca di nuove particelle. Esso è composto da una serie di sottorivelatori in grado di ricostruire le tracce delle diverse particelle prodotte in ogni evento. CMS è stato progettato per ottimizzare la rivelazione di leptoni a alto impulso, firma caratteristica di processi derivanti da nuova fisica. In particolare i muoni a grande angolo rispetto alla direzione del fascio verranno rivelati tramite l’uso di un sistema di camere di tubi a deriva (DT). Vista la grande luminosità prevista a LHC (1034 cm-2s-1), l’elevato numero di particelle prodotte in una collisione adronica e considerando che i processi di nuova fisica avranno sezioni d’urto di almeno 10 ordini di grandezza inferiori a quella totale, è fondamentale la presenza di un sistema di Trigger per selezionare gli eventi interessanti per l’archiviazione e la successiva analisi. In CMS tale sistema è suddiviso in due fasi: il Trigger di Livello 1, realizzato con un’apposita elettronica, e il Trigger di alto livello, sviluppato con programmi software eseguiti da processori commerciali. Il Trigger di Livello 1 è in grado di elaborare i dati a ogni incrocio dei fasci in modo sincrono e senza tempo morto. In vista dell’imminente inizio delle attività di LHC l’esperimento è sottoposto a una attività di messa a punto e verifica delle prestazioni, che va sotto il nome di commissioning. Parte di questa attività utilizza la presenza dei muoni originati dai raggi cosmici per avere una sorgente di particelle rivelabili dall’apparato. Nel corso dei test effettuati sul sistema DT utilizzando muoni cosmici è stata rilevata la presenza di un tipo particolare di rumore caratterizzato da un elevato numero di tubi di deriva che davano segnale simultaneamente. Il lavoro di tesi è stato incentrato sullo studio di questo tipo di rumore al fine di valutare il suo impatto sul funzionamento del sistema di Trigger e Acquisizione dati dell’esperimento. Dato che tale rumore genera segnali correlati nello spazio e nel tempo, ho ricercato con quale rate fosse in grado di generare Trigger. In particolare si è voluto verificare che il rate non fosse dell’ordine di grandezza del segnale prodotto dalle particelle ricercate (muoni o coppie di muoni), nel qual caso avrebbe potuto sia mascherare il segnale fisico sia elevare il rate di acquisizione oltre i limiti del sistema. Ho sviluppato un programma utilizzando il software di ricostruzione e simulazione dell’esperimento (CMSSW), con il quale ho analizzato i dati raccolti durante le sessioni di commissioning svoltesi fra l’Aprile 2007 e il Febbraio 2008 studiando in modo approfondito le modalità e la frequenza con cui si verificava questo tipo di rumore. Il software sviluppato potrà essere utilizzato in futuro per monitorare il rumore all’interno dell’esperimento quando funzionerà ad LHC. Nel capitolo 1 sarà presentato l’acceleratore LHC e il rivelatore CMS. Nel capitolo 2 verrà descritto il sistema di Trigger e Acquisizione dati per muoni, descrivendo in particolare le loro componenti

1

locali sviluppate per le DT. Il Capitolo 3 è dedicato alla descrizione delle caratteristiche del rumore utilizzando le informazioni raccolte dall’Acquisizione dati. In particolare sono illustrate le caratteristiche topologiche e temporali del rumore, con particolare attenzione alle correlazioni al fine di individuarne le cause. E’ inoltre descritto lo studio sul rate con cui si presenta il rumore, effettuato su un ampio campione di dati raccolti durante il commissioning. Infine il Capitolo 4 è dedicato all’analisi del comportamento del sistema di Trigger in presenza di rumore. Tale analisi è stata realizzata sia utilizzando i dati prodotti dall’elettronica durante le sessioni di commissioning sia tramite l’uso di un emulatore, al fine di poter dare una valutazione dell’impatto di questo problema sul funzionamento di CMS a LHC.

2

Capitolo 1

L’esperimento CMS a LHC 1.1 Il Large Hadron Collider Il Large Hadron Collider (LHC) è il nuovo acceleratore adronico realizzato al CERN di Ginevra all’interno del tunnel di 27 Km che ospitava precedentemente il collisionatore e+e- LEP. Attualmente è in fase di test in quanto la prima attivazione è prevista a Giugno del 2008, mentre i primi risultati di fisica sono attesi nel corso del 2009. LHC è stato progettato per ampliare gli orizzonti della fisica delle particelle producendo collisioni protone-protone con energia nel centro di massa di 14 TeV. Questa elevata energia è ottenibile grazie alla scelta di far collidere fasci di protoni anziché elettroni, minimizzando così la perdita di energia per irraggiamento, che e’ proporzionale all’inverso della massa della particella elevato alla quarta potenza. D’altra parte la scelta di adroni implica una sezione d’urto totale (σtot) molto elevata, rendendo necessario un sistema di selezione degli eventi per studiare i processi fisici interessanti (vedi Paragrafo 1.2.1) caratterizzati da σ<<σtot. Inoltre la necessità di produrre un sufficiente numero di eventi anche per processi con piccola sezione d’urto, ha fatto sì che una delle principali caratteristiche dell’acceleratore LHC sia un’elevata luminosità. Infatti, mentre ad esempio al Tevatron presso il FermiLab la luminosità raggiungeva il valore L=1032cm-2s-1, ad LHC raggiungerà il valore di L=1034 cm-2s-1, con un periodo iniziale in cui la luminosità sarà L=1033 cm-2s-1. Le collisioni avverranno ogni 25 ns, ovvero con una frequenza di 40 MHz (frequenza di bunch crossing – BX). In Tabella 1 e’ riportato un riassunto dei principali parametri funzionale di LHC.

Figura 1 Rappresentazione schematica di LHC e dei 4 apparati sperimentali.

3

Circonferenza 26.659 Km Massima luminosità ~ 1034 cm-2 s-1 ⇔ 10 Hz/nb Vita media dei fasci alla massima luminosità ~ 10 h Campo di dipolo all'iniezione 0.535 T Campo di dipolo all'energia massima 8.33 T Radio Frequenza 400.790 Hz Tempo di accelerazione 20 min. Energia del fascio all'iniezione 450 GeV Energia del fascio alla collisione 7 TeV Numero di pacchetti 2835 Protoni per pacchetto alla massima L ~1011

Spazio tra i pacchetti 7.48 m ⇔ 25 ns Frequenza di BX 40 MHz Dim. trasverse del fascio 0.303 × 0.303 mm2

Dim. trasverse del fascio alla collisione 15.9 × 15.9 µm2

Lunghezza del pacchetto 7.5 cm (0.25 ns) Fattore relativistico (all'iniezione) 479.6 Fattore relativistico (alla collisione) 7460.6 Frequenza di rivoluzione dei pacchetti 11.2455 kHz Energia acquistata per rivoluzione 489 KeV Energia persa per rivoluzione 6.7 KeV Vita media del fascio ~ 22 h

Tabella 1 Principali parametri funzionali di LHC

Oltre ai protoni, la macchina é stata progettata anche per produrre collisioni fra ioni pesanti, ad esempio Piombo-Piombo, ad un'energia nel centro di massa di 1150 TeV (2,76 Tev per nucleone) con una luminosità pari a 1027 cm-2s-1. I fasci di particelle di LHC viaggeranno in direzioni opposte in 2 condutture separate e collideranno in 3 punti di intersezione. Sono previsti 4 rivelatori: CMS, ATLAS, ALICE ed LHCb, la cui disposizione è mostrata in Figura 1. ATLAS e CMS sono rivelatori appositamente progettati per la ricerca di nuove particelle, mentre ALICE e LHCb sono rispettivamente specializzati nella fisica degli ioni pesanti (plasma di quark e gluoni) e fisica del quark bottom (violazione di CP).

1.2 La Fisica a LHC Numerosi sono i campi di indagine per gli esperimenti a LHC:

Ricerca del bosone scalare previsto dal modello standard delle interazioni elettrodeboli denominato Bosone di Higgs (HMS). La sua esistenza è richiesta dalla teoria mediante il meccanismo di rottura spontanea di simmetria che permette ai bosoni vettori intermedi W± e Z0 di acquisire massa.

Misure di precisione del modello standard, quali la massa del quark top o studio della violazione della simmetria CP nei mesoni contenenti il quark bottom.

Ricerca di nuova fisica oltre il modello standard. Le energie raggiunte permetteranno di escludere l’esistenza di altre famiglie di quark o leptoni non previste dalla teoria, o di verificare altri modelli teorici come le teorie Supersimmetriche.

4

1.2.1 Sezioni d’urto e rates I fenomeni fisici previsti a LHC hanno sezioni d’urto diverse per numerosi ordini di grandezza, come mostrato in Figura 2. La sezione d’urto totale elastica attesa a s = 14 TeV è di circa 70 mb. Una gran parte delle interazioni sono di tipo chiamato di “minimum bias”, dove il momento traverso scambiato fra i due protoni è piccolo e nella collisione sono prodotte particelle a piccoli angoli rispetto alla direzione dei fasci che collidono. Gli eventi interessanti provengono dalle collisioni frontali, dove il momento trasferito e’ grande e in cui si ha la creazione di particelle con alto impulso nel piano trasverso rispetto alla direzione dei fasci (impulso trasverso, PT).

Figura 2 Sezioni d’urto per diverti processi fisici a LHC

In un collisionatore di protoni come LHC gli eventi con alto PT sono dominati dalla produzione di jets originati dalla frammentazione di adroni. Gli stati finali nei quali sono prodotti leptoni e fotoni sono maggiormente interessanti, nonostante sezioni d’urto minori, in quanto i processi fisici di interesse sono più facilmente isolabili dal fondo. Quindi i fotoni e i leptoni con grande impulso traverso hanno un ruolo cruciale nella selezione degli eventi per un esperimento di LHC.

5

1.2.2 Il bosone di Higgs del Modello Standard Il Modello Standard elettrodebole è la teoria che descrive con maggiore successo le interazioni fra i componenti della materia alle dimensioni più piccole (≤ 10-18 m) e alle più alte energie (∼200 GeV) accessibili con gli strumenti attuali. E’ una teoria di campo quantistico che descrive le interazioni di fermioni con spin ½ (quark e leptoni) mediate da bosoni di gauge con spin 1. L’esistenza del bosone di Higgs è la più importante predizione del Modello Standard che non sia stata ancora verificata sperimentalmente. La sua presenza è richiesta in quanto l’invarianza di gauge introdotta nella teoria implica che i bosoni di spin 1 abbiano massa nulla. Quindi, per avere un modello teorico in cui i bosoni abbiano massa, come osservato sperimentalmente, si assume che le diverse particelle interagiscano con un nuovo tipo di campo scalare, il campo di Higgs. L’esistenza di questo campo ha vari effetti:

provoca la cosiddetta “rottura spontanea di simmetria”, che fa sì che nella teoria elettrodebole i bosoni vettori intermedi W± e Z0 acquisiscano massa, a differenza del fotone;

permette alla teoria di descrivere le interazioni fra particelle (quark e leptoni) con massa non nulla;

porta all’esistenza di un quanto elettricamente neutro H0 associato al campo, chiamato bosone di Higgs.

Nel modello standard la massa dell’Higgs è un parametro libero ricavabile esclusivamente dalla sua misura sperimentale. Un limite inferiore alla massa si è ottenuto tramite ricerca diretta a LEP [ ]1 ed è:

C.L.)(95%Gev114.4mMSH > .

D’altra parte, un limite superiore per la massa dell’Higgs proviene da un’accurata misura dei parametri elettrodeboli, le cui correzioni radiative sono fortemente sensibili a log( )

MSHm [ ]2

C.L.)(95%Gev212mMSH <

anche se un Higgs più massivo potrebbe essere compatibile con modelli più generali, quali le teorie Supersimmetriche. Lo scopo di LHC è quindi quello di ottenere energie in grado di produrre il bosone di Higgs e i rivelatori sono stati realizzati in modo da coprire intervallo di valori da ~90 GeV a ∼1 TeV

MSHm [ ].3

I principali diagrammi di Feynman che descrivono la produzione di Higgs a LHC sono riportati in Figura 3. Come si può notare dalla Figura 4 a LHC il processo dominante sarà mediante fusione di gluoni (g+g→H0 in Figura 3), mentre solo per ~ 0,7 Tev quello mediante fusione di W

MSHm ± e Z0 (q q → Hq q in Figura 4) diventa comparabile ed è identificabile grazie alla presenza di due energetici jet di adroni nello stato finale.

Figura 3 Diagrammi di Feynman per i processi di produzione di Higgs a LHC

6

Figura 4 Sezioni d’urto per la produzione di H0 in funzione della sua massa

Per individuare eventi con produzione di bosoni di Higgs è necessario conoscere i possibili canali di decadimento, i cui stati finali sono osservati dai rivelatori. I rapporti di decadimento (branching ratio) dei diversi canali dipendono dalla massa del bosone di Higgs prodotto, come mostrato in Figura 5.

Per mH <120 GeV il canale di decadimento dominante è H→b b , ma il segnale è difficilmente distinguibile a causa dei processi di fondo, che rendono complicata una precisa identificazione dei due jet di particelle prodotti dall’adronizzazione dei due quark b e b . Quindi il canale più promettente è H→γγ, che, nonostante il minore branching ratio, permette una efficiente selezione rispetto ai processi di fondo grazie al caratteristico stato finale costituito da due fotoni isolati con E ≈ 50 GeV. Quindi un’efficace selezione di processi di produzione del bosone di Higgs a questa energia richiede ottime prestazioni da parte del calorimetro elettromagnetico.

Figura 5 Rapporto di decadimento in funzione di MH

7

Per masse maggiori di 120 GeV il canale più interessante è H→ZZ(*)→4l (con l=leptone

carico, e± o µ±) che può essere osservato a LHC quando mH è compreso tra 120 e 700 GeV (è da ricordare che per mH< 2 mZ una Z è virtuale). Il canale è caratterizzato dalla firma caratteristica di 4 leptoni con grande impulso trasverso, la cui massa invariante è uguale a mH. Inoltre, con l’aumentare della massa la larghezza intrinseca del Bosone di Higgs diventa molto maggiore della risoluzione sperimentale, quindi le caratteristiche del rivelatore non sono cruciali e dovrebbe essere facilmente osservato un picco nella distribuzione delle masse invarianti dei 4 leptoni.

Rispetto al canale precedente H→WW(*)→2l2ν è sempre favorito (a causa della costante di accoppiamento maggiore), ma il segnale, caratterizzato da due leptoni con grande Pt e da un’elevata energia mancante (dovuta ai neutrini), non permette la ricostruzione diretta della massa dell’Higgs. Questo canale rimane comunque importante per l’identificazione del bosone nella fascia di energia 150÷190 GeV, in cui il decadimento in due W reali diventa cinematicamente permesso al contrario di quello in due Z reali. In questo intervallo di energie esso è quindi ulteriormente favorito.

In Figura 6 è infine mostrato il livello di significatività (ovvero il rapporto fra gli eventi di segnale e gli eventi dei processi di fondo) raggiungibile in un anno di funzionamento dell’acceleratore alla massima luminosità in funzione di mH, per diversi canali studiati. E’ evidenziata la soglia 5σ (σ=deviazione standard) , la minima significatività richiesta per la scoperta di nuovi segnali.

Figura 6 Osservabilità del bosone di Higgs in funzione della sua massa a LHC alla luminosità integrata L=105 pb-1

(su un anno di funzionamento).

8

1.3 L’esperimento CMS Il rivelatore CMS (Compact Muon Solenoid) sarà in grado di studiare molteplici processi fisici. E’ stato progettato in particolare per ottimizzare la rivelazione di muoni ed elettroni, firma caratteristica di processi derivanti da nuova fisica. L’esperimento è installato in una caverna sotterranea, è di forma cilindrica, lungo 22 m, con un diametro di 15 m e pesa circa 14000 tonnellate. Le sue principali caratteristiche sono (vedi Figura 7) :

un campo magnetico di 4T realizzato con un magnete superconduttore di forma solenoidale; un sistema centrale di tracciamento di alta qualità (risoluzione di 10-20 µm) che permette

una identificazione delle tracce con alta risoluzione; un calorimetro elettromagnetico, per un’accurata misura delle energie di elettroni e fotoni; un calorimetro adronico ermetico per la misura delle energie di tutti gli adroni prodotti

nell’evento; un sistema di rivelazione di muoni di alta qualità e ridondante, in grado di ricostruire le

tracce dei muoni e misurarne l’impulso nel piano trasversale (Pt).

Figura 7 Spaccato dell’esperimento CMS

In Figura 8 sono mostrate le sezioni longitudinali e trasversali del rivelatore, che illustrano il sistema di coordinate utilizzato. I fasci di protoni a LHC collideranno nel centro del rivelatore e la loro direzione definisce l’asse z. Nel piano trasversale sono utilizzate le coordinate polari r-φ. Invece, lungo il piano longitudinale è usata la pseudorapidità η,definita come:

2θtan-lnη =

dove θ è l’angolo rispetto all’asse z.

9

Figura 8 (a) Vista trasversale della regione del barrel del rivelatore CMS. (b) Vista longitudinale di un quarto

dell’apparato.

Il rivelatore CMS è suddiviso in una zona centrale cilindrica (barrel) segmentata in 5 anelli (wheels) lungo la direzione z, e due dischi alle estremità (endcaps). Le wheels sono numerate definendo quella centrale come wheel 0, e quelle ai due lati rispettivamente -1,-2 e 1, 2. All’esterno del solenoide si trova il rivelatore di muoni, composto da più stazioni di rivelazione, poste nel giogo di ferro che contiene il flusso di ritorno del campo magnetico. Il resto dei rivelatori si trova all’interno del solenoide, a parte due calorimetri adronici (Very forward calorimeters) che sono posti all’esterno degli endcaps. La misura del momento delle particelle cariche è effettuata grazie alla curvatura della traiettoria nel piano r-φ, dovuta al campo magnetico. Nella sezione trasversale presentata in Figura 8 è possibile vedere come questo campo influenza la traiettoria di un muone, la cui misura dell’impulso trasverso può avvenire in 3 modi indipendenti:

con il rivelatore di tracce centrale in base alla curvatura all’interno del magnete con la misura dell’angolo di incidenza sulla stazione più interna del rivelatore di muoni. con la curvatura della traiettoria all’interno del rivelatore muonico.

1.3.1 I Rivelatori in CMS Partendo dal punto di collisione dei fasci e procedendo verso l’esterno si incontrano diversi sottorivelatori (Figura 9): 1. Il rivelatore di tracce centrale (Tracker[ ]4 )

Il suo scopo è individuare con alta efficienza e buona risoluzione particelle cariche dotate di elevato momento trasverso nel range 5.2<η . E’ basato su rivelatori di silicio a pixel e a strisce, ed otterrà una precisione di ∆Pt = 5% e ∆Pt = 1% per particelle con Pt = 1 TeV/c e Pt = 100 GeV/c.

2. Il calorimetro elettromagnetico (ECAL[ ]5 ) Si tratta di un calorimetro omogeneo composto da ~105 cristalli scintillatori di PbWO4, caratterizzati da una veloce risposta temporale (10 ns) e piccolo tempo morto. Questi cristalli sono posizionati sia all’interno del barrel che sugli endcaps, nel qual caso sono preceduti da un rivelatore a strisce di silicio, dette di “preshower”, il cui scopo è di migliorare la determinazione nei punti di impatto di fotoni e di distinguere fra le coppie di fotoni prodotte nelle prime fasi dell’interazione e quelle originatesi in fenomeni successivi, come il decadimento di π0. Questo è fondamentale per migliorare la misura della massa invariante delle coppie di fotoni, fattore cruciale per la rivelazione di bosoni di Higgs tramite il canale H→γγ.

10

Ogni cristallo del barrel è lungo 23 cm e ha una copertura angolare ∆η×∆φ =0.0175 × 0.0175 e la risoluzione energetica di ECAL risulta essere:

EEEE 2.0%55.0%2

⊕⊕≈σ

Figura 9 Spaccato dell’esperimento CMS

3. I calorimetri adronici (HCAL e Very Forward calorimeter)

HCAL è un calorimetro a campionamento realizzato con piani assorbenti di ottone (spessi 50 mm del barrel e 80 mm negli endcaps) intervallati da scintillatori plastici con spessore di 4mm. La segmentazione del rivelatore è ∆η×∆φ =0.087 × 0.087. La risoluzione energetica di HCAL nel barrel è

%5%65⊕≈

EEEσ

mentre negli endcaps è

%5%83⊕≈

EEEσ

Il Very Forward Calorimeter è localizzato oltre il rivelatore di muoni, a circa 12 metri dal punto di interazione, ed è realizzato con assorbitori di acciaio intervallati da fibre di quarzo poste parallelamente alla linea del fascio. La misura di energia è effettuata tramite la luce Čerenkov emessa al passaggio delle particelle cariche, raccolta da un sistema a fibre ottiche che la convoglia ai fotomoltiplicatori posti in aree schermate. L’intero sistema di calorimetri adronici è fortemente ermetico in un’ampia regione (fino a

3.5=η ), quindi insieme alle informazioni date da ECAL permette la ricostruzione dell’energia totale di un evento.

4. Il sistema di rivelazione dei muoni Il rivelatore di muoni[ ]6 è il più esterno di CMS ed è installato nelle intercapedini del giogo di ferro per il ritorno del campo magnetico. Il sistema di rivelazione di muoni consiste di 3 sottosistemi indipendenti, con diverse caratteristiche a seconda della diversa intensità del campo magnetico e del flusso di particelle presenti nelle diverse regioni in cui sono posti.

11

I tubi a deriva (Drift Tube - DT) sono installati all’esterno del magnete nella zona del barrel (η<1.2) dove il flusso di particelle (circa 10 Hz/cm2) e il campo magnetico residuo (minore di 1 Tesla) sono relativamente bassi. Verranno descritti in dettaglio nel paragrafo successivo.

Le camere a strisce catodiche (Chatode Strips Chambers - CSC) sono camere proporzionali a fili (anodi) con catodi segmentati a strisce, che permettono di effettuare misure sia temporali che spaziali. Una particella carica che attraversa uno strato di CSC produce una carica per ionizzazione che viene raccolta da diverse strisce catodiche. Poiché queste strisce sono disposte radialmente, una interpolazione della carica misurata permette una misura della coordinata φ con un’ottima risoluzione. La contemporanea misura del segnale sui fili permette di ricostruire la coordinata ortogonale r. Sono state scelte per la zona frontale degli endcaps (0.9< η<2.1) dove devono operare in regime di grande flusso di particelle (con una frequenza dell’ordine dei KHz/cm2) e in un elevato campo magnetico residuo.

Le camere a piani resistivi (Resistive Plate Chambers -RPC) sono rivelatori gassosi a piani paralleli. Quelle utilizzate in CMS sono formate da 4 piani di bachelite che formano due intercapedini per il gas spesse 2mm. I piani sono ricoperti esternamente di grafite, e costituiscono i catodi ad alta tensione (9.5 KV). Delle strisce di alluminio isolate sono poste esternamente ai catodi di grafite, fra i due interstizi. Quando una particella carica attraversa una RPC produce una valanga che induce un segnale sulle strisce, che rivelano la somma dei segnali fra le due intercapedini. Queste camere sono poste sia nel barrel che negli endcaps in modo da dare affidabilità e ridondanza all’intero sistema. Nonostante abbiano una modesta risoluzione spaziale, sono caratterizzate da un’ottima risoluzione temporale e un tempo di risposta molto rapido; per questo motivo sono utilizzate per l’identificazione della collisione in cui il muone è stato prodotto ed esclusivamente nel sistema di Trigger dell’esperimento (Capitolo 2).

1.3.2 Le camere di tubi a deriva del Barrel Il sistema di camere di tubi a deriva è utilizzato nel rivelatore a muoni del CMS a causa della grande superficie che deve essere coperta. Il sistema è segmentato nelle 5 wheels di CMS lungo la direzione z, ognuna larga circa 2.5 metri, e diviso in 12 settori azimutali, che coprono ognuno 30°. Le camere a deriva sono sistemate in 4 cilindri concentrici (MB 1-2-3-4 in Figura 8), chiamati stazioni, a differenti distanze dal punto di collisione dei fasci e separate dal giogo di ferro. Ogni stazione consiste di 12 camere, con l’eccezione della quarta dove i settori superiori ed inferiori sono equipaggiati con due camere ciascuno (anziché una), portando il numero totale a 14 camere per stazione. L’intero rivelatore CMS è quindi equipaggiato con un totale di 250 camere di tubi a deriva, le cui dimensione dipendono dalla stazione. Ogni camera è sfasata azimutalmente rispetto a quella precedente più interna, per massimizzare l’accettanza geometrica. L’elemento di base del sistema di rivelazione è il tubo a deriva, la cui sezione trasversale, chiamata cella è mostrata in Figura 10.

12

Figura 10 Visione trasversale di una cella di un tubo a deriva, mostrate le linee di deriva isocrone per una tipica configurazione di voltaggio degli elettrodi

Ogni cella ha dimensioni trasverse 42 mm × 13 mm e contiene un anodo di acciaio inossidabile rivestito d’oro del diametro di 50 µm e lunghezza variante fra i 2 e i 4 metri. Uno strato di celle è ottenuto da due piani di alluminio paralleli, all’interno dei quali una serie di componenti di alluminio a forma di “I” (I-beams), spesse 1.2 mm e alte 9.6 mm, definiscono i bordi delle celle adiacenti. Le strisce di alluminio, depositate su entrambe le facce di ogni I-beam, e isolate da esso tramite un nastro di Mylar, servono da catodi. I fili anodici e i catodi sono posti rispettivamente a un voltaggio positivo e negativo e forniscono il campo elettrico all’interno della cella. La distanza fra il punto di passaggio della particella e il filo è misurata dal tempo di deriva degli elettroni di ionizzazione secondo la formula:

t0 t u x(t)

= tempo di arrivo della particella = tempo in cui l’impulso appare sull’anodo = velocità di deriva funzione del punto = distanza dall’anodo a cui è passata la particella

∫=t

tudttx

0

')(

Allo scopo che u risulti circa costante in ogni punto all’interno del volume della cella, il campo elettrico deve essere uniforme e a questo scopo sono state montate due strisce addizionali di alluminio caricate positivamente su entrambe le facce dei piani di alluminio (schermate con un isolatore) al centro della cella stessa, in corrispondenza del filo anodico. Le tensioni tipiche sono +3600 V, +1800 V, -1800 V rispettivamente per i fili, le strisce e i catodi. Molto importante per i rivelatori a ionizzazione è la scelta dei gas utilizzati. Per le camere a deriva posizionate nel barrel di CMS è stata scelta una miscela composta di Argon (80%) e CO2 (20%). L’argon è una scelta tipica per gli apparecchi a ionizzazione , in quanto caratterizzato da un’elevata ionizzazione specifica (numero medio di coppie ione-elettrone create al passaggio di una particella per unità di lunghezza), una bassa intensità del campo elettrico per la formazione di valanghe (il che permette di scegliere un punto di lavoro, determinato dalle tensioni sugli elettrodi, inferiore rispetto ad altri gas) e un basso costo. L’unico lato negativo è che l’Argon puro permette un guadagno limitato senza dare origine a scariche continue, in quanto durante il processo a valanga tende a emettere fotoni i quali possono estrarre fotoelettroni dal catodo e che possono dare origine ad ulteriori valanghe. Per evitare questo effetto, occorre introdurre gas che assorbano i fotoni (detti quenchers) e dissipino l’energia in forme diverse, quali stati dissociati o vibrazionali. A questo scopo è stato scelto un gas inorganico, che a differenza di quelli organici è meno efficiente ma mantiene le sue caratteristiche inalterate nel tempo e non dà problemi di manutenzione dello strumento anche dopo anni di utilizzo. La CO2 è una scelta comune a questo scopo tenendo anche conto che la sua miscela con l’Argon non è infiammabile. Il modulo fondamentale per la rivelazione e misura del Pt dei muoni è la camera di muoni, una cui visione trasversale è riportata in Figura 11, insieme a una fotografia di una camera dopo il suo assemblaggio.

13

Figura 11 Sezione schematica di una camera a muoni del barrel (sulla sinistra) e sua foto (sulla destra).

I tubi a deriva sono assemblati in piani (layers), il numero delle celle dipende dalla dimensione della camera. Quattro layers sono assemblati assieme per formare un quadrupletto chiamato super-layer (SL) con i ripiani confinanti sfasati di mezzo tubo, permettendo di risolvere l’ambiguità destra-sinistra della singola cella. Ogni stazione DT è composta di 3 super-layers, due dei quali sono dedicati alle misure di posizione nel piano di curvatura r-φ (fili paralleli alla linea del fascio), e uno per la misura della coordinata z nel piano longitudinale θ-z (fili perpendicolari alla direzione z), con unica eccezione la stazione più esterna MB4 alla quale manca il SL per la visione θ. Inoltre, come mostrato in Figura 11, all’interno di ogni camera si trova una struttura di alluminio a nido d’ape (Honeycomb plate) che funge da spaziatore leggero ma rigido ed è posta fra il SL φ interno e quelli esterni. Il suo scopo è allontanare maggiormente i due super-layer che effettuano le misure sul piano di curvatura, in modo da migliorare la risoluzione angolare. L’efficienza di identificazione di muoni da parte del sistema sarà superiore al 99%. Inoltre la risoluzione finale ottenibile è di ~ 150-200 µm per il punto di impatto del muone per ogni camera, mentre per quanto riguarda la misura di Pt nel barrel l’andamento è mostrato in Figura 12. Per tracce con Pt fino a 100 Gev la risoluzione risulta quasi costante in η fino a η=1.5, in quanto le tracce in questa regione hanno attraversato l’intero raggio del solenoide sentendo l’intero effetto del campo magnetico. A causa dello scattering multiplo anche se la risoluzione delle camere fosse superiore non ci sarebbe un significativo miglioramento della risoluzione sull’impulso.

Figura 12 Risoluzione dell’impulso per tracce di muoni simulati a valori selezionati di Pt utilizzando unicamente hits

dai rivelatori di muoni e la condizione di passaggio dal vertice.

Utilizzando anche le informazioni del tracker sarà possibile raggiungere le risoluzioni mostrate in Figura 13, dove si nota un miglioramento di quasi un ordine di grandezza.

14

Figura 13 Risoluzione dell’impulso per tracce di muoni simulati a valori selezionati di Pt utilizzando hits dai

rivelatori per muoni combinati con gli hits rilevati dal tracker.

15

Capitolo 2 Sistema di Trigger e Acquisizione Dati 2.1 Introduzione Il sistema di Trigger e Acquisizione dati[ ]7 è una parte essenziale di un esperimento in un acceleratore adronico. Con una frequenza di interazione di 40 MHz e alla luminosità finale di 1034cm-2s-1, sono previsti mediamente 17 eventi per incrocio dei fasci, che producono circa 1 Mb di dati ciascuno, per un rate finale di decine di Terabyte al secondo. Questo rate è di molti ordini di grandezza superiore alle possibilità di acquisizione su supporto fisso, che è dell’ordine di 100 Mb/s a 100 Hz. Il Trigger è stato strutturato per analizzare le informazioni provenienti dal sistema di Front End del rivelatore alla sua frequenza di funzionamento e di selezionare gli eventi fino a un rate di 100 Hz rendendoli poi disponibili al sistema di acquisizione che immagazzinerà i dati in un formato opportuno per l’analisi. 2.1.1 Il sistema di Trigger Lo scopo del sistema di Trigger del CMS è di ridurre il rate dei dati a un livello accettabile, selezionando gli eventi di interesse fisico. Questo richiede una riduzione del flusso delle informazioni dell’ordine di 105, che non è possibile ottenere in un’unica fase. A questo scopo il sistema di Trigger nell’esperimento CMS ha la struttura riportata in Figura 14.

Figura 14 Flusso dei dati nel sistema di Trigger di CMS.

16

Le due parti in cui è suddiviso il processamento sono: • Livello 1

Il Trigger di livello 1 è basato su dispositivi elettronici appositamente progettati ed elabora i dati ad ogni BX al fine di ridurre il tasso di eventi fino a un massimo di 100 KHz. Siccome nessuna decisione può essere presa in 25 ns, tutti i dispositivi di Trigger lavorano in serie, ovvero ogni elemento esegue il proprio compito in 25 ns e trasmette il risultato all’elemento successivo (pipeline processing). Per questo motivo il sistema di Trigger è costituito da dispositivi elettronici sincroni che operano a una frequenza di riferimento (data da un segnale di clock) di 40 Mhz. Il tempo totale di latenza per il livello-1 è limitato dalla necessità di mantenere tutte le informazioni del rivelatore fino a quando non viene presa una decisione. A causa dei buffer utilizzati questo limite temporale è di 3.2 µs. Il Trigger di livello 1 realizza la rapida ricostruzione di oggetti singoli (tracce di muoni, jet adronici) e misura le loro proprietà fisiche (come l’impulso traverso). E’ in grado di ricostruire variabili, come l’intera energia nel piano trasversale immagazzinata in un calorimetro, l’energia mancante (ovvero la differenza fra l’energia misurata nei rivelatori rispetto a quella nel punto di collisione), il numero totale di elettroni o muoni, sui quali poi vengono applicate delle condizioni di selezione. Questo è uno dei punti fondamentali nel sistema di Trigger in quanto la scelta di opportune condizioni deve essere studiata per ottenere la massima efficienza e purezza nella selezione dei processi fisici da studiare. La struttura del Trigger di livello-1 per il CMS è riportata in Figura 15.

Figura 15 Schema del sistema di Trigger di livello 1

• Trigger di alto livello (High Level Trigger, HLT)

I Trigger di alto livello sono implementati da processori commerciali che eseguono algoritmi di selezione sugli eventi selezionati dal Livello 1, utilizzando i dati acquisiti dal sistema di Read-Out. Anche in questo caso l’analisi avviene per passi successivi, passando i dati attraverso diversi filtri di Trigger. Lo scopo è selezionare gli eventi fino a un rate massimo di 100 Hz in modo da permettere al sistema di acquisizione di CMS di immagazzinare i dati in maniera permanente.

17

Gli obiettivi del Trigger di muoni di Livello-1 sono l’identificazione dei muoni con la massima efficienza, la misura di Pt e l’assegnazione del muone rivelato al BX in cui è stato prodotto. Inoltre molti eventi fisici di interesse producono coppie di muoni anche molto vicine nello spazio (come quelli prodotti nel decadimento di J/ψ) ed è quindi importante una buona efficienza di rivelazione per muoni che attraversino anche la stessa camera nello stesso BX. Allo stesso tempo dovrà essere ridotta al minimo la percentuale di falsi muoni generati dall’algoritmo di ricostruzione. La struttura del Trigger per muoni è riportata in Figura 16. Come si può notare per CSC e DT si possono distinguere essenzialmente due parti:

Trigger locale che ha lo scopo di ricostruire il passaggio dei muoni nella singola stazione e la cui elettronica è posta all’interno dell’esperimento CMS;

Trigger regionale che ricostruisce l’intero passaggio del muone all’interno del rilevatore ed effettua la selezione degli eventi migliori. La sua elettronica è situata in opportune stazioni in una sala sperimentale adiacente a quella del rivelatore.

Figura 16 Schema del sistema di Trigger dei muoni.

2.1.2 Sistema di Acquisizione Dati Gli obiettivi dell’acquisizione dati (DAQ) in CMS sono: • La lettura di tutta l’elettronica di Front End dopo la ricezione di un Trigger di primo livello

(Level-1 Accept, L1A) • La raccolta delle informazioni di ogni BX in un’unica struttura di dati • L’invio delle informazioni ottenute ai processori dedicati agli HLT • L’invio degli eventi accettati al Sistema di Calcolo online che include anche

l’immagazzinamento dei dati su supporto fisso

L’architettura del sistema DAQ di CMS è mostrato in Figura 17.

18

Figura 17 Architettura del sistema DAQ di CMS

Per ottenere gli obiettivi sopra elencati la DAQ è composta dalle seguenti parti: • Front End del detector: moduli che immagazzinano i dati dal detector fino alla ricezione

del segnale di accettazione dal Trigger di Livello 1. • Read-Out Systems : moduli che leggono i dati dal sistema di Front End del detector. I dati

sono quindi immagazzinati fino a quando non verranno inviati al processore che analizzerà l’evento.

• Builder Network: la collezione di reti che fornisce le interconnessioni fra il Read-Out e il Filter system.

• Filter System: i processori a cui arrivano gli eventi dal Read-Out. Questi eseguono gli algoritmi dell’HLT al fine di selezionare gli eventi che verranno salvati per una successiva analisi off-line.

• Event Manager: l’entità responsabile per il controllo dei flussi di dati nel sistema DAQ. Fornisce una gestione centralizzata per il controllo degli eventi che semplifica notevolmente la sincronizzazione dell’intero sistema.

• Control e Monitor System: responsabile per la configurazione e verifica (monitoring) di tutti gli elementi.

2.2 Sistema di Trigger e Acquisizione dati per le DT In Figura 18 è mostrata in modo schematico la struttura della parte locale del sistema di Trigger e Acquisizione dati per le camere di tubi a deriva per muoni del Barrel di CMS. L’elettronica di Front-End è implementata da processori ASIC. Questi sono raggruppati in schede che servono 16 canali (4 canali su quattro layer del super-layer), direttamente collocate nel pannello di chiusura del super-layer, sul lato opposto a quello in cui viene fornita la tensione a fili anodici e strisce catodiche. La funzione svolta dall’elettronica di Front-End è di amplificare il segnale proveniente dal rivelatore (limitando il rumore) e compararlo nel modo più veloce possibile con una soglia. Il risultato viene inviato sotto forma di segnale logico tramite cavi FTP (Foil Screened Twisted Pair, ovvero cavi contenenti fili di rame schermati da un foglio di alluminio) all’elettronica

19

della parte locale dei sistemi di Trigger e Acquisizione dati, posta in strutture di alluminio installate a fianco di ciascuna camera, chiamate Mini-Crate (Figura 19). Nei successivi paragrafi analizzeremo in dettaglio le parti più fortemente legate al lavoro svolto: il Trigger locale, il Trigger regionale e il sistema di Read-Out della DAQ.

Figura 18 Sistema locale di Trigger e Acquisizione dati per Camere di tubi a deriva

2.3 Il Trigger locale per le camere a deriva (DTBX) Il DTBX è il sistema di Trigger che effettua la ricostruzione locale dei segmenti della traccia di un muone che attraversa una camera a deriva. L’algoritmo è suddiviso in diversi stadi di elaborazione, organizzati in una struttura logica ad albero e implementati su dispositivi appositamente realizzati, posti in un Mini-Crate alloggiato a fianco delle camere di tubi a deriva (vedi Figura 19).

Figura 19 Fotografia dell’assemblaggio di un Mini-crate.

Compito di questo sistema è di identificare i muoni che attraversano la camera, misurare la posizione di impatto, l’angolo di curvatura della loro traiettoria rispetto alla perpendicolare alla camera ed assegnarli al corretto BX in cui sono stati prodotti. I principali requisiti fisici per il Trigger DTBX sono:

20

Alta efficienza globale nell’individuazione dei muoni (>90%); Alta efficienza per coppie di muoni ravvicinati (fino a pochi centimetri); Precisa misura di Pt; Bassa frequenza di false tracce; Assegnazione di ogni muone al BX di produzione.

Inoltre l’elettronica deve soddisfare precisi limiti: Limitato tempo di elaborazione (latenza); Affidabilità, in quanto non sarà accessibile durante il funzionamento di CMS; Programmabilità al fine di mettere a punto gli algoritmi; Tolleranza all’ambiente radioattivo presente in CMS; Bassa dissipazione di potenza.

Tutte queste richieste pongono stringenti limiti agli algoritmi e alla progettazione dei dispositivi. Il sistema è composto di 3 unità logiche: Bunch and Track Identifier (BTI), Track Correlator (TRACO) , e Trigger Sever (TS). 2.3.1 Il Bunch and Track Identifier Il BTI associa un segmento di traccia a un muone che attraversa una camera DT in uno specifico SL. Tale segmento contiene informazioni sulla traiettoria e il BX di produzione della particella. Ogni BTI è connesso a 9 celle dello stesso SL (Figura 20), con alcuni tubi condivisi con il BTI adiacente.

Figura 20 Sistema di riferimento dei BTI

L’algoritmo controlla tutte le possibili combinazioni di 4 celle compatibili con l’attraversamento di un muone con una traiettoria rettilinea, cercando eventuali corrispondenze ogni 25 ns. Il passaggio di un muone genera una correlazione dopo un tempo fissato, uguale al massimo tempo di deriva all’interno della cella, identificando così il BX di produzione. Il BTI inoltre ricostruisce un segmento di traccia calcolando la coordinata x e il parametro k = tanψ associati alla traiettoria del muone (vedi Figura 20). I segmenti sono classificati in due modi:

Trigger di alta qualità (HTRG) se la traccia è stata individuata nei 4 layers Trigger di bassa qualità (LTRG) se la traccia è stata individuata solo in 3 layers su 4.

Questo limita l’accettanza angolare dei BTI a ψmax = ± 45.7° per HTRG e ψmax = ± 56° per LTRG. Ciascun BTI spedisce al successivo dispositivo di Trigger 16 bits per ogni BX: 6 per la coordinata x (che ha una precisione di 1.25 mm), 6 per il parametro k (con una precisione di 60 mrad) e 1 per la qualità. Il BTI è realizzato in un dispositivo di tipo ASIC: 4 BTI sono messi nello stesso dispositivo (modulo BTI) e il loro numero dipende dalla dimensione della camera, variando da 50 a 70 per SL.

21

2.3.2 Il Track Correlator Il TRACO ha lo scopo di correlare i segmenti di traccia ottenuti dai BTI di entrambi i SL per la rivelazione nel piano r-φ di una camera DT. Ogni Traco è collegato a 4 BTIs nel SL interno (più vicino al punto di interazione di CMS) e 12 in quello più esterno (Figura 21).

Figura 21 Struttura del Track Correlator

L’algoritmo inizia convertendo i segmenti ricevuti dalle coordinate locali dei BTI al sistema di riferimento del TRACO e quindi selezionando il miglior segmento per ogni super-layer. A questo punto il TRACO verifica se i due segmenti sono correlati tramite un apposito algoritmo e se non lo sono conserva solo il segmento con la qualità maggiore. Applicando in “pipeline” due volte lo stesso algoritmo, a ogni BX vengono individuate le due migliori tracce che vengono trasmesse serialmente al Trigger Server. Il motivo della scelta di un secondo segmento risiede nella richiesta di voler identificare eventi in cui si ha la produzione di due muoni con traiettorie molto vicine. I dati finali che trasmette in uscita sono l’angolo radiale Φ e l’angolo di curvatura ΦB (mostrati in Figura 22) nel sistema di riferimento di CMS.

Figura 22 Parametri calcolati dal Track Correlator.

22

I segmenti correlati hanno una risoluzione migliore di quella dei BTI: 10 mrad per l’angolo di curvatura e 1mm per la posizione di impatto. Il TRACO è realizzato con chip ASIC e sono presenti da 12 ai 24 TRACO in ogni minicrate (in base alla geometria della camera), per un totale di circa 5000 dispositivi. 2.3.3 Il sistema Trigger Server Il Trigger Server[ ]8 è il sistema che seleziona i due migliori Trigger fra i segmenti di traccia ricostruiti da tutti i TRACO in una stazione per muoni e li invia ai dispositivi del Trigger regionale. La sua struttura logica è mostrata in Figura 23.

Figura 23 Struttura generale del sistema Trigger Server. Sono mostrati tutti i dispositivi e le connessioni, oltre alle board sui quali sono montati.

Il Trigger Server è composto da due sottosistemi, uno per la vista longitudinale (TST) e uno per la vista trasversale (TSφ). Il sistema TS nel piano r-φ riceve fino a due segmenti di traccia da ogni TRACO e ha il compito di selezionare i due migliori per trasmetterli al Trigger Regionale. La selezione viene effettuata privilegiando la qualità del segmento. Si assegna la priorità innanzitutto in base alla qualità assegnata dal TRACO, quindi per primi i segmenti correlati (partendo da HH, poi HL e LL), poi quelli non correlati appartenenti a un super-layer interno (prima H poi L) e infine quelli non correlati dei super-layer esterni. La selezione privilegia inoltre segmenti di traccia a più alto Pt, corrispondenti ad un angolo di bending minore, espresso in termini del parametro k come definito dal TRACO. Il TST inoltre produce un pattern di bit che indica quali BTI hanno rilevato una traccia (ogni bit è l’OR di 8 BTI adiacenti). Infine i dati sono inviati al sistema di Trigger regionale tramite la tecnologia LVDS [ ]9 . Questa consiste nell’inviare i singoli bit dei dati ad elevata frequenza ed è caratterizzata da un basso consumo di energia (in particolare nel confronto con i dispositivi ottici) ed alta capacità di trasmissione.

23

2.4 Il sistema di Trigger regionale per i tubi a deriva Lo scopo del sistema di Trigger regionale per i tubi a deriva è di individuare le tracce dei muoni nel barrel del CMS e di misurare il Pt utilizzando i segmenti provenienti dalle diverse camere. Tutti i dispositivi di questo sistema sono alloggiati in una opportuna camera schermata all’esterno del rivelatore CMS (Counting Room). La struttura del sistema è mostrata in Figura 24.

Figura 24 Schema del sistema regionale di Trigger.

2.4.1 Il Sector Collector Il Sector Collector[ ]10 (SC) funge da raccordo fra il sistema locale di Trigger, posto nei Mini-Crates all’interno del rivelatore con il sistema regionale di Trigger posto all’interno della Counting Room. Ogni settore è servito da una singola scheda SC e queste sono poste in appositi crate posti in strutture metalliche che circondano l’esperimento chiamate torri (Figura 25).

Figura 25 Posizione e collegamenti del Sector Collector

24

Le tracce provenienti da camere diverse arrivano sul SC a tempi diversi, questo sia a causa del tempo di volo dei muoni fra le varie stazioni (su cui l’elettronica di ciascuna camera è sincronizzata) sia per la differente lunghezza di cavi di collegamento. Compito del Sector Collector è di sincronizzare i segmenti provenienti dallo stesso BX, effettuare una selezione ed inviare i candidati al sistema Track Finder, posto nella counting room. In Figura 26 è mostrata la struttura della scheda del Sector Collector. Ogni ricevitore LVDS riceve le informazioni di Trigger di una camera e le invia al trasmettitore ottico. Una copia parziale di queste informazioni, contenente fra l’altro la qualità del segmento, il suo BX, le informazioni sugli hits in theta , viene inviata al chip di controllo a ogni bunch crossing. All’interno di questo chip è presente un buffer che di tipo RAM. E’ possibile inserire questi dati direttamente all’acquisizione del sistema tramite una connessione dedicata con le Read-Out board. Questa funzionalità è molto importante in quanto si tratta della prima volta in cui è possibile accedere ai dati prodotti dal sistema di Trigger.

Figura 26 Flussi di dati all’interno della scheda del Sector Collector

2.4.2 Drift Tube Track Finder I segmenti trasmessi dal DTBX sono ricevuti da due sistemi chiamati Drift Tube Track Finder DTTF, rispettivamente uno per la vista φ (Phi Track Finder, PHTF) e una per quella η (Eta Track Finder, ETTF). Ogni PHTF elabora i segmenti ricevuti dalle quattro stazioni di un settore con lo scopo di ricostruire le tracce all’ interno di un settore azimutale di 30° all’interno di ogni Wheel del Barrel. L’algoritmo del PHTF è composto da tre fasi, mostrate graficamente in Figura 27 .

25

Figura 27 Schema a blocchi dell’algoritmo del Phi Track Finder

Innanzitutto viene cercata da una Extrapolation Unit la corrispondenza fra i segmenti individuati nelle varie camere, estrapolando dalla misura di φ e η il possibile segmento nella camera successiva. Le coppie che corrispondono sono quindi inviate al Track Assembler che collega i vari segmenti per ottenere una traccia completa. Infine l’Assignment Unit effettua l’ultima elaborazione, assegnando i parametri delle tracce ai candidati. I processi di estrapolazione e ricostruzione usano anche segmenti dai settori vicini al fine di seguire le tracce che attraversano i confini tra ruote e settori. La precisione finale per il PHTF è di ± 2.5° su φ, ±0.1 per η e per quanto riguarda Pt dipende dal range di energia come mostrato nella Tabella 2.

Range di Pt [Gev] Precisione [GeV] 2 ÷ 4 0.5 4 ÷ 8 1 8 ÷ 14 2 14 ÷ 20 3 20 ÷ 40 5 40 ÷ 80 10 80 ÷ 140 20 140 ÷ ∞ -

Tabella 2 Precisione dell’output del DTTF per differenti intervalli di Pt.

L’ETTF raccoglie le informazioni nella vista θ dai Trigger DTBX delle stazioni in un spicchio (wedge) del CMS formato da 5 settori adiacenti lungo differenti wheels del barrel. L’unità cerca una coincidenza fra segnali provenienti da diverse stazioni, controllando se i segmenti sono allineati al fine di formare un’unica traccia. Questo è ottenuto come mostrato in Figura 28.

26

Figura 28 Schema dell’ ETTF

Un algoritmo compara gli hits ricevuti con una serie predefinita di patterns, poi vengono eliminati i sotto-pattern eventualmente individuati. Infine viene assegnato un valore per la pseudorapidità con una risoluzione del 3%. 2.4.3 Drift Tubes Muon Sorters Lo scopo del Muon Sorter è di selezionare le 4 migliori tracce di muoni individuate dai DTTF nell’intero sistema del Barrel, e di inviarle al Global Muon Trigger. Le tracce migliori sono quelle con la qualità più alta (assegnata in base al numero di segmenti utilizzati nella traccia ricostruita) e il maggiore impulso traverso. Il processo di selezione avviene tramite due tipi di elaboratori diversi in successione. Dapprima il Wedge Sorter deve selezionare le due migliori tracce di muoni in ciascuna wedge di CMS. Dopo aver ricevuto due candidati dal DTTF seleziona i due migliori e li invia al Muon Sorter. Questo riceve 24 tracce dai Wedge Sorters e invia le 4 migliori al Global Muon Trigger. 2.5 Sistema di Read-Out per le DT L’elettronica per il sistema di Read-Out[ ]11 per le DT è responsabile per l’acquisizione dei tempi fra il segnale proveniente dagli anodi e la ricezione del Trigger L1A e la loro trasmissione ai livelli superiori del sistema DAQ. Tale compito è effettuato dalle Read-Out Board (ROB) situate nel Mini-Crate assieme all’elettronica del sistema locale di Trigger. Due cavi FTP inviano i dati da ogni Mini-Crate nelle torri poste a fianco delle wheel di CMS dove sono localizzate le Read-Out Server Board (ROS). Ogni ROS riunisce i dati di un settore, li registra nel formato standard previsto in CMS e li spedisce alle schede di interfaccia con il sistema di acquisizione poste nella Control Room. 2.5.1 Read-Out Board Il dispositivo principale delle Read-Out Boards è il TDC (Time to Digital Converter[ ]12 ) a 32 canali, l’HPTDC (Higly Programmable TDC) sviluppato dal gruppo di Microelettronica del CERN. Ogni TDC riceve i segnali di ingresso provenienti dall’elettronica di Front End da 32 fili della camera. All’arrivo di un segnale che ha superato un valore di soglia, il TDC lo inserisce in un registro di memoria ed inizia un conteggio temporale. L’unità minima di questo conteggio è 1/32 di BX e corrisponde quindi a 0.78 ns. Quando arriva il segnale di L1A viene effettuata l’acquisizione dei

27

dati immagazzinati nel registro dinamico. Il valore di tempo che viene restituito dal TDC è ottenuto tramite la formula:

TTDC = Toff – Tcountdove Tcount è il tempo intercorso tra l’arrivo del segnale sul filo (Start) e L1A (Stop). In questi modo i tempi risultano ordinati in maniera corrispondente al tempo di deriva (ovvero a un tempo minore corrisponde un TTDC minore). La struttura del TDC è mostrata in Figura 29.

Figura 29 Struttura di un TDC

L’HTDC è stato disegnato in modo da gestire un rate di hits fino a 2MHz, molto più del necessario in quanto il rate in una canale rumoroso è dell’ordine dei kHz. Trovandosi nel Mini-Crate, l’HTDC è stato implementato con una tecnologia in grado di sopportare livelli di radiazione fino a 30 krad di dose totale. In ogni ROB sono presenti 4 HTTDC connessi in un circuito ad anello sincrono come mostrato in Figura 30.

Figura 30 Disposizione dei TDC in una ROB

I processori sono collegati in un anello a clock sincrono, realizzato in modo da evitare che il malfunzionamento di un singolo dispositivo interrompa il funzionamento dell’intera ROB. Quando avviene il Read-Out un HTDC alla volta trasmette i dati (8 bit in parallelo dei 32 della parola) in un serializzatore LVDS. Ogni Trigger genera un blocco di eventi da parte di una ROB, il quale contiene informazioni sul BX, sul numero dell’evento, sul numero di parole trasmesse, oltre all’informazione che contiene la misura temporale.

28

2.5.2 Dispositivi Read-Out Server Le ROS sono localizzate nelle torri poste a fianco delle wheel di CMS (dove si trovano anche le schede del sector collector per il Trigger). Ci sarà una ROS per ogni settore, che quindi riceverà 25 canali LVDS dalle ROB. Compito della ROS è deserializzare i dati, aggiungere le informazioni sulla ROB di provenienza e la qualità della trasmissione, ed inviarli all’event builder (nella counting room via fibra ottica).

Figura 31 Collocazione delle schede ROS e SC in una torre di CMS

29

Capitolo 3

Analisi del rumore correlato nei dati acquisiti durante l’attività di Commissioning

3.1 Introduzione A partire dall’Aprile del 2007 è iniziata l’attività di test delle camere a deriva del barrel nella loro collocazione finale all’interno delle wheels di CMS (commissioning). Durante i test effettuati con muoni cosmici sono stati osservati eventi con un numero di hits (ovvero di celle che hanno inviato un segnale) elevato, non compatibile con un processo fisico, visto che per ogni evento ci si aspetta il passaggio di una o due particelle. Tale effetto appariva evidente fin dall’osservazione del Monitor on-line (DQM, Data Quality Monitor), un software dedicato al monitoraggio della qualità dei dati raccolti dal rivelatore, in modo da fornire un immediato riscontro a chi lavora sull’esperimento. Questo rumore appariva topologicamente esteso all’interno di uno o più settori (vedi Figura 32) quindi diverso da altri tipi d rumore, solitamente legati a pochi fili rumorosi, precedentemente individuati e studiati nei test durante la produzione delle camere.

a) b)

Figura 32 Eventi di rumore per un settore (a) e per più settori (b) come visto dalla schermata del DQM

E’ stato quindi necessario effettuare uno studio approfondito del problema. In particolare si è voluto verificare le caratteristiche topologiche e temporali di questo tipo di rumore per vedere in che modo influenza il sistema di Trigger, così da poter valutarne il possibile impatto sul suo funzionamento a LHC. Per fare questo è stato sviluppato un programma utilizzando il software ufficiale sviluppato dell’esperimento CMS. In questo capitolo sono riportati i risultati dello studio effettuato su questo tipo di rumore utilizzando le informazioni registrate dal sistema di acquisizione, mentre nel successivo verranno esposti i risultati ottenuti sui possibili effetti sul Trigger.

30

3.2 Attività di Commissioning La fase di Commissioning è un momento fondamentale nella realizzazione di ogni esperimento. Il suo obiettivo è di rendere operativa l’apparecchiatura sperimentale con le caratteristiche attese in fase di progettazione in modo che sia in grado di raccogliere dati con alta efficienza. Bisogna quindi eseguire test sui singoli componenti e in seguito verificarne il funzionamento all’interno del sistema completo. Quest’ultima parte richiede innanzitutto analisi sull’integrazione dei vari apparati: alimentazione, raffreddamento, elettronica del detector, Trigger, acquisizione dati, sistemi di controllo, sistemi di sicurezza. Poi è necessario sincronizzare le diverse componenti, controllare la qualità dei dati ed ottimizzarla lavorando su calibrazione e allineamento. Si sono seguiti due approcci : uno di tipo “orizzontale” che prevede la verifica della funzionalità di ogni singolo componente e uno di tipo “verticale”, effettuando fasi di raccolta dati (run) di commissioning con sezioni più ampie dell’esperimento aumentando la scala di complessità. Dato che l’attività si è svolta contemporaneamente a fasi di installazione e cablaggio vi sono state molte complicazioni. E’ stato infatti necessario ottenere l’alimentazione finale, il cablaggio e il raffreddamento, verificare che l’elettronica non fosse disturbata da rumore generato all’interno della caverna da strumenti quali i saldatori. Inoltre i sistemi stessi di Acquisizione Dati e Trigger erano in fase di installazione e quindi non pienamente operativi nella forma finale. Per quanto riguarda le camere di tubi a deriva del barrel, dopo essere state assemblate nei centri di produzione, sono state sottoposte a una prima serie di test al CERN. In seguito sono state collocate all’interno delle wheel di CMS quando queste si trovavano ancora in superficie, e sottoposte a una prima fase di commissiong camera per camera, dove i servizi (allacciamento all’alimentazione, ai sistemi di Trigger a Acquisizione Dati, al gas) venivano forniti in modo provvisorio. Durante questo periodo si sono ottenuti risultati molto importanti soprattutto durante il Magnet Test e Cosmic Challenge (MTCC). Nell’estate del 2006 l’esperimento è stato chiuso al fine di verificare il funzionamento del magnete superconduttore ed effettuare una mappatura del campo magnetico. Per l’occasione una sezione di ognuno dei sotto-rivelatori di CMS era stata resa operativa (Tracker, HCAL, ECAL, DT, RPC, CSC). Per le camere DT erano disponibili 3 settori per un totale di 14 camere, che hanno fornito il Trigger per l’acquisizione all’intero sistema, permettendo di effettuare le prime ricostruzioni di tracce di raggi cosmici all’interno di CMS.

b) a)

Figura 33 a) Arrivo di una wheel all’interno della caverna sotterranea b) Vista frontale di una Wheel nella caverna di CMS.

In seguito gli elementi dell’esperimento sono stati calati uno a uno all’interno della caverna sotterranea posta lungo il percorso di LHC (Figura 33). Qui si è iniziato il lavoro di allestimento dell’esperimento per il suo funzionamento finale, e questo lavoro è stato affiancato dal commissioning finale per ogni dispositivo. Per le DT si è partiti da primi test sulle singole camere, per passare ad effettuare run di commissioning su un singolo settore, poi su più settori per arrivare a lavorare con un’intera wheel alla volta. Il procedimento seguito richiede inoltre una rapida analisi

31

dei dati raccolti in modo da fornire nel minor tempo possibile ai tecnici che lavorano sull’esperimento le indicazioni per effettuare, dove possibile, i necessari aggiustamenti. Per le camere DT sono stati effettuati tre tipi di run per il commissioning. Nei run detti di “noise” venivano inviati alla camera dei segnali di Trigger random al fine di individuare i fili rumorosi al fine di ripararli o isolarli. Nei run di “test pulse” venivano iniettati impulsi sui front-end simulando tracce nella camera in modo da verificare il comportamento dell’elettronica di Trigger e di Read-Out. Infine nei run di cosmici sono stati raccolti dati di muoni atmosferici che attraversano il settore, come verrà illustrato nel Paragrafo 3.3). Ogni fase del commissioning su un singolo settore[ ]13 prevedeva l’acquisizione di:

• almeno 100k eventi con cosmici • 170k eventi di test pulses • 100k eventi di run di rumore con diverse soglie sui fili (15-20 e 25 mV).

In conclusione gli obiettivi finali per il commissioning per le camere DT sono: • Controllo delle connessioni • Controllo della funzionalità dei Mini-Crates (contenenti l’elettronica di ciascuna camera) • Sincronizzazione delle camere di un settore • Controllo della trasmissione di Trigger e Read-Out dal sistema locale a quello regionale. • Studio del rumore • Studio della stabilità del Software per la DAQ • Partecipazione a run comuni con gli altri rivelatori di CMS.

3.3 Run di cosmici e Technical Trigger Per effettuare i test di commissioning la sorgente comunemente usata sono i muoni cosmici. Questi vengono prodotti come risultato dell’interazione di particelle (principalmente protoni) di alta energia con l’atmosfera terrestre, che dà origine a uno sciame di particelle che si propaga nell’aria (Figura 34). A livello del mare questa “radiazione cosmica secondaria” è composta principalmente da µ±, e±, γ e neutroni, mentre sotto terra si ritrovano solamente µ e neutrini. Il tipico rate di muoni a livello del suolo è di circa 200 Hz/m2, mentre a livello della caverna sotterranea di CMS si ha una diminuzione di un fattore cento, arrivando a un rate di 2Hz/m2.

Figura 34 Sciame cosmico con generazione di µ rilevato da CMS

32

La presenza di questi muoni cosmici è una grande opportunità per effettuare test di rivelatori, essendo una sorgente sempre disponibile e conosciuta. Nella loro utilizzazione per i test di CMS vi sono però alcune limitazioni. Innanzitutto bisogna tenere conto che l’intero esperimento è stato strutturato per rivelare particelle provenienti da una collisione in un punto preciso dello spazio, mentre invece i muoni cosmici solitamente attraversano l’intero esperimento dall’alto verso il basso passando anche molto lontani dal futuro punto di interazione. Questo fa sì che l’efficienza di individuazione dei µ sia molto inferiore a quella prevista, soprattutto ad esempio nei settori laterali delle wheel. Inoltre anche gli algoritmi di ricostruzione applicati nell’elettronica non sono particolarmente adatti allo studio di questo tipo di segnale. Ad esempio gli strumenti di ricostruzione tracce pongono come vincolo il passaggio dal vertice e l’attraversamento per prime delle camere interne di ogni settore (MB1), senza contare che non essendoci campo magnetico le particelle procedono in linea retta. Inoltre l’elettronica di LHC lavorerà in modo sincrono con le collisioni protone-protone mentre invece i cosmici arrivano con probabilità uniforme all’interno della finestra di 25 ns, rendendo difficoltosa ad esempio una precisa assegnazione del BX. Al fine di utilizzare i muoni cosmici come sorgente, per il commissioning è stata sviluppata una particolare configurazione chiamata Technical Trigger (Figura 35). Per le camere a livello di Mini-Crate è stata impostata la configurazione chiamata “Hany Theta”. Questa richiede che nei super-layers Ф all’interno di una camera siano identificate due tracce H (HH) o una traccia H e una L (HL). Nel caso di una sola traccia H non correlata, si richiede che ci sia un segnale nel super-layer theta, che sia H o L.

Figura 35 Technical Trigger per un settore[ ]14

Il segnale generato a livello di camera arriva al Sector Collector e da questo è inviato a una scheda CAEN V976[ ]15 . Questo dispositivo è in grado di effettuare alcune operazioni logiche sul segnale come OR o AND, e di convertirlo in un formato adatto per l’elettronica successiva (per esempio da TTL a NIM), che genera il segnale di L1A. Questo sistema permette di utilizzare diverse configurazioni per effettuare studi specifici, ad esempio osservare il comportamento di una camera quando il Trigger veniva generato da altre. Durante i run di commissioning con cosmici il Technical Trigger effettuava l’OR dei segnali di Trigger provenienti dalle camere del settore. Questa regola per il Trigger permette di avere un campione abbastanza ampio di dati per ogni tipo di camera su cui effettuare l’analisi. Al fine di poter effettuare il commissioning di più camere in parallelo vengono utilizzate più board CAEN ed effettuato un OR fra i Technical Trigger di più settori (Figura 36).

33

Figura 36 Technical Trigger per più settori

In Figura 37 sono riportati i rate di acquisizione ottenuti utilizzando il Technical Trigger nei run sui quali si è svolta l’analisi. Il rate dipende innanzitutto dalla posizione del settore. Infatti dato che i cosmici hanno una distribuzione che dipende dal quadrato del coseno dell’angolo con la verticale alla superficie terrestre i settori orizzontali hanno un’accettanza maggiore. Inoltre è anche evidente l’effetto dell’assorbimento dei muoni da parte del giogo di ferro dell’esperimento, che fa si che il rate sia maggiore nei settori superiori. Le differenze fra le varie ruote sono dovute alla loro posizione rispetto al pozzo lungo il quale sono stati calati gli elementi di CMS, nel momento in cui sono stati effettuati i run. Infatti l’assenza di roccia permette il passaggio attraverso il pozzo di un flusso molto maggiore di muoni.

Rate di acquisizione

0,0

5,0

10,0

15,0

20,0

25,0

30,0

35,0

40,0

45,0

50,0

1 2 3 4 5 6 7 8 9 10 11 12

Settori

Rat

e (H

z)

Wheel +2Wheel +1Wheel 0Wheel -1

Figura 37 Rate di acquisizione per settore durante i run di cosmici

34

3.4 Software di simulazione, ricostruzione e selezione di CMS Per l’esperimento CMS è stato sviluppato un pacchetto ufficiale di software in linguaggio C++ che va sotto il nome di CMSSW[ ]16 . Scopo di questo software è fornire all’utente tutti gli strumenti necessari per l’analisi fisica dei dati raccolti dal rivelatore. A questo scopo le principali operazioni svolte da CMSSW sono • L’unione dei dati acquisiti dai diversi sottorivelatori (RAW data) in un formato unico

accessibile per l’analisi (Root Files[ ]17 ) • L’implementazione degli algoritmi del Trigger di alto livello e degli strumenti per la

ricostruzione delle grandezze fisiche di interesse: tracce, momenti, energie…. • La simulazione dell’intero esperimento

L’elemento base per l’analisi è chiamato Evento. Fisicamente un evento è il risultato della lettura dall’elettronica del detector, ovvero dei segnali che sono stati generati da particelle nel corso di un bunch crossing. Dal punto di vista software un Evento è un contenitore all’interno del quale vengono inserite tutte le informazioni riguardanti il singolo bunch crossing in un formato opportuno. L’ambiente di lavoro CMSSW è di tipo modulare, dove ogni modulo, sviluppato come plug-in per l’eseguibile, è in grado di prendere informazioni dall’Evento, eseguire degli algoritmi e se necessario inserire i suoi risultati all’interno dell’evento stesso, come mostrato in Figura 38.

Figura 38 Struttura a moduli di CMSSW

Quando avviene l’immagazzinamento su supporto fisso, all’interno dell’Evento saranno contenuti: • Le informazioni raccolte dal rivelatore • I risultati del Trigger di livello-1 • I risultati delle selezioni dell’HLT Per effettuare ulteriori analisi sui dati è necessario realizzare un file di configurazione per l’eseguibile di CMSSW. All’interno del file di configurazione sono contenute le informazioni sui moduli da utilizzare, nonché le eventuali informazioni a loro necessarie (geometria, mapping del campo magnetico, mapping dell’elettronica, calibrazioni, etc.). I moduli rientrano in 5 categorie:

• Sources ⇒ Fornisce la sorgente, ovvero il file che deve essere processato • Producers ⇒ Creano dati da immettere nell’evento (ad esempio tracce ricostruite o oggetti

simulati) • Filters ⇒ Decidono in base a opportuni parametri se l’analisi dell’evento deve proseguire • Analysers ⇒ Studiano le proprietà dall’evento • Output Modules ⇒ Creano files con all’interno dati contenuti nell’evento

35

Lo schema del processo di analisi di una serie di eventi tramite CMSSW è mostrata in Figura 39. Nel caso dei dati di commissioning per ogni evento erano disponibili, oltre ai file RAW del detector, le informazioni del Trigger Locale registrate a livello del Sector Collector. Per effettuare le analisi descritte nei paragrafi successivi ho utilizzato un modulo di Source che leggeva i dati dai RAW file, essi poi venivano elaborati da un Unpacker che riorganizzava le informazioni di Read-Out e di Trigger in opportuni elenchi (Collection) per ogni evento. Ho poi scritto un Analyser che analizzava i dati messi a disposizione dalle Collection e che produceva i risultati principalmente sotto forma di oggetti grafici del programma ROOT. Quest’ultimo è un ambiente di lavoro ad oggetti che mette a disposizioni gli strumenti per la realizzazione e l’analisi di grafici ed istogrammi. Infine per la parte di emulazione ho utilizzato un modulo Producer che simulava l’output del sistema di Trigger a partire dalle informazioni di Read-Out.

Figura 39 Organizzazione dei dati nell’ambiente di lavoro di CMSSW

3.5 Caratteristiche dei dati utilizzati I dati sui quali ho effettuato l’analisi appartengono a run di cosmici acquisiti dall’Aprile del 2007 fino al Febbraio del 2008. I run sono stati realizzati in varie fasi. Inizialmente comprendevano un singolo settore, in un secondo momento due e nella fase finale un numero sempre maggiore di settori contemporaneamente. Nel corso degli studi effettuati ho analizzato 60 run contenenti 5.411.000 Triggers, per una durata totale di funzionamento a livello di settore di circa 210 ore. Ho utilizzato solo le informazioni dei settori che effettivamente davano Trigger e solo run in cui non si erano presentati specifici problemi tecnici (ad esempio problemi nel raffreddamento, nella qualità del gas, nelle tensioni degli elementi delle celle). I run scelti coprono praticamente tutti i settori delle wheel +2,+1,0 e –1. Per tutti i run e’ stata utilizzata la configurazione hardware riassunta in Tabella 3.

Tensione Filo anodico 3600 V Tensione Strisce anodiche 1800 V Tensione Catodi -1200 V Valore per la tensione di soglia sui fili 20 mV Configurazione del Trigger Locale HanyTheta Configurazione del Trigger Regionale Technical Trigger

Tabella 3 Setup sperimentale utilizzato per i run di cosmici

36

3.6 Proprietà spaziali e temporali del rumore per singolo settore Il primo passo per l’analisi è stato dare un criterio che permettesse di distinguere i normali eventi di cosmici da quelli che invece considero eventi di rumore. Come definizione ho deciso di considerare il numero di hits (1 hit = 1 cella che dà segnale a un tempo definito), in quanto un grande numero di hits è la principale caratteristica di questo tipo di rumore. In particolare come valore di soglia ho scelto 80 hits per settore, sia perché questo valore corrisponde circa al passaggio di due tracce che illuminino tutti i layers di un settore, sia perché è questo il valore oltre il quale gli eventi sono stati esclusi dagli altri studi effettuati sui dati di commissiong[ ]18 (di rates, efficienza, ricostruzione, etc). Quindi tale scelta mi permette di selezionare di tutti quegli eventi che non sono ancora stati analizzati. In Figura 40a è mostrato il numero di hits per eventi di tipo non rumoroso appartenenti a un run eseguito sul settore 4 della Wheel 0. Si notano una serie di picchi legati al passaggio delle particelle in più parti del rivelatore. Ad esempio si ha un primo picco a 8 hits corrispondente a una coppia di super-layers, seguito da uno a 12 per un’intera camera e così via. Oltre i 50 hits si nota come il numero di eventi cali sensibilmente dando origine a una coda dovuta sia al passaggio di più particelle, sia all’effetto dei fili rumorosi a causa dell’elettronica. In Figura 40b è mostrata per la stessa camera la distribuzione degli hits negli eventi di rumore. Innanzitutto appare evidente la prosecuzione della coda vista nel grafico precedente fino a circa 250 hits. Questa è dovuta principalmente alla presenza di singoli fili rumorosi che possono contribuire anche con 10-15 hits per evento. In seguito sono presenti eventi rumorosi distribuiti in maniera generalmente casuale fino a giungere a un valore di saturazione a cui appare un picco. Questo corrisponde a circa 1700 hits, pari a circa il 50% dei fili del settore con segnale.

a) b)

Figura 40 a) Numero di Hits per eventi normali b) Numero di Hits per eventi di rumore per il Settore 4 Wheel 1

Queste figure possono variare molto di aspetto da settore a settore. Ad esempio in Figura 41 sono mostrati come risultano per il settore 12 della Wheel 0. Per gli eventi non di rumore la distribuzione viene modificata dalla diversa orientazione della camera che porta a differenti probabilità di attraversamento da parte del muone. Per gli eventi di rumore rimane sempre visibile la coda fino a circa 300 hits, mentre la distribuzione successiva può essere molto varia, anche se in ogni caso è presente un picco di saturazione, in questo caso molto più marcato.

37

a) b)

Figura 41 a) Numero di Hits per eventi normali b) Numero di Hits per eventi di rumore per il Settore 12 Wheel 0

Il programma sviluppato permette anche di mostrare il numero di hits per layer, per super-layer e per camera. In Figura 42 ad esempio sono mostrati il numero di hits per layer all’interno di una camera MB1 del settore 4 Wheel 1. Si può subito notare come alcuni layers si presentino maggiormente rumorosi , ad esempio nel SL theta i layer 2 e 3 che in alcuni eventi risultavano completamente accesi (52 hits per 52 fili).

Figura 42 Numero di hits per layer in MB1 del Settore 4 Wheel 0

In Figura 43 sempre per la stessa camera sono mostrati gli hits per super-layer. In questo caso sono evidenti dei picchi per un numero di hits elevato, anche se non sembrano dei limiti di saturazione, visto ad esempio la presenza di eventi con Nhits maggiore di quello del picco nel super-layer Ф1, che indicano una diversa distribuzione di celle accese fra i super-layers a parità di livello di saturazione.

Figura 43 Numero di hits per super-layer per MB1 del Settore 4 Wheel 0

In Figura 44 sempre per il settore 4 è mostrato il numero di hits per camera. In questo caso il picco finale appare molto netto e non è presente nessun evento con un numero di hits maggiore. Inoltre il suo valore appare legato alla dimensione della camera. Questo è dovuto al fatto che rispetto al numero dei fili una camera è servita da un numero diverso di ROS, e quindi il limite di saturazione è legato alla dimensione del buffer interno di tale dispositivo.

38

Figura 44 Hits per camera per il per il settore 4 wheel 1

Il secondo passo è stato considerare la molteplicità degli hits sui singoli fili realizzando dei grafici di occupancy. Con questo termine si intende un grafico che mostri per tutti gli i fili del settore considerato quante volte abbiano dato hits durante un run. In Figura 45 è mostrato un grafico di questo tipo per eventi normali per un run del settore 8 wheel 1. Sull’asse y sono posti tutti i layers raggruppati per super-layers di ogni camera. Sull’asse x invece è riportato il numero del filo, in modo che ogni casella rappresenti una cella del settore. Questo permette di avere una rappresentazione grafica della forma del settore fornendo in modo intuitivo il suo comportamento. Per gli eventi non di rumore si nota come la distribuzione dell’occupancy sia uniforme, tranne le celle rumorose dovute all’elettronica (che corrispondono a quelle individuate negli studi effettuati sui run di “noise”) e quelle assenti, dovuto al fatto che erano scollegate dall’alta tensione o dai sistemi di acquisizione.

39

Figura 45 Occupancy dei fili per un run del settore 8 wheel 1

E’ interessante prendere in considerazione gli eventi di solo rumore. L’obiettivo è quello di verificare la presenza di particolari strutture nella modalità in cui zone del rivelatore danno origine al rumore, in modo da provare ad individuare ad esempio un dispositivo che ne sia la causa. Il risultato per lo stesso run del settore 8 è mostrato in Figura 46.

Figura 46 Occupancy dei fili per gli eventi di rumore per un run del settore 8 Wheel 1

Innanzitutto la copertura non è uniforme come nel caso precedente. Questo può essere sia dovuto a una statistica inferiore, ma principalmente al fatto che alcune zone sembrano più suscettibili al rumore di altre, come ad esempio il layer più esterno di MB3 che esibisce questo comportamento in gran parte dei settori analizzati. Inoltre le celle rumorose viste negli eventi normali appaiono sempre ben riconoscibili, ma allo stesso tempo alcune celle, soprattutto ai bordi delle camere mostrano di dare hits in maniera maggiore negli eventi con Nhits>80. Inoltre alcuni fili che nel caso precedente apparivano spenti, qui danno del segnale. Questo è dovuto al fatto che qualunque cosa dia origine al rumore è in grado di generare segnale sui fili anche quando questi non sono sotto tensione,

40

caratteristica che è stata sfruttata effettuando run senza tensione al fine di raccogliere solo eventi di questo tipo come illustrato nel Paragrafo 4.2.3. Il tipo di rappresentazione utilizzato si presta molto bene a dare un’idea del comportamento del rivelatore anche per un singolo evento. Ad esempio dalla figura di occupancy in Figura 47a è possibile, tenendo conto dell’allineamento dei segmenti nella vista φ, ipotizzare un passaggio della particella come mostrato in Figura 47b. In MB1 non e’ stata rilevata per la forte inclinazione che si nota nel piano θ.

b) a)

Figura 47 Muone che attraversa 3 camere del Settore 8

Per un evento di rumore si può verificare lo schema con cui si illumina il rivelatore. In alcuni casi le zone interessate dal rumore sono solo alcune camere, come mostrato in Figura 48a. Questo avviene in particolare per le MB4 e specialmente nei settori dove ce ne sono 2, ovvero il 4 e il 10. Nei casi in cui si è prossimi alla saturazione si ottiene una struttura del tipo mostrato in Figura 48b. Effettuando confronti fra un elevato numero di eventi si è verificato che il pattern di accensione varia ogni volta, quindi il sistema giunge ogni volta a saturazione con segnali da vasti gruppi di fili per ogni evento in modo diverso.

41

a) b)

Figura 48 Esempi di Eventi rumorosi

Associato a ogni hit si ha la misura temporale effettuata dai TDC e contenuta nei “digi”. Questa può essere espressa in 2 formati, o sotto forma di conteggi effettuati dai TDC stessi o in nanosecondi, dove il fattore di conversione è legato alla durata del conteggio stesso (0,76 ns). Se si pone in un grafico i tempi ottenuti dai “digi” per un intero run per ogni cella si ottiene una distribuzione chiamata Time-Box, uniforme in un intervallo temporale pari al tempo massimo di deriva in quanto la probabilità di passaggio è uniforme su tutta la cella. Sperimentalmente una normale Time-Box è caratterizzata da un margine di salita più smussato e da una coda dopo la discesa, dovuti alla non uniformità del campo elettrico in prossimità del filo anodico e dei catodi. Una caratteristica dei run eseguiti per il commissioning è il fatto che al momento dell’acquisizione (ovvero alla ricezione dell’L1A) i dati vengono copiati dai registri dei TDC in una finestra molto più ampia di quanto avverrà nel modo di funzionamento standard. Questo è possibile in quanto la frequenza dei muoni è molto inferiore di quanto sarà a LHC e permette di studiare in modo più approfondito il comportamento del sistema. Infatti l’analisi delle Time-Box permette lo studio di vari fenomeni. Ad esempio la presenza di fili che generano rumore ad alta frequenza per problemi di elettronica si ha una struttura come quella in Figura 50b. Oppure altro problema noto è la presenza di fili che danno rumore in modo correlato generando after pulses dopo la Time-Box stessa come in Figura 50a.

42

Figura 49 Time-Box di un layer per eventi normali

Figura 50 a) Time-Box con after-pulse generato da un filo rumoroso b) Time-Box dove un filo produce rumore in modo uniforme nel tempo

Si consideri ora il caso di maggiore interesse, ovvero la Time-Box di un layer per gli eventi di rumore. Il risultato per il layer 4 di MB3 nella stazione 4 della wheel 1 è mostrato in Figura 51. La struttura che appare in presenza di eventi molto rumorosi (Nhits>400) è caratterizzata dalla presenza di tre picchi. Il picco principale si trova all’interno dell’intervallo di tempi della Time-Box per eventi da muoni, con un massimo al centro di tale intervallo e una coda che prosegue fino alla fine della finestra temporale. Gli altri due picchi sono generalmente più bassi e i loro massimi sono situati rispettivamente circa 500 e 1500 ns prima del picco principale.

Figura 51 Time-Box per eventi di rumore

Il fenomeno è inoltre evidente per tutti i layer di un settore soggetto a rumore correlato, come mostrato in Figura 52. La struttura a picchi risulta solitamente meglio definita per le camere più esterne, in particolare MB3 e MB4.

43

Figura 52 Time-Box per eventi di rumore correlato nel settore 4, wheel 1

Effettuando studi sui “digi” per ogni singolo filo ho compreso che quanto osservato era dovuto alla presenza di ripetizioni, ovvero allo stesso insieme di hits registrato dal TDC ma acquisito più volte da diversi segnali di L1A consecutivi. Sembra quindi che in seguito ad un evento rumoroso (alta molteplicità di hits) il sistema continui a generare un Trigger per molti BX a seguire. Ho sviluppato un sistema di riconoscimento degli eventi che risultano “cloni” di un evento precedente basato sul funzionamento del TDC. Nel corso di un BX il TDC è in grado di effettuare 32 conteggi (quindi 0,76 ns per conteggio) espressi con una stringa di 5 bits. Visto che l’L1A è spedito sincrono con il segnale di clock dell’esperimento a 40 MHz, ogni ulteriore acquisizione avviene dopo numero intero di BX. Effettuando il modulo del numero di conteggi in base 32, nel caso si trovi per due hits lo stesso valore è possibile ipotizzare che si tratti di una ripetizione. Aggiungendo il vincolo che questo avvenga nell’evento subito successivo e che la stessa cosa si presenti per almeno una decina di fili ho ottenuto un metodo per riconoscere gli eventi cloni con un’alta efficienza (circa il 90%) e con una percentuale di falsi positivi inferiore all’1‰. Utilizzando questo metodo è possibile ottenere il valore dello spostamento osservato nelle Time-Box. Considerando 4 fili usati per l’analisi per il run sul settore 4 della wheel 1 si ottiene la Figura 53.

44

Figura 53 Shift temporale per gli eventi ripetuti

Lo spostamento risulta apparire per multipli di 500ns ed è di segno negativo. Questo è dovuto al fatto che quando arriva il secondo L1A intanto il TDC ha proseguito a contare, quindi gli viene associato un valore di tempo incrementato dell’intervallo fra i due L1A. Quando poi viene applicato l’Offset che inverte la misura temporale si ottiene un valore di tempo inferiore a quello del primo picco. Inoltre il valore ottenuto per lo spostamento è lo stesso fissato dalla “regola di Trigger” utilizzata. Questa consiste nell’impedire per 500ns la generazione di un ulteriore L1A dopo l’ultimo inviato. Questa regola è introdotta solo per il commissioning per diminuire l’effetto del rumore sul sistema di acquisizione dati, esso stesso in fase di commissioning, così da contenere la frequenza di acquisizione, minore di quella attesa a piena funzionalità. Avendo a disposizione un metodo per distinguere gli eventi “clone” dagli eventi primari (che li avevano generati) è stato possibile valutare anche la loro durata. Per prima cosa si è verificata la presenza di una struttura composta da un generatore e due ripetizioni, che è il limite che può rimanere nell’ambito della parte del registro del TDC che veniva acquisita. Si è però anche osservato che a volte oltre ai digi dell’evento ripetuto nel clone apparivano anche altri dati, che a loro volta si ripetevano al passaggio successivo. Il risultato sul run del settore 4 che ho già utilizzato per gli esempi precedenti (Figura 52e Figura 53) è mostrato in Figura 54.Sull’asse X è posto a quale numero di ripetizione corrisponde l’evento considerato, dove nella prima colonna sono riportati gli eventi che non hanno dato origine a ripetizioni. Sull’asse Y invece è riportato il numero di hits registrati in quell’evento. Come si può notare viene seguita l’evoluzione di periodi di rumore generanti eventi cloni lunghi fino a 4 eventi, ma in altri run analizzati si è arrivati fino a 6-7. Userò spesso anche nel capitolo successivo una rappresentazione come quella in Figura 54. Infatti essendo impossibile classificare in modo preciso i vari tipi di rumore, aggiungere ai grafici un’indicazione del numero di hits è un ottimo strumento per vedere come evolve il comportamento della grandezza studiata. Si può vedere che nella prima colonna si ha una distribuzione che comprende interamente gli eventi con meno di 600 hits, mentre oltre questo valore iniziano ad apparire le ripetizioni. In generale anche osservando altri run su vari settori la soglia oltre la quale iniziano a presentarsi le ripetizioni si colloca fra i 500 e i 600 hits per settore. Altra cosa interessante è che durante il periodo di rumore il numero delle celle illuminate sembra generalmente aumentare e la maggioranza degli eventi che risultano essere arrivati a saturazione è clone di un evento precedente.

45

Figura 54 Numero di hits per livello di ripetizione

Eliminando gli eventi ripetuti la Time-Box di Figura 52 diventa come mostrato in Figura 55, dove scompaiono i picchi prima del tempo di salita del segnale della Time-Box classica, la quale poi comprende gran parte del segnale, tranne in alcune camere in cui sono visibili after-pulses.

Figura 55 Time-Box settore 4 per eventi di rumore eliminando le ripetizioni

3.7 Correlazioni spaziali negli eventi di rumore per il singolo settore Per analizzare le possibili correlazioni spaziali all’interno di un singolo settore ho realizzato grafici ponendo sulle due coordinate il numero di hits nello stesso evento in due diverse parti del rivelatore. Per prima cosa si è analizzata la correlazione fra le camere dello stesso settore.

46

In Figura 56a è mostrato il risultato che si ottiene effettuando questo tipo di confronto fra MB1 ed MB2 del settore 8 della wheel 1 per eventi normali. Si nota la presenza di gruppi di punti non correlati collegati al passaggio della particella in una singola camera e punti correlati legati al passaggio in entrambe. Quando invece si rappresentano gli eventi di rumore come in Figura 56b (riferita sempre allo stesso settore nello stesso run) si nota come oltre i 50 hits per camera, un elevato numero di hits in una camera comporti la stessa cosa nell’altra.

a) b)

Figura 56 Numero di hits per evento in MB1 e MB2 per eventi normali (a) e di rumore (b)

Per studiare la presenza di correlazione tra i vari elementi del settore in eventi rumorosi si definisce il coefficiente di correlazione r. Siano x e y due variabili misurate simultaneamente N volte e aventi varianza rispettivamente σx e σy, nonché covarianza σxy, si definisce r come:

( )∑∑

∑

==

=

−−

−−==

N

ii

N

ii

i

N

ii

yx

xy

yyxx

yyxxr

11

2

1

)(

))((

σσσ

dove x e y sono i valori medi delle due variabili. Questo valore fornisce un indice di quanto i punti (xi,yi) si adattino a una retta e quindi quanto le due grandezze siano linearmente correlate. Nel caso la dipendenza sia esatta il valore di r risulta pari a 1, mentre se due variabili non sono correlate in un numero di misure tendente all’infinito il valore di r dovrebbe essere 0. Al fine di interpretare correttamente il valore assunto da r si definisce[ ]19

( )[ ]( )[ ]

( )( )∫

−−

−Γ−Γ

=≥1

2/420

0

12/2

2/12)(r

NN drr

NNrrP

π

dove Γ è la funzione gamma:

∫∞

−−=Γ0

1)( dttex xt x>0

PN rappresenta la probabilità che N misure di due variabili non correlate x e y diano un coefficiente più grande di un particolare r0. Già per N=100 perché si possa dire che ci sia correlazione fra due misure con un livello di confidenza del 95% è sufficiente che r>0.4[ ]20 . In Tabella 4 è mostrato il livello di correlazione fra le camere all’interno di un settore per eventi normali, dove si può vedere come il valore di r sia molto piccolo a parte per camere adiacente, dove è più probabile che un muone le attraversi entrambe.

47

MB1 MB2 MB3 MB4

MB1 1 0.20 0.049 0.025

MB2 - 1 0.18 0.096

MB3 - - 1 0.12

MB4 - - - 1

Tabella 4 Valore del coefficiente di correlazione fra le camere di un settore4 per eventi non di rumore

Quando invece si considerano gli eventi di rumore (Tabella 5) il valore di r diventano molto prossimi a 1 mettendo in evidenza la presenza di una correlazione lineare molto forte anche fra camere lontane.

MB1 MB2 MB3 MB4

MB1 1 0.97 0.95 0.95

MB2 - 1 0.98 0.96

MB3 - - 1 0.97

MB4 - - - 1

Tabella 5 Valore del coefficiente di correlazione fra le camere di un settore 4 per eventi di rumore

Lo stesso procedimento è stato utilizzato per confrontare il livello di correlazione fra i vari layers, per verificare l’esistenza di correlazioni privilegiate. Lavorando con gli eventi normali si vede che tendono a essere correlati fra di loro i layers all’interno della stessa camera (Figura 57a). Nel caso degli eventi di rumore invece i layers anche molto distanti fra di loro risultano fortemente correlati, anche se comunque questo è più forte fra layers vicini, soprattutto fra i due interni al super-layer Figura 57b).

a) b)

Figura 57 Valore del coefficiente di correlazione fra i layers di un settore per eventi normali (a) e di rumore (b)

48

3.8 Tipologie di eventi e relativi rates Nei paragrafi precedenti ho illustrato esempi del procedimento seguito per lo studio delle caratteristiche degli eventi con un numero di digi superiore a 80 hits in base alle quali è possibile effettuare una distinzione fra diverse tipologie legate al numero di hits stesso. Alla fine di questa analisi ho potuto classificare gli eventi in tre categorie: • Per un numero di hits per settore inferiore a 300 gli eventi appaiono non correlati fra

camere e layers. La loro origine è legata a un processo fisico che ha generato il Trigger, mentre il numero di hits anomalo può essere dovuto al passaggio di numerosi muoni appartenenti a uno sciame atmosferico, o a un singolo muone che ha creato uno sciame interagendo all’interno del rivelatore, o (causa che dal mio studio appare come la più comune) dal fatto che agli hits “fisici” si sovrappone l’effetto del rumore dato dall’elettronica su più fili, in particolare quelli posti ai bordi della camera. Visto che questi eventi appaiono come la prosecuzione della distribuzione degli hits degli eventi normali per Nhits>80 ci riferiremo a loro come ad eventi “coda”.

• Per un numero di hits fra 300 e 600 si ha un rumore correlato fra i layers all’interno di una camera. Rumore di questo tipo è presente spesso in quantità limitata e solo in alcuni settori.

• Per un numero di hits superiore a 600 il rumore appare correlato all’interno dell’intero rivelatore. Inoltre questo tipo di rumore appare perdurare nel tempo dando origine a copie degli eventi facilmente riconoscibili.

Queste considerazioni sono state alla base dello studio sulle frequenze degli eventi di rumore effettuato su 60 run del commissioning. La prima cosa da sottolineare è come, mentre il rumore di “coda” era sempre presente nei run di commissioning, la frequenza con cui si presentava il rumore correlato era molto variabile di run in run, essendo in alcuni casi addirittura assente. Anche all’interno dei singoli run il rumore di tipo correlato molte volte si presentava da un certo punto in poi e comunque molto spesso in gruppi di eventi rumorosi ravvicinati. Ad esempio in Figura 58 è mostrata l’evoluzione del numero di hits al passare degli eventi per un run del settore 12 della Wheel 0, dove i punti sono riportati solo per gli eventi rumorosi. Si può notare come, mentre gli eventi di “coda” sono distribuiti in modo uniforme per l’intera durata del run, quelli correlati appaiono solo da metà dello stesso e appaiono in gruppi soprattutto verso la fine.

Figura 58 Evoluzione del numero degli hits al trascorrere degli eventi per il rumore

49

La Tabella 6 raccoglie i risultati di 3 run effettuati in momenti diversi sullo stesso settore. Si può notare come, mentre il rumore locale resta nei 3 casi praticamente costante, il rumore correlato varia notevolmente.

Run Durata (min)

Eventi acquisiti Rate (Hz)

Eventi di rumore

Eventi di rumore locale

Eventi di rumore correlato

Rate di rumore (Hz)

Rate eventi di “coda” (Hz)

Rate eventi di rumore correlato (Hz)

28106 204 49059 4.2±0.1 728 645 83 0.059±0.002 0.053±0.002 0.0068±0.000828045 136 32699 4.3±0.1 601 444 157 0.074±0.003 0.054±0.003 0.019±0.001 28013 157 40624 4.2±0.1 833 623 210 0.088±0.004 0.066±0.003 0.021±0.001

Tabella 6 Informazioni sul rumore su 3 run sul settore 6 della wheel 2

In Tabella 7 è riportato un riassunto dei dati raccolti per la Wheel 1 settore per settore. Si tratta di dati mediati sui valori ottenuti nei diversi run che contenevano lo stesso settore. In tabella il rumore è stato distinto fra quello di “coda” e quello di tipo correlato.

Settore

Tempo di raccolta dati (min)

Eventi acquisiti Rate (Hz)

Eventi di rumore

Eventi di rumore locale

Eventi di rumore correlato

Rate di rumore (Hz)

Rate eventi di “coda” (Hz)

Rate eventi di rumore correlato (Hz)

1 644 143613 3.7±0.5 4616 2478 2138 0.12±0.01 0.06±0.01 0.055±0.007

2 616 221568 6.0±0.7 3091 2288 803 0.08±0.01 0.06±0.01 0.022±0.003

3 711 501961 12±1.4 3583 3025 558 0.08±0.01 0.07±0.01 0.013±0.002

4 241 258009 18±3 2221 1707 514 0.15±0.03 0.12±0.02 0.036±0.007

5 270 178394 11±2 1527 1388 139 0.09±0.02 0.09±0.02 0.009±0.002

6 295 81771 4.6±0.8 3072 1498 1574 0.17±0.03 0.08±0.01 0.09±0.02

7 288 50464 2.9±0.4 1537 990 577 0.09±0.02 0.06±0.01 0.033±0.006

8 427 136955 5.3±0.6 5181 1717 3464 0.20±0.02 0.07±0.01 0.14±0.02

9 308 165997 9±1 1975 1229 746 0.11±0.02 0.07±0.01 0.031±0.007

10 348 298585 14±2 2293 1645 652 0.11±0.02 0.08±0.01 0.021±0.005

11 348 188666 9±1 1583 1146 437 0.08±0.01 0.05±0.01 0.019±0.003

12 308 93765 5.1+0.8 1725 1379 346 0.09±0.02 0.07±0.01 0.041±0.003

Tabella 7 Dati di rate per i settori della Wheel 1

Dalla tabella si nota come il rumore di “coda” dipenda fortemente dal settore. L’origine della dipendenza è di due tipi. Da una parte questo rumore è generalmente legato alla presenza di fili rumorosi, il cui numero è una caratteristica dell’elettronica in quello specifico settore, come risulta dai dati raccolti nei run di “noise” del commissioning. D’altra parte è presente anche una dipendenza dal rate di acquisizione (vedi Figura 59). Questo è dovuto dal fatto che si ha generalmente a che fare con un rumore uniforme nel tempo che non genera Trigger, quindi se si acquisisce a una frequenza maggiore si ha l’effetto apparente di avere rumore a frequenza maggiore. In pratica questo si traduce in una percentuale fissa che un evento triggerato risulti di rumore.

50

Rate di rumore locale in funzione del rate di acquisizione

0.000.020.040.060.080.100.120.140.16

0.0 5.0 10.0 15.0 20.0 25.0

Rate di acquisizione (Hz)

Rat

e ru

mor

e co

n H

its<2

50

(Hz)

Figura 59 Confronto Rate acquisizione e rate rumore con 80<Nhits<250 per i settori della Wheel 1

Invece il rumore correlato appare presentarsi con frequenze molto più casuali senza alcuna apparente dipendenza dal rate di acquisizione.

Rate di rumore correlato in funzione del rate di acquisizione

0.0000.0200.0400.0600.0800.1000.1200.1400.160

0.0 5.0 10.0 15.0 20.0 25.0

Rate di acquisizione (Hz)

Rat

e ru

mor

e co

rrel

ato

(Hz)

Figura 60 Confronto fra il rate di acquisizione e il del rate rumore correlato (Nhits>600) per i settori della wheel 1

Per questo tipo di rumore sono state cercate altre dipendenze, ad esempio rispetto al momento (ora o data) in cui erano stati effettuati run. In Figura 61 è mostrato il rate di eventi di rumore correlato in funzione dell’ora per i run analizzati. Questo approccio è gravato da grandi incertezze infatti gli orari non venivano sempre registrati con precisione. Comunque si nota un particolare aumento della rumorosità soprattutto nel primo pomeriggio, cosa che potrebbe essere legata ad attività lavorative, mentre run eseguiti molto tardi mostravano minore rumore correlato. Tali osservazioni sarebbero in accordo con l’attribuire gran parte di questo rumore alle operazioni eseguite sull’esperimento durante il commissioning. Un’attività necessaria sarà quindi verificare se esistono possibili problemi di isolamento elettromagnetico del rivelatore e in tal caso ricercare delle soluzioni.

51

Rumore correlato in funzione dell'ora

0.0000.1000.2000.3000.4000.5000.6000.7000.8000.900

7.12 9.36 12.00 14.24 16.48 19.12 21.36 0.00 2.24

Ora

Freq

ìuen

za (H

z)

Figura 61 Rate rumore correlato in funzione dell’ora

3.9 Il rumore in più settori Ho illustrato visto finora era legato al comportamento del rumore nel singolo settore. Anche quando il run comprendeva più settori infatti si è lavorato separando le informazioni tenendo conto del rate di Trigger di ognuno. Questo era possibile perché il sistema di Trigger era un OR inclusivo dei Trigger delle singole camere. Spesso inoltre anche quando a funzionare era un’intera wheel, il Trigger veniva comunque generato solo da un sottoinsieme dei settori. Considerando il comportamento di più settori contemporaneamente si può studiare in che modo vari la frequenza del rumore. Si consideri ad esempio il run 33958 della wheel 1, effettuato con il Technical Trigger di sei settori. Per considerare separatamente i 6 settori ho considerato il loro numero di eventi pari al rate del Trigger al loro interno, ottenendo risultati molto simili a quelli degli stessi settori quando funzionavano separatamente. Per invece effettuare un’analisi sul rumore sull’intero sistema che si stava analizzando si è scelta una soglia di rumore più alta, pari a 160 hits per tenere conto della possibilità di un muone di attraversare due settori. In base a questa definizione in Figura 62 è mostrata la distribuzione degli hits di rumore. La distribuzione degli hits negli eventi di rumore, a differenza del caso del singolo settore, non mostra un valore di saturazione, cosa che ci porta a pensare quindi che qualunque cosa provochi il rumore abbia un effetto correlato su tutti i settori, ma non li illumini in modo uguale portandoli contemporaneamente a saturazione. Anche in questo caso è riconoscibile una coda della distribuzione degli hits per i normali eventi di cosmici, la quale poi è seguita da una distribuzione uniforme che arriva fino a numeri di hits molto elevati.

52

Figura 62 Distribuzione degli hits nel run 33958

In Tabella 8 sono riportati i dati per le frequenze sia a livello di singolo settore sia per tutti e sei contemporaneamente. In quest’ultimo caso si è considerato rumore oltre i 180 hits e rumore locale fino a 500.

Settore Eventi Rate (Hz) Eventi di rumore

Eventi rumore “di

coda”

Eventi rumore

correlato

Rate Rumore (Hz)

Rate rumore di “coda”

(Hz)

Rate rumore correlato (Hz)

7 20168 3.2±0.15 590 395 225 0.094±0.006 0.063±0.003 0.036±0.002

8 41637 6.6±0.3 617 403 214 0.098±0.006 0.064±0.003 0.034±0.002

9 67061 10.6±0.5 698 511 187 0.111±0.007 0.081±0.004 0.030±0.002

10 100727 16.0±0.8 797 602 195 0.127±0.007 0.096±0.004 0.031±0.002

11 63822 10.1±0.5 502 478 24 0.080±0.005 0.076±0.004 0.0038±0.0007

12 37610 6.0±0.3 607 508 99 0.080±0.005 0.081±0.004 0.016±0.002

6 Settori 295832 45±2 802 559 243 0.122±0.006 0.089±0.004 0.037±0.002

Tabella 8 Rate di acquisizione e rumore per un run della wheel 1

Come si può notare, mentre il rate di acquisizione risulta poco inferiore alla somma dei rate dei vari settori, denotando il fatto che il Trigger dato dai muoni non sia correlato fra i settori, questo non è valido per il rumore, che è circa lo stesso di un settore singolo. Questo è dovuto al fatto che il rumore risulta correlato all’interno dei vari settori.

In Tabella 9 ho costruito una matrice di correlazione come fatto in precedenza per layers e camere. La correlazione appare sempre presente, anche se piu forte fra il gruppo di settori 7-8-9 e 10, mentre il rumore è meno correlato per il 10 e 11.

Settori 7 8 9 10 11 12

12 0.61 0.61 0.61 0.67 0.45 1

11 0.33 0.37 0.38 0.49 1

10 0.88 0.86 0.90 1

9 0.88 0.90 1

8 0.91 1

7 1

Tabella 9 Tabella di Correlazione fra i settori del run 33958

53

In Figura 63 è riportato per ogni evento di un run effettuato con tutti i settori della wheel 1, il numero di settori che risultavano rumorosi sull’asse x, mentre sull’asse y è riportato il corrispondente numero di hits registrati sulla ruota. Generalmente i settori risultano rumorosi singolarmente, ma con un numero di hits limitato, mentre quando un settore dà rumore correlato, questo è generalmente presente anche in altri. Infatti la distribuzione è dominata da eventi che hanno dato rumore su tutti i 12 settori della wheel.

Figura 63 Numero di settori che risultano contemporaneamente rumorosi nel run 34762 della wheel 1

Il fatto che il singolo evento molto rumoroso in un settore coinvolga generalmente anche tutti gli altri è importante in quanto mi aspetto che anche considerando l’intero sistema il rate del rumore correlato non aumenti in modo proporzionale al numero di settori, ma resti circa costante.

54

Capitolo 4

Comportamento del Trigger in presenza di rumore Nel capitolo precedente ho studiato gli eventi di rumore analizzando le informazioni del Read-Out e mettendone in luce le caratteristiche topologiche e la frequenza con cui si presentavano. Un aspetto problematico di questo tipo di rumore è la sua possibilità di produrre segnali di Trigger. L’obiettivo di questo capitolo è studiare per il rumore:

1. le caratteristiche del Trigger che esso genera 2. la sua capacità di produrre tracce all’interno dell’esperimento 3. verificare se le sue caratteristiche e la sua frequenza possano mascherare eventi fisici a basso

rate che verranno ricercati a LHC

4.1 Descrizione delle variabili analizzate e loro distribuzioni per eventi in assenza di rumore

I dati di Trigger erano iniettati negli eventi acquisiti tramite il Sector Collector (vedi Paragrafo 2.4.1). Avevo quindi a disposizione per l’analisi: • Qualità Phi • Qualità Theta • Distribuzione in BX • Indicatore prima-seconda traccia • L’indicazione di wheel, settore e camera (dove per il Trigger, nei settori 4 e 10 dove sono

presenti due camere MB4 separate, le informazioni erano registrate come se ci fosse una sola camera, ovvero era trasmesso solo il miglior segmento fra entrambe)

Il modo in cui viene vengono generati questi dati è mostrato in Figura 64.

55

Figura 64 Associazione del BX nel Sector Collector

I risultati dell’elaborazione effettuata dal DTBX sulle informazioni di Front End vengono inviati dal Trigger Server al Sector Collector, dove sono spiati in un registro di scorrimento a 40 MHz e, in parallelo, sono inviati ai dispositivi successivi del sistema di Trigger. Nel registro i dati sono contenuti in una stringa di 8 bits organizzata come in Tabella 10.

Bits Contenuto 0 Indicatore 1°-2° traccia 1,2,3 Qualità Ф 4 Presenza di Trigger θ 5 Qualità θ 6 Combinazione logica di primi 5 dipendente dal

minicrate 7 Bit di calibrazione

Tabella 10 Contenuto dati spiati provenienti dal Sector Collector

Quando viene generato il Trigger di accettazione di primo livello il contenuto del registro del Sector Collector viene “congelato”. Se al tempo t1 il dato inviato dal DTBX entra nel registro, quando riceve il segnale L1A (tL1A), esso si troverà nella locazione di memoria data da tL1A-t1 (modulo 25 ns). Poiché la latenza dei diversi dispositivi di Trigger è fissata, i dati che hanno contribuito a generare l’L1A si troveranno sempre nella stessa locazione di memoria per tutti gli eventi. Visto che è l’intero buffer ad essere copiato si hanno anche informazioni su tutte le tracce create dal DTBX in tempi precedenti e successivi, anche quelle che non hanno contribuito alla generazione dell’L1A, quindi per una camera nel nostro evento si trovano più tracce di Trigger a diversi BX. Analizzando i dati per un normale run di cosmici si ottiene una distribuzione per i BX nelle varie camere come mostrata in Figura 65. La distribuzione è caratterizzata da un forte picco al valore di BX pari a 18, associato quindi al dato che ha generato il Trigger. Nelle camere dove è presente anche il layer theta non venivano mascherati i segmenti Φ di tipo L quando erano in concomitanza con un segmento su theta stesso. Questo permetteva di avere una maggiore efficienza ma non

56

sopprimeva le cosiddette tracce “fantasma” (“ghost”I) prodotte dall’algoritmo. Il risultato è una distribuzione sovrapposta al picco dei segmenti di qualità superiore, che non è presente per MB4.

Figura 65 Distribuzione dei valori di BX misurati per camera

I 3 bits per la qualità Ф in Tabella 10 codificano le possibili combinazioni delle qualità dei due super-layer così come vengono fornite dal TRACO, come mostrato in Tabella 11. Descrizione Simbolo Codice Hits traccia

di Trigger Trigger di livello alto in entrambi i super-layers HH 6 8 Trigger di livello alto nel in un super-layer e basso nell’altro HL 5 7 Trigger di livello basso in entrambi i super-layers LL 4 6 Trigger di livello alto nel super-layer esterno H0 3 4 Trigger di livello alto nel super-layer interno Hi 2 4 Trigger di livello basso nel super-layer esterno L0 1 3 Trigger di livello basso nel super-layer interno Li 0 3 Traccia nulla 7 0

Tabella 11 Codici di qualità per l’output del TRACO

Per normali eventi di cosmici la distribuzione in qualità ha l’aspetto mostrato in Figura 66. Appare evidente la grande quantità di qualità basse, pari a circa il 50% del totale. Questo è dovuto a due fattori. Innanzitutto visto che si hanno le informazioni in un’ampia finestra del registro del SC vengono inclusi anche segmenti L generati nei BX precedenti e successivi (“ghosts”). Inoltre, visto che usando il Technical Trigger una singola camera può dare origine all’L1A, in molti casi si acquisiscono informazioni da una stazione dove non è stato generato un Trigger, ma dove potevano essere presenti segmenti L spuri. L’asimmetria fra Trigger nel super-layer interno ed esterno è dovuto al fatto che in fase di selezione l’algoritmo predilige i primi.

I Questi trigger sono dovuti ad allineamenti spuri di 3 hits da parte dell’algoritmo dei BTI, ad esempio legati alla non eliminabile ambiguità destra-sinistra nelle DT.

57

Figura 66 Qualità per eventi di cosmici nel settore 4 Wheel 1

Combinando le informazioni di BX e qualità del Trigger si ottiene quanto mostrato in Figura 67. Come si può notare gran parte dei segmenti di qualità più alta cadono al BX corretto, mentre come ci si aspetta i segmenti L isolati risultano maggiormente distribuiti.

Figura 67 Qualità in funzione del BX per cosmici nel settore 4 Wheel 1

Un interessante metodo per visualizzare il comportamento del Trigger all’interno di un settore è l’utilizzo di uno strumento chiamato “matrice di Trigger”. Con questo termine si intende la rappresentazione di tutte le possibili combinazioni di Trigger da parte delle quattro camere presenti nel settore. Si consideri ad esempio la Figura 68, che si riferisce agli eventi non rumorosi per un run del settore 12 della Wheel 0. Si tratta di una distribuzione tipica, dove gran parte degli eventi (oltre il 40%) sono stati triggerati solo da una camera, in proporzione alla dimensione e posizione delle camere stesse. Per i Trigger provenienti da più camere dominano le coppie di camere consecutive, coerentemente con quanto ci si aspetta per una particella che attraversa una parte del rivelatore. Infine sono presenti circa un 5% di eventi che hanno coinvolto tutte e quattro le stazioni del settore.

58

Figura 68 Matrice di Trigger per il Settore 12 Wheel 0

4.2 I dati di Trigger negli eventi di rumore Per studiare il comportamento del sistema di Trigger in presenza di eventi di rumore, illustrerò i risultati ottenuti da alcuni runs particolarmente significativi. 4.2.1 Run 15278 Settore 12 Wheel 0 Questo run è molto indicativo per l’analisi di eventi di rumore. Infatti nella distribuzione del numero di hits presenta oltre agli eventi di “coda” (con 80<Nhits<250) un ampio campione di eventi con Nhits prossimo alla soglia di saturazione che hanno dato origine a “cloni”, come riassunto in Figura 69 e Tabella 12.

Run 15278 Settore 12 Wheel 0

Durata (min) 50 Eventi Acquisiti 28089 Eventi di rumore 1680 Eventi di “coda” 517 Eventi correlati 1163 Eventi “clone” 650 Tabella 12 Informazioni sul Run 15278

Figura 69 Numero di hits per evento nel run 15278

In Figura 70 è mostrata la matrice di Trigger per i soli eventi di rumore. Appare subito evidente uno dei principali problemi, ovvero la mancanza delle informazioni di Trigger per circa la metà degli eventi di rumore. Nel caso degli eventi non di rumore questo non si è mai verificato, cosa che porta a legare questo effetto al rumore stesso.

59

Figura 70 Matrice di Trigger per gli eventi di rumore nel run 1527

Se si associa all’informazione sulle stazioni che hanno dato Trigger il numero di hits nel settore si ottiene quanto mostrato in Figura 71. Si nota come il rumore con Nhits<250 si distribuisca in modo alquanto uniforme, come in una matrice di eventi normali. Con l’aumentare degli hits invece si notano alcune strutture interessanti, come gli eventi Nhits≈1000 che appaiono legati a rumorosità sulle camere interne (MB1 e MB2). Infine gli eventi in prossimità della saturazione si dividono fra quelli che hanno dato segnale di Trigger in tutte le camere e quelli in cui è assente.

Figura 71 Numero di hits nel settore rispetto alle camere che hanno dato segnali di Trigger

Ricordando la definizione di evento clone vista nel Capitolo 3.7 si è verificato che i casi senza Trigger si riferiscono a questo tipo di eventi. Si osservano due tipi di comportamenti distinti. Il primo composto da un primo evento con numero elevato di hits e con tracce di Trigger in tutte le camere, seguito da 2 eventi clone entrambi senza informazioni di Trigger. L’assenza di queste informazioni è legata al modo con cui vengono spiati i dati a livello del Sector Collector. Il fatto che venga copiato l’intero buffer di memoria per ogni L1A fa si che, se questi sono molto ravvicinati, in quelli successivi il sistema risulta occupato e non fornisce le informazioni richieste (avevamo visto che l’evento clone per la regola di Trigger appariva dopo 20BX, e nella nostra finestra temporale si vedono fino a 22 eventi dopo il BX corretto di Trigger). Altre volte invece, anziché non fornire le

60

informazioni di Trigger, viene inviato un clone del Trigger precedente. In questo caso si trattava di un vero e proprio errore di funzionamento del sistema che è stato risolto nel corso del commissioning. La netta separazione in questo run fra gli eventi di coda e quelli correlati che davano origine a ripetizioni ha permesso di analizzare le diverse condizioni separatamente. In Figura 72 sono mostrate le distribuzioni per BX e la qualità in funzione del BX per i due tipi di rumore, messi a confronto con i rispettivi grafici per gli eventi normali (Nhits<80).

Evento di cosmici normale (Nhits<80)

Evento di rumore correlato (NHits>600)

Evento di “coda” ( NHits<250)

Figura 72 Distribuzione di BX e della qualità in funzione del BX

61

In base a queste distribuzioni, per il rumore “di coda” si osserva che: • Il picco al BX corretto rimane chiaramente visibile e contiene gran parte dei segmenti di

alta qualità • Aumenta il numero dei segmenti L non correlati e anche la larghezza della loro

distribuzione nel tempo. Questo può essere causato dal rumore generato dall’elettronica che porta l’algoritmo a creare un maggior numero di ghost.

• Si osserva un numero limitato di tracce ad elevata qualità anche in BX lontani da quello in cui è stato generato il Trigger L1A. Questo può essere legato al passaggio di altre particelle all’interno della finestra temporale, che non hanno fornito un loro trigger perché soppresse dalla “regola di trigger”. Infatti non è mai presente un segmento di alta qualità oltre i 20 BX dal valore del picco della distribuzione.

Per quanto riguarda invece il rumore correlato: • Dopo il raggiungimento del valore di BX in cui è stato generato l’L1A la distribuzione in

BX diventa uniforme fino alla fine della finestra temporale per tutte le camere tranne MB4. • In tutti questi BX le qualità rimangono sempre alte, anche se è presente un’oscillazione fra

un tipo di qualità e un altro. Una ulteriore conferma del fatto che il sistema di Trigger nel rumore correlato continua a produrre segnale ogni BX si ha osservando il numero di dati di Trigger prodotti per evento. In Figura 73 si nota come nel caso di rumore (a) si ha un picco di Trigger per evento attorno a 22, esattamente per la distanza fra il BX esatto (18) e la fine della nostra finestra di Trigger (40). Nel caso di eventi normali (b) invece il numero di Trigger totale è minore.

a) b)

Figura 73 Numero di Trigger generati per evento nel rumore (a) o nei normali eventi di cosmici (b)

4.2.2 Run 17819 settore 4 wheel 1 Nel Paragrafo 3.6 studiando l’occupancy dei fili negli eventi di rumore si era notato che i fili che nei run normali non davano segnale (in quanto non sotto tensione), comparivano nel rumore correlato. Sfruttando questa caratteristica è stato effettuato il run 17819 sul settore 4 della wheel 1, dove non sono stati messi sotto tensione i fili in modo da osservare se venivano generati Trigger. Questo si è verificato con i risultati riportati in Tabella 13 , avallando ulteriormente l’ipotesi che il sistema sia sensibile a rumori di tipo elettromagnetico.

62

Run 17819 Settore 4 Wheel 1 Durata (min) 120 Eventi Acquisiti 1460 Eventi di rumore 1460 Eventi “clone” 858 Rate (Hz) 0.20 ±0.04

Tabella 13 Statistiche del Run 17819

In Figura 74 è mostrata la distribuzione del numero di hits: praticamente tutti gli eventi acquisiti avevano un numero di hits superiore alla mia definizione di rumore. E’ inoltre ben visibile il picco al limite di saturazione, insieme ad altre strutture, in particolare per Nhits≈600.

Figura 74 Numero di hits per l’evento 17819 Settore 4 Wheel 1

Si osservi ora la Matrice di Trigger per questo run riportata in Figura 75. Come nel run precedente si nota subito la grande quantità di Trigger mancanti, che come si è visto sono associati agli eventi “clone”. I restanti eventi del picco di saturazione anche in questo caso hanno generato dati di Trigger su tutte le camere. Si vede inoltre che il picco attorno a 600 ha dato sempre Trigger solo su MB4. Questo può essere dovuto al fatto che questo tipo di rumore venga in parte schermato dalla della struttura di CMS e quindi si manifesti maggiormente sulla camera più esterna. Sempre motivazioni simili possono aver dato origine ai molti eventi che hanno dato Trigger su MB1 e MB4, il che farebbe pensare ad una maggiore protezione delle camere interne (che non hanno mai fornito Trigger singolarmente).

63

Figura 75 Numero di hits in funzione delle camere con dati di Trigger

In Figura 76 è mostrata la distribuzione della qualità di Trigger in funzione del BX. Si può notare come vengano creati una grande quantità di segnali L, mentre il segnale di qualità più alta appare solo a BX successivi a quello di acquisizione (che come si è visto prima dovrebbe essere il 18). Questo potrebbe essere dovuto a un L1A generato dall’effetto del rumore su MB4, dove agisce prima, mentre solo in un secondo tempo, coinvolgendo più fili, inizia a dare Trigger di maggiore qualità anche nelle altre camere. Confrontando questo comportamento con quello del rumore correlato nei run normali sembrerebbe che la presenza di tensione sui fili contribuisca a far si che la sorgente del rumore porti il segnale sui fili sopra il valore di soglia più rapidamente.

Figura 76 Qualità del Trigger in funzione del BX

64

4.2.3 Run sul Settore 12 Wheel -1 Nei run effettuati sulla wheel -1 il settore 12 spiccava sempre per l’elevato numero di eventi di rumore, che sono risultati quasi esclusivamente di tipo “di coda” come riassunto in Tabella 14.

Run Durata (min) Eventi con trigger Eventi di rumore

Eventi di rumore con NHits<250

32177 90 28748 10768 10756 32175 83 26871 9914 9902 32184 80 26814 11332 11321 32180 40 13992 5434 5429 32179 50 16657 6499 6455 36702 90 28411 10768 10756

Tabella 14 Eventi di rumore nei run sul Settore 12 della Wheel -1.

Approfondendo il problema ho notato come nella distribuzione degli hits per evento fosse sempre presente un picco per un valore insolitamente elevato (attorno a 50 hits, Figura 77), che faceva si che la coda di eventi che rientravano nella mia definizione di rumore fosse molto maggiore del solito (vi rientravano più di un terzo degli eventi).

Figura 77 Numero di hits per evento nel run 36702

Il problema era legato alla MB3 e in particolare alla presenza di una zona contenente alcune celle molto rumorose nel SL Ф1, come mostrato in Figura 78.

65

Figura 78 Caratteristiche di MB3: in alto a sinistra numero di hits; in alto a destra Time-Box; in basso Occupancy della camere (dove si nota l’assenza del segnale in una parte dei super-layers corrispondente a una ROB.

Avere un rumore di elettronica così forte e in una zona estremamente ristretta si offre come caso limite per valutare l’impatto degli eventi di “coda” sul sistema di trigger. Nei run sulla wheel -1 erano mascherati i segmenti L, ma nonostante la mancanza di queste informazioni si può notare come il picco nella distribuzione di BX non appaia alterato (Figura 79).

Figura 79 Distribuzione del BX per il run36702

Quindi già solo la configurazione di Trigger a livello di camera “HanyTheta” è in grado di filtrare un rumore di elettronica, anche elevato e in una zona ristretta come in questo caso, in modo molto efficiente, cosa che rafforza la conclusione che per eventi con Nhits limitato gli effetti sul sistema di trigger siano trascurabili. 4.2.4 Osservazioni Generali sui dati di Trigger Gli esempi riportati ci permettono di trarre importanti conclusioni su come appaiono gli eventi di rumore dal punto di vista del trigger rispetto a quanto visto per l’acquisizione dati. Innanzitutto la presenza del rumore produce effetti in entrambi i sistemi: nel primo si osserva un aumento degli hits, nell’altro si ha un maggior numero di tracce, in particolare di tipo L.

66

Questo ci porta quindi a restringere l’origine del rumore stesso ai fili o all’elettronica di front end, comuni ad entrambi i sistemi. Inoltre si è visto come negli eventi di “coda” con Nhits<250 il sistema di trigger continui a funzionare senza particolari deviazioni per le qualità utili a generare l’L1A. Invece negli eventi ad elevata molteplicità il comportamento dei due sistemi si rivela diverso, in quanto rispecchia un differente comportamento nei confronti del segnale proveniente dai fili. Infatti i TDC sono sensibili solo alla salita del segnale, e quindi, in presenza di rumore prolungato nel tempo effettuano un’unica acquisizione al primo L1A ricevuto. Invece i BTI (che campionano a livello logico) a ogni BX processano il loro algoritmo tenendo conto dello stato del segnale in ingresso, e quindi generano dati di trigger a 40MHz per l’intera durata dell’evento di rumore. Questo effetto è soppresso nel commissioning dalla “regola di Trigger”, ma per valutare il comportamento nella configurazione finale a LHC va tenuto in considerazione. 4.4. Emulazione e rumore CMSSW oltre a essere in grado di fornire la completa simulazione dell’esperimento (Paragrafo 3.1) è anche in grado di emulare il sistema di Trigger. Un altro aspetto che ho voluto indagare nello studio del rumore è stato il comportamento di tale emulatore in sua presenza. Ho quindi utilizzato un opportuno modulo di tipo producer per l’emulazione del DTBX. Questo prende come sorgente dei dati nell’evento i digi e restituisce i dati di trigger come arrivano sul Sector Collector. L’emulatore simula anche la sincronizzazione dei dispositivi, utilizzando parametri[ ]21 calcolati a partire da dati reali ed inseriti in opportuni database. Il fatto di lavorare partendo dai digi prodotti da cosmici pone grossi problemi in quanto non sono sincronizzati come invece saranno le particelle prodotte a LHC. E’ quindi necessario avere a disposizione opportuni database che tengano conto di questo fattore per i dati di commissioning. Inoltre l’emulatore ricerca i digi solo all’interno della Time-Box prevista. Quindi non sarà in grado di fornirci informazioni accurate per gli eventi di rumore che generano “cloni” in quanto solo i digi creati all’inizio del periodo rumoroso sono all’interno della Time-Box. Negli eventi successivi quindi ci si aspetta che, non trovando digi, non dia origine ad informazioni di Trigger. Dove erano disponibili i parametri adatti per i run di commissioning si è verificato l’ottimo accordo per gli eventi con Nhits<80 nel ricostruire i segmenti all’interno delle singole camere, come mostrato nella matrice di Trigger in Figura 80.Le uniche inefficienze notate per questi eventi sono legate ai trigger singoli su MB4 nei dati reali, che spesso non apparivano in quelli emulati. Questo può essere dovuto a una non perfetta corrispondenza fra il file che descrive la camera e la sua reale posizione o configurazione. Anche fra le qualità l’accordo è molto elevato, come mostrato in Figura 81.

67

Figura 80 Confronto fra la matrice di Trigger generate dai dati reali e quella ottenuta da quelli emulati

a) b)

Figura 81 Confronto fra le qualità dei dati reali (a sinistra) ed emulati (a destra)

In Figura 82 è mostrato il confronto fra le matrici di Trigger per gli eventi di rumore. Anche in questo caso l’accordo a questo livello appare ottimo.

68

Figura 82 Confronto fra la matrice di Trigger generate dai dati reali e quella ottenuta da quelli emulati per gli eventi con Nhits>80

In questo caso si nota che gli eventi “persi” dall’emulazione sono in numero inferiore di quelli senza trigger nei dati reali. Per capire l’origine di questi trigger ho confrontato le matrici di trigger reale ed emulata in funzione del Nhits nel settore (Figura 83).

Figura 83 Numero di hits nel settore in funzione della matrice di Trigger per eventi reali (sinistra) ed emulati (destra)

Si è verificata la presenza di eventi con Nhits≈1500 con trigger nell’emulatore ma non nei dati reali, dove erano stati classificati come “cloni”. Questi eventi sono da associare alla presenza sui fili, oltre degli hits “clone”, di nuovi hits generatosi all’L1A successivo. Questo indica che, anche durante gli eventi di rumore alcuni fili possono scendere sotto il valore di soglia e poi risalire, dando origine a nuovi hits nei registri dei TDC. A una “oscillazione” dei fili accesi durante il rumore può anche essere legata la modulazione in qualità in funzione del BX vista in Figura 72. Nonostante il buon accordo trovato la nostra analisi con l’emulatore non è potuta procedere oltre. Infatti utilizzare gli emulatori per le fasi successive del sistema di trigger non produce risultati affidabili, visti i problemi di sincronizzazione legati alla natura stessa dei raggi cosmici. A questo si somma il fatto che l’emulatore, concepito per LHC, ricostruisce le tracce tenendo conto del campo magnetico e del passaggio per il vertice. Non è stato quindi possibile usare i nostri dati nell’emulatore per il Track Finder.

69

4.5 Ricostruzione di “tracce” di Trigger Le considerazioni fatte finora hanno riguardato tutti i segmenti generati da ogni camera all’interno della finestra temporale presa in considerazione, in modo da comprendere nel modo migliore possibile il comportamento del Trigger locale. Per capire come il rumore possa avere effetto sul trigger di primo livello è necessario capire come i dati visti finora vengano elaborati successivamente, in particolare a livello del Track Finder, dato che si è sempre lavorato a livello di settore. Non essendo stato possibile usare l’emulatore e non avendo nei nostri dati informazioni sulla posizione e direzione delle tracce ricostruite, ho sviluppato un modello semplificato che potesse dare delle indicazioni generali. Questo consisteva nel cercare di costruire, a ogni BX, una “traccia” aggiungendo i segmenti provenienti da camere che avessero soddisfatto la condizione “HanyTheta”. In pratica, per ogni camera, aggiungevo all’ipotetica “traccia” due segmenti nel caso fossero di tipo correlato (HH, HL, LL), oppure un segmento nel caso avessi un H in concomitanza con un trigger su theta. Lavorando con un singolo settore le “tracce” potevano essere composte come minimo da un segmento (solo un H in un’unica camera), fino a un massimo di 8 (2 segmenti correlati in ogni camera). Vediamo i risultati ottenuti prendendo come esempio il run 15278 del Settore 12 Wheel 0, già utilizzato nel Paragrafo 4.2.1. Nel caso di cosmici ho ottenuto un numero molto limitato di “tracce” in più camere, soprattutto nei settori maggiormente inclinati (Figura 84a). Questo è dovuto sia al fatto che il muone, vista la posizione del settore, attraversi solo una o due camere, sia alle difficoltà di sincronizzazione per i cosmici che portano segmenti generati dallo stesso muone a essere rivelate in BX differenti nelle diverse stazioni. Infatti osservando la distribuzione in BX si nota come il numero di tracce nei due BX 18 e19 sia circa uguale e comprenda gran parte del segnale.

a) b)

Figura 84 Per eventi di cosmici: a)Numero di tracce ricostruite in base al numero di segmenti di cui sono composte, b)numero di segmenti nelle tracce ricostruite per ogni BX della finestra

La situazione cambia radicalmente quando si considerano gli eventi di rumore correlato (Figura 85).

70

a) b)

Figura 85 Per eventi di rumore correlato: a)Numero di tracce ricostruite in base al numero di segmenti di cui sono composte, b)numero di segmenti nelle tracce ricostruite per ogni BX della finestra:

In questo caso i segmenti sono molto più fortemente correlati nello stesso BX, fornendo nella maggior parte di casi “tracce” che attraversano 3 o 4 camere. Inoltre le “tracce” non sono legate al BX “corretto”, anzi il massimo delle “tracce” a più elevata estensione si trova successivamente,in accordo con la generazione di trigger a ogni BX per eventi continuati che si è osservato in precedenza. Si trova anche in questo caso un effetto di “modulazione” come visto per le qualità, che sembra riproporre massimi nelle diverse fasce ogni 18±2 BX. Se consideriamo la Figura 85a notiamo come il 30% delle “tracce” di Trigger è almeno composta da almeno 6 segmenti. Quindi per ogni evento di rumore che genera ripetizioni registrato nel commissioning, abbiamo 20 BX successivi in cui viene prodotto Trigger, in cui 6-7 hanno “tracce” di almeno 6 segmenti. Naturalmente queste non sono vere e proprie tracce, non avendo io informazioni su come siano disposte spazialmente, ma questo modello mi fornisce una stima superiore della qualità degli oggetti di livello superiore prodotti dal rumore correlato. Inoltre, come descritto nel Paragrafo 3.9, il rumore correlato tende ad estendersi contemporaneamente su più settori, quindi è in grado, allo stesso BX, di generare tracce correlate all’interno di numerose zone del barrel. Come esempio è riportato in Figura 86 il numero di settori negli eventi di rumore con tracce composte di almeno 4 segmenti, per un run della Wheel 1 comprendente 6 settori. Nonostante siano dominanti i casi in cui è un singolo settore ad avere una “traccia”, c’è un elevato numero di casi con più tracce per BX, pari a circa il 15% dei Triggers.

Figura 86 Numero di settori con tracce in almeno 2 camere al variare del BX per eventi di rumore su un run della Wheel 1.

71

4.6 Effetto del rumore correlato sui rate di Trigger Per capire come il rumore possa incidere sul rate degli eventi triggerati occorre innanzitutto dare una stima della frequenza del rumore stesso. Per prima cosa ho escluso il rumore con Nhits<250 in quanto legato alla coda degli eventi cosmici normali (e non in grado di dare origine a Trigger autonomamente), e mi sono soffermato sul rumore ad elevata molteplicità di hits . Come si è visto questo rumore appare in modo molto aleatorio nei vari run: può essere completamente assente, apparire ad alta frequenza per un breve periodo o a bassa frequenza su lunghi tempi di acquisizione. Volendo esclusivamente una stima dell’ordine di grandezza della frequenza a livello di settore, ho quindi calcolato un valore di riferimento utilizzando i dati raccolti su tutti i 60 run analizzati. Il campione può apparire non omogeneo ma in verità non è mai apparsa una correlazione fra forma e posizione del settore e il rate del rumore correlato, tanto che come abbiamo visto un settore può presentare differenti valori di tale rate in ogni run. La frequenza di rumore correlato da me stimata risulta:

νrumore = (0.018±0.004) Hz Di questo rumore il rate di eventi facenti parte di ripetizioni (comprendendo quindi sia il “generatore” di cui si hanno informazioni di trigger, sia i “cloni” che ne sono privi):

νripetizioni = (0.015±0.004) Hz A ogni evento di questo tipo, in assenza della “regola di Trigger” corrispondono 20 Triggers, portando il rate a

νrumore correlato = (0.30±0.08) Hz Questo valore mi porta a considerare trascurabile il rate di eventi ad alta molteplicità che non generano ripetizioni (che sarebbe 0.003± 0.004 Hz) in quanto il suo valore è inferiore all’incertezza. Mi aspetto quindi un rate di (0.30±0.08) Hz di trigger almeno fino al livello del DTBX. Per capire la rilevanza di questo rumore ho voluto confrontarlo con i rates attesi a LHC. Questi sono espressi a livello dell’intero sistema, ma visto che il rumore correlato, quando si presenta, tende a coinvolgere ampie zone dell’esperimento contemporaneamente, ritengo che il rate di rumore non aumenti in modo sensibile a livello di barrel rispetto al suo valore per settore, e possa essere considerato come ordine di grandezza inferiore a 1 Hz. Su questo valore mi aspetto non influisca neanche la grande differenza nel rate di acquisizione fra gli eventi di cosmici e quelli a LHC, in quanto dagli studi effettuati nel Paragrafo 3.8 non è stata messa in luce una dipendenza il rate di acquisizione e il rate di rumore correlato. In Figura 87 è mostrato il rate atteso per un singolo muone avente impulso superiore a una soglia Pt

cut. Tenendo conto che la soglia per muoni a grande angolo è solitamente PTcut=25 Gev (linea rossa

in figura), il nostro rumore (punto rosso nel grafico) risulta inferiore di circa 3 ordini di grandezza, quindi trascurabile.

72

Figura 87 Rate per un singolo muone (|η|<2.4) definito come il numero di eventi con almeno un muone con impulso sopra una soglia Pt

cut.

Si è visto che coinvolgendo più settori il rumore considerato è in grado di generare più tracce di muoni nello stesso BX. Quindi tale rumore potrebbe interferire nelle regole di trigger per 2 µ, fondamentale per molti canali di ricerca per il bosone di Higgs (vedi Paragrafo 1.2.2). Come si è visto circa il 15% degli eventi di rumore danno tracce in almeno 2 settori, quindi il rate di rumore in grado di dare un segnale simile a quello per 2µ è come ordine di grandezza ~0.1 Hz. Il rate aspettato per 2 µ aventi entrambi impulso superiore a un valore di soglia Pt

cut è mostrato in Figura 88. Dalla figura si nota come con il Pt

cut che verrà solitamente utilizzato (5 Gev) il rate previsto è sempre di 3 ordini di grandezza superiore a quello del rumore qui studiato, che anche in questo caso risulta trascurabile.

Figura 88 Rate di due muoni (|η|<2.4) definito come il numero di eventi con almeno due muoni con Pt sopra una soglia Pt

cut.”MB 2mu” si riferisce a eventi con entrambi i muoni provenienti da decadimenti adronici. “MB mix” si riferisce a muoni provenienti da top, W o Z.

73

In conclusione , il rumore correlato con il rate con cui si è presentato al commissioning, non rappresenta un problema per il trigger di eventi di fisica a LHC che hanno rate notevolmente superiori. Quindi l’unico effetto di questo rumore è di “accecare” il rivelatore episodicamente per periodi di tempo pari a mezzo millisecondo. 4.7 Ipotesi sull’origine del rumore correlato Dai dati raccolti è possibile fare alcune osservazioni sul rumore più problematico, ovvero il rumore correlato prolungato nel tempo. Innanzitutto si tratta di un rumore non legato al segnale fisico. Infatti, come si è visto nel Paragrafo 4.3.2, viene rilevato anche in assenza di tensione sui fili, quindi non può essere generato col normale meccanismo di ionizzazione del gas al passaggio di una particella nella cella. Inoltre il fatto che il rumore venisse rilevato sia dai TDC che dai BTI mi porta a supporre che la sua origine sia nell’elettronica di Front-End che fornisce i segnali in ingresso ad entrambi questi dispositivi. Il fatto che il rumore si mostri in modo correlato in ampie parti dell’esperimento porta a interpretarlo come un rumore “di modo comune”. Si tratta una tipologia di rumore ben conosciuta in elettronica ed è dovuta a un segnale di interferenza che entra nel sistema attraverso la sua stessa terra, che è in comune con altri strumenti, come mostrato in Figura 89. Visto che il rumore appare legato all’elettronica di Front-End si può ipotizzare entri nel sistema attraverso la distribuzione delle basse tensioni. Indizi in questo senso provengono dalle matrici di correlazione fra diversi settori delle wheel (Tabella 9), dove settori più correlati si trovano sulle stesse linee di alimentazione di questo tipo di tensioni. Nei casi in cui il rumore era poi più localizzato questo poteva essere originato da radiazione elettromagnetica, entrata nel sistema a causa di mancanza di schermatura in alcuni fili di collocamento. E’ in corso un controllo delle schermature e un loro miglioramento per evitare effetti di questo tipo.

Figura 89 Schema di un rumore “di modo comune”

Nei dati legati all’evoluzione della risposta del sistema di trigger al rumore nel tempo, ho notato un carattere di tipo “oscillatorio”. Ad esempio questo si è visto nel modo in cui la qualità variava nel tempo (Figura 72), e lo si è ritrovato anche nel semplice modello di ricostruzione tracce (Figura 85a). Considerando vari campioni si arriva a stimare una distanza fra i massimi pari a (18±2) BX. Se questo valore fosse direttamente legato alle caratteristiche della sorgente del rumore questa avrebbe una frequenza di qualche MHz, ovvero apparterrebbe alla categoria delle onde HF (High Frequency). Queste frequenze sono presenti in saldatori che utilizzano campi elettrici o magnetici ad alta frequenza per portare i metalli ad alta temperature e coprono un range fra i 300kHz e i 3 MHz. Sono stati effettuati test su CMS[ ]22 verificando la reazione del sistema all’accensione dei sistemi di saldatura collegati alla stessa alimentazione centrale ( e quindi stessa terra) e si sono effettivamente

74

osservati burst di rumore dello stesso tipo di quelli già osservati nel corso dei run di commissioning. Si è inoltre verificato come questo rumore venisse rilevato sia dalla DT che dalle CSC, coinvolgendo quindi l’intero sistema di rivelazione di muoni. Questa causa spiega molto bene i run dove il rumore correlato si presenta per lunghi periodi, ma probabilmente non è l’unica causa. Spesso si sono osservati eventi di rumore correlato di brevissima durata, o a orari non lavorativi, che è difficile imputare al funzionamento in contemporanea con l’esperimento di un’apparecchiatura di saldatura. In ogni caso si è visto come il sistema DT sia sensibile al rumore “di tipo comune”. Nel funzionamento a LHC naturalmente non saranno presenti saldatori o altri strumenti di lavoro usati in fase di montaggio, ma nuove sorgenti di rumore potranno essere rappresentate dall’accensione in contemporanea con gli altri sotto-rivelatori di CMS, da cui durante il commissioning le DT erano isolate. In particolare potranno causare problemi l’alimentazione per i calorimetri e per il raffreddamento del magnete. Al fine di evitare complicazioni di questo tipo si sta studiando il modo di disaccoppiare le masse per i diversi sistemi elettronici. Le analisi che ho effettuato a livello del commissioning hanno fornito interessanti indicazioni sull’aspetto di questo tipo di rumore, che si riveleranno utili per monitorarlo in futuro.

75

Conclusioni Il lavoro di tesi è stato svolto sull’analisi del rumore correlato presente nei dati del commissioning per le camere di tubi a deriva, al fine di valutarne l’impatto sul sistema di Trigger. Il commissioning consiste in una serie di test volti a verificare funzionalità ed efficienza dell’esperimento dopo il suo montaggio. In particolare grazie alla presenza dei muoni cosmici è possibile avere a disposizione una sorgente di particelle rilevabili dal sistema. E’ durante i test con questo tipo di muoni che all’interno del sistema è stato rilevato un nuovo tipo di rumore caratterizzato da un’elevata molteplicità di hits. Nell’ambito del lavoro di tesi ho sviluppato un programma per lo studio di questo tipo di rumore utilizzando il software di Analisi Dati e Ricostruzione ufficiale di CMS (CMSSW). Ho utilizzato tale programma sui dati raccolti durante 60 runs di commissioning eseguiti fra l’Aprile 2007 e il Febbraio 2008. La mia analisi, effettuata inizialmente studiando ogni settore singolarmente, ha interessato gli eventi che presentavano un Nhits>80, che venivano esclusi dagli altri studi effettuati sui dati di commissioning. Ho potuto classificare gli eventi considerati in due categorie. La prima, che comprende eventi con Nhits < ~250, è composta da eventi triggerati da muoni cosmici, in cui si osserva la presenza di rumore generato dall’elettronica in parti localizzate del rivelatore, generalmente il layer esterno di MB3, e le celle poste alle estremità delle camere. Questi eventi presentano un rate, dipendente dal rumore dell’elettronica di ciascun settore, generalmente dell’ordine di 10-1 Hz. Essendo un rumore casuale e non in grado di generare trigger in maniera indipendente, il suo rate risulta legato a quello di acquisizione. Ho potuto osservare ciò effettuando confronti fra settori aventi rate di acquisizione di muoni cosmici diversi a causa della loro orientazione. La seconda categoria contiene eventi con una più elevata molteplicità, dai 600 hits per settore fino ad arrivare a un valore di saturazione determinato dalla dimensione dei buffer di memoria dei dispositivi di acquisizione. La principale caratteristica di questi eventi è di essere nella maggior parte dei casi generati da un segnale prolungato nel tempo, che si manifesta all’interno dell’elettronica di Front-end, collegata simultaneamente ai dispositivi di Acquisizione Dati (TDC) e a quelli di Trigger (BTI). Il TDC registra un hit solo in concomitanza con il fronte del segnale. Questi hits si presentano correlati topologicamente (distribuendosi nella maggior parte dei casi in modo uniforme all’interno del settore) e temporalmente (dando un segnale all’interno della Time-Box prevista). Gli eventi di questo tipo non si distribuiscono in modo uniforme nel corso dei runs, ma presentano rates variabili le range 0-0.7 Hz, con una frequenza media per i run analizzati dell’ordine di 10-2 Hz. Dal punto di vista del sistema di trigger ho verificato come questo rumore dia origine a un segnale di trigger senza che nessuna particella attraversi il rivelatore. Inoltre il risultato dell’algoritmo implementato dai BTI dipende solo dallo stato del segnale logico proveniente dal Front-end, quindi durante il rumore venivano generate tracce di trigger ad ogni BX. Questo porta anche all’acquisizione degli stessi hits dei TDC (spostati nel tempo) a ogni nuovo trigger generato, cosa che nel commissioning, a causa delle regole di Trigger utilizzate, avviene ogni 20 BX. Visto che a LHC non sarà presente nessun tempo morto, il rate risultante sarà aumentato di un ordine di grandezza, ovvero risulterà circa 10-1Hz. Il trigger generato è di alta qualità e sincronizzato fra le varie camere, cosa che rende possibile la ricostruzione di tracce che attraversano l’intero settore. Inoltre, dove sono disponibili i dati

76

“originali” acquisiti, ho potuto anche emulare questo tipo di trigger con un ottimo accordo con i dati reali. Alla luce di queste caratteristiche ho voluto stimare se questo rumore fosse in grado di generare trigger a rate comparabili con quelli dei processi fisici. Ho dovuto inizialmente valutare in che modo il rate di rumore scalasse all’aumentare dei settori e del rate di acquisizione. Gli studi che ho effettuato con più settori su una stessa wheel hanno mostrato come il rumore si presentasse nella maggior parte dei casi simultaneamente in tutti. Questo comporta che il rumore possa simulare il passaggio di più muoni nel barrel allo stesso BX, ma mostra come il rate complessivo non scali all’aumentare dei settori. Inoltre, analizzando settori che per forma e orientazione hanno rate di acquisizione di cosmici notevolmente diversi, non si è trovata una dipendenza fra il numero di eventi acquisiti e la quantità di rumore presentatosi. Sulla base dell’analisi effettuata, ho potuto stimare un rate di rumore correlato inferiore ad 1Hz. Questo valore risulta trascurabile a LHC sia rispetto al rate per il singolo muone, sia per la coppia di muoni prodotta allo stesso bunch crossing , entrambi dell’ordine dei 103Hz. Inoltre esistono forti indicazioni, legate alle caratteristiche osservate e a studi effettuati direttamente sull’esperimento, che una delle fonti di questo rumore durante gli orari di lavoro (dove il rate è risultato maggiore) possano essere strumenti quali i saldatori. Naturalmente apparecchi di questo tipo non saranno attivi durante il funzionamento dell’acceleratore, ma vista la sensibilità mostrata dal sistema delle DT a un rumore “di tipo comune”, problemi simili potrebbero ripresentarsi quando funzionerà in contemporanea con tutti gli altri sottorivelatori ed apparati di CMS. Per ovviare a questo problema sono sotto studio miglioramenti per isolare e disaccoppiare il segnale di massa dell’elettronica.

77

Indice delle Figure Capitolo 1 Figura 1 Rappresentazione schematica di LHC e dei 4 apparati sperimentali. ................................................................... 3 Figura 2 Sezioni d’urto per diverti processi fisici a LHC ................................................................................................... 5 Figura 3 Diagrammi di Feynman per i processi di produzione di Higgs a LHC ................................................................ 6 Figura 4 Sezioni d’urto per la produzione di H0 in funzione della sua massa ................................................................... 7 Figura 5 Rapporto di decadimento in funzione di MH ....................................................................................................... 7 Figura 6 Osservabilità del bosone di Higgs in funzione della sua massa a LHC alla luminosità integrata L=105 pb-1 (su

un anno di funzionamento)........................................................................................................................................ 8 Figura 7 Spaccato dell’esperimento CMS ......................................................................................................................... 9 Figura 8 (a) Vista trasversale della regione del barrel del rivelatore CMS. (b) Vista longitudinale di un quarto

dell’apparato............................................................................................................................................................ 10 Figura 9 Spaccato dell’esperimento CMS ....................................................................................................................... 11 Figura 10 Visione trasversale di una cella di un tubo a deriva, mostrate le linee di deriva isocrone per una tipica

configurazione di voltaggio degli elettrodi.............................................................................................................. 13 Figura 11 Sezione schematica di una camera a muoni del barrel. ................................................................................... 14 Figura 12 Risoluzione dell’impulso per tracce di muoni simulati a valori selezionati di Pt utilizzando unicamente hits

dai rivelatori di muoni e la condizione di passaggio dal vertice.............................................................................. 14 Figura 13 Risoluzione dell’impulso per tracce di muoni simulati a valori selezionati di Pt utilizzando hits dai rivelatori

per muoni combinati con gli hits rilevati dal tracker............................................................................................... 15 Capitolo 2 Figura 14 Flusso dei dati nel sistema di Trigger di CMS. ............................................................................................... 16 Figura 15 Schema del sistema di Trigger di livello 1 ...................................................................................................... 17 Figura 16 Schema del sistema di Trigger dei muoni. ....................................................................................................... 18 Figura 17 Architettura del sistema DAQ di CMS............................................................................................................. 19 Figura 18 Sistema locale di Trigger e Acquisizione dati per Camere di tubi a deriva..................................................... 20 Figura 19 Fotografia dell’assemblaggio di un Mini-crate................................................................................................ 20 Figura 20 Sistema di riferimento dei BTI ........................................................................................................................ 21 Figura 21 Struttura del Track Correlator ......................................................................................................................... 22 Figura 22 Parametri calcolati dal Track Correlator. ........................................................................................................ 22 Figura 23 Struttura generale del sistema Trigger Server. Sono mostrati tutti i dispositivi e le connessioni, oltre alle

board sui quali sono montati. .................................................................................................................................. 23 Figura 24 Schema del sistema regionale di Trigger......................................................................................................... 24 Figura 25 Posizione e collegamenti del Sector Collector ................................................................................................ 24 Figura 26 Flussi di dati all’interno della scheda del Sector Collector ............................................................................. 25 Figura 27 Schema a blocchi dell’algoritmo del Phi Track Finder ................................................................................... 26 Figura 28 Schema dell’ ETTF ......................................................................................................................................... 27 Figura 29 Struttura di un TDC......................................................................................................................................... 28 Figura 30 Disposizione dei TDC in una ROB ................................................................................................................. 28 Figura 31 Collocazione delle schede ROS e SC in una torre di CMS ............................................................................. 29 Capitolo 3 Figura 32 Eventi di rumore per un settore (a) e per più settori (b) come visto dalla schermata del DQM ...................... 30 Figura 33 a) Arrivo di una wheel all’interno della caverna sotterranea b) Vista frontale di una Wheel nella caverna di

CMS. ....................................................................................................................................................................... 31 Figura 34 Sciame cosmico con generazione di µ rilevato da CMS ................................................................................. 32 Figura 35 Technical Trigger per un settore....................................................................................................................... 33 Figura 36 Technical Trigger per più settori ..................................................................................................................... 34 Figura 37 Rate di acquizioni per settore durante i run di cosmici.................................................................................... 34 Figura 38 Struttura a moduli di CMSSW ........................................................................................................................ 35 Figura 39 Organizzazione dei dati nell’ambiente di lavoro di CMSSW.......................................................................... 36 Figura 40 a) Numero di Hits per eventi normali b) Numero di Hits per eventi di rumore per il Settore 4 Wheel 1......... 37 Figura 41 a) Numero di Hits per eventi normali b) Numero di Hits per eventi di rumore per il Settore 12 Wheel 0..... 38 Figura 42 Numero di hits per layer in MB1 del Settore 4 Wheel 0 ................................................................................. 38 Figura 43 Numero di hits per super-layer per MB1 del Settore 4 Wheel 0 ..................................................................... 38 Figura 44 Hits per camera per il per il settore 4 wheel 1 ................................................................................................. 39 Figura 45 Occupancy dei fili per un run del settore 8 wheel 1 ......................................................................................... 40

78

Figura 46 Occupancy dei fili per gli eventi di rumore per un run del settore 8 Wheel 1 .................................................. 40 Figura 47 Muone che attraverso 3 camere del Settore 8................................................................................................... 41 Figura 48 Esempi di Eventi rumorosi ............................................................................................................................... 42 Figura 49 Time-Box di un layer per eventi normali ........................................................................................................ 43 Figura 50 a) Time-Box con afterpulse generato da un filo rumoroso b) Time-Box dove un filo produce rumore in modo

uniforme nel tempo ................................................................................................................................................. 43 Figura 51 Time-Box per eventi di rumore ....................................................................................................................... 43 Figura 52 Time-Box per eventi di rumore correlato nel settore 4, wheel 1 ...................................................................... 44 Figura 53 Shift temporale per gli eventi ripetuti.............................................................................................................. 45 Figura 54 Numero di hits per livello di ripetizione.......................................................................................................... 46 Figura 55 Time-Box settore 4 per eventi di rumore eliminando le ripetizioni.................................................................. 46 Figura 56 Numero di hits per evento in MB1 e MB2 per eventi normali (a) e di rumore (b).......................................... 47 Figura 57 Valore del coefficiente di correlazione fra i layers di un settore per eventi normali (a) e di rumore (b)......... 48 Figura 58 Evoluzione del numero degli hits al trascorrere degli eventi per il rumore..................................................... 49 Figura 59 Confronto Rate acquisizione e rate rumore con Nhits<250 per i settori della Wheel 1..................................... 51 Figura 60 Confronto Rate acquisizione e rate rumore correlato per i settori della wheel 1............................................. 51 Figura 61 Rate rumore correlato in funzione dell’ora...................................................................................................... 52 Figura 62 Distribuzione degli hits nel run 33958 ............................................................................................................ 53 Figura 63 Numero di settori che risultano contemporaneamente rumorosi nel run 34762 della wheel 1........................ 54 Capitolo 4 Figura 64 Associazione del BX nel Sector Collector ...................................................................................................... 56 Figura 65 Distribuzione dei valori di BX misurati per camera......................................................................................... 57 Figura 66 Codice di qualità per eventi di cosmici ............................................................................................................ 58 Figura 67 Quality vs Bx per cosmici in un settore 4......................................................................................................... 58 Figura 68 Matrice di Trigger per il Settore 12 Wheel 0................................................................................................... 59 Figura 69 Numero di hits per evento nel run 15278 ........................................................................................................ 59 Figura 70 Matrice di Trigger per gli eventi di rumore nel run 1527................................................................................ 60 Figura 71 Numero di hits nel settore rispetto alle camere che hanno dato segnali di Trigger ......................................... 60 Figura 72 Distribuzione di BX e della qualità in funzione del BX.................................................................................. 61 Figura 73 Numero di Trigger generati per evento nel rumore (a) o nei normali eventi di cosmici (b)............................ 62 Figura 74 Numero di hits per l’evento 17819 Settore 4 Wheel 1 ..................................................................................... 63 Figura 75 Numero di hits in funzione delle camere con dati di Trigger .......................................................................... 64 Figura 76 Qualità del Trigger in funzione del BX ........................................................................................................... 64 Figura 77 Numero di hits per evento nel run 36702 ........................................................................................................ 65 Figura 78 Caratteristiche di MB3: in alto a sinistra numero di hits; in alto a destra Time-Box; in basso Occupancy della

camera. .................................................................................................................................................................... 66 Figura 79 Distribuzione del BX per il run36702 ............................................................................................................. 66 Figura 80 Confronto fra la matrice di Trigger generate dai dati reali e quella ottenuta da quelli emulati ....................... 68 Figura 81 Confronto fra le qualità dei dati reali (a sinistra) ed emulati (a destra) ............................................................ 68 Figura 82 Confronto fra la matrice di Trigger generate dai dati reali e quella ottenuta da quelli emulati per gli eventi

con Nhits>80 ............................................................................................................................................................. 69 Figura 83 Numero di hits nel settore in funzione della matrice di Trigger per eventi reali (sinistra) ed emulati (destra)

................................................................................................................................................................................ 69Figura 84 Per eventi di cosmici: a)Numero di tracce ricostruite in base al numero di segmenti di cui sono composte,

b)numero di segmenti nelle tracce ricostruite per ogni BX della finestra .............................................................. 70 Figura 85 Per eventi di rumore correlato: a)Numero di tracce ricostruite in base al numero di segmenti di cui sono

composte, b)numero di segmenti nelle tracce ricostruite per ogni BX della finestra:............................................ 71 Figura 86 Numero di settori con tracce in almeno 2 camere al variare del BX per eventi di rumore su un run della

Wheel 1. .................................................................................................................................................................. 71 Figura 87 Rate per un singolo muone (|η|<2.4) definito come il numero di eventi con almeno un muone con impulso

sopra una soglia Ptcut............................................................................................................................................... 73

Figura 88 Rate di due muoni (|η|<2.4) definito come il numero di eventi con almeno due muoni con Pt sopra una soglia Pt

cut.”MB 2mu” si riferisce a eventi con entrambi i muoni provenienti da decadimenti adronici. “MB mix” si riferisce a muoni provenienti da top, W o Z............................................................................................................ 73

Figura 89 Schema di un rumore “di modo comune”…….……………………………………………………………….73

79

Indice delle Tabelle Tabella 1 Principali parametri funzionali di LHC 4 Tabella 2 Precisione dell’output del DTTF per differenti intervalli di Pt. 26 Tabella 3 Setup sperimentale utilizzato per i run di cosmici 36 Tabella 4 Valore del coefficiente di correlazione fra le camere di un settore per eventi non di

rumore 48 Tabella 5 Valore del coefficiente di correlazione fra le camere di un settore per eventi di rumore 48Tabella 6 Informazioni sul rumore su 3 run sul settore 6 della wheel 2 50 Tabella 7 Dati di rate per i settori della Wheel 1 50 Tabella 8 Rate di acquisizione e rumore per un run della wheel 1 53 Tabella 9 Tabella di Correlazione fra i settori del run 33958 53 Tabella 10 Contenuto dati spiati provenienti dal Sector Collector 56 Tabella 11 Codici di qualità per l’output del TRACO 57 Tabella 12 Informazioni sul Run 15278 59 Tabella 13 Statistiche del Run 17819 63 Tabella 14 Eventi di rumore nei run sul Settore 12 della Wheel -1. 65

80

81

Bibliografia [1] R. Barate et al. Search for the standard model Higgs boson at LEP. Phys Lett., B565:61-75,

2003. [2] E. Tournefier. Electroweak results from LEP and SLC and test of the standard model.

2001. hep-ex/0105091. [3] Dean Bomeštar. SM Higgs Search at LHC. CMS TN/95-156. Novembre 1995. [4] CMS Tracker Technical Design Report, CERN/LHCC 98-006, Aprile 1998. [5] CMS Electromagnetic Calorimeter Technical Design Report, CERN/LHCC 97-031, Giugno

1997. [6] CMS Muon Technical Design Report, CERN/LHCC 98-006, Aprile 1998. [7] The Trigger and Data Acquisition project: Technical Design report , CERN/LHCC 2002-

26. [8] R. Travaglini, Design and test-experiment of the Trigger electronics for the muon Drift

Tube chambers of the CMS detector at LHC, Tesi di Dottorato, 2004. [9] National Semiconductor, An overview of LVDS technology. Application Note 971, Luglio

1998. [10] Luigi Guiducci, Design and Test of the Off-Detector Electronics for the CMS Barrel Muon

Trigger, Tesi di Dottorato, Marzo 2006. [11] C.F. Bedoya, J. Marin, J.C. Oller, C. Willmott, Overview of the Read-Out System for the

CMS Drift Tube Chambers , 9th Workshop on Electronics for LHC Experiments, Amsterdam Ottobre 2003.

[12] J. Christiansen, High Performance Time to Digital Converter, CERN/EP-MIC. Luglio

2002. [13] C.F. Bedoya, Commissioning Status and Planning Overview, CMS Week, 11 Dicembre

2007. [14] L. Guiducci, DT Trigger Sector Collector Synchronization, control and monitoring:

Status and Plans, Muon Barrel Workshop, 19 Ottobre 2007 [15] CAEN, Mod. V976 4 Fold Coincidence/Fan in Fan out/Translator . Techincal Manual,

Gennaio 2003 [16] CMS Software Page, http://cmsdoc.cern.ch/cms/cpt/Software/html/General/ [17] Rene Brun & Fons Rademakers, Root User’s Guide v 5.16, http://root.cern.ch/root/doc/ RootDoc.html , Luglio 2007

82

[18] C. Battilana, F.R. Cavallo, S. Marcellini, Trigger performance analysis on wheel commissioning data, Muon Barrel Workshop at CERN, Ottobre 2007. [19] John R. Taylor, Lo studio delle incertezze nelle misure fisiche, Zanichelli 1997 [20] E.M. Pugh e G.H. Winslow, The analysis of Physical Measurements, Addinson-Wensley,

1966 [21] S. Bolognesi e S. Maselli, DT Calibration from Commissioning Runs: Tzero, Ttrig,

VDrift: Preliminary results, Commissining Meeting, 10 ottobre 2007. [22] Frank Geurts, CSC/DT Global Noise Run, CSC ELOG 5 Ottobre 2007

83