Commissioning and Operation of the CMS Tracker analogue optical link system at TIF with CMSSW:
Alcuni approcci allanalisi dati (tra CMSSW e ROOT) Riunione mensile di software e analisi,...
-
Upload
gianmaria-quarta -
Category
Documents
-
view
220 -
download
1
Transcript of Alcuni approcci allanalisi dati (tra CMSSW e ROOT) Riunione mensile di software e analisi,...
Alcuni approcci all’analisi dati (tra CMSSW e ROOT)
Riunione mensile di software e analisi, 15/12/2008
Massimo Nespolo
1
Sommario:• Dalle root-uple all’EDM di CMS:
– Motivazione;– Confronto critico;
• Nella pratica:– Grafici immediati;– Approccio uniforme;
• Soluzione “definitiva”:– TFWLiteSelector.
Alcuni approcci all’analisi dati (tra CMSSW e ROOT)
2
Il problema
L’analisi viene effettuata parte in CMSSW e parte in ROOT
L’analisi in ROOT deve essere il piu’ possibile “agile”
Bisogna far comunicare i due framework
Necessità di avere un formato dati che faccia da ponte,ma che sia insieme facile da manipolare e da interpretare
ROOT opera su alberi, ma non impone l’organizzazione dei dati
3
Prima idea: Ntupla
TTree* anaTree = new TTree("events", "analysis tree" );const int Nmus = 100;float* ptmu = new float[Nmus];int Nmuons = 0;anaTree->Branch("ptmu", ptmu, "ptmu[Nmuons]/F" );
Utilizziamo i costrutti di base del C++ (arrays, puntatori, tipi base) e di ROOT (TTree, TBranches)
Otteniamo l’obbiettivo: un file per l’analisi in ROOT
Ci siamo appiattiti sul minimo comune a CMSSW e ROOT !
mama
4
Semplicità solo apparente
Ci siamo dimenticati (come spesso succede) che il C++ e’ un linguaggio “a due livelli” (Carlo Pescio, C++ Informer 12, ottobre 2000):
Iniziamo cosi' a capire la natura "a due livelli" del C++, (…): il C++ offre un supporto nativo low-level per costruire astrazioni di piu' alto livello. Il programmatore dovrebbe lavorare con queste astrazioni, costruendole quando servono, e non lavorare costantemente al livello nativo.
Estremamente incline all’errore (riservato ai piu’ esperti)
1. Spesso nessun delete[].
2. Rischio di sforare il limite dell’array.
3. Impossibile il type-cheking a tempo di compilazione.
1. Memory leaks.
2. Errore a run-time con morte del programma.
3. Si perdono i vantaggi del controllo forte sui tipi.
5
Destrutturazione dell’evento
Vantaggio per pochi dati, immediatamente visibili
Vi sono raggruppamenti “logici” di alcune variabili (prefissi)
Mostra velocemente i suoi limiti al crescere del numero delle varibili
La Ntupla costituisce una rappresentazione “piatta” (flat) dell’evento, senza sotto-strutture
Dovrebbero essere ottenuti tramite le strutture (branches) di ROOT
6
Seconda idea: classi custom (adapter)
7
1. Numerose (una per ogni classe di CMSSW).2. Per loro stessa natura instabili, modificate spesso.3. Non standard, cosa che si cerca di evitare.
Ambedue i problemi che abbiamo visto possono essere risolti ricorrendo ad opportune astrazioni
Scrivere delle classi, che incapsulino i dettagli
Idea subito abbandonata (fortunatamente), poiché:
EDM dentro ROOT
8
Tutti i files di CMS sono in realtà files di ROOT,con una struttura gerarchica “naturale”
1. A ciascuna collezione corrisponde un ramo.2. A ciascuna variabile corrisponde una foglia.3. Esistono alias compatti e standardizzati.
Abbiamo solo bisogno di un sistema che ci isoli dalle variabili private, per loro stessa natura soggette a cambiamento...
E’ sempre possibile fare un’analisi “tipo rootupla”,
a partire da ogni file di CMSSW
Dal prompt o tramite le classi generate da MakeClass e (meglio) da MakeSelector
FWLite
9
Libreria (sottinsieme del FrameWork CMSSW) che consente di interpretare il contenuto dei files di CMS
gSystem->Load("libFWCoreFWLite");AutoLibraryLoader::enable();gSystem->Load("libDataFormatsFWLite");
TFile file(“rootFile.root" );
A questo punto, abbiamo acceso diretto alla struttura gerarchica definita dall’EDM di CMS, ma soprattutto
alle funzioni che costituiscono l’interfaccia delle classi.
In pratica…
Un esempio grafico…
10
… e due esempi dal prompt
11
Events->Draw("IC5CaloJet.theta():IC5CaloJet.phi()", "", "LEGO2 CYL")
Events->Draw("Muons.pt():Muons.isolationR03().sumPt/Muons.pt()", "Muons.pt()<100")
Vantaggi
12
E’ possibile visualizzare il contenuto di ogni file, così come
produrre istogrammi e matrici
Il codice è sostanzialmente identico a quello che utilizziamo
in CMSSW: nomi delle classi, delle funzioni, degli alias…
Non dipendiamo dalla traduzione operata da una classe di tipo EDAnalyzer
Una volta capito l’EDM, possiamo concentrarci
sull’obbiettivo dell’analisi
Tutte le proprietà degli oggetti che stiamo analizzando sono
sempre disponibili
Non devo ripassare per CMSSW se mi serve una
nuova variabile
Aggiungere dati all’evento
13
Se il prodotto è relativamente “stabile”
Scriviamo un EDProducer (non un EDAnalyzer)
Se e’ una cosa che cambia spesso (tipo la massa invariante calcolata
per diversi tagli)
Lavoriamo in ROOT, e salviamo il prodotto in un
albero friend
I due approcci non sono mutualmente esclusivi:il concetto di albero friend si applica al momento in cui i files
vengono aperti per l’analisi in ROOT
fwlite::Event
14
TFile file(“rootFile.root");fwlite::Event ev(&file);
for( ev.toBegin(); ! ev.atEnd(); ++ev) { //sort of iterator
fwlite::Handle<std::vector<reco::Muon> > muons; muons.getByLabel(ev,“Muons");
//now we can access data}
Event loop esplicito, ma astrazione dai dettagli dei Branches
1. fwlite::Handle muons;2. muons.getByLabel(ev, “Muons”)
1. edm::Handle muons;2. ev.getByLabel( “Muons”, muons)
Un esempio: la Z
15
Rosso: pt > 20 GeVRosso: pt > 20 GeV e 2 muoni
TFWLiteSelector
16
TFWLiteSelector eredita da TSelector
1. Impone di separare Begin/Process/Terminate.2. Nessun loop esplicito (gestito internamente).3. Supporta il parallelismo tramite PROOF.
Alla funzione Process viene passato edm::Event, non
fwlite::Event
Il codice di analisi è identico (non solo simile) a
quello dell’EDAnalyzer
Differenza fondamentale rispetto a fwlite::Event
TFWLiteSelector: in pratica
17
class MyAnalysisAlgorithm {public: void process( const edm::Event & ); void postProcess( TList & ); void terminate( TList & );};
Isoliamo l’algoritmo di analisi in una classe (o una
struct) a parte
TFile file(“rootFile.root");TSelector* mysel = new TFWLiteSelector<MyAnalysisAlgorithm>Events->Process( mysel );
Creiamo un’istanza di TFWLiteSelector passando l’algoritmo come template
TFWLiteSelector ed EDAnalyzer
18
Lo stesso algoritmo può essere eseguito in CMSSW
void MyAnalyzer::analyze(const edm::Event& ev, const edm::EventSetup& ) {
algo_.process( ev ); }
Basta scrivere un EDAnalyzer molto semplice e standard
(pattern Adapter, GoF)
L’algoritmo visto prima diventa un membro privato della classe EDAnalyzer
Soluzione ottima, ma non aggiornata al formato di CMSSW 2_1_X
In sintesi…
19
• Il C++ è un linguaggio “a due livelli”:– Le classi devono rappresentare elementi del problema.– Vantaggi programmazione Object-based (non ancora
Object-oriented, di cui non abbiamo parlato).• FWLite:
– Accesso completo dell’EDM di CMS.• TFWLiteSelector:
– Analisi “ordinata” e parallelizzabile.– Possibilità di muovere il codice da ROOT a CMSSW.
• Analisi agili a partire da ogni file di CMS:– Interpretare i risultati è già abbastanza complicato…