Working Group Tool Analisi Dati M. Spalla, F. Bertolucci, G. Volpi 4/2/2014

Introduzione Gruppo motivato dalla ricerca di sinergie nello strutturare i codici di analisi per: Semplificare la fase di inizio di un’analisi per un nuovi arrivati Semplificare lo scambio di informazioni tecniche e codice Creare un set di casi per guidare all’uso ottimale dell’infrastruttura locale e di ATLAS per vari tipi di analisi Contribuire alla preparazione di una documentazione per compiti generici di analisi Cercare di valutare «pro» e «contro» di strumenti diffusi in ATLAS Confrontare l’uso di strumenti sviluppati dai sottogruppi rispetto a procedure standard E.g. D3PDReader vs TSelector o altri strumenti nativi di ROOT A parità di complessità preferiti gli strumenti nativi di ROOT Qualche considerazione sulla performance nella prossima presentazione 4/2/2014

Reminder dei termini di ATLAS L’analisi in ATLAS può utilizzare formati dati custom o ntuple «generiche» RAW/RDO contengono la risposta del detector e del trigger, come da acquisizione/simulazione ESD contengono la ricostruzione degli oggetti primari (tracce, cluster calorimetrici, …) e la risposta del detector AOD contengono oggetti di alto livello, direttamente utilizzabili in un analisi Limitata possibilità di riprocessamento in caso di update, AODAODFix DPD/NTUP ntuple ROOT «plain» Formato e contenuto delle ntuple deciso a livello di gruppi di analisi Nessuna possibilità di riprocessamento da NTUPNTUP xAOD futuro formato AOD con leggibilità da ROOT a-la DPD ATLAS ufficialmente supporta analisi solo su GRID Largamente utilizzato lxbatch Supporto informale per PROOF Software disponibile tramite AFS o CVMFS (preferito) export ATLAS_LOCAL_ROOT_BASE=/cvmfs/atlas.cern.ch/repo/ATLASLocalRootBase alias setupATLAS='source ${ATLAS_LOCAL_ROOT_BASE}/user/atlasLocalSetup.sh' setupATLAS 4/2/2014

Linguaggi e librerie Nell’analisi tipica non è necessario scrivere algoritmi per Athena Diventa necessario solo se si deve interagire in maniera avanzata con le primitive dell’analisi: tutti gli scenari studiati non prevedo questo caso Il Python assume un ruolo centrale in ATLAS Gli algoritmi più complicati si controllano tramite la loro interfaccia come oggetti Python (algo.key = value) in speciali scripts (joboptions) Facile da interfacciare a ROOT tramite pyROOT E.g. «import ROOT», «from ROOT import …» C++ come linguaggio principali per compiti «complicati» Loop sugli eventi, riempimento istogrammi o creazione ntuple personali Compiti possibili anche in python Performance intermedie tra CINT e compilazione Bash limitato a setup e controllo dell’esecuzione del codice di analisi locale o su GRID 4/2/2014

Cosa è per noi un analisi Necessità di leggere dati esistenti (reali o Monte Carlo) e produrre una selezione I campioni possono essere su GRID o localmente I dati sono accessibili sotto forma di ntuple leggibili da ROOT Si vogliono leggere tutti gli eventi e: Selezionare solo quelli interessanti (cutflow) Produrre plot di controllo e distribuzioni interessanti Produrre un ntuple ridotta con variabili custom 4/2/2014

Strumeti presi in considerazione D3PDReader Strumento mantenuto dalla comunità di ATLAS Mantenuto da esperti all’interno dell’esperimento Si aspetta segua l’evoluzione futura del EDM Adatto all’uso su GRID Costruzione di un codice di analisi molto personale TSelector Strumento generico di ROOT Ampia storia e documentazione Scheletro rigido ma integrato con tutte le modalità di analisi supportate da ROOT Elemento base per PROOF, uso lineare in GRID Possibilità di passare parametri e di integrare strumenti esterni Qualche rigidità imposta dalla costruzione di questa classe speciale Proxy Supportato da ROOT e considerato l’eveoluzione del TSelector Qualche rigidità aggiuntiva rispetto al TSelector ma maggiori performance e minore tempo di creazione del codice Tutti questi strumenti sono integrabili con RootCore Altri strumenti non considerati: MakeClass o altri strumenti ATLAS derivate da analisi specifiche 4/2/2014

Mini esempio (caso speciale) #!/usr/bin/env python import sys from array import array inputfiles = sys.argv[1].split(",") # prun concatenates the input in a comma separated list import ROOT ROOT.gSystem.Load("libTrigFTKSim.so") chain = ROOT.TChain("ftkdata") nfiles = 0 for f in inputfiles : nfiles += chain.Add(f) print "N files:", nfiles outfile = ROOT.TFile.Open("somedistr.root","recreate") treentrkthr = ROOT.TTree("tree_ntracks","Track over threshold, "+",".join([str(v) for v in thrs])) noverthrs = array('i',len(thrs)*[0]) treentrkthr.Branch("NTracksOverThr",noverthrs,"NTracksOverThr[%d]/I" % len(thrs)) NEntries = chain.GetEntries() print "N entries:", NEntries # loop over the events for ievt in xrange(NEntries) : if ievt%1000 == 0 : print ievt, "/", NEntries chain.GetEntry(ievt) # loop over the FTK tracks ntracks = chain.FTKMergedTracksStream.getNTracks() for i in xrange(len(thrs)) : noverthrs[i] = 0 for itrk in xrange(ntracks) : ftktrack = chain.FTKMergedTracksStream.getTrack(itrk) pt = ftktrack.getPt()*1e-3 # GeV for i, v in enumerate(thrs) : if pt>v : noverthrs[i] += 1 else : break # threshold can only increas # end loop over the FTK tracks if ievt<10 : print ievt, noverthrs treentrkthr.Fill() # end loop over the events print "Write and close the file" outfile.Write() outfile.Close() 4/2/2014

Lezione «mini esempio» Può essere usato localmente o in grid ./esempio.py ntup1,ntup2 Con un piccola modifica la list di file può essere divisa da spazi prun --exec "./ntrackptgethr.py %IN" --inDS «input» --athenaTag 17.3.10.1.17,slc5,IBLProd --noBuild --outDS «output» --outputs somedistr.root –mergeOutput Produce un set di job che lavorano su 50 files ognuno Ogni job produce un singolo file di output Un file finale di merge è creato automaticamente L’utente può scaricare un singolo file e produrre plot, fare fit, etc. etc. Per esempi più complessi vedere la prossima presentazione 4/2/2014

Discuss…. 4/2/2014