Report CMS CSN1 – 26 Settembre 2012 Torino 1. Outline Stato generale del computing di CMS Stato dei siti italiani o Tier1 o Tier2s Richieste e piani 2013.

Presentazione sul tema: "Report CMS CSN1 – 26 Settembre 2012 Torino 1. Outline Stato generale del computing di CMS Stato dei siti italiani o Tier1 o Tier2s Richieste e piani 2013."— Transcript della presentazione:

1 Report CMS CSN1 – 26 Settembre 2012 Torino 1

2 Outline Stato generale del computing di CMS Stato dei siti italiani o Tier1 o Tier2s Richieste e piani 2013 2

3 Run2012 Luminosita’ aggiornata al 24/9 3 (1 Hz/nb == 1e33 cm -2 s -1 )

4 Un buon anno … On track per ~ 20-25 1/fb nel 2012 (~70 giorni di pp missing) 4

5 Live time di LHC meglio delle previsioni Numeri aggiornati a fine Agosto 5 Da quando LHC e’ “a regime”, ~20% piu’ dati del previsto A fine Agosto: miliardi di eventi nei PD di fisica (prompt +parked) Previsione 2012: 5.9Msec in pp

6 Data parking attivo come previsto 6 Data parking e’ ADESSO un +75% di dati presi NOTA: da (fine) Settembre si e’ deciso di RADDOPPIARE il rate dei parked fino a ~ 600 Hz; totale da HLT ~ 1 kHz Il data parking sara’ quindi ~200% dei dati presi

7 Condizioni di running-Tier0 Dopo l’anno di “sofferenza” (2011) dovuto al pile up cominciato con <>=5 e finito con <>=20, il 2012 e’ stato un anno molto piu’ tranquillo anche se a PU~25 o Release SW CMSSW_5_2 ha una footprint RAM molto piu’ gestibile ad alto PU rispetto alle release di fine 2011 7 35% meno RAM 120% + veloce Nuovo compilatore (gcc 4.6.2) JEMalloc New ROOT Ottimizzazione dataformats Ottimizzazione pixel seeding (tracking) Ottimizzazione pixel vertexing … Nota: miglioramenti su un sample speciale ad altissimo PU; nella presa dati standard miglioramenti inferiore

8 Produzione MC Capacita’ attuale supera i 500MEvents/mese per GEN-SIM (da generatore a Geant4) e 1BEvents/mese per RECO 8 Fine Agosto: 7B AODSIM

9 Utilizzo risorse – globale T1 LHC 9 Da Marzo 2012 (inizio RUN 2012) sempre almeno al pledge

10 Utilizzo risorse – globale T2 LHC 10 Da Marzo 2012 (inizio RUN 2012) sempre almeno al pledge

11 Attivita’ di analisi 11 Utenti unici in una settimana a parte Natale, oscilla fra 300 e 500 Efficienza in ANALISI dei jobs di CMS ~90% (!)

12 Cosa leggono i jobs di analisi? 12 AOD RECO Transizione analisi a solo AOD in pratica completata; parte rimanente fisiologica (detector studies) (era una milestone 2012) A partire da fine 2011 i RECO (DT/MC) non vengono piu’ distribuiti ai T2 in Central Space; alcuni gruppi li spostano nei loro group space, ma sono soprattutto i DPG/POG che devono fare studi di detector. I PAG utilizzano nella stragrande maggioranza AOD

13 Risorse Italiane 13 Terremoto a Bologna Lavori ENEL a Pisa Problema elettrico campus di Bari Lavori elettrici a Bari Installazione III chiller a Rm1 I “rossi” sono praticamente sempre spiegabili con cause esterne. I siti sono solidi!

14 Risorse italiane: a fine 2012 14 T1 T2 T2: (solita) dolente nota. Risorse previste 1 Apr 2012, ma in caso di gara difficilmente presenti prima dell’autunno in pratica, CPU arrivate da poco, disco non ancora Come da Refs 2011, CSN1 Bari CPU: attive come da tabella Disco: siamo sotto Tape: come da tabella

15 Attivita’ italiana 15 T1 T2 Il totale, che spesso include CPU inutilizzate anche da altre VO, e’ da Marzo costantemente nella zona 7k-9k jobs runnanti allo stesso momento

16 Rispetto al totale CMS – T1 16 Il T1 e’ secondo solo a FNAL Utilizzo del CNAF come visto da CMS a cavallo delle pledge, quasi sempre sopra (effetto dovuto sostanzialmente ad altre VO che hanno utilizzato meno) Avere in Italia il L3 che sovrintende alla produzioneMC (V.Spinoso) da’ un ulteriore aiuto a “tenerci pieni”

17 17 Rispetto al totale CMS – T2 17 Lista di ~50 siti … 11 o 14 o 20 o Facile diventare ~ irrilevanti La FR con un solo anno di finanziamenti non al pledge e’ “scomparsa” sia a livello T2 che T1

18 Network 2 cambiamenti previsti Passaggio dei TierX italiani a LHCONE o LHCOPN: rete dedicata ai trasferimenti T0-T1 o LHCONE: rete dedicata a tutti i centri di calcolo di LHC (T2s per esempio), nata per soddisfare esigenze di trasferimento non contemplate in MONARC (vedi dopo) o Tutti i siti italiani passati senza problemi prima dell’estate GARR-X : tutti I T2 nel 2011 erano collegati alla rete italiana a 1-2 Gbit/s; GARR-X e’ l’upgrade a 10 Gbit/s o Gia’ successo a RM1, CNAF, BA, LNL (e TS, PG, …) o Pisa sta per arrivare (problemi lato GARR/Telecom, non lato sito) 18 Prima settimana di Bari con GARR-X: 7 Gbit/s raggiunti nei trasferimenti

19 Report Attivita’ T1 Analisi CMS al Tier1-CNAF attivata o Anche se non presente nel modello di calcolo originale, sforzo di CMS Italia + supporto e management CNAF o Tutti coloro appartenenti al gruppo=itcms possono usare il T1 per analisi da ~ fine Maggio Utilizzato soprattutto nella fase frenetica pre-ICHEP, ora il T1 e’ talmente pieno per produzioni che lo spazio per l’analisi e’ piccolo In generale, ottimo funzionamento del nostro T1 (grazie CNAF!) 19

20 20 Analisi! Un giorno qualunque della settimana scorsa al Tier1 …

21 Report attivita’T2 8 gruppi supportati o Bari : Higgs, SUSY o LNL : ElectroWeak, Muons o Pisa : Tracking, Tau & Particle Flow o Rome : Higgs, Egamma & ECAL Situazione stabile, difficile avere il 9 o gruppo (servirebbero almeno 125 TB in piu’ secondo le regole CMS-2012) 21

22 Bari Infrastruttura 18 Rack APC in produzione 10 in-row cooler APC 3 UPS da 80kVA in configurazione N+1 2 Chiller da 120kW ciascuno in ridondanza La farm viene usata: o come Tier2 per CMS e ALICE per le attività ufficiali di collaborazione o anche per attività legate ad utenti locali ( Tier3 like ) per diverse comunità scientifiche (Alice, CMS, SuperB, T2K, Glast/Fermi, Gruppo IV, Gruppo V, Chimica, Farmacia, Fisica medica, Pamela, Bioinformatica, Informatica, etc) o da circa 160 utenti locali registrati ( 72 di CMS ) o sia in interattivo che con sottomissioni al batch system locale Passati a LHCONE il 24 Aprile o Tutto ok Passati a GARR-X (10Gbit/s) o Tutto ok Acquisti 2012: o CPU fatto (gara comune) – arrivate -> in fase di installazione 4 twin squared, totale 32 CPU, 32x12 cores, ~ 3200 HS06 o Disco gara comune con LNL e Alice/TO terminata Vinta da DELL, ~ 330 Eur/TBN – stesso sistema del 2011 22

23 Legnaro Integrazione Legnaro-Padova o ottimi risultati dalla collaborazione tra le due sedi, anche in termini di manpower o CPU ora distribuite circa al 50% tra i due siti, mentre storage e servizi critici solo a LNL per minimizzare I downtime o a breve dovremo raddoppiare la banda del link LNL-PD, ora a 10Gb/s, che nei momenti di picco va in saturazione GARR-X e LHCONE attivi Acquisti 2012: o Le cpu della gara CNAF (Olidata) sono arrivate e sono in produzione da fine luglio, i numeri sono quelli che erano previsti nel foglio excel: 20 server, 40x12 cores, 3800 HS06. o Disco gara comune con LNL e Alice/TO terminata in attesa dell’ordine Vinta da DELL, ~ 330 Eur/TBN – stesso sistema del 2011 23

24 Pisa Passaggio tecnologia di storage dCache->Storm ultimato a luglio (senza downtime, senza spostare fisicamente I dati) CMS ha ~ 1300/5000 cores nel CED di Pisa, spazio disco diminuito per dismissione macchine solaris (non ancora conclusa gara 2012) Dopo una primavera in cui I teorici non erano troppo attivi, e riuscivamo a fare 2x del pledge, situazione rientrata nella normalita’ In GROSSE difficolta’ con il pagamento delle manutenzioni (chiller, condizionamento, centro stella….) non finanziate su nessun capitolo – da discutere con referees una soluzione Acquisti 2012: o CPU: nessuna risorsa finanziata (beh, 106 HS06) o Disco: 305 TBN (soprattutto dismissioni) Gara per espansione DDN mandata alla giunta a fine Aprile 3 partecipanti hanno risposto, la gara va avanti (piano piano…) 24 pledge LHCONE = ok GARR-X = non pervenuta

25 Roma1 CMS ha al momento 5 rack Knuerr, di cui 1 soltanto pieno a metà, gli altri in sostanza tutti pieni Ogni rack ha 1 switch con uplink a 10 Gb, oltre a 1 switch low-end per l’IPMI. Il Tier2 globale ha uno switch full 10 Gb, condiviso ATLAS-CMS-Servizi. Al momento CMS non ha necessità di un altro rack, i rimpiazzi saranno in genere più compatti. Acquisti 2012: o Nessuna CPU finanziata (beh, 106 HS06 ;) o Disco sotto i 40kEuro, non necessita di gara ~80 TBN acquistati come da preventivi; con risparmio sostituiti CE e SE o Terzo chiller installato, necessario per riottenere ridondanza. Purtroppo non attivo per mancanza fondi per acquisto ventole. 25 LHCONE = ok GARR-X = ok

26 Richieste 2013 Procedura: o RRB Aprile 2012 : prime richieste degli esperimenti e successivo scrutiny Sono la “base” delle richieste o Settembre 2012 : richieste per l’RRB di Ottobre, motivate in gran parte dal prolungamento del Run 2012(3) di 2 mesi. Mandate allo C-RSG che deve ancora pronunciarsi ufficialmente (lo fara’ a Ottobre) Attenzione pero’: le pledge per il 2013 devono essere inserite nel DB di WLCG entro il 30 Settembre (tutto piuttosto incasinato come tempi e relazioni di causa-effetto…) 26

27 Ma prima …. CMS Italia ha elaborato e mandato ai referees un documento sull’update del modello di analisi in Italia, come aggiornamento al Computing TDR del 2005 Visto che alcune richieste si basano su questo, vorremmo descriverne i punti salienti 27

28 Modifiche sostanziali al modello del ‘05 1.I trasferimenti di dati sono adesso possibili e permessi non piu’ attraverso la gerarchia alla MONARC, ma in pratica flat su tutti i livelli Questo ha richiesto il commissioning di ~50 2 links, effettivamente avvenuto LHCONE serve (anche) a questo! 28 T1 T2 T0 T1 T2 T1 T2 T0 T1 T2

29 Accesso WAN ai dati 2.Il modello iniziale prevede che “I jobs vadano dove I dati sono stati preallocati”, il che implica o Siti con poco storage sono inutili o E’ difficile sfruttare appieno le risorse, visto che richiede un matching di CPU libere e contemporanemante dati interessanti presenti nel sito Evoluzione: in alcuni casi (minoritari) CMS permette l’accesso remoto ai dati. Use cases approvati sono 1.Accesso interattivo in senso lato 2. Accesso in caso di fallback (se un sito ha problemi di storage, I jobs prima di fallire provano un accesso remoto) 3. Accesso in caso di overflow (non ancora implementato), che implica il utilizzo di CPU da siti ‘vicini” se quelle del sito che ospita I dati sono sature 29

30 Gerarchia Xrootd Tutto questo e’ implementato mediante una gerarchia di redirettori Xrootd o Italiano o Europeo (comprende CERN) o Globale (== EU + US) o Il sistema e’ ottimizzato: Un file viene cercato localmente Se non va, si prova sui siti italiani Se non va, si prova su EU, CERN compreso Se non va, si prova US Altrimenti -> ReadError 30

31 Utilizzo T1 3.Da circa un anno, utilizzato anche per produzione MC (da disegno solo per reprocessing) o Risultato: utilizzo al 100% (e oltre se e’ per quello) delle risorse 4.Da 5 mesi, possibile utilizzo per l’analisi (gia’ visto prima). L’idea e’ di utilizzare per questa attivita’ o Momenti senza jobs (praticamente inesistenti) o Il 5% delle risorse che CMS destina a utilizzi particolari (come “t1access”) o Eventuali overpledge e momenti di limitata attivita’ da parte delle altre VO o Per ora, garantire accesso solo agli italiani (in fin dei conti CMS non ci chiede di aprire a tutti) o NON chiedere risorse aggiuntive per utilizzo analisi al T1, usarlo in modo “parassitario” Notare che I casi in cui si DEVE girare al T1 sono pochissimi; accesso ai RAW data per debugging detector e data objects nella maggior parte dei casi 31

32 “Tier3” Il modello ’05 non specifica DOVE effettuare la parte finale delle analisi o DOPO aver girato sui dati, e salvato i dati skimmati/ridotti o In pratica, la fase in cui si girano macro con tagli finali, fit, combinazioni, etc. Per tale fase, e’ necessario girare sui dati skimmati, spesso con alto rate (cambio un taglio e rifaccio …) L’implicito del modello era che a questo livello, i dati skimmati fossero facilmente trattabili (pochi, piccoli, etc), e che fossero utilizzabili da UI o da PC desktop o da risorse locali non meglio specificate o E fuori da MoU con gli enti finanziatori 32

33 Non e’ cosi’ … Il MC di CMS e’ gia’ oggi molto piu’ aderente ai dati del previsto e stiamo effettuando la maggior parte di analisi con MVA, NN, BDT (e non con “cuts”) o Questi tools hanno bisogno di accedere in fase di selezione finale anche a zone di spazio delle fasi con basso S/N  molti piu’ eventi selezionati skimmando I dati Una CPU non basta per avere un turnaround veloce sui dati skimmati o Esempio: analisis H-> bb dati skimmati > 15 TB, sarebbero giorni di processing su singola CPU 33

34 Cosa e’ un “Tier3” Una FUNZIONE e non UN SITO Deve offrire possibilita’: o Interattivo Account locale, spazio HOME, etc o Su alcuni cores (batch, PROOF e simili ok) o Deve poter accedere agli skim su T2 Anche in streaming, non necessita’ di averli in locale o Deve avere spazio disco di lavoro locale (X TB/user) 34

35 Cosa serve per aiutare gli user italiani a fare analisi? 2 cose complementari o Priorita’ ai T2 (italiani) per gli italiani per girare sui dati – ha bisogno di una piccola quantita’ di CPU overpledge Deve essere ai T2 perche’ deve essere vicina ai dati o Macchine interattive “Tier3” per lo step finale o Torniamo ai preventivi … 35

36 C-RSG: ufficiale di 04/2012 36 In poche parole: Increase in T2 CPU Disk stays ~ stable Tape goes down

37 Agg. Richieste 09/2012 37 Questa e’ la colonna della pagina prima Razionale: -CPU T1/Tape T1 = incremento di lunghezza del RUN 2012 fino a Febbraio 2013 (+30% giorni di presa dati – pp fino a fine anno invece di fine ottobre) -E’ in pratica un ANTICIPO sulle richieste 2014, non un aumento netto -Disco T2: +8% per la dismissione di CASTOR al CERN, chiesto come anticipo dal 2014 - (dismissione 5.5 PB, chiesti 2 PB ai T2 tenendo conto del fatto che non tutto il cancellato era indispensabile)

38 Share italiano (pledges) T1 : storicamente 13% delle risorse CMS, per cui 38 T1Pledge 2012Target 2013 Aumento (al netto delle dismissioni) Totals 2012 CNAF fraction Totals 2013 (Sept 2012) CNAF Fraction CPU (kHS06) 18.85 22.75 3.9 1450.131750.13 DISK (TBN) 2860 3380 520 220000.13260000.13 TAPE (TB) 6630 6500 -130 510000.13500000.13 Aumento piccolo di CPU Diminuzione del tape (ma meno di quanto previsto a Aprile) Aumento del disco Aumento piccolo di CPU Diminuzione del tape (ma meno di quanto previsto a Aprile) Aumento del disco

39 2013 - Tier2 2102: Siamo al pledge Questo NON lascia evidentemente risorse CPU overpledge per prioritizzare gli italiani o NON richiesto Disco Overpledge Richiesta T2 2013: o CPU al pledge o + 1.5% di CPU per overpledge o Disco per pledge o + dismissioni as usual delle risorse piu’ vecchie 39 Situazione Fine 2012Dismissioni 2013 Dismissioni 2013 in % kHS06TBNkHS06TBN kHS06TBN Bari 12,88162,6196 2024 Pisa 12,6930072 08 Legnaro 11,310635,1174 4516 Roma1 106382,9150 2924 Totali 46,7344710,6592 2317

40 2013 – CPU T2 Si parte da 46.7kHS06 o 10.6 kHS06 (dismissioni) =16.4 kHS06 da finanziare sul 2013 per arrivare a 52.5kHS06 E cioe’ o BA = 2.6+1.45= 4.05 kHS06 o LNL =5.1+1.45= 6.05 kHS06 o PI =0+1.45= 1.45 kHS06 o RM1=2.9+1.45= 4.35 kHS06 40 1.5% overpledge dismissione

41 2013 – Disco T2 41 Disco T2: +2 PB  270 TB da distribuire nei 4 T2_IT; o 70 TB/T2 aggiuntivi a quanto mancante (poco) per il pledge precedente Sito Situazione Fine 2012TBN Dismissione TBN aumentoAumento TotaleSituazione Fine 2013 Bari 81619683.25279.25 899.25 Pisa 9307283.25155.25 1013.25 Legnaro 106317483.25257.25 1146.25 Roma1 63815083.25233.25 721.25 3447925 3780 targetShare (28000*.135)3780

42 “Tier3” Come gia’ successo per ATLAS (20k 2 anni fa, 20k l’anno scorso), chiediamo lo sblocco di un “gettone” di 30kEuro per attrezzare 2 “Tier3” Con 15k/each: o ~ 50 cores di calcolo (~8k dalle ultime gare) Sufficienti a coprire esigenze di un gruppo medio di CMS Italia o ~ 20-30 TB di disco Sostanzialmente area di lavoro Selezione dei siti: richiederemo o Garanzie sul supporto lato CMS e sull’interesse del gruppo (dal resp locale) o Ok di CCR per garantire supporto lato Sezione o Infrastruttura in grado di ospitare senza necessita’ di espansioni 42

43 RIASSUNTO delle risorse richieste – Sept12 RisorsaTotale dismissioni Totale nuovi acquisti (comprende dismissioni) TAPE T1??-130 TB CPU T1??+3.9 kHS06 DISCO T1??+520 TBN CPU T210.6 kHS06+16.4 kHS06 DISCO T2592 TBN+925 TBN 43 + 30k “Tier3” + overhead as usual (da tabelle referees) +15kEuro/T2 su Consumo per Manutenzioni T2 (gia’ chiesto molto volte e credo abbondantemente giustificato)

44 44 Bari Nei preventivi … numeri messi per 350 Eur/TBN e 14 Eur/HS06 (numeri 2012) LNL Pisa (ora + che dimezzato) Rm1 (+ i 60k di consumi per i 4 T2…)

45 Responsabilita’ 2013 Off/Cmp A fine 2012 il vecchio gruppo offline e’ stato diviso in due o Offline rimane responsabile della scrittura del software (F.Cossutti deputy L1) o Physics Performance & Datasets e’ responsabile della certificazione dei dati, delle calibrazioni, dell’infrastruttura DB, della validazione degli algoritmi (L.Silvestris L1, P.Azzi deputy L1); e’ anche punto di cintatto fra i gruppi di detector performance (DPG) e quelli che preparano I physics objects (POG) Computing ~invariato (D.Bonacorsi deputy L1) 45

46 46

47 47 Computing – struttura molto snellita rispetto a 2011

48 Responsabilita’ 2013 48 (come presenti nella tabella generale, nulla di nuovo…)

49 Milestones 2013 1.Tutti i T2 rendono disponibili i loro dati via Xrootd, per accesso remoto a tutti gli utenti italiani o Manca Rm1 (necessita upgrade dCache, dovrebbe avvenire a breve), e manca una definizione di servizio (ridondanza etc) 2.Presenza di un redirettore NAZIONALE che definisca una “cloud” italiana o Per adesso ci appoggiamo a quello europeo, a Bari 3.Utilizzo dei T1 per analisi, e possibilita’ di ospitarvi AOD di interesse per la comunita’ italiana o Per adesso analisi tecincamente possibile, ma non e’ definita una policy centralizzata per decidere quali samples siano di interesse italiano, ne’ una policy per una corretta gestione 49

50 50 2013 in poche parole Presa dati fino a ~ fine feb 2013 (cosmici compresi) – attivita’ CERN molto maggiore di un anno normale Dopo: o Attivita’ di calibrazione per avere set consistente 7+8 TeV 2010-2013 (PPD per calibrazioni, Off per release, Cmp per produzione samples di validazione) o Reprocessing di DT/MC per Summer conf – di tutto il run 7+8 TeV (Cmp per processing, PPD per sua certificazione) o Processing dei dati parked (PPD, Computing) – per allora saranno in numero maggiore dei dati prompt 2012 o Attivita’ pesante CERN fino almeno a fine estate Ramp-up veloce delle attivita’ di “evoluzione” o Computing: nuovo modello di calcolo, interazioni con IT+ATLAS per common solutions, etc o Offline: attivita’ di transizione a nuovo modello computazionale, multi core, nuove architetture

51 51 J.Incandela, Sept 19 th 2012 Solo reprocessing consistente dei dati almeno 8 mesi di full activity 2013 NON sara’ un anno di riposo per il computing Le risorse richieste sono critiche per CMS

52 Backup 52

53 Utilizzo CPU T0 53 2011: 50% Estate 2011 2012: fino al 90% % = % di utilizzo CPU su macchine 8 cores, Prompt RECO

54 54

55 Attivita’ per tipo in Italia 55 Attivita’ totale (T1+T2) da’ analisi ~20% del totale (senza T1 sarabbe ~ 50% come da disegno) T1 BA LNL PI RM1

56 56 *** Discussion title: CERN Computing Announcements Hi All, In an effort to enhance the ability of users to perform analysis at CERN we are moving away from the tape based user area to disk based storage. Currently when using the /castor/cern.ch/user/... area there is 5.5PB of data on tape accessed through a 300TB disk buffer. This results in data only lasting about a day on this buffer. This is very inefficient for users and for the CERN tape system. Instead of this area you should use a suitable Tier-2 facility. If you are based at CERN you may qualify for access to the CERN Tier-2 facility [*]. With data resident on disk at all times the performance should show marked improvement. It is envisaged that the process will be done in three phases; 1. User migration phase till 18th July Users should migrate their workflows to write to Tier-2 resources instead of CERN CASTOR. Users should also delete unneeded files in CASTOR. They are also free to migrate data they want to keep (and hopefully delete it from CASTOR afterwards). 2. Central migration phase till 31st August The castor user area will be made read-only. We will accept lists of files to be migrated to CAF-T2, made available for copying in bulk or for deletion. These lists should be sent to cms-castor-user-migration@cern.ch. The email should specify in the subject " DELETE|MIGRATE|EXPORT" and a text file (NOT a doc or PDF file) attachment should contain the list of files. Files that are contained in a DELETE email will be deleted. MIGRATE files will be copied to /store/user/ at CERN (provided your are authorised and have enough quota). EXPORT files will be put in a tar file at CERN for you to copy out of CERN. An example command to do this will be on the migration TWiki [**]. 3. End of service phase After the 1st September we will make the area unavailable. Any files not claimed will be deleted later during the year. If you need any assistance please consult the migration TWiki [**] where we will collect more information and a link for help requests. regards, Computing Management May 30 th, 2012

57 Uso T0/Filter Farm nel LS1 T0 Farm: sicuramente si’, gia’ nei piani nelle slide precedenti HLT farm: tecnicamente possibilie (gia’ fatto). In pratica non e’ chiaro quanto aiuti perche’ non ci si aspetta che l’infrastruttura di Cooling/Power distribution sia attiva per molto dopo la fine delle operazioni 57

58 http://cmsdoc.cern.ch/~mccauley/cmsphysics/ 58

59 59 Come # di talk, Italia seconda o terza (la Germania mette la loro SIF in CINCO, per cui sballa i numeri)

60 60 ~1 Miliardo di AOD prodotti al mese ~0.5 Miliardi di GEN-SIM prodotti al mese

61 Utilizzo T2 da parte di italiani Periodo = Aprile – Settembre 2012 Task di analisi eseguiti (ogni task identifica il processing di un dataset, e consiste in un numero di jobs tipicamente fra 100-1000) o Totale: ~10000 tasks, 500 utenti unici o Italiani: ~2000 tasks, 100 utenti unici Nota (ovvia): in un gruppo di analisi tipicamente solo 1 o 2 persone girano jobs sui dati/MC; questo NON e’ il numero di utenti attivi in analisi (definizione di italiani: cognome italiano + certificato INFN o CERN) 61

62 62 Data Parking Motivazioni: o Vari studi di fisica, fra cui SUSY a bassa massa (risonanze di-jet che potremmo perdere per le soglie 2012 troppo alte) Ottimizzazione trigger per Higgs (democratizzazione trigger VBF) Fisica del B(s) Realizzazione: in pratica salvare il ~200% dei dati processabili offline, e tenerne meta’ per il 2013 o “come se il 2013 ci fosse presa dati” Impatto: o Richieste aumentate di pochi percento per CPU, disco, tape o Gia’ assorbite nelle richieste di Aprile 2012

63 Uso disco 63 Esempio di Pisa per lo storage (problemi DGAS per gli altri) 10TB liberi fino a 5 gg fa, aggiunti 100 TB in emergenza in attesa della gara 2012 di disco (che e’ ancora in alto mare…)