Development #2278

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

Development #2277: Online integration

Device class for reconstruction from time slices

Added by Volker Friese 4 months ago. Updated about 2 months ago.

In Progress
Target version:
Start date:
Due date:
% Done:


Estimated time:
15.00 h


FairDevice class comprising the functionality of CbmRecoTs (unpacker + trigger + event builder). Including the infrastructure to run it (shell scripts).

Deliverable: reco/mq/CbmDevRecoTs

Related issues

Follows Framework - Development #2275: Reconstruction from time slice level Assigned 11/15/2021 11/19/2021
Precedes Framework - Development #2279: Online test with archived data Assigned 11/29/2021 12/03/2021
Precedes Framework - Development #2280: Integration into mCBM data taking Assigned 11/29/2021 12/03/2021


#1 Updated by Volker Friese 4 months ago

#2 Updated by Volker Friese 4 months ago

#3 Updated by Volker Friese 4 months ago

  • Due date set to 11/22/2021
  • Start date changed from 09/28/2021 to 11/22/2021
  • Follows Development #2275: Reconstruction from time slice level added

#4 Updated by Volker Friese 4 months ago

  • Due date changed from 11/22/2021 to 11/26/2021

#5 Updated by Volker Friese 4 months ago

#6 Updated by Volker Friese 4 months ago

#7 Updated by Volker Friese about 2 months ago

  • Status changed from Assigned to In Progress

Dear Pierre-Alain,

having the new algorithms TimeClusterTrigger and BuildEvents in place and integrated into cbmroot by the tasks CbmTaskTriggerDigi and CbmTaskBuildEvents, the "missing link" is a task for the algorithm UnpackSts, to come shortly. However, triggering and event building from simulated data is already possible. I thus suggest to think on the integration via CbmMQ right away. I see the alternative:
  • to create one device for each task (Trigger, Event Builder, Unpacker);
  • to create one device comprising all three algorithms.

For my personal learning curve, not being experienced with CbmMQ, it would be very beneficial to have one device replacing each respective task. But if this is not a meaningful run scenario, I do not want to burden you with dry developments. What do you think?

#8 Updated by Pierre-Alain Loizeau about 2 months ago

I think the single device is probably our end-goal, as that would minimize the memory consumption on the node.
But for the time being we could go for separate tasks, which would maybe make it more evident how the communication between Devices work.

Concerning the simulation, this is not possible for now: we do not have a source device taking simulated (digitized) data as input. Would probably not be too complicated, but I think it would nonetheless take some time to make it carefully as one would have to properly handle the different type of inputs (event base, time based) and the number of detectors present.
What would definitely be complicated to do in MQ is the transfer of the MC information, as I do not think anybody looked at how to treat the match objects in this context.

Also available in: Atom PDF