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
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
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
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
Le parole magiche
LCG
Tier 1 al CNAF
GRID.it
EDG -----> EGEE o Middleware
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
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
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.
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 !
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)
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.
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
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 …………..
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
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.
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
Dove e’ il problema ?
dovrebbe
•
•
•
•
Modello di computing
Computing TDR
LCG TDR
MoU Computing
sembra essere
•
•
•
•
MoU Computing
LCG TDR
Modello di computing
Computing TDR
• 2004
CMS Computing schedule
– 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 TDR submission
– Dec
Physics TDR submission
[Based on “steady state” prod and analysis]
• 2006
– ~Spring
– Dec
(Final) Data Challenge 06
Computing Systems Operational
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
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
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
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 interoperation 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
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
•
Many operational issues –
•
We are a long way from the grid appearing as
a single coherent facility – experiments must
adapt to the current state of development
– some solutions are (slowly) being developed
– points to priorities for gLite team
– 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
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
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
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)
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)
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 !
CMS Milestones 2004
1) 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%.
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).
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:
2- entro ottobre 2004 co mpletato DC2 sim ulazione , ricostruzione ed even tuale
repro cessing

n
n
n
Partecipazione di Tier1 ,2 (CNAF, Mil ano, Napoli , Roma1) a fasi
sim ulazion e, pile up e ric ostruzione e seguendo il 10% di ATLAS globale
in Itali a.
l
La fase di sim ulazione è comp le tata al 80% e i siti ATLASItali a hanno contribui to per il 15% all a CPU fornit a via
LCG (17% tenendo conto di tutti i siti it ali ani) che
rappresenta cir ca il 50% d i quella usata da ATLAS per il
DC2 (dati del 7-9). All’ origine la fr azione d i LCG era s tata
prevista come 60% del totale dell a CPU d i ATLAS.
Da aprile i siti Tier2 sono tutti LCG-capable, cioe' in tutti il s/w e'
install ato e testato in mi ni-produz ione italiana. ( Mil ano inserito in LCG da
prima del 2004).
l
OK
Ana lis i in Tier3 in collaborazione con Tier1,2: report per fi ne 2004
l
Ana lis i non inizierà prim a di nov emb re. Ritardo d i un paio
di mesi.
Contributo INFN a TDR computing
l
INFN ha dato contributi decisivi al s ist ema di produzi one
basato su LCG e al suo uso ne l DC2 e altr ettanto farà per il
sist ema di ana li si e per l’anali si. Il contributo al TDR sarà
di conseguen za ril evan te.
CMS: well done
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
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
40
62
3
40
62
6
40
62
9
40
70
2
40
70
5
40
70
8
40
71
1
40
71
4
40
71
7
40
72
0
40
72
3
40
72
6
40
72
9
40
80
1
40
80
4
40
80
7
40
81
0
40
81
3
40
81
6
40
81
9
40
82
2
40
82
5
40
82
8
40
83
1
40
90
3
40
90
6
Number of Jobs
ATLAS DC2 - Number of jobs - September 6
120000
100000
80000
60000
40000
LCG
NorduGrid
Grid3
Total
20000
0
-20000
Days
62
40 3
62
6
40
62
40 9
70
40 2
70
5
40
70
40 8
71
40 1
71
4
40
71
40 7
72
40 0
72
3
40
72
40 6
72
40 9
80
40 1
80
4
40
80
40 7
81
40 0
81
3
40
81
40 6
81
40 9
82
2
40
82
40 5
82
40 8
83
1
40
90
40 3
90
6
40
Number of Jobs
ATLAS DC2 - Number of Jobs - September 6
3000
2500
2000
1500
Grid3
NorduGrid
LCG
1000
500
0
Days
ATLAS DC2 - CPU usage
Grid3
29%
LCG
41%
LCG
NorduGrid
Grid3
Total:
NorduGrid
30%
~ 1350 kSI2k.months
~ 95000 jobs
~ 7.7 Million events fully simulated (Geant4)
~ 22 TB
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 dayby-day, as the need arises, for real, imperfect data coming from
the DAQ: no time for more big developments!
LHCb: smart indeed
La GRID ha performances di tutto rispetto.
LCG ha stabilita’ e robustezza
La collaborazione mira al sodo con intelligenza
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.
Migration
to LCG
424 CPU · Years
May: 89%:11%
Jun: 80%:20%
11% of DC’04
25% of DC’04
Jul: 77%:23%
Aug: 27%:73%
22% of DC’04
42% of DC’04
Production Share

LCG: 4 RB in use:
 2 CERN
 1 RAL
 1 CNAF
20 DIRAC Sites
DIRAC
TO 0.72% CNAF 5.56%
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%
Site
Production Share (II)
USA
Israel
Brasil
Switzerland
Taiwan
Canada
Poland
Hungary
France
Netherlands
Russia
Spain
Germany
Italy
United Kingdom
CERN
All Sites
CPU Time (h)
1408.04
2493.44
4488.70
19826.23
8332.05
21285.65
24058.25
31102.91
135632.02
131273.26
255324.08
304432.67
275036.64
618359.24
917874.03
960469.79
Events
32500
64600
231355
726750
757200
1204200
1224500
1999200
4997156
7811900
8999750
13687450
17732655
24836950
47535055
53708405
3711397.01
185549626
% Committed
Events
0.02%
0.03%
0.00%
0.12%
0.50%
0.39%
0.41%
0.65%
1.90%
0.66%
1.08%
9.10%
2.69%
4.00%
4.21%
3.20%
4.85%
3.00%
7.38%
16.20%
9.56%
10.70%
13.39%
30.20%
25.62%
21.20%
28.95%
100.00%
100.00%
Daily Job Production
DIRAC
2500 jobs (*)
LCG
2500 jobs (*)
(*) Job = Brunel Step = DST File
E’ vero che …..
Volete triggerare a 4 KHz????
Siete in grado di capirne le conseguenze ?
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
Parte economica: CMS
2005
Tier
Bari
Bologna
Catania
Firenze
Genova
Legnaro
Milano
Napoli
Padova
Pavia
Perugia
Pisa
Roma1
Torino
Total
LNL LCG
Pi LCG
Tier1 CNAF
Grand Total
Tier2
Tier2
Tier3
Tier3
disk (TB)
rich
prop
2
0
2
0
2
0
2
0
Inventariabile
box (#)
rich
prop
6
6
5
5
4
4
0
2
Consumo
Missioni E.
kEuro
rich
prop
prop
kEuro
kEuro
24
16 come richiesto
5 2 m.u.
10
16
10 come richiesto
46.5 2 m.u.
10
22.5
6
0 Italia
5
12.5
5 come richiesto
4
Tier2+
Tier3
Tier3
Tier2
Tier3
Tier3
Tier2
Tier2
Tier3
10
2
2
2
2
2
4
4
1.25
0
0
2
2
2
0
2
4
1.25
25
3
0
4
4
6
3
4
2
0
0
0
0
2
0
2
2
0
85
19.5
8
18
20
23
22
24
7
0
0
6
6
11
0
11
17
2
come richiesto
come richiesto
come richiesto
come richiesto
17.25
4
6
12
73
15
15
120
16
0
15
20
301.5
43
43
90
12
50
89.5
0
0
45
LCG
LCG
Tier1
33.25
6
6
50
95.25
39.25
223
51
387.5
152
89.5
45
come richiesto
come richiesto
Nota: Total va a carico di CSN I,
LCG va a carico di Grid.it
CNAF va a carico di Centro Regionale
23 1 m.u
2
2
4 3 m.u.
0
1
2 nulla
0
0
5
15
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
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
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)
Non ho motivo per cambiare le mie conclusioni di Giugno
Il capolinea
Sono quattro anni e mezzo che il gruppo dei referee del
computing LHC (e anche di Grid.it e anche del Tier 1) lavora
per aiutare questo grande progetto a decollare e ad assumere la
forma necessaria per garantire le scoperte che verranno.
Crediamo onestamente di averci messo l’impegno necessario e
siamo stati anche ripagati dal vedere le cose crescere pur tra
mille difficolta’ Abbiamo anche imparato tanto.
Rimettiamo al Presidente dell’INFN il mandato ricevuto (Grid.it
e Tier1) e ai Presidenti della CSN I e III quello per il calcolo
LHC degli esperimenti.
Garantiremo una qualche forma di continuita’ se ritenuta
necessaria e comunque forniremo tutto l’aiuto per la fase di
transizione.
Grazie per averci sopportato !