Alcuni approcci allanalisi dati (tra CMSSW e ROOT) Riunione mensile di software e analisi, 15/12/2008 Massimo Nespolo 1

Sommario: Dalle root-uple allEDM di CMS: – Motivazione; – Confronto critico; Nella pratica: – Grafici immediati; – Approccio uniforme; Soluzione definitiva: – TFWLiteSelector. Alcuni approcci allanalisi dati (tra CMSSW e ROOT) 2

Il problema Lanalisi viene effettuata parte in CMSSW e parte in ROOT Lanalisi 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 lorganizzazione 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 lobbiettivo: un file per lanalisi in ROOT Ci siamo appiattiti sul minimo comune a CMSSW e ROOT ! ma 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 allerrore (riservato ai piu esperti) 1.Spesso nessun delete[]. 2.Rischio di sforare il limite dellarray. 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 dellevento 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) dellevento, 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 unanalisi 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 dallEDM di CMS, ma soprattutto alle funzioni che costituiscono linterfaccia 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 lEDM, possiamo concentrarci sullobbiettivo dellanalisi Tutte le proprietà degli oggetti che stiamo analizzando sono sempre disponibili Non devo ripassare per CMSSW se mi serve una nuova variabile

Aggiungere dati allevento 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 lanalisi in ROOT

fwlite::Event 14 TFile file(rootFile.root"); fwlite::Event ev(&file); for( ev.toBegin(); ! ev.atEnd(); ++ev) { //sort of iterator fwlite::Handle > 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 dellEDAnalyzer 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 lalgoritmo di analisi in una classe (o una struct) a parte TFile file(rootFile.root"); TSelector* mysel = new TFWLiteSelector Events->Process( mysel ); Creiamo unistanza di TFWLiteSelector passando lalgoritmo 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) Lalgoritmo 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 dellEDM 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…