IL CALCOLO DEGLI ESPERIMENTI AD LHC DOPO LA SCOPERTA DELL’HIGGS Tommaso Boccali INFN Pisa 1.

Presentazione sul tema: "IL CALCOLO DEGLI ESPERIMENTI AD LHC DOPO LA SCOPERTA DELL’HIGGS Tommaso Boccali INFN Pisa 1."— Transcript della presentazione:

1 IL CALCOLO DEGLI ESPERIMENTI AD LHC DOPO LA SCOPERTA DELL’HIGGS Tommaso Boccali INFN Pisa 1

2 I modelli di calcolo degli esperimenti LHC Perche’ servono? La mole di dati raccolta e resa disponibile per l’analisi e’ ~2 ordini di grandezza superiore a qualsiasi esperimento precedente. Per la prima volta era chiaro non bastasse riempire una stanza di computer vicino all’apparato. Come sono strutturati? Il modello di calcolo e’ : Distribuito: Come da progetto MONARC (1999); decisione sia pratica sia politica Strutturato in livelli (Tier): Non tutti i siti sono uguali, soprattutto per la qualita’/quantita’ di Rete Geografica disponibile e la Qualita’ del Servizio I task critici (come la messa in sicurezza dei dati) sono limitati a pochi siti ben gestiti e connessi Il (un) MiddleWare Grid serve da colla, dando la “parvenza” (ad altissimo livello) di risorse flat WLCG con la funzione di governance politica dei siti, e per i contatti con le Funding Agencies 2

3 Run I, II, III, IV, … 3 Si sta gia’ parlando di un possibile ritardo, con RunII che dura tutto il 2018 e RunIV spostato di 12 mesi RunI: Higgs

4 In generale, “quanto” e’ il calcolo di LHC in termini assoluti e relativi?? Totali 4 Esperimenti, worldwide, 2015 (Pledges RRB) CPU: 3 MHS06 ( ~ 300k cores) Disk: 250 PB Tape: 250 PB Non comprende: Risorse non dichiarate Tier3 Cluster privati Risorse opportunistiche … Questo all’inizio del Run II, e poi?

5 Business emails sent 3000PB/year (Doesn’t count; not managed as a coherent data set) Google search 100PB Facebook uploads 180PB/year Kaiser Permanente 30PB LHC data 15PB/yr YouTube 15PB/yr US Census Lib of Congress Climate DB Nasdaq Wired 4/2013 In 2012: 2800 exabytes created or replicated 1 Exabyte = 1000 PB Reputed capacity of NSA’s new Utah center: 5000 ExaBytes (50-100 MW) Current ATLAS data set, all data products: 140 PB http://www.wired.com/magazine/2013/04/bigdata/ Big Data in 2012 We are big… not NSA-big, but big (and more cost efficient) We are big… not NSA-big, but big (and more cost efficient) ~14x growth expected 2012- 2020 ~14x growth expected 2012- 2020 C.Grandi

6 RunI, II, III, IV: terminologia (pp, ATLAS e CMS) Run2: 2015-2018 Up to 1.5e34, 25 ns, 13-14 TeV – up to 50 fb -1 /y = 30 Run3: 2020-2022 Up to 2.5e34, 25 ns, 13-14 TeV - up to 100 fb -1 /y = 50-60 Run4: 2025-2028 Up to ~5e34, 25 ns 13-14 TeV – up to 300 fb -1 /y = 140-200 Questa e’ la “Fase2” per ATLAS/CMS 6 1 y 6 y 11 y (+1?)

7 7 Gli esperimenti …

8 Esperimenti general purpose (ATLAS e CMS) Il “problema” e’ che l’Higgs e’ basso in massa, se si vuole studiare nel dettaglio non e’ possibile alzare le soglie dei trigger e mantenere stessi rates da HLT Altrimenti efficienza su H->WW (per esempio) decresce rapidamente Single lepton: necessario mantenere 20- 30 GeV almeno Scalando con la luminosita’, mantenendo ferme le soglie, l’effetto sui trigger e’ O(400 Hz) in 2012 O(1 kHz) in 2015-2018 O(5-10 kHz) in 2025+ 8

9 ALICE Per ALICE le motivazioni sono diverse, ma l’idea e’ di cambiare il rate input a HLT da O(100 Hz) a O(50 kHz) Cioe’ in pratica “tutto” Gia’ per RunIII (2020+).. E circa il 40% verso offline Il mondo HLT e Offline vengono “mischiati” Progetto O 2 2015+: up to 0.5 nb-1 (PbPb) 2020+: up to 10 nb-1 (PbPb) 1 TB/s 13 GB/s to tape Storage Reconstruction + Compression 50 kHz 80 GB/s 50 kHz (1.5 MB/event)

10 LHCB Per LHCb il salto e’ per RunIII (2020+) Anche qui, essenzialmente senza trigger di livello 1 (40 MHz verso HLT) Lumi livellata a 2x10 33 cm -2 s -1 (25 ns), 5x rispetto a 2012 (con 50 ns); > 2 Fino a 20 kHz “on tape” 2018+ Erano 5,12,20 kHz in 2012,2015 20kHz*5Msec = 100B events/y ! (memento: solo 100 kB/ev) Nessun reprocessing offline! La prompt reco _deve_ essere ok 10

11 Come scalano le risorse informatiche con acceleratore / scelte sperimentali? CPU: scala Linearmente con trigger rate (se tutto quello che viene raccolto deve essere processato… vedere dopo) + che linearmente con complessita’ dell’evento ( ), # tracks, … Con i dati integrati su almeno 2 anni Analisi: scala anche con il # di analisi contemporanee, e quindi con il # di utenti Storage: scala Linearmente con il trigger rate Meno che linearlmente con, … Con i dati integrati almeno dallinizio del Run … Mettendo tutto insieme in una simulazione, viene fuori che: Totali wrt RunI: RunII(III) = ~6-10, RunIV >100 11 Various Trigger Levels OFFLINE Rate #sec/year Event Size

12 Evoluzione 2025+ In modalita’ diverse i 4 Esperimenti LHC hanno delle upgrade sostanziali in vista, e cosi’ l’acceleratore I piani non sono del tutto sicuri, ancora, ma CMS, ATLAS: trigger rate 10x, Complessita’ dell’ evento 5x (e tempo di ricostruzione e’ + che lineare) Fattore 100-200 in aumento reale delle risorse 2025 vs 2015 LHCb, ALICE: aumenti meno spaventosi, ma upgrade 5 anni prima (2020)

13 Come fare a garantire fattori O(100) in 10- 12 anni? (la questione chiave e’ “allo stesso prezzo dell’attuale” Il famoso flat funding ) E’ facile se la tecnologia evolve a +50%/y (~ fattore 2 ogni 2 anni) Altrimenti non c’e’ davvero una risposta al momento Un po’ di idee ci sono Nessuna vera soluzione +50%/y +25%/y +20%/y

14 Un tempo 50% anno “si faceva” Moore’s law: “il numero di transistor per mm^2 raddoppia ogni 2 anni” (~50%/anno) 14 Butter’s law of photonics: “la portata di una fibra ottica raddoppia ogni 9 mesi” e Nielsen’s law: “La banda disponibile agli utenti aumenta del 50% l’anno” Kryder’s law: “la capacita’ di un disco magnetico per mm^2 raddoppia ogni 2 anni”

15 Queste leggi non hanno nulla di “profondo”, sono solo constatazioni a posteriori su un certo periodo Non hanno davvero carattere di predizione, e in effetti tutto fa pensare che stiamo “rallentando” 15

16 Previsioni CERN (B.Panzer) B.Panzer/CERN (2013): CPU +25%/y Storage +20%/y ~ raddoppio ogni 3-4 anni invece di 2 Su tre anni (2013-2015): ~2x Su sette anni (2013-2020): ~5x Su 13 anni (2013-2026): 10-15x 16 We are here CPU Disk

17 E la prospettiva economica? “siamo fortunati se potremo ottenere un flat funding” Stesse risorse ogni anno (ma stesse rispetto a quale anno?) Col RunII non siamo magari troppo lontani (ehm …) Ma al RunIV mancano fattori fra O(10x) Che fare? Convincere le FA a aumentare i fondi Fare “altro”, e in particolare Senza impattare la fisica prevista Con impatti sulla capacita’ di fare fisica 17 Miglioramenti nel modello (fare lo stesso, meglio) Fare meno, ma senza conseguenza

18 Alcune idee… 1. Usare meglio le risorse (ma siamo gia’ abbastanza bravi adesso, con risorse utilizzate al 100% del pledge se non oltre!) 2. Cercare nuove risorse (libere o … gratis?) 3. Cambiare tecnologia (GPGPU, ARM, FPGA, …) 4. (fare meno, ma senza impatto sulla fisica 1. Meno trigger rate 2. Soglie di ricostruzione piu’ alte 3. Meno MC 4. …) 5. Fare meno. (Amen)

19 19 Usare meglio le risorse Non banale, gli Esperimenti LHC le usano almeno al livello del 90% (a tutti i livelli gerarchici) C’e’ un po’ di margine, dovuto in generale alle restrizioni del modello e alla differenza residua fra i task che possono essere eseguiti sui vari Tier Per esempio, quando non c’e’ presa dati il Tier0 sarebbe libero per altre attivita’ (come analisi), ma in generale non e’ detto che ci siano al CERN dati a disposizione da analizzare. I Tier2 potrebbero fare reprocessing dei dati nelle vacanze natalizie, ma non hanno I dati Raw Accesso remoto ai dati diventato nel frattempo (piu’) possibile, grazie alle nuove reti geografiche general purpose (Youtube, Spotify, Facebook, …) 19

20 Trovare piu’ risorse (a pagamento o gratis…) Esistono risorse “nostre” non utilizzate da disegno nel computing offline Esempio lampante sono le farm di trigger, che sono assolutamente idle quando LHC non e’ in collisione Queste da disegno sono inutilizzate Nei Long Shutdown (~2 anni ogni 5-6) Negli Shutdown Invernali (~3 mesi l’anno) Nei Technical Stop (~ 1 settimana al mese) Negli Interfill (~30-50% del tempo di presa dati) Purtroppo non sono “facili” da utilizzare secondo il modello GRID SysOp diverso, no MiddleWare GRID Spesso sono usabili per piccole finestre di tempo, e con pattern non troppo prevedibili Risorse scientifiche “non nostre” Risorse di altre scienze Centri di calcolo HPC (Anche la Grid aveva come scopo un loro utilizzo, ma richiedeva una standardizzazione che per alcuni centri non e’ realizzabile) 20

21 … o a pagamento! Un tempo eravamo fra i maggiori utilizzatori di calcolo nel mondo, adesso la situazione e’ evoluta Stima della Cloud Amazon: O(50M) cores di calcolo disponibili (150x quello che usa tutto LHC) Stima storage NSA = 5M PB (~10000x) Nostro pattern di utilizzo interessante per i provider Cloud: Processing real time molto limitato Interessati piuttosto ll’integrale su perdiodi lunghi Possiamo (?) non utilizzare troppo storage sui provider Il trend generale e’ quello di provare a rendere qualunque risorsa disponibile utilizabile per i nostri task Drastico abbassamento delle richieste da parte degli esperimenti sui siti Per poter avere una platea piu’ ampia Containers, VM, (assenza di) storage locale … tutto va bene! Gestione centralizzata delle istanze di calcolo, non solo piu’ dei workflow: la Cloud! 21

22 3. Improve the algorithms We are not IT scientists, and in the pre Run1 phase focus was to have a running software Since then, large effort spent on optimization of critical part, with huge success (not uncommon 2x per year) Much more difficult in the future, low hanging fruits are gone 22

23 23 Cambio di tecnologia Per avere una speranza di essere “money efficient”, dobbiamo seguire I trend tecnologici M HEP! 23

24 Quali sono i trend tecnologici maggiori? Videogames GPGPU, calcolo vettoriale Smartphones / Tablet Basso consumo, basso prezzo - bassa potenza (50 $ vs 1000 $, 10W vs 100W, 1000 Gflops vs 7000 Gflops) Nvidia TitanX 7000 Gflops 250 W (~1000$) Tegra X1 1000 Gflops 10 W (8 ARMv8 cores) ($50?) Xeon E5 2650- v3 1000 Gflops 115W 1000$ 24

25 Fare meno Senza impatto sulla fisica (?) Fare meno MC e reprocessing, usando la conoscenza del detector da RunI Distribuire meno copie dei dati, usando accesso remoto Impatto non chiaro, ma di certo non positivo… Con impatto sulla fisica Diminuire trigger rate da 10 kHz a … dove si puo’ Aumentare threashold della riscostruzione offline Per esempio non fare tracking delle tracce sotto X GeV Ricostruire solo parte degli eventi “parcheggiando” in attesa di tempi liberi

26 Trend attuali sul calcolo Siti mono utente (mono VO) difficilmente sostenibili Aggregazione di centri piccoli in centri piu’ grandi (anche solo logica) con tanta rete Sotto una certa soglia, un sito non e’ piu’ economicamente sostenibile Dislocazione geografica Fisica e Logica delle macchine sempre meno rilevante Vedi il centro CERN a Wigner (~1500km) (ma vedi anche i problemi di Wigner: avere banda larga non basta, serve latenza bassa e v>c ancora non e’ riuscito a nessuno) Ricerca di linee di finanziamento meno dirette Altrimenti non saremmo qui! Approccio Cloud sembra una necessita’ a lungo termine (e in aggiunta, non in alternativa a GRID) per permettere di ampliare la platea di risorse utilizzabili Ha anche il vantaggio di alleggerire I nostri ricercatori e tecnologi dal mantenimento di uno stack software completo 26

27 Conclusioni Il calcolo italiano e’ cambiato profondamente negli ultimi 15 anni, e nel bene o nel male LHC e’ stato il fattore trainante I problemi che tenevano svegli di notte all’inizio di LHC (stabilita’ delle infrastrutture, nostra capacita’ di gestione dei siti, adeguatezza alle esigenze della presa dati) sono spariti; i nuovi problemi sono soprattutto legati al modello economico e alla sua sostenibilita’ Comprendendo anche la componente umana! ReCaS e’ stato ed e’ un esempio di evoluzione dell’infrastruttura, sia verso nuove forme di finanziamento, sia verso nuove modalita’ di utilizzo E di successo! 27