Dott. Pierluigi Paolucci

Presentazione sul tema: "Dott. Pierluigi Paolucci"— Transcript della presentazione:

1 Dott. Pierluigi Paolucci
Large Hadron Collider CMS Aleph LEP - LHC Alice Opal L3 Two superconducting magnet rings in the SPS LEP tunnel. LHCb Delphi PS ATLAS Experiments at LHC ATLAS A Toroidal LHC ApparatuS. (Study of Proton-Proton collisions) CMS Compact Muon Solenoid. (Study of Proton-Proton collisions) ALICE A Large Ion Collider Experiment. (Study of Ion-Ion collisions) LHCb (Study of CP violation in B-meson decays at the LHC collider) 16/09/2018 Dott. Pierluigi Paolucci

2 Dott. Pierluigi Paolucci
Gli esperimenti di LHC Gli apparati sperimentali sono molto grandi e composti da almeno 4 sottosistemi (Tracciatore, Calorimetri e spettrometro per muoni) Ogni sottosistema ha il suo sistema di Trigger, DAQ e DCS indipendenti (locali) I trigger ed i DAQ locali convergono poi in un unico sistema centrale dove i dati vengono visti come un unico insieme. Vista la grande quantità di dati che i sistemi locali devono trattare in un tempo così breve (25 ns) nasce l’esigenza di avere dei sistemi di trigger e di DAQ che siano molto veloci (40 MHz) e che possano scambiare dati ad una velocità elevatissima  NETWORKING A questa va poi aggiunta la necessità di avere un’enorme quantità di dati memorizzata definitivamente … in qualche modo. 16/09/2018 Dott. Pierluigi Paolucci

3 Problematiche generali
N (canali) ­ O(107); 20 interazioni ogni 25 ns enorme numero di connessioni networking Dati di sotto-rivelatori devono corrispondere sincronizzazione dei dati in 25 ns Segnali/time of flight del rivelatore > 25 ns identificazione del bunch crossing • Bisogna memorizzare i dati a 100 Hz selezione degli eventi 16/09/2018 Dott. Pierluigi Paolucci

4 Trigger con eventi “poco” frequenti
Semplice: supponiamo di avere una collisione/evento ogni 20 ms. dobbiamo costruire un trigger che impieghi meno di 20 ms per decidere se l’evento e’ buono o no Se l’evento non e’ OK  e’ pronto per il prossimo Se l’evento e’ OK  bisogna acquisirlo e questo significa un certo “tempo morto” sicuramente maggiore dei 20 ms che comportata la perdita di qualche evento successivo. 16/09/2018 Dott. Pierluigi Paolucci

5 Qualche numero utile per Trigger-DAQ
collisioni adroniche (pp  X; hN  X) stot ≈ 30 ÷ 60 mb L ≈ 1030 cm-2 s-1 (“vecchi” collider pp) L ≈ 1034 cm-2 s-1 (targhetta fissa) L ≈ 1034 cm-2 s-1 (LHC con freq. di 40 MHz) rate di eventi 105 ÷ 109 eventi/s sphy ≈ nb ÷ pb  reiezione di 10-8 ÷ 10-11 collisioni leptoniche (e+e-  X; n + targhetta  X) stot ≈ 20 ÷ 50 nb L ≈ 1031 cm-2 s-1 (“vecchi” collider LEP con freq. di 45 KHz) L ≈ 1033 cm-2 s-1 (“nuovi” collider PEP II con freq. di 250 MHz) rate di eventi 10-1 ÷ 102 eventi/s sphy ≈ stot  reiezione del background “semplice” 16/09/2018 Dott. Pierluigi Paolucci

6 Come quantificare il Trigger-DAQ I
Una volta note le caratteristiche della macchina acceleratrice (tipo di macchina, luminosità e frequenza) e della fisica che si vuole studiare (rate di eventi prodotti e rate di eventi da studiare) e progettato il rivelatore necessario per lo studio della fisica prescelta si può iniziare a progettare il trigger: Esempio I: PEP II: L ≈ 1033 cm-2 s-1, freq. di 250 MHz di collisioni e+e-; Fisica: circa 30 ÷ 50 Hz BaBar: 2·105 canali da acquisire (fili, cristalli, strips, pixel…) Sappiamo quindi che dobbiamo passare da 250 MHz a 30 Hz usando uno o piu’ trigger e che dobbiamo fare “in teoria” questa operazione di trigger in 4 ns (1/freq) leggendo i dati provenienti da 2 ·105 canali. 16/09/2018 Dott. Pierluigi Paolucci

7 Come quantificare il Trigger-DAQ II
Logicamente e’ impossibile generare un trigger in soli 4 nsec e quindi si introduce un tempo morto (latency) pari al tempo necessario a generare il trigger e quindi a decidere di acquisire i dati relativi a quel particolare evento. Questo tempo morto si “annulla” introducendo un buffer (memoria) lunga quanto la latency del trigger per ogni canale del rivelatore. Supponiamo di avere 2 livelli di trigger (BaBar) che ci consentono di passare da: 250 MHz  L1  2 KHz  L3  100 Hz Se ogni canale necessita di 2 bytes abbiamo che il DAQ (FARM di PC con circa 50 nodi) deve “trattare” circa: 2·105 x 2 Bytes = 4·105 Bytes = 400 KB x 100 Hz = 40 MB/s Con alcuni algoritmi (zero-suppresion) la dimensione finale di un evento si riduce a circa 25 KB corrispondente a circa 2.5 MB/s da salvare in memoria. 16/09/2018 Dott. Pierluigi Paolucci

8 Dott. Pierluigi Paolucci
Secondo Esempio (LHC) Esempio II: LHC: L ≈ 1034 cm-2 s-1, freq. di 40 MHz di collisioni p-p; Fisica: circa mHz ÷ kHz su un totale di GHz di eventi (pb ÷ nb su un totale di 10-1 barn). Esempio h  gg ha una sezione d’urto prevista di circa 10-1 pb che corrisponde a mHz) CMS: > 2·106 canali da acquisire (fili, cristalli, strips, pixel…) Questa volta abbiamo bisogno di una reiezione che va da 10-8 a Per fare cio’ si usano almeno 2 livelli di trigger ottenendo una riduzione di 40 MHz  L1  105 Hz  L3  102 Hz La latency in questo caso e di 2-3 ms mentre un evento e’ di circa 1 MB. 1 MBytes x 100 Hz = 100 MB/s 16/09/2018 Dott. Pierluigi Paolucci

9 DAQ-Trigger per grandi apparati
­ 30 Collisions/25ns ( 10 9 event/sec ) 10 7 channels (10 16 bit/sec) Luminosity = 10 34 cm -2 sec -1 25 ns Calorimetro 107 sensori 40 MHz Muoni 106 sensori 40 MHz sottoinsieme di dati LV1 - Trigger clock 25 ns durata ~ ms front-end con pipeline …. celle da 25 ns 105 Hz …. celle da 25 ns 105 Hz readout buffer readout buffer LV3 - Trigger durata ~ sec network Farm 102 Hz network Farm 102 Hz 16/09/2018 Dott. Pierluigi Paolucci

10 Trigger con eventi “molto” frequenti
Collisione/evento ogni 25 ns. E’ chiaramente impossibile generare un trigger in 25 ns. Si introduce quindi il concetto di pipe-line e cioè di una FIFO dove vengono “inseriti” i dati in attesa del trigger. La pipe-line deve essere lunga almeno quanto la trigger latency e cioè il tempo per generare il trigger (qualche ms). Il trigger lavora con un clock di 25 ns ed analizza più eventi insieme (in serie). Quando si ha un trigger si acquisisce tutto l’evento e quindi le celle delle pipe-line corrispondenti. Viste le distanze diventano molto importanti anche le tecnologie usate per la trasmissione dei segnali (fibre ottiche su lunghe distanze ~ 100 metri) 25ns 40 MHz 10 5 Hz 2 Lvl-1 HLT Front end pipelines Readout buffers Processor farms Switching network Detectors µsec sec 16/09/2018 Dott. Pierluigi Paolucci

11 Il Trigger per i grandi apparati
Possibilità di avere più livelli di trigger susseguenti con lo scopo di disaccoppiare le problematiche. 16/09/2018 Dott. Pierluigi Paolucci

12 Dott. Pierluigi Paolucci
Dal LEP ad LHC Il bunch crossing e quindi il rate di collisioni e’ andato sempre aumentando dal LEP dove si aveva una collisione ogni 22 ms (30 kHz), al Tevatron dove si e’ passati a 3.5 ms per finire con LHC dove si ha un bunch crossing di 25 ns che corrisponde a 40 MHz. 16/09/2018 Dott. Pierluigi Paolucci

13 Esempio di DAQ di CMS Vedi schema successivo
In CMS si e’ deciso di adottare: un livello di trigger hardware (Level 1) che opera una riduzione di un fattore 1000; un High Level Trigger software (FARM di computer) che riduce di un altro fattore 1000 arrivando ai 100 Hz  su disco; Vedi schema successivo 16/09/2018 Dott. Pierluigi Paolucci

14 Dott. Pierluigi Paolucci
Detectors 40 MHz 16 Million COLLISION RATE channels Charge Time Pattern 3 Gigacell buffers 100 kHz LEVEL-1 TRIGGER Energy Tracks 1 Megabyte EVENT DATA 1 Terabit/s 200 Gigabyte BUFFERS (50000 DATA CHANNELS) 500 Readout memories EVENT BUILDER A large switching network ( ports) with a total throughput of approximately 500 Gbit/s forms the interconnection between the sources (Readout Dual Port Memory) and the destinations (switch to Farm Interface). 1 Terabit/s Networks EVENT FILTER 5 TeraIPS It consists of a set of high performance commercial processors organized into many farms convenient for on-line and off-line applications. The farm architecture is such that a single CPU processes one event Gigabit/s SERVICE LAN Computing services Petabyte ARCHIVE 16/09/2018 Dott. Pierluigi Paolucci

15 Dott. Pierluigi Paolucci
Event building A communications network, such as the public switched telephone network, in which any user may be connected to any other user through the use of packet switching. It is the process of routing and transferring data by means of addressed packets so that a channel is occupied during the transmission of the packet only, and upon completion of the transmission the channel is made available for the transfer of other traffic. 16/09/2018 Dott. Pierluigi Paolucci

16 Dott. Pierluigi Paolucci
Processor farms 16/09/2018 Dott. Pierluigi Paolucci

17 Controllo e monitoring
Nei grandi esperimenti, con tanti rivelatori, elettronica, cavi, sistemi di alimentazioni, sistemi del gas e del raffreddamento, rack e crate ….. diventa estremamente importante disegnare un sistema di DAQ “lento” che controlli e monitori tutte queste grandezza necessarie per il corretto funzionamento dell’apparato sperimentale. Nel passato si sono usati per questo scopo una serie di programmi “custom” sviluppati dai singoli esperimenti, programmi che alla fine sono sempre risultati pesanti e difficili da mantenere. Nei laboratori, per esperimenti piccoli, si e’ sempre più andato diffondendo LabVIEW che da la possibilità di fare molte cose semplici in poco tempo. Al Fermilab e’ stato invece sviluppato un pacchetto SCADA per acceleratori e grandi esperimenti che si chiama EPICS e che si basa sulla tecnologia UNIX – CPU – VME. Questo e’ stato molto usato in BaBar ed altri grandi esperimenti. Ad LHC si e’ deciso di usare un framework “custom” sviluppato da un progetto CERN il cui core e’ un programma commerciale PVSS II. 16/09/2018 Dott. Pierluigi Paolucci

18 Controllo e monitoring
I sistemi SCADA usano una serie di middleware (protocolli di comunicazione) per comunicare con il mondo hardware. L’OPC ed il DIM sono oggi molto usati per comunicare con apparecchiature commerciali e con moduli VME. Per i sensori “lenti” e la lettura di segnali analogici “lenti” sono molto diffuse schede ADC dotate di un protocollo di comunicazione seriale come il CANbus ed il Profibus. 16/09/2018 Dott. Pierluigi Paolucci

19 Dott. Pierluigi Paolucci
Middleware OPC (OLE for Process Control) Industrial solution Reduce diversity of drivers Supported by a large number of companies Support for Filed buses, PLC and SCADA Three kinds of access: Read/Write (synchronous) Subscription (asynchronous) Refresh (forced read) DIM (Distributed Information Manager) Developed by Delphy and used by BaBar and others Client/server with publish/subscribe mechanism on top of TCP/IP Multi-platform support C/C++ libraries 16/09/2018 Dott. Pierluigi Paolucci

20 Dott. Pierluigi Paolucci
Run Control Al di sopra di tutti questi sottosistemi in cui abbiamo suddiviso il DAQ: Trigger di primo livello; Trigger successivi; Sistema di acquisizione dati (VME e/o custom) Calibrazione e Sincronizzazione; Detector Control and Monitoring; Ricostruzione degli eventi si ha il Run Control e cioe’ un package software, dotato di una GUI, capace di gestire tutte queste diverse componenti, sincronizzandone le operazione e gestendo tutti i diversi processi che ogni sottosistema genera. Il Run Control viene in genere sviluppato dai singoli esperimenti sulla basi di software commerciali e non. 16/09/2018 Dott. Pierluigi Paolucci

21 Dott. Pierluigi Paolucci
Conclusioni I grandi esperimenti del primo decennio del 2000 si basano su di un sistema d’acquisizione dati che ha le seguenti caratteristiche peculiari (“novità”): Decine di milioni di canali; Pipeline o buffer con celle da 25 ns e profondità totale di ms; Trigger di primo livello (hardware) veloci  ms; Altri livelli di trigger per passare di 40 MHz a 100 Hz; Livelli di trigger “software” con necessita’ di FARM e network di altissime prestazioni; Event builder basati su large switching network con prestazioni fino a Terabit per sec. Ricostruzione degli eventi con FARM di personal computer dotati del sistema operativo Linux. 16/09/2018 Dott. Pierluigi Paolucci