View
213
Download
0
Category
Preview:
Citation preview
Claudio Grandi INFN-Bologna
L’ambiente per la simulazione e l’analisi in CMS
Claudio Grandi
INFN-Bologna
2Claudio Grandi INFN-Bologna
Attività principali
• Simulazione della fisica• Simulazione del rivelatore• Simulazione dell’elettronica• Simulazione del trigger
• Ricostruzione• Analisi
• La simulazione dell’elettronica viene chiamata digitizzazione
3Claudio Grandi INFN-Bologna
Attività principaliSimulazione della fisica
Simulazione del rivelatore
Geometria del
rivelatore
HITSDigitizzazione(Specifica di
CMS)
DIGI(raw data)
RicostruzioneDati perl’analisi
4-momenti
Simulazione del Trigger
Dati del Trigger
TriggerDIGI
4Claudio Grandi INFN-Bologna
PythiaZebra fileswith HITS
HEPEVTntuples
CMSIM(GEANT3)
MC
P
rod
.
ORCADigitization
(merge signaland pile-up)
ObjectivityDatabase
OR
CA
Pro
d.
ORCAooHit
FormatterObjectivityDatabase
Catalog import
Gli strumenti utilizzati
Level 1 Triggersimulation
HLT Algorithms Reconstructed
ObjectsHLT G
rp
Data
bases
ObjectivityDatabase
Catalog import
ObjectivityDatabaseObjectivityDatabaseytivitcejbOytivitcejbOesabataDesabataD
Mirro
red
Db
’s(U
S,R
ussia
,Italy
...)
5Claudio Grandi INFN-Bologna
Gli strumenti utilizzati
• Simulazione della fisica Pythia• Simulazione del rivelatore CMSIM (GEANT3)
• Simulazione dell’elettronica ORCA• Simulazione del trigger ORCA• Ricostruzione ORCA• Analisi ORCA+HBOOK+PAW ( +IGUANA)
C++/JAVA FORTRAN
6Claudio Grandi INFN-Bologna
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
7Claudio Grandi INFN-Bologna
Programmare in ORCA
N.B. Non entrerò nel dettaglio di come funziona ORCA né di come si programma ad oggetti
• L’utente deve costruire un oggetto di analisi, che come tutti gli oggetti viene creato e distrutto
• L’oggetto analisi deve sapere quando viene letto un nuovo evento per poterlo analizzare– L’oggetto 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, l’oggetto che si registra al Dispatcher si chiama Observer
8Claudio Grandi INFN-Bologna
Dispatcher/Observer
Obs1Obs1 Obs2Obs2 Obs3Obs3
DispatcherDispatcher
Obs4Obs4 ObserversObservers
9Claudio Grandi INFN-Bologna
Un oggetto di analisi• Tipicamente un’analisi deve eseguire qualcosa:
– all’inizio della sua vita
Nel costruttore dell’analisi– 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 dell’analisi
• L’oggetto di analisi viene creato (come oggetto statico) semplicemente dichiarandolo!
PKBuilder<UserAnal> myAnal(“UserAnal”);
10Claudio Grandi INFN-Bologna
Il flusso del programma• In ORCA gli oggetti vengono prodotti solo quando
richiesti:– l’iniziatore del processamento è il codice utente– l’analisi deve conoscere solamente a chi chiedere gli
oggetti che vuole utilizzare senza conoscere le fasi precedenti del processamento!
– All’atto 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
11Claudio Grandi INFN-Bologna
Lazy Observers
LazyLazyObs2Obs2
ObsObs
DispatcherDispatcher
LazyLazyObs1Obs1LazyLazyObs1Obs1obsoleteobsolete
LazyLazyObs2Obs2obsoleteobsolete
LazyLazyObs1Obs1uptodateuptodate
LazyLazyObs2Obs2uptodateuptodate
12Claudio Grandi INFN-Bologna
Esempio: il trigger di muoni
RPC DTBX CSC
RPCOn-chamber
TriggerElectronics
PACTPAttern
Comparator Trigger
RPCsorter
DTsorter
CSCsorter
Global muon Trigger
BTIBunch & Track Identifier
TRACOTRAck COrrelator
Trigger Server
DT MTTFMuon Trigger Track Finder
Wire card
motherboard
CSC MTTFMuon Trigger Track Finder
Strip LCTcard
Wire LCTcard
Strip card
Calorimeterquiet bits
13Claudio Grandi INFN-Bologna
Componenti DT on-chamber
Il TRACO costruisce tracce in unacamera correlando i segmenti deipiani 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
14Claudio Grandi INFN-Bologna
Pacchetti in ORCAInterfaccia all’utente System setup
ConfigurazioneGeometriaecc...
Simulazione delle componenti del trigger
15Claudio Grandi INFN-Bologna
Diagramma delle classiOggetti vistidall’utente
Si attivano solamente quandol’output del trigger è richiesto
Camere e TriggerUnits sono in corri-spondenza 1-1
16Claudio Grandi INFN-Bologna
Interaction diagram per il BTIQuando l’output è richiestoQuando un evento è letto
17Claudio Grandi INFN-Bologna
Esempio di codice utente#include “...” // All needed include files here
class UserAnal : ActiveObserver<G3EventProxy*> {
public:
UserAnal() {}
virtual ~UserAnal() {}
void upDate(G3Eventproxy* ev) {
// Processing an event...
L1MuDTTrigSetup* setup = Singleton<L1MuDTTrigSetup>::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<UserAnal> myAnal(“UserAnal”);
18Claudio Grandi INFN-Bologna
SCRAM e CVS
Software Configuration, Release And Management
– Sviluppato da CMS – Compilazione e link dei programmi (build)– Gestione della configurazione– Distribuzione dell’ambinete 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
19Claudio Grandi INFN-Bologna
Comandi frequentiscram 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 dell’ambiente 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 l’ultima versione disponibile nella
repository tag una versione a cui è stato dato un nome
20Claudio Grandi INFN-Bologna
La struttura delle directories
Top Directory
srclibbin tmpconfig logs.SCRAM
subsys OSOS OSOS
subsyscodice 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 pacchettiesterni
logfiles
21Claudio Grandi INFN-Bologna
Struttura per un sottosistema
Sub-systemtop Directory
srcinterface
package
test
domain
stubsinterfacce (.h, .icc)
implementazione dei metodi (.cc) .h e .cc per
librerie di test
informazionisul dominio(doc, html, ecc...) programmi
utente pertest(.cpp, .cc)
22Claudio Grandi INFN-Bologna
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 all’eseguibile– debug (libxxx_d.so e libxxx_d.a): ogni libreria
può essere compilata con l’opzione 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!)
23Claudio Grandi INFN-Bologna
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 dell’ambiente oltre ad un esempio di BuildFile (vedi oltre...)
24Claudio Grandi INFN-Bologna
BuildFile• Sono l’equivalente dei Makefile unix e sono
invocati da scram b (in test o Workspace)• Contengono le informazioni sulle librerie:
<ignore>commenti</ignore>
<External ref=cern>
<External ref=cmsim>
<lib name=L1MuDTTrigger>
<use name=Muon>
<use name=CARF>
<use name=Utilities>
<bin file=ExProdRead.cpp>
Commenti sull’eseguibile
</bin>
include prodotti esterni
include la libreria di un package
include tutte le libreriedi un sotto-dominio
sorgente dell’eseguibile
25Claudio Grandi INFN-Bologna
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
• L’interfaccia per l’uso del database (Objectivity) è in fase di sviluppo (molti cambiamenti in ORCA 4 rispetto ad ORCA 3!!!)
26Claudio Grandi INFN-Bologna
Input files
• In ORCA 3 era possibile leggere direttamente gli HITS di GEANT dai files .fz e fare tutta l’analisi in modo transiente
• In ORCA 4 l’analisi 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
27Claudio Grandi INFN-Bologna
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 nell’header file– sono possibili strutture arbitrariamente complesse!!!
28Claudio Grandi INFN-Bologna
Componenti di Objy
29Claudio Grandi INFN-Bologna
Un po’ di lessico di Objy
Federazione: è il punto d’ingresso 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
30Claudio Grandi INFN-Bologna
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)
31Claudio Grandi INFN-Bologna
Documentazione
• Pagine web:– http://cmsdoc.cern.ch/orca ORCA– http://cmsdoc.cern.ch/orca/tutorials/index.html tutorial di ORCA 3
– http://cmsdoc.cern.ch/Releases/SCRAM/current/doc/html/index.html SCRAM
– http://www.loria.fr/~molli/cvs/doc/cvs_toc.html CVS
– http://wwwinfo.cern.ch/asd/lhc++/Objectivity/index.html Objectivity
Recommended