Computing e Offline: Come faremo le analisi del 2017 e oltre? Tommaso Boccali – INFN Pisa Andrea Rizzi - Univ. e INFN Pisa

outline Parte 1: quali / quante risorse abbiamo / avremo Parte 2: modello di analisi per fine RunII, e oltre. Possibili soluzioni

Come avviene la richiesta risorse e il procurement in CMS per l’anno X? Tutto questo passa per C-RSG RRB (Computing Resource Scrutiny Group) che “raccomanda come agire alle Funding Agencies” Ottobre X-2: prima presentazione delle richieste, basata su stime LHC (Lamont) Aprile X-1: revisione delle stesse, approval finale (Agosto X-1: le Funding Agencies comunicano le pledges che intendono formire entro il 1 Aprile X) Ottobre X-1: nel caso di emergenze, possibilita’ di revisione finale (ma con poca possibilita di azione da parte delle FA, con bilanci gia’ sostanzialmente congelati) Richiesta CMS RRB C-RSG Processo di 1.5 anni Pledges nel DB WLCG (Rebus)

Come facciamo a decidere quanto chiedere? Modello di calcolo per RunII, basato su Input macchina (secondi di presa dati per anno, profile del PU, …) E’ quello che e’, nessuna liberta’ di manovra Input CMS (dimensione degli eventi, tempo di processing, parking, numeri eventi MC, numero di reprocessing…) Poca liberta’ di manovra, decisioni soprattutto dettate da fisica Scelte operazionali (numero di copie dei dati su Disco, expiration date dei vecchi processing ,…) Una certa liberta’ di manovra, che dipende da quanto si voglia rischiare e da quanto si sia disposti a investire in personale che fa operazioni

Esempi di fattori (pseudo) arbitrari scelti RECO: Vita media solo di 3 mesi Fatta per il 50% dei Primary Dataset AOD: Meno di 2 copie distribuite fra T1 e T2 Reprocessing Solo uno per i dati, a fine anno, molto meno di uno per la simulazione Vita media dei samples A meta’ dell’anno N+1 i reprocessing non finali se ne vanno. MiniAOD: Tre versioni durante l’anno (compreso reprocessing finale) MC/DT 130% …

Cosa e’ successo quest’anno, “rompendo” la procedura Inizio anno, posizione post Chamonix: “2016 sara’ simile al 2012 come luminosita raccolta (un anno standard di produzione)” “BCMS sara’ provato ma difficilmente in produzione, Lumi max ~ 1e34” LHC long term plans infatti erano 5Msec di Stable Beams (~1400 ore) Hubner factor (SB time / total Run time) < 0.4 PU mediato sul fill ~ 25

Situazione a posteriori BCMS

LHC Ore di Stable Beams per Week: 2012 max 80 / 168 (45%)

Stime revisionate il 29 Luglio 2016 per il 2016-2018 Visto l’andamento reale del 2016, LHC ha rivisitato completamente piano 2016-2018, alla luce di Hubner Factor ~0.6 (e’ stato 0.85 a Luglio 2016) BCMS On (quindi 1.9e34 nel 2017 e 2018) ~40% piu’ stable beams (== 40% piu’ eventi) PU mediato sul fill oltre 36 (e > 55 a inizio fill) Eventi accumulati fine 2017 simile alla stima precedente fine 2018 LHC marcia un anno in anticipo

La “crisi” di Agosto - Settembre Tutti questi parametri sono del primo tipo (non abbiamo capacita’ di manovra diretta), per cui nuove richieste 2017 in media +40% rispetto a quelle approvate a Aprile 2016. +40% ~ + 20 Meur a livello mondiale (sarebbe + 4 M Eur a livello italiano) Lavoro di Agosto: mitigazione con cambiamenti operazionali per arrivare a +20%. Modello frozen il 18 Agosto per SP/DSPs Scrutiny dell’RRB approva al 100% le richieste RRB approva come “best effort”: Investimenti ulteriori non devono intaccare PhaseII commitment

Come e’ finita la storia? WLCG Pledges Calcolo LHC Under pledge di circa il 20% su molte categorie, con punte del 30% Verita’ sotto il tappeto: alcune FA (INFN per esempio) ha promesso all’Esperimento piu’ di quanto abbia comunicato ufficialmente Nessun motivo per non fidarsi Ma rende il processo di scrutiny alquanto distaccato dalla realta’

Siamo nel panico? 2017 …. No! (ma di certo non c’e’ da stare tranquilli …) CPU: Grossi miglioramenti in arrivo, soprattutto nella parte di simulazione MC (il “premixing”) Tape: Abbiamo pulito tantissimo durante l’estate (~ 30 PB, record finora imbattutto nella fisica delle alte energie!) Disco: La disponibilita’ di AOD per l’analisi sara’ di fatto piu limitata di oggi; la contemporanea ascesa dei MiniAOD dovrebbe rendere la cosa non drammatica 2018: un bel problema, soprattutto formale Gli aumenti rispetto al 2017 sono al momento enormi (quasi solamente dovuto al fatto che 2017 e’ diminuito) Ci sono dei +70% Strategia: cercare di capitalizzare del lavoro dei prossimi 6 mesi per ridurre il 2018 a livelli poco superiori al 2017 Diciamo entro un 10-20% compatibile con il famigerato flat-budget

Modello di analisi CMS e’ in pratica l’unico ad avere un analysis model “libero” L’utente manda i jobs quando gli servono risultati Non dove coordinarsi con nessuno CRAB3 e’ la sua interfaccia con il calcolo distribuito Modello di calcolo un po’ fumoso su quanti jobs servano per fare analisi a CMS (dipende da una miriade di fattori), prevede ~ 50k jobs running in ogni momento – ci siamo agevolmente In molti momenti I jobs in coda >> jobs running Gli altri: train model (le analisi si girano solo una volta ogni N settimane, tutti insieme) Inoltre: Fino a livello di AOD (MiniAOD adesso) ci sono “produzioni ufficiali” Tutto quello che c’e’ dopo e’ lasciato all’utente, senza recipe precise Puo’ usare C++, Root, Python, Perl, VisualBasic, shell script Non esistono ricette ufficiali di nessun tipo (almeno, non ufficialmente blessed) Idea di fondo: non mettere barriere ai fisici fino a quando non siamo costretti

Come fare analisi in modo ottimale? In particolare: I MiniAOD: cosa sono e perche’ li abbiamo Cosa si puo’ fare con i MiniAOD e cosa non si puo’ fare Oltre AOD e MiniAOD: analisi utenti

Reconstruction Output I MiniAOD – cosa sono? FullEvent Notevole passo di lato rispetto al modello standard dei DataTier di CMS (Circa 2005) Fino a oggi, avevamo RAW: solo l’immagine binaria dei FED buffers ~1 MB/ev FullEvent: contiene RAW+ tutti I prodotti di ricostruzione, non salvato dal 2010 almeno ~ 5 MB/ev RECO: un subset di FullEvent. Contiene la maggior parte dei prodotti di ricostruzione, per esempio Hit, Tracks, … Ancora salvato per I dati con una vita media di 3 mesi ~ 2 MB/ev AOD: un subset di RECO; permette molto cose, ma per esempio non ReTracking (ma refitting si) ~300 kB/ev Modello a cipolla …. Mai nuovi prodotti, ma sottoinsieme dei precedenti Reconstruction Output RAW RECO AOD

Reconstruction Output I MiniAOD! FullEvent Reconstruction Output Contengono prodotti (anche) non presenti in AOD Sono ottimizzati per Velocita’ di accesso in analisi Precisione numerica “quanto basta” Soddisfare le necessita’ di 75-80% delle analisi (da disegni iniziale) ~ 40-50 kB/ev RAW RECO AOD MiniAOD

AOD/MiniAOD - Cosa contengono? 12/5/2017 AOD/MiniAOD - Cosa contengono? AOD Tutti i particleFlowCandidate con tutti dettagli per candidate Tutte le tracce e hit delle tracce Informazioni calorimetriche (reduced rechit ecal, calo tower) Tutti i POG objects (Mu, Ele, etc..) Tutte le GenParticle (Pythia output tutti gli status) MiniAOD Tutti i PF candidate ma senza tutti i dettagli (packedCandidates) Alcuni dettagli delle tracce solo per alcuni packedCandidate (pt >1 GeV) Info calorimetriche ridotte al “tipo” di packedCandidate Dettagli per i POG object con selezione di qualita’ minima Meccanismo Pruned + Packed gen particles (quadrivettori di tutte le particelle stabili e dettagli di quelle piu’ interessanti) 17 17

Cosa si puo’ (non si puo’) fare da MiniAOD? 12/5/2017 Cosa si puo’ (non si puo’) fare da MiniAOD? Si puo’ (ri)fare PF jet con algoritmi e parameteri arbitrari GenJet con algoritmi e parametri arbitrari b-tagging e in parte vertexing Ricalcolare isolamenti e ID di leptoni e fotoni Ricalcolare Tau ID Matching MC a particelle “interessanti” Accedere ad informazioni di trigger rilevanti per le analisi (bit e quadrivettori) Non si puo’ fare Refit tracce (AOD) e retracking (RECO) Exclusive (B) physics non va: non si puo’ fare refit a vertice con ipotesi di massa, per esempio Rigirare ParticleFlow o POG object reconstruction Vertexing di tracce con pt < 1GeV Tau reconstruction cambiando input jet collection Accedere a dettagli della simulazione Accedere a dettagli del trigger In generale non si possono usare strumenti (e.g. producer, filters, analyzer e altri tool) disegnati per AOD/RECO perche’ le informazioni anche quando presenti sono salvate in modo diverso (sono prodotti “nuovi”) Codice da scrivere “da zero” 18 18

AOD vs MiniAOD Nota importante in vista di PhaseII: 12/5/2017 AOD vs MiniAOD Come visto nella prima parte della presentazione, gli AOD sono la maggior parte dello spazio disco di CMS, che e’ il problema maggiore di CMS (dal punto di vista dei $$) Spinta di Physics Coordination ad usare sempre di piu’ MiniAOD (75-80%  90% ??) Richiesta ai PAG di verificare fattibilita’ Piano di improvement a MiniAOD per allargare le possibilita Size budget per evento dei MiniAOD non puo’ essere sostanzialmente modificato La size comunque cresce con il PU La maggior parte degli use case puo’ essere coperto con piccoli ritocchi (~100byte/evento) I casi “troppo” particolari richiederebbero di aprire le porte dell’inferno (aumenti di oltre un fattore 2) Nota importante in vista di PhaseII: AOD = 10 MB MiniAOD = 250 kB … fattore 40 essenziale per stare nel budget delle risorse 19 19

Novita’ recenti in MiniAOD 12/5/2017 Novita’ recenti in MiniAOD Possibilita’ di accedere alle informazioni di tutte le tracce Parametrizzazione (vs pt,eta, nhit, etc..) della matrice di covarianza delle tracce Possibilita’ di avere “track details” anche sotto 1 GeV re-Vertexing (btag, tau, esclusione di tracce dal PV, etc..) Recupero delle generalTracks non usate da particleFlow nella collezione lostTrack Gia’ esistente per btag, estendere a tutto highPurity Piu’ dettagli per Elettroni/GSF (ambiguous track) Ulteriori miglioramenti per tau-reconstruction (forse) Pre-calcolo nei POG object di quantita’ diffuse a livello di analisi (e.g. miniIsolation) 20 20

Parametrizzazione Track covariance 12/5/2017 Parametrizzazione Track covariance Idea: Le incertezze di una traccia dipendono soprattutto da Pt, eta ed n-hit (altri effetti rilevanti: posizione primo hit, incertezza primo hit) Invece di salvare traccia per traccia la covarianza (50-100 Kb/ev) approssimare la covarianza con il valore medio per la data categoria eventualmente salvando in pochi bit le deviazioni rispetto a questo valore medio WORK IN PROGRESS G.Mandorli 21 21

Oltre i miniAOD Cosa esiste “dopo i MiniAOD”? Nulla di ufficiale, ma: 12/5/2017 Oltre i miniAOD Cosa esiste “dopo i MiniAOD”? Nulla di ufficiale, ma: Framework privati di vari gruppi/istituti (Python, FWLite, ROOT, C++, Scalla, qualunque cosa …) Framework pubblico (in CMSSW) usato da alcuni gruppi/istituti (PhysicsTools/Heppy) Problemi: Le ricette dei POG per ID, isolamento, event filtering, noise reduction, sistematiche, etc.. sono date in twiki e ogni gruppo reimplementa Manutenzione dei vari framework implica duplicazione del lavoro Fase di Ntuplizzazione sempre piu’ impegnativa dal punto di vista del calcolo O(2 miliardi) eventi per processing, a 1-10 Hz - > 10k-100k jobs Cosa potremmo volere per il futuro? (survey in arrivo) Ntuple centrali buone per l’analisi media (50% coverage?) Fwk centrale per farsi le proprie ntuple, ma con le POG recipes gestite centralmente Modello a treno: tanti ntuplizzatori privati eseguiti tutti insieme a scadenze fissate da computing 22 22

Heppy Nato da CMGTools, mantenuto da Colin/Giovanni/Andrea 12/5/2017 Heppy Nato da CMGTools, mantenuto da Colin/Giovanni/Andrea Parte “core” utilizzata anche da FCC Utilizzato da vari gruppi (Higgs, Susy, … ) Heppy e’ un framework python che mette moduli di analisi in sequenza (alla CMSSW) Lepton analyzer, Jet analyzer, etc… Utilizza la flessibilita’ del python per rendere tutto piu’ semplice (ma anche pericoloso e meno controllato): Tutti gli analyzer possono scrivere quello che vogliono dove vogliono Gli oggetti non hanno struttura “prefissata” (posso aggiungere proprieta’ ad un elemento ad ogni istante) Fornisce un sistema semplice per lavorare su “oggetti” e scrivere su flat ntuples Puo’ essere un punto di partenza come common fwk di CMS ma andrebbe riorganizzato definendo responsabilita’ 23 23

Perche’ Heppy (e Python?) Per utenti che vogliano solo analizzare dati e non contribuire allo sviluppo di algoritmi, Python e’ (incredibilmente) piu semplice di C++ Esempio: prova tutte le coppie di jets e trova quella con pt della coppia piu' alto e la salva nell'evento Esempio 2: non si deve compilare, messaggi di errore piu’ chiari

Conclusioni Il Calcolo di CMS ha retto bene per il 2016 Anche in presenza di condizioni impreviste A prezzo di un enorme sforzo umano, difficilmente sostenibile per lunghi periodi 2017: ce la faremo (anche se ci hanno dato meno delle richieste) 2018: un po’ da inventare, ma ci sono i presupposti per non sballare le richieste Modello di analisi Volutamente, in CMS e’ molto liberale Grossa spinta verso la standardizzazione con i MiniAOD, mai piu’ ricette home-made a-la PAT Andare verso una standardizzazione ulteriore?