1 / 62

ATLAS High Level Trigger/DAQ

ATLAS High Level Trigger/DAQ. S.Falciano - INFN Roma1. La presentazione è rivolta essenzialmente ad illustrare il piano finanziario 2004-2009 del sistema HLT/DAQ di ATLAS, discusso con i Referee della CSN1 negli ultimi mesi (se ne chiede l’approvazione in vista del RRB di Aprile). Outline.

morse
Download Presentation

ATLAS High Level Trigger/DAQ

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. ATLAS High Level Trigger/DAQ S.Falciano - INFN Roma1 CSN1 - 6/4/2004 S.Falciano - INFN Roma1

  2. La presentazione è rivolta essenzialmente ad illustrare il piano finanziario2004-2009 del sistema HLT/DAQ di ATLAS, discusso con i Referee della CSN1 negli ultimi mesi (se ne chiede l’approvazione in vista del RRB di Aprile). CSN1 - 6/4/2004 S.Falciano - INFN Roma1

  3. Outline • Breve riassunto delle caratteristiche del TDAQ di ATLAS : rates, bandwidth, performance, etc. • Criteri che hanno portato al disegno attuale : TDR “Baseline architecture” • Scenari di LHC per lavorare per il TDR -> Trigger menu • Cosa è cambiato • Presentazione del piano di spesa HLT/DAQ • “Baseline architecture” e Costi Globali • Piano finananziario CORE proposto per l’INFN • Addendum al MoU per il RRB del 26 Aprile 2004 • Problema dei “deferrals” e documenti disponibili • Risposte alle domande dei Referee • Meeting telefonico del 20 febbraio 2004 • Incontro del 16 e 17 marzo 2004 • Aggiornamento sul piano di lavoro per il 2004 • Conclusioni CSN1 - 6/4/2004 S.Falciano - INFN Roma1

  4. Detectors 1 GHz interaction rate / 40 MHz bunch-crossing rate Front-end 2ms latency Level 1 Pipelines <75 (100) kHz Readout Drivers O(10) ms latency Level 2 Readout Buffers O(1) kHz output rate Event Builder HLT Buffers & ~ seconds latency Event Filter Processing Farms O(100) Hz output rate Data Storage LVL1 • Hardware based (FPGA and ASIC) • Coarse calorimeter granularity • Trigger muon detectors ATLAS Trigger / DAQ Architecture LVL2 • Region-of-Interest (RoI) concept • Specialized algorithms • Fast selection with early rejection RoI Pointers EF • Full event available • Offline derived algorithms • Seeding by LVL2 • Best calibration / alignment • Latency less demanding CSN1 - 6/4/2004 S.Falciano - INFN Roma1

  5. ARCHITECTURE 40 MHz ROD 75 kHz 120 GB/s ROB ROB ROB ROIB L2SV L2N ~2+4 GB/s L2P ~2 kHz EBN SFI DFM EFN EFP EFP EFP EFP SFO ~ 200 Hz ~ 300 MB/s Trigger DAQ Calo MuTrCh Other detectors 40 MHz D E T RO LV L1 FE Pipelines 2.5 ms Lvl1 acc = 75 kHz Read-Out Drivers RoI RoI data = 1-2% 120 GB/s Read-Out Links D A T A F L O W H L T ~ 10 ms Read-Out Buffers LVL2 ROS RoI requests RoI Builder L2 Supervisor L2 N/work L2 Proc Unit Read-Out Sub-systems Lvl2 acc = ~2 kHz Dataflow Manager EB Event Building N/work ~ sec Event Filter Sub-Farm Input ~4 GB/s Event Builder Event Filter Processors Event Filter N/work EFacc = ~0.2 kHz Sub-Farm Output CSN1 - 6/4/2004 S.Falciano - INFN Roma1

  6. Strategia di selezione online degli eventi (1) • Il trigger di ATLAS si basa sul concetto di “physics objects” (muoni, elettroni, jet, …) • Oggetti “candidati” sono tipicamente identificati prima al LVL1 dove si ricostruiscono localmente (Calorimetri e Spettrometro per Muoni) • Gli HLT raffinano la ricostruzione, rigettano i “fake” e migliorano la precisione sui parametri misurati dell’oggetto (pT, …) • Gli oggetti vengono ricostruiti sia a livello di singolo rivelatore (come nel LVL1) sia attraverso una ricostruzione combinata di più rivelatori (HLT) • Gli oggetti vengono combinati insieme (Trigger menus) per formare delle “ipotesi di fisica”. • La derivazione dei Trigger Menus e delle soglie parte da un’analisi dei requirements di fisica, seguita da una verifica della capacità di reiezione ai vari livelli e infine prende in considerazione stime della bandwidth totale disponibile negli HLT (procedura iterativa). CSN1 - 6/4/2004 S.Falciano - INFN Roma1

  7. Strategia di selezione online degli eventi (2) • Differenti Trigger Menus sono previsti per il programma iniziale alla luminosità di picco di 2x1033 cm-1s-1 : • Inclusive physics triggers : formano il bulk della selezione online e sono scelti per garantire la copertura di gran parte del programma di fisica • Pre-scaled physics trigger : estendono la copertura del programma di fisica di Atlas includendo selezioni inclusive con soglie più basse al fine di allargare i sample di eventi utili per lo studio del fondo e delle performance dei rivelatori. • Exclusive physics triggers : estendono anche essi la copertura del programma di fisica. • Dedicated monitor & calibration triggers CSN1 - 6/4/2004 S.Falciano - INFN Roma1

  8. Gli scenari perlo “start-up” di LHC (2002) • Fino al 2001 (base per l’elaborazione del TP per HLT/DAQ/DCS) • 3 anni a 1x1033 “low luminosity” • più anni a 1034  “design luminosity” • Approccio semplificato, ma ipotesi di lavoro stabili • Nel 2001 e 2002 : • Nuovi scenariproposti a ritmi sempre più frequenti • Scenario di Ottobre 2002 (LHCC minutes, R. Cashmore note) • Statistica: ~10 fb-1ottenibili dal primo run di fisica • Durata: ~200 giorni di presa dati • Duty cycle: ~60%(14 hdi durata di un fill, 10 h perrefill) • Luminosità: 2x1033 CSN1 - 6/4/2004 S.Falciano - INFN Roma1

  9. LVL1 Trigger menus Adjusting of some thresholds to obtain similar output rate at 2x1033 as was foreseen at 1x1033 CSN1 - 6/4/2004 S.Falciano - INFN Roma1

  10. HLT rates for 2x1033 CSN1 - 6/4/2004 S.Falciano - INFN Roma1

  11. Selection signatures @L = 2·1033 cm-2s-1 + pre-scaled, monitor, calibration triggers CSN1 - 6/4/2004 S.Falciano - INFN Roma1

  12. Lo scenario di “deferral/staging” (2002) • “Staging” iniziale del detector • Alcune componenti rilevanti per le trigger performance mancheranno • layer medio dei pixel, wheels più esterni del TRT, parte dei readout drivers (ROD) del LAr, … • Significanza ridotta per la scoperta dell’ Higgs leggero (~ -10%) • Compensata da un aumento di ~ 20% di luminosità integrata • Massima rate al LVL1 di 50 kHz (LAr RODs) • Al TDAQ è stato chiesto nel 2002 cosa succederebbe se si operassero tagli drastici alle proprie spese per finanziare gli extra-costi dei progetti comuni • Comporterebbe tagli drastici al sistema iniziale di HLT/DAQ (rimarrebbe solo 1/3- 1/2 del CORE budget) • Rimandare l’acquisto di componenti commerciali di network / processori • Restringerebbe in maniera severa la capacità di rate/bandwidth • Meno di 1/2 di design rate capability (30-35 kHz peak LVL1 rate) • limiterebbe la B-physics & metterebbe a rischio parte della fisica di high-pT • Meno di 1/5 di design rate capability (10-15 kHz peak LVL1 rate ) • comporterebbe tagli drastici al programma di fisica di high-pT CSN1 - 6/4/2004 S.Falciano - INFN Roma1

  13. Preparazione del TDR • Si è assunto uno scenario di start-up ed evoluzione di LHC tale che : • 2007 – start-up a 2x1033 cm-2 s-1 per un anno • 2008 – luminosità nominale di 1x1034 cm-2 s-1 • Si è assunto che il piano di spesa dovesse tenere conto del “Completion Plan” di Atlas CSN1 - 6/4/2004 S.Falciano - INFN Roma1

  14. 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 CSN1 - 6/4/2004 S.Falciano - INFN Roma1

  15. Part 1 - Global View 1. Overview 2. Parameters 3. System Operations 4. Physics selection strategy 5. Architecture 6. Fault tolerance and error handling 7. Monitoring Part 2 - System Components 8. Data-flow 9. High-level trigger 10. Online Software 11. DCS 12. Experiment Control Part 3 - System Performance 13. Physics selection and HLT performance 14. Overall system performance and validation Part 4 - Organisation and Plan 15. Quality assurance and development process 16. Costing 17. Organisation and resources 18. Workplan and schedule CSN1 - 6/4/2004 S.Falciano - INFN Roma1

  16. TDR “Baseline architecture” La 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. CSN1 - 6/4/2004 S.Falciano - INFN Roma1

  17. Una milestone importante per ATLAS è stata la conclusione positiva del processo di review del TDR di HLT/DAQ/Control alla fine del 2003 CERN/LHCC 2003-069/G-067: ‘The LHCC finds both the technology adopted and the procedures proposed for the ATLAS HLT/DAQ/DCS to be adequate to achieve the physics goals stated in the Technical Proposal, and congratulates the ATLAS Collaboration on the quality of the work presented in the TDR.’ ‘The LHCC therefore recommends general approval of the ATLAS HLT/DAQ/DCS TDR.’ CSN1 - 6/4/2004 S.Falciano - INFN Roma1

  18. Cosa non è cambiato rispetto al TP • L’architettura TDAQ di Atlas è basata su tre livelli di trigger • Il primo Livello (LVL1) è un trigger implementato in hardware, il secondo (LVL2) e terzo (Event Filter) sono trigger software • Il secondo Livello funziona sul concetto di Region-of-Interest CSN1 - 6/4/2004 S.Falciano - INFN Roma1

  19. Meccanismo delle RoI - Implementazione • C’è una corrispondenza semplice tra :h-f 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 ==> ATLAS RoI-based Level-2 trigger … ~ ReadOut network più piccolo di un ordine di grandezza … … al costo di un maggiore traffico di controllo … 4 RoI -faddresses CSN1 - 6/4/2004 S.Falciano - INFN Roma1

  20. Level-2 Trigger Three parameters characterise the RoI-based Level-2 trigger: the amount of data required : 1-2% of total the overall CPU time : 10 ms average the rejection factor: x 30 CSN1 - 6/4/2004 S.Falciano - INFN Roma1

  21. Cosa è cambiato (1) • L’implementazione della parte di Read-out accoppiata ai Rivelatori : ROS, ReadOut System • ROD Crate (responsabilità Hw/Sw : Rivelatore) • ROS (responsabilità Hw/Sw : DAQ) • Nuova implementazione Hw del ROS basata su PC invece che VME • Nuova implementazione del Sw del ROD Crate (ROD Crate DAQ) ora di responsabilità DAQ. Ciò uniforma la DAQ Locale nel ROD Crate per tutti i Rivelatori (supporto centralizzato per local processing, configurazione, event sampling, etc.) CSN1 - 6/4/2004 S.Falciano - INFN Roma1

  22. R C P R O D R O D R O D R O D NIC ROD Crate Workstation ROBIN ROBIN ROBIN RCD and ROS F.E. Electronics Event Fragments (Detector specific) Config & Control VME bus Event sampling & Calibration data … ROD Crates Config & Control Event sampling & Calibration data LAN (GbEth.) ROLs ROD Fragments • Total number of ROD crates: 90 • Total number of ROS PCs : 144 • Total number of racks : ~15” ==>All in USA15 (underground) … ROS PCs … PCI bus ROB Fragments ROS Fragments GbEth. L2 & Event Builder Networks CSN1 - 6/4/2004 S.Falciano - INFN Roma1

  23. The ROBin Prototype CSN1 - 6/4/2004 S.Falciano - INFN Roma1

  24. Cosa è cambiato (2) • L’ I/O path del ReadOut System (ROS) • Opzione 1 : Bus Based path (il BUS è il PCI) • Opzione 2 : Switched Based path (GEth) • La preoccupazione è quella di aggiungere scalabilità al sistema CSN1 - 6/4/2004 S.Falciano - INFN Roma1

  25. S-Links PCI bus ROBIN GbE I/O path for Read-Out System • In TDR (30 June 2003): • “The optimisation of the ROS architecture will be the subject of post-TDR studies” using a Read-Out Buffer (ROBIN) prototype implementing bus-based (PCI) and switched-based (GEth) I/O paths • Schedule and milestones to match ATLAS commissioning • ROBIN Final Design Review completed LHCC 31.05.04 • Final decision on ROS Input/Output path EB 31.12.03 CSN1 - 6/4/2004 S.Falciano - INFN Roma1

  26. NIC ROBIN ROBIN ROBIN PCI bus S-Links Increased scalability if/when needed PCI bus ROBIN GbE GbEthernet L2 & Event Builder Networks I/O path for Read-Out System • On 11 Dec 2003, TDAQ decision was made:Bus-Based (BB) with Switch-Based (SB) as option for increased scalability • ROBIN :3 Slink input - PCI and GEth output • Max input retaining max output functionality • High potential for scalability and upgrades • The baseline implementation of the ROS would be BB with an upgrade path to combined BB and SB I/O or only SB I/O for future upgrades. Full assessment of the potential of the SB Read-Out will be done as soon as possible (planning in preparation), so as to be ready with a viable upgrade if and when needed. CSN1 - 6/4/2004 S.Falciano - INFN Roma1

  27. Cosa è cambiato (3) • Organization & resources CSN1 - 6/4/2004 S.Falciano - INFN Roma1

  28. 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 gruppipiù di 20 note ATLASquali documenti di supporto al TDR. CSN1 - 6/4/2004 S.Falciano - INFN Roma1

  29. Presentazione del piano di spesa • L’INFN si era impegnato a dare 3.3 MCHF per il sistema HLT/DAQ. • Al RRB del 26 Aprile si chiederà all’INFN di mantenere questo impegno a fronte del lavoro svolto dai gruppi italiani e di una definizione abbastanza dettagliata dell’architettura, delle sue componenti e dei suoi costi presentata nel recente TDR. • A fronte di questa richiesta i gruppi italiani si sono impegnati nella preparazione di un documento che mostra la congruità di questa cifra e presenta una suddivisione in categorie di spesa versus gli impegni della collaborazione. • Questo documento è stato presentato e discusso prima nel TDAQ Resource Committee (Resource Coordinator + Rappr. delle FAs) e poi presentato ai Referee e al Presidente della CSN1. • I profili di spesa globali e i finanziamenti delle FAs sono parte integrante dell’Addendum al MoU che verrà presentato al RRB di Aprile. CSN1 - 6/4/2004 S.Falciano - INFN Roma1

  30. New MoU table CSN1 - 6/4/2004 S.Falciano - INFN Roma1

  31. HLT/DAQ system cost profile (unit is kCHF) as published in the TDR CSN1 - 6/4/2004 S.Falciano - INFN Roma1

  32. Costi HLT/DAQ Architettura scalabile-> implementazione ottimale del piano di deferral dei finanziamenti e di upgrade futuri CSN1 - 6/4/2004 S.Falciano - INFN Roma1

  33. Premessa • La Collaborazione italiana HLT/DAQ è costituita da 230 membri : 32 di questi sono di istituti italiani (firme TDR) e rappresentano il 14% del totale. • Consideriamo dunque appropriato un contributo finanziario al progetto proporzionale a questa frazione e infatti 3.3 MCHF rappresentano circa il 14% del costo totale del sistema. CSN1 - 6/4/2004 S.Falciano - INFN Roma1

  34. “Aree di attività” dei gruppi italiani • Algoritmi di trigger di Livello-2 • Studi di performance del Livello-2 su Testbeds • Algoritmi di Event Filter • Studi di performance dell’Event Filter su Testbed e sviluppo dell’Event Filter Data Flow • DAQ • Detector Monitoring (anche su EF farm) per Pixel, Lar, Tile, MDT e RPC. • Trigger Monitoring per LVL1 e HLT • Detector/TDAQ integration ai Test Beam e nei Test Labs. CSN1 - 6/4/2004 S.Falciano - INFN Roma1

  35. Criteri per la selezione di aree funzionali e componenti da finanziare (1) • L’attività italiana è fortemente Detector-oriented. Il lavoro sui Test Beam ha rafforzato questo concetto poiché diversi step d’integrazione Detector-Readout-TDAQ sono stati portati avanti insieme. • Il lavoro sui Testbeds per sviluppare e testare prototipi DAQ e HLT è stato per noi molto importante. • Inoltre l’implementazione di algoritmi di trigger basati sui rivelatori in costruzione in Italia è stata una frazione molto grande della nostra attività. • Infine va ricordato che l’implementazione della simulazione completa di una slice verticale del trigger di muoni (LVL1-LVL2-EF) è stata possibile anche grazie al lavoro portato avanti nell’INFN sul trigger di muoni di primo livello. CSN1 - 6/4/2004 S.Falciano - INFN Roma1

  36. Criteri per la selezione di aree funzionali e componenti da finanziare (2) • La scelta delle aree da finanziare deve tenere conto di tutto ciò. • Perciò sembra appropriato finanziare le seguenti categorie di spesa: • Pre-serie (partecipazione ai test di validazione del sistema finale HLT/DAQ) • Detector Read-Out (Rack based, PC based, un rack contiene 11 PCs, un local file server, un local switch, un rack controller, power e cooling distribution. Il costo di un rack è di 110 kCHF. Vogliamo finanziare : • 11 ROSes per i Pixel • 16 ROSes per lo Spettrometro a Muoni • 8 ROSes per il Tile Per un totale di 5 racks (5 x 110 kCHF = 550 kCHF, 13% del R/O totale). • Processori di LVL2 e EF (Rack mounted, PC sono Dual-CPUs con Linux, 18% di contributo per il LVL2, 11.4% per l’EF) CSN1 - 6/4/2004 S.Falciano - INFN Roma1

  37. 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) Richiesta sblocco s.j. a settembre. CSN1 - 6/4/2004 S.Falciano - INFN Roma1

  38. Criteri per la selezione di aree funzionali e componenti da finanziare (3) • EF I/O (gli SFI sono PC come quelli dell’EF, rack mounted. La partecipazione italiana al Data Flow e al Monitoring giustifica un contributo del 13%) • Online (include le farm di processori per l’Online software, ossia Run_control, inizializzazione, etc. e dovrebbe rappresentare anche la frazione di monitoring dei rivelatori. Proposta di contributo del 20%) • Infrastruttura – Common items (si considera ragionevole fissare un piccolo fondo per item comuni che difficilmente ricadono nelle categorie precedenti quali licenze software, link al centro di calcolo, etc. Si pensa che esso debba essere di circa il 6% per l’INFN). CSN1 - 6/4/2004 S.Falciano - INFN Roma1

  39. Requested INFN funds for the HLT/DAQ system (unit is kCHF) CSN1 - 6/4/2004 S.Falciano - INFN Roma1

  40. INFN cost profile (unit is kCHF) for the chosen categories (*) The funds for the staged part of the detectors (such as the Pixels) should fall in the year 2008. Therefore they might be subtracted from those of the years 2005-2006, which correspond to the full detector, and moved in 2008. CSN1 - 6/4/2004 S.Falciano - INFN Roma1

  41. Documenti disponibili(alla CSN1 e al RRB del 26 aprile 04) • INFN funds for ATLAS HLT/DAQ • INFN Genova, LNF, Lecce, Napoli, Pavia, Pisa*, Roma1, Roma3 • Addendum to MoU • HLT/DAQ Common Items • ATLAS Agreement N°144/03 • Recognition and Use of the TDAQ Deferral Funding • HLT/DAQ Funding Profiles • DCS Cost Sharing * Al momento la Sezione di Pisa non è inclusa nella collaborazione TDAQ. CSN1 - 6/4/2004 S.Falciano - INFN Roma1

  42. Infrastructure - “Common Items” • Documento che stabilisce le regole di spesa degli items di infrastruttura • Fondi gestiti attraverso un Team account speciale al CERN • Si richiede alle FAs di approvare la spesa • Il TDAQ Resource Coordinator informa le FAs e l’IB sulle spese del Team. Approvato all’IB del 25 feb. 2004. CSN1 - 6/4/2004 S.Falciano - INFN Roma1

  43. Documento che stabilisce un meccanismo di controllo sui “deferral” (agreement tra ATLAS e Funding Agency) : • Obligations of the Parties • Return of deferred funds to TDAQ (decided by the TDRC, in line with the work plan defined in the TDR and in agreement with the TDIB and ATLAS management). CSN1 - 6/4/2004 S.Falciano - INFN Roma1

  44. Risposte ad alcune domande dei Referee (1) • Costo di HLT/DAQ del TDR vs MoU • Saclay e Turchia si sono ritirate portando via rispettivamente 3.9 MCHF+CFs e 150 kCHF. • Queste mancanze non sono state ripristinate e quindi il costo inferiore del sistema deve essere riassorbito dalle altre FAs • I 27000 kCHF sono la somma di 25500 kCHF delle FAs e 1500 kCHF di CFs CSN1 - 6/4/2004 S.Falciano - INFN Roma1

  45. Risposte ad alcune domande dei Referee (4) • Chiarimenti sui costi del DCS • Atlas-Italia non contribuisce al DCS centrale. • Il costo del DCS e' rimasto invariato rispetto al passato (1800 kCHF + Common Funds). Poiche' nel TDR sono stati riportati anche i Common Funds allocati al DCS (e non nel capitolo TDAQ del MoU), cio' appare come un aumento. • In conclusione, la divisione dei fondi per il DCS e', ed e' sempre stata: CERN 1600. kCHF, NIKHEF 200. kCHF, Common Funds 1325. kCHF. CSN1 - 6/4/2004 S.Falciano - INFN Roma1

  46. Risposte ad alcune domande dei Referee (2) • Criteri per la scelta del profilo temporale di spesa • Abbiamo disegnato un sistema che evolve in funzione delle risorse disponibili, che va da un sistema iniziale con una rate massima di LVL1 di circa 40 kHz ad uno finale con una rate massima di 100 kHz 2004 :Acquisto e messa in opera della pre-serie fatta con le componenti finali del TDAQ (commissioning del Tile?) 2005: Inizia il commissioning dei detector e di HLT/DAQ. Ai detector serve il 75% dei Detector Readout. 2006 :Commissioning. Run di cosmici. 2007 :LHC start-up. 37% circa delle farm HLT disponibili. 37.5 kHz è la rate di LVL1 sostenibile. Mancano il 25% dei ROD. 2008 :LHC alla lminosità nominale, 75 kHz di rate di LVL1. Questo è il momento in cui cominciano a tornare indietro i deferral. 2009 :Sistema completo con le performance per cui è stato disegnato, ossia rate di LVL1 di 100 kHz. Nota : nella fase iniziale la priorità viene data agli aspetti DAQ perche’ essi servono per il commissioning del rivelatore, mentre le farm HLT e in particolare il LVL2, vengono dimensionate al minimo. CSN1 - 6/4/2004 S.Falciano - INFN Roma1

  47. Workplan and schedule (TDR) CSN1 - 6/4/2004 S.Falciano - INFN Roma1

  48. Risposte ad alcune domande dei Referee (3) • Stabilità dei costi • Abbiamo lavorato tenendo conto delle migliori stime, ad oggi, sull’evoluzione dei processori. • Il progetto GRID e il gruppo Cern di technology tracking ha osservato che il comportamento delle performance dei processori è sotto la curva aspettata. • Poiché anche i tempi e le modalità di funzionamento della macchina sono indicativi ed esistono incertezze sui tempi di processamento degli eventi, si è scelto di fissare la potenza dei processori a un valore indicativo che rappresenta la media delle prestazioni aspettate nell’intervallo 2006-2009. • Si è assunto una Dual-CPU (high-end) a 8 GHz al costo indicato nel rapporto GRID del Cern, ossia 4 kCHF. E’ stato applicato un fattore di sicurezza del 30% per tenere conto delle incertezze. CSN1 - 6/4/2004 S.Falciano - INFN Roma1

  49. Risposte ad alcune domande dei Referee (5) • Chiarimenti sui costi M&O-A e Common Items Nel documento : "Memorandum of Understanding for Maintenance and Operation of the ATLAS Detector", ATLAS LHC Meeting 14. CERN-RRB-2002-035, CERN 5 April 2002 (disponibile sul web). In esso, all'Annex 9 : Category A Headings for ATLAS M&O, Cost Categorization, troviamo: Online Computing (no recording media) System management Data storage, (temporary on disk) Detector controls Computer/processors/LANs Software licences Common desktop infrastructure CSN1 - 6/4/2004 S.Falciano - INFN Roma1

  50. Risposte ad alcune domande dei Referee (5 cont) • La differenza sta nel fatto che i costi dei nostri Common Items sono "costi iniziali", mentre quelli di M&O-A sono "costi ricorrenti", ossia le possibili integrazioni/sostituzioni/update/etc. che saranno sicuramente necessarie per il sistema. • I fondi M&O non possono essere utilizzati per comprare inizialmente un sistema o una parte di esso, ma servono per mantenerlo funzionante nel tempo con le stesse prestazioni. CSN1 - 6/4/2004 S.Falciano - INFN Roma1

More Related