UNIVERSITÀ DEGLI STUDI DI TRIESTE - Infn
←
→
Trascrizione del contenuto della pagina
Se il tuo browser non visualizza correttamente la pagina, ti preghiamo di leggere il contenuto della pagina quaggiù
UNIVERSITÀ DEGLI STUDI DI
TRIESTE
Dipartimento di Ingegneria e Architettura
Laurea Triennale in Ingegneria Informatica ed
Elettronica
Studio preliminare per l’ottimizzazione di
algoritmi per l’analisi di dati del Cherenkov
Telescope Array
20 novembre 2019
Laureando Relatore
Matteo Scorcia Prof. Francesco Longo
Correlatore
Dott. Thomas Gasparetto
Anno Accademico 2018/2019
Alla mia cara famiglia, ed ai miei cari amici.
Elenco delle figure
1.1 Rendering di come sarà l’array di telescopi nel sito dell’emi-
sfero Sud[1]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Come CTA rileva la luce Cherenkov[1]. . . . . . . . . . . . . . 2
1.3 Prototipo di fotomoltiplicatore al silicio[2]. . . . . . . . . . . . 3
1.4 Linea temporale dello sviluppo di CTA[3]. . . . . . . . . . . . 4
2.1 Logo di ctapipe[4]. . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Esempio di ”Issue” ancora aperto. . . . . . . . . . . . . . . . . 7
2.3 GitHub Issues aperti[5]. . . . . . . . . . . . . . . . . . . . . . 8
2.4 Pulse time issue[5]. . . . . . . . . . . . . . . . . . . . . . . . . 9
2.5 Struttura dei dati inerenti ad un evento. . . . . . . . . . . . . 11
2.6 Evento dopo la calibrazione. . . . . . . . . . . . . . . . . . . . 12
3.1 Esempio di geometria di una camera LST. . . . . . . . . . . . 13
3.2 Esempio di immagini estratte da ogni evento per ogni telescopio. 15
3.3 Esempio di informazioni MonteCarlo. . . . . . . . . . . . . . . 15
3.4 Esempio di immagine senza Background Noise. . . . . . . . . 16
3.5 Esempio di immagine con Background Noise. . . . . . . . . . 17
4.1 Workflow dell’algoritmo tailcuts_clean. . . . . . . . . . . . . 19
4.2 Parametrizzazione ellittica. . . . . . . . . . . . . . . . . . . . 21
4.3 Ricostruzione del punto di origine dello sciame date le imma-
gini rilevate da 4 telescopi[6]. . . . . . . . . . . . . . . . . . . 22
5.1 Esempio di ellisse con asse maggiore che interseca il centro
della camera. . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.2 Workflow semplificato del processo per il calcolo del ”numbers
of different pixels”. . . . . . . . . . . . . . . . . . . . . . . . . 29
5.3 Esempio di ellisse con asse maggiore che non interseca il centro
della camera. . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.4 Suddivisione finale dei dati. . . . . . . . . . . . . . . . . . . . 33
5.5 Caricamento dei dati di un evento memorizzato precedente-
mente in un file ”.npz”. . . . . . . . . . . . . . . . . . . . . . . 35
i
ELENCO DELLE FIGURE
6.1 Immagine con rumore. . . . . . . . . . . . . . . . . . . . . . . 37
6.2 Immagine pulita con parametri standard. . . . . . . . . . . . 38
6.3 Immagine pulita con parametri ottimizzati. . . . . . . . . . . 38
6.4 Sistema per la predizione dei parametri ottimi di cleaning. . . 39
6.5 Training del sistema di predizione. . . . . . . . . . . . . . . . 40
7.1 Output generato dagli script, divisione dei dati ottenuti prima
per range energetico, poi per tipo di telescopio. . . . . . . . . 42
ii
Indice
Introduzione v
1 Il Progetto Cherenkov Telescope Array (CTA) 1
1.1 Il concetto dietro CTA . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Perché nasce il progetto CTA . . . . . . . . . . . . . . . . . . 2
1.3 Descrizione dei telescopi . . . . . . . . . . . . . . . . . . . . . 3
1.3.1 I diversi tipi di telescopi . . . . . . . . . . . . . . . . . 3
1.4 Stato dell’arte del progetto CTA . . . . . . . . . . . . . . . . 4
1.5 Simulazioni Monte Carlo . . . . . . . . . . . . . . . . . . . . . 4
1.5.1 Simtel file (Simulation telescope array file) . . . . . . . 5
2 ctapipe 6
2.1 Principali tecnologie utilizzate in ctapipe . . . . . . . . . . . . 6
2.1.1 GitHub . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.2 Python . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.3 Numpy, Astropy, matplotlib . . . . . . . . . . . . . . . 7
2.2 Stato dell’arte di ctapipe . . . . . . . . . . . . . . . . . . . . 8
2.2.1 Il framework . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.2 Esempio di codice - Containers . . . . . . . . . . . . . 9
3 Imaging degli eventi con ctapipe 13
3.1 Gestione degli eventi in ctapipe . . . . . . . . . . . . . . . . 14
3.1.1 Immagini senza Background Noise . . . . . . . . . . . 15
3.1.2 Immagini con Background Noise . . . . . . . . . . . . 16
4 Image Cleaning 18
4.1 Algoritmo per l’image cleaning - tailcuts clean . . . . . . . . . 18
4.1.1 Problema del fissare parametri del cleaning . . . . . . 20
4.2 Hillas Parametrization . . . . . . . . . . . . . . . . . . . . . . 20
4.3 Perché serve l’image cleaning . . . . . . . . . . . . . . . . . . 22
5 Ottimizzare parametri del cleaning 23
5.1 Parametri di qualità per l’ottimizzazione . . . . . . . . . . . . 23
5.1.1 Parametro di qualità: closest approach . . . . . . . . . 24
iii
INDICE
5.1.2 Parametro di qualità: likelihood function . . . . . . . 26
5.1.3 Parametro di qualità: numbers of different pixels . . . 26
5.1.4 Diverse scelte di parametri di cleaning per la stessa
immagine . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.2 Come implementare l’ottimizzazione dei parametri . . . . . . 31
5.3 Dati finali . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.3.1 Esempio di visualizzazione dei dati memorizzati . . . . 34
6 Discussione dei risultati ottenuti 36
6.1 Comparazione del cleaning tra parametri fissati e parametri
ottimizzati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
6.2 Possibili utilizzi dei risultati trovati . . . . . . . . . . . . . . . 37
6.2.1 Metodo di utilizzo - Machine Learning . . . . . . . . . 39
6.2.2 Metodo di utilizzo - Benchmarking . . . . . . . . . . . 40
7 Conclusioni 41
iv
Introduzione
In questa tesi è riportata l’esperienza di tirocinio presso i laboratori dell’Isti-
tuto Nazionale di Fisica Nucleare (INFN) sezione di Trieste, Area di Ricerca.
Il lavoro svolto durante il tirocinio è stato mirato ad ottenere dei risultati
sull’ottimizzazione dei parametri di cleaning di un algoritmo (”tailcuts clea-
ning”) che serve appunto a pulire delle immagini da un rumore di fondo. Un
raggio gamma ad altissima energia, a contatto con l’atmosfera produce uno
sciame di particelle cariche che viene rilevato da una serie di telescopi che
catturerà l’immagine di cui si farà il cleaning del rumore. I parametri di
cleaning usati fin’ora, sono dei parametri fissi che vengono distinti solo dal
tipo di telescopio.
Questo è un metodo non ottimale dal momento che per ogni immagine, un
ricercatore deve provare in modo empirico a settare dei parametri che effet-
tivamente siano adeguati alla pulizia dell’immagine singola. Questa è stata
una delle motivazioni principali della ricerca svolta durante il tirocinio. Inol-
tre, trovando questi parametri si può creare un ”benchmarking” per vedere
come cambiano i parametri di cleaning ottimali in base ad informazioni come
l’energia dell’evento che ha generato lo sciame, così da poter trovare corre-
lazioni non ovvie ad una prima analisi tra i parametri di cleaning e l’evento
stesso.
Il ciclo di vita del software realizzato è un susseguirsi di proposte da par-
te dello studente, implementazioni, considerazioni sull’implementazione da
parte del relatore e correlatore, modifiche.
I primi capitoli sono introduttivi al progetto generale CTA ed al software
ctapipe, poi si inizia ad entrare sempre più nello specifico sulla tematica
dell’image cleaning e del suo stato dell’arte.
Infine gli ultimi capitolo descrivono le soluzioni trovate assieme ad una descri-
zione in linguaggio naturale delle procedure ottenute (con qualche accenno
a pseudocodice e codice vero e proprio) per implementare tali soluzioni.
v
Capitolo 1
Il Progetto Cherenkov
Telescope Array (CTA)
L’osservatorio CTA, è composto da due array di telescopi. Il primo posto nel-
l’emisfero Nord (La Palma, isola della Spagna), il secondo posto nell’emisfero
Sud (Atacama, Deserto del Chile, in Figura 1.1).
Figura 1.1: Rendering di come sarà l’array di telescopi nel sito dell’emisfero
Sud[1].
1.1 Il concetto dietro CTA
Radiazione elettromagnetica ad altissima energia (Very High-Energy, detta
anche VHE) raggiunge la terra, portando con sé informazioni sui fenomeni
più energetici dell’Universo[8].
Questa Radiazione viene rivelata grazie agli ”Imaging Air Cherenkov Te-
lescopes” (IACTs), cioè dei telescopi che utilizzano le radiazioni Cheren-
kov generate dallo sciame di particelle cariche causato dai raggi gamma ad
alta energia (VHE) che interagiscono con l’atmosfera terrestre[9]. Esempi
di IACTs attualmente operativi sono: H.E.S.S. (High Energy Stereoscopic
System)[10], VERITAS (Very Energetic Radiation Imaging Telescope Array
System)[11], MAGIC (Major Atmospheric Gamma Imaging Cherenkov)[12].
1
CAPITOLO 1. IL PROGETTO CHERENKOV TELESCOPE ARRAY
(CTA)
Figura 1.2: Come CTA rileva la luce Cherenkov[1].
Il progetto CTA, propone di utilizzare questo stesso sistema di ricezione
dei raggi gamma, facendo un imaging stereoscopico simultaneo di ciascuno
sciame di particelle con più telescopi, per poi ricostruire le proprietà del rag-
gio gamma originario che ha interagito con l’atmosfera a partire da queste
immagini (vedi Figura 1.2)[8].
1.2 Perché nasce il progetto CTA
Gli attuali IACTs esistenti, lavorano con sensibilità e risoluzione angolare e
range energetico minori di quanto riuscirà a raggiungere CTA. Con esso, si
vuole riuscire a rilevare raggi gamma che vanno dai 20 GeV fino ai 300 TeV.
Le migliorie rispetto ai telescopi esistenti sono le seguenti [8] :
• Sensitività
• Risoluzione angolare
• Risoluzione temporale
• Area di raccolta dei raggi gamma
• Range energetico di rilevazione dei raggi gamma
2
CAPITOLO 1. IL PROGETTO CHERENKOV TELESCOPE ARRAY
(CTA)
Figura 1.3: Prototipo di fotomoltiplicatore al silicio[2].
Il progetto CTA, infatti, ha lo scopo di perseguire ricerche scientifiche
quali [8] :
• Rilevare galassie attive con un flusso di raggi gamma che attualmente
non è possibile osservare
• Studio dei buchi neri al loro centro
• Studio della storia della formazione stellare dell’Universo
• Studio sulla natura della materia oscura
• Studio delle sorgenti dei raggi gamma nel piano galattico
• Studio sulla violazione della prorietà d’invarianza di Lorentz
1.3 Descrizione dei telescopi
Le camere montate sui telescopi devono poter captare la luce blu genera-
ta dall’effetto Cherenkov con un durata minore di qualche miliardesimo di
secondo. Proprio per la natura effimera di questo evento, i telescopi sono do-
tati di specchi ad alta riflettività che convogliano la luce direttamente nelle
camere che avranno una risposta estremamente veloce per catturare l’effetto.
La luce catturata dalle camere (tramite dei fotomoltiplicatori e/o fotomol-
tiplicatori al silicio) (vedi Figura 1.3), viene poi digitalizzata e trasmessa al
sistema di acquisizione dati[2].
1.3.1 I diversi tipi di telescopi
Per coprire i requisiti dello spettro di energia rilevabile prefissati da CTA,
sono necessari tre classi di telescopi:
3CAPITOLO 1. IL PROGETTO CHERENKOV TELESCOPE ARRAY
(CTA)
Figura 1.4: Linea temporale dello sviluppo di CTA[3].
• LST (Large Sized Telescope).
Sono i telescopi con gli specchi più grandi e rilevano energie tra i 20 ed
i 150 GeV, molto veloci a riposizionarsi[13].
• MST (Medium Sized Telescope).
Sono i telescopi che rilevano energie tra i 5 ed i 150 TeV, servono
soprattutto a fare profonde analisi del cielo in cerca di sorgenti di raggi
gamma[14].
• SST (Small Sized Telescope).
Sono i telescopi con gli specchi più piccoli ma anche quelli più nume-
rosi, servono soprattutto alla rilevazione di alte energie grazie alla loro
altissima sensitività (range energetico fino a 300 TeV)[15].
1.4 Stato dell’arte del progetto CTA
Al momento, sono stati costruiti prototipi dei tre tipi di telescopi: SST, MST
ed LST. Il progetto CTA è ancora nella fase di pre-costruzione, ma come si
vede in Figura 1.4, si sta avviando la pre-produzione.
1.5 Simulazioni Monte Carlo
Essendo i telescopi ancora in fase di costruzione, le informazioni sui raggi
gamma che dovrebbero essere captate da quest ultimi, vengono ad essere
simulate così da avere comunque dei dati su cui lavorare per lo sviluppo
del software ctapipe, e per la ricerca sulle migliori prestazioni ottenibili da
4CAPITOLO 1. IL PROGETTO CHERENKOV TELESCOPE ARRAY
(CTA)
diverse strategie di puntamento dei telescopi. Questi dati, sono delle simu-
lazioni che riproducono l’impatto dei raggi gamma nell’atmosfera terrestre
e il conseguente sciame di particelle. Per il progetto CTA, è stato scelto il
generatore di sciami denominato CORSIKA. Esso, codice open source usato
ampiamente da tutti Gli IACTs arrays, rappresenta lo standard nella comu-
nità della fisica delle astroparticelle. Il flusso di fotoni Cherenkov simulato da
CORSIKA viene raccolto per ogni posizione e tipologia dei telescopi predefi-
nita. La simulazione di questi eventi, richiede un’enorme quantità di spazio
su disco ed un’enorme quantità di tempo di CPU (in una giornata si comple-
ta una simulazione dell’ordine di qualche TeraByte). Per questo motivo si
è deciso di utilizzare 14 centri distribuiti per la computazione e memorizza-
zione delle simulazioni. La simulazione di solito, viene direttamente passata
ad un simulatore di array di telescopi (creando così dei file di tipo .simtel),
reiterando il processo variando dettagli implementativi dei telescopi oppure
variando il background dato dal cielo notturno, così da poter vedere anche
quale configurazione produce risultati migliori rispetto alla stessa rilevazio-
ne di uno sciame. Tutte le simulazioni finite poi, sono memorizzate e rese
accessibili da remoto ai membri del progetto CTA[16].
1.5.1 Simtel file (Simulation telescope array file)
Per memorizzare queste informazioni, si è creato un formato proprietario di
CTA chiamato .simtel che, rappresenta un numero molto alto di ”eventi”
(sciami e relativi effetti Cherenkov, generati da una particella, che hanno
innescato la rilevazione da parte di uno o più telescopi.) nello stesso file.
Questi file .simtel vengono poi letti grazie ad un implementazione in Python3
del formato dati EventIO, denominato ”pyeventio”[17].
Nei capitoli successivi si descriverà come vengono utilizzati questi simtel file,
come funziona e com’è strutturato il software ctapipe.
5Capitolo 2
ctapipe
ctapipe è un framework per l’elaborazione dei dati di CTA. Correntemen-
te alla versione 0.7.0, viene sviluppato e modificato molto frequentemente
per esplorare varie possibilità di utilizzo di tecnologie diverse e di diverse
implementazioni delle classi che compongono la parte di API.
Figura 2.1: Logo di ctapipe[4].
2.1 Principali tecnologie utilizzate in ctapipe
2.1.1 GitHub
Questa continua evoluzione, è possibile grazie alla piattaforma online per il
controllo di versione del software ”GitHub”, la quale permette di lavorare
da remoto al codice di ctapipe, modificandolo e richiedendo in un secondo
momento l’effettiva applicazione delle modifiche dopo una revisione di un
gruppo di utenti selezionato. GitHub permette inoltre, di lavorare anche
su ”branch” diversi così da poter avere modifiche parallele che non vanno
in conflitto tra di loro. Ultimo ma non meno importante, è la possibilità
di pubblicare ”Issues” (vedi Figura 2.2), dei report su un problema dove
gli utenti che lavorano al progetto possono discutere e trovare soluzioni al
problema stesso.
6CAPITOLO 2. CTAPIPE
Figura 2.2: Esempio di ”Issue” ancora aperto.
2.1.2 Python
Tutto il framework ctapipe è scritto in Python3 (con compatibilità del co-
dice dalla versione Python 3.6 in poi). La ragione principale è la vasta
documentazione del linguaggio, la grandissima comunità che lavora ai pro-
blemi ogni giorno, la popolarità riscontrata nella comunità dei fisici, ma
soprattutto alla grande intellegibilità del codice da parte di esterni.
2.1.3 Numpy, Astropy, matplotlib
Funzionalità principali di Numpy usate [18] :
• Supporto a strutture dati come matrici e array multidimensionali
• Vasta gamma di funzioni matematiche per queste strutture dati
Funzionalità principali di Astropy usate [19] :
• Conversione di unità e quantità fisiche
• Definizione di costanti astronomiche
• Definizione di coordinate celesti
Funzionalità principali di Matplotlib usate [20] :
• Plotting di istogrammi, immagini, figure geometriche
7CAPITOLO 2. CTAPIPE
Figura 2.3: GitHub Issues aperti[5].
2.2 Stato dell’arte di ctapipe
Il framework ctapipe, anche se funzionante (ma non efficiente) in quasi la
sua totalità, è ancora pieno di ”Issues” che devono essere risolti come si può
vedere in Figura 2.3
I tipi di ”Issues” possono essere i più disparati, da problemi legati alla
strumentazione a problemi di design del software, da problemi di ottimiz-
zazione a semplici domande su come utilizzare al meglio delle funzioni già
implementate.
Per esempio, in Figura 2.4 si può vedere come ci si è accorti, lavorando
ad un altra parte di ctapipe, che una scala dei tempi che dovrebbe essere in
nanosecondi, viene invece ad essere implementata in un’unità di misura che
non è stata moltiplicata per la frequenza di clock dei telescopi.
Questo ha portato ad avere una scala che, per gli LST che lavorano ad alte
frequenze (GHz), sembra essere in nanosecondi, ma per gli SST che lavorano
anche con frequenze di 250MHz, questa scala è erronea[21].
2.2.1 Il framework
ctapipe è appunto un framework, e come tale si propone di essere la strut-
tura intermedia che aiuta il fisico o sviluppatore che deve utilizzare i dati
raccolti dalle camere (eventi codificati in simtel files che saranno creati o da
simulazioni o dai telescopi reali una volta avviata la produzione) mettendo a
8CAPITOLO 2. CTAPIPE
Figura 2.4: Pulse time issue[5].
disposizione di questi ultimi, degli strumenti di analisi degli eventi, display
delle immagini di un evento, pulizia dell’immagine o ”image cleaning” da
qualsiasi rumore di fondo (per esempio il bagliore residuo generato dal cielo
notturno), di acquisizione corretta dei dati del simtel file, la ricostruzione
stereoscopica dell’evento dalle immagini dei telescopi.
2.2.2 Esempio di codice - Containers
Una parte molto importante di ctapipe sono i ”containers”, cioè le struttu-
re dati create appunto per contenere dati eterogenei. Il codice seguente è
l’implementazione di un container di ”HillasParameters”.
class HillasParametersContainer(Container):
container_prefix = ’hillas’
intensity = Field(nan, ’total intensity (size)’)
x = Field(nan, ’centroid x coordinate’)
y = Field(nan, ’centroid x coordinate’)
r = Field(nan, ’radial coordinate of centroid’)
phi = Field(nan, ’polar coordinate of centroid’, unit=u.deg)
length = Field(nan, ’RMS spread along the major-axis’)
width = Field(nan, ’RMS spread along the minor-axis’)
psi = Field(nan, ’rotation angle of ellipse’, unit=u.deg)
skewness = Field(nan, ’measure of the asymmetry’)
kurtosis = Field(nan, ’measure of the tailedness’)
La struttura è molto semplice, c’è un prefisso per identificare il container
ed una serie di oggetti di tipo Field.
9CAPITOLO 2. CTAPIPE
Il codice seguente è l’implementazione della classe Field in ctapipe.
class Field:
"""
Class for storing data in ‘Containers‘.
Parameters
----------
default:
default value of the item (this will be set when the
‘Container‘
is constructed, as well as when ‘Container.reset()‘ is called
description: str
Help text associated with the item
unit: ‘astropy.units.Quantity‘
unit to convert to when writing output, or None for no
conversion
ucd: str
universal content descriptor (see Virtual Observatory
standards)
"""
def __init__(self, default, description="", unit=None,
ucd=None):
self.default = default
self.description = description
self.unit = unit
self.ucd = ucd
def __repr__(self):
desc = f’{self.description}’
if self.unit is not None:
desc += f’ [{self.unit}]’
return desc
Come si può notare, il metodo ”__init__” che viene richiamato nel Contai-
ner per istanziare un campo prende semplicemente come parametri obbliga-
tori un oggetto di default che verrà inizializzato al momento della creazione
del container e una descrizione del campo.
I tipi di Containers sono molti, ma fondamentalmente hanno tutti la stes-
sa struttura. Questa struttura semplice e lineare è alla base di tutte le
informazioni che è possibile raccogliere da un evento di un simtel file.
class DataContainer(Container):
""" Top-level container for all event information """
event_type = Field(’data’, "Event type")
r0 = Field(R0Container(), "Raw Data")
r1 = Field(R1Container(), "R1 Calibrated Data")
10CAPITOLO 2. CTAPIPE
Figura 2.5: Struttura dei dati inerenti ad un evento.
dl0 = Field(DL0Container(), "DL0 Data Volume Reduced Data")
dl1 = Field(DL1Container(), "DL1 Calibrated image")
dl2 = Field(ReconstructedContainer(), "Reconstructed Shower
Information")
mc = Field(MCEventContainer(), "Monte-Carlo data")
mcheader = Field(MCHeaderContainer(), "Monte-Carlo run header
data")
trig = Field(CentralTriggerContainer(), "central trigger
information")
count = Field(0, "number of events processed")
inst = Field(InstrumentContainer(), "instrumental information
(deprecated")
pointing = Field(Map(TelescopePointingContainer),
’Telescope pointing positions’)
Questo codice rappresenta il container che viene creato quando si carica
in memoria un evento da un simtel file. L’unica cosa che cambia a livello
concettuale rispetto al container prima mostrato, è la funzione ”Map()” pre-
sente nel campo ”pointing”. Questa funzione semplicemente serve per creare
un dizionario di sub-containers (in questo caso il sub-container è ”Telesco-
pePointingContainer”) così da poter avere dei campi in un container che
puntano ad un set di sub-containers. Gli altri campi hanno la sola parti-
colarità di essere dei container a loro volta, e questo permette di avere dei
dati che hanno una struttura autoesplicativa. Questo significa che si può
”navigare tra i dati” guardando cosa sono i dati stessi (Figura 2.5):
Allo stato attuale, quando un ”DataContainer” viene creato, gli unici dati
presenti sono quelli nei Fields ”r0” ed ”r1”.
11CAPITOLO 2. CTAPIPE
Figura 2.6: Evento dopo la calibrazione.
Il metodo ”CameraCalibrator()” si occupa di simulare tutta la catena di pro-
cessi per la calibrazione della camera che servono per ricavare i Fields ”dl0”
(una riduzione del volume dei dati rispetto ”r1”) e ”dl1” (una calibrazione
dei dati presenti in ”dl0”). Questo processo, verrà effettuato dali telescopi
quando saranno operativi e quindi il metodo ”CameraCalibrator()” risulterà
deprecato. Il Field ”dl2” serve per memorizzare i dati riguardanti ricostru-
zioni spaziali ed energetiche dello sciame di particelle rispetto alle diverse
informazioni dei diversi telescopi che hanno rilevato l’evento (Figura 2.6).
12Capitolo 3
Imaging degli eventi con
ctapipe
Quando un telescopio rileva un evento, cioè ne cattura lo sciame di particelle
tramite la camera, quello che arriva a ctapipe in input è un file .simtel
che verrà poi gestito da opportune librerie per estrarre i dati in maniera ef-
ficiente e collocarli in un container di tipo ”DataContainer” per ogni evento.
L’immagine che il telescopio rileva viene rappresentata in ctapipe tramite
un oggetto ”numpy.ndarray” che rappresenta per ogni posizione di un pixel
la quantità di carica rilevata dalla camera del telescopio.
La geometria della camera del telescopio (che può essere esagonale oppure
rettangolare) è rappresentata da un oggetto di tipo ”CameraGeometry” (ve-
di Figura 3.1). Questo oggetto contiene informazioni sulla forma dei pixel
(esagonali o rettangolari), la posizione dei pixel sulla camera e la matrice dei
pixel adiacenti denominata ”neighbour_matrix” (Figura 3.1).
Figura 3.1: Esempio di geometria di una camera LST.
13CAPITOLO 3. IMAGING DEGLI EVENTI CON CTAPIPE
3.1 Gestione degli eventi in ctapipe
Gli eventi in ctapipe vengono caricati da un file .simtel nell’oggetto ”events”
che contiene un numero non definito a priori di oggetti di tipo ”DataCon-
tainer” non calibrati che rappresentano ognuno un evento diverso. Questa
procedura è ottenuta dal seguente codice:
input_url = find_in_path(’file simtel compresso (xxxx.simtel.gz)’,
’path assoluto del simtel file’)
events = event_source(input_url)
Una generale procedura utilizzata per entrare volta per volta, in ogni
evento di un simtel file, e calibrare evento per evento, è la seguente:
input_url =
find_in_path(’gamma_20deg_0deg_run101___cta-prod3-lapalma3-2147m-LaPalma.simtel.gz’,
’/home/matteo/ctasoft/resources’)
events = event_source(input_url, max_events=1)
calibrator = CameraCalibrator()
for event in events:
calibrator(event)
A questo punto nel ciclo for si può estrarre tutta l’informazione che si
vuole dall’evento corrente, per esempio si può estrarre l’immagine dello scia-
me vista dal telescopio selezionato per ogni telescopio triggerato da un evento
(Figura 3.2):
from ctapipe.io import event_source
from ctapipe.calib import CameraCalibrator
from ctapipe.utils.datasets import find_in_path
input_url =
find_in_path(’gamma_20deg_0deg_run101___cta-prod3-lapalma3-2147m-LaPalma.simtel.gz’,
’/home/matteo/ctasoft/resources’)
events = event_source(input_url, max_events=1)
calibrator = CameraCalibrator()
for event in events:
calibrator(event)
for telescope_id, dl1 in event.dl1.tel.items():
image = dl1.image
print(’telescope_id:’, telescope_id, ’image type:’,
type(image), ’array: ’, image)
14CAPITOLO 3. IMAGING DEGLI EVENTI CON CTAPIPE
Figura 3.2: Esempio di immagini estratte da ogni evento per ogni telescopio.
Figura 3.3: Esempio di informazioni MonteCarlo.
3.1.1 Immagini senza Background Noise
Essendo i simtel file ancora delle simulazioni attuate da CORSIKA, possiamo
conoscere a priori anche delle informazioni che negli eventi reali non sarebbe
possible avere; queste informazioni sono contenute nel campo ”mc” di un
”Datacontainer”.
Nell’evento rilevato dal telescopio, sarà presente un rumore di fondo, che
può essere dovuto a raggi cosmici, muoni, oppure dal ”Night Sky Backround”
(NSB) che può causare la rilevazione casuale di immagini. Solitamente questo
rumore di fondo ha una distribuzione uniforme nel campo visivo utile del
telescopio[22].
Il campo ”mc” (Monte Carlo) ha informazioni riguardanti l’evento che si
rileverebbe senza nessun rumore di fondo (Figura 3.3). Queste informazioni
sono pertanto relative al raggio gamma che genera lo sciame di particelle.
Tra questi dati, c’è anche l’immagine che vedrebbe il telescopio se non ci fosse
nient’altro che lo sciame di particelle generato dal raggio gamma (Figura 3.4):
telescope_id = 2
camera = event.inst.subarray.tels[telescope_id].camera
15CAPITOLO 3. IMAGING DEGLI EVENTI CON CTAPIPE
Figura 3.4: Esempio di immagine senza Background Noise.
fig, axs = plt.subplots(1, 1, figsize=(10, 6))
d1 = CameraDisplay(camera, ax=axs)
axs.set_title(’Ground_Truth ’ + camera.cam_id)
d1.image = event.mc.tel[telescope_id].photo_electron_image
d1.add_colorbar()
plt.show()
plt.close(fig)
Questa informazione è molto utile soprattutto per avere un riferimento
di cosa dovrà dare in output un algoritmo di cleaning dell’immagine di uno
sciame affetta da rumore di fondo.
3.1.2 Immagini con Background Noise
L’immagine dopo la calibrazione della camera, cioè l’immagine che si ot-
terrà da un telescopio dopo la rilevazione dell’evento, è allocata nel campo
”dl1” del ”DataContainer”. Come già detto, questo campo attualmente viene
riempito dal metodo CameraCalibrator(), che ha lo scopo di simulare tutta
la catena di processi per arrivare dal campo ”r1” al campo ”dl1”. Nel Field
”dl1”, sarà presente un oggetto di tipo numpy.ndarray denominato ”image”,
che rappresenta proprio l’immagine calibrata; dove ogni posizione dell’ar-
ray rappresenta univocamente un pixel della camera e il valore dell’elemento
dell’array rappresenta il numero di conteggi di fotoni (Figura 3.5):
telescope_id = 2
camera = event.inst.subarray.tels[telescope_id].camera
16CAPITOLO 3. IMAGING DEGLI EVENTI CON CTAPIPE
Figura 3.5: Esempio di immagine con Background Noise.
fig, axs = plt.subplots(1, 1, figsize=(10, 6))
d1 = CameraDisplay(camera, ax=axs)
axs.set_title(’Camera: ’ + camera.cam_id)
d1.image = event.dl1.tel[telescope_id].image
d1.add_colorbar()
plt.show()
plt.close(fig)
17Capitolo 4
Image Cleaning
Quando l’immagine di un evento viene catturata dalla camera di un telesco-
pio, si catturerà inevitabilmente anche del rumore di fondo come spiegato nel
precedente capitolo. Per ovviare a questo problema, sono stati pensati diver-
si algoritmi che hanno l’obiettivo di eliminare il rumore di fondo lasciando
intatto lo sciame generato dall’evento.
4.1 Algoritmo per l’image cleaning - tailcuts clean
L’algoritmo più basilare ma anche quello che sta alla base di tutti gli altri
algoritmi di cleaning è denominato ”tailcuts_clean”:
def tailcuts_clean(geom, image, picture_thresh=7,
boundary_thresh=5, keep_isolated_pixels=False,
min_number_picture_neighbors=0):
pixels_above_picture = image >= picture_thresh
if keep_isolated_pixels or min_number_picture_neighbors == 0:
pixels_in_picture = pixels_above_picture
else:
number_of_neighbors_above_picture =
geom.neighbor_matrix_sparse.dot(
pixels_above_picture.view(np.byte)
)
pixels_in_picture = pixels_above_picture & (
number_of_neighbors_above_picture >=
min_number_picture_neighbors
)
pixels_above_boundary = image >= boundary_thresh
18CAPITOLO 4. IMAGE CLEANING
Figura 4.1: Workflow dell’algoritmo tailcuts_clean.
pixels_with_picture_neighbors =
geom.neighbor_matrix_sparse.dot(pixels_in_picture)
if keep_isolated_pixels:
return (
pixels_above_boundary & pixels_with_picture_neighbors
) | pixels_in_picture
else:
pixels_with_boundary_neighbors =
geom.neighbor_matrix_sparse.dot(
pixels_above_boundary
)
return (pixels_above_boundary &
pixels_with_picture_neighbors) | (
pixels_in_picture & pixels_with_boundary_neighbors
)
Parametri di input (Workflow in Figura 4.1):
• geom: oggetto ”CameraGeometry”, definisce la geometria della camera.
• image: oggetto ”numpy.ndarray”, è l’immagine che va ripulita dal ru-
more.
• picture_threshold: float, i pixel che hanno valori più piccoli di questa
soglia vengono scartati (settati a 0).
• boundary thresh: float, i pixel adiacenti ad un pixel che ha superato
la ”picture_threshold” e che hanno valore più alto di questa soglia
vengono conservati, gli altri vengono scartati.
• keep_isolated_pixels: boolean, se questo valore è ”True” tutti i pi-
xels che hanno superato la ”picture_threshold” vengono conservati, se
questo valore è ”False” allora i pixels vengono conservati solo se i pi-
xels sopravvissuti alla ”picture_threshold” hanno dei pixel adiacenti
sopravvissuti alla ”boundary_thresh”.
19CAPITOLO 4. IMAGE CLEANING
• min_number_picture_neighbors: non ha nessun effetto se ”keep_isolated_pixels”
ha il valore ”True”. Serve per definire il numero minimo di pixels
adiacenti che deve avere un pixel per sopravvivere al cleaning.
4.1.1 Problema del fissare parametri del cleaning
Come abbiamo già visto, ci sono dei parametri nell’algoritmo ”tailcuts clean”
che vanno fissati: il modo in cui decidere quali valori dare a questi parametri,
è stato deciso da terzi in modo arbitrario facendo una stima di quali sono i
parametri che andrebbero bene per qualche evento, distinguendo anche per
tipo di telescopio. Ovviamente questo è un primo approccio, ed i parametri
scelti sono stati fissati in questo modo solo per dare una referenza di quale
valore questi parametri potrebbero avere per qualche evento registrato.
Di seguito un esempio di come sono stati scelti i parametri ”picture_threshold”,
”boundary_thresh”, ”min_number_picture_neighbors”:
...
# unoptimized cleaning levels, copied from
# https://github.com/tudo-astroparticlephysics/cta_preprocessing
cleaning_level = {
’LSTCam’: (3.5, 7.5, 2), # ?? (3, 6) for Abelardo...
’FlashCam’: (4, 8, 2), # there is some scaling missing?
’ASTRICam’: (5, 7, 2),
}
...
In questo snapshot di codice si è creato un dizionario dove ogni elemen-
to ha la seguente sintassi: ” : (,
, )”. La scelta dei pa-
rametri non è dettata da nessun procedimento logico ma soltanto da osser-
vazioni empiriche da parte di altri ricercatori.
Per questo motivo, uno dei principali obbiettivi del tirocinio è stato pro-
prio quello di trovare un modo per ottenere dei parametri che abbiano una
relazione logica con l’immagine da pulire dal rumore.
4.2 Hillas Parametrization
Il seguente codice è l’implementazione in ctapipe di un algoritmo per estrar-
re da un’immagine ripulita dal rumore di fondo i ”parametri di Hillas”. Questi
parametri non sono altro che una modo per rappresentare matematicamente
lo sciame di particelle gamma che ha sempre una forma ovale e può quin-
di essere descritto da un’ellisse. L’algoritmo come parametri formali ha un
oggetto di tipo ”numpy.ndarray” che rappresenta un’immagine a cui è stato
applicato un algoritmo di cleaning (”image”), e un oggetto di tipo ”Came-
20CAPITOLO 4. IMAGE CLEANING
Figura 4.2: Parametrizzazione ellittica.
raGeometry” che definisce la geometria della camera del telescopio che ha
rilevato l’immagine di cui si è fatto il cleaning (”geom”).
def hillas_parameters(geom, image):
.
.
.
return HillasParametersContainer(
x=u.Quantity(cog_x, unit),
y=u.Quantity(cog_y, unit),
r=u.Quantity(cog_r, unit),
phi=Angle(cog_phi, unit=u.rad),
intensity=size,
length=u.Quantity(length, unit),
width=u.Quantity(width, unit),
psi=Angle(psi, unit=u.rad),
skewness=skewness_long,
kurtosis=kurtosis_long,
)
Di seguito il codice per fare visualizzarre l’ellisse parametrizzata dai valori
ottenuti dal metodo ”hillas_parameters” (Figura 4.2):
21CAPITOLO 4. IMAGE CLEANING
Figura 4.3: Ricostruzione del punto di origine dello sciame date le immagini
rilevate da 4 telescopi[6].
hillas_containers = {}
hillas_c = hillas_parameters(camera[clean], d1.image[clean])
hillas_containers[telescope_id] = hillas_c
fig, axs = plt.subplots(1, 1, figsize=(10, 6))
d3 = CameraDisplay(camera, ax=axs)
axs.set_title(’Hillas parameters display: ’)
d3.image = cleaned_image
d3.add_colorbar()
d3.overlay_moments(hillas_containers[telescope_id], color="red",
with_label=False, lw=2, keep_old=True)
plt.show()
plt.close(fig)
4.3 Perché serve l’image cleaning
Ci sono diversi motivi per cui l’image cleaning è un processo necessario,
primo tra tutti, la ricostruzione stereoscopica dello sciame di particelle che
avviene tramite i ”parametri di Hillas”, e per ricavare questa ricostruzione
servono le varie immagini catturate dai vari telescopi che hanno rilevato
l’evento (Esempio in Figura 4.3). Ci sono poi altre ricostruzioni di diversa
natura, come la ricostruzione energetica di un evento che richiede comunque
una descrizione dello sciame di particelle non affetto da rumore.
22Capitolo 5
Ottimizzare parametri del
cleaning
In questo capitolo si analizzeranno tutti i parametri utilizzati (creati duran-
te il tirocino) negli script realizzati durante il tirocinio per determinare la
qualità dell’algoritmo ”tailcuts clean” su un’immagine, fissati i parametri di
cleaning.
5.1 Parametri di qualità per l’ottimizzazione
Il cleaning è il processo effettuato subito prima del ”Hillas parametrization”
(approssimazione dello sciame con un’ellisse), quindi è ragionevole pensa-
re che se la parametrizzazione dell’ellisse è un algoritmo completo che non
subirà ulteriori modifiche (ed è questo il caso), allora si può utilizzare pro-
prio l’ellisse che approssima lo sciame pulito dal rumore. Usando l’ellisse
di un’immagine però, stiamo assumendo che la dipendenza della qualità di
un cleaning dalla sua approssimazione ellittica non sia un problema per il
semplice fatto che l’algoritmo per l’approssimazione ellittica non cambierà.
Un altro dato molto importante che è ragionevole usare per determinare la
qualità di un cleaning, è sicuramente l’immagine che vedrebbe il telescopio se
non ci fosse nient’altro che lo sciame di particelle generato dal raggio gamma
(immagine che d’ora in avanti verra identificata come ”ground_truth”).
Ultima informazione importante per i parametri di qualità è che gli eventi
estratti dai file simtel simulati con CORSIKA, hanno tutti la particolarità
di essere centrati rispetto ai telescopi; ogni sciame dovrà avere l’ellisse che
lo approssima con l’asse maggiore che interseca esattamente il centro della
camera (Figura 5.1).
Questo significa che più l’ellisse che approssima lo sciame dopo il clea-
ning ha un’asse maggiore distante dal centro (questa distanza viene spesso
denominata ”closest approach”).
23CAPITOLO 5. OTTIMIZZARE PARAMETRI DEL CLEANING
Figura 5.1: Esempio di ellisse con asse maggiore che interseca il centro della
camera.
5.1.1 Parametro di qualità: closest approach
La distanza definita come ”closest approach” è il parametro principale che
indica la qualità dalla parametrizzazione ellittica di un’immagine di un’even-
to estratto da un simtel file simulato.
Il calcolo del closest approach è definito dal seguente codice:
def closest_distance(center, line):
"""
find the minimum distance between a set of points(line) and a
point(center)
Parameters
----------
center :
reference point
line :
a numpy array
Returns
-------
24CAPITOLO 5. OTTIMIZZARE PARAMETRI DEL CLEANING
distance:
minimum distance
"""
distance = cdist([center], line).min()
return distance
def closest_approach_distance(hillas_container):
"""
find the closest distance between the straight line
corresponding to the major axis of an ellipse and the center of
an image(cameraGeometry like)
Parameters
----------
hillas_container :
dictionary with telescope IDs as key and
HillasParametersContainer instances as values
Returns
-------
close_dist:
the closest approach calculated in meters
"""
length = np.linspace(-1, 1, 30)
length = u.Quantity(length, u.m, copy=False)
y = hillas_container.y + length * np.sin(hillas_container.psi)
x = hillas_container.x + length * np.cos(hillas_container.psi)
center = (0, 0)
line = np.array([x, y])
line = line.T
closest_approach = closest_distance(center, line)
closest_approach = u.Quantity(closest_approach, u.m)
return closest_approach
L’esatta definizione di questo parametro è la seguente:
il closest approach è la distanza minima calcolata dal centro della camera ed
il prolungamento infinito dell’asse maggiore dell’ellisse
25CAPITOLO 5. OTTIMIZZARE PARAMETRI DEL CLEANING
5.1.2 Parametro di qualità: likelihood function
Il parametro ”likelihood function” è una funzione che esprime la differenza
in termini di cariche nell’immagine ”ground truth” e l’immagine pulita con
un certo set di parametri fissato:
def likelihood_function(event, cleaned_image, telescope_id):
"""
returns a number that has to be compared with another
likelihood to find which image has a better approximation of
the ground truth image after the cleaning
Parameters
----------
event :
calibrated event
cleaned_image :
dictionary with telescope IDs as key and
HillasParametersContainer instances as values
telescope_id:
unique number for the identification of a telescope
Returns
-------
likelihood:
a scalar number that represent the sum of all the
differences between ground truth and cleaned image
"""
ground_truth_image =
event.mc.tel[telescope_id].photo_electron_image
diff = np.abs(cleaned_image - ground_truth_image)
likelihood = diff.sum()
return likelihood
L’esatta definizione
P di questo parametro è la seguente:
likelihood = i |(pixel_immagine_pulita)i −(pixel_immagine_ground_truth)i |
5.1.3 Parametro di qualità: numbers of different pixels
Questo parametro è quello meno intuitivo ma anche il più significativo sulle
differenze tra il ground truth e l’immagine pulita.
Per prima cosa si fa il cleaning dell’immmagine ground truth con gli stes-
26CAPITOLO 5. OTTIMIZZARE PARAMETRI DEL CLEANING
si parametri utilizzati nel cleaning dell’immagine con rumore, dopodichè si
calcola lo XOR tra le due maschere booleane restituite dal cleaning delle
rispettive immagini e si conta il numero di valori rimasti a ”True”:
def numbers_of_different_pixels(camera, event, cleaned_image,
telescope_id, picture, boundary, min_neighbors):
"""
find a quality parameter that is the representation of the
number of pixels survived in cleaned image but
not in cleaned ground truth image or vice versa.
The cleaned ground truth is needed to have a logic correlation
(independence from noise) between the 2 images that
has to be compared.
Parameters
----------
camera:
Camera geometry information
picture:
picture threshold for the tailcuts cleaning
boundary:
boundary threshold for the tailcuts cleaning
min_neighbors:
minimum number of neighbors in the picture for the tailcuts
cleaning
event :
calibrated event
cleaned_image :
dictionary with telescope IDs as key and
HillasParametersContainer instances as values
telescope_id:
unique number for the identification of a telescope
Returns
-------
number_difference_pixels_survived:
a scalar number that represent the counting of all the
pixels that are in the cleaned image or
in the cleaned ground truth BUT not in both of them
"""
ground_truth_image =
27CAPITOLO 5. OTTIMIZZARE PARAMETRI DEL CLEANING
event.mc.tel[telescope_id].photo_electron_image
clean = tailcuts_clean(
camera,
ground_truth_image,
boundary_thresh=boundary,
picture_thresh=picture,
min_number_picture_neighbors=min_neighbors
)
cleaned_ground_truth = ground_truth_image.copy()
cleaned_ground_truth[~clean] = 0.0
pixels_survived_image_cleaning = cleaned_image > 0
pixels_survived_ground_truth_cleaning = cleaned_ground_truth > 0
difference_pixels_survived =
np.logical_xor(pixels_survived_image_cleaning,
pixels_survived_ground_truth_cleaning)
number_difference_pixels_survived =
np.count_nonzero(difference_pixels_survived)
return number_difference_pixels_survived
Il cleaning del ground truth serve per togliere tutte quelle particelle isola-
te che fanno parte dello sciame ma che non interessano la parametrizzazione
ellittica (questo perché interessa soprattutto il cluster principale dello scia-
me).
Quest parametro definisce il numero di pixels che sono sopravvissuti ad
il cleaning dell’immagine oppure al cleaning del ground truth ma non ad
entrambi (Illustrazione del processo in Figura 5.2).
5.1.4 Diverse scelte di parametri di cleaning per la stessa
immagine
L’image cleaning può pregiudicare la parametrizzazione ellittica dello sciame.
Questo significa che un cleaning con parametri sbagliati porta ad avere una
parametrizzazione ellittica sbagliata. L’esempio riportato in Figura 5.1 ha i
seguenti parametri:
• picture threshold = 2.5
• boundary threshold = 5
• min number picture neighbors = 2
Verrà ora riproposto lo stesso sciame con parametri di cleaning apposita-
mente sbagliati per constatare quanto questi cambino la parametrizzazione
ellittica (Figura 5.3):
28CAPITOLO 5. OTTIMIZZARE PARAMETRI DEL CLEANING
Figura 5.2: Workflow semplificato del processo per il calcolo del ”numbers of
different pixels”.
• picture threshold = 2
• boundary threshold = 5
• min number picture neighbors = 2
29CAPITOLO 5. OTTIMIZZARE PARAMETRI DEL CLEANING
Figura 5.3: Esempio di ellisse con asse maggiore che non interseca il centro
della camera.
In Figura 5.3 si può notare come un piccolissimo cambiamento del ”pic-
ture threshold” è bastato per rendere assolutamente errata l’ellisse che do-
vrebbe approssimare lo sciame. Un fatto noto ma non dimostrato ancora dai
ricercatori che utilizzano ctapipe, è che la parametrizzazione del cleaning,
per avere dei risultati accettabili, dovrebbe avere un ”picture threshold” che
è un valore che fluttua attorno alla metà del valore del ”boundary threshold”
(per esempio se il picture threshold è 10, il boundary threshold potrebbe
essere 20 come 19.5 come 19.75).
Questo non vuol dire che non si potrebbero avere dei cleaning di un’immagine
accettabili con valori che non sono uno il doppio dell’altro, ma sicuramente
adottando questa regola, si riuscirà ad ottenere un risultato accettabile ite-
rando un numero finito di volte sui parametri del cleaning.
D’ora in avanti si farà uso di questa regola per trovare dei parametri di
cleaning accettabili:
def create_possible_parameters():
"""
compute all the possible cleaning levels and
does the storage in a numpy array.
Parameters
----------
30CAPITOLO 5. OTTIMIZZARE PARAMETRI DEL CLEANING
Returns
-------
possible_cleaning_levels:
array with all the possible cleaning levels chosen
"""
# cleaning levels with minimum neighbors set to 0
picture_range = np.arange(1, 10, 0.25, dtype=np.float32)
boundary_range = np.arange(2, 20, 0.5, dtype=np.float32)
min_neighbors_range = np.zeros(len(picture_range), dtype=np.int)
possible_cleaning_levels_0 = np.c_[picture_range,
boundary_range, min_neighbors_range]
# cleaning levels with minimum neighbors set to 1
min_neighbors_range = np.ones(len(picture_range), dtype=np.int)
possible_cleaning_levels_1 = np.c_[picture_range,
boundary_range, min_neighbors_range]
# cleaning levels with minimum neighbors set to 2
min_neighbors_range = np.multiply(min_neighbors_range, 2,
dtype=np.int)
possible_cleaning_levels_2 = np.c_[picture_range,
boundary_range, min_neighbors_range]
# cleaning levels with minimum neighbors set to 3
min_neighbors_range = np.ones(len(picture_range), dtype=np.int)
min_neighbors_range = np.multiply(min_neighbors_range, 3)
possible_cleaning_levels_3 = np.c_[picture_range,
boundary_range, min_neighbors_range]
possible_cleaning_levels =
np.append(possible_cleaning_levels_0,
possible_cleaning_levels_1, axis=0)
possible_cleaning_levels = np.append(possible_cleaning_levels,
possible_cleaning_levels_2, axis=0)
possible_cleaning_levels = np.append(possible_cleaning_levels,
possible_cleaning_levels_3, axis=0)
return possible_cleaning_levels
5.2 Come implementare l’ottimizzazione dei para-
metri
Il primo problema da affrontare è sicuramente come definire un processo di
ricerca del cleaning più acccettabile.
Dopo varie discussioni e vari tentativi si è arrivati alla conclusione che il
31CAPITOLO 5. OTTIMIZZARE PARAMETRI DEL CLEANING
modo più facile da implementare ma che porta ad un buon risultato in tem-
pi ragionevoli (nell’ordine di 14 secondi per un evento che ha 30 immagini)
è un’iterazione di diversi parametri di cleaning per ogni sciame rilevato da
un telescopio di ogni evento che verrano poi confrontati tra loro per trovare
il set di parametri che minimizza le tre funzioni che determinano la quali-
tà di un cleaning. Di seguito uno pseudocodice per comprendere il work-
flow del processo (https://github.com/MatteoScorcia/cta-benchmarks/
blob/master/Preparation/parameters_search/tests/param_cleaning_per_
event_image.ipynb):
• Creazione set di tutti i possibili parametri
• Loading del simtelfile
• Iterazione su ogni evento
• Calibrazione dell’evento corrente
• Iterazione su ogni immagine rilevata per l’evento corrente
• Iterazione su ogni possibile cleaning per l’immagine corrente
• Calcolo del parametro di qualità ”closest approach distance” per i
parametri di cleaning correnti
• Calcolo del parametro di qualità ”likelihood function” per i parametri
di cleaning correnti
• Calcolo del parametro di qualità ”numbers of different pixels” per i
parametri del cleaning correnti
• Confronto i parametri di qualità del cleaning corrente con quelli del
cleaning precedente
• Scelta dei parametri di cleaning che hanno i parametri di qualità mi-
gliori tra i due confrontati
• A fine dell’iterazione degli eventi creazione di un file compresso dove si
inserisce in ogni riga «tipo di telescopio>, ,CAPITOLO 5. OTTIMIZZARE PARAMETRI DEL CLEANING
Figura 5.4: Suddivisione finale dei dati.
di suddividere i dati in base all’energia dell’evento. (https://github.com/
MatteoScorcia/cta-benchmarks/blob/master/Preparation/parameters_
search/tests/param_cleaning_per_event_cam_energybin.ipynb) I ran-
ge energetici sono definiti in questo modo:
def create_energy_bin_array(minimum=1, maximum=1300, num_bins=10):
energy_bin = np.logspace(np.log10(minimum), np.log10(maximum),
num_bins)
energy_bin = np.around(energy_bin, 2)
energy_bin = u.Quantity(energy_bin, u.GeV)
return energy_bin
Quindi ci sono 10 segmenti che suddividono l’energia da 1 GeV a 1300
GeV, in modo logaritmico per avere i segmenti con alta energia più grandi
(questo perché ci si aspetta di avere molti più eventi ad alta energia che a
bassa energia).
Per ogni segmento del range energetico si crea una cartella in cui verranno
memorizzati i dati per tipo di camera.
5.3 Dati finali
I dati finali raccolti quindi, sono dei file compressi di tipo ”.npz” (compres-
sione del modulo ”numpy”) suddivisi come in Figura 5.4.
I dati quindi vengono suddivisi nel seguente modo:
33CAPITOLO 5. OTTIMIZZARE PARAMETRI DEL CLEANING
output (folder)
event_cam (folder)
file contenente i dati suddivisi solo per immagine
file contenente i soli dati delle camere di tipo ”FlashCam”
file contenente i soli dati delle camere di tipo ”LSTCam”
file contenente i soli dati delle camere di tipo ”NectarCam”
file contenente i soli dati delle camere di tipo ”SCTCam”
event_cam_energybin (folder)
primo segmento del range energetico (folder)
file contenente i dati delle camere di tipo ”FlashCam”
con energia degli eventi nel segmento corrente
file contenente i dati delle camere di tipo ”LSTCam” con
energia degli eventi nel segmento corrente
file contenente i dati delle camere di tipo ”NectarCam”
con energia degli eventi nel segmento corrente
file contenente i dati delle camere di tipo ”SCTCam” con
energia degli eventi nel segmento corrente
.
.
.
ultimo segmento del range energetico (folder)
file contenente i dati delle camere di tipo ”FlashCam”
con energia degli eventi nel segmento corrente
file contenente i dati delle camere di tipo ”LSTCam” con
energia degli eventi nel segmento corrente
file contenente i dati delle camere di tipo ”NectarCam”
con energia degli eventi nel segmento corrente
file contenente i dati delle camere di tipo ”SCTCam” con
energia degli eventi nel segmento corrente
5.3.1 Esempio di visualizzazione dei dati memorizzati
In Figura 5.5 un’esempio di come potrebbe essere un file memorizzato di cui
si è poi fatto il loading in un secondo momento. Il file caricato contiene tutti
i dati calcolati per ogni immagine di ogni evento letto in modo sequenziale
dal primo fino all’ultimo (il formato dati è quello illustrato nella sezione 5.2).
34CAPITOLO 5. OTTIMIZZARE PARAMETRI DEL CLEANING
Figura 5.5: Caricamento dei dati di un evento memorizzato precedentemente
in un file ”.npz”.
35Capitolo 6
Discussione dei risultati
ottenuti
In questo capitolo si discuterà su quali sono e soprattutto su come verranno
utilizzati i risultati trovati durante il tirocinio.
6.1 Comparazione del cleaning tra parametri fissati
e parametri ottimizzati
Per mostrare i risultati di un’ottimizzazione prendiamo in considerazione
un’immagine da pulire (Figura 6.1).
i parametri che si dovrebbero usare sarebbero i seguenti:
• picture threshold = 3.5
• boundary threshold = 7.5
• min number neighbours = 2
In Figura 6.2 l’immagine pulita.
Dove i valori dei parametri di qualità sono i seguenti:
ground truth difference: 206.18165264115387
closest approach: 0.12064042781505235 m
number different pixels: 5
Usando invece i parametri ottimizzati calcolati dallo script:
• picture threshold = 9
• boundary threshold = 18
• min number neighbours = 3
36CAPITOLO 6. DISCUSSIONE DEI RISULTATI OTTENUTI
In Figura 6.3 l’immagine pulita.
Dove i valori dei parametri di qualità sono i seguenti:
ground truth difference: 280.80540532704117
closest approach: 0.04652706142336392 m
numbers different pixels: 2
Ovviamente essendo il cleaning con i parametri ottimizzati più restrittivo,
toglie più informazione e proprio per questo il primo parametro (ground truth
difference) risulta più grande nel secondo caso.
Come si può vedere invece, gli altri due parametri hanno subito un netto
miglioramento.
6.2 Possibili utilizzi dei risultati trovati
Il problema principale del cleaning attuale, è che per ogni immagine bisogna
controllare che i parametri di cleaning diano risultati accettabili. Questo
ovviamente dovrebbe essere un processo da automatizzare perché anche es-
sendo ctapipe designato per il ”post hoc analysis”, c’è comunque una mole
che si aggira intorno al TeraByte per simtel file.
Avere dei parametri di cleaning fissi come allo stato attuale è impensabile ed
è per questo che un primo utilizzo dei dati trovati, potrebbe essere quello di
creare un cleaning che si adatta all’immagine presentata. Questo può essere
Figura 6.1: Immagine con rumore.
37Puoi anche leggere
