ATLAS Stato del Computing Gianpaolo Carlino INFN Napoli CSN1, Roma 30 Giugno 2009 Attività computing 2009 Richieste sblocco sub judice 1 1
Attività di computing nel 2009 (e alcuni risultati prelimianari di STEP09) test Data Management System Reprocessing ai Tier1 Replica del LFC DB Test Analisi Distribuita (Hammer Cloud) Meccanismi di Fair Share Attività nei Tier2
Data Distribution: 10M test Test del DDM nel caso di distribuzioni di grandi numeri di dataset composti di piccoli file. No throughput test Numeri 10,000 datasets (10 M di file) da distribuire in 10 giorni 1000 dataset di 100 files (pochi MB ognuno) per ogni T1 100,000 subscriptions in totale Ogni dataset trasferito dal Tier1 host a tutti gli altri Tier1s Metriche: Ogni sito deve importare 1M files in 10 giorni con efficienza >95% 100,000 files per day Storm al CNAF: > 30 Hz for srm operations
Data Distribution: STEP09 test dell’intero modello di data placement: T0 tape, T0 T1 (disk), T0 T1 (tape), T1 T1 (disk), T1 T2 Nominal load e file size per ogni tipo di dati Run al rate medio di 940 MB/s dal Cern per 24 h/day T1 rate determinati dagli RRB shares CNAF: Throughput medio: 130 MB/s Efficienza trasferimenti T1 T2: 100%
Il Reprocessing al Tier1 Problematica: accesso agli input files RAW data su tape da trasferire su disco in pre-stage Condition Data in DB Cool/Oracle replicati in Oracle stream ai Tier1 + alcune costanti (LAr e InDet) in POOL files referenziati dal DB Oracle replicati con DDM Processo composto di quattro fasi: pre-stage dei RAW file da riprocessare da tape e copia su WN accesso ai Conditions Data sottomissione dei job con il sistema dei pilot 1 job per RAW file e O(1000) RAW file per Run copia separate dei file di output su disco e tape Nel 2008: test di pre-stage e di accesso a Oracle test di Prestage: OK test di scalabilità del DB con O(1000) job concorrenti ha mostrato un degradamento dell’accesso ai dati nel Tier1 e della Oracle stream in tutti i Tier1 Modifica dell’accesso ai Condition Data per ridurre le queries al DB Oracle Condition DB release: SQLite file contenente i dati del DB Oracle per un run Tar file con la DB release e i POOL calibration files distribuiti in tutti i Tier1 e acceduti dai job di reprocessing
Xmas and Spring campaigns Reprocessing ai Tier1 Xmas and Spring campaigns cosmici e 1beam Output (DPD, AOD, ESD, TAG, N-tuples) distribuiti nei T1 eT2 secondo il CM Target: efficienza > 99% Xmas T1 CA CERN DE ES FR IT ND NL UK US Sum Tot jobs 17997 6947 20965 10550 47270 14018 14031 32140 54038 116250 334206 Done 17896 6942 20913 10518 47103 13952 14002 32088 53817 115942 %% 99.5 100.0 99.8 99.7 99.9 99.6 Aborted 101 5 52 32 167 66 29 221 308 1033 0.6 0.1 0.3 0.4 0.5 0.2 Spring Netto miglioramento del rate di errori 0.3% contro 3.5% Il CNAF ha superato entrambe le validazioni. Error rate 0.5% (contro 4.4%) dovuto soprattutto a un task che richiedeva >2GB di memoria
Al CNAF: 29977 jobs finiti (metrica: > 10000 per un T1@5%) Reprocessing in STEP09 J. Shiers – WLCG MB 16/06 Al CNAF: 29977 jobs finiti (metrica: > 10000 per un T1@5%)
Replica Catalogo locale LFC Eliminazione dei Single Point of Failure della cloud: Ogni Tier1 ospita il catalogo LFC che contiene le informazioni sulla locazione dei file nell’intera cloud e non è normalmente replicato altrove. Pericoloso Single Point of Failure Problemi in Italia nela prima parte del 2008 a causa dell’instabilità del CNAF. Si è reso necessario individuare un sistema di failover Sistema di replica a Roma dell’LFC del CNAF (db Oracle) con il sistema Dataguard messo a punto in collaborazione con il CNAF. La replica viene constantemente aggiornata real time e, quando il DB principale al CNAF viene spento, ne assume automaticamente le funzionalita’. Ritorno automatico al DB del CNAF quando questo ritorna in operazione Testato con successo durante il down del CNAF di fine marzo. Il DB di Roma è entrato in funzione immediatamente e non c’è stata nessuna interruzione di attività in Italia Unico Tier1 di Atlas ad essere dotato di replica
Commissioning Analisi Distribuita Hammer Cloud: Stress test iniziati in Italia, prima cloud in Atlas, in novembre AOD based analysis (soprattutto muoni), use-cases definiti da alcuni utenti, 2 italiani. ~ 200 job lanciati contemporaneamente per saturare un Tier2 medio permette di verificare l’efficienza dei tool di DA (wms vs panda) e lo stato dei siti (limitazioni o malconfigurazioni, la loro stabilità e la presenza di problemi temporanei) Risultati ottenuti ottimizzazione delle configurazioni dei siti Rete. Verificata la necessità di avere una connessione a 10Gbps tra WN e Storage Storage. Silanciamento nel carico sui disk server ottimizzazione dell’accesso ai dati accesso diretto ai dati nello storage (protocollo RFIO) Athena File Stager: copia dei file su WN Esempio: Efficienza dei job (%) e Event Rate (Hz)
Rete nei Tier2 Si è verificata la necessità di connessione a > 1 Connessione a 1 Gbps Si è verificata la necessità di connessione a > 1 Gbps tra WN e Storage per i tipici job di analisi: CPU a pieno carico, lettura eventi a ~ 20 Hz 20 Hz * 0.2 MB per evento = 4 MBps per job 200 job slots 800 MBps E’ necessaria una connessione a 10 Gbs e un sistema di storage adeguato Rate con rete a 1 Gbps ~ 3 Hz Connessione a 10 Gbps Sistema di rete usato nei Tier2 in attesa delle soluzioni individuate dal gruppo di rete della CCR 1 Gbps RACK n n+1 10 Gbps m m+1 Fibra Cluster di Rack 1 Cluster di Rack 2
Rete nei Tier2 Switch di rack 3Com Router Sez. Napoli Router Tier2 Roma Router Tier2 Roma Atlas
Meccanismi di Fair Share ATLAS Computing Model: nei Tier2 50% attività di sumulazione e 50% analisi utenti CPU non pledged e parte del 50% riservate agli utenti sono dedicate al gruppo atlas/it Necessario un sistema di fairshare per la definizione delle priorità dei job in modo da “difendere” l’analisi dall’attività centrale di simulazione e garantire risorse dedicate per gli utenti italiani LSF – Multi VO test: Fairshare Targets: ATLAS 50%: User 30% Prod 70% LHCB 50% User 50% Prod 50% PBS – Multigroup test: Fairshare Targets: ATLAS 40% ATLAS PROD 30% ATLAS IT 30% 10 Time Windows 1h long Job lenght: 2 hours
Meccanismi di Fair Share La suddivisione dei job tra i diversi gruppi oscilla in modo da garantire un utilizzo del tempo di CPU (Wall clock time) secondo i target di share definiti Esempio di suddivisione delle slot di calcolo tra diversi ruoli/gruppi VOMS nel Tier2
Accounting nei Tier2 INFN-LNF INFN-MILANO INFN-NAPOLI-ATLAS INFN-ROMA1-ATLAS
Stabilità dei siti Gli utenti hanno bisogno di siti che siano stabilmente up and running Shift 7/7 dei membri dei Tier2 (estesi dopo STEP anche a utenti “volontari”) per controllare il funzionamento dei siti, dei servizi di grid e delle attività di computing di Atlas in Italia
Stima risorse 2009 LHC data taking Cosmics data taking MC simulation Analisi utenti
Stima Risorse 2009 Strategia richieste: Infrastrutture dei siti: server e rete Sostituzione di server cruciali per i Tier2 (CE e SE) in quanto macchine obsolete (2005) o inadeguate (singola alimentazione, RAM insufficiente). Doppio CE per balancing del carico Connessione a 10 Gbps tra WN e storage per le nuove risorse Risorse di calcolo e storage Stima in base alla schedula ufficiale del run 2009 Richiesta di sblocco del s.j. Anche nel caso di ulteriori ritardi di LHC e della conseguente riduzione delle risorse necessarie per il 2010, l’acquisizione delle risorse 2009 permette ai Tier2 di allinearsi al Tier1 (gare da poco avviate) e alla cloud italiana di allinearsi alle altre cloud di ATLAS Modifica del CM in base alla specificità della cloud italiana Spostamento nei Tier2 di alcune funzionalità previste nel Tier1 a causa della limitazione delle risorse al CNAF: replica completa AOD e DPD solo ai Tier2 Richiesta di risorse adeguate da dedicare all’attività dei gruppi italiani oltre i pledges
ATLAS DataWorkflow Il CM di ATLAS, in base all’esperienza del commissioning e la limitazione di risorse disponibili, sta modificando le policy di replica dei dati rispetto al C-TDR L’analisi in Grid degli utenti viene svolta nei Tier-2. Solo analisi di gruppo nei Tier1
Storage nei Tier2 Detector data 110 TB RAW, ESD, AOD, DPD Centrally managed Managed with space tokens Example for a 200 TB T2 Simulated data 40 TB RAW, ESD, AOD, DPD Centrally managed MC CPUs Physics Group data 20 TB DnPD, ntup, hist, .. Group managed GROUP Analysis tools User Scratch data 20 TB User data Transient SCRATCH LOCAL Local Storage Non pledged IT User data Locally managed 19
Stima risorse 2009 - LHC 2 periodi “2009” Oct 09 – Mar 10 “2010” Apr 10 – Mar 11 Data taking Apr 09 – Sep 09: no LHC (sim e cosm) Oct 09 – Mar 10: 1,7· 106 sec (pp) 3,4· 108 ev @ 200 Hz Apr 10 – Oct 10: 4,3· 106 sec (pp) 8,6 · 108 ev @ 200 Hz Ecm = 5 + 5 TeV (only?) RAW = 1.6 MB - AOD = 0.15 MB - ESD = 0.8 MB 20
Stima risorse 2009 - Cosmici Cosmics data taking 2009 ~ 5· 108 ev ~ 1 PB di RAW e ESD/ DPD Il CM prevede che i dati siano replicati solo ai Tier1 e on demand ai Tier2. In base all’esperienza degli ultimi mesi prevediamo che una piccola quota (O(10) TB) di cosmici verrà richiesta nei Tier2 italiani. Non si conservano i cosmici dei run più vecchi.
Stima risorse 2009 - Analisi Analisi nei Tier2 analisi caotica da parte degli utenti produzione di D3PD produzione private MC (statistica limitata prevista da Atlas, necessità di produrre e conservare RDO per ricostruzioni private) calibrazioni dei mu (MDT, LVL1, RPC) analisi di gruppo. large scale skimming di eventi da ESD e AOD con produzione di DPD Prevista soprattutto al Tier1. Aumento dell’utilizzo delle risorse dei Tier2 per la presenza di una replica completa di AOD Risorse dedicate agli utenti italiani CPU: E’ operativo dall’inizi del 2009 il gruppo VOMS atlas/it che identifica gli utenti italiani. In base a meccanismi di fair share è possibile garantire una quantità di risorse almeno uguale alle risorse off-pledged. Disco: Spazio disco dedicato agli utenti italiani (LOCALUSERDISK). Il pool ATLASCRATCHDISK è utilizzato da tutti gli utenti di Atlas ed è un’area scratch
Stima risorse 2009 - Analisi Stato attuale dell’uso dei Tier2 da parte degli utenti netti miglioramenti qualitativi maggiore richiesta delle risorse del Tier2 per attività connesse allo studio dei rivelatori vista la limitazione nell’uso delle risorse al CERN analisi dei RAW data dei cosmici e stream di calibrazione con i tool di analisi distribuita consolidamento dell’uso dei tool da parte dei gruppi di fisica estensione all’analisi di root-ple con Ganga aumento velocità dei job grazie all’ottimizzazione delle configurazioni di rete e dei protocolli di accesso ai dati in seguito agli stress test dell’hammer cloud. ci attendiamo un significativo aumento quantitativo dell’uso dei Tier2 per l’analisi da parte della comunità italiana con la presa dati Circa 20 gruppi italiani di analisi. Principali attività legate allo studio delle performance dei rivolatori e del trigger e alle calibrazioni Fisica: W/Z (2), SUSY (2), Top, Higgs (3), Jets, Esotica, Z’, Bphys Performance, Calibrazione: EM Calo / Photon ID, Pixel, Tau/Etmiss, btag trigger, Jet calib e reco, LVL1 muon, RPC, MDT, combined muons
Stima risorse 2009 - MC Stima basata sulla produzione “MC08”: iniziata nel 2008 e recentemente migrata ora a G4 v9.2 più vari improvement La durata di un anno del run 2009-2010 ha un forte impatto sulla produzione MC, è necessario prevedere sample addizionali per cui il numero totale di eventi da simulare non è più legato al numero di eventi acquisiti: 3 o 4 new Ecm/bunch conifigurations, ognuna di circa 200M eventi variazioni o studi di sistematici in base ai dati raccolti, p.es. tuning o modifiche del modello di hadronic shower, (~150M ev ognuno) La simulazione viene svolta soprattutto nei Tier2: 5 % share simulazione IT, 70% share simulazione ai Tier2. I tempi di simulazione sono cresciuti di un ordine di grandezza rispetto al C-TDR. Necessità di produrre un campione significativo con la fast simulation E’ in corso uno studio di ottimizzazione del tempo vs le performance in Geant4 Total full sim: 1,2 B ev MC08: 340 M New MC: 900 M 300 M nel ’09, 600 M nel ‘10 Total fast sim: 1,2 B ev solo 600 M su disco 200 M nel ‘09, 400 M nel ‘10 Simulation time HS06 Full simulation 8000 Fast simulation 400
Stima risorse 2009 - riepilogo Riassunto risorse necessarie 2009 Attività CPU (HS06) Disco (TBn) LHC data taking 220 Cosmici 20 Simulazione 4800 200 Utenti 6400 160 Totale 11200 600 Risorse disponibili nei Tier2 Tier2 CPU (HS06) Disco (TBn) LNF 688 46 Milano 1832 202 Napoli 2110 209 Roma 1990 195 Tot 6620 652 Richieste CPU Disco HS06 K€ TBn Necessità attività 2009 11200 600 Risorse disponibili 6620 314 Richieste 2009 4580 138 286 229 Costi CPU: 0.03 K€/HS06 Disco: 0.8 K€/TBn Nella determinazione dello spazio disco necessario si è tenuto in conto di quanto è attualmente vuoto.
Riepilogo Richieste Tier2 2009 Suddivisione per sedi 30% per i Tier2 approvati (con piccole variazioni per il disco) 10% per il proto Tier2 Riteniamo necessario il finanziamento di Frascati per il 2009 per permettere al sito di partecipare alle attività di computing in maniera significativa e di evidenziare la sua importanza nella cloud italiana CPU Disco Server Switch Totale HS06 K€ TBn LNF 458 15 29 23 5,5 3,5 47 Milano 1374 41 90 72 11 128 Napoli 10,5 129 Roma 77 61 15,5 121 Tot 4580 138 286 228 425
Conclusioni Le attività di computing in ATLAS e in Italia negli ultimi mesi hanno mostrato che il sistema ha raggiunto una solidità e efficienza in molte sue parti tali da poter affrontare il prossimo data taking data management Reprocessing, al CNAF in particolare Il sistema di analisi distribuita è in continua fase di evoluzione (introduzione della sottomissione con i pilot anche in europa) e deve essere approfondita la scalabilità In Italia. Rispetto alla CSN1 del luglio 08 notevolissimi miglioramenti al CNAF, sia di performance (Storm viene usato in Atlas come riferimento) che di gestione Nei Tier2 sono state ottimizzate le configurazioni di storage e rete per migliorare le performance dell’analisi. Alta efficienza media.
Backup slides
Accounting ATLAS
Accounting ATLAS
Simulazione MC Strategia di simulazione con Geant4 …… Hits prodotti nei Tier2 e trasferiti nei Tier1 Merging degli HITS in file di 2 GB … e ricostruzione MC Prestage HITS dal tape sul disco Digitizzazione ( RDO) Ricostruzione ( ESD, AOD) Archivio RDO, ESD e AOD su tape Distribuzione AOD agli altri Tier1 e ai Tier2 della cloud Simulazione con ATLFAST2 Generazione AOD AOD trasferiti al Tier1 Al Tier1 distribuzione degli AOD agli altri Tier1 Archivio degli AOD su tape
Simulazione MC - Performance Tempo medoi di simulazione nel 2005 (C-TDR) ~ 800 HS06, oggi 8000 HC06 Dipendenza da eta: passaggio da ||<3 (2005) a ||<6 (per simulare correttamente l’attività nel FCAL): fattore ~3 Rappresentazione completa della geomatria di ATLAS (5M di volumi, geometria dominata dalla struttura molto complicata del LAr): fattore ~3 Physics list con il modello di shower adronico di Bertini (miglioramento significativo degli shapes degli shower adronici): fattore ~2 Attività in corso per ridurre i tempi di simulazione in G4: ottimizzazione dei range cuts, time cut per i neutroni lenti, rimozione dei neutrini dalla lista delle particelle da tracciare Miglioramento delle performance della fast simulation
Simulazione MC What’s in MC08 Single particles: e, γ, μ, π0, π±, Λ, η, KS... Fixed E, fixed/varying Et, etc, for calib, tracking, calo, ideal PID, trigger... Studies “SM Physics” samples Min bias, Jets (pt sliced and lower cut), γ-jet – several MCs, different geometries, misc. other options (total 90M) W, Z with multiple models, systematics (total 80M) “PID related” Filtered samples to enhance e/γ backgrounds, filter samples for muon backgrounds Also counted bb/cc inclusive samples here (with & w/o lepton filter) “Other” New physics (exotics, SUSY, Higgs) & special background; ttbar and single-top, dibosons, etc
Risorse totali Tier2 Confronto con i piani di sviluppo di ATLAS (non ancora ufficiali) e i pledge 2009 Lo sblocco del s.j. permette di soddisfare i pledge dell’esperimento e di garantire sufficienti risorse dedicate agli utenti italiani T2 IT T2 ATLAS IT/ATLAS Pledges CPU (HS06) 11200 111000 10.1% 5920 (5%) Disco (TBn) 938 8.4% 700 (5%)