Project

General

Profile

Actions

Development #2263

closed

Development #2256: Demonstrator for digi-based trigger, STS-only

Development #2257: Preparation of software infrastructure

Base class for event builder

Added by Volker Friese 8 months ago. Updated 6 months ago.

Status:
Closed
Priority:
Normal
Assignee:
Target version:
Start date:
09/28/2021
Due date:
10/13/2021
% Done:

100%

Estimated time:
Spent time:

Description

A base class for the event building process is to be implemented. Data interfaces are: CbmTimeslice (input digis), vector<double> (input trigger times), vector<CbmRawEvent> (output events).

Target: algo/base/CbmTrigger


Related issues

Blocked by Framework - Development #2261: Data containers for event and time slice digisClosedJan de Cuveland09/28/202110/08/2021

Actions
Blocks Framework - Development #2273: Reconstruction from digi levelAssignedVolker Friese11/08/202111/12/2021

Actions
Precedes Framework - Development #2267: Migrate event builderClosedVolker Friese10/14/202110/22/2021

Actions
Precedes Framework - Development #2271: Task for event buildingClosedVolker Friese10/14/202110/29/2021

Actions
Actions #1

Updated by Volker Friese 8 months ago

Actions #2

Updated by Volker Friese 8 months ago

  • Due date set to 10/13/2021
Actions #3

Updated by Volker Friese 8 months ago

Actions #4

Updated by Volker Friese 8 months ago

Actions #5

Updated by Volker Friese 8 months ago

Actions #6

Updated by Volker Friese 7 months ago

  • Status changed from Assigned to In Progress
  • Assignee changed from Volker Friese to Dominik Smith
  • % Done changed from 0 to 20

It seems that the functionality of the event builder is well-defined - it is basically a copy/move from time-slice digis into the event class. Most probably, there will not be different implementations to that. Anyhow, following our general strategy, we should introduce a base class only when at least two algorithms are at hand.

With the introduction of the data containers CbmDigiTimeslice (input) and CbmDigiEvent (output) (see #2261, not yet merged), I think we can go ahead here now.

The API is defined as:
class EventBuilder {
public:
std::vector<CbmDigiEvent> operator() (const CbmDigiTimeslice& ts, const std::vector<double> triggerTimes) const;
}

The parameters to take are the time windows w.r.t. trigger time, specific for each detector. They should be set either with the constructor or by an appropriate Config method.

Are monitoring data needed? If yes, they shall be defined in a container EventBuilderMoni, to be included as return value in the functor call, like

std::pair<std::vector<CbmDigiEvent>, EventBuilderMoni> operator() (const CbmDigiTimeslice& ts, const std::vector<double> triggerTimes) const;

Question: should the digis be moved or copied? Probably, for such basis POD as our digis there is not much of a performance difference, but it may save memory. When we decide to move, the CbmDigiTimeslice argument cannot be const.

Actions #7

Updated by Volker Friese 6 months ago

  • % Done changed from 20 to 100

With the implementation of the event builder in MR 567, this issue can be considered reolved.

Actions #8

Updated by Volker Friese 6 months ago

Volker Friese wrote:

With the implementation of the event builder in MR 567, this issue can be considered resolved.

Actions #9

Updated by Volker Friese 6 months ago

  • Status changed from In Progress to Closed
Actions

Also available in: Atom PDF