Massimo Masera Torino CALCOLO

Sommario 13/5/2011 Calcolo - ALICE Uso del Tier-1 e dei Tier-2 italiani Enfasi sulle attività di analisi Previsioni relative per il 2012 (e 2013) Trieste 2

Dati /5/2011 Calcolo - ALICE 3 Tipo di collisioneNumero eventiVolume RAW data p-p7.0× TB Pb-Pb7.0× TB Numero di dati che superano i criteri di trigger Uso delle risorse per tipo di attività: ➫ Ricostruzione: 10 % ➫ MC e Analysis Trains: 75% ➫ Analisi caotica: 15% I dati RAW sono replicati nei Tier-1

Uso delle risorse: analisi 13/5/2011 Calcolo - ALICE 4 L’analisi è fatta interamente su GRID fino agli istogrammi finali Su Analysis Facilities basate su PROOF (CAF – CERN -, SKAF – Kosice, LAF – Lione, TAF – Torino) La TAF è in fase di test e integrazione con il Tier-2: usata da qualche alpha-tester locale In Italia è prevalentemente su GRID Nel grafico: job utente (quindi analisi caotica). Poco meno di 400 utenti Tutte le risorse liberate per la sola analisi caotica in vista di QM

Reminder: analisi 13/5/2011 Calcolo - ALICE 5 L’analisi su GRID è divisa in attività scheduled e caotiche Le attività scheduled sono condotte lanciando dei job detti “analysis trains” Treni perché ogni job gestisce diverse “analysis tasks” indipendenti in modo da accedere i dati un numero minore di volte Tutte le analysis tasks ereditano da una interfaccia astratta comune Possono operare su ESD e AOD Le attività utente differiscono per il fatto che si tratta in genere di analysis tasks singole Spesso i job sono lanciati da una sessione interattiva di ROOT che attraverso un AliEn-plugin crea un masterjob che a sua volta gestisce un numero variabile (O 100) di subjobs I subjob girano di preferenza dove ci sono i dati di input Al termine i risultati sono sommati (merged) in un unico output  questa operazione comporta sempre l’accesso remoto agli output dei subjobs

GRID: tempi di attesa 13/5/2011 Calcolo - ALICE 6 ROSSO – Tempo di attesa nella task queue (average 38 min) BLU – job duration (average 115 min)

Uso delle risorse in Italia/1 13/5/2011 Calcolo - ALICE 7 Profilo essenzialmente costante di job nei T2. Ultima entry in Italia: Trieste (farm di sezione)

Uso delle risorse in Italia/2 13/5/2011 Calcolo - ALICE 8 In questo periodo è stata attivata una cosa speciale a 4GB di RAM che qui non è monitorata in MonaLisa. La coda è stata necessaria per il reprocessing di PbPb. Prevalentemente attività di analisi per QM

Wall time CPU 13/5/2011 Calcolo - ALICE 9

Efficienza di CPU 13/5/2011 Calcolo - ALICE 10 Efficienze di riferimento: 60% per l’analisi utente e 85% per il resto Da marzo efficienza sistematicamente bassa. Il problema è stato discusso da S.Bagnasco nella riunione del T1 questa mattina Causa principale: problema nel codice a basso livello nell’accesso dati. Dovrebbe essere risolto con la prossima tag di ROOT Nessun intervento prima di Quark Matter Efficienze di riferimento: 60% per l’analisi utente e 85% per il resto Da marzo efficienza sistematicamente bassa. Il problema è stato discusso da S.Bagnasco nella riunione del T1 questa mattina Causa principale: problema nel codice a basso livello nell’accesso dati. Dovrebbe essere risolto con la prossima tag di ROOT Nessun intervento prima di Quark Matter CPU efficiency

Uso delle risorse: Storage 13/5/2011 Calcolo - ALICE 11 L’occupazione dei dischi in Italia è in linea con quella della collaborazione Dati RAW solo ai Tier-1. Al CNAF sono stati trasferiti finora solo dati PbPB Per il resto MC output, ESD, AOD, end user files Tipo di distribuzione: ESD e AOD replicati con fattore di replica 3-4. Ranking degli SE usato per la scelta. Gli utenti NON hanno nessun controllo sulla localizzazione dei dati SedeTB disponibili TB usati% usato Bari LNL Torino236 (*)15767 CNAF (T0D1) CNAF (T1D0) (*) 71 TBn non sono ancora in linea. L’occupazione attuale è del 93%.

Accesso allo storage 13/5/2011 Calcolo - ALICE 12 AOD, ESD analysis

Che cosa abbiamo imparato 13/5/2011 Calcolo - ALICE 13 Il sistema di calcolo distribuito su GRID è stato in grado di supportare la prima “offensiva” massiccia di User Analysis L’analisi per Quark Matter è stata fatta interamente su GRID e sulle Analysis Facilities L’analisi caotica è stata fatta in parallelo con le attività scheduled Il sistema di prioritizzazione e di quote ha mostrato di funzionare bene L’incremento di user analysis nel corso dell’ultimo anno è aumentata di un fattore 5 senza problemi importanti La velocità di risposta delle risorse è stata soddisfacente anche in regime di saturazione Problema: Efficienza di CPU Prima priorità dopo Quark Matter

Evoluzione del computing model 13/5/2011 Calcolo - ALICE 14 Schema di ricostruzione cambiato: nuovi passi intermedi legati essenzialmente alla calibrazione offline di alcuni rivelatori del barrel: TPC, TOF e in parte SDD Data Taking Online Calibration Complete Pass1 Data Taking Online Calibration Pass0 Reco+Calib Complete Pass1 Data Taking Online Calibration Pass0 Reco+Calib Partial Pass1 Monitoring + QA trains Complete Pass1 Ripetuto Computing Model Computing Model modificato Strategia attuale

… e altre novità 13/5/2011 Calcolo - ALICE 15 Per assicurare che la ricostruzione dei dati utile per la fisica (“physics reconstruction”) sono attvati degli speciali analysis trains dedicati alla Quality assurance (nella prossima slide l’esempio di task per il solo tracciatore interno). Riunioni di QA con cadenza settimanale Aumento della potenza di CPU richiesta dovuto a: Nuovo algoritmo per trovare V0 (V0 finder) per PbPb Per il MC: nuovo digitizer per la TPC con maggiori dettagli Nuovi detector dal 2011 (EMCAL + altri moduli TRD) Trigger mix (alta centralità in PbPb 2011 e alta molteplicità in pp) Calibrazione offline

Esempio: QA tasks per l’ITS 16 SPD QA Task SSD QA Task ITS-SA Tracking QA Task ITS-GLOBAL Tracking QA Task ITS Vertexing QA Task ITS Alignment QA Task SDD QA Task Monitoring of performance at the sub- system level. Heavily (bu not completely) based on local reconstruction SPD + TRACKS vertices (mean vertex  calibration task) Essentially based on track to point residuals In a reconstruction schema based on a tight schedule, the output of the QA tasks need to be checked and the corresponding runs can be either validated or not. In the second case alignment and/or offline calibration may be needed ITS offline

Aggiornamento dei parametri per valutare le necessità di risorse 13/5/2011 Calcolo - ALICE 17 I cambiamenti nel C.M. si riverberano sui paqrametri utilizzati per valutare le necessità di calcolo Il guadagno in termini di spazio per l’ESD (PbPb) si paga con un maggior tempo di ricostruzione pp/eventPbPb/event CPU reco (KHEP06×s)0.07 (+10%)9.75 (+71%) CPU MC (KHEP06×s)1.30 (+40%) (+4%) Raw size (MB)1.3 (+18%)12.5 (0%) ESD size (MB)0.08 (+37%)1.20 (-65%) MC Raw size (MB)0.4 (0%)61.5 (0%) MC ESD size (MB)0.26 (0%)50 (0%)

Previsioni di run 13/5/2011 Calcolo - ALICE 18 pp data taking from March 2011(2012) to October 2011(2012) (135 days, with a 50% LHC availability and a 46% LHC efficiency, 2.7×10 6 effective seconds; 1.0×10 9 events, 5×10 8 MB events + 0.5×10 8 rare events) AA data taking from November 2011(2012) to December 2011(2012) (19 days, with a 50% LHC availability and a 46% LHC efficiency, 3.7×10 5 effective seconds; 7.4×10 7 events) LHC shutdown in 2013

Risorse: Tier-1 13/5/2011 Calcolo - ALICE 19 Prossimi grafici: legenda In arancione (stime 2010): stime utilizzate l’anno scorso con estrapolazione fino al I dati corrispondono alla prima revisione dello scrutiny group dopo il RRB dell’aprile 2010 In blu (stime 2011): valutazioni di ALICE presentate al RRB. Fair share italiano 19%. per lo storage e successivamente per il tape ci sono variazioni che saranno evidenziate Le valutazioni 2011 differiscono dalle stime apr Sono state presentate al RRB di ottobre 2010 In verde In verde: piano di acquisizione risorse del Tier-1 (fonte: presentazione di L.Dell’Agnello al Comitato di gestione del T1 del 19/04/2011)

Risorse: Tier-1 13/5/2011 Calcolo - ALICE 20 kHS06 PB Per il 2013, abbiamo mantenuto la richiesta di disco invariata rispetto al Nelle valutazioni presentate al RRB c’era una flessione del 19% rispetto al 2012, che riteniamo non praticabile e non opportuna Rispetto al piano CNAF: ➫ modesto incremento della CPU al 2012 (+10%) ➫ decremento del disco (-20%)

Tier-2 Situazione esistente 13/5/2011 Calcolo - ALICE 21 Dotazione a inizio anno nei Tier-2 – non sono conteggiate le risorse di Cagliari, che erano 1760 HS06 e 30 TB Caveat: a Bari e Torino sono state dismesse risorse a 32 bit per un totale di circa 1300 HS06 Dotazione a oggi Incrementi di CPU a Torino e di disco a Bari, LNL e Torino realizzati con fondi 2010 sbloccati a settembre. 71 TBn a Torino sono montati e saranno disponibili nei prossimi giorni

Tier2: Risorse acquisibili con fondi già assegnati 13/5/2011 Calcolo - ALICE22 Dotazione a fine giugno con CPU nuove a LNL e Bari (gara CNAF conclusa) Sono stati acquistati 6008 HS06 e 218 TBn. La previsione a settembre era di acquisire 3400 HS06 e 175 TB. La differenza è principalmente nella CPU: la gare CNAF ha avuto un forte ribasso (- 40%) sulla base d’asta Acquisizioni con fondi Le stime economiche sono le basi d’asta. Fine anno?

Risorse: Tier2 13/5/2011 Calcolo - ALICE 23 in verde Legenda: I punti in verde rappresentano: ➫ Punto 2010: la disponibilità nei 4 T2 a gennaio 2011 ➫ Punto 2011: la disponibilità a fine giugno 2011 (consegna CPU a LNL e Bari) ➫ Punto 2012: La presunta disponibilità al termine delle 2 gare su fondi 2011 per storage e CPU kHS06 PB

Risorse 2012: che cosa manca? 13/5/2011 Calcolo - ALICE 24 La presente valutazione è naturalmente preliminare. Per arrivare ai valori di target 2012, mancano: RisorsaFine 2011Target 2012DCosto (a base d’asta 2011) CPU20461 HS k€ DISCO1125 TB k€ Totale490 k€ Overhead (*)60 k€ Gran Totale550 k€ (*) 6% su CPU, 5% su DISCO e 7% su TOTALE

Trieste Oltre a Trieste abbiamo centri attivi a Bologna e Cagliari. Al momento non c’è stato in ALICE Italia un dbattito approfondito sui “Tier-3”. Qui presento la situazione di Trieste, ma un quadro completo sarà mostrato alla prossima riunione di CSNIII 13/5/2011 Calcolo - ALICE 25

Sito di Trieste Farm di Sezione esistente dal 2003 per riunire le necessità di calcolo di tutti i gruppi / esperimenti presenti a Trieste Finanziata da Sezione, Commissione Calcolo,INFN-GRID, Dotazione Gruppi ed alcuni esperimenti Pianificazione architettura, installazioni, configurazioni, manutenzioni e aggiornamenti a carico del Gruppo di Calcolo della Sezione Situazione attuale: 190 TB di disco condiviso (GPFS), 106 CPU (382 core) per un totale di 3300 HEP-SPEC2006 Grid INFN-TS (LCG-CE + SRM) attivo dal 2002 e integrato nella farm dal 2008, condivisione con assegnazione dinamica degli slot di calcolo tra job locali e job di grid, presenti numerose VO: cms, glast, theophys, lhcb, atlas … Contributo di GrIII tramite PRIN + dotazioni (512 HEP-SPEC TB)

Alice-Grid a Trieste Interesse da parte di Alice Trieste a sviluppare un centro per l’analisi parallela e interattiva mediante sistemi basati su cluster di elaboratori virtuali (PRIN 2009 TO- TS-CA) Integrazione della farm di Trieste con Alice-Grid : Installazione di 3 macchine dedicate alla gestione del calcolo e dello storage di Alice-Grid (VOBox, Server Xrootd, Redirector) Installazione di CREAM CE (utilizzato anche da altre VO) Installazione di un primo blocco di storage 5 TB integrato localmente in GPFS e reso disponibile come SE per Alice-Grid Test SE + VOBox Studio di fattibilità di un centro per le analisi utente a Trieste: Attivazione del sito per batch job Studio di virtualizzazione e integrazione PROOF/LSF Attivazione per gli utenti locali del centro per le analisi: Necessità di aumentare lo spazio su disco di 15 TB per la fase finale di analisi (AOD e ntuple di 5 utenti locali impegnati nelle analisi di Alice) Possibilità di aprire il centro a tutta la collaborazione