STATO ED ESIGENZE DEL CALCOLO PER GLI ESPERIMENTI NELL’ INFN
Il 29 giugno a Napoli si e’ tenuta una prima riunione congiunta della Commissione
Calcolo/CNTC, allargata ai rappresentanti degli esperimenti, per effettuare una
ricognizione dei bisogni di calcolo per l’INFN derivanti dall’introduzione delle nuove
tecnologie, ormai generalmente adottate nel mondo della fisica delle Alte Energie e
Nucleare.
Lo scopo era specificatamente rivolto non a una determinazione esauriente delle strategie
del calcolo dei singoli esperimenti e dei relativi profili finanziari, che sono tipicamente
di competenza delle Commissioni Scientifiche Nazionali, quanto ad effettuare una prima
ricognizione dei nuovi modelli di calcolo e delle conseguenti esigenze riguardanti :
il supporto e gli strumenti software richiesti ai servizi centrali di calcolo delle
singole sedi compresi quelli che possono essere meglio sviluppati con progetti
nazionali
il personale qualificato nelle nuove tecnologie
le infrastrutture di rete locale e geografica
le problematiche da studiare con progetti dedicati
Questo documento raccoglie i risultati di questo primo incontro e va considerato come il
primo passo di un percorso che permettera’ di elaborare un piano dettagliato pluriennale
di sviluppo del computing specifico per l’INFN, in sintonia ed integrato con quelli che
saranno per quella data sviluppati dagli esperimenti a LHC, che costituiscono l’impegno
principale in questo campo.
La nuova direzione del CERN ha deciso di costituire entro settembre 1999 un review
committee che ha il mandato di rivedere i progressi in corso e la pianificazione delle
attivita’ di computing degli esperimenti a LHC e della divisione IT in vista dello start-up
di LHC.
La review dello stato dei piani esistenti sul computing dovra’ essere completata per
l’inizio del 2000 (marzo) assieme alla formulazione di una serie di raccomandazioni per
il futuro che comprenderanno anche la (ri)definizione di un insieme coerente di
milestones per lo sviluppo del computing degli esperimenti a LHC.
I bisogni degli esperimenti e quanto questi si aspettano in futuro dalla divisione IT, dalle
Agenzie di finanziamento coinvolte nel programma LHC e dal CERN dovranno essere
documentati il piu’ dettagliatamente posssibile. Questo implica per l’INFN individuare le
responsabilita’ che la componente italiana dei vari esperimenti intende assumersi e le
relative necessita’. In particolare dovra’ cominciare a chiarirsi all’interno degli
esperimenti e degli organismi istituzionali se l’INFN intende contribuire con centri
regionali in Italia al calcolo degli esperimenti a LHC e quali problemi tecnici sono da
affrontare immediatamente per arrivare a una soluzione soddisfacente per lo start up di
LHC. La scala dei problemi da affrontare e’ enorme e quindi lo studio di queste soluzioni
va affrontato con una certa urgenza.
Lo scopo di questo documento e’ quello di fornire alla direzione INFN un panorama
globale dei bisogni derivanti dai modelli di computing dei nuovi esperimenti, non solo
quelli a LHC, in modo che possa essere elaborata una politica organica di pianificazione
delle risorse necessarie per tutti e di studio di eventuali soluzioni tecnologiche comuni.
Il corpo del documento e’ costituito dai testi elaborati dei singoli esperimenti ed e’
preceduto da un’introduzione e da un sommario esecutivo che riassume gli aspetti
principali dei modelli di calcolo coinvolti e delle relative esigenze.
INTRODUZIONE
Una volta scelto di adottare le nuove tecnologie Object Oriented e le moderne
metodologie di Software Engineering per lo sviluppo del software, il primo problema
che la Fisica delle Alte Energie e Nucleare ha affrontato e’ stato quello di cercare di
ricostituire al piu’ presto quell’insieme di elementi, che nel passato potevano essere
identificati generalmente con i componenti della attuale libreria del CERN, in modo da
fornire agli esperimenti i nuovi strumenti, basati sull’Object Oriented e il C++, da
utilizzare per costruire il proprio software specifico.
In secondo luogo si e’ reso necessario lo sviluppo di nuovi modelli, che tenessero conto
delle potenzialita’ delle nuove tecnologie, quali ad esempio le basi di dati ad oggetti, per
permettere una efficiente organizzazione del lavoro, del calcolo e dell'analisi dei dati per
collaborazioni formate da migliaia di persone sparse in tutto il mondo
Si tratta di un compito non facile perche’ l’ambiente HEP ha necessita’ difficilmente
riscontrabili oggi in altri campi in termini di:
quantita’ e distribuzione dei dati da analizzare ( 5- 10 Pbytes/ esperimento LHC )
potenza di elaborazione necessaria
prestazioni della rete locale e geografica
durata di vita e complessita’ del software da sviluppare (20 anni)
numero di sedi e ricercatori coinvolti in un unico esperimento e quindi motivati a
lavorare insieme in modo coordinato e organico (~2000)
Il mondo commerciale quindi, che e’ un punto di riferimento fondamentale per aver
adottato da lungo tempo le moderne tecnologie, non sempre offre prodotti che si adattino
alle stringenti richieste dell’ambiente HEP.
Il problema per HEP quindi e’ quello di valutare quanto il mondo commerciale possa
attualmente fornire e sviluppare poi o in toto, o partendo da una base commerciale
esistente, i prodotti di cui ha bisogno per le proprie necessita’.
Specifici progetti di R&D sono stati sviluppati in questi anni al CERN e negli USA per
dare una risposta a queste domande. I primi risultati cominciano ora ad essere a
disposizione degli esperimenti : Geant4, Objectivity, LHC++, CLHEP, tools di analisi
etc.. Pero’ non sempre i risultati di questi progetti portano a prodotti accettati da tutta la
comunita’ e l’esperienza insegna che molta e’ ancora la strada da percorrere prima di
poter ricostituire un insieme organico di elementi come era la vecchia CERNLIB.
L’acquisizione di nuove competenze nel mondo HEP non puo’ quindi limitarsi al livello
di pura utenza, ma deve includere una frazione non trascurabile di personale che sia in
grado effettuare gli sviluppi di base necessari per ricostuire quel quadro di riferimento
organico in cui poi i fisici potranno introdurre i propri algoritmi di analisi come nel
passato. Questi sviluppi non saranno di breve durata ed e’ prevedibile che saranno
necessarie alcune iterazioni prima di arrivare alle soluzioni finali.
Inoltre queste dovranno essere costruite con metodologie professionali in modo da poter
garantire una lunga vita ai prodotti che su di esse saranno costruiti.
E’ auspicabile che in tutto questo processo l’INFN non si limiti ad un ruolo di pura
utenza e debba quindi dipendere da altri per ogni ulteriore sviluppo, ma partecipi alle
attivita’ di creazione degli strumenti di base che richiedono il massimo livello di
competenze. In questo modo si potra’ sviluppare anche nel campo delle nuove tecnologie
del computing un livello di eccellenza pari a quello che l’INFN ha sempre posseduto in
altri settori : meccanica, elettronica, rivelatori, analisi.
La costituzione del CNTC ha fornito un punto di riferimento importante agli esperti dei
servizi di calcolo e degli esperimenti per promuovere e organizzare la partecipazione ai
grandi progetti internazionali di sviluppo sul computing moderno.
Il grande entusiasmo con cui la comunita’ INFN ha accolto i corsi di formazione sulle
metodologie e applicazioni OO del CNTC, saturando costantemente tutti i posti
disponibili, fa ben sperare che all’interno dell’Ente si possano costituire, accanto ad una
diffusione generale di queste, anche dei nuclei di alto livello professionale.
La creazione di questi nuclei deve pero’ essere seguita e incentivata con particolare
attenzione da parte dell’Ente. E’ altrettanto necessaria della formazione generalizzata e
costituisce anzi la condizione necessaria perche’ dopo i corsi le competenze del personale
possano continuare a progredire e con queste i contributi INFN al computing dei nuovi
esperimenti..
In prospettiva le attuali esigenze del mondo della fisica nucleare e sub-nucleare sembrano
destinate ad avere un’ampia diffusione in tutte le societa’ avanzate in cui le applicazioni
dell’Information Technology svolgono un ruolo sempre piu’ strategico.
L’ambiente HEP infatti, pur essendo di dimensioni trascurabili in termini economici
rispetto alle dimensioni del mercato di una societa’ informatizzata (vedi ad es. i ~ 2000
PC INFN rispetto ai 200 Milioni venduti nel mondo) precorre in molti aspetti come
esigenze il mercato di massa e costituisce un banco di prova altamente significativo per
molte delle applicazioni che sono destinate ad avere un ruolo strategico in ogni societa’
avanzata .
L’ambiente di fisica delle Alte Energie e Nucleare puo’ dunque offrire un’opportunita’
unica per praticare e sperimentare le nuove tecnologie che si sono sviluppate in tutti
questi anni nel campo dell’Information Technology al massimo livello e puo’ essere
attraente anche per organizzazioni o persone esterne all’ambiente stesso.
Quindi opportuna attenzione deve essere dedicata per sfruttare queste potenzialita’
individuando i progetti europei, le collaborazioni con industrie, facolta’ di informatica e
altre organizzazioni che siano interessate a progetti comuni e possano arricchire il
bagaglio di conoscenze disponibili.
All’estero sono ormai numerosi i progetti di questo tipo, vedi ad esempio:
In USA il progetto GIOD che e’ un progetto congiunto (Caltech-CERN-HP) su Globally
Interconnected Object Databases che investiga l’usabilita’, la scalabilita’ e la portabilita’
del codice OO degli esperimenti a LHC su un sistema gerarchico di grandi servers e
medio piccole macchine client distribuite su reti locali e geografiche veloci.
Vedi : http://pcbunn.cithep.caltech.edu/
In USA i progetti che vanno sotto il nome di Data Analysis Grid e comprendono :
Il progetto DoE/NGI: The Particle Physics Data Grid (PPDG): 1999-2000+ a cui
partecipano i maggiori laboratori USA HENP : FNAL, BNL, ANL, LBNL, SLAC,
JLAB, e alcune universita’ : Caltech and CACR, SDSC, Wisconsin (CS) che ha il
compito di sfruttare le conoscenze e i tools esistenti per costruire un sistema di
gestione dei dati distribuito
Vedi : http://www.phys.ufl.edu/~avery/mre/ppdg_proposal.pdf
Il progetto DoE IT2/SSI: Development of Proposal for HENP Data Management:
“Virtual Data”
Vedi : http://www.internet2.edu/ e referenze collegate
Il progetto NSF: US Data Analysis Grid: 2001 – 2005 che e’ un joint proposal a
cui partecipano US CMS/US ATLAS/LIGO e ha il compito di sviluppare dei
centri secondari di analisi dei dati che siano ben coordinati con un centro centrale e
che ha richiesto un finanziamento superiore a 50 Milioni di dollari
Vedi : http://www.phys.ufl.edu/~avery/mre/
Tutti questi tre progetti si basano su una infrastruttura di rete comune ad alte prestazioni
Nell’ultima referenza possono essere trovati i riferimenti a numerosi progetti in altri
settori che richiedono l’analisi di alcune Pbytes di dati :
The Earth Observing System Data Information System (EOSDIS) (3 PB by 2001);
The Human Brain Project. Time series of 1 Terabyte scans of the human brain,
generating of the order of a Petabyte of data in a short period of time;
The Human Genome Project;
Astronomical scans (e.g., Sloan Sky Survey) ;
Geophysical data;
Satellite weather image analysis, where chaotic processes are studied;
Point of sale receipts, in which patterns of consumer spending are tracked ;
Banking records, which are analyzed for spending cycles or unusual transactions
which may relate to illegal activities.
In Gran Bretagna e’ stato di recente finanziato, come Joint Research Equipment
Initiative per un valore di circa 2.5 Milioni di sterline, un progetto di mass storage,
collegato al Montecarlo Array Processor (MAP), proposto da Liverpool in collaborazione
con Compaq, che contribuisce al finanziamento. Come primo stadio, il progetto sta
costruendo un prototipo di mass storage con la capacita’ di 40 TBytes per produrre e
analizzare dati di simulazione per l’esperimento LHC_b. In questo prototipo saranno
studiati e risolti i problemi tecnici per garantire la scalabilita’ di questo sistema alle
centinaia di TBytes necessarie per LHC.
SOMMARIO DELLE RICHIESTE
L’esame dei documenti presentati dagli esperimenti permette di individuare piu’
precisamente gli aspetti di particolare impatto sulle esigenze del sistema di calcolo in cui
l’INFN e’ coinvolto e di grande interesse per le tecnologie coinvolte.
Lo studio di molte di queste, alla luce di quanto detto sopra, puo’ certamente raccogliere
un interesse non limitato alla sola fisica delle Alte Energie e Nucleare.
Tecniche Object Oriented per lo sviluppo di tutto il Software di elaborazione e
analisi dei dati, vedi LHC,Babar, Compass e parzialmente CDF
Utilizzo dei moderni databases ad oggetti per l‘archiviazione e l’accesso
simultaneo ai dati degli eventi in tutte le loro varie fasi di elaborazione (RAW,
DST, N-tuples…).Vedi LHC, Babar e Compass
Utilizzo di sistemi di mass storage per la gestione automatica di dischi e nastri,
vedi LHC, Babar, Compass CDF, NA48
Sviluppo di modelli di calcolo distribuiti con due possibili livelli :
- Distribuzione a livello di Centri Regionali dei dati anche in stadi intermedi di
elaborazione e della CPU , vedi LHC e parzialmente Babar-INFN
- Distribuzione via rete dei soli dati nella fase finale di elaborazione (N-tuple)
Vedi CDF
Sviluppo di FARM italiane con grande potenza di CPU, vedi teorici, AMS, Virgo,
Kloe e tutti gli esperimenti gia’ citati interessati ai Centri Regionali
Per lo sviluppo di queste tematiche vi e’ una richiesta generalizzata da parte degli
esperimenti di supporto da parte di esperti dei servizi di calcolo.
Le richieste dettagliate presentano gradi di maturita’ diversi a seconda della tematica e
degli esperimenti.
Nel seguito si cerchera’ quindi di riassumere le esigenze fin d’ora gia’ ben definite e di
proporre una schedula per arrivare a una definizione dettagliata di quelle non ancora
mature oggi.
ESIGENZE BEN DEFINITE
Le esigenze gia’ ora sufficientemente definite riguardano:
1. Software professionals
Necessita’ di software professional che riguardano principalmente ATLAS e CMS per lo
sviluppo del software con le moderne tecnologie e lo sviluppo e i test dei modelli di
calcolo per LHC connessi con le attivita’del progetto Monarc. Alcune di queste richieste
sono considerate di particolare urgenza (1999) e attualmente gia’ sono stati individuati
dei candidati validi per sopperire ad esse.
ATLAS
Dall'indagine svolta fra i gruppi ATLAS-Italia si prevede che nel 2000 si verificheranno
4 esigenze di posizioni temporanee di questo tipo, in presenza sia di progetti adatti che di
persone disponibili e preparate. Tre di queste posizioni figurano gia' nelle richieste
presentate al MURST nell'ambito del cofinanziamento INFN per il progetto PANDA, il
cui esito si dovrebbe conoscere a settembre 99; la quarta esigenza si colloca nell'ambito
dell'attivita' Lev3Trigger/EventFilter.
Queste esigenze dovrebbero essere soddisfatte entro i primi mesi del 2000 e la loro
illustrazione dettagliata sara’ inserita nel documento sul Calcolo Atlas-Italia in
preparazione appunto per i primi mesi del 2000 in connessione con la review sul
computing degli esperimenti a LHC
Ci sono poi 2 esigenze urgenti che dovrebbero essere soddisfatte prima della fine del
2000 a Milano e Roma, che vengono illustrate qui con qualche dettaglio.
- Il gruppo di Milano-LARG, che prevede di impegnare circa 3 FTE sulle attivita' di
sviluppo sw OO, ha inoltre un ruolo cruciale in MONARC e nelle attivita' connesse,
tramite l'attivita' di Project Leader svolta da Laura Perini e grazie all'impegno a
tempo pieno (sopratutto nel campo delle OODB e dei relativi tests e misure di prestazioni
su rete locale ed estesa) di una persona esperta la cui posizione temporanea informaticospecifica scade a dicembre 99.
Il venire meno di questo contributo alle attivita' di MONARC avrebbe conseguenze gravi
anche sulla capacita' italiana di esercitare efficacemente un'azione di leadership sulle fasi
future del progetto e comunque di giocare un ruolo rilevante negli studi, sviluppi e
decisioni sulla preparazione del calcolo ad LHC che si svolgeranno in ogni caso nei
prossimi anni, anche indipendentemente dalla continuazione di un progettospecifico.
- Il gruppo di Roma1 dedica circa 3.5 FTE all'attivita' di sviluppo software che riguarda
tre aspetti principali, tutti legati al muon detector:
1 - Analisi dei dati di test-beam e studi di autocalibrazione delle camere MDT.
Questa attivita' viene svolta da tempo e con notevole impegno; il livello di competenza
acquisito porta ad assumere nei confronti della collaborazione il commitment di fornire il
software di autocalibrazione per la camere MDT dell'esperimento.
2 - Simulazione del Livello1 del trigger mu (barrel).
La responsabilita' per la realizzazione dell'elettronica di trigger comporta una intensa
attivita' di studio e simulazione; il gruppo ha assunto da tempo l'incarico di sviluppare
il software di simulazione e includerlo nel framework ufficiale per permettere gli studi di
performance combinata.
3 - Algoritmi per il Livello2 del trigger mu (barrel).
Un impegno crescente e' posto nello sviluppo del patter recognition delle tracce e nella
determinazione dell'impulso dei mu; la complessita' del problema e' aumentata dalla
necessita' di mantenere una versione di simulazione nel framework generale e una
versione ottimizzata per i test di prestazioni in ambito on-line. Anche per questo item il
gruppo ha un commitment nei confronti della collaborazione.
Il manpower complessivamente dedicato a queste attivita' e' di ~3 fte (~4 nel 2000).
L'attivita' di sviluppo software e il livello di impegno verso la collaborazione sopra
delineati richiedono, specie in questa fase di migrazione del software alla nuova
architettura, l'apporto di ulteriore manpower. Per altro, il fatto che tutte le attivita' siano
portate avanti nell'ambito del muon detector permette una notevole sinergia. In tal senso
sembra opportuno poter disporre in tempi brevi di una posizione temporanea (per la quale
si e' a conoscenza di candidati dalle caratteristiche idonee) con l'intento di rafforzare la
capacita' complessiva del gruppo di gestire questa fase di transizione e mantenere gli
impegni verso la collaborazione.
CMS
Per quanto riguarda le stime di personale coinvolto ad oggi e le necessita' di figure
professionali da affiancare nelle Sezioni all'attivita' di Computing di CMS, si e' fatta
ancora una volta l'indagine sulla base dei criteri esposti piu' sopra nei paragrafi 2 e 3.1.
Il risultato a portato ad una valutazione di
circa 15 FTE nella simulazione/ricostruzione
circa 10 FTE nello sviluppo
circa 2 FTE nel Core software
circa 8 FTE nell'analisi dei dati dai Testbeam
circa 4 FTE impegnati in Monarc e Centri Regionali
Il totale degli FTE e' in linea con la percentuale di partecipazione dell'INFN a CMS, con
eccezioni degne di nota in posizioni chiave e di spinta professionalita' (non siamo assenti,
anzi spesso trainanti, ma "sotto quota").
I desiderata delle Sezioni piu' impegnate in questa attivita' ha riscontrato la necessita' da
subito (1999) per alcuni anni (almeno fino al 2005) di alcune unita' (da 4 a 8) di figure
professionali per tutte e tre le tipologie elencate nel paragrafo 3.1 (Physicist Computer
Professional, Computer Professional, System Professional).
Alcune di queste esigenze sono urgenti in quanto riguardano figure particolarmente rare
nell’INFN, anche se negli ultimi tempi molto si e’ fatto con l’attivita’ della CNTC, le
Borse di studio Informatiche e gli “Assegni di ricerca”. In particolare nelle Sezioni piu’
impegnate in CMS si identificano da subito almeno 6 posizioni del tipo citato, anche se
reperire questo personale “professional” non e’ facile.
Per completezza va ricordato che molte Sezioni CMS hanno presentato al MURST il
progetto di cofinanziamento PANDA che, nella speranza venga approvato, potrebbe
coprire una parte considerevole delle necessarie risorse di investimento e di personale
dedicato.
BABAR
I bisogni di software professionals vengono soddisfatti in generale in Babar utilizzando
personale esterno pagato con i fondi comuni a cui l’INFN contribuisce per la parte a lui
spettante con i finanziamenti proposti dal GR1.
2.
Necessita’ di rete per l’esperimento CDF
L'analisi di CDF e' centrata su n-tuple (in realta' Root files) sul disco locale del PC di
ogni persona (linux). Le n-tuple verranno create con job batch che girano su macchine
collegate ai dischi dati con link ad alta velocita', quindi al Fermilab dove i dati sono su
SAN basata su FC, o su nastri robotizzati su SCSI locale. Le n-tuple verranno poi copiate
sui dischi locali dei PC in Italia attraverso la rete o spedite su cassetta per DHL.
Data set di uso frequente saranno replicati su disk servers locali nelle sezioni. Si
immaginiamo 3 di questi servers (PI,PD,BO e.g.) con uno/due TeraBytes di disco
ognuno.
La banda necessaria per CDF tra l'Italia e Fermilab e’ stimata in :10 Mbit/sec l'anno
2000, a crescere fino a 40-50 Mbit/sec al momento che sara’ disponibile il data set finale
(circa 1PB nel 2002/3).
La banda necessaria all'interno dell'INFN: circa 5 volte quanto necessario con gli USA,
ma anche un fattore 10 sarebbe desiderabile.
Deve essere possibile privilegiare l'interattivo sulla rete : supporto per controllo e monitor
remoto attraverso strumenti di QOS od in alternativa links dedicati temporanei stile
ISDN per videolink.
Si richiede il supporto per sistemi di videoconferenza basati su CODEC e si auspica la
messa in opera di un MCU in Italia.
ESIGENZE DI PIU’ LUNGO RESPIRO
L’esame delle richieste degli esperimenti permette inoltre di individuare i seguenti
bisogni che dovrebbero essere risolti con progetti di sviluppo comuni.
La prima necessita’ e quelle di dare inizio ad un progetto sul mass storage i cui
requirements sono gia’ ben definiti in connessione con analoghi progetti in corso di
definizione a livello internazionale (CERN, DESY, USA…..)
Ci sono poi degli sviluppi futuri che sono di grande interesse strategico ma su cui il
dibattito non e’ stato ancora finalizzato e riguardano:
FARM
Centri regionali
Sviluppo di applicazioni sulla rete con qualita’ di servizio garantito
Sviluppo Software OO
Il primo punto riguarda lo sviluppo di un sistema standard per il controllo e la gestione di
grandi FARM per la simulazione e l’elaborazione distribuita dei dati.
E’ attualmente in corso un dibattito interno all’INFN per verificare il grado di
partecipazione e i requirements per un progetto di questo tipo che puo’ interessare anche
il progetto APE. Un documento dovrebbe essere elaborato per la fine dell’anno.
Un progetto simile per l’Event Filter Farm degli esperimenti a LHC e’ stato approvato dal
LCB al CERN e sara’ necessario sfruttare i punti di convergenza.
Il secondo punto riguarda le scelte riguardanti i possibili Centri Regionali in Italia che
sono attualmente studiate dagli esperimenti a LHC sfruttando anche i risultati ottenuti dal
progetto Monarc la cui prima fase di ricognizione e ‘ prevista terminare alla fine
dell’anno.
Oltre allo studio del comportamento dei database ad oggetti distribuiti, lo sviluppo di
strumenti di simulazione del computing model e le guidelines per lo sviluppo dei Centri
regionali, una delle componenti fondamentali per il calcolo a LHC, prese in
considerazione da Monarc, e ‘ costituita dalle rete su cui si stanno sperimentando con la
partecipazione del CNAF meccanismi per la prioritarizzazione del traffico relativo alle
varie applicazioni basato su meccanismi di qality of service.
Lo sviluppo software Object Oriented richiede da una parte l’acquisizione di nuove
metodologie e dall’altra l’acquisizione di strumenti di software engineering di supporto.
La Commissione Calcolo seguendo le richieste dei gruppi ha fornito una prima serie di
licenze di Insure++ e Rational Rose a tutta la comunita’ INFN tramite un server centrale
localizzato al CNAF. E’ presumibile che nel futuro con l’estendersi delle conoscenze
queste esigenze crescano e cresca anche la necessita’ di sperimentare nuovi prodotti resisi
disponibili sul mercato
SCADENZE E RACCOMANDAZIONI
A fine del 2000 dovrebbe essere completata una proposta complessiva almeno per il
computing di ATLAS e CMS tenendo conto anche dei tempi che verranno meglio
definiti nella gia’ citata review del computing degli esperimenti a LHC che il
management del CERN effettuera’ tra la fine 1999 e i pimi mesi del 2000. Il fine e’ di
arrivare ad un memorandum of understanding sul computing che comprendera’
presumibilmente sia i finanziamenti che le responsabilita’ di sviluppo del sistema di
calcolo e del software per ogni istituzione.
Per la fine del 2000 inizio 2001 dovranno quindi essere gia’ individuati, per quanto sopra
detto, gli impegni dettagliati dei gruppi INFN e le necessita’ di risorse anche umane di
software professional che questi comportano.
Si ritiene quindi importante poter chiarire con gli organi di direzione dell’INFN quali
sono le prospettive per la soddisfazione delle esigenze gia’ ben individuate con i loro
tempi e quali strategie adottare per arrivare alla definizione dei memorandum of
understanding sul computing per gli esperimenti a LHC. Alcuni degli sviluppi necessari
sono di interesse di tutto l’INFN e inoltre molti di questi potrebbero trovare un interesse
piu’ vasto di quello HEP come dimostrano gli esempi sopra citati in USA e GB.
Sarebbe importante poter discutere e individuare con gli ogani di direzione dell’INFN le
strategie migliori per poter eventualmente avere accesso ad altre fonti di finanziamento
esterne all’ente , Comunita’ Europea, MURST etc.conservando un controllo unitario su
questi progetti.
COLLEZIONE DELLE RICHIESTE DEGLI ESPERIMENTI
1. STATO ED ESIGENZE DEL CALCOLO DI ATLAS-ITALIA al luglio 1999
STATO DEL COMPUTING DI ATLAS
Le attivita' riguardanti il Calcolo di ATLAS si possono raggruppare in tre filoni
principali:
1 - Analisi da dati dei Test-Beams (TB) e studi di fisica e di prestazioni di parti
dell'apparato (TB inclusi) basati sulla simulazione. Il Technical Design Report (TDR)
della fisica, comprensivo studio delle potenzialita' fisiche e delle prestazioni di ATLAS
in piu' di 800 pagine, e' stato pubblicato in giugno 99. In questa fase ulteriori simulazioni
sono richieste solo per alcuni argomenti specifici, specificatamente per la finalizzazione
degli studi sul trigger.
Queste attivita' sono la continuazione di quanto fatto in passato e come tali non
richiedono in generale risorse diverse da quelle correntemente impiegate. E' comunque in
corso anche per le attivita' collegate ai TB un'evoluzione verso il software (sw) Object
Oriented (OO), sia per quanto riguarda la transizione della simulazione a GEANT4, sia
per quanto riguarda il software di analisi. Per alcuni rivelatori sono gia' stati fatti partire
progetti pilota di questo tipo e altri inizieranno a breve.
2 - Sviluppo del software OO per l'esperimento.
La collaborazione ha deciso che il sw di simulazione, ricostruzione e analisi di ATLAS
nel 2005 dovra' essere completamente basato su disegno e codice OO con preferenza per
il linguaggio C++. Per il disegno e lo sviluppo di questo software si valuta siano
necessari circa 1000 anni-uomo di impegno globale.
Originariamente (nel Computing Technical Proposal, CTP, pubblicato all'inizio del 1997)
si era previsto che una prima versione di questo sw, con funzionalita' limitate, ma
sufficienti a permettere almeno alcuni studi a livello di singoli sottorivelatori, sarebbe
stata disponibile entro la fine del 2000, mentre l'implementazione di una versione
utilizzabile per tutti gli studi di fisica e prestazioni dell'apparato era prevista per il 20032004.
La data di fine 2000 dovra' probabilmente essere riconsiderata alla luce dei risultati della
Atlas Computing Review (ACR, vedi infra), mentre la previsione del 2003-2004
mantiene la sua validita', cosi' come la milestone di Giugno 2001 per la scelta
del sistema per la persistenza degli oggetti ( Persistent Object Manager, POM, per cui la
scelta di baseline e' finora Objectivity-DB).
Nel febbraio 99 ATLAS ha recepito i risultati della ACR che si era svolta nei quattro
mesi precedenti; di conseguenza e' stata decisa una riorganizzazione del calcolo, che,
mantenendo l'obiettivo di fondo del sw OO citato sopra, mira pero' specialmente ad un
maggiore coinvolgimento nello sviluppo del sw OO della comunita' fin qui impegnata
prevalentemente sulle simulazioni e analisi fisiche (la comunita' al cui lavoro e'
largamente dovuto il TDR della fisica appena concluso). Un ulteriore scopo della
riorganizzazione e' favorire l'assunzione di impegni di sviluppo sw chiari e ben definiti da
parte dei diversi Istituti della collaborazione, in vista di un "Memorandum of
Understanding per il sw e Computing".
E' stata costituita una "Architecture Task Force" che dovra' realizzare una partizione del
software da sviluppare, in base alla quale i diversi Istituti negozieranno le loro
responsabilita' specifiche. La prima fase di questo processo dovrebbe concludersi con
l'inizio del 2000, e comprendere anche la (ri)definizione di un insieme coerente di
milestones per lo sviluppo del sw di ATLAS.
3 - Preparazione del sistema di calcolo di ATLAS per il 2005.
La problematica era stata affrontata inizialmente gia' del CTP, dove e' anche fornita una
prima valutazione molto approssimativa del costo del sistema delle farms, con CPU's,
dischi e "nastri" per il periodo 2000-2006 compreso. Il costo era stato stimato in
36 MCHF, corrispondenti ad una quota parte italiana di circa 5.4 GL.
Al momento le attivita' principali su questa linea si svolgono nell'ambito del progetto
MONARC; le caratteristiche del progetto, le sue prospettive e la rilevanza per ATLAS,
nonche' il legame con il costituendo Computing National Board di ATLAS
sono trattati nell'allegato documento "Centri Regionali e ATLAS-Italia".
Il management del CERN ha annunciato un mese fa ( durante la riunione del LHC
Computing Board, LCB, del 23-6-99 ) una "Computing Conceptual Review" che si
svolgera' fra settembre 99 e l'inizio del 2000, al cui interno saranno ricollocati i
Computing Progress Reports degli esperimenti e ha sottolineato l'importanza dei risultati
anche di MONARC in questo contesto.
In seguito alla Review sara' preparato uno Workplan CERN per il Computing di LHC,
entro la primavera del 2000 e si dovra' iniziare a prevedere i finanziamenti relativi.
ESIGENGE PER IL CALCOLO DI ATLAS
Le esigenze discusse in questo documento sono principalmente quelle rilevanti a medio e
lungo termine per
1 - lo sviluppo del sistema di sw OO
2 - lo sviluppo del sistema di calcolo
entrambi i sistemi si suppone dovranno entrare in produzione nel 2005.
Le esigenze legate alle attivita' correnti di TB, simulazione, ricostruzione e analisi sono
prese in considerazione solo in quanto si inseriscono in prospettiva nei due filoni elencati
sopra.
Esigenze comuni a entrambi i filoni, oltre ai servivi informatici di base, comprendono:
- Personale qualificato
- Strumenti per la collaborazione a distanza (Collaborative
Tools)
- Licenze sw
Esigenze specifiche per 2) comprendono inoltre:
- Investimenti in CPU, dischi, "nastri"
- Infrastrutture per il "Centro Regionale"
- Reti
- Coordinamento fra gli esperimenti LHC italiani
ATLAS-Italia si propone di articolare la discussione del suo piano per il sw e computing
con le opportune istanze dell'INFN in 3 fasi, all'inizio di ciascuna delle quali si propone
di presentare un documento di riferimento.
Questo testo e l'allegato "Centri Regionali e ATLAS-Italia" costituiscono il primo
documento.
I tempi e contenuti degli altri documenti saranno i seguenti:
- Nei primi mesi del 2000: elenco degli impegni nello sviluppo del sw OO;
quantificazione delle risorse di CPU, disco, nastro richieste dal modello di calcolo fino al
2006 compreso; piano per la prototipizzazione a medio termine. Esigenze relative.
- A fine 2000: proposta per un Centro Regionale in Italia; primo piano globale per il sw e
calcolo ATLAS-Italia. Esigenze relative.
La quantificazione delle esigenze di hardware, reti, infrastrutture, etc. per il medio e
lungo termine, e' pertanto ora prematura e verra' affrontata nei due documenti previsti per
il 2000.
Risulta invece urgente affrontare la tematica delle esigenze di personale qualificato,
ovvero di quelle figure che sono usualmente indicate col termine di "Sw e/o Computing
Professionals" (per brevita' semplicemente "Professionals" nel seguito), intendendo
"Esperti dedicati ad attivita' di alto contenuto tecnologico nel campo del sw e/o del
computing".
Il termine ha quindi significato analogo a quello che ha assunto per BaBar, dove pero'
questo personale deve largamente essere acquisito dall'esterno dell'esperimento e
grava quindi sui fondi comuni dell'esperimento stesso.
Questa situazione non dovra' ripetersi per LHC e le competenze necessarie devono
percio' essere sviluppate all'interno di ATLAS e dei servizi INFN di supporto.
Per chiarire meglio cosa si intende qui per "Professional" sembrano utili anche i punti che
seguono:
- Ruolo nello sviluppo del sistema di sw e calcolo:
+ Supporto e ottimizzazione delle prestazioni per quanto riguarda lo sviluppo del sw di
simulazione, ricostruzione e analisi specifico di un esperimento. Questo sviluppo dovra'
continuare ad essere realizzato prevalentemente dai fisici.
+ Partecipazione diretta invece nelle attivita' seguenti:
- Sviluppo del framework generale dell'offline e dell'online e interfacciamento
dei pacchetti di utilita' generale (commerciali e no) necessari
- Specificatamente interfacciamento e gestione della persistenza degli oggetti
(Database OO, Objectivity etc.)
- Ottimizzazione e prototipizzazione del calcolo distribuito, con le relative
attivita' di modelling.
- Tipo di preparazione richiesta.
Non sembra che sia necessariamente da richiedersi una laurea in informatica, ingegneria
informatica o similia.
Nel ruolo di "Professional" saranno necessari alcuni "software engeneers", ma in molti
casi dei laureati in fisica, magari con qualche esperienza dell'ambiente delle alte energie,
possono ricoprire questi ruoli altrettanto bene o addirittura meglio, purche' ovviamente
abbiamo portato a termine un serio, approfondito e definitivo processo di riconversione
alle tecnologie del sw e computing.
- Ruolo nell'INFN.
In generale queste figure potrebbero bene inserirsi nei ruoli tecnologici dell'INFN.
In Atlas-Italia c'e' attualmente una quasi completa mancanza di personale con questo
profilo.
Una quantificazione completa delle esigenze e' prematura, ma si possono gia' indicare
alcune linee utili per la valutazione.
Si possono utilizzare due metologie:
1 - Top-Down: dagli impegni che si intende prendere alla stima del personale necessario
Questa via dovra' essere seguita contestualmente con l'assunzione degli impegni degli
Istituti italiani, nel contesto della preparazione di un "MoU per il sw e computing" che
iniziera' nell'autunno 99.
I gruppi italiani di Atlas non sono oggi in grado di svolgere in modo sensato questo tipo
di esercizio; ATLAS-USA ha pero' presentato in marzo 99 un piano di questo tipo i cui
aspetti piu' rilevanti si riassumo qui per confronto; fra parente si sono riportate le stime
che risulterebbero dalla banale trasposizione ad ATLAS-Italia dell'esercizio fatto da
ATLAS-USA.
Valutazione delle esigenze di personale per il solo sviluppo software fatte da ATLASUSA:
- 1000 anni-uomo per tutto ATLAS per lo sviluppo sw
- 200 anni-uomo quota parte proporzionale spettante ad ATLAS-USA
(120 per ATLAS-It)
- FTE in ogni anno 33=200/6anni (20 FTE per ATLAS-it)
- 60% fisici e 40% Professionals (8 Professionals per ATLAS-it)
In maggior dettaglio le stime USA sono
48 anni-uomo di Professionals per core sw
36 anni-uomo di Professionals per non-core sw
115 anni-uomo di fisici
2 - Bottom-Up : dai progetti che progressivamente maturano alle competenze che essi
richiedono e che possono essere sviluppate in essi.
Da un'indagine realizzata fra i gruppi di italiani di ATLAS, risulta che le stime della
manodopera di tipo "fisici" che sara' impegnata nello sviluppo del sw OO di ATLAS
varia fra 15 FTE per fine 99 a 23 per fine 2001. C'e' invece soltanto 1 Professional
permanente e senior coinvolto in queste attivita'; inoltre ci sono 2 giovani con posizioni
temporanee di specifico contenuto informatico in scadenza a dicembre 99 e marzo 2000.
Risulta chiara la drammatica carenza di "Professionals" e di conseguenza l'urgenza di
acquisire queste competenze; sembra ovvio che una delle strade da percorrere e' lo
sviluppo di queste competenze all'interno dei gruppi tramite la partecipazione attiva a
progetti adatti di giovani interessati a specializzarsi in questo settore e che abbiano gia'
sviluppato le competenze di base necessarie a dare fin dall'inizio un apporto significativo
al progetto. Si puo' essere confidenti che nel nostro ambiente esistano abbastanza giovani
con queste caratteristiche, anche grazie alle attivita' di sensibilizzazione, informazione e
training realizzate nell'INFN, specialmente a cura della CNTC, e alle borse informatiche
bandite negli ultimi anni.
E' importante che al momento in cui i gruppi portano a maturazione entro la
collaborazione dei progetti adatti e quando siano disponibili delle persone con le giuste
caratteristiche, sia possibile inserire rapidamente le persone nei progetti tramite una
procedura agile con cui l'INFN possa accordare posizioni temporanee (ad es. Assegni di
Ricerca o art.23 a seconda del livello della persona e del tipo di progetto) valutando
congiuntamente il progetto e le persone proposte per la posizione.
Dall'indagine svolta fra i gruppi ATLAS-Italia si prevede che nel 2000 si verificheranno
4 esigenze di posizioni temporanee di questo tipo, in presenza sia di progetti adatti che di
persone disponibili e preparate. Tre di queste posizioni figurano gia' nelle richieste
presentate al MURST nell'ambito del cofinanziamento INFN per il progetto PANDA, il
cui esito si dovrebbe conoscere a settembre 99; la quarta esigenza si colloca nell'ambito
dell'attivita' Lev3Trigger/EventFilter.
Queste esigenze dovrebbero essere soddisfatte entro i primi mesi del 2000 e la loro
illustrazione dettagliata si prevede di inserirla nel documento sul Calcolo Atlas-Italia
citato sopra e schedulato appunto per i primi mesi del 2000.
Ci sono poi 2 esigenze urgenti che dovrebbero essere soddisfatte prima della fine del
2000, che vengono illustrate qui con qualche dettaglio.
- Il gruppo di Milano-LARG, che prevede di impegnare circa 3 FTE sulle attivita' di
sviluppo sw OO, ha inoltre un ruolo cruciale in MONARC e nelle attivita' connesse,
tramite l'attivita' di Project Leader svolta da Laura Perini e grazie all'impegno a
tempo pieno (sopratutto nel campo delle OODB e dei relativi tests e misure di prestazioni
su rete locale ed estesa) di una persona esperta la cui posizione temporanea informaticospecifica scade a dicembre 99.
Il venire meno di questo contributo alle attivita' di MONARC avrebbe conseguenze gravi
anche sulla capacita' italiana di esercitare efficacemente un'azione di leadership sulle fasi
future del progetto e comunque di giocare un ruolo rilevante negli studi, sviluppi e
decisioni sulla preparazione del calcolo ad LHC che si svolgeranno in ogni caso nei
prossimi anni, anche indipendentemente dalla continuazione di un progetto
specifico.
- Il gruppo di Roma1 dedica circa 3.5 FTE all'attivita' di sviluppo software che riguarda
tre aspetti principali, tutti legati al muon detector:
1 - Analisi dei dati di test-beam e studi di autocalibrazione delle camere MDT.
Questa attivita' viene svolta da tempo e con notevole impegno; il livello di competenza
acquisito porta ad assumere nei confronti della collaborazione il commitment di fornire il
software di autocalibrazione per la camere MDT dell'esperimento.
2 - Simulazione del Livello1 del trigger mu (barrel).
La responsabilita' per la realizzazione dell'elettronica di trigger comporta una intensa
attivita' di studio e simulazione; il gruppo ha assunto da tempo l'incarico di sviluppare
il software di simulazione e includerlo nel framework ufficiale per permettere gli studi di
performance combinata.
3 - Algoritmi per il Livello2 del trigger mu (barrel).
Un impegno crescente e' posto nello sviluppo del patter recognition delle tracce e nella
determinazione dell'impulso dei mu; la complessita' del problema e' aumentata dalla
necessita' di mantenere una versione di simulazione nel framework generale e una
versione ottimizzata per i test di prestazioni in ambito on-line. Anche per questo item il
gruppo ha un commitment nei confronti della collaborazione.
Il manpower complessivamente dedicato a queste attivita' e' di ~3 fte (~4 nel 2000).
L'attivita' di sviluppo software e il livello di impegno verso la collaborazione sopra
delineati richiedono, specie in questa fase di migrazione del software alla nuova
architettura, l'apporto di ulteriore manpower. Per altro, il fatto che tutte le attivita' siano
portate avanti nell'ambito del muon detector permette una notevole sinergia. In tal senso
sembra opportuno poter disporre in tempi brevi di una posizione temporanea (per la quale
si e' a conoscenza di candidati dalle caratteristiche idonee) con l'intento di rafforzare la
capacita' complessiva del gruppo di gestire questa fase di transizione e mantenere gli
impegni verso la collaborazione.
2. STATO ED ESIGENZE DEL CALCOLO DI CMS ITALIA
1. Introduzione
Il calcolo (“Computing” per meglio rendere l’insieme delle problematiche che riguardano
il trattamento dei dati Off-line) per CMS ha una complessita’ che non e’ mai stata
affrontata in HEP.
Alcuni degli elementi della complessita’ sono:
La dimensione dei dati da tarttare (1Pbyte/anno di Raw data per decine di anni).
Le risorse di Computing necessarie per trattare i dati (centinaia di TeraByte di
Storage e centinaia di migliaia di SpecInt95).
La complessita’ del Rivelatore e dell’analisi dei dati che si riflettono sullo sviluppo
del Software (migliaia di anni-uomo per lo sviluppo dei codici).
La vita media del progetto (decine di anni).
La distribuzione ed il numero dei Fisici e delle Istituzioni partecipanti (migliaia di
individui in centinaia di Istituzioni sparse nel Mondo).
La distribuzione delle risorse di Calcolo e la necessita’ di “Collaborazione a
distanza”.
Queste considerazioni hanno portato a considerare il "Computing" come un
"sottorivelatore" dell'apparato e di conseguenza a sviluppare il progetto attraverso le
metodologie tipiche degli apparati sperimentali: sviluppo e studio di nuove tecniche, fasi
prototipali, attivita' di R&D, realizzazione di architetture, definizione degli scopi e
programmi di sviluppo/realizzazione anche per il reperimento delle risorse.
Una considerazione particolare riguarda il Software. CMS ha adottato l'approccio della
programmazione ad Oggetti ed il linguaggio C++. Questa scelta richiede la scrittura (che
comunque andava fatta) dei programmi per l'esperimento attraverso nuove architetture e
tools, ma anche il "recupero", insieme alla comunita' HEP, di tutte le librerie e
metodologie di Analisi comunemente usate. A cio' si aggiunge la scelta di mantenere i
dati in un DataBase a sua volta ad oggetti, database che, ad oggi (la scelta definitiva sara'
nel 2001) e' identificato in Objectivity.
2. Attivita' e persone coinvolte in CMS Italia Computing.
A parte le attivita' sul Computing Model (e piu' specificatamente sul Centro Regionale)
condotte attraverso la Collaborazione a Monarc e le attivita' connesse alla Farm Off-line
al CERN per CMS (in parte ancora connesse a Monarc ed in parte legate al Computing
Common Fund) che verranno descritte dopo, le attivita' che da oggi sono attive e che si
amplieranno nei prossimi anni sono le seguenti.
Sviluppo Software "specifico". Questa attivita' riguarda lo sviluppo del codice legato
agli apparati sperimentali e viene prevalentemente svolta nelle Sezioni INFN. Tale
attivita' comprende: a) lo sviluppo del software finalizzato alla costruzione del
detector (dal disegno dei silici, al database dei cristalli, alla simulazione del campo
nelle celle delle camere a muoni, etc.); b) la codifica software dell'apparato per la
simulazione; c) lo studio e codifica degli algoritmi legati al trigger con conseguente
analisi fisica dei segnali; d) l'architettura e la codifica della ricostruzione delle
informazioni rilevanti per l'analisi partendo dalle capacita' dei detector.
Attualmente sono impegnate circa 30 persone (non FTE) dell'INFN (staff e non,
ovvero borsisti e/o dottorandi/assegnisti) in questa attivita' che continuera' fino allo
startup di CMS ed anche oltre, anche se con minor impegno. Tutte le Sezioni sono
coinvolte con riguardo ai detector dove l'INFN ha forti responsabilita': muoni, tracker
ed Ecal.
Per questa attivita' non servono grandi mezzi di calcolo, ma risorse dedicate ad ogni
singolo sviluppatore sulla piattaforma (SUN, Linux) identica ai suoi colleghi, oltre ai
tools particolari nei desktop dedicati (distributed collaborative tools).
Sviluppo Software "centrale" (Core software). Questa attivita' riguarda lo sviluppo e
la codifica delle attivita' comuni a tutta CMS (per tutti i detector pertanto). Alcuni
esempi sono: la simulazione in Fortran (CMSIM), il software Process per lo sviluppo
ciclico, il supporto al software (gestione del codice, versioni, etc.), l'Information
System, il Framework per l'analisi e la ricostruzione, i generatori di eventi, la
simulazione in OO (OSCAR), la ricostruzione in OO (ORCA), il software per i
TestBeam, il supporto per l’ ODBMS, etc.
In questa attivita' sono coinvolte 6-7 persone provenienti da alcune Sezioni INFN
(staff e non) purtroppo spesso non a tempo pieno. CMS ha fatto un'analisi dettagliata
delle funzioni (e capacita') richieste in funzione del tempo (dal 1998 al 2006)
mostrando che gia' oggi sono necessari 21 FTE (non persone) che cresceranno a 33
FTE nel 2006.
Ad oggi c'e' gia' una mancanza di 7 FTE e l'INFN contribuisce con circa 2 FTE
rispetto ai circa 3 FTE che le competerebbero (~13/15%). Questo personale e'
fortemente specializzato e di difficile formazione e la sua attivita' si svolge
prevalentemente al CERN (occorrono mezzi dedicati quali Ws Linux o SUN).
Analisi dei dati dai Test Beam. Questa attivita' riguarda la scrittura dei codici di
rappresentazione dei setup e la loro simulazione, oltre ai programmi di analisi. A
questo si aggiunge il "porting" del data recording and analysis in OO (nel framework
generale del software di CMS su Objectivity).
In questa attivita' sono coinvolte tutte le Sezioni INFN di CMS, per un totale di circa
30 persone (non Fte) (staff e non). L'attivita' andra' calando nel tempo, mano a mano
che i detector verranno costruiti, tuttavia crescera' invece l'attivita' legata alla
comprensione degli apparati che e' la naturale evoluzione di quasta attivita'. Le
necessita' per questa attivita' sono qualche CPU dedicata e grandi quantita' di storage
per i dati reali (sia le nple che i DB in Objectivity) e simulati dell'ordine del TeraByte.
Simulazione e studio dei processi Fisici legati alla definizione del Trigger. Questa
attivita' riguarda la simulazione di eventi fisici insieme al possibile background e la
ricostruzione (in OO) degli stessi al variare degli algoritmi di trigger per valutarne
l'efficienza e la fattibilita'. L'attivita' crescera' nel tempo e diventera' sempre piu'
importante. Ad oggi sono stati formati in CMS quattro Working Groups (detti di
Fisica): Muon WG, e-gamma WG, b-tau WG, jets missing/energy WG. Chiaramente
queste simulazioni richiedono anche una profonda conoscenza dei detector e delle
loro possibilita'.
In questa attivita' sono impegnate ad oggi circa 20 persone (non Fte) divise tra alcune
Sezioni INFN con partecipanti ai WGs dei Muons e dei b-tau.
Questa attivita' richiede grandi risorse, sia di man-power che di mezzi di calcolo,
essendo la la sua importanza molto rilevante. In particolare e' necessario poter
disporre di personale aggiuntivo.
L'attivita' richiede inoltre grandi potenze di CPU (dedicate e condivise, magari
attraverso Condor) e grandi capacita' di storage dedicate per centinaia di GByte. Un
esempio per il solo WG dei muoni puo' dare la dimensione dell'impresa, considerando
che i gruppi italiani sono tra i piu' forti anche nel WG del b-tau. Per il 1999 (con una
accuratezza statistica dell'ordine del 10%) occorrono per gli studi previsti circa 120
GByte di disco e circa 150 giorni di CPU su una macchina della potenza di 10 SI95,
mentre per il 2000 i numeri equivalenti diventano circa 1 TByte di disco e circa 150
giorni di CPU su una macchina della potenza di 100 SI95.
3. Supporto necessario
Le categorie di supporto necessario all'impresa del Computing di CMS per l'INFN
possono essere schematizzate come segue.
Personale dedicato. In aggiunta alle persone con esperienza gia' coinvolte nel
Computing (e a quelle che vorranno aggregarsi) sono necessarie alcune figure
specifiche.
a) Physicist Computer Professional: Fisico esperto di computing, e' la figura che
attualmente e' cosi' scarsa nell'INFN e che in parte equivale al Fisico che si occupa a
tempo pieno di elettronica o di rivelatori. Occorre far crescere queste competenze ,
attraverso contratti temporanei adeguati e poi eventualmente mantenere stabilmente
questi "professionisti" nell'INFN.
b) Computer Professional. E' un professionista del software (laureato in Informatica,
Igegneria, Fisica) che si affianca ai Fisici per un progetto definito per un tempo di
qualche anno. La loro presenza deve essere garantita per l'arco del progetto, senza la
pretesa che queste figure rimangano nell'INFN, con contratti temporanei.
c) System Professional. E' un professionista dei Sistemi di calcolo (laureato in
Informatica, Ingegneria o Fsica) capace di gestire il software, i tools e l'hardware in
un periodo di grande variabilita' e necessita' particolari quali sono gli anni prima di
LHC e i primi di presa dati. E' necessario dove la concentrazione di attivita' e mezzi
supera la soglia della gestione personale e puo' essere condiviso con altri esperimenti,
ma non e' un tecnico saltuario. La presenza deve essere garantita per l'arco del
progetto attraverso contratti temporanei.
Hardware dedicato. Occorrono una serie diversificata di risorse che vanno dal "posto
lavoro", alle CPU e storage di riferimento per il Gruppo, alla CPU e storage per le
simulazioni, alle CPU e storage dedicate a tutto l'esperimento (vedi Centro
Regionale), alle risorse condivise dell'INFN (per es Condor).
Un discorso a parte riguarda il Network per il quale possono esserci necessita' molto
forti nella connessione al CERN ed al Centro Regionale (oltre alla necessaria
connetivita' per l'attivita' di ricerca "generale").
Software dedicato. Mentre il software specifico e' responsabilita' dell'esperimento
CMS, occorrono le licenze per i Sistemi Operativi, le licenze per i compilatori, i
compilatori stessi, i tools di sviluppo del codice, le librerie scientifiche come LHC++
(compreso Objectivity), i tools di calcolo distribuito, le applicazioni moderne di Rete
(VRVS, Web, collaborative tools, etc), per non citare l'infinita' di applicativi sul
desktop (dal virus scan a Word).
Servizi. Il supporto dai servizi risulta essenziale, specialmente quello di "alto livello".
La particolarita' di questi servizi risiede nella dinamicita' richiesta, ovvero nella
capacita' di fornire le nuove od aggiornate funzionalita' in tempi rapidi. Alcuni di
questi servizi sono: la consulenza sistemistica, il supporto di rete (locale ed estesa),
l'architettura degli applicativi client-server, i file system distribuiti (da NFS ad AFS
ad DFS), il supporto per Linux, il DNS, i Mail, i backup, le videoconferenze, il Web,
etc. Senza dimenticare la Manualistica e la Documentazione.
4. Farm Off-line al CERN
La capacita' di calcolo al CERN per CMS e' una risorsa comune a tutto CMS il cui scopo
principale e' di "ricostrurire" gli eventi la prima volta almeno (in verita' riempie il
DataBase ad Oggetti con gli oggetti ricostruiti). E' convinzione comune che la Farm Offline debba fornire anche la capacita' di analisi ad un centinaio di fisici per le analisi piu'
"hot" e per fornire il supporto a quelle attivita' che, almeno inizialmente, dovranno essere
svolte al CERN (calibrazioni, tuning, controlli etc). La configurazione e le dimensioni di
questa Farm sono parte del Computing Model di CMS e pertanto oggi legate anche a
Monarc. Un primo prototipo funzionale e' previsto per il Dicembre 2002 (Milestone di
CMS Computing) ed le prime stime di configurazione portano a dimensioni (di CPU,
storage disco e nastro, LAN, etc) almeno 100 volte superiori a quanto e' utilizzato dagli
Esprimenti correnti (e comunque almeno 40 volte superiori a quanto e' previsto dai
prossimi Esperimenti come CDF runII). L'INFN, oltre a doversi fare carico della propria
quota di partecipazione, deve anche esprimere i propri suggerimenti (almeno questo)
sulla possibile archiettura che ritiene piu' opportuna per le funzioni richieste: per fare
questo occorrono professionalita', tempo, studi e test. Naturalmente correlato a questo
argomento si colloca l'impegno CORE sul Computing Common Fund di CMS che
ammonta in totale a 500 KCHF nell'arco di 8 anni.
5. Centro Regionale e Modello di Computing (Monarc)
Il Computing di CMS e’ stato definio per la prima volta nel Computing Technical
Proposal della fine del 1996. Da allora innumerevoli studi e progressi sono stati fatti sia
nello sviluppo del Software, sia nell’Hardware, sia nelle Architetture distribuite.
Il progetto congiunto Monarc tra gli Esperimenti ad LHC (Atlas, CMS, LHCb) iniziato
alla fine del 1998 ha per scopo la definizione di possibili Modelli di Analisi dei dati
distribuiti e la loro valutazione. Le componenti principali del progetto riguardano: a) La
simulazione attraverso appositi tools dei modelli di analisi; b) La definizione delle
Architetture distribuite; c) Il disegno dei possibili modelli di analisi; d) La misura dei
parametri critici attraverso Testbed.
Molti sono i risultati ottenuti da Monarc, con la partecipazione attiva di CMS ed ATLAS,
e di particolare interesse in questo momento sono due items emersi: l’implementazione
dei Testbed con conseguente attivita’ di R&D e la definizione dei Centri Regionali di
calcolo ed analisi (architettura).
Monarc prvede due fasi, la prima conclusasi in Luglio di quest’anno e la seconda prevista
per la fine del 1999. La Collaborazione sta studiando la possibilita’ di attivare una terza
fase per l’anno 2000 tesa a fornire una base piu’ consistente per lo studio e la
prototipizzazione dei Modelli di Analisi.
Testbed. In questa attivita’ sono impegnate alcune Sezioni di CMS ed ATLAS per la
misura delle prestazioni dei database distribuiti ad oggetti. Una conseguenza
importante di questa attivita’ di R&D e’ la diffusione e crescita delle competenze
INFN in questo innovativo campo. A questo si aggiunge la effettiva sperimentazione
di collaborazione tra varie sedi con risorse comuni e coordinate. Si realizza in questo
modo una base di partenza per l’analisi distribuita con la condivisione di risorse
hardware, software, infrastrutturali ed umane, dislocate localmente: e’ un nuovo
“distributed computing” che HEP sta realizzando. Inoltre questa sperimentazione
puo’ misurare la fattibilita’ di Centri Regionali distribuiti (non troppo), ma nache
verificare le necessita’ locali e generali di coordinamento per l’accesso e l’uso
integrato di un Centro Regionale unico per CMS Italia (od eventualmente una
gerarchia di Centri di Computing, Tier1 --> Tier2).
Per questa attivita’ non sono necessarie grandi risorse hardware, ma risorse umane
competenti e software appropriato. Tuttavia sara’ presto (nel 2000) necessario passare
a prototipi di scala superiore, sulla base dell’esperienza acquisita, che richiederanno
investimenti rilevanti in hardware e network.
Centro Regionale. I Centri Regionali sono la base dell’architettura distribuita di
analisi per LHC, ed e’ una scelta dei modelli proposti da Monarc con l’accordo di
CMS (ed ATLAS). I Centri Regionali rappresentano la risorsa “nazionale” di calcolo
per l’analisi dei dati ed a questi afferiscono le attivita’ di tutta la “regione”. Pertanto
l’analisi distribuita avviene tra Centri Regionali + il CERN che risultano coordinati e
sincronizzati tra loro attraverso il Database distribuito. I Centri regionali sono una
risorsa dell’Esperimento e la loro funzione e’ coordinata nell’esperimento formando
una unica architettura integrata di Computing (Computing Model, appunto). Sulla
base di un disegno di Porcesso di Analisi ed Accesso ai Dati (proposto dallo studio
sui processi di analisi di Monarc) e’ possibile definire le funzioni e le dimensioni dei
Centri Regionali.
Si ritiene che un Centro Regionale debba essere delle dimensioni del 20% della Farm
Off-line al CERN (di ogni Esperimento) e debba fornire tutti i servizi di Analisi. Le
stime dei costi e del personale necessario alla implementazione e funzionamento
mostrano una variabilita’ in funzione dell’evoluzione della tecnologia ed ancor piu’ in
funzione delle possibili scelte di implementazione. Stime correnti sono dell’ordine
della decina di Glit e dell’ordine di 20-30 FTE di personale (all’anno) altamente
professionale. I colleghi americani di CMS hanno gia’ individuato la sede del Centro
Regionale in FERMIlab e stanno proponendo programmi e costi di implementazione
per l’approvazione ed il finanziamento.
Per cio’ che riguarda la realizzazione di un Centro Regionale italiano alcune
opzioni/possibilita’ sono attualmente oggetto di studio in CMS Italia (e Monarc): a)
Un Centro in un unico sito (eventualmente con una gerarchia di piu’ piccole
concentrazioni di risorse ad esso collegate: Tier2); b) Un Centro distribuito su tutte le
Sezioni di CMS; c) Un Centro presso i Consorzi di Calcolo; d) Un Centro realizzato
tra pochi siti principali (Sezioni piu’ coinvolte).
Preso la comunita’ CMS Italia e’ attualmente in corso uno studio per valutare le
alternative e proporre le metodologie per una scelta, con un preconcetto negativo per
l’opzione c).
Va inoltre fatto notare che una possibilita’ oggetto di discussione e’ quella di avere un
unico Centro Regionale INFN per tutto LHC.
I tempi per la decisione sul Centro Regionale sono dettati dalle milestones di CMS
che prevedono l’identificazione dei candidati per il 2000 e la prima prova di
funzionalita’ per il 2002. L’INFN deve rapidamente definire la propria strategia di
coinvolgimento operando le scelte che ritiene piu’ efficienti e fattibili per garantire la
possibilita’ di analisi dei dati di CMS alla propria comunita’ di Fisici.
6. Risorse
Le risorse necessarie al Computing di CMS per l'INFN possono essere qui riassunte sulla
base di quanto sopra esposto nella seguente lista:
Hardware (CPU, dischi, nastri, supporto)
–
–
–
–
–
Attivita' di R&D: Centro Regionale/Monarc, Sviluppo Software
Simulazioni: Working Groups di Fisica
Centro Regionale: Realizzazione
Off-line Fram al CERN
Network
–
–
"Posti lavoro"
LAN in Sede sia per attivita' di R&D che per la Simulazione
WAN per il Centro Regionale verso il CERN e verso le Sezioni ad esso connesse.
Realizzazione di connessioni di test. Wan per il supporto alla Simulazione
distribuita e lo Sviluppo.
Software (non sempre e' un mero costo, ma spesso e' anche solo un problema di
disponibilita')
–
–
–
–
Licenze "quotidiane"
Licenze del tipo di LHC++
Tools di sviluppo
Sistemi Operativi e Compilatori
Man Power
–
–
–
–
Attivita' di supporto
Attivita' di sviluppo
Attivita' di produzione
Centro Regionale
I costi di queste risorse, in funzione degli anni fino al 2006, ed in funzione delle attivita'
correnti e previste portano a stime globali dell'ordine di decine di Glit, con un'incertezza
legata alla grande variabilita' del Mercato Informatico ma ancor piu' alle scelte
Architetturali che si vanno facendo per il Computing Model. Naturalmente la
funzionalita' di tali Architetture sara' anche legata alla disponibilita' di investimenti e di
personale con competenze adeguate.
Per quanto riguarda le stime di personale coinvolto ad oggi e le necessita' di figure
professionali da affiancare nelle Sezioni all'attivita' di Computing di CMS, si e' fatta
ancora una volta l'indagine sulla base dei criteri esposti piu' sopra nei paragrafi 2 e 3.1.
Il risultato a portato ad una valutazione di
circa 15 FTE nella simulazione/ricostruzione
circa 10 FTE nello sviluppo
circa 2 FTE nel Core software
circa 8 FTE nell'analisi dei dati dai Testbeam
circa 4 FTE impegnati in Monarc e Centri Regionali
Il totale degli FTE e' in linea con la percentuale di partecipazione dell'INFN a CMS, con
eccezioni degne di nota in posizioni chiave e di spinta professionalita' (non siamo assenti,
anzi spesso trainanti, ma "sotto quota").
I desiderata delle Sezioni piu' impegnate in questa attivita' ha riscontrato la necessita' da
subito (1999) per alcuni anni (almeno fino al 2005) di alcune unita' (da 4 a 8) di figure
professionali per tutte e tre le tipologie elencate nel paragrafo 3.1 (Physicist Computer
Professional, Computer Professional, System Professional).
Alcune di queste esigenze sono urgenti in quanto riguardano figure particolarmente rare
nell’INFN, anche se negli ultimi tempi molto si e’ fatto con l’attivita’ della CNTC, le
Borse di studio Informatiche e gli “Assegni di ricerca”. In particolare nelle Sezioni piu’
impegnate in CMS si identificano da subito almeno 6 posizioni del tipo citato, anche se
reperire questo personale “professional” non e’ facile.
Per completezza va ricordato che molte Sezioni CMS hanno presentato al MURST il
progetto di cofinanziamento PANDA che, nella speranza venga approvato, potrebbe
coprire una parte considerevole delle necessarie risorse di investimento e di personale
dedicato.
7. Conclusioni
La realizzazione del Modello di CMS richiede forti investimenti per l’INFN e la
creazione di infrastrutture e personale con grande professionalita’. Da ora e’ necessario
investire in attivita’ di Ricerca/Sviluppo e sulla formazione del personale in modo da
influire sulle scelte architetturali ed essere pronti e competitivi per l’analisi dei dati di
CMS. La Collaborazione italiana ritiene che sia necessario affiancare ai Ricercatori e
Tecnologi gia’ coinvolti, anche in ruoli chiave, personale aggiuntivo al progetto, con
contratti temporanei di qualche anno. Le stime delle necessita’ in funzione degli impegni,
anche in prospettiva, portano a qualche unita’ di personale professionale all’anno che si
ritiene possa dare un contributo notevole al progetto.
CMS Italia ha deciso di perseguire la formazione di un Centro Regionale per CMS ed a
tale scopo e’ in corso uno studio per la definirne la consistenza e le caratteristiche; questo
studio verra’ discusso da CMS Italia entro il 1999. Contemporaneamente e’ in corso
all’interno della Collaborazione CMS una Review del progetto di Software&Computing,
dovuta per l’Autunno di quest’anno, anche in relazione al Technical Progress Report
(update del Computing Technical Proposal della fine del 1996) previsto come milestone
di CMS per la fine 1999 – inizio 2000.
Il CERN, di concerto con gli Esperimenti ad LHC, ha proposto un Computing
Conceptual Review a partire da Settembre 1999 per definire le architetture e gli
investimenti per il Calcolo entro la Primavera del 2000. Anche il progetto Monarc ha
come milestone la delivery dei rilultati dello studio sul Computing Model per la fine 1999
– inizio 2000, proponendo una “terza fase” per una piu’ attenta analisi prototipale durante
il 2000.
Tutte queste attivita’ sono temporalmente coincidenti, dimostrando che i tempi sono
maturi per questo progetto, e l’INFN che e’ gia’ fortemente impegnato in questo campo,
deve urgentemente intervenire fornendo chiaro supporto alle strategie di evoluzione del
Calcolo di CMS.
3. STATO ED ESIGENZE DEL CALCOLO DI CDF ITALIA
LE RICHIESTE
-------------La rete:
La banda necessaria per CDF tra l'Italia e Fermilab:
10 Mbit/sec l'anno prossimo, a crescere fino a 40-50 Mbit/sec al momento che sara’
disponibile il data set finale (circa 1PB nel 2002/3)
La banda necessaria all'interno dell'INFN:
circa 5 volte quanto necessario con gli USA, ma anche un fattor 10 sarebbe
desiderabile.
Il supporto software locale:
Soprattutto system management: linux, Root, servers SUN o SGI, SMQL
Aiuto per la importazione dell'ambiente di lavoro FNAL e la distribuzione del codice.
Piccolo costo di licenze.
Il supporto software sulla rete:
Privilegiare l'interattivo sulla rete
Supporto per controllo e monitor remoto attraverso strumenti di QO od in alternativa
links dedicati temporanei stile ISDN per videolink
Videoconferenze etc.:
Ancora codec. Serve un MCU italiano.
LO SCENARIO
-----------1) ACCESSO AI DATI
L'analisi CDF e' centrata su n-tuple (in realta' Root files) sul disco locale del PC di ogni
persona (linux). E' irrilevante se le n-tuple sono davvero files di PAW, Root, o semplici
campioni di dati ridotti per mettere a punto la selezione. Il punto importante e' che sono
files di pochi GB che permettono un veloce accesso interattivo.
Quando il tempo di processamento di un data set passa da pochi minuti a un'ora o piu',
non e' piu' importante che i dati siano locali.
Le n-tuple verranno create con job batch che girano su macchine collegate ai dischi dati
con link ad alta velocita', quindi al Fermilab dove i dati sono su SAN basata su FC, o su
nastri robotizzati su SCSI locale. In ogni caso protocollo SCSI (niente tcp/ip come con
sistemi di storage net-centrici tipo Enstore od HPSS). Le n-tuple verranno poi copiate sui
dischi locali dei PC in Italia attraverso la rete o spedite su cassetta per DHL.
Data set di uso frequente saranno replicati su disk servers locali nelle sezioni.
Immaginiamo 3 di questi servers (PI,PD,BO e.g.) con uno/due TeraBytes di disco
ognuno.
2)BISOGNI DI MASS STORAGE
CDF usera' nastri 8mm di nuova tecnologia (non i vecchi exabyte) con capacita' di circa
50-100 GB/nastro. Pianifichiamo di dotare ogni PC di un lettore, ma di non avere nessun
robot in Italia. I disk servers nelle sezioni useranno array di dischi RAID (SCSI, ma
teniamo d'occhio IDE per il prezzo) connessi su Ultra SCSI locale. Non si prevede nessun
particolare bisogno di mass storage in grandi quantita'. Probabilmente non sara' mai
necessario ne' utile avere dei robot per nastri in Italia.
3)BISOGNI DI CPU
Non abbiamo ancora un piano per il MonteCarlo. Estrapolando dal passato immagino che
quanto predisposto per l'analisi dei dati sia sufficiente anche per il MonteCarlo. Molto
MC, come in passato, verra' prodotto a Fermilab usando stavola anche la farm della
ricostruzione.
4)BISOGNI DI RETE
Bisogna poter copiare efficientemente le n-tuple sulla rete. Efficientemente vuol dire
un'ora per un file di un giga-byte, ovvero 1 Mega-bit/sec per utente. Questo non dovrebbe
essere un problema se la rete con gli USA cresce nell'immediato futuro come previsto
oggi, e se la rete italiana GARR le si adegua.
Per la rete locale l'accesso veloce tra i vari PC desktop e' importante, ma di nuovo fastethernet con 100Mbit/porta fully switched dovrebbe essere una realta' ovunque nel giro di
due anni.
5)SOFTWARE
Il codice per il Run 2 e' di fatto quasi tutto OO. C++ e' lo standard per l'offline, l'online
usa Java sulle macchine unix e C per i sistemi real-time. Una diffusione delle competeze
di software OO nelle sezioni e' la benvenuta, ma non vedo una traduzione di questo in un
esplicito supporto locale, al di la' della installazione dei compilatori. Volendo si puo'
proporre di assumere un guru OO in ogni sezione, come ha fatto Fermilab, ma mi sembra
irrealistico. L'ambiente di lavoro sara' prevalentemente linux, ma CDF supporta anche
SUN e Silicon Graphics, e questi sono i sistemi operativi preferiti per dei data servers
multi-cpu di medie dimensioni (almeno al momento attuale, ma certo con l'ingresso sul
mercato delle cpu Intel a 64bit le cose possono rapidamente cambiare in un "tutto linux").
Oltre al supporto "base" per linux, servira' aiuto dal system manager per installare e
mantenere l'evironment di lavoro clonato dal Fermilab, CDF si basa sulla replica di
"tutto" sul computer locale, non su AFS, ed alcune operazioni richiedono privilegi e/o
conoscenze da system manager.
4. STATO ED ESIGENZE DEL CALCOLO DI NA48 ITALIA
1. Introduzione
Questo documento illustra le infrastrutture e le strategie di calcolo per
l'analisi in Italia dei dati raccolti durante la presa dati 1997-2000
dell'esperimento NA48 al CERN per la misura di precisione della violazione
diretta di CP nei decadimenti dei K neutri, misura che verra eseguita
con una precisione di 2*10-4. E' stata prevista una farm nazionale
farm nazionale per permettere un'analisi il piu' possibile completa ed
indipendente, senza dover condividere le risorse di calcolo del CERN.
In questo documento verranno illustrati anche i piani e le necessita'
di calcolo per una futura espansione.
2. L' esperimento
NA48 e' un esperimento che si svolge al CERN di Ginevra. Scopo dell'esperimento
e' la misura di precisione della violazione diretta di CP nei decadimenti
dei K neutri.
La collaborazione e' composta da circa 200 persone (Italia, CERN, Francia,
Germania, Gran Bretagna, Russia, Austria, Polonia), di cui quella Italiana
costituisce circa il 35%.
La presa dati all'SPS del CERN e' iniziata nell'estate del 1997 e durera'
presumibilmente fino all'autunno del 2000.
Nel 1997 sono stati acquisiti 25TB di dati, circa 75TB nel 1998.
Nel 1999 e 2000 ci si aspetta una quantita' di dati dell` ordine dei 100TB.
3. I dati
L'esperimento NA48 si basa su un sistema software scritto in FORTRAN o C.
Tools tradizionali quali ZEBRA vengono utilizzati per la formattazione dei
dati RAW, cioe' dei dati non ricostruiti. HEPDB e' il database che
raccoglie le informazioni relative alla geometria, calibrazione del
detector, condizioni di run, etc. SHIFT viene utilizzato per lo staging su
disco/nastro dei dati e per soddisfare on-line le richieste degli utenti
per l'analisi al CERN.
Strutture C organizzano il contenuto dei dati ricostruiti, i COMPACT,
che riducono il formato RAW di un fattore 10 in termini di spazio
occupato. I GOLD COMPACT contengono invece eventi filtrati. Sono questi
ultimi i dati esportabili e disponibili per l'analisi utente finale.
Nel 1997 sono stati esportati per l'analisi in Italia 250GB di
GOLD COMPACT, nel 1998 circa 1TB. Nel 1999 e 2000 si prevede che la
quantita' di dati esportabili sia di altri 2.5TB.
Al CERN le informazioni relative ai dati vengono memorizzate in un database
basato sulla struttura a directories del filesystem UNIX.
Una serie di utilities scritte in PERL permettono l'individuazione dei dati
e la sottomissione di jobs di produzione previo staging dei dati su disco.
4. La FARM Nazionale Italiana
Per un'analisi il piu' possibile completa ed indipendente, che possa
permettere patterns anche non ufficiali senza dover condividere le risorse
di calcolo disponibili al CERN, e' stata costituita una farm nazionale
italiana nella sezione INFN di Pisa. Tale farm al momento e' capace di
gestire una quantita' di GOLD COMPACT pari a circa 1.2 TB e di fornire
adeguato spazio on-line per la produzione di n-tuple ufficiali.
La farm italiana si compone al momento di un Compaq AlphaServer 4100 con 4
CPUs 5/466 capaci ognuna di 14.1 SPECint95 and 36.1 SPECfp95 (Digital, Feb 97).
La macchina e' dotata di 1GB di RAM e serve in linea circa 660GB di spazio
disco. Una libreria magnetica ATL894 munita di 4 tape drives DLT7000, 48
slots utilizzabili per contenere dati e 4 porte per l'input delle cassette,
puo' servire in maniera automatica circa 1.5TB di dati.
La farm di NA48 viene utilizzata da circa 50 fisici delle sedi INFN di
Cagliari, Ferrara, Firenze, Perugia, Pisa, Torino.
I GOLD COMPACT vengono analizzati in modo coordinato dal programma ufficiale
(italiano) e vengono quindi prodotte delle n-tuple (~20GB per il 1997).
Tipicamente vengono eseguite 4-5 produzioni. Altre produzioni con minore
output vengono lanciate su richiesta da un utente autorizzato. Le n-tuple
ufficiali vengono lette da vari utenti per produrne di piu' piccole (o
istogrammi o files ascii). Queste ultime sono poi trasferite via rete per
l'analisi in sede.
4.1 Configurazione
Per garantire disponibilita' continua di operazioni e minimizzare le
possibili cause di interruzione, si e' cercato di creare una
configurazione per quanto possibile indipendente dalla rete e dai suoi
servizi e si sono attivati metodi di backup e ridondanza per dati
importanti. Tutto il software utile e’ quindi disponibile
localmente.
L'Andrew File System (AFS) e' installato ma oltre all'autenticazione AFS
nella cella pisana, e' permessa anche l'autenticazione locale. AFS viene
utilizzato essenzialmente per il mirroring del software e per permettere un
facile accesso ai dati personali.
Gli utenti hanno a disposizione ciascuno 100MB per le home directories e
1GB per contenere i risultati della loro analisi. Circa 250 GB sono
disponibili per le n-tuple ufficiali. Tali dati sono sottoposti a backup
automatico e anche manuale on-demand.
L' attivita' batch (NQS) e' quella principale. E' permessa, in maniera
controllata, attivita' interattiva per definire il proprio job di analisi,
per compilazione/debugging, sottomissione dei jobs e prima analisi dei
risultati.
4.2 Il Data Management
Data la difficolta' di porting su piattaforma Digital Unix e di adattamento
e configurazione del software SHIFT alle esigenze di data handling della
collaborazione italiana di NA48, si e' deciso di adottare uno Hierarchical
Storage Manger (HSM) proprietario per la gestione ed il serving automatico
dei dati. Dopo aver sperimentato il modulo HSM di Legato NSR Save e Restore
offertoci da Compaq e verificato la sua inadeguatezza alle specifiche e
il prodotto EMASS/AMASS FileServ non completamente disponibile per Digital
Unix, abbiamo optato per la scelta di UNITREE HSM e UCFM (Unitree Central
File Manager), unico disponibile sul mercato per Digital Unix e confacente
alle specifiche.
Sono stati sviluppati tools per la lettura delle cassette provenienti dal
CERN e scritte secondo lo standard per il labeling dei nastri ANSI v3.0.
Tools per l'import automatico dei dati nel filesystem UniTree sono stati
scritti in PERL.
UCFM fornisce un namespace facilmente accessibile per tutti i dati
residenti sia su disco che su nastro e un meccanismo di staging
completamente trasparente che non richiede modifiche nel codice utente.
Tale meccanismo favorisce l'accesso anche random ai dati e una loro facile
classificazione. Il database per la classificazione dei dati (DBM) e tutti
i tools per il loro browsing e per la sottomissione di jobs sono stati
parzialmente riscritti in Perl sulla base degli scripts adottati al CERN.
Sono stati sviluppati in casa anche degli scripts che, sfruttando i mezzi
offerti da UNITREE, permettono un facile recupero dei dati nel caso di
perdita di un nastro o di un disco del pool di staging.
Meccanismi che permettono l'autocleaning dei drives e il tape
consolidation, cioe' la possibilita' di ricompattare i dati su nastro,
sono anche stati implementati sfruttando quanto permesso dal prodotto.
I servizi di backup automatico non sono attualmente implementati
all'interno di UNITREE, il quale non permette una condivisione della
robotica della libreria magnetica con altre applicazioni. E' in corso una
attivita' di sviluppo con la collaborazione dei tecnici UNITREE per
permettere allo scheduler del backup di non competere con le richieste di
migrazione dei dati in e out e per la condivisione del controller della
robotica.
4.3 UniTree HSM
UniTree HSM e' un prodotto abbastanza flessibile da un punto di vista della
configurazione ed e' una discreta implementazione del IEEE Mass Storage
System Reference Model v4.0. Permette di vedere tutto il pool di dati
disponibile su disco o su nastro attraverso un filesystem UNIX-like servito
mediante NFS. Esso presenta delle caratteristiche vantaggiose come quella
di poter vedere, tramite un listing, le proprieta' di un file (size,
ownership, modification/last access/creation time, etc.), di decidere su
quale nastro o pool di nastri un file debba essere memorizzato, di
permettere prestaging manuale, di avere meccanismi automatici per il
save/restore dei database contenenti le informazioni relative ai files e ai
nastri, di recuperare abbastanza facilmente da situazioni di emergenza
marcando un disco, nastro, drive come rotti o non disponibili, etc.
L'utilizzo di UniTree ha reso abbastanza semplice il debugging di alcuni
problemi nei dati di NA48 dovuti alla loro formattazione in superfiles e ai
meccanismi di export al CERN.
La configurazione di UniTree sulla farm prevede un'area di staging su disco
di circa 200GB. Il meccanismo di "bulk migration" sveglia un demone ogni 2
ore (parametro configurabile) alla ricerca di possibili candidati da
migrare su nastro (ogni nuovo file). Quando le richieste di dati riempiono
il pool di staging per il 90% (HWM,configurabile) della sua capacita',
i dischi vengono liberati cancellando i files gia' migrati su nastro e non
acceduti fino a che lo spazio occupato non si abbassa all'87% (LWM,
configurabile) di quello disponibile. Quando un programma FORTRAN esegue
l'OPEN di un file di dati, se tale file e' disponibile su disco, l'OPEN
procede, altrimenti il programma viene messo in wait finche' l'HSM non
recupera il file dal nastro e fa lo staging completo del file su disco.
In questo momento il pattern di accesso ai dati e' controllato. Un unico
utente autorizzato lancia il programma di analisi ufficiale in batch e fa
lo scanning dei dati secondo un disegno predefinito. Si prevede di poter
cambiare questo schema in futuro.
UniTree HSM pur servendo al suo scopo ha evidenziato qualche carenza,
prima fra tutte la scarsa velocita' di accesso ai dati (superata
parzialmente con l'utilizzo della versione 2.1).
La collaborazione con gli esperti UniTree in California e il supporto sono
pero' stati ottimi fino ad oggi ed i vari problemi incontrati hanno
lentamente trovato una soluzione (anche se a volte parziale).
5. Il calcolo dopo la FARM
Le architetture supportate da NA48 sono : SUN/Solaris, HP/HP-UX, Compaq/DUX,
IBM/AIX, PC/Linux. In buona parte delle sezioni INFN in Italia parte della
collaborazione NA48 e' presente la piattaforma Compaq/DUX, mentre HP/HP-UX e'
presente a Pisa e Perugia. La piattafoma PC-Intel/Linux RedHat e' in continua
diffusione presso tutte le sezioni.
Si prevede quindi di organizzare sempre meglio il supporto per i PC/Linux
RedHat in maniera da permettere sia lo sviluppo software sia l'analisi
delle n-tuple finali su questa piattaforma.
A Pisa in particolare una connessione veloce switched a 100Mb/sec permette
sia alle macchine HP sia ai vari PCs di accedere ai dati sulla FARM.
6. Gli sviluppi futuri
Il test sui dati 98 permettera' di definire meglio il modo futuro di
impiego della farm.
Si prevede un ampliamento della robotica per accomodare l'arrivo dei nuovi
dati (2.5TB). Un probabile ampliamento della CPU e dello spazio disco
permetteranno oltre che una piu' veloce analisi dei dati un accomodamento
delle esigenze riguardanti le attivita' di simulazione e MonteCarlo. Ad
oggi non e' chiaro in quale direzione si prevede muoversi per l'ampliamento
della CPU, se verso soluzioni server o verso la formazione di farms basate
su PCs poco costose che richiedono pero' un'attenta organizzazione da un
punto di vista di gestione dei sistemi e organizzazione di accesso ai
dati. Con l'ampliamento della CPU e il passaggio a un sistema distribuito
diventa senz'altro importante l'uso di un sistema batch che offra piu'
possibilita' di quanto disponibile in NQS, per esempio uno scheduling
basato anche sulle risorse hardware disponibili o sul numero di richieste
verso l'HSM. Un possibile candidato e' sicuramente LSF e siamo abbastanza
interessati negli sviluppi condotti a FNAL per utilizzare un'unica licenza
LSF per fare lo scheduling su piu' nodi (LSF clients sviluppati in Python).
7. Le necessita'
Le necessita' avvertite dalla collaborazione italiana di NA48 per il
calcolo investono tre campi: system management e user environment,
data handling e la rete.
Per cio' che riguarda il system management e lo user environment, lo
sviluppo di tools che permetta la centralizzazione della gestione di
sistemi distribuiti quali per esempio SUE al CERN e' sicuramente un
desiderata specialmente per il previsto ampliamento della FARM con sistemi
distribuiti. In particolare, il supporto centralizzato di PCs con Linux
RedHat e' di sicuro interesse.
La distribuzione ASIS con mezzi quali quelli disponibili al CERN che
permettono la selezione dei prodotti voluti con possibile installazione
locale e' un altro elemento di interesse per NA48. La Sezione INFN di Pisa
si sta organizzando per importare i tools ASIS disponibili al CERN.
Un'integrazione di questa attivita' con quella di qualche gruppo di lavoro
INFN e' sicuramente desiderabile. Anche gli scripts HEPIX cosi'
come esportati dal CERN contengono molte peculiarita' valide solo in
quell'ambiente. Sarebbe auspicabile una maggiore integrazione con le
realta' delle sezioni INFN.
Un'altra area di interesse e' sicuramente quella del gruppo di lavoro INFN
per tools di backup. Tali tools dovrebbero essere esportabili a qualsiasi
piattaforma e magari integrabili con data managers esistenti (UniTree ?).
Anche in questo campo la collaborazione con il gruppo di lavoro per il
backup INFN e' auspicabile.
Per cio' che riguarda i sistemi batch, la collaborazione italiana NA48
intende indagare tra quelli disponibili in ambiente HEP e in particolare a
esportare quello utilizzato a FNAL per le farms di PCs tramite l'utilizzo
di LSF.
Per cio' che riguarda il data handling, al momento e' pesantemente
utilizzato il prodotto UniTree HSM v1.9.1. Tale prodotto ha mostrato delle
carenze (velocita di scrittura, retries on error nelle letture non
esistenti, backup non integrato, etc.). Queste sono state superate ma in
generale piacerebbe avere soluzioni alternative per non dipendere da un
prodotto specifico e proprietario. Si auspicherebbe quindi una
collaborazione con il CERN, per esempio nello sviluppo del progetto CASTOR
e in generale per fornire tools per il management dei nastri, la nascita di
un working group INFN e in generale una maggiore preparazione del personale
INFN incaricato di gestire questo tipo di sistemi mediante formazione,
partecipazione a workshops, conferenze, gruppi di lavoro.
Per cio' che riguarda la rete, sembra che GARR-B risponda bene alle
esigenze della collaborazione italiana di NA48 per il login interattivo, il
trasferimento dati (500-1000MB/utente ogni 4-5 giorni), mirroring del
software (pochi MB ogni 4 giorni), update del database di esperimento HEPDB
(totale di 120MB, updates incrementali di pochi kilobytes una volta al
giorno), utilizzo del WEB.
Si richiede invece piu' banda o banda dedicata per servizi quali NetMeeting
(sempre piu' diffusi sulla scrivania degli utenti) e le virtual rooms VRVS
del CERN. Si spera che sempre piu' sezioni si attrezzino con
apparecchiature ISDN/CODEC per la videoconferenza.
In termini di risorse umane, fino ad oggi e' stato utilizzato circa il
50-60% del tempo di un tecnologo per attivita' quali:
a. Copiatura dati al CERN e trasferimento a Pisa
b. Import dati sulla FARM, bookeeping e archiving
c. Manutenzione/aggiornamento sistema e HSM
d. Aggiornamento software NA48 e database
e. Sviluppo tools vari.
5. STATO ED ESIGENZE DEL CALCOLO DI COMPASS ITALIA
1. L'esperimento COMPASS
COMPASS (COmmon Muon and Proton Apparatus for Structure and Spectroscopy) e'
stato proposto nel marzo del 1996 da una vasta comunita' di fisici
interessati nello studio della struttura dei nucleoni e della spettroscopia
adronica.
Il programma di fisica richiede di accumulare una grande statistica, e cio'
ha importanti conseguenze sui rivelatori (la maggior parte dei quali sono di
tipo nuovo: RICH con fotocatodo a CsI, GEM, micromega, straw tubes), sul
DAQ, e sull'immagazzinamento e processatura e analisi dei dati.
Le rate stimate prevedono l'acquisizione di 10^4 eventi/sec, tipicamente di
30 KB ciascuno, corrispondenti ad una rate di acquisizione di 35 MB/sec, e
per un totale di 300 TB di dati per anno di misura (100 giorni di presa
dati).
L'esperimento, approvato nel febbraio 1997, e' in fase di costruzione.
L'installazione di alcune parti dell'apparato nella Hall 888 dell'SPS del
CERN e' gia' iniziata; il debugging dell'apparato iniziale avverra' a
partire dal maggio 2000 e subito dopo iniziera' la presa dati.
2. Modello di analisi
Il modello di analisi di COMPASS prevede che
- i dati sperimentali vengano immagazzinati su nastro via CDR (Central Data
Recording), e conservati al CERN; l'accesso ai dati deve essere garantito
per tutta la durata dell'esperimento;
- la processatura dei dati (produzione di DST/microDST) avvenga in "tempo
reale" (alla stessa velocita' dell'acquisizione), in parallelo alla loro
registrazione; la potenza di calcolo necessaria e' stimata essere
dell'ordine delle 20000 CU;
- la maggior parte dell'analisi fisica venga fatta a partire dai microDST o
da DST filtrati (di dimensioni non superiori a qualche TB), e sia
distribuita nei diversi Istituti della Collaborazione.
Distribuzione dei dati su diversi siti e accesso rapido e concorrenziale ai
dati RAW sono quindi punti fondamenteli sia per ridurre le necessita' di
riprocessatura, sia per garantire un uso efficiente di tutte le risorse.
Per realizzare questo modello, anche su COMPASS e' stato deciso di usare
tecniche nuove, sia hardware che software.
3. Calcolo al CERN
Per COMPASS si sta costruendo al CERN una "farm" dedicata per il calcolo
offline (la Compass Computing Farm, CCF), progettata per fornire la
capacita' di input/output per ricevere i dati dall'esperimento (CDR) e
archiviarli su nastro (HMS; al momento HPSS), e la capacita' di calcolo
necessaria alla ricostruzione degli eventi e alla gestione dei dati
(caricamento da nastro dei dati da analizzare e scrittura su nastro dei
risultati).
Il progetto della CCF (indicato come soluzione dalla "New Computing Farm
Task Force", CERN IT/PDP, nel 1998) prevede dei server centrali che
gestiscono i dati e li smistano, per le diverse fasi, a un numero elevato di
PC clienti. Si pensa di utilizzare dell'ordine di 5-7 server Unix di circa
10 TB di spazio disco (probabilmente dischi con tecnologia RAID) e un
centinaio di PC, ad es. dual Pentium II 450 MHz.
Nello schema previsto per l'analisi, i dati saranno inseriti fin dall'inizio
in una federazione di banche di dati, per permettere in ogni fase
successiva un accesso efficiente alla parte RAW degli eventi. Il database in
uso (Objectivity/DB, che e' il prodotto commerciale attualmente ritenuto
migliore per soddisfare alle esigenze degli esperimenti attuali, anche per
le caratteristiche di "scalabilita'" che dovrebbero essere inserite nelle
prossime versioni) dovrebbe permettere l'accesso remoto alle banche di
dati stesse e la duplicazione di insiemi di dati particolarmente critici,
per velocita' di accesso o importanza per una specifica analisi, su
calcolatori in rete. L'uso di Object-Oriented DataBase e' di grande
importanza per la riuscita del modello di analisi proposto, nel quale si
assume di poter utilizzare le nuove funzionalita' di I/O (in particolare il
"tagging" degli eventi in base alle loro caratteristiche "fisiche" per una
rapida selezione, l'accesso "automatico" a tutte le altre informazioni
rilevanti (nastri, files, calibrazioni, ecc., accesso remoto e
concorrenziale ai dati).
Una farm di tali dimensioni e i tools software che si intendono utilizzare
necessitano di una delicata fase di test. Un prototipo della CCF e'
funzionante al CERN dal 1998; test con dati simulati provenienti dalla zona
sperimentale sono stati gia' eseguiti e proseguiranno anche nel corso di
quest'estate.
Sinteticamente, lo schema dei test gia' eseguiti e' il seguente:
- un prototipo della farm online, situato nella zona sperimentale di
COMPASS, manda dati al computer centre via fibra (Gigabit Ethernet) in
stream multipli (circa 10), a velocita' variabile per simulare i dati veri;
- nel prototipo della CCF (costituito da una decina PC e 1 o 2 server
equipaggiati con Gigabit Ethernet), i dati vengono ricevuti dai server e
mandati a una federazione di banche dati Objectivity/DB essenzialmente
usando i PC; i database vengono quindi mandati dai server ad HPSS.
Con un server SUN 450 e' stato possibile gestire una rate fino a 7 MB/sec.
Sui PC sono stati utilizzati sia Windows NT che Linux, per confrontare i
tempi necessari a leggere gli eventi da file binari e creare un oggetto per
evento: il sistema operativo Linux e' risultato il 30% piu' veloce, fatto
che, assieme agli altri vantaggi offerti da Linux, fa pensare che questa
sara' la soluzione scelta.
I test in corso, invece, dovrebbero permettere di verificare (anche se su
scala ridotta) il funzionamento dell'intera catena di archiviazione e
processatura dei dati e di investigare la possibilta' di sostituire i
servers Unix con PC adeguati.
Per quanto riguarda il programma di ricostruzione off-line, la
Collaborazione ha a suo tempo deciso di scrivere un programma nuovo, anche
in base alle richieste di mantenimento del programma, utilizzando disegno e
architettura OO e C++ come linguaggio.
Il programma di ricostruzione deve inoltre avere una struttura "modulare",
con interfacce ben definite tra i diversi blocchi (sia software esterno che
interno al programma stesso) per permettere rapidi cambiamenti in fase di
ottimizzazione e mantenimento. Il programma di fisica diversificato
dell'esperimento richiede inoltre che il programma di ricostruzione (CORAL)
sia estremamente flessibile e possa essere adattato "facilmente" alle
necessita' che si dovranno affrontare (dal tempo di processatura disponibile
per ciascun evento, all'update di costanti di calibrazioni e allineamento).
4. Calcolo locale
4.1 Analisi dei dati
La grande quantita' di RAW data e il numero limitato di fisici italiani
partecipanti a COMPASS (al momento ci sono due Sezioni INFN coinvolte:
Torino e Trieste) sono tali da escudere la processatura completa in Italia
di una frazione significativa di RAW data.
Il lavoro off-line in Italia consistera' essenzialmente nello sviluppo e
test di nuovo software e nell'analisi fisica dei DST/microDST relativi a
misure specifiche. La possibilita' di accedere a informazioni contenute
nella parte RAW degli eventi e nei ralativi database delle "condizioni"
(calibrazioni, geometria, ecc.) e' fondamentale per aumentare l'efficienza
locale e ridurre sia le richieste di riprocessatura che le necessita' di
spazio su disco in sede.
Le funzionalita' delle banche di dati distribuite su larga scala,
costituiscono un anello fondamentale in questo schema, e il loro studio con
dati reali costituira' la prima fase dell'impegno in Sede sull'analisi (vedi
progetto PANDA, presentato al MURST nel 1999, ex-40%).
Disponendo di un sistema di gestione delle banche dati adeguato, il
lavoro di analisi potrebbe venir eseguito su una copia locale di parte dei
DST (o meglio su una loro "duplicazione logica", che garantisca la
"sincronizzabilita'" dei dati in ogni momento), accedendo via rete alle
informazioni non disponibili localmente ma necessarie per parti specifiche
dell'analisi (migrazione di banche dati dal CERN alle Sezioni coinvolte).
Analogamente, i test di software nuovo potrebbe essere fatto in sede
accedendo a campioni specifici di RAW data.
Naturalmente, essendo l'efficienza dell'accesso a banche di dati con Wide
Area Network strettamente legato alla banda garantita, un buon collegamento
con il CERN e' fondamentale. Va notato che oggi e' estremamente
difficoltoso, e per alcune applicazioni impossibile, lavorare in sede
(almeno a Trieste) proprio a causa dei problemi di collegamento
Trieste-CINECA; e' evidente che in situazioni simili il contributo del
lavoro in sede sarebbe notevolmente ridotto.
Per COMPASS si intende dotarsi in entrambe le Sezioni di una farm del tipo
CCF in scala molto ridotta, per realizzare un ambiente di lavoro in
pratica indistinguibile da quello implementato sulla CCF, e di dotarsi di
una potenza di calcolo e della capacita' di "storage" sufficienti.
In particolare, a Trieste si prevede l'installazione di un sistema iniziale
costituito da: un server Unix (ad es. Sun Enterprise 450); uno switch con
porte Gigabit Ethernet e Fast Ethernet (ad es. 3Com SuperStackII Switch
3900) per realizzare una rete locale; dischi Ultra Wide SCSI per una
capacita' di circa 400 GB; 4 o piu' PC con sistema Linux, da affiancare a
workstation esistenti; una unita' DLT, 28 cassette.
4.2 Altre attivita' di calcolo
Alle attivita' legate all'analisi di fisica dei dati, vanno aggiunte a
livello locale attivita' diverse, come l'analisi di dati di test e
monitoring relativi a rivelatori specifici (ad esempio il RICH1, interamente
finanziato dall'INFN e di cui Trieste ha la responsabilita'), e produzione
di dati MonteCarlo.
Per queste attivita', a Trieste si pensa di utilizzare per ancora un tempo
non trascurabile il cluster SUN, installato e utilizzato per l'analisi dei
dati e la produzione di MC dell'esperimento SMC; tale cluster e' stato
installato ed attualmente mantenuto ad alti livelli di efficienza grazie a
continui upgrade con sole forze interne al gruppo attualmente coinvolto su
COMPASS. Per il futuro si ritiene necessario che il cluster venga mantenuto
dal Servizio Calcolo della Sezione.
4.3 Risorse necessarie
A parte le necessita' di hardware gia' elencate, si ritiene indispensabile
sia un buon collegamento con il CERN, garantendo la necessaria larghezza di
banda, sia il supporto in termini di risorse umane.
WAN:
Nell'immediato sarebbe auspicabile il ritorno nel collegamento Trieste-CERN
a livelli confrontabili a quelli di un anno fa; al momento il collegamento
e' tale da impedire qualsiasi lavoro remoto. La situazione e' inaccettabile,
e le varie scadenze per possibili miglioramenti vengono disattese.
Dai primi mesi del 2000, la banda garantita Trieste CERN dovrebbe poter
raggiungere i 2 Mbit/sec nei periodi di punta della fase iniziale.
Necessita' analoghe ci saranno per il link Torino CERN.
Risorse umane:
Come per il cluster SUN attualmente esistente, si ritiene necessario che la
farm sia gestita e mantenuta dal locale Servizio Calcolo, sia per quanto
riguarda il software che l'hardware. In particolare si ritiene
indispensabile il supporto di esperti in gestione clusters e ottimizzazione
network, e competenti nelle nuove tecnolgie.
Supporto in sede, soprattutto a livello di consulenza, sarebbe quanto mai
auspicabile anche per disegno e architettura OO.
Altro:
Possibilita' per fisici, studenti, tecnici, di seguire corsi a vari livelli
sulle nuove tecnologie (HW e SW).
4.4 Ricadute
Questo progetto per COMPASS, come gli altri progetti nuovi proposti
recentemente, non sono privi di rischi ne' a costo zero. E' nostra
convinzione, comunque, che si debba fare il possibile per portarli a
termine, in particolare in questo periodo di rapida evoluzione, in cui i
precedenti schemi di sviluppo del software e di gestione dei dati sembrano
superati. I vantaggi derivanti dall'aumento delle conoscenze specifiche e
dalla loro diffusione sarebberero immediati per l'intera comunita'.
6. STATO ED ESIGENZE DEL CALCOLO DI ZEUS ITALIA
1. L'esperimento ZEUS
L'esperimento ZEUS, in fase di acquisizione dati dal 1992, opera al
collisionatore ep HERA a DESY, Amburgo. L'energia del fascio di protoni
e` stata Ep=820 GeV fino al 1997, ed Ep=920 GeV dal 1998. L'energia del
fascio di elettroni o positroni e` Ee=27.5 GeV.
ZEUS ha integrato una luminosita` di circa 18 pb-1 con elettroni e circa
48 pb-1 con positroni.
Il run presente terminera` nel maggio del 2000, seguito da un lungo shutdown,
circa 9 mesi, per le modifiche previste per la fase II di HERA, di alta
luminosita`. Si prevede di passare dalla attuale luminosita` istantanea
di 1.4 10^31 cm-2 s-1 a 7.5 10^31 cm-2 s-1.
2. Modello di calcolo dell'esperimento ZEUS
L'esperimento ZEUS si e` dotato di un centro di calcolo (ZARAH) ubicato a DESY.
ZARAH e` concettualmente diviso in due parti: una parte dedicata alla
ricostruzione degli eventi ed una parte riservata all'analisi.
Il confine tra le due parti e` "mobile", nel senso che, a seconda delle
esigenze del momento, una o piu` CPU di analisi possono essere trasferite alla
ricostruzione e viceversa.
Le CPU sono SGI, e vi sono due potenti sistemi di file-serving. Vi sono
in totale 44 CPU di diversa potenza (200-250 MHz) e lo spazio disco totale
ammonta a circa 2440 GB.
Sulle CPU riservate all'analisi tipicamente girano programmi fortran che
lavorano sui mini DST e producono le n-ple, che sono poi trasferite sui dischi
dei cluster remoti (sia il cluster italiano a DESY, per lo piu` work-station
alpha, che i cluster nelle sezioni) per le analisi "end-point".
Il cluster italiano a DESY consiste in 8 w/s alpha a cui si aggiungono 10 PC,
utilizzati prevalentemente come posti-lavoro, sebbene, utilizzando linux,
stia gradualmente aumentando il loro uso anche nelle fasi terminali delle
analisi (oltre che per la attivita` di produzione di documentazione).
Per i dati sono attualmente a disposizione circa 120 GB di spazio disco.
Nelle sezioni disponiamo di cluster di alpha (o di una singola w/s per le
sezioni con piccole partecipazioni) ed e` in costante aumento il numero di
PC.
Le analisi end-point sono effettuate sia utilizzando PAW che programmi
(tipicamente fortran) che lavorano sulle n-ple e vari script unix di servizio.
Per esperienza ogni analisi implica una occupazione di spazio disco di
10-15 GB (n-ple dei dati reali e dei campioni Monte-Carlo per il calcolo delle
accettanze e lo studio dei fondi).
Sulle work-station italiane, sia a DESY che nelle sezioni, girano
continuamente i programmi di simulazione Monte-Carlo.
Il modello di produzione Monte-Carlo e` basato sul sistema "funnel".
Semplificando, possiamo dire che attraverso questo sistema la produzione
e` gestita centralmente da DESY, sottomettendo i files di dati appropriati
sui cluster a DESY e nelle sedi remote (per l'Italia: Bologna, Padova, Roma e
Torino), sulla base delle richieste dei gruppi di fisica. I dati prodotti,
dopo la simulazione completa dell'apparato e la ricostruzione sono ritrasferiti
a DESY ed archiviati su supporto magnetico. I trasferimenti tra i cluster
italiani e DESY avvengono via rete.
La produzione italiana si attesta intorno al 25% della produzione totale.
Per avere un'idea, nei primi 6 mesi del 1999 sono stati trasferiti circa 900
GB di dati (prevalentemente di notte).
L'uso di afs e` in continuo aumento, specialmente per la produzione di
eseguibili locali usando librerie remote.
Un'ultima considerazione riguarda l'uso di www. Si puo` affermare che ormai
il "web" e` uno strumento fondamentale per le attivita` quotidiane di ricerca
(recupero e sottomissione di documentazione, ricerche bibliografiche, articoli
elettronici, controllo remoto dell'esperimento e monitor della qualita` dei
dati, gestione locale della posta elettronica ecc.).
3. Upgrade dei cluster
Buona parte dell'hardware e` vecchio ed in manutenzione, per cui e` necessario
procedere ad un upgrade dei cluster (cluster italiano a DESY e cluster
di Sezione).
I criteri che ci hanno guidato nella definizione dell'upgrade sono:
a) domanda sempre piu` forte di spazio disco
b) un posto lavoro (per definizione "economico") deve possedere anche risorse
sufficienti per attivita` di analisi locali
c) il posto-lavoro deve anche consentire di decentrare tutte le attivita` di
editing, di produzione di documentazione, gestione terminale di posta
elettronica ecc.)
d) la tecnologia basata su PC con s/o linux (o w/s economiche equivalenti)
sembra rispondere ai punti b) e c).
Questi punti hanno condotto alla seguente strategia:
- Dotarsi di un server sufficientemente potente per gestire lo spazio disco
e fornire la CPU necessaria per i processi piu` onerosi
- Rinnovare i posti-lavoro attraverso PC-linux o equivalenti
- Usare le w/s "vecchie" finche` funzionano, togliendole gradualmente dalla
manutenzione
4. Upgrade del calcolo centrale di ZEUS
Il sistema ZARAH si e` dimostrato eccellente. Tuttavia, per andare incontro
alle necessita` di sviluppo necessarie per la fase di alta luminosita`, e`
necessario rivolgersi a tecnologie meno costose, sia dal punto di vista
del costo per upgrade di CPU, che dei contratti di manutenzione.
Le linee che saranno seguite possono essere riassunte come segue:
a) Usare nuove tecnologie: costruzione di una infrastruttura basata su PC
b) Consolidamento del sistema di file-serving:
- tutti gli HD su un solo server
- rimozione del secondo server
- sostituzione dei vecchi dischi da 2 GB con dischi da 23/36 GB
c) Cancellazione dei contratti di manutenzione
E` gia` stato realizzato un prototipo del sistema basato su PC. Si tratta di
17 PC utilizzabili per analisi (quando non sono impegnati nella ricostruzione)
che utilizzano linux. Il sistema batch adottato e` Load Share Facility (LSF).
L'esperienza e` positiva e 60 nuovi PC sono stati ordinati recentemente.
5. Nuove tecnologie di calcolo
ZEUS e` un esperimento "maturo", basato su tecnologie di calcolo sviluppate
ormai da oltre un decennio.
I dati di ogni run sono organizzati in una serie di files (MDST), contenenti
eventi squenziali. I MDST sono inseriti in un database basato sul software
ADAMO sotto il quale opera ZEBRA per la gestione dell'I/O fortran.
In ZEUS si ritiene che l'utilizzo delle nuove tecnologie di calcolo, basate
su OO, sia tuttavia importante, sia per la gestione della seconda fase
dell'esperimento, che per dare la possibilita` ai giovani (laureandi,
dottorandi) di apprendere le nuove tecnologie sebbene nel contesto di un
esperimento avanzato.
Un primo avvicinamento a queste nuove tecnologie si e` avuto tramite la
realizzazione di un database di "tags", denominato ZES (Zeus Event Store),
basato su Objectivity (4.02).
Schematicamente, per ogni evento sono calcolate varie quantita`, dette tags,
sulle quali e` possibile operare calcoli e selezioni tramite un filtro.
Tecnicamente questa operazione di filtraggio e` effettuabile al livello delle
"control-cards" dei programmi di analisi, rendendo velocissima la selezione
degli eventi a cui si e` interessati.
Una collezione di databases definisce un database federato, i cui elementi sono
due oggetti fondamentali: l'oggetto "evento", che contiene i tags, e l'oggetto
"file" che contiene i puntatori ai MDST su cui risiede l'evento vero e proprio.
Ogni database consiste in un insieme di runs, e occupa, tipicamente, uno spazio
di 200-450 MB.
Gli sviluppi futuri di questo modello vanno nella direzione di salvare tutto
cio` che e` necessario per potere ricalcolare le variabili dell'evento senza
dovere passare attraverso la tradizionale fase di "reprocessing".
Schematicamente:
solo 1 volta
+-------------+
+--------------+
+-------------------+ richiesta | Tools
|
| DATI GLOBALI | --------> | Database Federati | <-------- | di analisi |
+--------------+
| OOmicroDST
| --------> |
|
riempimento +-------------------+ dati
| OO e vecchi |
del Database
+-------------+
La sensibilita` alle nuove tecnologie di calcolo e` molto forte in generale
nel laboratorio, e DESY ha deciso di investire in questo settore.
E` stato elaborato un progetto pilota, detto OOTWG (Object Oriented Techniques
Working Group) a cui partecipano membri di ZEUS, H1, Direttorato e Centro di
Calcolo del laboratorio.
Gli obiettivi sono:
a) sviluppo ed implementazione di un formato OO comune per ZEUS ed H1
(ispirato al lavoro di RD45 al CERN)
b) sviluppo di interfacce ai tools moderni quali LHC++, ROOT ecc.
c) sviluppo di interfacce al software fotran esistente
Si prevede pertando di muoversi dl modello attuale tipo:
+----------------------------------------------------------------------+
| I/O fortran --> ZEBRA --> ADAMO --> tools fortran di analisi --> PAW |
+----------------------------------------------------------------------+
ad un modello tipo:
+----------------------------------------------------------------------------+
|
|
|
+--- tools analisi OO
|
|
/
|
|OBJECTIVITY --> Modello ZEUS/H1 ---+
|
\
|
|
+--- interfaccia --> ADAMO --> tools |
|
analisi |
|
attuali |
+----------------------------------------------------------------------------+
|
6. Conclusioni e commenti finali
Gli upgrades sia del calcolo centrale di ZEUS che dei cluster dei gruppi
italiani (quello comune a DESY e quelli nelle Sezioni) andranno nella direzione
di utilizzare le tecnologie basate su PC o w/s equivalenti.
Per i cluster italiani e` previsto un server capace di gestire
lo spazio disco (che si prevede di raddoppiare) e dotato di CPU e RAM
sufficienti per i task piu` onerosi.
Le nuove tecnologie di calcolo, basate su OO, stanno entrando anche in ZEUS
(ed H1) e cio` permettera` ai giovani di non perdere il passo con le evoluzioni
delle tecniche off-line.
I servizi di calcolo delle Sezioni, che attualmente forniscono aiuti
fondamentali nelle gestioni dei sistemi (installazioni di hardware, upgrades
dei sistemi operativi, backup centralizzati e assistenza in genere) dovrebbero
dotarsi di personale esperto di linux e delle nuove tecnologie di calcolo.
Sottolineando i grandi meriti delle recenti iniziative prese all'interno
dell'INFN per la diffusione delle nuove tecniche tra i ricercatori, si
ritiene importante che la documentazione, anche sotto forma di tutorial,
esempi e FAQ, possa essere organizzata in modo sistematico su web.
7. STATO E NECESSITA’ DEL CALCOLO DI AMS ITALIA
AMS: volo STS-91 e Stazione Spaziale
Le sezioni INFN partecipanti ad AMS sono: Bologna, Milano, Perugia e Pisa.
In questa nota viene brevemente descritto quanto realizzato per la gestione,
archiviazione e distribuzione dei dati del volo STS-91, a livello nazionale.
Il Data Center e`stato realizzato presso la sezione INFN di Milano.
Si presentano inoltre le previsioni di massima per il Data Center per i
dati della Stazione Spaziale ISSA. L’inizio della presa dati su ISSA e`
prevista nel 2003. Va considerato che, mentre negli esperimenti da acceleratore
si ha di norma una central computing facility, negli esperimenti spaziali e`
compito dei singoli laboratori occuparsi della gestione ed archiviazione dei dati,
in particolare dei raw data. In questa nota vengono infine indicate le esigenze
del Data Center a cui vanno aggiunte le esigenze di calcolo delle singole sezioni.
Volo STS-91 (2-12 Giugno 1998)
1) Ricezione dati durante il volo
Nel 1998 abbiamo avuto un volo e quindi una presa dati della durata di 10 giorni.
Il Data Center INFN di AMS a Milano si e` organizzato per la ricezione in tempo
reale dei dati. Il flusso dei dati, provenienti da Johnson Space Center (Houston),
e` avvenuto via ALTEC-Alenia (Torino).
Il rate di trasmissione tra Shuttle e Terra e` in media di 1 Mbit/s con una
capacita` massima di 2 Mbit/s. In 10 giorni sono stati raccolti complessivamente
circa 120 Gbyte (110 dal canale HRDL e 12 dal canale SRDL + dati Shuttle).
Non tutti questi dati pero` sono stati ricevuti in real time a causa di problemi
all’apparecchiatura di trasmissione a bordo dello Shuttle.
2) Organizzazione e gestione dei dati
Il volume di dati prodotti comprende i dati raw trasmessi dallo Shuttle e i dati
ricostruiti a posteriori.
a) I dati raw comprendono gli eventi trasmessi nel canale HRDL (high rate data link),
gli House-Keeping (HK) trasmessi nel canale SRDL (slow rate data link) e i dati
ausiliari dello Shuttle (dati CAS). Complessivamente si tratta di 120
Gbyte.
b) I dati ricostruiti sono stati prodotti off-line dopo il volo. Esistono finora
tre produzioni (realizzate al CERN) relative a gradi di calibrazione progressivamente
piu` elevati. Ognuno di questi run ha prodotto circa 200 Gbyte di dati.
In questo periodo il Data Center ha organizzato i dati in modo da costituire un
archivio, totalmente accessibile via Web, con diversi gradi di organizzazione dei dati.
Parte dei dati e` stata organizzata in Data-Base in modo tale che possa essere
selezionabile in maniera molto mirata. Tutti i dati necessari sono inoltre archiviati
on-line e sono accessibili via rete file per file. Infine le produzioni precedenti di d
ati ricostruiti e i dati raw ridondanti sono archiviati off-line (su supporto magnetico).
La quantita` totale dei dati finora archiviati (piu` quelli che si completeranno nel
corso del 2000) e`:
1) Data-Base: 60 Gbyte;
2) Archivio on-line: 500 Gbyte;
3) Archivio off-line: 1 Tbyte.
Si prevede inoltre di rendere disponibile un ulteriore campione di dati ricostruiti,
contenenti solo le informazioni piu` rilevanti per analisi fisiche. Tale campione
verra` prodotto e reso accessibile non appena reperito lo spazio disco necessario.
Necessita` e sviluppi richiesti in previsione della Stazione Spaziale
International Space Station Alpha - ISSA (2003)
1) Flusso dei dati
Si puo` prevedere un rate di trasmissione dati paragonabile a quello che si e`
avuto per il volo STS-91. Ovvero dobbiamo attenderci una trasmissione media di
circa 2 Mbit/s con punte anche maggiori. Bisogna prevedere dei periodi di cattiva
trasmissione con susseguenti momenti di recupero. Pertanto e` necessario avere
una banda dedicata che possa arrivare ad almeno 4 Mbit/s.
In contemporanea alla presa dati ci sara` la produzione degli eventi ricostruiti,
che verosimilmente verra` portata avanti al CERN. Vista la mole di dati prodotti
a partire dai dati raw (rapporto 2/1) e` necessario prevedere un rate di trasferimento
doppio rispetto a quanto richiesto per i raw data. Sara` necessaria quindi una banda
di almeno 4 Mbit/s.
Infine bisogna garantire una banda sufficiente per le richieste di dati da parte
delle sezioni INFN (Bologna, Perugia e Pisa) che fanno parte della collaborazione ed
avere un margine per accessi ulteriori. Se pensiamo di voler trasmettere ad un rate di
2 Mbit/s e di voler servire almeno 2 richieste concorrenti dobbiamo prevedere una banda
ancora di almeno 4 Mbit/s. Inoltre e` necessario garantire la banda passante per le
sezioni INFN di Bologna, Perugia e Pisa.
In totale quindi occorre una banda in input/output dell’ordine di 12 Mbit/s durante
il periodo di presa dati, ovvero a partire dal 2003 e per almeno tre anni.
2) Quantita` di dati da archiviare
La durata prevista per la missione e` di almeno tre anni, durante i quali dalla Stazione
Spaziale riceveremo circa 20 GByte di dati al giorno, per un totale, su tre anni, di
circa 20 TBytes.
La quantita` di dati complessiva prodotta si puo` stimare moltiplicando per un fattore
10 questo numero, scalando in maniera conservativa quanto osservato per il campione
dati del volo STS-91. Si ottiene quindi un campione totale di 200 Tbytes, di cui circa
meta` saranno on-line.
3) Struttura del Milano Data Center
Si intende implementare una struttura simile a quella adottata per il volo STS-91; da
un lato verra` tenuto on-line il campione di dati che saranno disponibili per un accesso
diretto (es. ftp), dall’altro i dati verranno organizzati in un Data-Base relazionale,
che ne conterra` il data-catalog/inventory. Questa struttura permettera` un caricamento
in tempo quasi reale, garantendo una possibilita` di selezione mirata in breve tempo dopo
l’acquisizione del dato stesso. Un’analoga organizzazione verra` sviluppata per i dati
ricostruiti. La seguente tabella riassume tipi di implementazioni e campione di dati
relativi, dopo tre anni di presa dati (2006).
Tipo di struttura
Campione di dati
Dati RAW on-line: 20 Tbyte
Dati RAW on-line in Data Catalog DB: 10 Tbyte
Dati ricostruiti on-line: 40 Tbyte
Dati ricostruiti in Data Catalog DB: 10 Tbyte
Dati off-line: 200 Tbyte
4) Tecnologie da utilizzare
In base a quanto descritto sopra, si renderanno necessari l’utilizzo di risorse hardware
ad alta affidabilita`, lo sviluppo di strumenti di monitor e gestione automatica del
campione di dati e l’implementazione di un Data-Base relazionale ad alta efficienza per
la realizzazione dei cataloghi dei dati.
5) Gestione on-line remota dei dati
La struttura descritta permetterebbe inoltre di contribuire, da parte delle sezioni INFN,
alla gestione on-line dell’esperimento in modo remoto durante il periodo di presa dati.
8. STATO E NECESSITA’ DI CALCOLO DI ARGO
Nell’ambito dell’esperimento ARGO l’attività di acquisizione ed
immagazzimanto dati avviene localmente sul sito di Yangbajing.
I dati immagazzinati su cassette di tipo DLT vengono poi inviati
in NAPOLI dove devono essere processati e distribuiti per l’analisi
dati alle sezioni partecipanti all’esperimento.
===============================================================
=
Attualmente sul sito di YangBajing sono previsti:
- Scrittura dei Raw Data su nastri DLT (35/70GB).
- Controllo Locale dell’apparato. Attualmente non c’è modo di
effettuare monitoraggio e/o controllo remoto dell’apparato
dall’Italia.
In futuro sarebbe necessario avere le seguenti facilities sul
sito:
- Network (eventualmente via satellite) per il monitoring dello
stato dell’apparato dall’Italia con un eventuale controllo
remoto. Tale network potrebbe essere utilizzato anche in futuro
trasferimento veloce dei dati ridotti potenzialmente interessanti
evitando di dovere attendere il trasferimento fisico dei dati a
Napoli. Ciò comporterebbe il mantenimento di una parte dei dati
on-line che consentirebbe l’accesso via rete anche in vista di
possibili coincidenze in quasi real-time con altri rivelatori o
con altri esperimenti (e.g. VIRGO per la rivelazione di onde
gravitazionali)
- Implementazione di un sistema di on-line processing locale per
la riduzione e pre-analisi dati con scrittura su DST. Tale sistema
dovrebbe essere caratterizzato da una potenza di calcolo
dell’ordine dei 100GFlops.
===============================================================
=
Attualmente nella Sezione di Napoli sono previsti:
- Lettura e Processing dei dati di Yangbajing su workstation.
In futuro sarebbe necessario avere le seguenti facilities:
- Potenziamento del network per il trasferimento dati alle sezioni
afferenti all’esperimento in modo da consentire l’accesso diretto
via internet ai raw data e/o ai dati post-processati, evitando la
necessità di inviare i DST o i raw data alle sezioni che lo
richiedano.
- Sistema di processing parallelo per la riduzione ed analisi dei
dati per i diversi settori della fisica interessati con eventuale
scrittura su DST con una potenza ancora da definire ma > 100
Gflops.
Implementazione di un database locale, possibilmente in accordo a
scelte più generali dell’INFN, per la gestione dei dati processati
e per l’historical monitoring dell’apparato con una capacità di
archiviazione do dati on-line dell’ordine del TeraByte.
Valutazione della possibilità di utilizzazione di nuove tecnologie
object oriented.
Potenziamento del network e standardizzazione dei dati per una
eventuale distribuzione e scambio di dati, in particolare per
eventuali coincidenze in quasi tempo reale con altri esperimenti
dell’INFN (e.g. coincidenze di gamma ray bursts con emissione
gravitazionale).
Creazione di un’infrastruttura adeguata nella sezione di Napoli
per l’archivio fisico dei dati di ARGO (eventualmente con un robot
dedicato) ed addestramento del personale della sezione e delle
sezioni afferenti all’esperimento alla gestione di archivi,
database e alle nuove tecnologie che potrebbero essere
potenzialmente usate nell’esperimento.
9. STATO E NECESSITA DI CALCOLO DEL GR IV
Nell' ambito del gruppo IV, l' uso di strumenti ed attrezzature di
calcolo puo' essere diviso nei seguenti settori:
- funzionalita' di base.
In questo settore, che copre l' accesso alla rete, il servizio di mail etc.,
le esigenze sono essenzialmente le stesse che
per il resto dell' ente, con una importante eccezione, per quanto
riguarda la video-conference.
In quest' ambito, e' importante che i teorici, in tutte le sezioni,
possano avere accesso a servizi efficienti di video-conferenza con
due finalita' fondamentali:
- possibilita' di seguire seminari a distanza.
- possibilita' di collaborazione a distanza. A questo scopo,
in aggiunta a quanto succede in video-conferences tradizionali,
e' fondamentale poter utilizzare white-boards elettroniche di ampie
dimensioni. Esistono in commercio sistemi che offrono queste possibilita'
a prezzi ragionevolmente limitati (dell' ordine di 30 ML per istallazione).
- calcolo scientifico di medio-bassa entita'.
In questo settore, le risorse di calcolo sono basate su PC (che usano
quasi eslcusivamente Linux) o workstation Unix. La scelta tra PC personali
o workstation (o servers) di gruppo e' in genere dovuta a preferenze
personali. Un uso massiccio di questi sistemi viene fatto per problemi
di manipolazione simbolica, in genere utilizzando i due o tre programmi
commerciali ormai standard (Mathematica, Maple, MathLab). Nell'
ambito del gruppo di lavoro che si occupa di Linux, si potrebbe esaminare
la possibilita' di realizzare una distribuzione del sistema operativo
theory-oriented, che contiene questi programmi, ed eventualmente anche
le librerie NAG.
- simulazione numerica
L' attivita' di simulazione numerica di fisica statistica e di teorie
di gauge sul reticolo e' l' area di maggior utilizzo di risorse di calcolo
in ambito teorico. Possiamo distinguere tra simulazione a relativamente
basso utilizzo di calcolo (discussa in questo paragrafo) e in simulazione
"massiccia", descritta nel prossimo paragrafo e basata su APE.
Per quanto riguarda la simulazione, con calcolatori tradizionali, i fisici
del gruppo IV utilizzano workstation tradizionali e farm di PC.
Per quanto riguarda l' uso di workstation tradizionali si va diffondendo l'
uso di CONDOR, che e' visto soprattutto come un sistema di controllo di
programmi ditribuiti su varie macchine e gestiti centralmente, piuttosto
che come un sistema di recupero di cicli di CPU eventualmente persi. E'
importante che questa caratteristica di praticita' dell' uso di Condor
rimanga nell' evoluzione del progetto.
In tempi recenti, e' invece nata una attivita' pionieristica di sviluppo di
cluster di PC che vengono usati per simulazioni di media entita'. Si tratta
in genere di sistemi di PC (tipicamente bi-processore), connessi con reti
di elevate prestazioni (ad esempio Gbit ethernet). Questi cluster
usano in genere sistemi Linux (con parallel extensions) ed usano ambienti
di programmazione parallela relativamente piu' complessi che non il modello
della farm usato nell' analisi di eventi sperimentali. E" auspicabile che
l' esperienza raggiunta in questo campo possa essere messa a frutto in
tutto l' INFN.
- Il progetto APE
Le simulazioni massiccie di QCD sul reticolo sono basate in ambito INFN
essenzialmente sull' uso di APE100 e (a partire da questo autunno) di
APEmille. Questa tendenza e' iniziata intorno al 1993 ed e' previsto che
continui ancora per parecchi anni. Attualmente sono istallati sistemi
APE100 a Bari, Milano, Pisa, Roma I e Roma II, per una potenza di calcolo
integrata di circa 170 Gflops.
Nella prima meta' del 2000 i sistemi APE100 verranno sostituiti da macchine
APEmille (che sostituiranno gradualmente APE100) per una potenza di calcolo
totale di circa 1 TFlops (1000 GFlops).
Il progetto speciale APEmille sta per concludersi. Nel prossimo anno ci
si aspetta che inizi lo sviluppo di una nuova generazione di sistemi dedicati
per la fisica sul reticolo (apeNEXT). L' obbiettivo di questo progetto, che
dovrebbe essere una collaborazione europea,
e' quello di realizzare, nell'arco di tre anni, sistemi di calcolo di qualche
Tflops di potenza (con circa 1 Tbyte di memoria).
