/!\ <!> Attention: all information in this wiki page is based in the EUDAQ 1 event model philoshopy. For updated version following WP5 event model based in EUDAQ 2, please visit: http://flcwiki.desy.de/AIDA2020WP5_Task5.

Inherits from AIDA2020 Work Package 5 web page

Task 5.5: Event Model for Combined DAQ within the Linear Collider Community

Towards ILC common test beams

It is proposed to run, during ILC ommon testbeams, in a synchronous mode with a central DAQ system: a central clock that delivers common start/stop signal for all systems that then read during the readout cycle. Proceeding in this way requires that all systems should agree on internal clock frequencies but it takes advantage of all independent standalone DAQ developments.

CentralDAQSchematics.png

In this scheme, EUDAQ is proposed as central and high level DAQ due to its modularity, portability and proven succes.

EUDAQforLC

The use ofEUDAQ by the ILC community started with CALICE calorimeters community which set out to develop a common DAQ with the support of EUDET in 2006-10, to fully exploit the benefits of having a common family of front-end readout chips. With the discontinuation of the support of ILC activities in the UK this effort dried out before completion and therefore a lost of coherence between calorimeters developments (scintillator, silicon and gaseous). The issue of common DAQ and synchronization came up again during due to:

The AIDA2020 efforts towards developing LC test beam standards for the entire LC community gave a fresh pushto the CALICE efforts to integrate EUDAQ as common DAQ software.

EUDAQforLC Git Repository

A github community has been created in order to collect all subsystems EUDAQ producers and converter plugins.

https://github.com/EUDAQforLC

The idea is that every subsystem fork the eudaq (and eudaq-configuration) repositories and create, in the producers folder (i.e. producers/calice), its own producers which should be able to run standalone using the standard features of EUDAQ (run control, data collector, logger).

In order to keep every subdetector contribution independent and working, it is proposed that every subsystem:

its producers and data converters.

As an example, you can check the AHCAL branch: https://github.com/EUDAQforLC/eudaq/tree/ahcal_testbeam2016, based in the stable v1.6-dev branch from the main repository. The code, from May, has been already merged with the eudaq1-.6 branch.

The branch mentioned above corresponds to the producers used by the AHCAL detector and the Beam Interface (BIF), tested and optimized during the testbeams in 2016. You can use them as starting point to write your own producers. For more information, you may contact Adrian Irles (AHCAL-DESY) or the eudaq crew.

  1. The main purpose of this community is to serve as sharing point and discussion point for all LC subdetector DAQ systems, not only for developping the EUDAQ producers but also to drive data format compatibilites. Some basic informations are:

    • The producers are hardware dependent.
    • The Converters from raw data to LCIO format should be as general as possible, able to be used for everyone. For example, the CaliceGenericConverterPlugin is written in a general way to be used for all Calice producers that have LCGenericObjects in the lcio files. For that, a minimun agreement in the format of the EUDAQ raw data event is desired.

  2. Is a free-contribution repository (send a mail toAdrian Irles (AHCAL) if you want to be in the membership list of the EUDAQforLC git team).

  3. The producers and data converters might be pushed, afterwards, to the main eudaq repository where the eudaq developpers will check them and ask for corrections or improvements in case of need.

    • The ideal would be push the standalone codes to the main eudaq repository all together or in subsets (i.e. a calice folder in the main producers folder), after being tested in "standalone mode"

Code structure

Slighlty different code structures are foreseen for EUDAQ1 and EUDAQ2.

For the first version, the producers are the only "detector dependent" code. This means that also the DataConverterPlugins where part of the main library (libEUDAQ.so).

For EUDAQ2, this is slightly modified: the converters should be part in the producers folders since they are hardware dependent.

For example, for the CALICE case:

  1. For EUDAQ 1, https://github.com/EUDAQforLC/eudaq/tree/ahcal_testbeam2016 and https://github.com/eudaq/eudaq/tree/v1.6-dev

    • we have one folder in the producer folder that contains the different producers: producers/calice/AHCAL, producers/calice/BIF_AHCAL, etc...
    • The Converter is in main/lib/plugins/CaliceGenericConverterPlugin.cc
  2. For EUDAQ2, https://github.com/EUDAQforLC/eudaq/tree/master and https://github.com/eudaq/eudaq/tree/master

    • we have one folder in the producer folder that contains the different producers: producers/calice/AHCAL, producers/calice/BIF_AHCAL, etc...
    • the converters are part of libcalice.plugin.so which is generated from the files in producers/calice/src

Some useful links:

Proposal of a common Raw Data Format

Events may be sent to the DAQ using the SendEvent() method in the producer.

void SendEvent(const Event &);

Where the parameter is usually takes as parameter a RawDataEvent object which is serialised and sent to the Data Collector. This object is a generic container for blocks of raw bytes used to encapsulate the data read out from the sensor electronics and send it to the DAQ. The number of blocks is not limited.

It is up to each Producer how the raw data are encoded since it is up to the corresponding DataConverterPlugin how they are encoded.

CALICE proposal of the RawDataEvent format

Here is a proposal for a common RawDataEvent format based in the CALICE detector needs. It is fundamented in the fact that we want to use the LCIO format as common format for the raw data, therefore a common RawDataEvent which can be converted in LCIO using a common CaliceGenericConverterPlugin is needed.

RawDataEvent *nev = new RawDataEvent("CaliceObject", _runNo, _cycleNo);
string s = "EUDAQDataScCAL";
nev->AddBlock(0,s.c_str(), s.length());
s = "i:CycleNr:i:BunchXID;i:EvtNr;i:ChipID;i:NChannels:i:TDC14bit[NC];i:ADC14bit[NC]";
nev->AddBlock(1,s.c_str(), s.length());
nev->AddBlock(2, vector<int>()); // dummy block to be filled later
nev->AddBlock(3, vector<int>()); // dummy block to be filled later
nev->AddBlock(4, vector<int>()); // dummy block to be filled later
nev->AddBlock(5, vector<int>()); // dummy block to be filled later

The way to fill the subsequent blocks depends on the Producer. For the AHCAL case:

while receiving data {
  nev->AddBlock(nev->NumBlocks(),infodata);
}
deqEvent.push_back(nev);

where infodata is a vector of integers.

Common data converters (RawDataEvent --> LCIO object)

Using the above mentioned common definition for the RawDataEvents, is easier to convert the blocks into LCIO Generic Objects, as it is done in CaliceGenericConverterPlugin.

The converter identifies the subdetector that sends the data reading the first block and the is flexible to read in different ways the 4 blocks dedicated to useful information. After this, it converts the rest of the blocks in vectors of integers that are throw in the LCGenericObject.

Every entry of these LCIO objects will have a header that can contain all the information that we want (for example the data format) and a set of entries consisting in bunch of integers. It is responsability of each subdetector to decode the information during monitoring or for offline analysis.

Comparison of different LCObjects performances

As mentioned above, the LCGeneric Objects offers good flexibility to be used for different subdetectors but have some drawbacks due to this high level of flexibility: it saves always a header and its internal structure is heavy and complicated. This is translated in two undesired features:

The impact of using these objects or other less flexible but better designed to save space and increase speed has been done using the AHCAL DAQ. More specifically, what has been done is of the performance (writting time, file sizes, data acces...) of the LCGenericObjects and the EVENT:TrackerRawData object which serves as testing format. All available objects are listed here.

The following tables show a comparison of file size and writting speed for different formats:

And for two different data structures:

To fill these tables a generator of dummy data has been used. This generator simulates a 100% data occupancy of 256 chips (x36 channels) at rates of XXX X-( .

~Size (MB/readout cycle)

Data Format

RawDataEvent

LCGenericObject

TrackerRawData

Text file

channel by channel

2.6 (0.5 compressed with gzip)

0.5

0.3-0.4

6-7

chip by chip

0.7 (0.025 compressed with gzip)

0.025

0.015

###

~Speed of writting (readout cycle/s)

Data Format

RawDataEvent

LCGenericObject

TrackerRawData

Text file

channel by channel

13

4-5

13

7-8

chip by chip

13

13

13

###

Obviously, the text file is the worst option (heavy and slow). It is also important to remark that the LCObjects are, by default, compressed using standard zlib libraries. If the RawDataEvents are also compressed, the size is similar than in the LCGenericObject format. In other hand, if the LCIO files are not compressed, the speed is increased by a factor 2-3. Finally, the maximum speed of the data generator is 13 cycle/s, therefore, the values in the table are intrinsically limited by this number.

It is observed that the size and writing speed of the files is clearly optimized by:

LCIO data format

BIF

see BIF section

EVENT::LCGenericObject: One entry per ROC. Four numbers are given for every trigger:

[   id   ] i:Type:i:EventCnt:i:TS_Low:i:TS_High - isFixedSize: false
--------------------------------------------------------

[00000731] i:50331648; i:449; i:91639648; i:200578; i:16973824; i:49744725; i:91645249; i:200578; i:16973824; i:49744726; i:92107790; i:200578; i:16973824; i:49744727; i:92204049; i:200578; i:16973824; i:49744728; i:92524077; i:200578; i:16973824; i:49744729; i:92591582; i:200578; i:16973824; i:49744730; i:93075374; i:200578; i:16973824; i:49744731; i:93097880; i:200578; i:16973824; i:49744732; i:93225387; i:200578; i:16973824; i:49744733; i:93274140; i:200578; i:16973824; i:49744734; i:93315393; i:200578; i:16973824; i:49744735; i:93359158; i:200578; i:33554432; i:449; i:91639648; i:200578;  -----
---------------------------------------------------

Scintillator AHCAL and ECAL

EVENT::LCGenericObject: One entry per chip. The hit bit and gain bit is encoded inside the TDC and ADC values. Information updated in April 2016.

i:CycleNr:i:BunchXID;i:EvtNr;i:ChipID;i:NChannels:i:TDC14bit[NC];i:ADC14bit[NC]

To extract, for channel j, the ADC, TDC, and hit bit, we should do:

tdc, adc

tdc[j] = TDC14bit[j]%4096;

adc[j] = ADC14bit[j]%4096;

hit bit, gain bit (if the numbers encoded in the ADC and TDC 14 bit integers are not equal, we reject the event):

hitbit_adc[j] = (ADC14bit[j] & 0x1000)?1:0; gainbit_adc[j] = (ADC14bit[j] & 0x2000)?1:0;

hitbit_tdc[j] = (TDC14bit[j] & 0x1000)?1:0; gainbit_tdc[j] = (TDC14bit[j] & 0x2000)?1:0;

Silicon ECAL

EVENT::LCGenericObject.

One entry per channel. Updated to November-December'15 data.

i:acq,i:bx,i:dif,i:chip,i:mem,i:cell,i:adc_hg,i:adc_lg,i:trig_hg,i:trig_lg

SDHCAL

EVENT::RawCalorimeterHit

Dedicated object, one entry per channel and hit,

4 integers: CellID0, CellID1, Amplitude, TimeStamp

TPC

EVENT::TrackerRawData

Dedicated object, one entry per channel,

3 integers: CellID0, CellID1, Amplitude, TimeStamp

1 vector of shorts: ADCValues

Event Building

At first level, an event is defined as the collection of data in the detector produced by a single incident particle. The most basic building of an event in testsbeams of trigger based experiments (i.e. LHC experiments) is done by associating all the information of the detector collected in a specfic time window after being triggered by an external signal.

The ILC collisions are foreseen to be studied by autotriggered detectors. For this kind of detectors the situation is a bit different:

The event (online) building is crucial for data analysis but also for online quality monitor during testbeam to study correlations in time and geometry - all detectors are running at the same time? are they alligned?. Together with the intrinsic complexity of the event building for autotriggered detectors, the event building should be as generic as possible an foresee combined testbeams of devices with different integration times (i.e. high granularity calorimeters with rolling shutter pixel sensors).

Event Building for the AHCAL+BIF

As a test case, we will discuss the basic idea of event building using the AHCAL+BIF setup. This configuration has been tested with beam in different ocasions. The first one was in Nobember 2015 (DESY testbeam, T24) where both devices were running in standalone mode in what concerns to data taking. Next time was in May 2016 at DESY TB22. In this ocasion, both devices data taking was managed by EUDAQ(1) and therefore the data were collected in one individual file in the format discussed above making possible the online monitoring of the time correlation between AHCAL and BIF.

The following diagram show the general timing performance of the AHCAL and the BIF. Exceptuating the TDC ramps, this diagram is a quite generic explanation of the timing performance of autotriggered detectors for Linear Collider (working in Linear Collider mode or in testbeam mode).

timing.png

The first two lines in the diagram show the master clock behaviour during the acquisition window. Notice the big difference in the size (in time) of the BXID for ILC mode or testbeam mode. The 3rd and 4th line shows the behaviour of all the channels in one ASIC (36 channels in AHCAL case). Remember that all ASIC (SPIROC2) run independently of the others. In testbeam mode, if there are two events in the same BXID and channel, the second is missed.

In testbeam mode, we use a external trigger signal as validation, so we only keep the data for those BXID in which we have real hits triggered by the external triggers.

For each hit, the ASICs provides ADC and TDC. Both are charge (adc ticks), the difference is that the first is directly related to the collected charge by the SiPMs and the second has a fix ramp. This allows to use the value of the TDC as time, adding a granularity of 4096 to the 4 us of the BXID. When a hit is recorded by a channel, the TDC rampup stops so the measured value can be used as time inside the BXID if the TDC ramp are well calibrated. The SPIROC have two different TDC ramps for odd and even BXIDs.

Finally, the BIF provides absolute timestamps for start/stop acquisition and the triggers from the external reference. The BIF has an offset between the start acq and the first BXID that needs to be calibrated during data taking.

As important remark: BIF and AHCAL run the same 40 MHz clock, so everything is synchronous.

The event building is done (online and offline) using the LCIO data from EUDAQ. In these files, one "entry" corresponds to one Readout Cycle. The steps to make the event building are:

  1. Calibrate the BIF offset
  2. Calculate the BXID of every hit from the BIF timestamp.
  3. Sort the AHCAL data by BXID.
  4. Create events collectin ghe AHCAL and BIF data corresponding to the same event.

The procedure is schematically shown in the following diagram. For more techincal details, visit here. Is important to remark that this event building makes no use of the TDC information. This is due to the fact that we are assuming that the TDC ramps are not yet calibrated and that calibration is going to be done with the data from those testbeams. Adding the TDC information will add a new degree of complexity to the process and will require a dedicated offline analysis that is not crucial for online data event model purposes.

EventBuilding.png

AIDA2020WP5_Task5.5_eudaq1 (last edited 2017-04-27 09:58:06 by AdrianIrles)