Computing Model ATLAS & CMS Federica Fanzago (CMS) & Monica Verducci (ATLAS) III Workshop Italiano della Fisica di ATLAS e CMS Bari, 20-22 Ottobre 2005

Computing ModelComputing Model ATLAS & CMS ATLAS & CMS

Federica Fanzago (CMS) & Monica Verducci (ATLAS)

III Workshop Italiano della Fisica di ATLAS e CMS

Bari, 20-22 Ottobre 2005

Fanzago-Verducci Computing Model Atlas & CMS 2

SommarioSommario

Introduzione ad LHC Descrizione del Computing Model Data Flow Trigger e Streams Work Flow Data e service challenges Conclusioni Items di discussione


Large Hadron Collider LHCLarge Hadron Collider LHC

Collisioni protone-protone

Energia fascio: 7 TeV

Luminosita': 1034 cm-2 s-1

(2007: 0.5*1033 cm-2 s-1; 2008/09: 2*1033 cm-2 s-1)

Sezione d’urto totale anelastica pp tot(pp) = 70 mb

Sistema gerarchico di calcolo per gestione dati

Frequenza bunch-crossing : 40 MHz

~ 20 collisioni p-p per bunch crossing

~PB/sec

Sistema gerarchico di trigger per riduzione dati

109 eventi/s =>1GHz

1 evento ~ 1MB

~MB/sec ~PB/anno raw data


Computing Model: perche’Computing Model: perche’ Per far fronte ai problemi di gestione di questa grande quantita’ di dati

archiviarli (grande capacita’ di storage) distribuirli

per garantire l’accesso ai dati ai fisici della collaborazione indipendentemente dalla loro locazione

definire policy locali e globali per l’utilizzo delle risorse

per avere sufficiente capacita’ di calcolo processing dati analisi produzioni dati simulati

Gli esperimenti LHC hanno deciso di utilizzare una architettura distribuita basata sulla grid.

I servizi grid sono forniti da World Wide LCG Computing Grid (WLCG) che utilizza software di EGEE (Enabling Grids for E-sciencE), di American Open Science Grid (OSG) e NorduGrid


Computing Model: cos’e’Computing Model: cos’e’Il Computing Model definisce:

Modello dei dati e come questi vengono distribuiti dalla presa dati all’analisi finale

Architettura e gerarchia delle risorse Policies di accesso dati e risorse dislocati geograficamente nei vari centri Procedure di calibrazione e allineamento, Processing e reprocessing dati reali Come fare la produzione dei dati simulati in ambiente distribuito Come fare l’analisi in ambiente distribuito Tools che si interfacciano ai servizi grid Come e quando fare i test dell’architettura, dei servizi e del modello dati

Il Computing Model stabilisce inoltre le performances che si vogliono ottenere dal Computing System in ambiente distribuito, per permettere un accesso veloce sia ai dati ricostruiti per effettuare le analisi durante la presa dati sia ai RawData per servizi di monitoring, calibrazione e allineamento.


Computing Model: architettura Computing Model: architettura distribuitadistribuita

Online System

Offline Processor Farm

CERN Computer Centre

US Regional Centre ~4 TIPS

France Regional

Centre ~4 TIPS Italy Regional

Centre ~4 TIPS

InstituteInstituteInstituteInstitute ~0.25TIPS

Physicist

workstations

“bunch crossing” 25 nsecs.

1 evento ~ 1 MB

Tier2 Centre ~1 TIPS




LNL ~1 TIPS

Tier 0Tier 0

Tier 1Tier 1

Tier 2Tier 2

40 Mhz

(1000 TB/s)

1 TIPS is ~ 25,000

SpecInt95 equivalents

Tier 3Tier 3

40 Mhz

(1000 TB/s)

Alcuni dati usati per la calibrazione e il monitoring vanno ai centri Tier1 dedicati, e poi ritornano al Tier0

100-1000 MB/s

ATLASCMS

I Tiers comunicano fra di loro attraverso la GRID!


Online system: il TriggerOnline system: il Trigger Scopo: ridurre la quantita' di dati filtrando gli eventi “non interessanti”

25ns40 MHz

105 Hz

103 Hz

102 Hz

Front end pipelines

Readout buffers

Processor farms

Switching network

Detectors

µsec

ms

sec

LVL 1

LVL 2

LVL 3

ATLASATLASATLASATLAS CMSCMSCMSCMS

LVL 1

HLT

40 MHz

µsec

sec

105 Hz

102 Hz

25ns

~PB/sec

~MB/sec ~PB/anno

• Primary stream (tutto l’evento dall’EF)

• Stream calibrazione ed allineamento

• Physics trigger (tuning- express line)

• Pathological events (evts non accettati dall’EF)

• Primary stream (tutto l’evento dall’EF)

• Stream calibrazione ed allineamento

• Physics trigger (tuning- express line)

• Pathological events (evts non accettati dall’EF)

• 10 Primary stream (50 dataset)

• Stream di calibrazione

• Express-line stream (contiene dati da processare con alta priorita’)

• 10 Primary stream (50 dataset)

• Stream di calibrazione

• Express-line stream (contiene dati da processare con alta priorita’)


Calibrazione ed Allineamento Calibrazione ed Allineamento

I processi di calibrazione e allineamento generano “non-event data” necessari per la ricostruzione degli “event-data”.

Esistono diversi processi di calibrazione ed allineamento:

CMS

•Test di precalibrazione al Local DAQ

Dagli event data:•A livello di sub-detector•Dopo DDU (Detector Dependent Unit ) Readout system•Dopo event-filter farm•Off-line

ATLAS •Input Raw data possono provenire direttamente dall’event stream o essere processati nel sub-detector read-out system.•A livello dei RODs (sub-detector read-out system)•All’interno dell’event filter•Dopo l’event filter ma prima della “prompt reconstruction”•Offline dopo la “prompt reconstruction”


ATLAS DatabasesATLAS DatabasesConfiguration Database e Condition Database

Manual Input

TCorddb

RODHLT/DAQ

DCS System

Online Calib. farm

RODHLT/DAQ

DCS System

Monitorqueries

Reco.farms

Offline analysis

Geom.

Setup

Calib

CONFIGURATION DB

Geom.

Setup

Calib

CONDITION DB

Monitordata

DCS

ATLASDetector

DCSDetector Con. Sys.•HV, LV•Temperatura•Allinemaneto

Front-End

EventFilter

Level2Trigger

ROSs

Level1Trigger

VME CrateRODs

ATHENA code

Configuration Database

Conditions Database

ByteStream Files


CMS DatabasesCMS Databases

Co

nd

ition

s

Calib

ratio

n

Online Master Data Storage

Online Master Data Storage

Calibrazione / allineamento Stima = 90 TB /annoDati da usare nell’HLTPoi copiati sul Tier 0 e replicati ai Tier1: necessari nei riprocessamenti e nell’analisi

Con

figuratio

n

Offline ReconstructionConditions DBONline subset

Offline ReconstructionConditions DBONline subset

Sincronizzazione sulle conditions

Co

nd

ition

s

Offline ReconstructionConditions DBOFFline subset

Master Copyno “event data” al Tier0


Ruolo dei Tiers Ruolo dei Tiers

Tier-0 al CERN: archivia tutti i dati dell'online (RAW) e ne fa una prima ricostruzione (RECO/ESD). Conserva i dati per la calibrazione. Dal Tier 0 i RECO+RAW vengono distribuiti ai Tier-1’s

Tier-1: archiviano i dati e forniscono servizi per la simulazione, ricostruzione, calibrazione e skimming (AOD). Gli AOD vengono trasferiti ai Tier2

Tier-2: simulazione per computing system commissiong, copia degli AOD per analisi con diversi sistemi di streaming, campioni di eventi in formato RAW e ESD per calibrazioni e sviluppo algoritmi di ricostruzione, calibration centers

CERNCERN

TriggerEvent Filter

TriggerEvent Filter

CNAF CNAF

TIER 0TIER 0TIER 0TIER 0

TIER 1TIER 1

TIER 2TIER 2

TIER 3TIER 3

Tier-3: Analisi dati utenti

Rate

[Hz]

RAW

[MB]

ESDRECO[MB]

AOD

[kB]

MonteCarlo

[MB/evt]

ATLAS 200 1.6 0.5 100 2

CMS 150 1.5 0.25 50 2

ATLAS ~ 10CMS ~ 6

ATLAS ~ 40CMS ~ 25


La grid: middleware LCGLa grid: middleware LCG

Principali componenti del middleware lcg

Virtual Organizations (CMS,ATLAS,ecc)

Resource Broker (RB) Replica Manager (RLS) Computing Elements (CEs) Storage Elements (SEs) Worker nodes (WNs) User Interfaces (UIs)

CE

Resource Broker (RB)

Workload Management

System

UIJob submission

tools

SE

SE

SE

Data location system

InformationService collector

Query for data

Query for matchmaking


In v

ia d

i svi

lupp

o

Tool di esperimento interfacciati ai Tool di esperimento interfacciati ai servizi gridservizi grid

Gli esperimenti stanno sviluppando i propri tools per la produzione dei dati simulati (MC) e per l'analisi distribuita interfacciandosi ai servizi forniti dalla grid

CMS ATLAS

DATA MANAGEMENT

Data Transfer service PhEDEx DDM e DQ2

Data Publication service RefDB/PubDB->DBS/DLS AMI

PRODUCTION

Production Job Submission Tool

MCRunJob AtCom, GANGA, RAT

ANALYSIS

Distributed Software Installation

XCMSI No UI, ProdSys

Analysis Job Submission Tool CRAB AtCom, GANGA, RAT

MONITORING

Application Monitoring BOSS MDS, AtCom

Dashbord Monalisa P. manager, Monalisa


Computing Model CommissioningComputing Model Commissioning

E’ importante per gli esperimenti verificare più volte nel tempo la fattibilità e la scalabilità dell’intero sistema (infrastruttura, software, data management, data workflow), con livelli di complessità via via sempre più prossimi alle condizioni che si avranno allo startup di LHC.

Gli esperimenti, con i data e service challenges, vogliono valutare la robustezza e la scalabilita' dell'intero sistema

Data Challenges Service Challenges


Data Challenges Passati: ATLASData Challenges Passati: ATLAS

ATLAS DC 1 Lug 2002-Mag 2003 Organizzazione delle risorse disponibili (hardware e

persone): primo approccio all’uso della grid Mostrato la necessità di un sistema integrato Richiesta di più manpower Tests sul software grid

Massiccia produzione di dati per HLT e Physics Workshop

Dimostrata la possibilità di poter simulare, ricostruire e salvare su disco all’interno di una struttura distribuita.

Circa 15M eventi sono stati generati con Geant3 (fortran), 40 M di eventi ‘single-particle’ per un volume totale di 70TB.


ATLAS DC 2ATLAS DC 2 Mag 2004-Gen 2005Mag 2004-Gen 2005 SCOPO:

Largo uso del GRID middleware e dei suoi tools (Tier 0 exercise)

Analisi di fisica a grande scala

Studio del computing model (fine 2004)

Produzione intensiva su LCG-2

RISULTATI:

Circa 15M eventi generati con Geant4, ovvero 40TB di dati raccolti in 200000 files. Sono state usate le tre GRIDS: LCG/Grid3/NorduGrid nel rapporto 40/30/30% con un’efficienza globale del 60%.

Il trasferimento dati al CERN è stato effettuato via DQ, con una media di 2-3000 files al giorno, 50 GB/giorno, che è stata poi portata a 100000 files al giorno (1.5 TB/giorno).

PROBLEMI: Tier 0 exercise ridotto per mancanza di risorse software

Problemi di Stagein/out, trasferimenti di files

Il Central Production database Oracle, lenta risposta

Problemi con LCG information system, connessioni perse , lentezza del Resource Broker (limitati jobs per giorno)


Simulazione di ATLAS e 2004 Combined Test Beam Test delle procedure di calibrazione e allineamento Circa 9 M di eventi (50 kB per evento) per un totale di 4.5 TB collocati in

Castor Produzione per l’ATLAS Physics Workshop

Circa 5 M di eventi sono stati generati, simulati, digitizzati ed infine ricostuiti (AOD, ESD), 173 differenti canali di fisica alcuni con pile-up.

Problemi umani connessi alla registrazione manuale all’interno del Production System, limitato trasferimento di files dovuto a Castor (mass storage system).

Differenze con il DC2: Condor G (esecutore LCG) -> 12000 jobs

jobs per day

0

1000

2000

3000

4000

5000

6000

7000

8000

6/2

5/2

004

7/2

5/2

004

8/2

5/2

004

9/2

5/2

004

10/2

5/2

004

11/2

5/2

004

12/2

5/2

004

1/2

5/2

005

2/2

5/2

005

3/2

5/2

005

4/2

5/2

005

5/2

5/2

005

6/2

5/2

005

7/2

5/2

005

Jobs per day on the LCG-2 infrastructure

DC2 Rome prod

Rome Workshop & Test Beam Rome Workshop & Test Beam (2004)(2004)


CMS EDG stress test 2002CMS EDG stress test 2002

Primo tentativo di produzione dati in ambiente grid (EDG 1.3.4) Scopo:

valutare il livello di maturità del middleware EDG capire se EDG risponde alle esigenze di produzione dell’esperimento scoprire problematiche, misurare prestazioni valutare tool per interfaccia utente e per monitoring risorse e job

Risultato: sono stati prodotti ~260K eventi MC in tre settimane (10500 job sottomessi). Efficienza grid ~50-90% a seconda del tipo di job (durata, input-output)

Problemi evidenziati: il test è stato “difficile” perché il primo in ambiente distribuito. Molti parametri in gioco, persone non molto esperte Eccessivo bisogno di supporto alle risorse e servizi Particolarmente debole RB ed Information Service


CMS DC04 marzo-aprile 2004CMS DC04 marzo-aprile 2004 Scopo: dimostrare la fattibilita’ della catena:

Ricostruzione dati al T0, 25Hz (25% del rate previsto allo startup) 35 M ev.simulati (PCP)

Registrazione dati nel Replica Catalog (RLS) Trasferimento dati ai T1 e T2 Analisi dati sincrona con il trasferimento Pubblicazione nel catalog degli output dell’analisi

Risultato: DC04 ha raggiunto l’obiettivo della ricostruzione e dell’analisi sincrona al rate di 25Hz . In particolare:

25 M eventi ricostruiti (DST) ~6TB dati; 10M eventi analizzati 15000 job di analisi sottomessi in due settimane; 90-95% efficienza grid 20 minuti tra ricostruzione T0 e inizio analisi T1 2 minuti ritardo introdotto dalla grid nell’esecuzione job

Problemi evidenziati: catalogo centrale (RLS) troppo lento in scrittura e lettura, non soddisfa le esigenze

dell’esperimento. Risorse e servizi necessitano controllo costante. Sistema in generale complesso per essere utilizzato da un utente non esperto

In ambiente grid (LCG)


Data and Service Challenges Futuri: Data and Service Challenges Futuri: ATLASATLAS

Durante questo autunno, si testerà (SC3) il Production System Produzione nel Tier0 con trasferimento dati ai Tier1 Produzione MonteCarlo distribuita che permetterà di testare il

trasferimento dal tier1 al Tier2 in entrambe le direzioni. DQ->DQ2: Dataset Selection Catalog + Logical Replica Catalog

A fine anno, comincerà la “pre-production” per il DC3 (CSC) La mole di dati sarà di un ordine di grandezza maggiore di quella del

DC2 Tests su: scalabilità del Tier-0, distribuzione dei dati, e analisi

distribuita, offline trigger software Molti users Ultima possibilità per validare il software e il computing system prima

dei dati veri Cosmic rays a fine anno:

Test di calibrazione e accesso ai database Simulazione di eventi di cosmici per analisi


CMS e LCG SC3: challenge in corsoCMS e LCG SC3: challenge in corsoLCG SC3 e’ un service challenge a cui partecipano tutti gli

esperimenti LHC. E’ divisa in due fasi: fase “throughput” (luglio 05): test trasferimento dati tra T0 - T1

- T2. CMS usa PhEDEx come tool di trasferimento

PhEDEx si interfaccia con diversi protocolli di trasferimento:GSIFTP e SRM (nasconde varie tecnologie di storage, dpm, castor, dcache)

PhEDEx scrive su un LCG-POOL catalog locale,backend MySQL, per creare cataloghi file

fase “service” (da settembre fino fine anno): non solo trasferimento dati ma anche test sui tools e sul computing model di esperimento data management con pubblicazione dati su PubDB e RefDB workload management con creazione e sottomissione job analisi

(via CRAB) e produzione test integrazione PhEDEx con LFC (catalogo grid) per

pubblicazione dati Problemi: e’ stato necessario debugging del servizio castor-2 al

CERN.


CMS Challenge futuri CMS Challenge futuri Cosmic challenge (06):servirà a testare i moduli installati

acquisendo i dati dei cosmici. Dal punto di vista del computing:

Verra’ usato il nuovo framework Possibile test sul data management e job workflow ricostruzione

dati, trasferimento ai Tiers e pubblicazione sui DB per futura analisi.L’obiettivo principale è il test dei rivelatori.

SC4 (06): service challenge di tutti i servizi che verranno usati allo startup. Le produzioni MC e l’analisi fatte nel challenge serviranno per il P-TDR.

CSA (06) Computing, Software, Analysis: test completo di tutta la catena del computing dalla presa dati all’analisi finale. Si vuole verificare che software e servizi siano pronti per la presa dati.

Verranno prodotti milioni di eventi. I Tier1e2 dovranno girare job di analisi sui dati trasferiti e calibrazioni.


Attività prevista nei centri italiani Attività prevista nei centri italiani (ATLAS)(ATLAS)

Ricostruzione:Muon Detector (LE, NA, PV), Calorimetri (MI, PI), Pixel Detector (MI)

Calibrazioni/allineamento/detector data: MDT (LNF, RM1-3), RPC (LE, NA, RM2), Calorimetri (MI, PI), Pixel

Detector (MI) Cond. DB (CS), Det. Descr. DB (LE, PI), Det. Mon. (CS, NA, UD)

Studi di performance:Muoni (CS, LE, LNF, NA, PI, PV, RM1-2-3)Tau/jet/EtMiss/egamma (GE, MI, PI)

Analisi:Higgs sia SM che MSSM (CS, LNF, MI, PI, PV, RM1)Susy (LE, MI, NA)Top (PI, UD)Fisica del B (CS, GE, PI)

Simulazioni connesse alle attività suddette Studi sul modello di analisi VOMS e Lexor sono prodotti italiani!

Tier1

Tier 1: CNAFTier 2: Milano, Roma 1, Frascati, Napoli


Attività prevista nei centri italiani Attività prevista nei centri italiani (CMS)(CMS)

Ricostruzione: Muon DT - Torino, Padova, Bologna Muon RPC - Bari, Napoli Ecal - Roma1, MilanoB Tracker - Pisa, Firenze, Perugia, Catania, Bari

Calibrazioni/allineamento/detector data: Muon DT - Padova, Torino Muon RPC - Ecal - Roma1, MilanoB Tracker - Bari, Pisa, Firenze Condition DBs : ECAL - Roma1 Detector monitoring :Tracker - Pisa, Bari : Muon - Bologna : Ecal - Trieste, MilanoB

Studi di performance: Muon (DT + RPC) - Padova, Torino, Bologna, Bari, Napoli Ecal - Roma1, MilanoB Tracker - Pisa, Firenze, Bari, Perugia

Analisi: Higgs sia SM che MSSM - Firenze, Bari, Roma1, Padova, Bologna, MilanoB, Perugia,

Napoli, Pavia, Pisa, Torino Susy - Catania, MilanoB, Bari, Pisa Top - Pisa, Bologna b-physics - Firenze, Napoli, Pisa, Perugia SM Z/W - MilanoB, Roma1 QCD - Perugia, Bologna

Tier 1: CNAFTier 2: Legnaro, Pisa, Roma, Bari


ConclusioniConclusioni L’enorme quantità di dati che verranno prodotti dagli

esperimenti LHC quando entreranno in funzione richiederanno un sistema di calcolo gerarchico e distribuito basato sulla grid.

Gli esperimenti stanno testando con challenges di complessità crescente la solidità e la maturità del computing model per arrivare pronti allo startup.

I challenges finora fatti, mettendo in evidenza problematiche e colli di bottiglia, hanno permesso al sistema di evolvere e di ridurre gli errori di sistema ed umani che avevano caratterizzato i primi tests.

Alcuni aspetti sono ancora in fase di studio … Discussione


Items di discussioneItems di discussione

CMS ed ATLAS sono due progetti molto simili fra loro, le differenza esistenti appartengono ai diversi usi che hanno fatto della grid: CMS ha sviluppato alcuni propri tools, soprattutto interfaccia utente, contrariamente ad ATLAS che si affida ‘quasi’ completamente ad LCG

Da un punto di vista dell’utente finale: e’ veramente ‘user-friendly’ usare la grid?

Alla luce dei risultati dei challenges, un punto problematico per entrambi gli esperimenti sembra essere il data-discovery. Come viene affrontato nelle due realtà.

Quanto devono essere associati i challenges di computing con quelli di fisica, ad esempio nel prossimo cosmic challenge?

Quando e’ giusto fare un service challenge? A che livello di maturità dei tools, per evitare debugging o vero e proprio sviluppo?


Back upBack up



CERN Computer Centre

FermiLabFrance Regional Centre

Italy Regional Centre (CNAF)

Germany Regional Centre

~100 MBytes/sec

Bari

Tier 0Tier 0

Tier 2Tier 2 Bologna LNL Padova

PubDB

Localcatalogues

ValidationTools

Data vengono spostati dal Tier 0 ai Tier 1 e Tier 2 con PhEDEx

PhEDEx

PhEDEx

CMS data movement

Una volta trasferiti i dati vengono validati e pubblicati nei catalogo locale

RefDB


What is PhEDEx?What is PhEDEx? A data distribution management

system Used by CMS

Blends traditional HEP data distribution practice with more recent technologies

Grid and peer-to-peer filesharing

Scalable infrastructure for managing dataset replication

Automates low-level activity Allows manager to work with

high level dataset concepts rather than low level file operations

Technology agnostic Overlies Grid components Currently couples LCG, OSG,

NorduGrid, standalone sites

•Two principle use cases- push and pull of data

Raw data is pushed onto the regional centresSimulated and analysis data is pulled to a subscribing site

By T.Barrass


ruolo dei tiers negli esperimentiruolo dei tiers negli esperimenti

CMS CAF Functionality:CERN Analysis Facility: development of the CERN Tier-1 / Tier-2

Integrates services associated with Tier-1/2 centersPrimary: provide latency-critical services not possible elsewhere

Detector studies required for efficient operation (e.g. trigger)Prompt calibration ; ‘hot’ channels

Secondary: provide additional analysis capability at CERN By P.Capiluppi


CRAB analisi distribuita...CRAB analisi distribuita...


CMS:analisi distribuita…come sara’CMS:analisi distribuita…come sara’

Dataset Bookkeeping System: sa che dati esistono. Contiene descrizione dati specifiche di CMS. Non contiene informazioni sulla locazione dei dati Completa responsabilita di CMSData Location Service: sa dove sono I dati. Mappaggio tra file-blocks (data location unit) e SE. Local File Catalog: sa dove sono fisicamente i dati e con quale protocollo accederli.

CRAB: tool per la creazione e la sottomissione di job di analisi.Permette agli utenti di girare il proprio codice di analisi su dati remoti come se fossero in locale

CRAB


RefDB

CE

Script generator (MCRunJob)

I want to monitor

1. Cross section

2. N events

3. Ntpl size

4. Ntpl location

Template.shSo, here’s my template

Std output

Job Monitoring

Yes! Here’s what I want:

1. Cross section

2. N events

3. Ntpl size

4. Ntpl location

CMS Production SystemCMS Production System

By M.Corvo


ATLAS production SystemATLAS production System

LCG NG(Grid3)OSG

LSF

LCGexe

Condorexe

NGexe

OSGexe

LSFexe

ProdDB

Data Man. System

RLS RLS RLS

Don Quijote2

Eowyn

Lexor

AMI

PandaDulcinea


Data Management System ATLAS Data Management System ATLAS

Documents

Computing Model ATLAS & CMS Federica Fanzago (CMS) & Monica Verducci (ATLAS) III Workshop Italiano della Fisica di ATLAS e CMS Bari, 20-22 Ottobre 2005