Gruppo1 - Lecce 24/09/2003 S.Falciano - INFN Roma1 ATLAS High Level Trigger/DAQ S.Falciano - INFN Roma1

Gruppo1 - Lecce 24/09/2003 S.Falciano - INFN Roma1

ATLAS High Level Trigger/DAQ

S.Falciano - INFN Roma1


Outline presentazione

• Progetto, partecipazione, milestones 2003• HLT/DAQ

• TDR : stato e contenuto– Global view : system requirements and “Baseline

architecture”– System components and functions– System performance– Organization and plan

• TDR : contributi italiani• Milestone 2004• Testbeam 2003/2004

• Conclusioni


Attività italiane• Trigger di Livello-1 muoni (barrel)

(Napoli, Roma1, Roma2)• Trigger di Livello-2 muoni (barrel) (Pisa,

Roma1)• Trigger di Livello-2 pixel (Genova)• Event Filter (Lecce, Pavia, Roma3)• DAQ (LNF, Pavia, Roma1)• DAQ testbeam (TDAQ + gruppi detector)

9 Sezioni INFN più Rivelatori e Offline (32 fisici per HLT/DAQ)


Incarichi nel progetto TDAQ• S.Veneziano (Roma1) -> Coordinatore trigger LVL1 muoni barrel+endcap+MUCTPI

• V.Vercesi (Pavia) -> Coordinatore PESA (Physics and Event Selection Architecture)

• A.Nisati (Roma1) -> IB Chairperson e Coordinatore algoritmi muoni in PESA

• F.Parodi (Genova) -> Coordinatore algoritmi b-tagging in PESA

• A. Negri (Pavia) -> Coordinatore Data Flow Software per l’Event Filter

• S.Falciano (Roma1) -> Coordinatore Detector Readout nel DIG e Detector HLT slices

... e per i testbeam• P.Morettini (Genova) -> Coordinatore DAQ testbeam H8 pixel

• E.Pasqualucci (Roma1) -> Coordinatore DAQ testbeam H8 muoni


• Marzo– Scrittura del nuovo software di Data Flow dell'Event Filter e

Monitoring.

100% Il software, il cui disegno era iniziato nel 2002, e‘ stato completamente sviluppato ed e' ora utilizzato su testbeam.

– Integrazione completa del software di calibrazione delle camere MDT nell'EF/DAQ del Testbeam. 100% Anche questa integrazione, iniziata nel 2002, è stata effettuata ed e' operativa nell'attuale testbeam.

• Aprile – Integrazione e test "slice" verticale LVL1/HLT/DAQ/DCS per un

rivelatore ATLAS (e.g. rivelatore di muoni) in laboratorio.

100% Integrazione effettuata in laboratorio per LVL1/RPC/TGC e camere MDT (elettronica di lettura e software di acquisizione e

trigger). Il testbed e' stato particolarmente utile per la messa a punto del software e di parte dello hardware per il testbeam del 2003.

Stato Milestones HLT/DAQ 06/2003


• Giugno – Sottomissione al LHCC del Technical Design Report di

HLT/DAQ/DCS. 100% Milestone raggiunta il 30/6/2003. Il TDR è ora in ristampa e verrà presentato al LHCC il 24/9/2003. I contributi italiani sono stati notevoli ed hanno riguardato il DAQ e i trigger di alto livello (LVL2 per Pixel e Muoni, adattamento dei programmi di ricostruzione offline all'Event Filter, framework software e responsabilità di alcuni capitoli importanti quali quello di PESA).

Stato Milestones 06/2003 (cont.)


TDR : stato e contenuto

– Sottomesso al comitato LHC il 30/6/2003• ATLAS High-Level Trigger, Data Acquisition and

Controls Technical Design Report, CERN/LHCC/2003-022

• Feedback molto positivo dalla “LHCC comprehensive review” del 2 luglio su HLT/DAQ

“The architectural open issues have essentially been resolved, an offline-online collaboration is building up, beam- and laboratory tests have been performed, the extensive DCS-implementation and the management structure.”

• Presentazione di ATLAS alla “Open LHCC session” del 24/9/2003 al CERN


Part 1 - Global View1. Overview2. Parameters3. System Operations4. Physics selection strategy5. Architecture6. Fault tolerance and error handling7. Monitoring

Part 2 - System Components8. Data-flow9. High-level trigger10. Online Software11. DCS12. Experiment Control

Part 3 - System Performance13. Physics selection and HLT performance14. Overall system performance and validation

Part 4 - Organisation and Plan15. Quality assurance and development process16. Costing17. Organisation and resources18. Workplan and schedule


TDR Part 1 : Global viewLa scelta dell’architettura si è basata sui seguenti criteri :

• La copertura del programma di fisica prevista da ATLAS• L’esistenza di prototipi funzionanti• Misure di “performance” che soddisfano o le specifiche finali di ATLAS o

possono essere tranquillamente estrapolate alle performance richieste sulla scala dei tempi reali (CPU speed dei PC, ….)

• La chiarezza di come evolvere dallo scenario iniziale di set-up ridotto, quale quello utilizzato su testbeam, al sistema completo ad alta luminosità

• Uno scenario dei costi che parte dallo “staged detector” fino al completamento del sistema

• La possibilità di trarre vantaggio dall’evoluzione della tecnologia mentre l’esperimento è in corso

L’architettura proposta potrebbe essere costruita oggi con le tecnologie attuali e raggiungere le performance richieste. Poichè sono previsti avanzamenti significativi nel campo del networking e computing, ciò ci aiuterà a semplificare ulteriormente alcuni aspetti complessi del sistema.


DATAFLOW

EB

ROSH

L

T

LVL1

DE

T RO

ROD

LVL2

Trigger DAQARCHITECTURE

2.5

s

~ 10 ms

40 MHz

75 kHz

~2 kHz

~ 200 Hz

Calo MuTrCh Other detectors

SFI

SFO

EBN

EFN

FE Pipelines

Read-Out Drivers

Read-Out Sub-systems

Dataflow Manager

Sub-Farm Input

Sub-Farm Output

Event Filter N/work

ROIB

L2P

L2SV

L2N

Event Filter

DFM

EFPEFP

EFPEFP

RoI Builder

L2 SupervisorL2 N/work

L2 Proc Unit

RoI

RoI data = 1-2%

RoI requests

Lvl2 acc = ~2 kHz

Event Building N/work~ sec

Lvl1 acc = 75 kHz

40 MHz

120 GB/s

~ 300 MB/s

~2+4 GB/s

Event FilterProcessors

120 GB/s

~4

GB

/s

EFacc = ~0.2 kHz

Read-Out Buffers

Read-Out Links

ROB

ROB

ROB

Event Builder


• C’è una corrispondenza semplice tra :

region <-> ROB number(s) (per ciascun rivelatore)

-> per ciascuna RoI, i processori di LVL2 possono identificare rapidamente la lista dei ROB con i correspondenti dati di ciascun rivelatore

• Questo meccanismo fornisce un modo potente ed economico per avere un importante fattore di reiezione prima

dell’ Event Building completo

4 RoI addresses

==> ATLAS RoI-based Level-2 trigger

… ~ ReadOut network più piccolo di un ordine di grandezza …… al costo di un maggiore

traffico di controllo …

Meccanismo delle RoI - Implementazione


Level-2 Trigger

Three parameters characterise the RoI-based Level-2 trigger:

the amount of data required : 1-2% of totalthe overall CPU time : 10 ms average

the rejection factor: x 30


TDR Part 2 : System components

• Data Flow (DAQ)• High-Level Triggers

– LVL2, EF, Event Selection Software (ESS)

• Online Software (DAQ)• DCS• Experiment Control


VME bus

•Total number of ROD crates: 90•Total number of ROS PCs : 144•Total number of racks : ~15”==>All in USA15 (underground)

F.E. ElectronicsF.E. Electronics

… ROD Crates

ROD CrateWorkstation

LAN (GbEth.)

GbEth.

… ROS PCs

ROD Fragments

ROB FragmentsROS Fragments

Event Fragments (Detector specific)

L2 & Event Builder NetworksL2 & Event Builder Networks

ROLs

RCD and ROS

… PCI bus

Config & Control

Event sampling & Calibration data

NIC

RO

BIN

RO

BIN

RO

BIN

RCP

ROD

ROD

ROD

ROD

Config & Control

Event sampling & Calibration data


The ROBin Prototype




HLT Event Selection Software


Realistic Data Access

Realistic bytestream format data generated using simulated events from DataChallenge-1. Used to measure data access and preparation times

Realistic bytestream format data generated using simulated events from DataChallenge-1. Used to measure data access and preparation times

Different implementations for LVL2, EF and Offline

Bytestream converters produce objects required by algorithms. Handle ROB mapping, calibration, etc.

Requires detailed understanding of the detector and read-out

Use of off-line services. TES uses Storegate


TDR Part 3 : System Performance

• DataFlow for LVL2 (RoI collection) and EF tested and required performance demonstrated

• LVL2 processing with algorithms and simulated data in realistic format tested in full trigger environment– Required performance demonstrated with LAr and Muon

Detectors using dedicated data preparation code– Further optimisation needed for data preparation code from

offline (specially true for calorimetry code)

• Functional test made of HLT vertical slice• Results validate the RoI mechanism, only ~2% of the data

after LVL1 needs to be moved over networks• Further work needed to validate use of off-line services in

LVL2, but outlook promising


LVL2 track reconstruction for b-tagging selection

Impact parameter resolution vs pT u-jet rejection vs b-tagging efficiency


Fast physicsperformance

HLT TP, layout M HLT TDR, layout P

Perfect match of the two resolutions for pt = 20 GeV

HLT TP, layout M


MOORE – Event Filter muon reconstruction

Risoluzione in impulso Efficienza


LVL2 Performance Test• The LVL2 performance has been

measured on a cluster using a 2.2 GHz Dual Xeon for the L2P fetching data via Gigabit Ethernet– Simulated LVL1 selected Di-jets

eventsloaded in the ROS(E)

– Ran LAr LVL2 selection algorithms in LAr data.

InputHandler

Event Selectio

nThreads

LVL1Result

LVL2 Processing Task

EventQueue

LVL2Result

LVL1Result

LVL2Supervisor

• LVL2 selection uses specially written algorithms in multi-threaded tasks– Highly optimized (decision time

~10ms)– Thread-safe


Integral plots of each part of the LVL2 Calo

processing time - after optimization

Largest contribution is from Data Preparation

Algorithm is the smallest contribution to the processing time



EF Data Flow

• In each EF Processor (EFP) the EFD application handles the flow of events

• The Event Selection Software runs in separate PT applications

• The complete event is in shared memory and the PT is passed a pointer (avoids copying)

• The PT write the EF Result into the shared memory

• For accepted events the Output task combines the EF Result into the event

EFP EFD InputTask

Sorting

Task

ExtPTs

Task

ExtPTs

Task

Output

Task

Counting

Task

Histogr.Task

PreProc.

Task

PostProc.

Task

PT

PT

PT

PT

PT

SFI

SFO



TDR Part 4 : Organization and Plan (3)

Workplan and schedule


Contributi italiani al TDR• Studio e validazione delle componenti DAQ

– Data Flow (Data Collection e Event Filter)– Online software (Configurazione, Monitoring, Run Control)– Detector software (ROD Crate DAQ, Data Format, Monitoring)

• Studio e validazione degli HLT– Software framework (Athena)– Algoritmi di livello-2 (Pixel e Muoni)– Algoritmi di filtro e calibrazione ottenuti dai programmi offline (e.g.

MOORE per la ricostruzione e CALIB per la calibrazione dei muoni)– Uso online dello schema di acceso ai dati dei rivelatori e alla loro

geometria secondo l’Event Data Model (definizione e sviluppo software dei formati ByteStream dei dati dei rivelatori utilizzati e della loro definizone ad oggetti, Raw Data Objects utile per gli algoritmi di trigger)

• Contributo alla scrittura e al coordinamento di importanti capitoli del TDR (vedi PESA)

Sono state prodotte dai gruppi italiani o in collaborazione con altri gruppi più di 20 note ATLAS quali documenti di supporto al TDR.


Milestones 2004• Marzo

– Integrazione Livello-2/Event Filter/DAQ su Testbed al CERN con il Livello-1 in emulazione.

• Ottobre – Integrazione Detector/Livello-1/Livello-2/Event Filter/DAQ/DCS su

Testbeam Combinato (Pixel-Lar-Tile-MDT-RPC).


Trigger scintillator

The HLT/DAQ at the test beam - 2003 In ATLAS, we value the strategy of real life use (test beam, test sites)

of “final system” software releases, used for performance measurements on test beds

The same complete DAQ (and HLT framework) software releaseis used on test bedsand at the test beam

ATLAS Combined run at H8 - Sep 2003Pixel - SCT - “Phantom EM” - TileCal - MDT - RPC - TGC ROD


H8 test beam setup - 2003H8 TDAQ



Dataflow performance at H8Event rate

Data throughput

Dataflow measured on a test-beam-like implementation of standard

release without and with

Event Filter framework

==> Performance beyond detector data-taking capability

0

20004000

60008000

1000012000

1400016000

18000

700 1700 2700 3700 4700 5700

ROS fragment size [bytes]

Eve

nt

rate

[H

z] no EF, no writingto disk

no EF, SFI writesto disk

with 1 EFD, with orwithout writing


TileCal Monitoring at H8

• Event Display and Monitoring taskbased on Online Software tools



In 2004 in H8…

• A Calorimeters Combined Test Beam– LAr & Tilecal on the same rotating table

• A Inner Detector Combined Test Beam– Pixels and SCT (in the same box?)– TRT with a barrel slice

• Muon chambers: MDT, RPC, TGC

Why not to have an ATLAS Barrel slice?


Set-up 2004


What type of measurements?

• This is a unique occasion to intercalibrate the Barrel e.m. and the hadronic calorimeters – Energy sharing– Shower containment– Weighting techniques studies– Linearity, resolution, e/h, etc.

• Alignment and tracking of the Inner Detector components• All interesting combinations


HLT/DAQ al Testbeam 2004

• Common Trigger Local Network Integrazione degli HLT (LVL2 & EF) Ultima versione del software DAQ (Data Flow &

Online) Migrazione da DAQ-1 a DAQ-0 (Pre-series prototype)

• Integrazione del DCS (Common Infrastructure & Sub-Detector layers)

Altri item comuni importanti anche per il DAQ


Many levels where to combine…

• Electronics and trigger– Master trigger & common busy in “normal” operations;

combination of TTC partitions; Timing of each sub-detector (long baseline)

– Readout: event-by-event; will all sub-detectors be read out in fully pipelined mode?

• Detectors & LVL1– Making sure that LVL1-sources are there, as well as

destinations• Tilecal & LAr tower signals• RPC (& TGC)


Many levels where to combine… (2)

• Detectors (via DAQ) & LVL2– All sub-detectors “contribute” to LVL2

• Detectors & DAQ– Review and install :

• Read-Out Links (input from sub-detectors)• DAQ ROS machines (Read-Out Systems)• DAQ SFI machines (Keeping today situation of 1 PC per

detector?)

– Use of the ATLAS TDAQ Data Format

• Detectors & DCS



• Event Filter – One of the most interesting places where to combine the

sub-detectors– It forces offline programs to be fast and ready well before

offline data analysis starts– Last year we had Pixel, Tilecal and Muons analysis

programs working together in EF, but never combining data of a given sub-detector with the others: this is what we must do,even if already done this year with Muon & Tile



• Offline– As soon as the geometry of the setup is defined, the

simulation of all detector components can start– A way to use the “combined reconstruction”– If everything works in ATHENA (ATLAS software

framework) also EF can benefit and vice versa– Analysis programs of the sub-detectors have to converge

to a unique output


Tentatively in 2004…(schedule dated 3/9/2003)

SPS proton run: 23 weeks + 2 “25 ns” weeks4-6 weeks at the beginning4-6 weeks at the end

Fully combined partially combined

Stand alone runs


Beam availability

• Pions, electrons– 1-9 GeV, 10-20 GeV, 30-300 GeV– Intensity up to 108/spill in specially shielded zones (4.8 sec spill).

Typical 106/spill

• Muons– 20-300 GeV– Intensity up to 106-107 (limited by radiation protection issues

because the zone is not completely shielded)

• Photons– Production of electron/photon by secondary beam at 180 GeV

maximum


Pixel

GPM

RODs

…SBC

ROD Crate

GPM

ROD

…SBC

SCT

ROD Crate

GPM

ROD

…SBC

TRT

ROD Crate

GPM

ROD

…SBC

Tilecal

ROD Crate

GPM

GPM

…SBC

Tilecal

Beam Crate

GPM

ROD

…SBC

MDT

ROD Crate

GPM

GPM

…SBC

Muons

Beam Crate

* n

GPM

ROD

…SBC

LAr

ROD Crate

* n

* n

GPM

ROD

…SBC

ROD Crate

RPC

ID ROS

LAr ROS

Tilecal ROS

Muon ROS1

Muon ROS2

LVL1 Calo ROS

CTP ROS

ROD

ROD

…SBC

LVL1 Calo

ROD Crate

ROD

ROD

…SBC

CTP & CTPI

ROD Crate

To EB/EF

Com

bin

ed

ru

n 2

004

- G

lob

al

layou

t


Additional h/w for HLT Vertical Slice• Additional hardware needed

– RoIB (Mk II ?)– 1 LVL2 Supervisor– 1 LVL2 Processor– 1 pROS

• DAQ + EF Hardware already in use at the Test Beam– 1 DFM– 1 SFI– 1 EF Processor– 1 SFO


OperatorIF

DataViewer

AlarmIF

ConfigDB

ConditionsDB

DCS_IS

DIPMagnet

CERN

LHCDSS DAQ IS

DAQ MRS

DAQ RC

DCS Back-End ArchitectureDCS Back-End Architecture

CIC

Global Control Station(GCS)

Tile Pixel SCT TRT LArMDT TGC RPC (CSC)

OP

C

LCSEB-

LCSB-

LCSB+

LCSEB+

Cooling LV HV Misc.

LCS

HECHV

OP

C

LCS

TempO

PC

LCS

ISEGHV

OP

C

LCS

FECrates

OP

C

HV/LV

OP

C

PC

Purity

OPCPVSS CAN

DDC

Local Control Stations (LCS)

Subdetector Control Stations (SCS)


DetectorDetector

DAQDAQ

DCSDCS

HLTHLT

OfflineOffline

ConfigurationData

ConditionsData

MeasuredConditions

All Conditions

Configuration & Conditions Databases(Data Flow – Physics Run)

52S.Falciano

• Goal is to treat the Combined Testbeam like a Data Challenge (approximately coincident in time with DC2)

• Major Software Releases Deliverables :– LCG Component Integration– Geant4 Integration & Validation

• Full detector simulation• Digitization in place for all detectors

– Pile-up Infrastructure in place• All detectors supported

– Detector Description Integration• Reconstruction and G4 Simulation from common geometry

– Calibration/alignment infrastructure in place– Physics Analysis environment

• Interactive as well as batch– GRID integration

Simulation, Reconstruction and Analysis tools

53S.Falciano

ATLAS Computing Timeline• POOL/SEAL release

• ATLAS release 7 (with POOL persistency) => end Oct 2003

• LCG-1 deployment

• ATLAS complete Geant4 validation

• ATLAS release 8 => begin Feb 2004

• DC2 Phase 1: simulation production

• DC2 Phase 2: intensive reconstruction (the real challenge!)

• Combined test beams (barrel wedge)

• Computing Model paper

• ATLAS Computing TDR and LCG TDR

• DC3: produce data for PRR and test LCG-n

• Computing Memorandum of Understanding

• Physics Readiness Report

• Start commissioning run

• GO!

2003

2004

2005

2006

2007

NOW


Evoluzione del sistema e staging

• Il sistema TDAQ è stato disegnato tale che dimensioni e performance evolvano in funzione della disponibilità delle risorse. Le performance finali corrispondono ad una trigger rate di Livello-1 di 100 kHz.

• La stima dei costi del TDAQ di ATLAS è basata su un modello dettagliato del numero di componenti in funzione della rate di trigger di Livello-1 (e.g. 37.5 kHz, 75 kHz, 100 kHz).

• Fattori di sicurezza sono applicati soprattutto nel tenere conto delle performance degli HLT (tempo di processamento degli eventi e fattori di reiezione) e del costo di componenti “custom” (come ad esempio i ROBin) e “commerciali” (come ad esempio i processori).

• Si è arrivati a definire un profilo temporale di spesa che è un’evoluzione del sistema a partire dal commissioning del detector fino alla realizzazione di un TDAQ con le sue performance finali


Costi HLT/DAQ

Architettura scalabile-> implementazione ottimale del piano di

deferral dei finanziamenti e di upgrade futuri


Pre-serie di HLT e DAQ • Include una versione su piccola scala del sistema allo scopo di validare

l’implementazione del TDAQ (e.g. 10% di Detector R/O, 1 switch per LVL2, 1 switch per EF, 2 sub-farm nella loro versione a “rack” di ATLAS e 5% del sistema online)

• Il dimensionamento è stato fatto essenzialmente su criteri di “funzionalità”

• E’ un sistema di dimensioni superiori ai testbed di cui disponiamo attualmente utilizzati per fare sviluppi e misure di performance. All’uopo si possono aggregare i due switch e le due sub-farm per provare solo il LVL2 o solo l’EF in una configurazione più estesa

• Si basa sulle tecnologie finali • Userà il software finale del Data Flow e dell’Online• L’uso previsto è in laboratorio, ma in caso di necessità si potrà utilizzare

per far partire il commissioning del Tile Calorimeter (primo rivelatore ad installarsi)


Conclusioni (1)

• Il sistema Trigger&DAQ di ATLAS sarà implementato con tre livelli di trigger e farà uso del meccanismo di Region-of-Interest: Importante riduzione nel trasferimento dei dati

• Il disegno del sistema è completo ma aperto a: Ottimizzazione dell’ I/O a livello di Read-Out System Ottimizzazione dell’uso dei network di LVL2 e Event Builder

• L’architettura è stata validata con: Testbed di varie dimensioni e ottimizzati per scopi diversi Test Beam ad H8

• L’architettura è scalabile: Permettendo il piano di “deferral” di ATLAS Aperta a futuri upgrade


Conclusioni (2)

• Studi di performance degli HLT sono basati su algoritmi completi e su dati con un formato realistico. La preparazione dei dati (non il tempo di accesso) richiede un

tempo di processamento sostanzioso.

• La strategia di ATLAS di usare delle componenti software dell’Offline per gli HLT è fattibile e sostenuta da misure recenti.

• Si è stabilito un utile link Online-Offline che ha prodotto: Sharing degli sviluppi Feedback per una ottimizzazione globale del software.


Riserve


Costi di HLT/DAQ (approx.) in kCHF

2004 2005 2006 2007 2008 2009 Totale(kCHF)

Profilo 1000 3800 4900 4800 8200 4300 27000

Deferral(13%->)

13500(1755)

Coommon Funds

1500

NuovoProfilo

14500 3800 4900 2300 0 0

INFN(13%)

130 +1755

494 637 299 0 0 3315(3300)


Costi di HLT/DAQ (approx.) in kEuro

2004 2005 2006 2007 2008 2009 Totale(kEuro)

Profilo 684 2599 3352 3283 5609 2941 18468

Deferral(13% ->)

9234(1200)

Coommon Funds

1026

NuovoProfilo

9918 2599 3352 1573 0 0

INFN(13%)

89 +1200

338 436 204 0 0 2267(2066)

Documents

Gruppo1 - Lecce 24/09/2003 S.Falciano - INFN Roma1 ATLAS High Level Trigger/DAQ S.Falciano - INFN Roma1