Calcolo ATLAS e CMS C. Bozzi, INFN FE per il gruppo di referaggio: F. Bossi, CB, R. Ferrari, D. Lucchesi, D. Martello, M. Morandin, S. Pirrone, M. Taiuti Roma, 31 marzo 2010
Sommario Richieste 2011 (e 2012) –Complice l’estensione del run al 2011, l’eccezionalità delle richieste per il 2010 si è traslata anche al 2011 –Occorre valutare l’opportunità di questa assunzione Valutazione difficile: non ci sono ancora abbastanza dati! …forse sarà più facile in autunno Utilizzo delle risorse Raccomandazioni dei referee –Fare uscire Bari-CMS dall’incubatore –Autorizzare gli esperimenti a spendere quanto avuto a settembre –(ATLAS ha già speso in parte, quindi si tratta della differenza) –Proponiamo un (limitato) riarrangiamento delle risorse CMS per tenere conto del livello raggiunto nei vari centri
Richieste all’RRB: tempo macchina La luminosità non conta, si assume di acquisire dati sempre al massimo del trigger rate (300Hz CMS, 200Hz ATLAS)
Fabbisogni (2010, 2011, 2012) ATLAS CMS
Utilizzo risorse CERN+T1 (2009)
Utilizzo disco IN2P3 FNAL FZK
CPU al Tier1 CNAF (2009)
CPU ai Tier2 TIER1 PISA LNLLNL BARIBARI ROMA1-ATLAS NAPOLI ROMA1-CMS MILANO TORINO CATANIA LNF CNAF-LHCB (mar09/mar10)
Attività esperimenti: ATLAS 2 campagne di reprocessing dati raccolti in autunno 2009 Contributo poco significativo del CNAF a causa di limitazioni HW (2GB di RAM) Produzione MC a Tier1 e Tier2 in accordo con le risorse italiane di ATLAS Analisi dei dati ai Tier2 non ha saturato le risorse disponibili ma c’era da attenderselo…
Reliability & availability ATLAS
Utilizzo risorse T2 ATLAS MI NA RM1 Proto T2 LNF
ATLAS: commenti T2 Milano: sottoutilizzo dovuto a –test (StoRM+GPFS, POOL) –dismissione di macchine ex-CNAF non più utilizzabili (SLC4 non più supportato da ATLAS) –Riconfigurazione della farm (cambiamento di nome non propagato correttamente nell’accounting) T2 Napoli & Roma1: migliorie infrastrutturali Proto-T2 LNF: –Nuovo responsabile (A. Annovi) –Si sta procedendo con l’ampliamento della sala calcolo Lavori edili: ordine partito Impianti elettrici e tecnologici: partiti incarichi di progettazione
ATLAS: proposte Richieste: 777kE Tre Tier2 Un proto-Tier2 finanziato al 30% Proposte: 679kE CSN1 01/10: autorizzato l’acquisto di disco per Milano, Napoli, Roma1 (~20kE per sito) Proponiamo di autorizzare le gare per gli acquisti rimanenti
CMS: disponibilità delle risorse Milestone
CMS: utilizzo dei centri Negli ultimi mesi c’è correlazione tra i centri e con il calcolo globale di CMS BA LNL PI RM1
CMS: job terminati con successo BariLNL Pisa Roma1
Attività CMS: punti salienti Bari: responsabilità produzione MC, test su sistemi di storage e utilizzo della farm per lavoro interattivo Legnaro: piena integrazione delle risorse LNL-Padova (farm ex-Babar) Pisa: –il centro di calcolo di CMS più utilizzato in Italia (>Tier1!) –Anno cruciale: sostituzione di macchine vecchie e arrivo di ingenti risorse non-INFN (fisici teorici, PRIN) –CMS rischia di diventare socio di minoranza Roma1: buoni progressi nel funzionamento del sito Milestones: alto livello di soddisfazione per tutti i siti –quando l’utilizzo CPU è minore, lo è per tutto CMS –la metrica dei “successful jobs” è migliorabile (basta un singolo utente per falsarla), ma dà comunque informazioni utili
Attività CMS: produzione MC V. Spinoso
Centro di calcolo di Bari Infrastruttura descritta in un documento allegato all’agenda di questa riunione La farm è usata da gruppi locali sia per produzioni MC ma anche per l’analisi finale dei dati dei vari esperimenti (LHC o Astrofisica, Magic, Fisica Teorica) con una forte attività interattiva Ottimizzazione del sistema di storage –testato Lustre+StoRM, poi adottato in produzione Ottimizzazione dell’uso dei WN come macchine per sessioni interattive
Ottimizzazione storage ed efficienza CPU CMS ALICE L’efficienza nell’uso della CPU per i job di CMS è paragonabile a quella di LNL – Anche se l’hw utilizzato è di qualità sicuramente inferiore L’efficienza nell’uso della CPU per Alice è la migliore insieme a quella di Torino che ha la stessa infrastruttura software (Lustre+xrootd)
L’incubatore di TIER2 Alcuni TIER2 sono leggermente piu’ prematuri degli altri e vengono messi in incubatore I motivi di immaturita’ individuati sono: Bari: infrastruttura non completamente definita e costosa non si tratta nè di una approvazione preventiva nè di una bocciatura definitiva queste sedi vengono mantenute su “life support”, con una crescita modesta, ma sufficiente a mantenere l’attività e rispondere alle esigenze dell’esperimento la sede deve diventare o rimanere attiva in GRID e nei SC, DC, possibilmente collaborando con i Tier2 alla soluzione dei problemi comuni Se per questo sono necessarie risorse, vanno finanziate Ci saranno momenti di verifica per valutare se modificare questo schema
Come si esce dall’incubatore ? Per far partire ulteriori Tier2 si devono verificare alcune condizioni: la sede risolve i suoi punti di debolezza i Tier2 finanziati dell’esperimento funzionano con alta efficienza si capisce che il modello di analisi distribuita degli esperimenti LHC funziona si dimostra che la potenza di calcolo addizionale è effettivamente necessaria nei tempi previsti
Bari: la situazione attuale Infrastruttura di base in produzione da maggio 2009 e ormai rodata Farm utilizzata stabilmente da diversi gruppi, locali e non Dimensioni già del tutto comparabili con quelle degli altri T2 di CMS L’esperienza del gruppo di computing di Bari si è dimostrata utile all’intera collaborazione LHC ha funzionato nel periodo finale del 2009 Il modello di calcolo dell’esperimento si è dimostrato capace di sostenere elevati livelli di carico: –~40kjobs/day in italia –~500kjobs/month in italia –>80% di successo dei jobs Il centro di Bari ha contribuito alla pari degli altri T2 già approvati a sostenere gli elevati livelli di carico
Raccomandazioni CMS Giudichiamo in maniera positiva i progressi raggiunti dai vari centri di calcolo di CMS in Italia e riteniamo che le risorse finanziarie globalmente allocate al calcolo di CMS permettono l’acquisto di risorse che soddisfano i piani di calcolo di CMS in Italia nel Ci congratuliamo con i colleghi per i progressi fatti nel Tier2 di Roma1 in termini di affidabilita’ e utilizzo negli ultimi mesi. Auspichiamo che tali risultati trovino conferma nel mantenimento degli standard raggiunti e nell'ulteriore miglioramento nell’utilizzo del centro nel prossimo futuro, ritenendo ciò complementare a quanto raggiunto sino a oggi. Riteniamo che l'acquisto di materiale aggiuntivo sia necessario per consolidare lo stato raggiunto. Invitiamo il gruppo di Roma1 a collaborare per l'integrazione del Tier2 CMS in un unica infrastruttura GRID della Sezione, come già avvenuto negli altri Tier2 CMS, con modalità da discutere e finalizzare in una milestone. Riconosciamo le prestazioni di ottimo livello ottenute in maniera continuativa nel centro di calcolo di Bari. Condividiamo le motivazioni per il riconoscimento a tale centro dello status Tier2 per CMS e, in tale prospettiva, evidenziamo come una maggiore disponibilità di risorse rispetto a quelle finanziate consentirebbe al centro di contribuire appieno al calcolo di CMS sfruttando i risultati conseguiti attraverso i test estensivi dei sistemi di storage effettuati nell’ultimo anno. Raccomandiamo quindi di effettuare le gare nei vari centri per gli importi finanziati in CSN1 a settembre Considerate le situazioni contingenti di Roma e Bari, riteniamo che debba essere operato un migliore bilanciamento fra le risorse destinate ai due centri. Raccomandiamo pertanto di destinare a Bari all’incirca il 25% delle risorse di calcolo che verranno acquistate a Roma1, lasciando a CMS la determinazione dell’ammontare preciso, sulla base di considerazioni di carattere pratico quali ad esempio l’acquisto di sistemi completi, il loro collegamento alla rete locale e cosi’ via.
CMS: proposte Richieste: 1058kEProposte: 637kE Circa il 25% delle risorse di CPU e disco acquistati a Roma1 andrà destinato a Bari CMS Italia propone un riarrangiamento delle risorse leggermente diverso, ma ugualmente accettabile.