ALICE Computing
F.Carminati/CERN
Commissione Scientifica Nazionale I
Perugia, 11-12 novembre 2002
Commissione Nazionale I
1
sistema online
il trigger multi-livello
filtra il fondo e
riduce il volume dei dati
/sec)
B
G
0
(16
z
zato
z
H
i
l
k
a
i
8
c
spe
e
r
a
w
hard
–
sec)
0
/
o
B
l
l
G
e
(4
liv
z
dded
e
H
b
m
0
e
20
ssori
e
c
o
r
–p
ec)
1
s
/
o
B
l
l
G
e
liv
(2.5
z
H
30
PCs
2
La collaborazione ALICE
livello
include 1223 collaboratori da
85 istituti in 27 nazioni
11-12 novembre 2002
Peso totale
Diametro esterno
Lunghezza totale
Campo magnetico
10.000t
16,00m
25m
0.4Tesla
30 Hz/sec)
GB
(1.25
ti &
a
d
e
n
razio fline
t
s
i
g
e
r
i of
analis
Commissione Nazionale I, Perugia
2
Decisione strategica nel 1998
Framework ROOT
GEANT3, PAW
FORTRAN
Hits
Zebra/RZ/FZ
cinematica
in C++
Geant3
ALICE
geometria
in C++
Hits
Digits
ROOT Trees
11-12 novembre 2002
Commissione Nazionale I, Perugia
3
Schema di sviluppo di AliRoot
Infrastruttura offline di ALICE
strutture
hits di
ROOT
macro
in C++
File di
output di
ROOT
11-12 novembre 2002
strutture
digits di
ROOT
macro
in C++
tracce
di
ROOT
risultati
fisici
macro
in C++
Visualizazione di
dati con ROOT
Commissione Nazionale I, Perugia
4
L’infrastruttura
L’infrastruttura di AliRoot
„ C++: 450kLOC + 225kLOC (generate) + macros: 77kLOC
„ FORTRAN: 13kLOC (ALICE) + 914kLOC (programmi esterni)
„ Mantenuto su Linux (g++ e icc), HP-UX, DEC Unix, Solaris
„ Usato per tutti i TDR’s
Due pacchetti da installare (ROOT+AliRoot)
„ Meno di 1 secondo per linkare (grazie a 37 librerie shared)
„ Installazione “1-click-away”: scarica e make
AliEn
„ Perl5: 25kLOC (ALICE), ~1.5MLOC (componenti open source)
Installata in più di 30 siti da fisici (!!)
„ Più di 50 fisici dei differenti sotto-detettori partecipano allo
sviluppo di AliRoot
„ Il 70% del codice è sviluppato all’esterno, il 30% dal gruppo di
Offline del CERN
11-12 novembre 2002
Commissione Nazionale I, Perugia
5
Struttura di AliRoot
G4
G3
FLUKA
HIJING
AliRoot
Virtual MC
HBTAN
AliEn
ISAJET
EVGEN
STEER
MEVSIM
PYTHIA6
PDF
PMD
STRUCT
EMCAL
CRT
TRD
ITS
START
PHOS
FMD
TOF
MUON
ZDC
TPC
RICH
HBTP
RALICE
ROOT
11-12 novembre 2002
Commissione Nazionale I, Perugia
6
1/100 di un evento ALICE
La complessità del detettore
ALICE è simile ad ATLAS o CMS
GEANT3
„
„
Sviluppato in 1981
Tuttora usato dalla
maggioranza degli
esperimenti
GEANT4
„
„
Un investimento enorme
Adozione molto lenta da
parte della FAE
FLUKA
„
„
11-12 novembre 2002
Commissione Nazionale I, Perugia
Fisica state-of-the-art,
adronica, elettromagnetica
e neutronica
Difficile da usare per
simulazioni di tutto il
detettore
7
Il Virtual MC
Geant4_vmc.tar.gz include le
classi di interfaccia
TVirtualMC <--> Geant4
Codice
utente
VMC
Geant3.tar.gz include
una versione migliorata
di Geant3 con una
intefaccia C++
G3
Trasporto G3
G4
Trasporto G4
FLUKA
Trasporto
FLUKA
Ricostruzione
Modellatore
geometrico
Visualizzazione
Generatori
11-12 novembre 2002
Commissione Nazionale I, Perugia
8
Stato di TFluka/VMC
Interfaccia ai generatori (OK)
„
Tutti i generatori di AliRoot sono accessibili
Š Hijing(Param), Herwig, GEVSIM, ISAJET, PYTHIA…
Geometria (OK via FLUGG, sotto test)
„
Tracking tramite FLUGG e l’interfaccia virtuale
I.Gonzàlez
E.Futo
Stepping action (aka GUSTEP, in sviluppo)
Stacking (discussione in corso)
11-12 novembre 2002
Commissione Nazionale I, Perugia
9
3 milioni di volumi
ALICE
11-12 novembre 2002
Commissione Nazionale I, Perugia
10
Test Geant4.4.1
50cm
50cm concrete(n,Xn)@68MeV
concrete(n,Xn)@68MeV
Pa
ram
etr
izz
azi
on
e
11-12 novembre 2002
Commissione Nazionale I, Perugia
11
Sviluppo della ricostruzione
Efficienza di tracking per TPC+ITS a dN/dy 8000
„
La definizione standard delle tracce buone verso le false richiede che
tutti i 6 hits dell’ITS siano corretti
Š La maggior parte delle tracce false hanno solo un punto sbagliato
„
Quando la condizione è rilassata a 5 hits buoni su 6 l’efficienze
migliora del 7 - 10 % (e la probabilità di tracce sbagliate è
corrispondentemente più bassa)
11-12 novembre 2002
Commissione Nazionale I, Perugia
12
Perchè il calcolo distribuito?
I bisogni del calcolo LHC sono enormi, per esempio per ALICE
„
„
„
„
„
1.25 GB/s durante i runs di ioni pesanti
~3 PB/anno di nastri, ~1.5 PB di dischi
~1800 kSI95 (~70,000 PC2000)
~ 8MEuro di solo hardware
Milioni di linee di codice da sviluppare e mantenere per >20 anni
Tecnicamente, politicamente e sociologicamente non si può
concentrare al CERN
„
„
„
Le “funding agencies” preferiscono investimenti nazionali che al
CERN
La competenza è naturalmente distribuita
Una struttura centralizzata costringerebbe la gente a viaggiare
fisicamente
Ma il modello distribuito è tecnicamente più difficile da realizzare e
in principio globalmente più costoso
„
La sfida è quindi massimizzare l’efficienza minimizzando i costi
11-12 novembre 2002
Commissione Nazionale I, Perugia
13
Il modello di calcolo distribuito
Idea di base
„
Ogni fisico deve avere in principio uguale accesso ai dati e alle risorse
di calcolo
Il sistema finale sarà molto complesso a causa del numero
„
„
dei siti e dei componenti in ogni sito
delle diverse operazioni da effettuare in parallelo: simulazione,
ricostruzione, analisi coordinata e caotica
La cattiva notizia è che gli strumenti di base mancano
„
„
„
„
„
„
Gestione di risorse distribuite
Spazio virtuale distribuito dei nomi dei files e degli oggetti
Autenticazione e autorizzazione distribuita
Gestione di grandi cluster locali
Replicazione e caching dei dati
Monitoraggio e diagnostica delle reti WAN/LAN
La buona notizia è che non siamo soli
„
Tutti i problemi sopra sono al centro degli sviluppi che in Europa e US
vanno sotto il nome collettivo di GRID
11-12 novembre 2002
Commissione Nazionale I, Perugia
14
Il problema da risolvere
Offrire un uso naturale di risorse distribuite …
„ Una persona (production manager, utente) sottomette i
jobs a una coda
„ I files (output e data) finiscono su un file system dove
possono essere manipolati
„ Lo stato delle code e delle risorse è monitorato
… nascondendo (per quanto possibile) il fatto che siano
distribuite …
„ Ovviamente all’utente, il sistema risultante sarà più
complesso
… e ottimizzando il loro uso …
„ Rispetto al sistema equivalente non distribuito
… con un software a livello di produzione …
„ Cioè basato il più possibile su standard e software esistente
e solido
„ Magari con uno scopo limitato alla FAE
11-12 novembre 2002
Commissione Nazionale I, Perugia
15
AliEn: una GRID leggera
AliEn (http://alien.cern.ch)
è unaresource
alternativa leggera
a una
soluzione
di
The “Grid
problem”
is
about
sharing
&
coordinated
griglia completa, ed è basato su componenti standard (SOAP, Web
services, componenti e architettura OGSA) che comprende
problemCatalogo
solving
virtual
dei in
filesdynamic,
visto come unmulti-institutional
file system globale via tavole
RDB
Catalogo dei TAG come estensione
Autenticatione sicura
organizations
Gestore di coda centrale (modello "pull" invece che "push")
Infrastruttura di monitoring
P.Messina
Installazione automatica del software via AliKit
La funzionalità di base della GRID !!
„
„
„
„
„
„
AliEn è usato da ALICE per tutte le produzioni, in particolare per il PPR
AliEn è la componente GRID per MammoGRID, un progetto
di mammografia di 3 anni e 2M€ sponsorizzato dalla UE e
partito in settembre
11-12 novembre 2002
Commissione Nazionale I, Perugia
16
AliEn
(P.Buncic, P.Saiz, J-E.Revschbak)
Accesso ai dati
Architettura
Catalogo files
Bookkeeping
Autenticazione
DISK
Perl5
Tier1
alien
DISK
SOAP Server
ALICE
ALICE
allien
LOCAL
allien(shell,Web)
D0
(shell,Web)Client
path
char(255)
Client
allien
| | | |
| | | |--b/
| | API
| | |--barbera/
|--./
USERS
--./
| |--cern.ch/
dir
integer(11)
| |--r3418_01-01.ds
(shell,Web)
hostIndex integer(11) <fk> User Application
| | |--user/
Client
| |--r3418_02-02.ds
entryId
| | | |--a/
| |--36/integer(11) <pk> (C/C++/Java/Perl)
SOAP Client
| |--r3418_03-03.ds
| | | | |--admin/
| | |--stderr
ALICE
Authorisation
| |--r3418_04-04.ds
| | | | |
| Service
| |--stdin
SIM
T2526
Authorisation
DBI
| | | | |--aliprod/
| | |--stdout
DBI
| |--r3418_05-05.ds
type
char(4)
Service
Proxy server dir| |
Proxy server
| | | | Servizi
integer(8)
T2527
| |--r3418_06-06.ds
DB
DB
name
char(64)
(trasporto
files,
| | | |--f/
| |--37/
type
char(4)
Servizio di
Driver Driver
| |--r3418_07-07.ds
char(8)
DBIowner
dir|--stderr integer(8)
| | | | |--fca/
sincronizzazione
|
|
char(16)
ctime
autenticazione sicuro
| |--r3418_08-08.ds
name
char(64)
Proxy server
|--simulation/
| | | |
comment
char(80)
| | owner
|--stdin
ecc)
char(8)
DB
indipendente dalla
| |--r3418_09-09.ds
content
char(255)
| |--2001-01/
| | | |--p/
| | ctime
|--stdout
char(16)
Driver
method
char(20)
base di dati
| | |--V3.05/
char(80)
| | | | |--psaiz/File transport| |--r3418_10-10.ds
| ADMIN
| comment
methodArg
char(255)
content
char(255)
| | | |--Config.C
sottostante
| | | | | |--as/ Service | |--r3418_11-11.ds
| |--38/
gowner
char(8)
ADMIN
method
char(20)
size
integer(11)
| | | |--grun.C
| | | | | |
| | methodArg
|--stderr char(255)
| |--r3418_12-12.ds
File Catalogue
File
Catalogue
PROCESSES
gowner
| | | | | |--dos/
| | |--stdin char(8)
|
|--r3418_13-13.ds
size
integer(11)
File transport
| | | | | |
| | |--stdout
File Catalogue
|Service
|--r3418_14-14.ds
File Catalogue
| | | | | |--local/
SOAP
| |--r3418_15-15.ds
File(specifiche
Catalogue
dei job) input e
Catalogo dei files: fileFiles, comandi
system globale su output dei jobs, tags e anche
DB Synci tar file
File
Catalogue
nel catalogo
base dati relazionale binari sono immagazzinatiService
11-12 novembre 2002
Commissione Nazionale I, Perugia
Coda di task centrale
17
Physics Data Challenges con AliEn
AliEn
Stato Produzione
@GRID
Produzioni ALICE
100%
90%
Total jobs
0% per site
80%
CERN
70%
Torino
60%
LBL
Lyon 50%
Catania 40%
OSC 30%
20%
FZK
Padova 10%
CNAF 0%
500
GSI
Utrecht 450
Zagreb 400
Budapest350
Prague 300
0%
0%
0% 0%
2% 4%
1%
6%
42%
5%
17%
15%
15100 jobs, ~12CPUh/job
~1GB output/job
fino a 450 jobs simultanei
#of jobs
CPU
8%
2001-02
2002-03
2002-04
Numero dei jobs simultanei
Series1
250
200
150
100
50
0
2001-02
11-12 novembre 2002
2002-02
2002-02
2002-03
Production round
Commissione Nazionale I, Perugia
2002-04
18
La GRID di ALICE
http://www.to.infn.it/activities/experiments/alice-grid
OSU/OSC
LBL/NERSC
Birmingham
Nantes
Saclay
GSI
CERN
Merida
Lyon
37 persone
21 instituzioni
In Italia:
Tier1: CNAF
Tier2 di riferimento: Torino
Dubna
NIKHEF
Torino
Padova
Bologna
IRB
Bari
Cagliari
Yerevan
Catania
Kolkata, India
Capetown, ZA
11-12 novembre 2002
Commissione Nazionale I, Perugia
19
AliEn & PROOF
TagDB
Parametri di
selezione
CPU
Procedura
PROOF
RDB
Proc.C
Proc.C
Portare il kiloByte
al PetaByte e non
il PetaByte al
kiloByte
11-12 novembre 2002
DB1
Locale
CPU
Remoto
DB2
Proc.C
DB3
CPU
Proc.C
DB4
CPU
Proc.C
DB5
CPU
DB6
CPU
Commissione Nazionale I, Perugia
20
ALICE & testbed EDG
Intensa attività di test
Valutazione del testbed
„
„
Script per sottomettere periodicamente job di AliRoot
su tutti i EDG/CE via il EDG/RB
Site web per monitorare lo stato e la statistica
Interoperabilità AliEn/EDG
„
„
„
Portaggio EDG UI su RH7.2 and Solaris
Portaggio EDG/CE e EDG/SE su RH7.2
Test preliminari dell’EDG/RC per un uso eventuale in
parallelo con AliEn
L’esperienza di ALICE con EDG (e AliEn) ha
costituito l’essenza dell’input di ALICE a HEPCAL
11-12 novembre 2002
Commissione Nazionale I, Perugia
21
11-12 novembre 2002
Commissione Nazionale I, Perugia
22
GENIUS (aka R.Barbera)
11-12 novembre 2002
Commissione Nazionale I, Perugia
23
Integrazione AliEn-EDG
EDG RB
RB
EDG
Server
Server
Comune:
In comune:
™
™ JDL
JDL
™
Autenticazione
™ Autenticazione
Requires:
Richiede:
™
al RC
di EDG
™ AliEn
AliEn gateway
SE on EDG
nodes
™
WN al
™ Accesso
Accesso dall’EDG
all’AliEn Data
Data
Catalogue
di AliEn
Catalogue
dal WN
EDG
Data
Data
Catalogue
Catalogue
11-12 novembre 2002
EDG CE
CE
EDG
AliEn/EDG
AliEn CE CE
EDG UI
UI
EDG
AliEn/EDG SE
EDG RC
Commissione Nazionale I, Perugia
WNs
WNs
AliEn SE
Local mass
storage or
EDG SE
EDG SE
24
ALICE (computing) Data Challenges
AliRoot
Dati
raw
Verificare la scalabilità del
sistema acquisizione dati
Dati
simulati
DAQ
ROOT I/O
GEANT3
GEANT4
FLUKA
Verificare l’integrazione
online – offline – HLT
Seguire l’evoluzione della
tecnologia
TIER 1
TIER 2
Regionali
ROOT
CASTOR
GRID
CERN
TIER 0
TIER 1
11-12 novembre 2002
Commissione Nazionale I, Perugia
25
Configurazione hardware della ADC IV
3 switches Gigabit
4 switches Gigabit
TBED00
01-12
13-24
3
25-36
3
3
37-48
LXSHARE
3
01D-12D
13D-24D
2
2
TBED0007D
TOTAL: 32 ports
25D-36D
2
TOTAL: 18 ports
6
CPU servers on FE
2
3
49-60
3
61-72
3
7376
3
Fibers
77-88
89-112
Backbone
(4 Gbps)
10 TAPE servers
Totale: 192 CPU servers (96 su Gbe, 96 su Fe), 36 DISK servers, 10 TAPE servers (distribuiti)
4 switches Gigabit
11-12 novembre 2002
2 switches Fastethernet
Commissione Nazionale I, Perugia
26
Prestazioni
Generazione dei dati negli LDC, event building, niente scrittura
5 giorni non-stop
• 1800 MBytes/s continui (milestone: 1000 Mbytes/s)
Generazione dei dati negli LDC, event building, scrittura su disco
4.5 giorni non-stop
✑ volume totale : ~ 140 Tbytes
✑ 350 MBytes/s continui (milestone 300 MBytes/s)
11-12 novembre 2002
Commissione Nazionale I, Perugia
27
Piani per le PDC di ALICE
Verificare il modello e l’infrastruttura di calcolo
Ridurre il “rischio tecnologico”
Comprendere le potenzialità fisiche del detettore
Mettere a punti codici di simulazione, ricostruzione e analisi
Periodo
(milestone)
Frazione della
capacità finale (%)
06/01-12/01
1%
06/02-12/02
5%
01/04-06/04
10%
01/06-06/06
20%
11-12 novembre 2002
Obiettivi fisici
Studi pp, ricostruzione TPC e ITS
Primi test della catena completa dalla
simulazione alla ricostruzione per il PPR.
Semplici tools di analisi.
Digits in formato ROOT.
Catena completa usata per studi di trigger.
Prototipo dei tools di analisi.
Confronto con il MonteCarlo parametrizzato.
Raw data simulati.
Test del sistema finale per ricostruzione e
analisi.
Commissione Nazionale I, Perugia
28
Modello di calcolo
e distribuzione risorse
ALICE sta definendo il modello di calcolo
Il Tier0 registra i dati
„
Niente elaborazione
I Tier1 si dividono la ricostruzione
„
„
„
Probabilmente in modo asimmetrico, nel senso che il
Tier1 del CERN dovrebbe averne fino al 30%
Però uno sharing diverso è possibile
E questo sarà verificato nelle data challenges
I Tier2 si dividono la simulazione e l’analisi
„
„
Tranne quella parallela, dove probabilmente i vari
centri parteciperanno più simmetricamente
Punto da verificare
11-12 novembre 2002
Commissione Nazionale I, Perugia
29
Sharing risorse LCG / esperimento
La questione dello sharing tra LCG e risorse specifiche di
esperimento è da definire
„ Se LCG fosse stabile, sarebbe sensato includervi tutte le
risorse
„ Però questo impedirebbe la necessaria attività R&D
„ E gli esperimenti hanno bisogno di risorse garantite per le
Physics Data Challenges
L’integrazione può essere solo progressiva
All’inizio sarà necessaria una certa “ridondanza” nella
dotazione totale (esperimento + LCG)
„ Per poi “integrare” le dotazioni di esperimento man mano
che l’efficienza di LCG aumenta
Un vigoroso e coerente lavoro comune di test è la
condizione perché questo succeda rapidamente e in modo
efficace
11-12 novembre 2002
Commissione Nazionale I, Perugia
30
Necessità di calcolo per la PDC III
Year,Quarter
CPU
Total Requirement for Simulation
Total Requirement for reconstruction
Total Requirement for analysis
Total CPU Requirement
STORAGE
Total Requirement for Simulation
Total Requirement for reconstruction
Total Requirement for analysis
Total Storage requirements
LOAD BALANCE CPU
CERN
TIER-1s OUT CERN
Tier-2s
Total CPU Requirement (check)
LOAD BALANCE STORAGE
CERN
TIER-1s OUT CERN
Tier-2s
Total Storage requirements (check)
11-12 novembre 2002
04Q1
ksi95
month
65
124
249
438
04Q2
ksi95
month
TB
21
63
84
TB
21
187
13
220
ksi95
month
131
175
131
438
ksi95
month
140
187
140
467
TB
25
34
25
84
TB
66
88
66
220
156
311
467
Flessibilità del
modello di calcolo
distribuito
Scenari alternativi
Year,Quarter
LOAD BALANCE CPU
CERN
TIER-1s OUT CERN
Tier-2s
Total CPU Requirement (check)
LOAD BALANCE STORAGE
CERN
TIER-1s OUT CERN
Tier-2s
Total Storage requirements (check)
Commissione Nazionale I, Perugia
04Q1
ksi95
month
66
241
131
438
04Q2
ksi95
month
70
257
140
467
TB
13
46
25
84
TB
33
121
66
220
31
Costo calcolo ALICE 2001-2005
Progetto di massima per un centro regionale di calcolo per l'INFN
costi valutati nel piano triennale ALICE (02-04): 1652 kEU
Costi CPU (kEU/kSI95)
Costi dischi (kEU/TB)
Costi tapes in kEU (unità da 18 GB/h)
CPU (kSI95) (2001 assegnati)
Dischi (TB) (2001 assegnati)
Tape capacity (TB) (2001 assegnati)
Costi CPU kEU (2001 assegnati)
Costi dischi kEU (2001 assegnati)
Costi tapes kEU (2001 assegnati)
Totale kEU
Totale kEU (integrati)
2001 2002 2003 2004 2005
53
34
21
13
8
29
14
7
4
2
TOT
15
15
15
63
2
6
12
20
23
11
12
19
28
35 105
4
58
78
70 210
95 195 249 266 189 994
300 172 136 100
63 772
30
0
60
60 120 270
425 367 446 427 371 2036
425 792 1237 1664 2036
Capacità prevista nel 2005 = 15% di quella finale
11-12 novembre 2002
Commissione Nazionale I, Perugia
32
Il processo di sviluppo del software
ALICE ha un piccolo gruppo offline al CERN…
„
Concentrato su infrastruttura, distribuzione del software e
manutenzione
…più 10-15 persone distribuite
„
Coordinazione GRID (Cerello, Torino), World Computing Model
(Nantes), Base di dati dei detettori (Varsavia)
Un ciclo di sviluppo adattato ad ALICE è stato sviluppato
„
„
„
„
Gli sviluppatori lavorano sui soggetti più importanti in ciascun
momento
Una versione stabile di produzione esiste sempre
Il codice è posseduto collettivamente
Il ciclo di release è flessibile e l’installazione molto semplice
Micro-cicli di sviluppo hanno luogo continuamente
Macro-cicli avvengono due-tre volte l’anno
„
„
Discussi e implementati durante settimane offline e “code review”
In corrispondenza di release maggiori
11-12 novembre 2002
Commissione Nazionale I, Perugia
33
Manutenzione di AliRoot
Pianificazione uniforme delle release
„
„
Una release maggiore ogni sei mesi
Una release minore (tag) ogni mese
Manutenzione e supporto continui
„
Ci sono molto pochi bug nella release di produzione perché
la versione di sviluppo è sempre disponibile
Enfasi sulla qualità del codice di produzione
„
Correzioni, protezioni, pulizia del codice, controllo della
geometria
Ogni notte sono prodotti diagrammi UML, listing del codice,
violazioni delle coding rules, build e tests
Un singolo repository con il codice di produzione e di
sviluppo
11-12 novembre 2002
Commissione Nazionale I, Perugia
34
ALICE Offline Computing Structure
Software
Projects
Management
Board
EC DataGRID
WP8
Coordination
Detector
Projects
International
Computing
Board
A.Masoni
Regional
Tiers
Offline Board
Chair F.Carminati
DAQ
P.Vande Vyvre
Production Environment &
Coordination
ROOT FrameWk
Data Challenges
HLT algorithms
P.Buncic
• Simulation
production
• Reconstruction
production
• Production farms
• Database
organisation
• Relations with IT &
other comp. centres
Framework & Infrastructure
F.Rademakers
•
•
•
•
•
•
•
•
Framework development
Database technology
HLT Farm
Distributed computing (GRID)
Data Challenge
Industrial joint Projects
Tech. Tracking
Documentation
11-12 novembre 2002
Simulation
A.Morsch
•
•
•
•
•
•
•
Detector Simulation
Physics simulation
Physics validation
GEANT 4 integration
FLUKA integration
Radiation Studies
Geometrical modeller
Commissione Nazionale I, Perugia
Reconstruction & Physics
K.Safarik
•
•
•
•
•
•
•
Tracking
Detector reconstruction
HLT algorithms
Global reconstruction
Analysis tools
Analysis algorithms
Calibration & alignment algorithms
35
ROOT, ALICE & LCG
LCG ha come obiettivo la costruzione dell’infrastruttura di calcolo
per LHC
ALICE ha esercitato forti pressioni perché LCG fosse basato su
ROOT e AliEn
Gli altri esperimenti hanno scelto un relazione cliente-fornitore con
ROOT e ignorato AliEn
„
„
Svilupperanno alternative per alcuni elementi esistenti di ROOT o li
nasconderanno dietro interfacce astratte
e useranno i risultati dei progetti GRID
ALICE ha espresso le sue preoccupazioni
„
„
„
Manca il tempo per sviluppare e “dispiegare” un nuovo sistema
Duplicazione e dispersione di attività
Divergenza con il resto della comunità della FAE
ALICE continuerà a sviluppare la sua infrastruttura
„
E a fornire tecnologie di base come il VMC o il modellatore geometrico
… e cercherà di collaborare con LCG il piú possibile
11-12 novembre 2002
Commissione Nazionale I, Perugia
36
Conclusione
ALICE ha soluzioni che stanno evolvendo in una solida
infrastruttura per il calcolo
Le maggiori decisioni sono state prese e gli utenti le hanno
di fatto adottate
La collaborazione tra fisici ed “informatici” è eccellente
La stretta integrazione con ROOT permette una grande
rapidità di prototipaggio e di sviluppo
AliEn fornisce una soluzione GRID completa adattata ai
bisogni della FAE che ci ha permesso di effettuare enormi
produzioni con solo due persone “ai comandi”
Molte delle soluzioni sviluppate da ALICE hanno un alto
potenziale di diventare soluzioni comuni ad altri esperimenti
(magari anche esperimenti LHC)
11-12 novembre 2002
Commissione Nazionale I, Perugia
37