Scaricare la presentazione
La presentazione è in caricamento. Aspetta per favore
PubblicatoVittorio Fabris Modificato 9 anni fa
1
11 Novembre 2002Laura Perini - CSN1 Perugia1 Calcolo e Software di Atlas Overview Organizzazione ATLAS Softare/Computing e ruolo INFN Data Challenges GRID e Computing Model Software (da Dario Barberis)
2
11 Novembre 2002Laura Perini - CSN1 Perugia2 Computing organization simulationreconstructiondatabasecoordinator QA groupsimulation reconstruction databaseArch. team Event filter Technical Group National Comp. Board Comp. Steering Group Physics Comp. Oversight Board Detector system
3
11 Novembre 2002Laura Perini - CSN1 Perugia3 Key ATLAS Computing bodies –Computing Oversight Board (COB): ATLAS Spokesman and Deputy, Computing Co-ordinator, Physics Co-ordinator. Role: oversight, not executive. Meets ~monthly. –Computing Steering Group (CSG): Membership first row and first column of Detector/Task Matrix, plus Data Challenge Co-ordinator, Software Controller, Chief Architect, Chair NCB, GRID Coordinator. The top executive body for ATLAS computing. Meets ~monthly. –National Computing Board (NCB): Representatives of all regions and/or funding agencies, GRID-coordinator and Atlas Management ex- officio. Responsible for all issues which bear on national resources: notably provision of resources for World Wide Computing. Meets every two months. –‘Software weekly’: weekly forum open to all ATLAS for discussion of ongoing topics: releases, computing platforms,… –‘Software workshop’: one week computing meeting open to all ATLAS, to review and discuss all aspects of computing. Four a year. –Many specific groups (e.g. Arch. Team, DataBase, Simulation, Recon., etc.) meet regularly. (between weekly and monthly)
4
11 Novembre 2002Laura Perini - CSN1 Perugia4 ATLAS Detector/Task matrix ( CSG members) F.Touchard M. Bosman V. Vercesi Event Filter A.Amorim M.Wielers Trigger/DAQ S. Tapprogge LVL2 trigger S. GoldfarbA. RimoldiJ.Shank Muon T. LeCompte A. SolodkovF. MerrittA. Solodkov Tile calorimeter Hong MaM. LeltchoukS.RajagopalanJ. Collot Liquid Argon D.FroidevauxF.LuehringD.Rousseau/ D.Barberis D. Barberis Inner Detector D.MalonA.Dell’AcquaD. RousseauN. McCubbin Chair DatabaseSimulationReconstructionOffline Coordinator S. George
5
11 Novembre 2002Laura Perini - CSN1 Perugia5 Other ATLAS key post-holders –Chief Architect: D.Quarrie (LBNL) : CSG –Physics Co-ordinator: F.Gianotti (CERN) –Software Librarian: S. O’Neale –Planning Officer: T.Wenaus (BNL/CERN): CSG –Detector Description Co-ordinator: D.Quarrie –Chair NCB: A.Putzer (Heidelberg/CERN): CSG –GRID Co-ordinator: L.Perini (Milano): CSG –Data Challenge Co-ordinator: G.Poulard (CERN): CSG –Release Co-ordinator: (rotating) D.Rousseau –Software ‘Controller’: J-F Laporte (Saclay):CSG –Quality Assurance: S.Albrand (Grenoble), P.Sherwood (UCL) –LCG PEB: G.Poulard, SC2: N.McCubbin e D.Froidevaux GDB: N.McCubbin, G.Poulard (in WG2: Resources) L.Perini (Deputy) (in WG1: GRID Middleware Selection for LCG-1)
6
11 Novembre 2002Laura Perini - CSN1 Perugia6 Organizzazione ATLAS-INFN Dalla fine del 2001 abbiamo costituto un organismo SCASI (Steering Computing and Software Atlas INFN): –L.Perini (Chair,csg,ncb), P.Bagnaia, D.Barberis(csg), A.Farilla, L.Luminari(ncb), L.Merola, L.Nisati, A.Rimoldi, V.Vercesi(csg) Coordinamento e stimolo per l’impegno dei gruppi INFN nel s/w e Computing. Utile per identificare linee di intervento e per dare maggior peso a INFN.
7
11 Novembre 2002Laura Perini - CSN1 Perugia7 Alois.Putzer@cern.ch grid tools used at 11 sites
8
11 Novembre 2002Laura Perini - CSN1 Perugia8 Legenda Figura (fino al 5%) CERN 28.6% US14.2% Germania 10.9% Giappone10.7% Francia 9.6% Italia 5.0% –CPUs Roma1 46, CNAF 40, Milano 20, Napoli 16, LNF 10=122 –122/3200< 4% Abbiamo fatto più del nostro share di CPU ma INFN è il 10% di ATLAS –Dobbiamo recuperare un fattore >2 nella CPU!
9
11 Novembre 2002Laura Perini - CSN1 Perugia9 ATLAS DC1 Phase II : Nov. 02-Mar.03 2002 –Pile-Up Production (High and Low Luminosity) About the same CPU neeed as for phase 1 70 Tbyte 100 000 files Additional countries/institutes will join –Large scale Grid test in November/December in preparation for reconstruction Reconstruction start March 2003 – using ATHENA. CPU needed 15 simulation production sites. Ideal for wider GRID use
10
11 Novembre 2002Laura Perini - CSN1 Perugia10 DC2-3-4-… DC2: Q3/2003 – Q2/2004 –Goals Full deployment of Event Data Model & Detector Description Geant4 replacing Geant3 (fully?) Pile-up in Athena Test the calibration and alignment procedures Use LCG common software Use widely GRID middleware Perform large scale physics analysis Further tests of the computing model –Scale As for DC1: ~ 10**7 fully simulated events (pileup too) DC3: Q3/2004 – Q2/2005 –Goals to be defined; Scale: 5 x DC2 DC4: Q3/2005 – Q2/2006 –Goals to be defined; Scale: 2 X DC3
11
11 Novembre 2002Laura Perini - CSN1 Perugia11 Risorse per 2003 Risorse INFN-ATLAS Tier1+Tier2 da 120 CPU’s a 300 per assicurare share 10% in DC2: –A regime ATLAS e la sua parte italiana intendono conferire tutte le loro risorse Tier1 e Tier2 a LCG, con la ovvia condizione che il buon funzionamento sia provato Per ora sono committed a LCG 50 CPU a Milano, in parte in corso di acquisto e in parte (30) conferite da Atlas, e lo share ATLAS delle 50 CPU del CNAF committed a LCG nel 2002 – Le richieste 2003 ATLAS includono 140 CPU al Tier1 Espansione CPU LCG a Milano (80 CPU disponibili per Q3-2003) –Inoltre ATLAS dispone di 46 CPU Roma1, 36 altre sedi (Napoli e LNF hanno partecipato a DC1-1 con 16 e 10 CPU rispettivamente, Pisa partecipa a DC1-2 con altre 10)
12
11 Novembre 2002Laura Perini - CSN1 Perugia12 Infrastruttura h/w ATLAS-INFN Modello di distribuzione con cui siamo partiti: –~ 60% risorse in Tier1, ~ 30% diviso equamente fra 2 Tier2, Roma1 e Milano –Motivato sopratutto da scarsità iniziale di risorse umane per il calcolo. Ma ora si sta creando maggiore disponibilità di persone, importante per gestire bene le maggiori risorse necessarie (vedi modello di CMS) –Discuteremo la candidatura di Napoli a terzo Tier2 –Roma1 e Milano restano della stessa dimensione e ruolo –Roma1 in LCG gia’ a fine 2003? –Proporremo un ruolo chiaro e attivo per i Tier3 pronti ad impegnarsi ora ( Genova, Lecce, Pavia, Pisa, e presto Roma2, Roma3) => richieste a CSN1 già in 2003
13
11 Novembre 2002Laura Perini - CSN1 Perugia13 ATLAS and GRID Atlas has already used GRID for producing DC1 simulations –Production distributed on 39 sites, GRID used for ~5% of the total amount of data by: NorduGrid (Bergen, Grendel, Ingvar, ISV, NBI, Oslo, Lund, LSCF), who produced all their data using GRID US Grid Testbed (Arlington, LBNL, Oklaoma), where GRID was used for ~10% of their DC1 share (10%=30k hours) Eu-Datagrid rerun 350 DC1 jobs (~ 10k hours) in some Tier1 prototype sites: CERN, CNAF, Lyon, RAL, Nikhef e Karlsrhue ( CrossGrid site): this last production was done in the first half of September and was made possible by the work of the Atlas- EDG task force
14
11 Novembre 2002Laura Perini - CSN1 Perugia14 ATLAS-EDG task force The Task Force, led by Oxana Smirnova, has members both from ATLAS and EDG: 40 members (!) on the mailing list, ca 10 of them working nearly full-time, Good results have been achieved: –A team of hard-working people across the Europe proved that it is possible to execute real tasks on the EDG Testbed already now –ATLAS software (release 3.2.1) is packed into relocatable RPMs, distributed and validated elsewhere –DC1 production script is “gridified”, working submission script is made –Jobs are run in the right site, correct results are stored Still work needed (in progress) for reaching sufficient stability and easiness of use –Working with 5 sites, full up time all services <30%, corresponding rate of successful jobs (when input data only at CERN 98% success!!!) –Atlas-EDG continuing till end 2002, interim report with recommendations being produced
15
11 Novembre 2002Laura Perini - CSN1 Perugia15 Plans for the near future In preparation for the reconstruction phase (spring 2003) we foresee further Grid tests in Nov/Dec. –Perform more extensive Grid tests. –Extend the EDG to more ATLAS sites, not only in Europe. –Test a basic implementation of a worldwide Grid. –Test the inter-operability between the different Grid flavors. Inter-operation = submit a job in region A, the job is run in region B if the input data are in B; the produced data are stored; the job log is made available to the submitter. The EU project DataTag has a Work Package devoted specifically to interoperation in collaboration with US IvDGL project: the results of the work of these projects is expected to be taken up by LCG (GLUE framework).
16
11 Novembre 2002Laura Perini - CSN1 Perugia16 Plans for the near future (continued) ATLAS is collaborating with DataTag-IvDGL for interoperability demonstrations in November. The DC1 data will be reconstructed (using ATHENA) early 2003: the scope and way of using Grids for distributed reconstruction will depend on the results of the tests to be done in Nov/December. –ATLAS is fully committed to LCG and to its Grid middleware selection process: our “early tester” role has been recognized to be very useful for EDG. –We are confident that it will be the same for LCG
17
11 Novembre 2002Laura Perini - CSN1 Perugia17 Long Term GRID Planning Worldwide Grid tests are essential to define in detail the ATLAS distributed Computing Model. The principles of the cost and resource sharing are described in a paper and were presented in the last ATLAS week (October) and endorsed by the ATLAS Collaboration Board. Il documento referenziato sopra è –PRINCIPLES OF COST SHARING FOR THE ATLAS OFFLINE COMPUTING RESOURCES –Prepared by: R. Jones, N. McCubbin, M. Nordberg, L. Perini, G. Poulard, and A. Putzer Nelle trasparenze seguenti (da A.Putzer CB talk) ne illustro gli aspetti piu’ importanti
18
11 Novembre 2002Laura Perini - CSN1 Perugia18 The ATLAS Offline Computing Facility (Tier1s+some Tier2s) The typical ATLAS user will copy small samples of the AOD and ESD to his/her local disk and use these data to test his/her programs. If access to more data is needed he/she will use the Grid middleware to access the Distributed Virtual Offline Computing Facility and make use of the necessary resources wherever it is most efficient. Unless very small samples of events are involved, it is envisaged that the programs will be sent to the data. A normal user will have limited access to the resources. AOD production will be done under central management, and so sudden large-scale batch processing on the ESD’s will not occur without warning and agreement. It is assumed that the synchronization of the data, the resource brokerage and the authorization handling is taken care of by the Grid middleware (possibilmente anche l’accounting fra diverse regioni)
19
11 Novembre 2002Laura Perini - CSN1 Perugia19 Resources Estimates (1) We have to consider two main areas of computing activities: – Large-scale ‘production’;e.g. reconstruction, MC sim. – Data analysis by small groups of users Contrary to the the CPU-time needed to simulate or reconstruct one event, the requirements for the user analyses can only be estimated very roughly. CPU (MSI95) Tape (PB)Disk (PB) Addition ManpowerFTE CERN (T0+T1) 0,46,70,5 Each RC0,2 0,45 `6`Ext. RC‘s 1,2 2,430 Total1,67,92,9
20
11 Novembre 2002Laura Perini - CSN1 Perugia20 Proposed Cost Sharing(1) The costs for the offline computing to be shared by the ATLAS institutes include: the ‘visible’ part of the regional facilities the networking costs (not in the budget so far) the consumables the manpower to run and maintain the centre (including Grid services) Only the CPU and data intensive part of the ATLAS offline computing, which needs to be performed at the large regional facilities, is foreseen to be covered by the resources and cost sharing.
21
11 Novembre 2002Laura Perini - CSN1 Perugia21 Proposed Cost Sharing(2) The ATLAS CERN-equivalent computing costs are roughly 15 MCHF/year [1], to be shared by the institutes, following the cost sharing principle laid out in the Maintenance & Operation MoU, in proportion to the number of their scientific staff holding PhD or equivalent qualifications (‘qualified authors’), as is the case for sharing so-called category A costs. The expected sharing between funding agencies will be presented by the ATLAS resource coordination in tables just like the other ATLAS costs.[1] [1] These costs do not include the hardware and manpower for the CERN T0/T1 that are a host- laboratory responsibility and budgeted in the CERN cost to completion Council papers. [1]
22
11 Novembre 2002Laura Perini - CSN1 Perugia22 Proposed Cost Sharing(3) Institutes can contribute in different ways to the overall costs of the ATLAS Virtual Distributed Offline Computing Facility including in-kind contributions in form of hardware, consumables and manpower in their own country at a regional facility in another country Such in-kind contributions have to be qualified by the ATLAS NCB and will be part of the ATLAS offline computing centre, i.e. rules for accessing and using these resources - by all members of the collaboration -will be defined by the ATLAS management. For the costing, it is proposed to use the equivalent cost at CERN. The NCB will annually review the contributions, and establish the credited value to the ATLAS computing costs.
23
11 Novembre 2002Laura Perini - CSN1 Perugia23 Stato e sviluppi del software di ATLAS Framework Data Base Event Data Model e Geometria Simulazione Trigger ed Event Filter Test beam e Calibrazioni Ricostruzione Data Challenges Piano di sviluppo (2003-2005) Contributo italiano
24
11 Novembre 2002Laura Perini - CSN1 Perugia24 Cenni storici e principi generali Fino al 1999, il software di ATLAS era basato su Fortran, Geant3 e Zebra: –suite completa utilizzata per preparare i TDR dei rivelatori (1996-1998) e il Physics TDR (1999) L’”Architecture Task Force” nel 1999 ha deciso che il “nuovo” software di ATLAS si sarebbe basato su: –C++ come linguaggio di programmazione –modularità degli algoritmi di simulazione e ricostruzione –separazione fra rappresentazione dei dati in memoria e su data base (intercambiabilità del data base) –separazione fra dati degli eventi e geometria dei rivelatori –separazione fra simulazione e ricostruzione Il 1º ciclo di sviluppo del “nuovo” software è quasi completo
25
11 Novembre 2002Laura Perini - CSN1 Perugia25 Framework Il framework sviluppato da ATLAS è “Athena” –basato su Gaudi (collaborazione con LHCb) Essenzialmente completo. Sviluppi recenti (e in corso) nelle seguenti aree: –Data Dictionary: ADL (ATLAS Description Language) per generare automaticamente i convertitori fra le versioni transienti e persistenti degli oggetti (LCG) –Infrastruttura per Pile-Up Lettura di eventi da vari files, “merge” degli hits –Interattività Possibilità di compilare/linkare/testare moduli applicativi
26
11 Novembre 2002Laura Perini - CSN1 Perugia26 Data Base Il data base utilizzato da ATLAS (a partire dalla fine del 2001) per gli eventi è il sistema ibrido ROOT+MySQL (LCG) –ROOT contiene i dati degli eventi –MySQL ha il catalogo –Transizione da Objectivity/DB in pochi mesi grazie alla separazione transiente/persistente alla base dell’architettura di Gaudi/Athena Classi persistenti generate automaticamente con ADL Sviluppi in corso: –Integrazione dei data base per geometria e eventi –“Conditions”: allineamenti, calibrazioni, altri dati che variano nel tempo (LCG)
27
11 Novembre 2002Laura Perini - CSN1 Perugia27 Event Data Model L’Event Data Model descrive l’organizzazione dei dati di ogni evento: –transienti (in memoria) –persistenti (nel data base) Il nuovo EDM di ATLAS è basato sulla separazione stretta fra dati dell’evento e geometria del rivelatore: –solo gli identificatori geometrici degli elementi del rivelatore sono usati per correlare i dati dell’evento con la geometria Sviluppo ancora in corso per (quasi) tutti i rivelatori –completamento previsto per inizio 2003
28
11 Novembre 2002Laura Perini - CSN1 Perugia28 Geometria Singola sorgente di dati geometrici: data base NOVA/MySQL –per il momento riempita solo da atlsim/Geant3 –letta da Geant4 e Athena Problema: i numeri non bastano per definire la geometria, ci vuole anche codice –GeoModel produce la geometria in memoria (in Athena) e la passa a Geant4 e ricostruzione così Geant4 e ricostruzione hanno la stessa geometria ma per Geant3 non c’è nulla di automatico! Infrastruttura tuttora in corso di sviluppo (LCG) Contributo italiano: geometria dei rivelatori di muoni
29
11 Novembre 2002Laura Perini - CSN1 Perugia29 Simulazione Simulazione completa con Geant4 (integrata in Athena) pronta entro la fine del 2002 Sviluppi in corso: –ottimizzazione della descrizione di ciascun rivelatore (memoria e tempo di esecuzione) –integrazione dei vari rivelatori –definizione degli hits –validazione della fisica di Geant4 Contributo italiano: –geometria dei rivelatori di muoni –infrastruttura –validazione della fisica di Geant4
30
11 Novembre 2002Laura Perini - CSN1 Perugia30 Trigger ed Event Filter Trigger di 1º livello: –trigger (simulazione dettagliata, ottimizzazione e algoritmi) High Level Triggers (2º livello ed Event Filter): –architettura (Event Filter Dataflow) –algoritmi per trigger L2 –algoritmi per trigger e E T –muoni di bassa energia (TileCal) –b-tagging on-line –utilizzo di (moduli di) programmi di ricostruzione off- line nell’Event Filter
31
11 Novembre 2002Laura Perini - CSN1 Perugia31 Test Beam e Calibrazioni I test beam dei vari rivelatori sono gli ambienti naturali dove esercitare il nuovo software: –decodifica del formato “raw data” (ByteStream) –sviluppo di algoritmi di allineamento e calibrazione –simulazioni di singoli moduli con Geant4 –validazione della fisica di Geant4 attraverso il confronto fra dati reali e simulazione Contributo italiano: –software per acquisizione, decodifica, monitoring, allineamento, calibrazione e analisi: MDT e RPC (test beam H8 e X5, test stand con cosmici) Pixel (test beam H8, irraggiamento al PS) LAr e TileCal: integrazione nel test beam combinato (“fetta” di ogni rivelatore di ATLAS)
32
11 Novembre 2002Laura Perini - CSN1 Perugia32 Ricostruzione Ricostruzione completa in Athena entro gennaio 2003 di eventi generati da atlsim/Geant3 con geometrie TDR (1997-1999) e DC1 (2002): –Inner Detector: iPatRec e xKalman++ –Calorimetri: CaloRec e JetRec –Muoni: MuonBox (F90) e Moore –Ricostruzione combinata: egammaRec, eflowRec, tauRec, MissingET, MuonIdentification, Vertexing Importante contributo italiano: ricostruzione dei muoni (Moore)
33
11 Novembre 2002Laura Perini - CSN1 Perugia33 Piano di sviluppo (1) fine 2002 – inizio 2003: –completamento del primo ciclo di sviluppo del software OO/C++: Framework Simulazione veloce Event Data Model Geometria Ricostruzione –implementazione della simulazione completa in Geant-4 e integrazione Geant4/Athena
34
11 Novembre 2002Laura Perini - CSN1 Perugia34 Piano di sviluppo (2) 2003 – 2005: –Secondo ciclo di sviluppo del software OO: consolidamento/ottimizzazione di Event Data Model e Geometria (transiente e persistente) sviluppo di procedure di allineamento e calibrazione sviluppo e integrazione del “Conditions Data Base” simulazione: ottimizzazione di Geant4 (geometria e fisica) simulazione: ottimizzazione della risposta del rivelatore integrazione on-line/off-line: software per Trigger ed Event Filter ricostruzione: sviluppo di una strategia globale basata su componenti modulari intercambiabili
35
11 Novembre 2002Laura Perini - CSN1 Perugia35 Contributo Italiano (1) Il nostro contributo allo sviluppo del software di ATLAS è coerente con: –le nostre competenze –gli impegni dei gruppi italiani nello sviluppo e la costruzione dei rivelatori Contributi all’organizzazione: –3 membri del Computing Steering Group: D. Barberis (Inner Detector Software Coordinator) L. Perini (GRID Coordinator) V. Vercesi (Physics & Event Selection Architecture Coordinator) Contributi all’infrastruttura: A. De Salvo (distribuzione di s/w per data challenges) A. Farilla (organizzazione dei Computing Workshops) Produzione per DC1: CNAF, RM1, MI, NA, GE, LNF, LE
36
11 Novembre 2002Laura Perini - CSN1 Perugia36 Contributo Italiano (2) Simulazione: test di framework, descrizioni geometriche e data base per la simulazione con Geant4: A. Rimoldi (Muon Simulation Task Leader) simulazione dei muoni (geometrie ATLAS e Test Beam) in Geant4 (PV, RM2) validazione della fisica di Geant4 (PV, GE) Trigger ed Event Filter trigger L1/L2 (RM1, NA) trigger Pixel/b-tagging L2 (GE) trigger e E T (MI, PV) muoni di bassa energia (PI) architettura Event Filter (PV)
37
11 Novembre 2002Laura Perini - CSN1 Perugia37 Contributo Italiano (3) Software connesso ai rivelatori e ricostruzione: –Inner Detector: Analisi on-line (UD) e off-line (MI) del test beam dei Pixel Digitizzazione e Clustering dei Pixel (MI) Formato ByteStream e convertitori da/a EDM off-line (UD) Ricostruzione di vertici primari e secondari (GE) –Muoni: Software per test beam e per test stand con raggi cosmici: DAQ, monitoring, analisi (RM1, RM2, RM3, NA, LE, PV) Formato ByteStream e convertitori da/a EDM off-line (RM) CALIB: programma di auto-calibrazione delle MDT (RM1, RM3, CS) MOORE: Muon Object-Oriented REconstruction (RM3, NA, LE) – A. Farilla è Coordinatore di MOORE
38
11 Novembre 2002Laura Perini - CSN1 Perugia38 Conclusioni Il software di ATLAS è in rapida evoluzione: –il gradiente è positivo Il primo ciclo di sviluppo di software OO è quasi completo –il piano di sviluppo del secondo ciclo verrà definito nei dettagli nei prossimi mesi dal nuovo Computing Coordinator Il software pervade tutto l’esperimento: –è importante avere strategie comuni online e offline –necessita una maggiore integrazione di software e anche di persone –va anche migliorato il controllo della qualità Il contributo italiano al software di ATLAS è importante: –focalizzato nei settori di nostra competenza –riconosciuto dalla collaborazione con nomine a rilevanti responsabilità organizzative
Presentazioni simili
© 2024 SlidePlayer.it Inc.
All rights reserved.