CbmRoot » Framework

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.

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