11 Novembre 2002Laura Perini - CSN1 Perugia1 Calcolo e Software di Atlas Overview Organizzazione...

11 Novembre 2002 Laura Perini - CSN1 Perugia 1

Calcolo e Software di AtlasOverview

Organizzazione ATLAS Softare/Computing e ruolo INFN

Data Challenges

GRID e Computing Model

Software (da Dario Barberis)


Computing organization

simulation reconstruction database coordinator

QA group simulation reconstruction database Arch. team

Event filter

Technical Group

National Comp. Board

Comp. Steering Group Physics

Comp. Oversight Board

Detector system


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)


ATLAS Detector/Task matrix ( CSG members)

F.TouchardM. BosmanV. VercesiEvent Filter

A.AmorimM.Wielers

Trigger/DAQ

S. TapproggeLVL2 trigger

S. GoldfarbA. RimoldiJ.ShankJ.ShankMuon

T. LeCompteA. SolodkovF. MerrittA. SolodkovTile calorimeter

Hong MaM. LeltchoukS.RajagopalanJ. CollotLiquid Argon

D.FroidevauxF.LuehringD.Rousseau/ D.Barberis

D. BarberisInner Detector

D.MalonA.Dell’AcquaD. RousseauN. McCubbinChair

DatabaseSimulationReconstructionOffline Coordinator

S. George


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)


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.


[email protected]

grid tools used at 11 sites


Legenda Figura (fino al 5%)

• CERN 28.6%• US 14.2%• Germania 10.9%• Giappone 10.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!


ATLAS DC1 Phase II : Nov. 02-Mar.03ATLAS 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 <20% than in simulation,

but 30 TB of data scattered in >15 simulation production sites. Ideal for wider GRID use


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


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)


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


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


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


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).


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


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


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)


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,4 6,7 0,5

Each RC 0,2 0,2 0,4 5

`6`Ext. RC‘s

1,2 1,2 2,4 30

Total 1,6 7,9 2,9


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.


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] 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.


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.


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


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


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


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)


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


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


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


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 ET

– muoni di bassa energia (TileCal)– b-tagging on-line– utilizzo di (moduli di) programmi di ricostruzione off-line

nell’Event Filter


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)


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)


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


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


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


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 ET (MI, PV)

• muoni di bassa energia (PI)• architettura Event Filter (PV)


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


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

11 Novembre 2002Laura Perini - CSN1 Perugia1 Calcolo e Software di Atlas Overview Organizzazione...

Documents

Transcript of 11 Novembre 2002Laura Perini - CSN1 Perugia1 Calcolo e Software di Atlas Overview Organizzazione...