Attività di calcolo ALICE/Bari Visita Referaggio TIER2-Bari 24 Gennaio 2006 D. Di Bari Dipartimento IA di fisica “M. Merlin” e sez. INFN - Bari.

Presentazione sul tema: "Attività di calcolo ALICE/Bari Visita Referaggio TIER2-Bari 24 Gennaio 2006 D. Di Bari Dipartimento IA di fisica “M. Merlin” e sez. INFN - Bari."— Transcript della presentazione:

1 Attività di calcolo ALICE/Bari Visita Referaggio TIER2-Bari 24 Gennaio 2006 D. Di Bari Dipartimento IA di fisica “M. Merlin” e sez. INFN - Bari

2 2 Sommario Il gruppo ALICE-Bari Attività di calcolo svolta in passato e competenze acquisite Modello di calcolo dell'esperimento e ruolo dei centri Tier 2 per ALICE Attività di ricerca riguardante gli aspetti di gestione della farm

3 Il Gruppo Alice-Bari Attività scientifica nella fisica degli Ioni Pesanti dagli anni ’80 (WA85,WA94,WA97,NA57) Coinvolgimento costante nelle attività di calcolo Produzione di eventi da Raw Data  DST Analisi svolta dei segnali di fisica Produzione di particelle strane e multistrane Produzione di mesoni (carichi e neutri) Rapporti di produzione Confronti con MonteCarli Partecipazione all’esperimento ALICE

4 ALICE Bari  ALICE – PIXEL (12.1 FTE)( Bari, Bratislava, Catania, CERN, Kosice, LNL, Padova, Salerno, Udine )  Rivelazione di particelle prodotte nell’interazione primaria mediante layer di rivelatori al silicio bidimensionali (ITS)  ALICE – HMPID ( 13.7 FTE ) (Bari, Cern)  Identificazione di particelle cariche ad alto p T ( ,k,p) nella regione centrale di rapidità mediante un rivelatore Cerenkov ad immagini anulari Silicon Pixel Detector muon arm side HMPID

5 ALICE Bari: responsabilità  ALICE – PIXEL Resp. locale Alice-Pixel (VM) Resp. costruzione moduli PIXEL (VM) Coordinamento Nazionale ALICE-PIXEL (VM) Resp. risposta del rivelatore Pixel in AliRoot (GB) Responsabile DCS Pixel (D. Elia)  ALICE – HMPID Project leader HMPID (EN) Resp. locale Alice-Hmpid (DDB) Resp. offline-board di Alice-Hmpid (DDB) Conveenor della sez. “jet-quenching” (DDB fino 2004) Resp. analisi HMPID (DDB) Resp. DCS HMPID (GDC) (ECS) Alice Pixel

6 Alice-Pixel: calcolo  Database di Costruzione: http://pcal04.ba.infn.it  Attività di DCS per SPD  Modello di risposta del rivelatore I risultati dell’analisi dati dei test beam sono stati confrontati con i due modelli di risposta integrati in AliRoot: a)Modello puramente geometrico b)Modello geometrico con l’aggiunta del meccanismo di diffusione della carica di ionizzazione prodotta  Studi di fisica: Produzione di open charm e beauty: Sviluppo di algoritmi per la determinazione dei vertici secondari a 3 o più corpi degli adroni con carica netta di charm o beauty nel contesto ad alta molteplicità tipico delle interazioni Pb-Pb ad LHC Produzione pilota di 100 eventi simulati in ambiente AliRoot per lo studio del decadimento D+  K -  +  + in eventi centrali Pb-Pb (produzione in corso con l’ausilio dl calcolo distribuito)  Molteplicità di particelle cariche Lo studio della molteplicità consente una caratterizzazione del mezzo prodotto nella collisione essendo connessa alla densità di energia ottenuta nella collisione Studio e confronto della molteplicità in collisioni p-p, p-A e A-A.

7 Alice-Hmpid: calcolo  Database di Costruzione e di allineamento  Attività di DCS per HMPID in fase avanzata (ECS)  produzione per il PPR finita con risultati ormai pubblicati  Identificazione di particelle cariche ( ,K,p)  Analisi di eventi ad alta molteplicità Pb-Pb e pp  Track matching  Efficienza e contaminazione  Algoritmi di “combined PID” introdotti  Processati 1000 eventi eventi centrali Hijing Pb-Pb a  sNN = 5.5 TeVin sede (1 TB) completamente ricostruiti  Processati 1000 eventi eventi centrali Hijing Pb-Pb a  sNN = 5.5 TeV in sede (1 TB) completamente ricostruiti  Segnali di fisica  rapporto K/p e  p/p vs. p T  Identificazione  (1020) →K + K - tramite identificazione mesoni  Processati 3 10 5 eventi centrali Hijing Pb-Pb a  sNN = 5.5 TeV (fast simulation)  Processati 3 10 5 eventi centrali Hijing Pb-Pb a  sNN = 5.5 TeV in sede (fast simulation)  VHMPID per  p/p per 10 < p T < 15 GeV/c  ALICE-RICH in STAR al BNL

8 Calcolo futuro per ALICE ALICE-Pixel Studio del decadimento D + → K - π + π + generazione (PYTHIA) di eventi con D + → K - π + π + ~ 9000 mesoni D per evento(|y| < 2) ottimizzazione algoritmo di vertice secondario Produzione di almeno 10K eventi Pb-Pb (corrispondenti a circa 10 8 collisioni centrali Pb-Pb) ~ 1,5 GB/evento per 15 TB di spazio disco ALICE-Hmpid  (1020) →K + K - Completamento studio  (1020) →K + K - (10 3 eventi,1TB) studio efficienza e contaminazione Effetti sistematici (accettanza) (10 3  10 4 eventi,1  5 TB) VHMPID (~ 10 3 eventi)

9 9 Modello di Calcolo di ALICE: ruolo dei Tier 2 Generare con tecniche MC l'analogo dei “RAW Data” ed effettuare la ricostruzione sie di essi che dei RAW reali, producendo gli “ESD” Effettuare analisi “caotica” dei dati ricostruiti rispondendo alle esigenze dei singoli gruppi di ricerca (iniziative autonome rispetto ai piani della collaborazione) Fornire area di storage a breve termine con accesso veloce a copie multiple di una parte dei dati grezzi e ricostruiti

10 10 Attività di calcolo di Alice-Bari (i) 2002 primi esperimenti con grid testbed Risorse limitate (3 macchine e 1 disk server) partecipazione a sessioni di produzione distribuita di eventi MC utili per preparare il PPR di ALICE Sperimentati due testbed: AliEn (sviluppato internamente alla collaborazione ALICE) e INFN-Grid 2003 Approfondimento delle metodologie di gestione di macchine in cluster e di integrazione di farm locali in testbed di griglia (tuning S.O., Distributed Filesystem, network layout, etc.) Utilizzo delle (poche) risorse disponibili per la partecipazione a stress-test della rete GARR Risorse identificate come “Tier 3” N.B. Sin dall’inizio sinergia con il gruppo di Giorgio per risolvere problemi inerenti la sperimentazione

11 11 GARR Network Stress Test Tier1@CNAF 105.6 M Tier2@Torino 84.0 M Tier2@Catania 28.8 M Tier3@BARI 160 K

12 12 Attività di calcolo di Alice-Bari (ii) 2004 Disk Server (0.7 TiByte) 3 nodi di calcolo double Xeon 1.8 GhZ UPS configurato per shutdown automatici Configurazione su rete privata con nodo di front- end pubblico Integrazione (per quanto possibile) con vecchie macchine Abbastanza risorse per partecipare al Physycs Data Challenge 2004 svolgendo il ruolo di un centro Tier 2

13 13 Cluster di Bari nel 2004 alicegrid3 (front-end + SE ) NFS+private

14 14 Attività di calcolo di Alice-Bari (ii) Physics Data Challenge 2004 Verifica del modello di computing basato sull’uso di GRID  Simulazione ed analisi del 10% dei dati stimati in un tipico anno di presa-dati di ALICE Svolgimento in tre fasi:  Fase I: produzione eventi di fondo  Fase II: eventi di segnale, merging e ricostruzione  Fase III: analisi dati con infrastruttura grid (Utilizzo di tre testbed : AliEn, LCG, Grid.it) Contributo di Bari Utilizzo di risorse integrate nel testbed AliEn 10 CPU a Bari su un totale di 3500 disponibili nei 3 testbed (0.3%) Coordinamento a livello di collaborazione: scambio di informazioni per rendere efficienti le configurazioni delle farm Acquisiti Know-How ed esperienza nella gestione di cluster di calcolo per svolgere High Troughput Computing

15 15 PDC'04: Risultati Fase 1 BARI 235 job su 56000 (0.42%) Efficienza superiore alla media con sole 10 CPU!

16 16 PDC'04: Risultati Fase 2 2 Testbed 5M eventi prodott i BARI 1620 job su 180000 (0.9%) Nessun probl. di configuraz. Efficienza maggiore

17 17 Attività di calcolo di Alice-Bari (iii)  2004-2005  Sinergia con altri esp. (FINUDA) per condivisione risorse  Acquisto di nuove macchine:  5 biprocessori Xeon 2.4 GhZ (ALICE)  2 Disk Server (Storage totale: 3 TiByte)  3 biprocessori Xeon 2.8 GhZ (FINUDA)  1 Disk Server (1.5 TiByte)  Configurazione in spazio di indirizzi pvt  3 macchine di Front-End per bilanciare il carico.  Configurazione Job Manager replicata su 3 nodi per minimizzare eventuali downtime  Sperimentazione del tool di inst./conf. automatica QUATTOR  Sperimentazione e test del sistema di storage distribuito dCache ( http://dcache.org ) http://dcache.org  Sviluppo di componenti per l'integrazione di dCache nel nuovo middleware gLite (Ing. Nicolò Fioretti)  Attività sperimentali svolte su macchine non “in produzione”  Uso farm in locale: esperienza e Know-How per poter fornire servizio sempre + affidabile

18 Può gestire il trasferimento e lo storage di centinaia di TByte di dati I dati possono essere distribuiti su un gran numero di disk server (Pool) Lo spazio di storage aggregato viene visto con un filesystem unico e un namespace uniforme Supporto della gestione delle repliche dei file Punti di accesso distribuiti (Door) Load balancing automatico dei trasferimenti fra pool mediante metriche di costo Connettività modulare verso i sistemi HSM (Hierarchical Storage Management) Migrazione/ripristino automatica dei file verso/da HSM Interfaccia di amministrazione su protocollo SSH standard Interfaccia WEB di monitoring (es: http://alicegrid4.ba.infn.it:2288/)http://alicegrid4.ba.infn.it:2288/ Accesso ai file con libreria dCap (dCache Access Protocol) Il Mass Storage System dCache

19 Progettazione e realizzazione a Bari (lavoro di tesi) di una architettura software che risolve il problema della pubblicazione delle informazioni dinamiche degli Storage Element sull’Information Service di Grid: InfoCollector- InfoProvider. InfoCollector: Componente integrata in modo specifico nello Storage Element per recuperare le informazioni di stato in tempo reale “dall’interno” del sistema. InfoProvider: Componente che importa le informazioni dalla componente InfoCollector in modo uniforme (via TCP) e le pubblica sull’Information Service di Grid. Pieno supporto del modello informativo Glue Schema 1.2. Informazioni dinamiche distinte per le Storage Area delle diverse VO (proprietà dello spazio): di ogni VO è noto quanto spazio ha usato e quanto ne ha a disposizione. Monitoring delle singole istanze di protocolli di accesso e di controllo. Architettura InfoCollector-InfoProvider

20 Installazione locale di dCache 1.6.6

21 21 2005: LCG Service Challenge 3 ed ALICE PDC '05 Fase preparatoria: Giugno-Luglio Service Phase: Settembre-Dicembre Verifica di tutti gli use cases offline eccetto l'analisi Stabilire quali servizi i T2 devono offrire/richiedere Accanto ai servizi di base (MW ufficiale) "agents" e "daemons" da rendere disponibili in ogni sito tramite un nodo dedicato, la cosiddetta VO-BOX Test di storage distribuito SRM enabled ALICE ha svolto il proprio Physics Data Challenge 2005 nell'ambito di SC3 usando i T2 per simulare produzione di eventi MC centrali e memorizzarli sugli SE dei T2, registrando i file sul proprio catalogo centrale

22 22 LCG SC3: Contributo di ALICE/Bari Installazione di un nodo con funzioni di VO-BOX (alicegrid6.ba.infn.it) installazione completa di una UI LCG risoluzione problemi di accesso da parte dei ruoli della VO (production manager, gsissh, etc.) installazione di tool per il discovery delle informazioni relative alla specifica VO integrazione con risorse di storage di LCG/Bari Assistenza nelle fasi di installazione sulla VO-BOX degli agents e dei servizi specifici dell'esperimento Test di utilizzo dei canali FTS tra Bari e CNAF tramite realizzazione di script in perl (Per il PDC'04 si era usato un trasferimento basato su 'aiod')

23 23 Statistiche SC3 Ottobre-Dicembre 22500 job completati (Pb+Pb e p+p) (8h/ev) Output totale: 20 TB (90% CASTOR2, 10% sugli SE dei siti) 22 centri partecipanti: 4 T1's: CERN, CNAF, GridKa, CCIN2P3 18 T2's: Bari (I), Torino (I), Clermont (FR), GSI (D), Houston (USA), ITEP (RUS), JINR (RUS), KNU (UKR), Muenster (D), NIHAM (RO), OSC (USA), PNPI (RUS), SPbSU (RUS), Prague (CZ), RMKI (HU), SARA (NL), Sejong (SK), UiB (NO)

24 24 Statistiche SC3: job conclusi T1's: CERN: 19%, CNAF: 17%, GridKa: 31%, CCIN2P3: 22% T2's: 11% di job “DONE” in totale problema nell'installazione degli agents sulle VO-BOX legati a problemi di sottoutilizzo delle risorse dovuti al ritardo con cui Bari ha iniziato a ricevere job (inizi di dicembre) precedenza al running dei job su risorse T1 piuttosto che sui T2

25 25 SC3: job running 7-8 Dicembre (Monitorng by MonaLisa)

26 26 Statistiche SC3: utilizzo CPU Valori riferiti a 15 siti (80% T1, 20%T2) T1's: CERN: 8%, CCIN2P3: 12%, CNAF: 20%, GridKA: 41% T2's: Bari: 0.5%, GSI: 2%, Houston: 2%, Muenster: 3.5%, NIHAM: 1%, OSC: 2.5%, Prague: 4%, Torino: 2%, ITEP: 1%, SARA: 0.1%, Clermont: 0.5% ------------------- NB - comunità di riferimento: per es., Salerno può essere interessato ad afferire a Bari per il proprio calcolo (fine)

27 Slides di riserva

28 28 Cluster “minimale” alicegrid2 (front-end+SE) NFS+private Test e attività di “learning” svolti con 2 sole macchine

29 Deployment tipico di dCache Figura disponibile nella sezione di documentazione del sito ufficiale di dCache : http://www.dcache.org/ manuals/dcache.nicolo. overview.jpg

30 dCache 1.6.6 sarà utilizzato per il SC4 dalla maggior parte dei centri Tier1: TRIUMF Canada, CC-IN2P3 France, GridKA Germany, NIKHEF/SARA Netherlands, RAL UK, BNL USA, FNAL USA (Jamie Shiers, 12 ottobre 2005, LCG). Le librerie dCap sono includono la libreria CERN GFAL (Grid File Access Library) Supporto di SSL, meccanismi di sicurezza GSI (Grid Security Infrastructure), Kerberos, HTTP/S Supporto di SRM 1.7 (~ 2) e gsiFTP Fino alla versione 1.6.5 non era disponibile la funzionalità GRIS (Grid Resource Information Service). Erano utilizzati i metadati di SRM per aggirare il problema: incompleto ed inefficiente. dCache come Storage Element LCG

31 Integrazione in dCache delle componenti InfoProvider-InfoCollector (su CVS a DESY) in collaborazione con DESY-IT, in particolare con Patrick Fuhrmann (responsabile e sviluppatore dCache). Contatti con Laurence Field per l’uso (e il miglioramento) del sistema GIP (Generic Information Provider).  L’ 8 novembre 2005 è stato rilasciato dCache 1.6.6 (ultima versione ufficiale) che comprende il sistema InfoProvider.  L’InfoProvider farà parte di LCG 2.7.0 (prossima versione) per il middleware dello SE dCache (con procedura di configurazione automatica).  Possibile utilizzo della stessa architettura anche per altri SE (come DPM). Collaborazioni e distribuzione

32 Deployment di dCache InfoProvider