Gruppo1 - Lecce 24/09/2003 S.Falciano - INFN Roma1 ATLAS High Level Trigger/DAQ S.Falciano - INFN...
-
Upload
petronel-martino -
Category
Documents
-
view
219 -
download
0
Transcript of Gruppo1 - Lecce 24/09/2003 S.Falciano - INFN Roma1 ATLAS High Level Trigger/DAQ S.Falciano - INFN...
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
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
Gruppo1 - Lecce 24/09/2003 S.Falciano - INFN Roma1
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)
Gruppo1 - Lecce 24/09/2003 S.Falciano - INFN Roma1
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
Gruppo1 - Lecce 24/09/2003 S.Falciano - INFN Roma1
• 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
Gruppo1 - Lecce 24/09/2003 S.Falciano - INFN Roma1
• 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.)
Gruppo1 - Lecce 24/09/2003 S.Falciano - INFN Roma1
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
Gruppo1 - Lecce 24/09/2003 S.Falciano - INFN Roma1
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
Gruppo1 - Lecce 24/09/2003 S.Falciano - INFN Roma1
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.
Gruppo1 - Lecce 24/09/2003 S.Falciano - INFN Roma1
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
Gruppo1 - Lecce 24/09/2003 S.Falciano - INFN Roma1
• 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
Gruppo1 - Lecce 24/09/2003 S.Falciano - INFN Roma1
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
Gruppo1 - Lecce 24/09/2003 S.Falciano - INFN Roma1
TDR Part 2 : System components
• Data Flow (DAQ)• High-Level Triggers
– LVL2, EF, Event Selection Software (ESS)
• Online Software (DAQ)• DCS• Experiment Control
Gruppo1 - Lecce 24/09/2003 S.Falciano - INFN Roma1
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
Gruppo1 - Lecce 24/09/2003 S.Falciano - INFN Roma1
The ROBin Prototype
Gruppo1 - Lecce 24/09/2003 S.Falciano - INFN Roma1
Gruppo1 - Lecce 24/09/2003 S.Falciano - INFN Roma1
Gruppo1 - Lecce 24/09/2003 S.Falciano - INFN Roma1
HLT Event Selection Software
Gruppo1 - Lecce 24/09/2003 S.Falciano - INFN Roma1
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
Gruppo1 - Lecce 24/09/2003 S.Falciano - INFN Roma1
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
Gruppo1 - Lecce 24/09/2003 S.Falciano - INFN Roma1
LVL2 track reconstruction for b-tagging selection
Impact parameter resolution vs pT u-jet rejection vs b-tagging efficiency
Gruppo1 - Lecce 24/09/2003 S.Falciano - INFN Roma1
Fast physicsperformance
HLT TP, layout M HLT TDR, layout P
Perfect match of the two resolutions for pt = 20 GeV
HLT TP, layout M
Gruppo1 - Lecce 24/09/2003 S.Falciano - INFN Roma1
MOORE – Event Filter muon reconstruction
Risoluzione in impulso Efficienza
Gruppo1 - Lecce 24/09/2003 S.Falciano - INFN Roma1
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
Gruppo1 - Lecce 24/09/2003 S.Falciano - INFN Roma1
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
Gruppo1 - Lecce 24/09/2003 S.Falciano - INFN Roma1
Gruppo1 - Lecce 24/09/2003 S.Falciano - INFN Roma1
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
Gruppo1 - Lecce 24/09/2003 S.Falciano - INFN Roma1
Gruppo1 - Lecce 24/09/2003 S.Falciano - INFN Roma1
TDR Part 4 : Organization and Plan (3)
Workplan and schedule
Gruppo1 - Lecce 24/09/2003 S.Falciano - INFN Roma1
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.
Gruppo1 - Lecce 24/09/2003 S.Falciano - INFN Roma1
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).
Gruppo1 - Lecce 24/09/2003 S.Falciano - INFN Roma1
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
Gruppo1 - Lecce 24/09/2003 S.Falciano - INFN Roma1
H8 test beam setup - 2003H8 TDAQ
Gruppo1 - Lecce 24/09/2003 S.Falciano - INFN Roma1
Gruppo1 - Lecce 24/09/2003 S.Falciano - INFN Roma1
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
Gruppo1 - Lecce 24/09/2003 S.Falciano - INFN Roma1
TileCal Monitoring at H8
• Event Display and Monitoring taskbased on Online Software tools
Gruppo1 - Lecce 24/09/2003 S.Falciano - INFN Roma1
Gruppo1 - Lecce 24/09/2003 S.Falciano - INFN Roma1
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?
Gruppo1 - Lecce 24/09/2003 S.Falciano - INFN Roma1
Set-up 2004
Gruppo1 - Lecce 24/09/2003 S.Falciano - INFN Roma1
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
Gruppo1 - Lecce 24/09/2003 S.Falciano - INFN Roma1
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
Gruppo1 - Lecce 24/09/2003 S.Falciano - INFN Roma1
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)
Gruppo1 - Lecce 24/09/2003 S.Falciano - INFN Roma1
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
Gruppo1 - Lecce 24/09/2003 S.Falciano - INFN Roma1
Many levels where to combine… (4)
• 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
Gruppo1 - Lecce 24/09/2003 S.Falciano - INFN Roma1
Many levels where to combine… (5)
• 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
Gruppo1 - Lecce 24/09/2003 S.Falciano - INFN Roma1
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
Gruppo1 - Lecce 24/09/2003 S.Falciano - INFN Roma1
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
Gruppo1 - Lecce 24/09/2003 S.Falciano - INFN Roma1
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
Gruppo1 - Lecce 24/09/2003 S.Falciano - INFN Roma1
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
Gruppo1 - Lecce 24/09/2003 S.Falciano - INFN Roma1
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)
Gruppo1 - Lecce 24/09/2003 S.Falciano - INFN Roma1
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
Gruppo1 - Lecce 24/09/2003 S.Falciano - INFN Roma1
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
Gruppo1 - Lecce 24/09/2003 S.Falciano - INFN Roma1
Costi HLT/DAQ
Architettura scalabile-> implementazione ottimale del piano di
deferral dei finanziamenti e di upgrade futuri
Gruppo1 - Lecce 24/09/2003 S.Falciano - INFN Roma1
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)
Gruppo1 - Lecce 24/09/2003 S.Falciano - INFN Roma1
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
Gruppo1 - Lecce 24/09/2003 S.Falciano - INFN Roma1
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.
Gruppo1 - Lecce 24/09/2003 S.Falciano - INFN Roma1
Riserve
Gruppo1 - Lecce 24/09/2003 S.Falciano - INFN Roma1
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)
Gruppo1 - Lecce 24/09/2003 S.Falciano - INFN Roma1
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)