Claudio Grandi - INFN

L’ambiente per la simulazione e
l’analisi in CMS
Claudio Grandi
INFN-Bologna
Claudio 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
Claudio Grandi
INFN-Bologna
2
Attività principali
4-momenti
Geometria
del
rivelatore
Dati per
l’analisi
Dati del
Trigger
Claudio Grandi
INFN-Bologna
Simulazione
del rivelatore
Simulazione
della fisica
HITS
Digitizzazione
(Specifica di
CMS)
Ricostruzione
DIGI
(raw data)
Simulazione
del Trigger
Trigger
DIGI
3
ORCA Prod.
MC Prod.
Gli strumenti utilizzati
HEPEVT
ntuples
Pythia
CMSIM
(GEANT3)
Zebra files
with HITS
Catalog import
Objectivity
Database
ORCA
Digitization
(merge signal
and pile-up)
Objectivity
Database
ORCA
ooHit
Formatter
HLT Grp
Databases
Claudio Grandi
INFN-Bologna
Objectivity
Database
Objectivity
Objectivity
Database
ytivitcejbO
Database
esabataD
Mirrored Db’s
Level 1 Trigger
simulation
HLT Algorithms
Reconstructed
Objects
(US,Russia,Italy...)
Catalog import
4
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
Claudio Grandi
INFN-Bologna
FORTRAN
5
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
Claudio Grandi
INFN-Bologna
6
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
Claudio Grandi
INFN-Bologna
7
Dispatcher/Observer
Dispatcher
Obs1
Claudio Grandi
Obs2
INFN-Bologna
Obs3
Obs4
Observers
8
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”);
Claudio Grandi
INFN-Bologna
9
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
Claudio Grandi
INFN-Bologna
10
Lazy Observers
Dispatcher
Lazy
Obs2
uptodate
obsolete
Lazy
Obs1
uptodate
obsolete
Claudio Grandi
INFN-Bologna
Obs
11
Esempio: il trigger di muoni
RPC
DTBX
CSC
RPC
BTI
Wire card Strip card
On-chamber
Trigger
Electronics
Bunch & Track Identifier
PACT
Trigger Server
TRACO
TRAck COrrelator
Wire LCT
card
Strip LCT
card
motherboard
PAttern
Comparator
Trigger
Muon Trigger Track Finder
Muon Trigger
Track Finder
RPC
sorter
DT
sorter
CSC
sorter
Calorimeter
quiet bits
Claudio Grandi
DT MTTF
CSC MTTF
Global muon Trigger
INFN-Bologna
12
Componenti DT on-chamber
Il BTI trova segmenti in un
quadrupletto e assegna il BX
utilizzando una tecnica di
mean-timer
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
Claudio Grandi
INFN-Bologna
13
Pacchetti in ORCA
Interfaccia all’utente
System setup
Simulazione delle
componenti del trigger
Claudio Grandi
INFN-Bologna
Configurazione
Geometria
ecc...
14
Diagramma delle classi
Si attivano solamente quando
l’output del trigger è richiesto
Oggetti visti
dall’utente
Camere e Trigger
Units sono in corrispondenza 1-1
Claudio Grandi
INFN-Bologna
15
Interaction diagram per il BTI
Quando un evento è letto
Claudio Grandi
INFN-Bologna
Quando l’output è richiesto
16
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”);
Claudio Grandi
INFN-Bologna
17
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
Claudio Grandi
INFN-Bologna
18
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
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
Claudio Grandi
INFN-Bologna
19
La struttura delle directories
creata da
Top Directory
scram project ...
.SCRAM
bin
OS
OS
config
configurazioni per il
build
Claudio Grandi
OS
logs
log
files
src
subsys
tmp
OS
subsys
codice sorgente
(checkout + utente)
files temporanei
librerie (incluso in
(files oggetto,
$LD_LIBRARY_PATH) dipendenze, ecc...)
eseguibili
(incluso in $PATH)
configurzioni
per i pacchetti
esterni
lib
INFN-Bologna
20
Struttura per un sottosistema
informazioni
sul dominio
(doc, html, ecc...)
domain
interface
package
src
implementazione
dei metodi (.cc)
interfacce
(.h, .icc)
Claudio Grandi
Sub-system
top Directory
INFN-Bologna
programmi
utente per
test
(.cpp, .cc)
test
stubs
.h e .cc per
librerie di
test
21
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!)
Claudio Grandi
INFN-Bologna
22
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...)
Claudio Grandi
INFN-Bologna
23
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>
Claudio Grandi
INFN-Bologna
include prodotti esterni
include la libreria
di un package
include tutte le librerie
di un sotto-dominio
sorgente dell’eseguibile
24
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!!!)
Claudio Grandi
INFN-Bologna
25
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
Claudio Grandi
INFN-Bologna
26
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!!!
Claudio Grandi
INFN-Bologna
27
Componenti di Objy
Claudio Grandi
INFN-Bologna
28
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
Claudio Grandi
INFN-Bologna
29
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)
Claudio Grandi
INFN-Bologna
30
Documentazione
• Pagine web:
– http://cmsdoc.cern.ch/orca ORCA
– http://cmsdoc.cern.ch/orca/tutorials/in
dex.html tutorial di ORCA 3
– http://cmsdoc.cern.ch/Releases/SCRAM/cu
rrent/doc/html/index.html SCRAM
– http://www.loria.fr/~molli/cvs/doc/cvs_
toc.html CVS
– http://wwwinfo.cern.ch/asd/lhc++/Object
ivity/index.html Objectivity
Claudio Grandi
INFN-Bologna
31