Slides - Agenda INFN

Auger Offline
Domenico D’Urso
Università “Federico II” e sez. INFN di Napoli
I Corso di formazione INFN
su aspetti pratici dell'integrazione di applicazioni in GRID 12 Novembre 2007
Osservatorio Pierre Auger:
un rivelatore ibrido
Rivelatori di superficie (SD) + Telescopi per la luce di
fluorescenza (FD)
 Diverse
tecniche di misura consentono la
compresnione delle incertezze sistematiche
riguardanti le singole tecniche
 Una migliore risoluzione della ricostruzione del
“core” e della traiettoria dei RC
 La misura “calorimetrica” dell’energia effettuata
con l’FD permette di calibrare in energia l’SD
(da sempre una delle maggiori e più
problematiche questioni di questa tecnica),
facendo così in modo che l’SD sia in grado di
stimare l’energia dei RC in modo quasi modelindependent
 Possibilità di misurare un set più ampio di
parametri sensibili alla massa del primario
L’Osservatorio P. Auger sarà
completato entro gennaio 2008
 4 edifici per la
rivelazione di
luce di
fluorescenza,
ognuno con 6
telescopi,
 1600 rivelatori
Cerenkov
(spaziati di 1.5
km su una
griglia a maglia
triangolare)
4800 PMTs, di
cui ~1400 già
attivi
3000 km2 di superficie
Surface Detectors
Solar panel and
electronic box
GPS
antenna
Comm
antenna
Three 8”
PM Tubes
White light
diffusing liner
De-ionized water
Battery
box
Plastic tank
The FD telescope
Spherical mirror, 3.4 m
radius of curvature
2.2 m diameter
diaphragm, corrector ring
30ox30o FOV, 15 mm
diameter spot
Spherical focal surface:
 20x22 hexagonal PMTs
(Photonis XP3062)
 light collectors (mercedes star);
pixel size = 45 mm
Obiettivi del progetto Offline




Fornire una infrastruttura per il supporto delle varie
attività legate all’analisi dei dati dell’Osservatorio
Pierre Auger ed alla sua simulazione
Essere flessibile per venire incontro alle esigenze di
un elevato numero di utenti e di un esperimento di
durata ventennale
Permettere di simulare e ricostruire eventi
utilizzando l’apparato di superficie, i telescopi di
fluorescenza o entrambi (eventi ibridi)
Consentire la ricostruzione e l’analisi dei dati delle
tecniche di calibrazione dell’apparato nonché degli
eventi laser prodotti da due laser facilities poste al
centro dell’area occupata dall’Osservatorio
Obiettivi del progetto Offline (2)



Essere facilmente generalizzabile o estendibile nel
caso di futuri upgrades dell’apparato sperimentale
Gestire diversi formati di dati sia di input che di
output, basati su classi ROOT
Sfrutturare tutte le potenzialità del C++ e della
programmazione object-oriented e ad al tempo
stesso consentire da parte di utenti non esperti di
programmazione sia un semplice utilizzo sia una
facile implementazione dei propri codici di analisi
Costituenti Principali



Un insieme di moduli che possono essere
assemblati e messi in sequenza
mediante
istruzioni fornite tramite un XML file
Una struttura event attraverso cui i moduli
possono scambiarsi i dati l’un l’altro e dove
vengono
scritte
tutte
le
informazioni
di
simulazione e ricostruzione
Una struttura detector dove è riprodotto il
funzionamento e la configurazione dell’apparato in
funzione del tempo
Gestione dei Moduli: Run
Controller


Le operazioni di data processing della Collaborazione Auger
possono essere facilmente fattorizzate. Gli algoritmi sono
implementati in moduli, inseriti nel framework mediante una
macro.
L’esecuzione della sequenza dei moduli è gestita mediante un
Run Controller. La sequenza, così come i parametri di
configurazione dei vari moduli o dello stesso framework, è
specificata mediante degli XML files.
Run Controller
XML
Config
File
Sequencer
VModule
Module Registry
Module
XML
Config
File
Gestione dei Moduli: Run
Controller (2)


La struttura modulare
consente facilmente di
confrontare algoritmi, di
sostituirli e di combinarli
nei più svariati modi.
Le informazioni di
configurazione sono
registrate in un oggetto
chiamato CentralConfig
specificando un file di
bootstrap che contiene le
informazioni ed i link ai file
di configurazione.

Durante l’esecuzione il programma è in grado di
verificare se i parametri di configurazione corrispondono
a quelli suggeriti di default mediante md5 digests.
Descrizione dell’Event




La struttura event può contenere in sé i dati raw, di
calibrazione, di ricostruzione e di Monte Carlo.
È il principale mezzo di comunicazione tra i moduli: in
essa i moduli scrivono i risultati dei loro algoritmi e da
essa estraggono le informazioni di cui necessitano.
L’accesso alle strutture dati avviene solo by reference e
tutti i costruttori sono resi “private” per evitare una
qualsiasi copia accidentale.
La struttura è creata automaticamente se necessario ed
è fornita di semplici funzioni per interrogare l’event
riguardo i suoi costituenti: event.HasFEvent().
Descrizione del Detector

È stata realizzata un’unica interfaccia per gestire le
informazioni riguardanti la configurazione e le
performances del rivelatore.
L’interfaccia è
organizzata
seguendo la
gerarchia
dell’apparato
sperimentale.

L’accesso ai dati viene gestito da managers, che
estraggono informazioni da diverse fonti:
 XML files nel caso di informazioni fisse (tipo la
posizione di una occhio etc..)
 databases MySQL, nel caso si tratti di
informazioni dipendenti dal tempo
(calibrazioni, status dell’atmosfera, etc..)
Descrizione del Detector (2)




I managers gestiscono anche le situazioni in cui al tempo
specificato non è presente la quantità a cui si è interessati
(tipo informazioni sulla trasparenza atmosferica ad una
data ora) secondo quanto specificato nei loro files di
configurazione
A seconda dei dati è possibile utilizzare differenti manager
in modo da rendere estremamente flessibili le condizioni di
utilizzo (qualità di grande aiuto soprattutto in fase di
simulazione).
La struttura detector è fornita di funzioni particolari, models, che
possono essere utilizzate per il processamento di dati ottenuti sul
rivelatore (modello per calcolare l’attenuazione della luce fra due punti,
modello di PMT, di liner di una tank, etc..)
I modelli possono essere gestiti da un super-model (es.SuperMieModel)
Utilities
Con il software sono distribuiti una serie di
utilities:
 un parser XERCES basato su linguaggio XML;
 un error logger;
 vari strumenti per la gestione di quantità
fisiche e matematiche;
 utilities di test;
 un pacchetto di geometria che permette
l’utilizzo di oggetti geometrici astratti quali
punti e vettori, sui quali è possibile eseguire
operazioni in “astratto”, senza la necessità di
un sistema di coordinate di riferimento.
Controllo codici



Test di unità per ogni singolo componente del framework
utilizzando il framework CppUnit (unit tests).
Verifica del corretto funzionamento delle applicazioni
durante il loro continuo sviluppo (acceptance tests).
BuildBot, un sistema Python-based:
 un master deamon è informato ogni qualvolta il codice
viene modificato in modo rilevante;
 il master ordina ad un set di build slaves, presenti su
varie piattaforme, di scaricare l’ultima versione del
codice, ricompilarlo e procedere ai vari test di
controllo (unit e acceptance).
 in caso di incongruenze nei test, vengono mandati dei
messaggi di warning agli sviluppatori interessati.
Pacchetti Esterni
L’Offline fa uso di diversi pacchetti esterni:
 Doxygen, per la generazione della documentazione;
 MySQL, per la creazione e la gestione dei database;
 Xerces, per l’analisi sintattica dei file XML e la loro validazione;
 CLHEP, per l’implementazione delle trasformazioni di geometria;
 BOOST, per le sue estensioni del C++;
 ROOT, per le sue classi di supporto;
 Geant4 (opzionale), per la simulazione dettagliata dell’apparato;
 CppUnit, per la realizzazione degli unit tests
 CDAS, librerie di acquisizione dell’apparato di superficie;
 FDEventLib, librerie di acquisizione dell’apparto di fluorescenza;
 AIRES, Monte Carlo per la simulazione degli sciami in atmosfera.
Test dell’Offline su varie piattaforme
Esempi: Hybrid Event
Reconstruction


La ricostruzione di un evento
ibrido viene suddivisa in step
logici, ad ognuno dei quali
corrisponde un modulo
L’organizzazione in moduli
consente facilmente di
sostituire algoritmi alternativi
per un determinato step e
confrontare così diverse
metodologie di
processamento esattamente
nelle stesse condizioni
Lancio del job: userAugerOffline –b bootstrap.xml
defaultFD
FManager
FCalibSQL
Manger
database
server
defaultSD
EventFile
Reader
Conclusioni




L’Offline è un software framework per l’analisi dei dati
estremamente flessibile.
La sua struttura modulare permette in modo naturale di
poter confrontare diverse metodologie per la risoluzione di
un problema.
L’interfaccia realizzata per l’accesso alle informazioni sul
rivelatore e sull’evento consente di evitare agli utenti di
dover interagire con diversi formati e dati sorgenti.
L’implementazione dell’analisi con l’Offline, senza rinunciare
a tutte le potenzialità del linguaggio C++ e della
programmazione object-oriented, ne rende possibile l’utilizzo
anche agli utenti meno esperti.