ATLAS: il calcolo Alessandro De Salvo A. De Salvo – 3 maggio 2013

2012 LHC data taking Luminosità Integrata (LHC) ~ 23.3 fb -1 Luminosità Integrata (ATLAS) ~ 21.7 fb -1 Luminosità di picco = 7.73 x cm -2 s -1 Logical data: singola copia dei dati prodotti Physical data: insieme di tutte le copie prodotte e replicate nelle cloud ITALY (CNAF DISK) ALL ATLAS 60e3 50e3 30e3 20e NTUP ESD AOD HITS RAW AOD NTUP HITS RAW ESD 2.5e3 2e3 1.5e3 1e3 0.5e e3 100e3 80e3 60e3 40e3 20e HITS RAW NTUP AOD ESD 80e3 10e3 40e3 70e3 120e3 2

Efficienza trasferimento al primo tentativo ~93% 100% considerando i retries Export dal Tier0 ai Tier1 RAW: 1 copia primaria (disco) + 1 copia custodial (tape) ESD: 1 copia primaria e 1 copia secondaria (su disco in siti diversi) AOD: 2 copie primarie + 1 copia secondaria +copie secondarie ai Tier2 con il sistema dinamico di replica Suddivisione per attività: Data Brokering: replica dinamica dei dati Data Consolidation: pre-placement (T1-T1) Data export 3

Utilizzo del tape in ATLAS (Mar 2012 – Feb 2013) 4

T2D = Tier2 “Directly Connected” Tier2 connessi direttamente tra di loro e a tutti i Tier1 Storage per dati primari come i Tier1 Preplacement di una quota di dati Group data Requirement molto stretti Metriche di trasferimento con tutti i Tier1 Livello di commitment e relibility adeguato Avg(Byterate)+StD(Byterate) SMALL<0.05MB/s<0.1MB/s≥0.1MB/ s MEDIUM<1MB/s<2MB/s≥2MB/s LARGE<10MB/s<15MB/s≥15MB/s T2D approvati: AGLT2 BEIJING-LCG2 BU_ATLAS_Tier2 CA-SCINET-T2 CA- VICTORIA-WESTGRID-T2 CSCS-LCG2 DESY-HH DESY-HH DESY-ZN GOEGRID GRIF GRIF IFIC-LCG2 IN2P3-LAPP IN2P3- LPC IN2P3-LPSC INFN-MILANO-ATLASC INFN-NAPOLI-ATLAS INFN-ROMA1 LRZ-LMU MPPMU MWT2_UC SWT2_CPB TOKYO-LCG2 UAM-LCG2 UKI-LT2-QMUL UKI-NORTHGRID- LANCS-HEP UKI-NORTHGRID-MAN-HEP UKI-SCOTGRID-ECDF UKI-SCOTGRID-GLASGOW UKI-SOUTHGRID-OX-HEP UNI- FREIBURG WT2 WUPPERTALPROD ifae I 3 T2 italiani più grandi (Milano, Napoli, Roma) sono stati dichiarati T2D dall’inizio e sono entrati subito in LHCONE. Frascati sarà incluso quando avrà i requisiti minimi di risorse necessarie. Tier 2 Diretti (T2D) 5

Necessità di individuare i siti più affidabili per l’analisi cui inviare la maggior parte dei dati. Classificazione in base alle performance (stabilità) 4 Gruppi: Alpha: (60% share): T2D con rel > 90% Bravo: (30% share): non T2D con rel> 90% Charlie: (10% share): 80% < rel < 90% Delta: (0% share): rel <80% Classificazione dei Tier 2 Aprile

Ricostruzione (T1), Simulazione e Analisi di gruppo (produzione centralizzata di D3PD in alcuni gruppi di fisica) Job di produzione running nella griglia SUCCESSFUL 89.96% FAILED 9.76% CANCELLED 0.29% 7

Job di analisi running nella griglia Attività di analisi stabile ~ 40k-50k job simultanei negli ultimi mesi con picchi fino a 60k Buona efficienza per i job di analisi continuo aumento dell’affidabilità della griglia attraverso l’esclusione automatica dei siti non performanti SUCCESSFUL 69.9% FAILED 11.65% CANCELLED 18.37% Possibili cause della cancellazione dei job il build job non compila (failed) e gli altri vengono cancellati l'utente ha sbagliato, se ne accorge e cancella i job in coda prima dell'esecuzione rebrokering: i job aspettano troppo in un sito e vengono spostati. Dal punto di vista di PanDA, vengono clonati e i job originali sono cancellati 8

Utilizzo vs pledge Pledge 2012 Pledge

% utilizzo risorse rispetto alle risorse pledged 2012/2013 Utilizzo risorse in Italia: CNAF IT – 8.55% Pledge 2012 Pledge 2013 INFN-T1 normalized CPU time (HS06) Apr 2012 – Apr 2013 ALICE ATLAS CMS LHCb 10

Utilizzo risorse in Italia: Produzione Job Efficiency CNAF Roma Frascati Napoli Milano CNAF 45.70% Napoli 15.77% Roma 15.95% Milano 9.90% Frascati 7.09% IT 6.70% 11

Utilizzo risorse in Italia: Analisi Job Efficiency CNAF Roma Frascati Napoli Milano CNAF 35.10% Napoli 20.83% Roma 19.62% Milano 9.51% Frascati 9.35% IT 6.2% 12

Utilizzo risorse in Italia: Federazione T2 Pledge 2012 Pledge

Il sistema di replica dinamico dei dati PD2P, basato sulla popolarità del dati, già dal 2010 ha ottimizzato l’uso del disco dei Tier2 permettendo la copia di dati interessanti. Circa +90 TB al mese Nessun rischio saturazione, si possono cancellare i dati secondari Utilizzo del disco nei Tier 2 ATLAS Italia Terabytes 500 NTUP AOD ESD DAOD 14

Availability = time_site_is_available/total_time Reliability = time_site_is_available/ (total_time-time_site_is_sched_down) Availability / Reliability

Frascati Roma1 Milano Napoli Utilizzo risorse in Italia: Accounting Tier 2 Mar

Problemi e novità a Frascati  Problemi e novità infrastrutturali sala calcolo  Downtime per l'upgrade del sistema di condizionamento per un mese, dal 18/12/2012 al 17/01/2013  Lavori infrastrutturali per la creazione di una nuova sala calcolo che ospiterà il Tier-2 in fase di completamento  Tale sala sarà dotata anche di un sistema di condizionamento di backup  L'installazione di tale sistema ha creato i problemi tra gennaio e dicembre  I tecnici hanno dovuto a svuotare dall'acqua l'intero sistema che condiziona anche Dafne, il centro di calcolo dei Laboratori e quello di Kloe  Alla riaccensione una serie di detriti hanno otturato le tubature ed una pulizia profonda successiva è stata necessaria  La nuova sala è praticamente ultimata, rimangono poche cose da finire e il collaudo, per cui a breve sarà consegnata  Il nuovo router a 10 Gbps, ordinato a dicembre 2012, è stato consegnato in questi giorni  Il trasferimento nella nuova sala avverrà contestualmente all'installazione del nuovo switch  Il trasferimento richiederà l'ameno una settimana di down-time, ma più probabilmente due, dato che andranno spostati tutti i rack, smontare alcune pareti tra le due sale, ecc…  Difficoltà relativamente al middleware e l'hardware.  A marzo 2013 il CE e diverse macchine hanno avuto guasti tecnici, per cui l'accounting risultante è inferiore alla linea blu  Problemi di rete dovuti alla saturazione del link a 1Gbps (sarà risolto con il nuovo router)  Problema al creamdb del CE, scarso supporto  Installato un secondo CE ma la procedura per aggiungere il nuovo CE nelle code dell'esperimento è stata piuttosto lunga  Problemi all'HLRmon del CNAF  Molti job del sito, in particolare tutti quelli relativi al nuovo CE, non sono stati accountati  Situazione sistemata ieri con gli amministratori del CNAF 17

Problemi a Milano  Blocchi (programmati o meno) del condizionamento  Blocchi (programmati o meno) a maggio 2012, giugno 2012, agosto 2012, aprile 2013  downtime 0.5 – 3 giorni  Worker nodes  8 server twin Asus RS700D-E6-PS8 di E4 con problemi di accesso ai dischi interni (dischi sostituiti da E4)  Storage  Problemi ad un controller (2 volte)  alla richiesta SCSI di un blocco rispondeva col contenuto di un altro blocco, corrompendo il file system  i tentativi di soluzione da parte di E4 sono stati  aggiornamenti vari del firmware  sostituzione dei controller  sostituzione di un'enclosure  sostituzione della testa (enclosure 0)  Sostituzione di altri 3 controller su 2 storage differenti  Risoluzione un problema per cui, quando partiva un rebuild, a volte lo storage perdeva la connessione con gli host  Dopo lo spegnimento e il riavvio per una interruzione di corrente, uno storage ha perso tutte le LUN 18

Risorse Attività ATLAS 2014 Lo Scrutiny Group ha approvato ad aprile 2013 le seguenti risorse per ATLAS 19

Previsione dell’utilizzo delle risorse fino al 2015  Il goal finale per il 2015 è quello di prendere dati a 1kHz di trigger rate  La dimensione degli eventi sarà uguale a quella del 2012 oppure a quella dei sample del MC di upgrade a 13 TeV  Molto lavoro richiesto per raggiungere questo traguardo!  Nei calcoli per il 2015 si assumono 21 settimane di presa dati e 30% di efficienza, con la maggior parte del run a 25 ns e pilep moderato (μ=25) 20

Utilizzo delle risorse per il  2013  Possibile riprocessamento dei dati e MC per studi ulteriori  Produzione di ulteriore nuovo MC per l’analisi  Attività molto intensa di analisi utente e di gruppo  2014  Produzione di sample più grandi di MC per il run ad alta energia  Reprocessing completo finale dei dati e MC del , utilizzando l’evoluzione del modello dei dati preparato per la presa dati del 2015  Attività di preparazione del Run 2 (full dress reharsal)  2015  Processamento e riprocessamento dei nuovi dati ad alta energia  Produzione associata di MC per I nuovi dati  Incremento di attività utente e di gruppo 21

Piano di distribuzione dati per il

Preparazione al run del 2015  ATLAS ha piani ambiziosi per l’upgrade delle attività di Software e Computing  Software: ricostruzione, simulazione, analisi  Ottimizzazione delle performance degli algoritmi, utilizzando in modo più adeguato le CPU moderne  Riduzione dell’utilizzo di memoria  Parallelismo a livello di evento e di algoritmo  Riduzione della dimensione degli eventi  Computing distribuito  Nuovo sistema di Data Management (Rucio)  File based data management, subscriptions and rules,..  Upgrade del Production System (PanDA + JEDI + DEfT)  New TRF, log file merging, …  Merging at T2s, dynamic job definition based on scouts, …  Procedure operative e wrokflow  Ottimizzazione delle analisi di gruppo e utenti finali 23

Multiprocessing e concurrent framework  Le risorse Grid in WLCG sono limitate come agreement a 2GB/core  Il software di ricostruzione di ATLAS fatica a mantenere questo limite  Non è ancora possibile girare la ricostruzione a 64 bit tranne che in nodi speciali dove è disponibile più memoria  Tale situazione certamente peggiora con l’aumento dell’energia e del pileup  Le nuove tecnologie vanno in direzione di CPU many-core, perciò l’approccio corrente non è più sostenibile, nonché l’ultilizzo di eventuali risorse HPC praticamente impossibile  ATLAS prevede di rendere operativo AthenaMP durante LS1 e iniziare lo sviluppo di un nuovo framework concorrente con Full threading e parallelismo a livello di eventi e algoritmi  Collaborazione con IT/OpenLab, PH-SFT, LHCb e CMS  Questo nuovo approccio richiederà anche la migrazione del sistema di Computing distribuito, a partire dalle configurazioni delle code fino alle convenzioni di nomenclatura dei file  Necessaria una chiara strategia per I siti, in fase di sviluppo 24

Group Analysis Workflow - AMSG  Il formato AOD sembra non essere l’ “Analysis Object Data” per la maggior parte delle analisi  La produzione dei formati di dati di gruppo (D3PD/NTUP) è effettuata centralmente  La situazione corrente rallenta l’analisi, crea problemi nella Grid, riempiendo I dischi, e non scala al 2015 con il Run 2  E’ necessario cambiare il modello di analisi e il suo workflow per aumentare il thoughput La full event reconstruction dai dati RAW agli AOD impega 20 s/evento ed occupa 200 kB/evento 25

Utilizzo della farm HLT durante LS1  La farm HLT di ATLAS verrà usata come un “sito” Grid opportunistico durante LS1  ~14k core, corrispondenti ad un grande T2 (se non un T1)  Infrastruttura overlay di tipo Cloud basata su OpenStack  CERN IT (Agile), CMS (HLT Farm) e BNL già utilizzano OpenStack 26

Nuovi protocolli di accesso ai dati  Sperimentazione dei nuovi protocolli di accesso  xrootd e HTTP supportanto lo streaming su WAN  Sperimentazione dei protocolli di accesso remoti e comparazione con I protocolli di storage nativi a disposizione  I protocolli verranno adottati sulla base delle performance, dell’affidabilità e della semplificazione che manifesteranno  Valutazione successiva di un modello per la rottura del modello di località dei dati per i job  Impatto sull’infrastruttura (storage e network)  Migrazione finale all’infrastruttura di Storage Federato  Attualmente basato su sulla tecnologia xrootd (FAX) 27

Uso di risorse opportunistiche  Cloud commerciali a basso costo o gratuite  Utilizzo di VM allocate staticamente in una cloud è stato ampiamente dimostrato in produzione (includendo anche la farm HLT)  ATLAS si concentrerà ad ottimizzare la gestione dinamica delle risorse di calcolo attraverso delle interfacce di provisioning di VM (ad esempio OpenStack)  Il piano consiste nell’integrare la AutoPilot Factory 2 con OpenStack/EC2  Si lavorerà sull’ottimizzazione del workflow per l’utilizzo di risorse opportunistiche  Il nuovo “event server”, ossia il dispatcher di eventi per la parallelizzazione dei task, sarà molto utile in questo ambito  Possibilità di utilizzo di risorse di tipo HPC, ma alcuni problemi  Whole-node scheduling  Assenza di disco nei nodi  Nessuna connessione outbound 28

GPU: GAP Realtime (FIRB) “Realization of an innovative system for complex calculations and pattern recognition in real time by using commercial graphics processors (GPU). Application in High Energy Physics experiments to select rare events and in medical imaging for CT, PET and NMR.”  FIRB partito ad inizio del 2013  Per ciò che riguarda la comunità HEP, verrà studiato l’utilizzo di trigger hardware di basso livello con latenza ridotta e trigger software di alto livello  Si studieranno I casi di NA62 L0 e l’High Level Muon Trigger di ATLAS come “casi fisici”  Roma coinvolta nello studio del trigger di ATLAS 29

ATLAS: as study case for GPU sw trigger ATLASThe ATLAS trigger system has to cope with the very demanding conditions of the LHC experiments in terms of rate, latency, and event size. LHC luminosityThe increase in LHC luminosity and in the number of overlapping events poses new challenges to the trigger system, and new solutions have to be developed for the fore coming upgrades ( ) GPUs high level triggerGPUs are an appealing solution to be explored for such experiments, especially for the high level trigger where the time budget is not marginal and one can profit from the highly parallel GPU architecture ATLAS GPUsmuon identification and reconstructionWe intend to study the performance of some of the ATLAS high level trigger algorithms as implements on GPUs, in particular those concerning muon identification and reconstruction. Slide from G. Lamanna / A. Messina 30

Altre evoluzioni  Completa migrazione ed utilizzo dell’ATLAS Grid Information System in produzione  Definitivo abbandono dei servizi di IS di Grid in favore di AGIS  Abbandono anche del WMS, finora utilizzato ancora solo per le installazioni del software  Installation System migrato completamente ad AGIS + Panda  Sorgente primaria di informazioni per Panda e DDM  Migrazione ad SL6  Inizio ufficiale delle migrazioni ad SL6 a giugno 2013  Alcune delle release necessitano di una patch per funzionare con l’analisi a causa delle opzioni diverse di compilazione  Possibile soluzione generica trovata di recente, in fase di test  In ogni caso le release più utilizzate sono state già sistemate o comunque funzionanti nativamente  Migrazione ad IPv6  Test dei servizi con IPv6 necessario  SHA-2  Migrazione imminente, necessario un controllo dei servizi  Finalizzazione dell’integrazione di gLexec in Panda 31

Partecipazione italiana alle attività di upgrade  ATLAS Italia partecipa alle attività di ADC in diversi aspetti  Database  Installazione del software (CVMFS e distribuzione)  Monitoring  Network infrastructure (LHCONE)  Storage  Federazioni di xrootd e HTTPD  DPM  VO management  Altre attività (PRIN)  Cloud Computing  Hadoop (EventIndex)  Network Infrastructure (LHCONE)  Proof on Demand  La partecipazione alle rimanenti attività è largamente limitata dalla disponibilità di persone  Attività sulle GPU, inserite in un FIRB  Interesse della comunità per GPU e multiprocessing/ottimizzazione del codice, ma NON c’è manpower 32

Risorse Disponibili CPU CPUFrascatiMilanoNapoliRomaTotale HP To be pledged Le CPU totali a disposizione dei Tier2 comprendono anche risorse che non pledged: CPU per uso locale (cluster proof) o in griglia ma dedicate principalmente alle attività italiane (Tier3) finanziate con fondi vari –Proof on Demand, share per analisi e simulazione MC per il ruolo atlas/it le CPU obsolete (fino al 2013 e già rifinanziate) ancora in produzione ma in corso di spegnimento CPU non a completa disposizione dei siti –(es. scope a NA, SuperB a LNF) Queste CPU concorrono alla definizione della linea blu dell’accounting che in alcuni casi è significativamente maggiore della linea rossa Nel conto delle CPU pledged sono comprese le CPU gara CNAF 2013 ancora da installare CPU disponibili 2013 “pledged” 33

Risorse Disponibili 2013 – Disco DiscoFrascatiMilanoNapoliRomaTotale Totale disponibile to be pledged 3565 Lo storage totale disponibile nei Tier2 comprende anche l’area locale in cui sono conservati i dati di tutti gli utenti italiani (LOCALGROUP), non solo gli utenti locali La dimensione di queste aree è di circa 100 TB per Tier2 In gran parte già occupata, gli utenti dovranno cancellare i dati vecchi non più necessari per fare spazio ai dati del 2013 l’utilizzo di queste aree è irrinunciabile per cui il loro volume va sottratto allo storage da dichiarare pledged Storage disponibile 2013 “pledged” 34

Risorse Obsolete nel 2014 Le CPU obsolete sono le macchine comprate nel 2010 e installate fine 2010 inizi 2011 (non sono comprese le macchine installate successivamente). Le CPU hanno garanzia triennale Lo storage obsoleto comprende le SAN comprate nel 2008 e installate giugno Garanzia quinquennale Le dismissioni di Napoli sono finanziate da RECAS La sostituzione del materiale obsoleto, secie per i dischi, è fondamentale per il buon funzionamento dei centri e quindi dell’intero sistema di computing italiano di ATLAS CPU (HS06) Disco (TBn) Frascati11870 Milano Napoli Roma Tot Tot – NA Risorse obsolete

Risorse Obsolete nel 2015 Le CPU obsolete sono le macchine comprate nel 2011 e installate fine 2011 inizi 2012 (non sono comprese le macchine installate successivamente). Le CPU hanno garanzia triennale Lo storage obsoleto comprende le SAN comprate nel 2009 e installate nel Garanzia quinquennale CPU (HS06) Disco (TBn) Frascati Milano Napoli Roma Tot Tot – NA Risorse obsolete

Richiesta Risorse I Le risorse necessarie per il 2014 sono determinate dalla volontà di conservare il ruolo significativo nel computing di ATLAS acquisito negli ultimi anni conservando gli share di risorse pledged per le attività centrali: Tier1: 10% Tier2: 9% CPU e 7% Disco e di garantire la competitività agli utenti italiani mediante l’uso di risorse dedicate nei Tier2 e Tier3 ATLAS Share IT ATLAS IT 2014 ATLAS IT disponibile Attività 2014 CPU T1 (kHS06) % * 3.6 Disco T1 (PB) 3310% * 0 CPU T2 (kHS06) 3909% Disco T2 (PB) 497% * Pledge

Richiesta Risorse II Le risorse per le attività italiane sono già disponibili e non inclusi nel disponibile “pledged” 2013 e non sono necessarie ulteriori richieste Attività 2013 Attività Italiane Obs Richieste 2014 K€ CPU T2 (kHS06) Disco T2 (TB) Prezzi stimati: CPU = 10 k€/kHS Disco = 350 k€/PB Attività 2013 Attività Italiane Obs Richieste 2014 K€ CPU T2 (kHS06) Disco T2 (TB) Recas - Napoli Totale 38

Richiesta Risorse III Overhead per rete e server aggiuntivi Algoritmo Bozzi (cfr. presentazione CSN1 Bari Settembre 2011): Rete: 6% (cpu) + 5% (disco) = 11.5 k€ Server: 7% (cpu + disco) = 14.6 k€ A cosa servono: Rete: switch di rack Server: servizi di grid A cosa corrispondo questi finanziamenti: Rete: 2.9 k€ per Tier2, uno switch SENZA modulo 10 Gbps! Per collegare le nuove risorse e/o sostituire i primi switch ormai fuori manutenzione Server: 3.65 k€ per Tier2, un server per sezione 39

Conclusioni  Il Computing di ATLAS ha dimostrato di essere robusto ed affidabile per il processamento dei dati, sia MC che analisi finale, tuttavia sono stai individuati dei punti dove è necessario migliorare  Durante il LS1 il Computing Model di ATLAS subirà un sostanziale cambiamento, apportando modifiche sia al codice di ricostruzione/analisi sia ai servizi infrastrutturali  Le richieste per il 2014 e 2015 sono diminuite in conseguenza delle nuove risorse provenienti dal progetto RECAS nelle sedi di BA, NA, CS e CT  E’comunque fondamentale fornire supporto ai Tier2 esistenti per quel che riguarda le dismissioni 40

Backup slides 41

Trigger rate 2015 Luminosity expected to increase from 7×10 33 to 2×10 34 corresponding to about a factor 3 in rates Pile up will increase affecting the effective trigger rates Moving to √s=14 TeV cross sections will increase on average by a factor 2.5 Rates would increase by about one order of magnitude. To keep the increase within a factor ~2 (50kHz→100kHz L1 and 450Hz→1kHz EF) selections have to be improved/tightened minimizing the impact on physics. PS: The physics (Higgs, top...) remains the same. 42 Slide from C. Gatti / D. Orestano

Trigger menu 2012 vs 2015 Current menu scaled to Slide from C. Gatti / D. Orestano

Trigger menu 2012 vs 2015 Menu at 2×10 34 and 14 TeV 44 Slide from C. Gatti / D. Orestano Increase single e/gamma threshold Increase single and di muon thresholds Increase single and di tau thresholds Increase Jet and MET thresholds