Il calcolo a LHC

1. Il calcolo a LHC F. Ferroni, P. Lubrano, A. Marini, G. Salina, M. Sozzi, M. Taiuti A. Martin, M. Morandin CSNI - Assisi 22-9-2004

2. Oggi parliamo di: -Amarcord -La definizione dei soggetti piu’ importanti -Lo stato dell’arte -Le prospettive degli esperimenti -Le complicazioni di politica scientifica -La proposta di finanziamento -Un ringraziamento e un saluto CSNI - Assisi 22-9-2004

3. Le date chiave: 22-02-2000 Cari Colleghi,vi invito a far parte di un gruppo di referee, presieduto da F. Ferroni,con il compito di valutare la proposta GRID, in fase di preparazionesotto la guida di M. Mazzucato.Ferroni, Marini, Taiuti, Salina forniranno il loro parere alleCommissioni Scientifiche 1, 2, 3, 4 e 5 rispettivamente.. ………………..omissis……………………………………Vi ringrazio per la collaborazione e vi saluto cordialmente,Enzo Iarocci La nascita della percezione della Grid

4. Le date chiave: 15-06-2001 Based on the findings and recommendations of the CERN LHC Computing Review the LHC Computing Grid Project was presented by the CERN Management to the CERN Council (15 June 2001).The CERN budget, as presently planned, does not cover the cost in staff or equipment of CERN's share of this project. Therefore, the Members States were asked to consider in particular the resourcing of Phase 1(Prototype) ……omissis………. Il CERN prende coscienza che avere un ruolo centrale implica fantasia, sopratutto finanziaria

5. Le parole magiche LCG Tier 1 al CNAF GRID.it EDG -----> EGEE o Middleware

6. La ineluttabile nascita di LCG I requirement degli esperimenti La mancanza di risorse al CERN La necessita’ di politica scientifica del calcolo distribuito L’affermarsi della EC come soggetto principale nel gioco della e-science

7. I requirement degli esperimenti Raccogliere eventi a rate >= 100 Hz (100Hz*10**7s*1MB/evento ~ 10**15 B da processare un numero imprecisato di volte) Un centro di calcolo al CERN (Tier0) che trasformi i raw-data Una serie di centri di calcolo (Tier1) che sappiano fare storage, calibrazione, reprocessing, produzione MC ed analisi Una serie di centri piu’ piccoli (Tier2) da adibire a compiti di supporto ai Tier1 (i.e. produzione MC) e centrali nell’analisi dati E via scendendo ai Tier3 dove l’analisi dovrebbe regnare sovrana

8. Nulla di troppo nuovo. ma… Lo storage e’ estremamente piu’ massiccio di qualsiasi cosa vista prima Il numero di macroaree geografiche, nazioni, agenzie, istituti, laboratori, fisici e’ certamente unprecented e offre una infrastruttura di risorse distribuite che sarebbe ingenuo pensare di razionalizzare. La GRID nasce per questo ! Gli esperimenti sono quattro e al di la’ di legittime manifestazioni di indipendenza la completa quadruplicazione delle risorse infrastrutturali (hardware, software, personale) sarebbe pressoche’ impossibile da coprire. Senza contare che almeno un tipo di risorsa (umana) e’ assai limitata.

9. E che LCG sia dunque Costruire un Tier0 (4 di fatto) che garantisca il first pass processing Coordinare la gestione una rete di Tier (nazionali o di esperimento) che sfruttando le risorse di GRID permetta un accesso trasparente ai dati (prodotti, calibrati, ricostruiti, riprocessati, analizzati) La chiave magica che doveva aprire tutte le porte della GRID era il middleware sviluppato nell’ambito di un progetto europeo (supportato e affiancato da vari progetti nazionali -i.e. Grid.it) chiamato European Data Grid (EDG) coordinato dal CERN ma non sotto il controllo di LCG. Questa (che si ripetera’ con EGEE) e’ la parte tricky dell’operazione. Voler avere pagato dalla EC lo sviluppo di una tecnologia di calcolo necessaria all HEP ma senza farlo sembrare !

10. E che LCG sia dunque (2) Garantire attraverso un processo di interazione con gli esperimenti lo sviluppo di un software comune di base da mantenersi quindi a cura di un gruppo centrale che minimizza dunque la necessita’ di risorse proprie a ogni esperimento. Esempi diversi ma rilevanti nel bene di questa parte sono l’evoluzione di GEANT4 finalmente ripresa in mano dalla comunita’ degli utenti e lo sviluppo dell’event store (POOL) a seguito dell’abbandono di Objectivity Siglare accordi con le funding agency che permettano lo sviluppo della fase prototipale pur in assenza di gran parte delle risorse centrali (CERN) Usare le risorse EDG (e poi EGEE) ancora in questa direzione Far finta di essere ricchi pur essendo miserabili (peccato per la spiacevole arroganza che accompagna questa peculiare situazione)

11. LCG so far C’e’ evidenza che i progressi in direzione di un Tier 0 ci siano. Una volta quantificate le risorse necessarie allo startup e per i primi 2(?) anni (LCG TDR prossimo anno) questa parte dovrebbe essere in grado di svilupparsi La parte di GRID merita un discorso approfondito. Abbiate pazienza. Lo sviluppo del software per gli esperimenti come detto ha progredito in parti fondamentali (POOL uber alles) ma non e’ esente da critiche di metodo e merito. Questa parte del progetto fa uso di un centinaio di FTE, si proprio cosi’ ! Molti di questi non rispondono al management di LCG (Torre Wenaus, nello specifico); fanno quello per cui sono pagati dalle funding agencies. O te li pigli cosi’ o li rimandi indietro ma non verranno sostituiti. Il management di LCG (rappresentanti degli esperimenti inclusi) e’ colpevole di aver accettato questo modello se non addirittura averlo incoraggiato.

12. LCG so far (2) I progetti software lanciati dal board di LCG che poteva farlo (SC2) una volta iniziati hanno preso vita propria che e’ sfuggita a ogni forma di controllo. Alcuni progetti hanno una utilita’ tra il nullo e il dannoso pur tuttavia le risorse loro allocate di fatto non possono essere meglio usate. Va detto che gli esperimenti (per loro volonta’ direi) salgono sul ponte di comando di LCG per prendere il te’ al piu’. Il comitato sopra citato (SC2) e’ stato nullificato nella riorganizzazione del progetto avvenuta recentemente ma nonostante le raccomandazioni delle review del LHCC e di altre autorevoli fonti e’ stato mantenuto e anzi forse rimpolpato per avere un altro forum dove lasciar sfogare chi vuole disturbare il manovratore

13. LC-GRID Il Middleware Il progetto non ha (volutamente) scritto dei requirement che fossero chiari. Va detto che mancava ancora la consapevolezza di cosa fosse realistico fare e in che tempi e con che manpower. Inoltre il rapporto con EDG e’ stato gestito in modo pessimo. Il risultato e’ che il middleware prodotto da EDG e’ arrivato tardi, e’ risultato una somma incoerente di pezzi (qualcuno dei quali ben fatto), di difficile integrazione e gestione. Uno sforzo enorme da parte di personale LCG (in parte italiano) ha permesso di giungere a una release (LCGII) utilizzabile (di fatto nei primi mesi del 2004). Cocci pero’ ne sono stati lasciati molti …………..

14. LC-GRID (2) Gli americani sono stati de-facto incoraggiati a prendere una strada autonoma che probabilmente avrebbero preso comunque (Grid3) La comunita’ nordica (NorduGrid) non ha avuto alcun motivo per lasciare un sistema ragionevolmente efficiente e passare a uno pesantemente complesso All’inteno del core dei paesi europei soci fondatori di questa impresa non c’e’ stata visione unitaria per guardare avanti e ancora non c’e’ (i.e. IN2P3 a Lyon) Il primo fatto col quale convivere e’ dunque l’esistenza di una molteplicita’ di flavor di GRID da armonizzare in modo che un esperimento possa utilizzare tutte le risorse senza troppa pena

15. LC-GRID (3) EGEE, il nuovo progetto europeo che segue EDG dovrebbe coprire la ingegnerizzazione del middleware (un eufemismo che sta per scrittura di un pacchetto coerente e robusto) e fornire le risorse (specialmente umane) per la gestione delle operazioni di LCG (OpCenter, CallCenter e quant’altro) Il siccessore di LCGII dovrebbe essere gLite. Non abbiamo ancora elementi di valutazione di questo prodotto. Per convergere sulla definizione comunque c’e’ stata una discussione lunga e tempestosa, indice di una gestione che non si confronta colle realta’ diverse di cui e’ composto il progetto.

16. LCG: bianco o nero ? • Difficile da dire: • Non ho una percezione chiara del futuro di questo progetto in tutte le sue parti. • C’e’ comunque un passaggio fondamentale che manca. Il TDR di LCG. • E qui si sta dipanando una vicenda con aspetti preoccupanti. • C’e’ un ordine naturale delle cose: • Gli esperimenti sperimentano un modello di calcolo • Ne descrivono le implicazioni tecnico, scientifico, finanziarie in un Computing-TDR • LCG con gli esperimenti disegna il suo progetto per lo startup e i primi due anni (LCG - TDR) • Si firma un MoU che descrive gli impegni per il computing LHC

17. Modello di computing Computing TDR LCG TDR MoU Computing MoU Computing LCG TDR Modello di computing Computing TDR Dove e’ il problema ? dovrebbe sembra essere

18. CMS Computing schedule • 2004 • Oct RRB for MoUs structures agreement • Dec Computing TDR in initial draft form • 2005 • April RRB Comp MoUs (Exps and LCG) final document [to be signed in June] • July LCG TDR and CMS Computing TDRsubmission • Dec Physics TDRsubmission[Based on “steady state” prod and analysis] • 2006 • ~Spring(Final) Data Challenge 06 • DecComputingSystems Operational

19. Come si deve interpretare ? La volonta’ del CERN di accaparrarsi (nel senso buono diciamo) le risorse mancanti (specialmente di personale) nel piu’ breve tempo possibile L’incoscienza degli esperimenti che sembrano sottovalutare un problema non marginale: non esiste alcuna esperienza di analisi (ne’ concentrata ne’ distribuita) su cui fondare una descrizione di un futuro plausibile

20. E’ un early warning non la descrizione di un fallimento Alcuni risultati ottenuti durante i Data Challenge degli esperimenti non sono trascurabili e indicano che almeno per la parte deterministica del processo (Produzione MC e Ricostruzione) si possono ottenere i risultati voluti Ci sono anche pero’ segni che il personale del CERN (IT) non sia del tutto all’altezza dei compiti. Per esempio il problema dello storage e la sua evoluzione va guardato con grande attenzione. Sembra che le prove di (in)efficienza fin qui fornite nello storage su cassetta stiano spostando le richieste degli esperimenti su un modello tutto-disco

21. LCG LHC Computing Grid Project - LCG Project Status Summary POB - 30 August 2004 Les Robertson – LCG Project Leader CERN – European Organization for Nuclear Research Geneva, Switzerland

22. Key Points (i) Grid Deployment • Very many sites have joined, with more nominal capacity than we expected at this time • Each experiment has full control over the sites that it accepts to use • The accounting system is now in the certification phase • There has been continued progress in inter-operation with other grid infrastructures – Grid3 and NorduGrid • First service challenge starting • The Grid Deployment steering group has been established to oversee • Service challenges • Inter-operability • Operational problem escalation

23. Key Points (ii) Grid Deployment has entered a new phase • Basic middleware is basically working • responsible now for a small fraction of the problems • Many performance issues • some solutions are (slowly) being developed • points to priorities for gLite team • Many operational issues – • mis-configuration, out of date middleware • resources unsuitable for experiments needs (e.g. insufficient disk space) • slow response by sites to problems – exacerbated by the holiday period, security concerns • We are a long way from the grid appearing as a single coherent facility – experiments must adapt to the current state of development

24. Key Points (vi) Resources at CERN for Phase 2 • In the Council paper on cost of completion (March 2002) the funding foreseen in the CERN budget fell short of the estimated costs by CHF 20M • The latest planning round for materials and staff stays within the original cost estimates • But the deficit with respect to the funding committed at CERN is still CHF 20M • The DG proposed in June Council that funding agencies look at the possibilities for continued/new special funding for staff at CERN in Phase 2. So far only Spain has responded to this call. • Because of the extension of Phase 1 from 3 to 4 years (delay of LHCC startup) the staff profile (heavily dependent on special funding) falls off rapidly from early 2005 • Key staff will shortly receive termination notices • Therefore it is essential to decide on how to deal with the funding shortfall in the next months

25. Advice needed • There is some probability that there will be additional funding: • the solution proposed by the DG – for special funding for staff; • moving the cost of tape media to the funding agencies, as was always done for previous experiments; • calling on the CERN contingency – as considered at the time of the cost to completion paper • A shortfall of CHF 10M would have a significant effect on the materials budget – increasing the risk that we are not prepared for LHC data analysis, and requiring additional analysis capacity outside CERN. • The project leader does not believe that the costs can be cut any further without a clear reduction in the scope of the CERN part of the project • But the two solutions proposed to reduce the role of the host lab require outside centres to take on very significant responsibilities. • We need to find a solution within three months that enables us to plan the Phase 2 staffing at CERN Al lupo al lupo, datemi tutti I soldi altrimenti mal ve ne incogliera’

26. Il nostro Tier1 al CNAF • E’ il Centro Regionale piu’ efficace nell’ambito di LCG • La spinta degli esperimenti non LHC ha contribuito ad accelerarne lo sviluppo (fu dunque una decisione saggia)

27. Il nostro Tier1 al CNAF: preoccupazioni • Personale (cosi’ non ce la facciamo) • Meccanismo delle gare (cosi’ rischiamo di buttare soldi e arrivare tardi) • Cambio di management (minimizzare i problemi della transizione)

28. Un numero impressionante • ~ 65 giovani lavorano con contratti di vario tipo per Grid.it in senso esteso • Rispetto a Perugia (Novembre 2002) il personale e’ raddoppiato • Materia di riflessione !

29. CMS Milestones 2004 Partecipazione di almeno tre sedi al DC04 {scadenza Marzo}: OK, 100% 2) Integrazione del sistema di Calcolo CMS Italia in LCG {scadenza Giugno}:slitta di 4 mesi, in progress 60% 3) Partecipazione al C-TDR e preparazione al P-TDR {scadenza Ottobre}: lamilestone C-TDR di CMS e' slittata al Luglio 2005, e quella per il P-TDR aGennaio 2006, in-progress 20% 4)Partecipazione al PCP del DC05 {scadnze Dicembre}: la milestone di CMS e'stata annullata e sotituita con le produzioni ed analisi "continue", 0%.

30. LHCb Milestones 2004 Partecipazione al DC04. La produzione Monte Carlo e' terminata alla fine del mese di Luglio. Dobbiamo procedere all'analisi dei dati simulati. Riteniamo di averesoddisfatto al 100% questa milestone (tra l'altro con un ampio ed efficace utilizzo della Grid italiana).

31. ATLAS Milestones 2004 Ough…. Troppo complicate, mi sono fatto fare fesso ! (vedi talk di Barberis a Pisa in Giugno) Comunque queste vale la pena di guardarle:

32. CMS: well done

33. Le prospettive di CMS Evoluzione da una attività a “Data Challenges” ad una “Permanent Production and Analysis effort” • Questa attivita’ portera’ a: • Definire un CMS Computing Model, “misurato” nella parte dell’analisi • Definire l’uso delle componenti di “Grid” (LCG) • Produrre il Computing TDR di CMS e contribuire a quello di LCG • Definire i contenuti dei Computing MoUs • Produrre il Physics TDR

34. ATLAS DC2 Phase I • Not all problems solved • NorduGrid • RLS; Access to the conditions database; Storage elements died … • Grid3 • Try to avoid single points of failure (adding new servers) • Lack of storage management in some sites • LCG • Still some problems with resource broker and information system • And data management (copy and register) and stage in/out problems • For all • Slowness of the response of the Production Database (Oracle) • Problem that appears after ~6 weeks of running and which is still not fully understood (mix software and hardware problems? being worked with IT-DB). • Has been solved! • Consequences: we did not succeed (yet) to run as many jobs as expected per day • In “good time-slots” the rate of about 2000 jobs running at the same time on LCG was sustained for 5-10 days • Nevertheless should be completed by end-September and is “Grid” only

38. Final prototype: DC3 • We should consider DC3 as the “final” prototype, for both software and computing infrastructure • tentative schedule is Q4-2005 to end Q1-2006 • cosmic run will be later in 2006 • This means that on that timescale (in fact, earlier than that, if we have learned anything from DC1 and DC2) we need: • a complete s/w chain for “simulated” and for “real” data • including aspects missing from DC2: trigger, alignment etc. • a deployed Grid infrastructure capable of dealing with our data • enough resources to run at ~50% of the final data rate for a sizable amount of time (one month) • After DC3 surely we will be forced to sort out problems day-by-day, as the need arises, for real, imperfect data coming from the DAQ: no time for more big developments!

39. LHCb: smart indeed La GRID ha performances di tutto rispetto. LCG ha stabilita’ e robustezza La collaborazione mira al sodo con intelligenza

40. Dynamically Deployed Agents • The Workload Management System: • Put all jobs in its task queue; • Submit immediately in push mode an agent in all CEs which satisfy initial matchmaking job requirements: • This agent do all sort of configuration checks; • Only once these are satisfied pull the real jobs on the WN. • Born as a hack, it has shown several benefit: • It copes with misconfiguration problems minimizing theirs effect. • When the grid is full and there are no free CE, pull jobs to queues which are progressing better. • Jobs are consumed and executed in the order of submission.

41. 424 CPU · Years May: 89%:11% 11% of DC’04 Jun: 80%:20% 25% of DC’04 Jul: 77%:23% 22% of DC’04 Aug: 27%:73% 42% of DC’04 Migration to LCG

42. Production Share • LCG: 4 RB in use: • 2 CERN • 1 RAL • 1 CNAF 20 DIRAC Sites DIRACCNAF 5.56% TO 0.72% Roma 0.05% PD 0.10% 43 LCG Sites NA 0.06% MI 0.53% Legnaro 2.08% FE 0.09% CT 0.03% + CA 0.05% CNAF 4.10% BA 0.01%

43. Production Share (II)

44. DIRAC LCG Daily Job Production 2500 jobs (*) 2500 jobs (*) (*) Job = Brunel Step = DST File

45. E’ vero che ….. Volete triggerare a 4 KHz???? Siete in grado di capirne le conseguenze ?

46. C’e’ qualcosa che non capisco • Dimostrazione che 100Hz passano la ricostruzione (tutti e entro la latency) • Dimostrazione della calibrazione dei rivelatori (quando, dove , come) • Data reduction e data distribution (chi, dove, quando, come) • Relazione tra formati e utilizzo • Accesso massiccio e randomico ai dati I famosi primi 100 giorni che non saranno una luna di miele

47. Parte economica: CMS Nota: Total va a carico di CSN I, LCG va a carico di Grid.it CNAF va a carico di Centro Regionale

48. Parte economica: CMS Non c’e’ nessuna forma di punizione. C’e’ il tentativo non semplice di far corrispondere le risorse al lavoro da fare includendo delle inefficienze ragionevoli e cercando anche di favorire un riequilibrio del modello (quindi chi e’ stato molto favorito nel passato -LNL- puo’ passare un giro anche se ha lavorato splendidamente) Per I Tier3 il modello e’ troppo fuzzy ancora. La fase di analisi (calibrazioni) fara’ chiarezza

49. Parte economica: ATLAS Tier 2 150 Keuro SJ, da discutere quando pronti: "verifica che ATLAS sia ON track per l'inizio del DC3 nel 2005". Tier 3 Genova = 5 KEuro (due bi processori) Lecce = 2.5 Keuro (1 bi processore) Pavia = 5 Keuro (due bi processori) + 3 Keuro (disco) Pisa = 2.5 Keuro (un bi processore) + 3 Keuro (disco) Roma 2 = 5.0 (due bi processori) Roma 3 = 2.5 (un bi processore) + 3 Keuro disco + 1.5 Keuro PC al CERN

50. Parte economica: ATLAS (2) M.E. Milano: = 9 KEuro (due mu, Perini, Cavalli) Roma 1 = 13.5 Keuro (3 mu, Rapp. Naz., DeSalvo) Pavia = 4.5 Keuro (1 mu Rimoldi)) Roma 3 = 4.5 Keuro (1 mu Farilla)