Calcolo%20e%20Software%20di%20Atlas%20Overview - PowerPoint PPT Presentation

View by Category
About This Presentation



Fino al 1999, il software di ATLAS era basato su Fortran, Geant3 e Zebra: ... dei vari rivelatori sono gli ambienti naturali dove esercitare il nuovo software: ... – PowerPoint PPT presentation

Number of Views:66
Avg rating:3.0/5.0
Slides: 39
Provided by: DarioBa3


Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Calcolo%20e%20Software%20di%20Atlas%20Overview

Calcolo e Software di Atlas Overview
  • Organizzazione ATLAS Softare/Computing e ruolo
  • Data Challenges
  • GRID e Computing Model
  • Software (da Dario Barberis)

Computing organization
Comp. Oversight Board
National Comp. Board
Comp. Steering Group
Technical Group
Event filter
QA group
Arch. team
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)
Other ATLAS key post-holders
  • Chief Architect D.Quarrie (LBNL) CSG
  • Physics Co-ordinator F.Gianotti (CERN)
  • Software Librarian S. ONeale
  • 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)
  • 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 limpegno dei gruppi
    INFN nel s/w e Computing. Utile per identificare
    linee di intervento e per dare maggior peso a

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
  • 122/3200lt 4 Abbiamo fatto più del nostro share
    di CPU ma INFN è il 10 di ATLAS
  • Dobbiamo recuperare un fattore gt2 nella CPU!

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 lt20 than in
    simulation, but 30 TB of data scattered in gt15
    simulation production sites. Ideal for wider GRID

  • DC2 Q3/2003 Q2/2004
  • Goals
  • Full deployment of Event Data Model Detector
  • 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 107 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 Tier1Tier2 da 120 CPUs 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
  • Roma1 e Milano restano della stessa dimensione e
  • 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) gt richieste a CSN1
    già in 2003

  • Atlas has already used GRID for producing DC1
  • 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
    (1030k 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
  • 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
  • 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
    lt30, 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
  • Perform more extensive Grid tests.
  • Extend the EDG to more ATLAS sites, not only in
  • 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
  • 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 è
  • 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 (Tier1ssome
  • 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 ESDs 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 laccounting
    fra diverse regioni)

Resources Estimates (1)
  • We have to consider two main areas of computing
  • Large-scale productione.g. reconstruction, MC
  • 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

CPU (MSI95) Tape (PB) Disk (PB) Addition ManpowerFTE
CERN (T0T1) 0,4 6,7 0,5
Each RC 0,2 0,2 0,4 5
6Ext. RCs 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)
  • LArchitecture 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
  • separazione fra rappresentazione dei dati in
    memoria e su data base (intercambiabilità del
    data base)
  • separazione fra dati degli eventi e geometria dei
  • separazione fra simulazione e ricostruzione
  • Il 1º ciclo di sviluppo del nuovo software è
    quasi completo

  • 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
  • Interattività
  • Possibilità di compilare/linkare/testare moduli

Data Base
  • Il data base utilizzato da ATLAS (a partire dalla
    fine del 2001) per gli eventi è il sistema ibrido
  • ROOT contiene i dati degli eventi
  • MySQL ha il catalogo
  • Transizione da Objectivity/DB in pochi mesi
  • grazie alla separazione transiente/persistente
    alla base dellarchitettura di Gaudi/Athena
  • Classi persistenti generate automaticamente con
  • Sviluppi in corso
  • Integrazione dei data base per geometria e eventi
  • Conditions allineamenti, calibrazioni, altri
    dati che variano nel tempo (LCG)

Event Data Model
  • LEvent Data Model descrive lorganizzazione dei
    dati di ogni evento
  • transienti (in memoria)
  • persistenti (nel data base)
  • Il nuovo EDM di ATLAS è basato sulla separazione
    stretta fra dati dellevento e geometria del
  • solo gli identificatori geometrici degli elementi
    del rivelatore sono usati per correlare i dati
    dellevento con la geometria
  • Sviluppo ancora in corso per (quasi) tutti i
  • completamento previsto per inizio 2003

  • Singola sorgente di dati geometrici data base
  • 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
  • ma per Geant3 non cè nulla di automatico!
  • Infrastruttura tuttora in corso di sviluppo (LCG)
  • Contributo italiano geometria dei rivelatori di

  • 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 m (simulazione dettagliata,
    ottimizzazione e algoritmi)
  • High Level Triggers (2º livello ed Event Filter)
  • architettura (Event Filter Dataflow)
  • algoritmi per trigger L2 m
  • algoritmi per trigger t e ET
  • muoni di bassa energia (TileCal)
  • b-tagging on-line
  • utilizzo di (moduli di) programmi di
    ricostruzione off-line nellEvent 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
  • 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
  • Pixel (test beam H8, irraggiamento al PS)
  • LAr e TileCal integrazione nel test beam
    combinato (fetta di ogni rivelatore di ATLAS)

  • 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
  • sviluppo e integrazione del Conditions Data
  • simulazione ottimizzazione di Geant4 (geometria
    e fisica)
  • simulazione ottimizzazione della risposta del
  • 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 allorganizzazione
  • 3 membri del Computing Steering Group
  • D. Barberis (Inner Detector Software Coordinator)
  • L. Perini (GRID Coordinator)
  • V. Vercesi (Physics Event Selection
    Architecture Coordinator)
  • Contributi allinfrastruttura
  • A. De Salvo (distribuzione di s/w per data
  • A. Farilla (organizzazione dei Computing
  • 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 m L1/L2 (RM1, NA)
  • trigger Pixel/b-tagging L2 (GE)
  • trigger t 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

  • Il software di ATLAS è in rapida evoluzione
  • il gradiente è positivo
  • Il primo ciclo di sviluppo di software OO è quasi
  • il piano di sviluppo del secondo ciclo verrà
    definito nei dettagli nei prossimi mesi dal nuovo
    Computing Coordinator
  • Il software pervade tutto lesperimento
  • è importante avere strategie comuni online e
  • necessita una maggiore integrazione di software e
    anche di persone
  • va anche migliorato il controllo della qualità
  • Il contributo italiano al software di ATLAS è
  • focalizzato nei settori di nostra competenza
  • riconosciuto dalla collaborazione con nomine a
    rilevanti responsabilità organizzative