Project

General

Profile

Actions

Development #2267

closed

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

Development #2265: Migrate algorithms

Migrate event builder

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

Status:
Closed
Priority:
Normal
Assignee:
Target version:
Start date:
10/14/2021
Due date:
10/22/2021
% Done:

100%

Estimated time:
10.00 h
Spent time:

Description

The current event builder is to be adapted to the base class CbmAlgBuildEvents and implemented in the algo directory. The current software should stay in place until verfication of the new algorithm.

Target: algo/evbuild/CbmAlgBuildEvents

Question here: do we have are can imagine to have different algorithms for this task (extracting digis around a trigger time and creating a CbmRawEvent)? If not, we do not necessarily need a base class.


Related issues

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

Actions
Follows Framework - Development #2263: Base class for event builderClosedDominik Smith09/28/202110/13/2021

Actions
Actions #1

Updated by Volker Friese 8 months ago

  • Due date set to 10/14/2021
  • Start date changed from 09/28/2021 to 10/14/2021
  • Follows Development #2263: Base class for event builder added
Actions #2

Updated by Volker Friese 8 months ago

  • Due date changed from 10/14/2021 to 10/22/2021
Actions #3

Updated by Volker Friese 8 months ago

Actions #4

Updated by Dominik Smith 8 months ago

Question here: do we have are can imagine to have different algorithms for this task (extracting digis around a
trigger time and creating a CbmRawEvent)? If not, we do not necessarily need a base class.

Good question. I tend to see base classes as something that should be implemented as the need for them arises, i.e. at the earliest together with the second instance of classes that will derive from them. That way, the shared properties of the respective objects are clear from the outset and don't have to be predicted in advance. Also, doing it this way doesn't lead to states of the code that contain "unused generality", which some clean-coding paradigms suggest avoiding.

Basically, the argument against unused generality is a combination of "you probably won't need it" i.e. "accurately predicting future needs is hard", "it will confuse the users" and "it leads to higher code complexity without gains in functionality".

I would say the same thing about a base class for trigger / seed finding algorithms, by the way.

Actions #5

Updated by Volker Friese 8 months ago

One prime reason for base classes is of course to implement common functionality. The second one, however, is to be able to start the framework integration before the concrete implementation is available.

The trigger is a very general concept - actually, it is the core of the online data processing, and there will be many different and differently complex triggers. The digi-based trigger (seed finder) is only one and a rather simple example. Already here, we are discussing different implementations (fixed window size vs. minimum number of digis).

Actions #6

Updated by Dominik Smith 8 months ago

Ok, sounds good. I see that all of the tasks that were assigned to me are marked as blocked by some other task. I will wait for this to be cleared.

Actions #7

Updated by Dominik Smith 7 months ago

@Volker Friese: Is the description of this issue still valid? Should CbmRawEvent be used or CbmDigiEvent?

The same question should be answered for https://redmine.cbm.gsi.de/issues/2263

Actions #8

Updated by Volker Friese 7 months ago

RawEvent is mistyped, I of course meant the new class CbmDigiEvent.

Since the task is so generic, I am almost done with an implementation. Dominik, could you attend to #2266 instead, to avoid parallel work?

Actions #9

Updated by Dominik Smith 7 months ago

Ok, I will do that

Actions #10

Updated by Volker Friese 7 months ago

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

First version available in MR 567. Don't know why it's not automatically linked to here.

Actions #11

Updated by Volker Friese 6 months ago

  • % Done changed from 70 to 100

Finalised implementation in MR 567.

Actions #12

Updated by Volker Friese 6 months ago

  • Status changed from In Progress to Closed
Actions

Also available in: Atom PDF