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 model-independent 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 Three 8” PM Tubes Plastic tank White light diffusing liner De-ionized water Solar panel and electronic box Comm antenna GPS antenna Battery box

Spherical focal surface: 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. XML Config File Run Controller Sequencer Module Registry VModule Module

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 EventFile Reader Lancio del job: userAugerOffline –b bootstrap.xml defaultFD FManager FCalibSQL Manger database server defaultSD

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.