Analisi dati nell’esperimento LHCb

1. Analisi dati nell’esperimento LHCb CSN1, 16/5/06 U. Marconi, INFN Bologna

2. Flusso dei dati in LHCb Rivelazione (40 MHz) Trigger (2 kHz) Monte Carlo RAW 60 MB/s RAW 10 MB/s rDST (B esclusivi) 25KB/evt Ricostruzione Ricostruzione e preselezione sono gestite centralmente rDST Preselezione DST, TAG Ridurre la taglia dei campioni a livello di 106÷ 107 eventi per ogni tipologia prevista Analisi utente ntuple

3. Modello di calcolo DST x 7 Analisi dei dati al Tier1 DST replicati in ciascun Tier1

4. Tier1 e Tier2 al CNAF 1° anno di presa dati Risorse di calcolo di LHCb Tier2 15% delle risorse LHCb al CNAF Tier1 1/6 delle risorse LHCb al CNAF LHCb Computing TDR, CERN/LHCC 2005-019

5. Scenario di analisi • 5105 job di analisi all’anno, corrispondenti a 103 job concorrenti al giorno, della durata media di 3 ore ciascuno. • LHCb ha raggiunto picchi di 5500 job attivi simultaneamente su LCG, con 3000 job attivi in media durante i periodi di produzione Monte Carlo. • Risorse dedicate all’analisi: • ~ 20% delle risorse di CPU. • ~ 10% delle risorse di disco. • Parametri di riferimento: • 25% della collaborazione attiva nell’analisi. • 80% dell’analisi su campioni di 106 eventi. • 20% dell’analisi su campioni di 107 eventi. • Dimensione di un evento DST+RAW: ~(100 + 25) kB. • Tempo di calcolo per job di analisi 0.3 kSI2k·s/evento,

6. Modello di analisi (1/2) • Al momento l’orientamento della collaborazione sarebbe quello di non sottoporre le richieste di esecuzione di job di analisi direttamente a LCG. • I job di analisi debbono essere sottoposti ad una sistema di gestione delle richieste della collaborazione (DIRAC). Da questo i job sono poi inviati alla Grid mediante il WMS di LCG. • I job di ciascun utente vanno in esecuzione secondo l’ordine di inserimento nella coda di DIRAC e secondo priorità determinate. • Le priorità e le eventuali restrizioni relative a ciascuna richiesta di esecuzione di job di analisi sono gestite dalla collaborazione all’interno di questo modello.

7. Modello di analisi (2/2) • L’utente invia il job di analisi a DIRAC • DIRAC produce un Pilot Agent come job di LCG. • Il Pilot Agent raggiunto il Worker Node, effettuati tutti i controlli del caso, recupera un job di analisi dalla task queue di DIRAC. • Lo stato di esecuzione del job può essere seguito sia mediante il WMS, sia mediante DIRAC stesso. • Per recuperare l’output ci sono due tecniche: • File di piccole dimensioni tornano indietro mediante il WMS come sandboxes. • Altrimenti essi sono trasmessi dal job verso gli Storage Element.

8. DIRACper la sottoposizione dei job Job di analisi from DIRAC.Client.Dirac import * dirac = Dirac() job = Job() job.setApplication('DaVinci', 'v12r15') job.setInputSandbox(['DaVinci.opts', 'lib ']) job.setInputData(['/lhcb/production/DC04/v2/DST/ 00000742_00003493_10.dst']) job.setOutputSandbox(['DVNtuples.root', 'DaVinci_v12r15.log']) jobid = dirac.submit(job,verbose=1) print "Job ID = ",jobid DIRAC Python script

9. Interfaccia utente per l’analisi(Ganga) http://ganga.web.cern.ch/ganga Codice Python ~20k linee di codice Dataset Application Job definition Backend Job submission Job monitoringand output retrieval Job cancellation

10. Test di analisi distribuita Test di analisi distribuita sono in corso da alcuni mesi http://lhcb01.pic.es/DIRAC/Monitoring/Analysis/

11. LHCb DIRAC Monitoring

12. Risultati (1/3) Tier1 site • Analisi distribuita realizzata utilizzando il sistema DIRAC-LCG. L’efficienza è del 95%. • Errori dovuti ad inconsistenze nei cataloghi. • Sottoposizione diretta dei job di analisi alla Grid, senza restrizioni sui centri di calcolo. L’efficienza è del 50%. • Sottoposizione diretta ai soli Tier1. L’efficienza è del 91%. Piccole differenze con il caso DIRAC-LCG sono dovute alla sottoposizione ripetuta in caso di insuccesso.

13. Risultati (2/3) • Sistema di analisi DIRAC-LCG utilizzando solo Tier1. • Un sito Tier1 con problemi allo SE. • 75% di successi al primo tentativo di sottoposizione. • 95% di successi eliminando il Tier1 non operativo e riprovando.

14. Risultati (3/3) • Analisi su un campione di 5 Meventi. Tempo di attesa per l’invio dei job di analisi Tempo di recupero dell’output 90% entro 3 ore 95% entro 4 ore 100% entro 10 ore Problemi di accesso ai dati al Tier1

15. Contributi INFN • Sviluppo del software di esperimento. • Realizzazione dell’interfaccia per l’invio dei job di analisi al RB di LCG. • Implementazione del meccanismo di policy enforcement per la sottoposizione dei job. • Librerie per il Data Management. • Attività di interesse generale in collaborazione con il Tier-1 • Collaudo delle soluzioni per lo storage e collaudo delle SRM. • Workshop sullo storage al CNAF https://grid-it.cnaf.infn.it/cdsagenda/fullAgenda.php?ida=a068 sommario disponibile a http://grid-it.cnaf.infn.it/cdsagenda/askArchive.php?base=agenda&categ=a068&id=a068s8t1/document (per accedere al sommario, user: guest, password: susy)" • Replica dei cataloghi al Tier1 mediante Oracle Data Base. • Controllo remoto dei server di calcolo mediante IPMI. • Soluzioni per High Availability.

16. Conclusioni • Le esigenze di LHCb sul fronte dell’analisi sono sostanzialmente chiare. • Il software per la gestione dell’analisi distribuita è già oggi piuttosto evoluto. • L’accesso dei job ai dati è questione delicata. È previsto avere i dati stripped su disco al Tier1: la selezione della preselezione consente di avere campioni di taglia contenuta. • Il personale INFN dedicato a LHCb è impiegato efficacemente, sia nella integrazione del software LCG sia a supporto delle attività di interesse generale presso il CNAF. • Il CNAF per LHCb è fondamentale • Ospiterà sia il centro Tier1 sia le risorse di calcolo Tier2. • Il CNAF ha sviluppato buone competenze tecniche e ha compiuto evidenti progressi. Difetta ancora gravemente di mano d'opera, e necessita di migliore organizzazione delle risorse umane. Manca personale di esperienza qualificato nella gestione del lavoro.