Computing e Offline Come faremo le analisi del

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 Run. II, e oltre. Possibili soluzioni

Come avviene la richiesta risorse e il procurement in CMS per l’anno X? • 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 Tutto questo passa per C-RSG RRB (Computing Resource Scrutiny Group) che “raccomanda come agire alle Funding Agencies” RRB C-RSG Pledges nel DB WLCG (Rebus) Processo di 1. 5 anni

Come facciamo a decidere quanto chiedere? • Modello di calcolo per Run. II, basato su 1. Input macchina • (secondi di presa dati per anno, profile del PU, …) • E’ quello che e’, nessuna liberta’ di manovra 2. Input CMS • (dimensione degli eventi, tempo di processing, parking, numeri eventi MC, numero di reprocessing…) • Poca liberta’ di manovra, decisioni soprattutto dettate da fisica 3. 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 dei samples • AOD: • Mini. AOD: • Reprocessing • MC/DT • Vita media solo di 3 mesi • Fatta per il 50% dei Primary Dataset • Meno di 2 copie distribuite fra T 1 e T 2 • Solo uno per i dati, a fine anno, molto meno di uno per la simulazione • A meta’ dell’anno N+1 i reprocessing non finali se ne vanno. • Tre versioni durante l’anno (compreso reprocessing finale) • 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 ~ 1 e 34” • LHC long term plans infatti erano • 5 Msec 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%) • 2016 max 140 / 168 (83%)

Stime revisionate il 29 Luglio 2016 per il 20162018 • 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. 9 e 34 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 Phase. II 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 Mini. AOD 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 • CRAB 3 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 ~ 50 k 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 (Mini. AOD adesso) ci sono “produzioni ufficiali” • Tutto quello che c’e’ dopo e’ lasciato all’utente, senza recipe precise • Puo’ usare C++, Root, Python, Perl, Visual. Basic, 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 Mini. AOD: cosa sono e perche’ li abbiamo • Cosa si puo’ fare con i Mini. AOD e cosa non si puo’ fare • Oltre AOD e Mini. AOD: analisi utenti

I Mini. AOD – cosa sono? • Notevole passo di lato rispetto al modello standard dei Data. Tier di CMS (Circa 2005) • Fino a oggi, avevamo Full. Event Reconstruction Output RAW RECO • RAW: solo l’immagine binaria dei FED buffers • ~1 MB/ev • Full. Event: contiene RAW+ tutti I prodotti di ricostruzione, non salvato dal 2010 almeno • ~ 5 MB/ev • RECO: un subset di Full. Event. 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 Re. Tracking (ma refitting si) • ~300 k. B/ev • Modello a cipolla …. Mai nuovi prodotti, ma sottoinsieme dei precedenti AOD

I Mini. AOD! • 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) Full. Event Reconstruction Output RAW RECO AOD • ~ 40 -50 k. B/ev Mini. AOD

AOD/Mini. AOD - Cosa contengono? • AOD ● ● ● Tutti i particle. Flow. Candidate con tutti dettagli per candidate • Mini. AOD ● Tutte le tracce e hit delle tracce ● Informazioni calorimetriche (reduced rechit ecal, calo tower) ● Tutti i POG objects (Mu, Ele, etc. . ) Tutte le Gen. Particle (Pythia output tutti gli status) ● ● Tutti i PF candidate ma senza tutti i dettagli (packed. Candidates) Alcuni dettagli delle tracce solo per alcuni packed. Candidate (pt >1 Ge. V) Info calorimetriche ridotte al “tipo” di packed. Candidate 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)

Cosa si puo’ (non si puo’) fare da Mini. AOD? • Si puo’ (ri)fare ● ● ● ● PF jet con algoritmi e parameteri arbitrari Gen. Jet 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 Particle. Flow o POG object reconstruction Vertexing di tracce con pt < 1 Ge. V 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”

AOD vs Mini. AOD ● ● 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’ Mini. AOD (75 -80% 90% ? ? ) – Richiesta ai PAG di verificare fattibilita’ Piano di improvement a Mini. AOD per allargare le possibilita Size budget per evento dei Mini. AOD non puo’ essere sostanzialmente modificato – ● – – La size comunque cresce con il PU – La maggior parte degli use case puo’ essere coperto con piccoli ritocchi (~100 byte/evento) – I casi “troppo” particolari richiederebbero di aprire le porte dell’inferno (aumenti di oltre un fattore 2) Nota importante in vista di Phase. II: – AOD = 10 MB – Mini. AOD = 250 k. B … fattore 40 essenziale per stare nel budget delle risorse

Novita’ recenti in Mini. AOD ● 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 Ge. V re-Vertexing (btag, tau, esclusione di tracce dal PV, etc. . ) Recupero delle general. Tracks non usate da particle. Flow nella collezione lost. Track – ● ● ● Gia’ esistente per btag, estendere a tutto high. Purity 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. mini. Isolation)

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 WO RK IN P ROG RES S G. Mandorli

Oltre i mini. AOD ● Cosa esiste “dopo i Mini. AOD”? 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 (Physics. Tools/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 - > 10 k-100 k 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

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’ – ● ●

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 Mini. AOD, mai piu’ ricette home -made a-la PAT • Andare verso una standardizzazione ulteriore?