Functional r equirements for BGV demonstrator ( Run 2)

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


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


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


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


DAQ flowDAQ flow


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


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


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


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)


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.


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)


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


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


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:

...

Documents

Functional r equirements for BGV demonstrator ( Run 2)