Differences between revisions 4 and 5
Revision 4 as of 2016-03-24 13:14:57
Size: 6734
Editor: AdrianIrles
Comment: EUDAQforLC repository information
Revision 5 as of 2016-03-24 13:25:40
Size: 7547
Editor: AdrianIrles
Comment:
Deletions are marked like this. Additions are marked like this.
Line 80: Line 80:
=== RawDataEvent format ===
AHCAL proposal.
Line 81: Line 83:
== Comparison of different LCObjects performances ==
/!\ In progress.
Line 82: Line 86:
=== RawDataEvent format === I have done a comparison of the performance (writting time, file sizes, data acces...) of the LCGenericObjects and more specific objects. We don't have an specific LCObject that fulfill our needs for raw data, so for this study, I used the EVENT:TrackerRawData as example.

http://lcio.desy.de/v01-10/doc/doxygen_api/html/classEVENT_1_1LCObject.html
Line 85: Line 92:
/!\ I have the information, I need to write it down.
Line 86: Line 95:
/!\ I have the information, I need to write it down --> wait until next testbeam in june?
Line 87: Line 98:
/!\ I have the information, I need to write it down --> wait until next testbeam in june?
Line 88: Line 101:
/!\ To do.
Line 89: Line 104:
/!\ In progress. To be polish and optimized during/after AHCAL testbeam in may.

=== Beam Interface (BIF) ===

Introduction to the AIDA2020 project and the WP5 (Data acquisition system for beam tests)

What is AIDA-2020?

The AIDA-2020 project brings together the leading European research infrastructures in the field of detector development and testing and a number of institutes, universities and technological centers, thus assembling the necessary expertise for the ambitious programme of work.

Visit the AIDA2020 webpage.

WP5: Data acquisition system for beam tests

Visit the AIDA2020 WP5 webpage.

AIDA-2020 is divided into 15 Work Packages. A Work Package (WP) is a unit of work within the project. The WPs are theoretically independent but they were defined in order to foster synergies in AIDA-2020.

Objectives

  • Specification of interfaces and provision of a control and timing system to allow multiple detectors to be linked together.
  • Develop a central data acquisition software and run control to enable multiple detectors to be combined in one experiment.
  • Develop monitoring systems to automatically check the data quality.
  • Develop a system to monitor the environmental conditions, such as temperature, of several detectors.
  • Define an event for online data where data is combined from detectors with very different signals and properties.

Tasks

Task

Task Leaders

Task 5.1 Scientific coordination

David Cussans (UNIBRIS)

Task 5.2 Interface, synchronisation and control of multiple-detector systems

David Cussans (UNIBRIS)

Task 5.3 Development of central DAQ software and run control

Matthew Wing (UCL)

Task 5.4 Development of data quality and slow control monitoring

Fabrizio Salvatore (USSUS)

Task 5.5 Event model for combined DAQ

Adrian Irles (DESY)

WP5 Technology Transfer Officer

Matthew Wing (UCL)

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

EUDAQforLC

The use ofEUDAQ by the ILC community sttarted 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:

  • demand to operate combined set-ups of electromagnetic (e.g. silicon based) and hadronic (e.g. scintillator based) calorimeters,
  • the need to study hybrid prototypes (i.e. silicon + scintillator calorimeters in 2014)

CALICE community decided to use EUDAQ which is a modular and portable framework for DAQ, is well tested, maintained and successful.

We hope that this seamlessly integrates with the AIDA2020 efforts towards developing LC test beam standards for the entire LC 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.

In this scheme, EUDAQ is proposed as central and high level DAQ.

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 would be 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 everything separated and working, it is proposed that every subsystem:

  • write
  • test in eudaq v1.5-dev and/or the master (eudaq 2, in continuous development) branches.
  • and push them to the EUDAQforLC repository.

i.e. https://github.com/EUDAQforLC/eudaq/tree/ahcal_v1.5-dev

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

  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.

    • 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 needed.

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

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

Some useful links:

  • EUDAQ for AHCAL
  • github basics
  • EUDAQ manual (1.5)
  • EUDAQ manual (2.x)

RawDataEvent format

AHCAL proposal.

Comparison of different LCObjects performances

/!\ In progress.

I have done a comparison of the performance (writting time, file sizes, data acces...) of the LCGenericObjects and more specific objects. We don't have an specific LCObject that fulfill our needs for raw data, so for this study, I used the EVENT:TrackerRawData as example.

http://lcio.desy.de/v01-10/doc/doxygen_api/html/classEVENT_1_1LCObject.html

LCIO data format

Scintillator Calorimeters (AHCAL and ScECAL sharing readout technology and using scintillator tiles)

/!\ I have the information, I need to write it down.

SDHCAL

/!\ I have the information, I need to write it down --> wait until next testbeam in june?

Silicon ECAL with tungsten absorber

/!\ I have the information, I need to write it down --> wait until next testbeam in june?

TPC

/!\ To do.

Notes in Event Building

/!\ In progress. To be polish and optimized during/after AHCAL testbeam in may.

Beam Interface (BIF)

AHCAL standalone case

EventModelforCombinedDAQ_AIDA2020WP5 (last edited 2016-03-24 16:16:48 by AdrianIrles)