BGV meeting ctrl&moni 28-Feb-2014 CERN Massimiliano Ferro-Luzzi 1
Functional requirements for Functional requirements for BGV demonstrator (Run 2)BGV demonstrator (Run 2)
this is work ongoing will soon be available in written (proper document)
not discussing performance requirements herenot discussing performance requirements here
BGV meeting ctrl&moni 28-Feb-2014 CERN Massimiliano Ferro-Luzzi 2
GeneralitiesGeneralities
The main purpose of the BGV is to deliver transverse beam size values (one H and one V) per bunch at the highest possible rate– aim for a per-bunch statistical accuracy of ~5% in 3 min for 1011 p
The beam size values are extracted from transverse 2D (HxV) distributions, which can also be made available to the operators
Accessorily, it can also measure – a beam trajectory ( => position, slopes)
– relative bunch amplitudes for any bunch slot ( => ghost charge!) The BGV will be able to measure beam sizes at any energy and any
beam intensity – of course, the data rate will scale with the bunch intensity and depend
on energy and beam species
NB: here, bunch slot = BCIDNB: here, bunch slot = BCID
BGV meeting ctrl&moni 28-Feb-2014 CERN Massimiliano Ferro-Luzzi 3
Some basic factsSome basic facts
BGV demonstrator is for LHC Ring 2, but the idea is to later (after Run2) develop one BGV per ring. These will be two independent systems, like the LDM of each ring.
In a first phase, the BGV demonstrator will have to be commissioned by experts only
In a second phase, the BGV will be used by CCC operators– but experts will continue to debug/improve/calibrate
reflected in the control/monitoring architecture
BGV ECS (PVSS)for expertsBGV ECS (PVSS)for experts
detectorFE
DAQReadoutboards
LHC SCADALHC CMWfor LHC operation
LHC SCADALHC CMWfor LHC operation
slow control data storage event data storage
LHC VacLHC Vac
vac sysgas
target
slow control data storage
BGV meeting ctrl&moni 28-Feb-2014 CERN Massimiliano Ferro-Luzzi 4
What "event data" does the BGV produce and how ?What "event data" does the BGV produce and how ?
Upon a "Level-0 trigger" the detector FE delivers analog signals of all fibres to the Readout board (TELL1)
The TELL1 board digitizes (ADC) the signal and performs (FPGAs) a zero-suppression (subtract pedestals, subtract common-mode, find candidate "hits" and construct a "cluster" from that). It creates a data bank for this triggered event (BCID...) and puts together a fixed number of events in a multiple event package (MEP) before sending it by Gbit to a specific node of the DAQ farm (as decided by the ODIN readout supervisor)
On the DAQ node an event-builder process waits until receives MEP from all sources (TELL1s+ODIN), builds the events and passes these to an HLT process. The HLT process makes the pattern recognition and fitting (tracks + vertex). The event data are then passed to a disk writer process.
0
0
position
AD
C c
lus.
cha
rge
cluster
tracks and vertex
fibre channel
sign
al
BGV meeting ctrl&moni 28-Feb-2014 CERN Massimiliano Ferro-Luzzi 5
DAQ flowDAQ flow
BGV meeting ctrl&moni 28-Feb-2014 CERN Massimiliano Ferro-Luzzi 6
Basic requirements from CCC operationBasic requirements from CCC operation
Monitoring:beam size X and Y vs time
– same for a selectable BCID (or set of BCIDs)ghost charge vs timebeam positions (H, V) and slopes (H, V) vs time
– same for a selectable BCID (or set of BCIDs)histogram of event rate vs BCID
Control:detector
– "turn ON/OFF" (to be defined what it means)
– "reset BGV" (to be defined what it means)
– load a filling scheme and edit which slots should be considered for data acquisition
gas target– control gas injection
BGV meeting ctrl&moni 28-Feb-2014 CERN Massimiliano Ferro-Luzzi 7
Basic requirements from expertsBasic requirements from experts
Control:– restart a run
– load a filling scheme and edit prescale factor per BCID
– change the proportions of vertex : cluster : NZS trigger rates
– send test pulse triggers
– change L0 trigger thresholds
– change HLT trigger cuts
Difference to LHCb: add beam energy and beam modes to ODIN bank (could be used to
adjust HLT cuts per event ?) event time ordering must be respected to ~1s BGV DAQ acts ~like a "monitoring farm" in the sense that it must
produce online results (trends) based on selected events
BGV meeting ctrl&moni 28-Feb-2014 CERN Massimiliano Ferro-Luzzi 8
Event data sizes out of TELL1sEvent data sizes out of TELL1s
Zero-suppressed data:TELL1 data will depend on num Ncl of clusters per BGV event and data size scl per cluster (as for VELO, fixed)
Assume here Ncl = 300 and scl = 4 B
Thus 1.2 kB per triggered event– As a comparison the VELO (84 TELL1s) has for pp=8 TeV an event
size of about 9 kB.To the TELL1 data one should add the transport overhead and the ODIN dataAssume about 1.5kB per event.
Non-zero suppressed data: of the order of 128*144*1B = ~20kB per triggered event
128channels + 16header channels8bit ADC value
BGV meeting ctrl&moni 28-Feb-2014 CERN Massimiliano Ferro-Luzzi 9
Event data rates TELL1s to DAQEvent data rates TELL1s to DAQ
Zero-suppressed data from TELL1s to DAQ:
Absolute maximum = 1.5kB/Trg x 1 MTrg/s = ~1.5 GB/s distributed over 8 TELL1 sources (~ 200MB/s per source)
will probably be less, because we set a L0 trigger threshold which keeps the L0 rate below 1MHz (few 100 kHz)
BGV meeting ctrl&moni 28-Feb-2014 CERN Massimiliano Ferro-Luzzi 10
DAQ output event data categoriesDAQ output event data categories
vertex data: these are the data used online to make the beam profiles. They are produced in the online reconstruction.– these are "final" results, i.e. include already the vertex resolution corrections
– storing split vertices also allows to get the resolution (but without changing alignment)
cluster data: needed for online monitoring of pattern recognition and for offline verification of results. Allow to re-do the tracks and vertices, perform alignment, parametrise the vertex resolution corrections, etc. These data are appended to some events at a reduced rate for monitoring, but it should be possible to increase the rate for dedicated "calibration" runs.
NZS data (non-zero suppressed): these "raw" data are needed to monitor pedestals and noise, to check the overall behaviour of the front-end part. The data are appended to some events but at a very reduced rate.
Additionally: histograms of vertex data, for example.
BGV meeting ctrl&moni 28-Feb-2014 CERN Massimiliano Ferro-Luzzi 11
DAQ output event data: vertex dataDAQ output event data: vertex data
These are the data used online to make the beam profiles. They are produced in the online reconstruction.
– these are "final" results, i.e. include already the vertex resolution corrections
Estimated data size:
Minimum data are*:
vertex track multiplicity 1 short 2B
vertex 3D positions 3 floats 12B
vertex position covariant matrix 9 floats 32B
header data ODIN 50B
Rate of about 3 Hz per bunch (max. 2800 bunches)
Max rate: 3Hz x 2800 x 100B = 800 kB/s
This should be the dominant data rate
*Alternative: split vertices 1 & 2, mult & 3D => 2x(2B+12B) = 28B (don't need covariance)
BGV meeting ctrl&moni 28-Feb-2014 CERN Massimiliano Ferro-Luzzi 12
DAQ output event data: cluster dataDAQ output event data: cluster data
Needed for online monitoring of pattern recognition and for offline verification of results. Allow to re-do the tracks and vertices, perform alignment, parametrize the vertex resolution corrections, etc. These data are appended to some events at a reduced rate for monitoring, but it should be possible to increase the rate for dedicated "calibration" runs.
Estimated data size:
this is the same as the TELL1 data input to DAQ
=> 1.5kB/Trig.
Rate:
To keep reasonable compared to the vertex data, limit to about 80kB/s which would mean abut 50Hz maximum
BGV meeting ctrl&moni 28-Feb-2014 CERN Massimiliano Ferro-Luzzi 13
DAQ output event data: NZS dataDAQ output event data: NZS data
These "raw" data are needed to monitor pedestals and noise, to check the overall behaviour of the front-end part. The data are appended to some events but at a very reduced rate.
Estimated data size: order of 20 kB
Rate:
To keep reasonable compared to the vertex data, limit to about 80kB/s which would mean about 4Hz maximum
BGV meeting ctrl&moni 28-Feb-2014 CERN Massimiliano Ferro-Luzzi 14
Slow control dataSlow control data
Front end:128 SiPM Temp values32 SiPM bias voltages and currents ?xxx LV states (or voltage and current values ?)
Readout:
...
DAQ:
...
Vacuum:
...