Claudio Grandi INFN-Bologna Lambiente per la simulazione e lanalisi in CMS Claudio Grandi INFN-Bologna.

Presentazione sul tema: "Claudio Grandi INFN-Bologna Lambiente per la simulazione e lanalisi in CMS Claudio Grandi INFN-Bologna."— Transcript della presentazione:

1 Claudio Grandi INFN-Bologna Lambiente per la simulazione e lanalisi in CMS Claudio Grandi INFN-Bologna

2 Claudio Grandi INFN-Bologna 2 Attività principali Simulazione della fisica Simulazione del rivelatore Simulazione dellelettronica Simulazione del trigger Ricostruzione Analisi La simulazione dellelettronica viene chiamata digitizzazione

3 Claudio Grandi INFN-Bologna 3 Attività principali Simulazione della fisica Simulazione del rivelatore Geometria del rivelatore HITS Digitizzazione (Specifica di CMS) DIGI (raw data) Ricostruzione Dati per lanalisi 4-momenti Simulazione del Trigger Dati del Trigger DIGI

4 Claudio Grandi INFN-Bologna 4 Pythia Zebra files with HITS HEPEVT ntuples CMSIM (GEANT3) MC Prod. ORCA Digitization (merge signal and pile-up) Objectivity Database ORCA Prod. ORCA ooHit Formatter Objectivity Database Catalog import Gli strumenti utilizzati Level 1 Trigger simulation HLT Algorithms Reconstructed Objects HLT Grp Databases Objectivity Database Catalog import Objectivity Database Objectivity Database ytivitcejbOesabataD Mirrored Dbs (US,Russia,Italy...)

5 Claudio Grandi INFN-Bologna 5 Gli strumenti utilizzati Simulazione della fisica Pythia Simulazione del rivelatore CMSIM (GEANT3) Simulazione dellelettronica ORCA Simulazione del trigger ORCA Ricostruzione ORCA Analisi ORCA+HBOOK+PAW ( +IGUANA) C++/JAVA FORTRAN

6 Claudio Grandi INFN-Bologna 6 ORCA e CARF Object Reconstruction for CMS Analysis –digitizzazione del rivelatore –ricostruzione del rivelatore –simulazione del trigger –ricostruzione degli oggetti fisici –strumenti di analisi CMS Analysis and Reconstruction Framework –immagazzinamento dei dati –framework per analisi e ricostruzione La proprietà di un dato di poter essere immagazzinato su disco è detta persistenza Un oggetto non persistente è detto transiente

7 Claudio Grandi INFN-Bologna 7 Programmare in ORCA N.B. Non entrerò nel dettaglio di come funziona ORCA né di come si programma ad oggetti Lutente deve costruire un oggetto di analisi, che come tutti gli oggetti viene creato e distrutto Loggetto analisi deve sapere quando viene letto un nuovo evento per poterlo analizzare –Loggetto analisi si registra presso un servizio che sa quando viene letto un nuovo evento per poter essere notificato al momento opportuno Il servizio che notifica la presenza di un nuovo evento viene chiamato Dispatcher, loggetto che si registra al Dispatcher si chiama Observer

8 Claudio Grandi INFN-Bologna 8 Dispatcher/Observer Obs1Obs2Obs3 Dispatcher Obs4 Observers

9 Claudio Grandi INFN-Bologna 9 Un oggetto di analisi Tipicamente unanalisi deve eseguire qualcosa: –allinizio della sua vita Nel costruttore dellanalisi –al set-up della geometria (della calibrazione, ecc…) Deve essere Observer di SetUp –evento per evento Deve essere Observer di Event –alla fine del processamento Nel distruttore dellanalisi Loggetto di analisi viene creato (come oggetto statico) semplicemente dichiarandolo! PKBuilder myAnal(UserAnal);

10 Claudio Grandi INFN-Bologna 10 Il flusso del programma In ORCA gli oggetti vengono prodotti solo quando richiesti: –liniziatore del processamento è il codice utente –lanalisi deve conoscere solamente a chi chiedere gli oggetti che vuole utilizzare senza conoscere le fasi precedenti del processamento! –Allatto di una richiesta di alto livello viene iniziata una catena di richieste che arriva fino agli oggetti elementari (ad esempio i raw data). Le richieste vengono quindi soddisfatte ripercorrendo la catena in senso inverso La tecnica viene chiamata reconstruction on demand ed è implementata tramite LazyObserver

11 Claudio Grandi INFN-Bologna 11 Lazy Observers LazyObs2 Obs Dispatcher LazyObs1LazyObs1obsolete LazyObs2obsolete LazyObs1uptodate LazyObs2uptodate

12 Claudio Grandi INFN-Bologna 12 Esempio: il trigger di muoni RPC DTBX CSC RPC On-chamber Trigger Electronics PACT PAttern Comparator Trigger RPC sorter DT sorter CSC sorter Global muon Trigger BTI Bunch & Track Identifier TRACO TRAck COrrelator Trigger Server DT MTTF Muon Trigger Track Finder Wire card motherboard CSC MTTF Muon Trigger Track Finder Strip LCT card Wire LCT card Strip card Calorimeter quiet bits

13 Claudio Grandi INFN-Bologna 13 Componenti DT on-chamber Il TRACO costruisce tracce in una camera correlando i segmenti dei piani R- Il Trigger Server seleziona i migliori 2 segmenti della camera, sopprime i ghosts e passa le tracce al Trigger Regionale Il BTI trova segmenti in un quadrupletto e assegna il BX utilizzando una tecnica di mean-timer

14 Claudio Grandi INFN-Bologna 14 Pacchetti in ORCA Interfaccia allutente System setup Configurazione Geometria ecc... Simulazione delle componenti del trigger

15 Claudio Grandi INFN-Bologna 15 Diagramma delle classi Oggetti visti dallutente Si attivano solamente quando loutput del trigger è richiesto Camere e Trigger Units sono in corri- spondenza 1-1

16 Claudio Grandi INFN-Bologna 16 Interaction diagram per il BTI Quando loutput è richiesto Quando un evento è letto

17 Claudio Grandi INFN-Bologna 17 Esempio di codice utente #include... // All needed include files here class UserAnal : ActiveObserver { public: UserAnal() {} virtual ~UserAnal() {} void upDate(G3Eventproxy* ev) { // Processing an event... L1MuDTTrigSetup* setup = Singleton ::instance(); L1MuDTTrig* dttrig = setup->DTTrig(); //define chamber (iwh,ist,ise) and BX (is) int iwh=…;int ist=…;int ise=…;int is=…; L1MuDTChambPhSegm* first = dttrig->chPhiSegm1(iwh,ist,ise,is); L1MuDTChambPhSegm* second = dttrig->chPhiSegm2(iwh,ist,ise,is); L1MuDTChambThSegm* theta = dttrig->chThetaSegm(iwh,ist,ise,is); } }; #include Utilities/Notification/interface/PackageInitializer.h PKBuilder myAnal(UserAnal);

18 Claudio Grandi INFN-Bologna 18 SCRAM e CVS Software Configuration, Release And Management –Sviluppato da CMS –Compilazione e link dei programmi (build) –Gestione della configurazione –Distribuzione dellambinete di siluppo –condivisione delle risorse Concurrent Versioning System –Gestione del codice sorgente (anche in sviluppo!) Il processo di copilazione e creazione di librerie, link di un eseguibile, ecc... viene detto build

19 Claudio Grandi INFN-Bologna 19 Comandi frequenti scram list lista dei progetti disponibili scram project ORCA ORCA_4_0_0 installazione di una directory di sviluppo per ORCA 4.0.0 scram b build delle librerie o degli eseguibili eval `scram runtime -csh` definizione dellambiente per buid e running cvs co Examples/ExProduction copia il codice da CVS alla directory di lavoro repository dove CVS tiene il codice checkout/commit copia dal repository alla directory di lavoro e viceversa head lultima versione disponibile nella repository tag una versione a cui è stato dato un nome

20 Claudio Grandi INFN-Bologna 20 La struttura delle directories Top Directory srclib bin tmp config logs.SCRAM subsys OS subsys codice sorgente (checkout + utente) files temporanei (files oggetto, dipendenze, ecc...) librerie (incluso in $LD_LIBRARY_PATH ) configura- zioni per il build creata da scram project... eseguibili (incluso in $PATH ) configurzioni per i pacchetti esterni log files

21 Claudio Grandi INFN-Bologna 21 Struttura per un sottosistema Sub-system top Directory src interface package test domain stubs interfacce (.h,.icc) implementazione dei metodi (.cc).h e.cc per librerie di test informazioni sul dominio (doc, html, ecc...) programmi utente per test (.cpp,.cc)

22 Claudio Grandi INFN-Bologna 22 Librerie Viene prodotta una libreria per ogni sottosistema. Per crearla si usa scram b nella top directory del sottosistema –shared ( libxxx.so ): funzioni caricate a run-time si possono ricompilare le librerie senza dover ri-linkare! le librerie devono essere disponibili a run-time –archive ( libxxx.a ): funzioni attaccate alleseguibile –debug ( libxxx_d.so e libxxx_d.a ): ogni libreria può essere compilata con lopzione per il debugger (lenta! occupa molto spazio!) –per default vengono create shared e shared_debug Editare top_dir/config/library_makefile.mk per avere solo le shared (se è il caso!)

23 Claudio Grandi INFN-Bologna 23 Il sotto-dominio Workspace Contiene i programmi utente Assomiglia alla directory test di un package E il posto in cui lavorare! Per la configurazione si usa il file: top_dir/config/Worksapce_makefile.mk Se fate il check-out di Workspace avete alcuni programmi di esempio e files per la configurazione dellambiente oltre ad un esempio di BuildFile (vedi oltre...)

24 Claudio Grandi INFN-Bologna 24 BuildFile Sono lequivalente dei Makefile unix e sono invocati da scram b (in test o Workspace ) Contengono le informazioni sulle librerie: commenti Commenti sulleseguibile include prodotti esterni include la libreria di un package include tutte le librerie di un sotto-dominio sorgente delleseguibile

25 Claudio Grandi INFN-Bologna 25 Parametri Gran parte dei parametri (nomi dei files, numero di eventi, informazioni per il pile-up, ecc..) sono passati ai programmi tramite variabili ambientali unix Alcuni parametri di configurazione sono scritti nel file.orcarc che viene cercato nella directory di lavoro Linterfaccia per luso del database (Objectivity) è in fase di sviluppo (molti cambiamenti in ORCA 4 rispetto ad ORCA 3!!!)

26 Claudio Grandi INFN-Bologna 26 Input files In ORCA 3 era possibile leggere direttamente gli HITS di GEANT dai files.fz e fare tutta lanalisi in modo transiente In ORCA 4 lanalisi può essere fatta solamente a partire da databases di Objectivity Esiste un programma speciale di ORCA che viene chiamato ooHitFormat che copia gli HITS di GEANT dai files.fz ai databases di Objectivity senza fare alcun processamento

27 Claudio Grandi INFN-Bologna 27 Objectivity/DB Objectivity/DB ( Objy ) è un database ad oggetti. Ciò significa che i dati sono salvati in strutture complesse e non in strutture lineari –Vi ricordate: COMMON/MZSTORE/...ISTORE(BIGNUMBER) ??? Ogni oggetto è caratterizzato da un identificatore. Questo permette di usare un efficiente sistema di puntatori per navigare nel database Ogni oggetto è creato a partire dalle informazioni contenute nellheader file –sono possibili strutture arbitrariamente complesse!!!

28 Claudio Grandi INFN-Bologna 28 Componenti di Objy

29 Claudio Grandi INFN-Bologna 29 Un po di lessico di Objy Federazione: è il punto dingresso al sistema di databases Schema: contiene la struttura degli oggetti. E salvato nella federazione Database: coincide fisicamente con un file Boot file: contiene le informazioni per entrare nella federazione Lock server: è un processo che gestisce gli accessi concorrenti ai files delle federazioni AMS server: è un processo che permette di accedere ai databases remoti Container: le unità logiche in cui è diviso un database

30 Claudio Grandi INFN-Bologna 30 Uso di Objy con ORCA Ogni utente si crea una propria federazione di sviluppo La variabile ambientale $OO_FD_BOOT punta al boot file della federazione I databases coi dati possono essere attaccati alla federazione privata in read-only Se si vogliono solamente analizzare i dati senza modificare gli schemi o creare nuovi databases, si può usare la federazione comune di analisi (attualmente quelle dei gruppi HLT)

31 Claudio Grandi INFN-Bologna 31 Documentazione Pagine web: –http://cmsdoc.cern.ch/orca ORCAhttp://cmsdoc.cern.ch/orca –http://cmsdoc.cern.ch/orca/tutorials/in dex.html tutorial di ORCA 3http://cmsdoc.cern.ch/orca/tutorials/in dex.html –http://cmsdoc.cern.ch/Releases/SCRAM/cu rrent/doc/html/index.html SCRAMhttp://cmsdoc.cern.ch/Releases/SCRAM/cu rrent/doc/html/index.html –http://www.loria.fr/~molli/cvs/doc/cvs_ toc.html CVShttp://www.loria.fr/~molli/cvs/doc/cvs_ toc.html –http://wwwinfo.cern.ch/asd/lhc++/Object ivity/index.html Objectivityhttp://wwwinfo.cern.ch/asd/lhc++/Object ivity/index.html