Computing Model ATLAS

1
Computing Model ATLAS CMS

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

2
Sommario

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

3
Large Hadron Collider LHC

• Collisioni protone-protone
• Energia fascio 7 TeV
• Luminosita' 1034 cm-2 s-1
• (2007 0.51033 cm-2 s-1 2008/09 21033 cm-2
  s-1)
• Sezione durto totale anelastica pp stot(pp)
  70 mb

Frequenza bunch-crossing 40 MHz 20 collisioni
p-p per bunch crossing
Sistema gerarchico di calcolo per gestione dati
Sistema gerarchico di trigger per riduzione dati
109 eventi/s gt1GHz 1 evento 1MB
MB/sec PB/anno raw data
PB/sec
4
Computing Model perche

• Per far fronte ai problemi di gestione di questa
  grande quantita di dati
• archiviarli (grande capacita di storage)
• distribuirli
• per garantire laccesso ai dati ai fisici della
  collaborazione indipendentemente dalla loro
  locazione
• definire policy locali e globali per lutilizzo
  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

5
Computing Model cose

• Il Computing Model definisce
• Modello dei dati e come questi vengono
  distribuiti dalla presa dati allanalisi 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 lanalisi in ambiente distribuito
• Tools che si interfacciano ai servizi grid
• Come e quando fare i test dellarchitettura, 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.

6
Computing Model architettura distribuita
CMS
ATLAS
40 Mhz (1000 TB/s)
40 Mhz (1000 TB/s)
Offline Processor Farm
Alcuni dati usati per la calibrazione e il
monitoring vanno ai centri Tier1 dedicati, e poi
ritornano al Tier0
1 TIPS is 25,000 SpecInt95 equivalents
Tier 0
CERN Computer Centre
Tier 1
France Regional Centre 4 TIPS
Italy Regional Centre 4 TIPS
US Regional Centre 4 TIPS
Tier 2
I Tiers comunicano fra di loro attraverso la
GRID!
Institute 0.25TIPS
Institute
Institute
Institute
Tier 3
100-1000 MB/s
Physicist workstations
7
Online system il Trigger
Scopo ridurre la quantita' di dati filtrando gli
eventi non interessanti
PB/sec
CMS
ATLAS
Detectors
25ns
40 MHz
25ns
40 MHz
Front end pipelines
LVL 1
LVL 1

• Primary stream (tutto levento dallEF)
• Stream calibrazione ed allineamento
• Physics trigger (tuning- express
  line)
• Pathological events (evts non accettati
  dallEF)

105 Hz
105 Hz
µsec
µsec

• 10 Primary stream (50 dataset)
• Stream di calibrazione
• Express-line stream (contiene dati da processare
  con alta priorita)

Readout buffers
LVL 2
ms
Switching network
103 Hz
Processor farms
LVL 3
HLT
102 Hz
102 Hz
MB/sec PB/anno
sec
sec
8
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

• ATLAS
• Input Raw data possono provenire direttamente
  dallevent stream o essere processati nel
  sub-detector read-out system.
• A livello dei RODs (sub-detector read-out system)
• Allinterno dellevent filter
• Dopo levent filter ma prima della prompt
  reconstruction
• Offline dopo la prompt reconstruction

• 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

9
ATLAS Databases
Configuration Database e Condition Database
Manual Input
TCord db
ROD
HLT/DAQ
DCS System
Online Calib. farm
CONFIGURATION DB
CONDITION DB
Geom.
Monitordata
Geom.

Setup
Setup
DCS
Calib
Calib
ROD
HLT/ DAQ
DCS System
Monitor queries
Reco. farms
Offline analysis
10
CMS Databases
Calibrazione / allineamento Stima 90 TB
/anno Dati da usare nellHLT Poi copiati sul Tier
0 e replicati ai Tier1 necessari nei
riprocessamenti e nellanalisi
Offline Reconstruction Conditions DB ONline subset
Online Master Data Storage
Sincronizzazione sulle conditions
Calibration
Configuration
Master Copy no event data al Tier0
Conditions
Conditions
Offline Reconstruction Conditions DB OFFline
subset
11
Ruolo dei Tiers
TIER 0
Trigger Event Filter
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
RECORAW vengono distribuiti ai Tier-1s
ATLAS 10 CMS 6
TIER 1
CNAF
Tier-1 archiviano i dati e forniscono servizi
per la simulazione, ricostruzione, calibrazione
e skimming (AOD). Gli AOD vengono trasferiti ai
Tier2
ATLAS 40 CMS 25
TIER 2
TIER 3
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
RateHz RAWMB ESDRECO MB AOD kB Monte CarloMB/evt
ATLAS 200 1.6 0.5 100 2
CMS 150 1.5 0.25 50 2
Tier-3 Analisi dati utenti
12
La grid middleware LCG
UI Job submission tools

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

Query for matchmaking
Workload Management System
Information Service collector
Query for data
Data location system
Resource Broker (RB)
CE
SE
SE
SE
13
Tool di esperimento interfacciati ai servizi 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-gtDBS/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
In via di sviluppo
14
Computing Model Commissioning

• E importante per gli esperimenti verificare più
  volte nel tempo la fattibilità e la scalabilità
  dellintero 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

15
Data Challenges Passati ATLAS

• ATLAS DC 1 Lug 2002-Mag 2003
• Organizzazione delle risorse disponibili
  (hardware e persone) primo approccio alluso
  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 allinterno 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.

16
ATLAS DC 2 Mag 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 unefficienza 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)

17
Rome Workshop Test Beam (2004)

• 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 lATLAS 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
  allinterno
  del Production System,
  limitato
  trasferimento di files dovuto a
  
  Castor (mass storage system).
• Differenze con il DC2 Condor G
  (esecutore LCG)
  -gt 12000 jobs

Jobs per day on the LCG-2 infrastructure
Rome prod
DC2
18
CMS 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 dellesperimento
• 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

19
CMS 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
  dellanalisi
• Risultato DC04 ha raggiunto lobiettivo della
  ricostruzione e dellanalisi 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
  nellesecuzione job
• Problemi evidenziati
• catalogo centrale (RLS) troppo lento in scrittura
  e lettura, non soddisfa le esigenze
  dellesperimento.
• Risorse e servizi necessitano controllo costante.
• Sistema in generale complesso per essere
  utilizzato da un utente non esperto

In ambiente grid (LCG)
20
Data and Service Challenges Futuri ATLAS

• 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-gtDQ2 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

21
CMS e LCG SC3 challenge in corso

• LCG 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
  trasferimentoGSIFTP 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.

22
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.
• Lobiettivo principale è il test dei rivelatori.
• SC4 (06) service challenge di tutti i servizi
  che verranno usati allo startup. Le produzioni MC
  e lanalisi fatte nel challenge serviranno per il
  P-TDR.
• CSA (06) Computing, Software, Analysis test
  completo di tutta la catena del computing dalla
  presa dati allanalisi 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.

23
Attività prevista nei centri italiani (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

Tier 1 CNAF Tier 2 Milano, Roma 1, Frascati,
Napoli
Tier1
24
Attività prevista nei centri italiani (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

Tier 1 CNAF Tier 2 Legnaro, Pisa, Roma, Bari
25
Conclusioni

• Lenorme 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 ?

26
Items 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 dellutente 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?

27
Back up
28
(No Transcript)
29
CMS data movement
RefDB

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

100 MBytes/sec
CERN Computer Centre
Tier 0
PhEDEx
FermiLab
France Regional Centre
Italy Regional Centre (CNAF)
Germany Regional Centre
PhEDEx
ValidationTools
Tier 2
PubDB
Una volta trasferiti i dati vengono validati e
pubblicati nei catalogo locale
30
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 centres
• Simulated and analysis data is pulled to a
  subscribing site

By T.Barrass
31
ruolo 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 centers Primary 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
32
CRAB analisi distribuita...
33
CMSanalisi distribuitacome sara
CRAB
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
Dataset Bookkeeping System sa che dati esistono.
Contiene descrizione dati specifiche di CMS. Non
contiene informazioni sulla locazione dei dati
Completa responsabilita di CMS Data 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.
34
CMS Production System
RefDB

• Yes! Heres what I want
• Cross section
• N events
• Ntpl size
• Ntpl location

• I want to monitor
• Cross section
• N events
• Ntpl size
• Ntpl location

Template.sh
So, heres my template
Script generator (MCRunJob)
Job Monitoring
Std output
CE
By M.Corvo
35
ATLAS production System
ProdDB
AMI
Data Man. System
Don Quijote2
Eowyn
LCG exe
Condor exe
NG exe
OSG exe
LSF exe
Panda
Dulcinea
Lexor
RLS
RLS
RLS
(Grid3) OSG
LCG
NG
LSF
36
Data Management System ATLAS