19 ottobre 1999LHCb - GAUDI 1 GAUDI - Architettura e framework di LHCb Marco Cattaneo, CERN Ottobre 1999.

Presentazione sul tema: "19 ottobre 1999LHCb - GAUDI 1 GAUDI - Architettura e framework di LHCb Marco Cattaneo, CERN Ottobre 1999."— Transcript della presentazione:

1 19 ottobre 1999LHCb - GAUDI 1 GAUDI - Architettura e framework di LHCb Marco Cattaneo, CERN Ottobre 1999

2 19 ottobre 1999LHCb - GAUDI 2 Riassunto  Introduzione –L’esperimento LHCb –Organizzazione del progetto di Calcolo –Strategia per lo sviluppo del software  Architettura GAUDI –Scopo e obiettivi –Scelte del design –Qualche dettaglio  Implementazione –Scelte tecnologiche, Tools,... –Stato del progetto e piani per il futuro

3 19 ottobre 1999LHCb - GAUDI 3 LHCb: L’Esperimento  LHCb é un esperimento all’LHC dedicato a misure con grande precisione della violazione di CP nel decadimento di B d e B s  LHC é uno strumento ideale per produrre grandi quantità di B d e B s  Tutti i canali interessanti sono rari, con branching ratios intorno a 10 -5.

4 19 ottobre 1999LHCb - GAUDI 4 LHCb: Il Rivelatore

5 19 ottobre 1999LHCb - GAUDI 5 LHCb in cifre  Collaborazione: ~45 istituti, ~350 persone  Costo: 86 MCHF  Electronica: ~10 6 canali  Trigger: 4 Livelli. 40 MHz  1 MHz  40 kHz  5 kHz  200 Hz  Acquisizione Dati: 100 kB/evento. 2-4 GB/s  20 MB/s. 1.5 10 6 MIPs  Stato attuale: –Technical proposal in febbraio 1998 –Approvato in settembre 1998 –Fase R&D per ~2 anni (TDRs nel 2000-2001)

6 19 ottobre 1999 6 Organizzazione del Progetto di Calcolo

7 19 ottobre 1999LHCb - GAUDI 7 Strategia di sviluppo per il nuovo software  Fase di design con una piccola squadra di 6-8 persone –architetto, amministratore delle librerie, specialisti dei domini con esperienza di design e/o programmazione  Stabilire i criteri di base per il design globale  Raccogliere User Requirements e scenari, per convalidare il design  Fare scelte tecnologiche per implementare i primi prototipi  Approccio incrementale allo sviluppo. Release ogni ~4 mesi.  Ciclo di sviluppo guidato dagli utenti. Priorità, feedback, etc.  Design Review completa (~1/anno) seguita da decisioni strategiche  Release accompagnati da documentazione completa  Allargare squadra di sviluppo per coprire nuovi domini

8 19 ottobre 1999LHCb - GAUDI 8 Architettura GAUDI  Vogliamo sviluppare una Architettura e un Framework da usarsi a tutti gli stadi dell’analisi dei dati di LHCb –Trigger livelli 2 e 3, simulazione, ricostruzione, analisi –Le applicazioni di controllo (slow control, run control) non sono comprese  Gli utenti (i fisici) svilupperanno le applicazioni personalizzando il framework; –ereditando dalle base classes –usando i componenti del framework –attraverso parametri di configurazione  I componenti saranno sviluppate anche usando altri frameworks specializzati (GUI, persistenza, simulazione,... )

9 19 ottobre 1999LHCb - GAUDI 9 Struttura del Software Frameworks Toolkits RicostruzioneSimulazione Analisi Foundation Libraries Triggers Una serie di Frameworks e di Toolkits. Un framework principale: GAUDI, vari frameworks specializzati: visualizzazione, persistenza, interattività, simulazione (Geant4), etc. Una serie di librerie di base: STL, CLHEP, etc. (Vocabolario) Una serie di applicazioni costruite sopra i frameworks, che implementano gli algoritmi di fisica.

10 19 ottobre 1999LHCb - GAUDI 10 Principali criteri del design  Separazione tra “dati” e “algoritmi”  Tre tipi di dati: –“event data” (dati ottenuti dalle collisioni delle particelle - vere o simulate) –“detector data” (struttura, geometria, calibrazioni, allineamenti, parametri ambientali,..) –“statistical data” (istogrammi, …)  Separazione tra dati “persistenti” e dati “transienti”. –Isolamento del codice degli utenti dalla tecnologia di persistenza –Criteri di ottimizzazione diversi e/o incompatibili. –Transiente come ponte tra diverse rappresentazioni.

11 19 ottobre 1999LHCb - GAUDI 11 Principali criteri del design (2)  I dati (“data stores”) al centro dell’architettura. –“Algoritmi” come produttori e consumatori di “data objects” –Accoppiamenti minimi tra algoritmi  “User code” incapsulato in pochi luoghi specifici: – “Algoritmi”: Codice di fisica – “Convertitori”: Convertono data objects da una rappresentazione a un’altra  Ogni componente ha una o più “interfaccie” ben definite, le più “generiche” possibili. »In C++, pure abstract class

12 19 ottobre 1999LHCb - GAUDI 12 Object diagram

13 19 ottobre 1999LHCb - GAUDI 13 Interfaccie ConcreteAlgorithm EventDataService IDataProviderSvc IHistogramSvc IMessageSvc IAlgorithm IProperty ObjectAObjectB Ogni componente implementa una o più interfaccie Ogni componente usa una o più interfaccie di altri componenti Un Algoritmo usa molti Servizi DetectorDataService HistogramService MessageService ParticlePropertySvc IParticlePropertySvc

14 19 ottobre 1999LHCb - GAUDI 14 Algoritmi Algorithm A Algorithm B Algorithm C Transient Event Data Store Data T1 Data T2, T3 Data T2 Data T3, T4 Data T4 Data T5 Data T1 Data T5 Real dataflowApparent dataflow Un Algoritmo sa solo quali dati (tipo e nome) usa come input, e quali creerà come output. Il solo accoppiamento tra algoritmi è tramite i dati. L’ordine di esecuzione dei sub- algoritmi è la responsabilità dell’algoritmo genitore. A C B Parent

15 19 ottobre 1999LHCb - GAUDI 15 Servizi  Agli algoritmi vengono forniti vari servizi  Esempi: –Job Options service (card files) –Message reporting service –Event/Detector/Histogram data service –Event Selector –Persistency and Conversion services –User Interface (GUI) –Particle property service –... Particle Prop. Service Algorithm PP File IService IParticlePropertySvc IProperty

16 19 ottobre 1999LHCb - GAUDI 16 Event Data Store Transient Event Store Event Data Service Persistency Service Algorithm retrieveObject( “EcalDigits(3)”,...) registerObject( “key”,...) Direct reference Fetch() Store() creates Mantiene in memoria gli oggetti utilizzabili da altri oggetti (servizi, algoritmi). Recupera oggetti se necessario Struttura ad albero (file system) Identificazione tramite indirizzo logico (“/Event/RawEvent/Ecal”) Lo Store è il proprietario degli oggetti. È sua responsabilità fare il clean-up.

17 19 ottobre 1999LHCb - GAUDI 17 OutputStream Persistenza Event Data Service Persistency Service Sicb data Files Algorithm SicbCnvSvc RootCnvSvc Root data Files Converter Sicb/Zebra Root I/O OutputStream AppManager Transient Event Store Varie tecnologie disponibili simultaneamente: Objy, Root, Zebra,… Convertitori per trasformare gli oggetti da una rappresentazione a un’altra

18 19 ottobre 1999LHCb - GAUDI 18 Data Processing Application Editors Conversion services Algorithms Detector Description Persistent Detector Description (DDDB) DetElem Geom Calib Geom Slow Editors Transient detector store DetElem Geom Calib Slow Algorithms Conversion services Projection view: version & event time Other representations ? Update persistency Detector Data Producers

19 19 ottobre 1999LHCb - GAUDI 19 Visualizzazione Transient Event/ Detector Store Conversion Service Representations Store (graphical, textual) Converter Data Item Selector User Interface Selects objects in store

20 19 ottobre 1999LHCb - GAUDI 20 Configurazione  Quali sono i bottoni disponibili? –JobOptions. Semplici da usare. Permettono all’utente di modificare le caratteristiche e parametri di qualsiasi algoritmo o servizio (cards file) –Properties database. Un modo più sofisticato per modificare le caratteristiche degli algoritmi e servizi. –Detector database. Per creare nuove configurazioni del rivelatore o delle condizioni. –Scrivere codice specifico. Per esempio è possibile configurare l’applicazione specificando nelle JobOptions quali algoritmi eseguire e in che ordine. –User interface. Grafica, command line (scripting language), etc.

21 19 ottobre 1999LHCb - GAUDI 21 Packages Package group Package dependency Gaudi (foundations) LHCbEvent (event model) HbookCnv (converters) SicbCnv (converters) RootCnv (converters) GaudiExam. (applications) LHCbAlg (algorithms) DetDesc (detect. model) DetCnv (converters) Futio (SICB) optional RIO CernLib CLHEP STL GAUDI Framework La suddivisione in packages è un problema architetturale. Grosse conseguenze per: tempo di compilazione dipendenze di link configuration management taglia dell’eseguibile... Le dipendenze tra packages devono essere approvate dall’architetto. Evitare dipendenze circolari

22 19 ottobre 1999LHCb - GAUDI 22 Implementazione  Piattaforme: –WNT, Linux, IBM AIX, HP-UX  Tools e Librerie:

23 19 ottobre 1999LHCb - GAUDI 23 Stato del progetto  Sett ‘98 - nominato architetto, riunita squadra di 6 persone  Nov 25 ‘98 - review esterna dell’architettura – obiettivi, architecture design document, URD, scenari  Feb 8 ‘99 - GAUDI primo release –prima software week con presentazioni e tutorials –pianificazione (insieme agli utenti) del secondo release –ingrandimento della squadra GAUDI  Mag 30 ‘99 - GAUDI secondo release –seconda software week … –pianificazione del terzo release –ingrandimento della squadra GAUDI (GEANT4 simulation toolkit)  Nov ‘99 - prossimo release e software week  Gen ‘00 - seconda review esterna

24 19 ottobre 1999LHCb - GAUDI 24 Lavori in corso:  Integrazione di GEANT4  Visualizzazione, event display  Detector description  Algoritmi e tools per l’analisi dei dati  Evaluazione Java  Collaborazione con LHC++ –Definizione delle interfaccie  Prossimamente: Migrazione del programma di ricostruzione

25 19 ottobre 1999LHCb - GAUDI 25 Strategia di migrazione  Obiettivo finale: tutte le applicazioni esclusivamente in OO  Fase di transizione –Incorporare i programmi di ricostruzione e analisi esistenti in GAUDI (wrap FORTRAN) »Rompere il programma esistente in algoritmi indipendenti »Sviluppare un modello OO completo dell’evento »Scrivere convertitori che permettono l’accesso ai dati nei due formati »Problemi: molti convertitori nelle due direzioni, COMMON blocks etc. –Nuovi algoritmi possono essere sviluppati esclusivamente in GAUDI »e.g. Tracking pattern recognition  Fase ibrida –C++ e FORTRAN coesistono in un unico programma di ricostruzione »Problemi: 2 detector decriptions, 2 card files, doppia memoria, che formato per l’output? –Rimpiazzare il FORTRAN gradualmente

26 19 ottobre 1999LHCb - GAUDI 26 Conclusioni  Abbiamo completato il primo anno del viaggio verso OO –L’architettura è definita (interfaccie, componenti) –Due release del framework sono stati fatti, con una funzionalità minima, per provare le varie idee. –Il terzo release, in novembre, avrà una funzionalità sufficiente per incominciare una migrazione dal FORTRAN.  Abbiamo bisogno di consigli e critiche –Organizzazione, design fisico, development tools, libraries, foundation libraries, etc. –Decisioni strategiche del design, frameworks e soluzioni esistenti, etc. –Strategia di migrazione  Abbiamo bisogno di collaboratori –Integrazione di altri tools nel framework –Perfezionamento di componenti esistenti