Project

General

Profile

Actions

Development #2278

open

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

Development #2277: Online integration

Device class for reconstruction from time slices

Added by Volker Friese 12 months ago. Updated 6 days ago.

Status:
In Progress
Priority:
Normal
Assignee:
Target version:
Start date:
11/22/2021
Due date:
11/26/2021 (about 10 months late)
% Done:

0%

Estimated time:
15.00 h

Description

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 levelResolvedVolker Friese11/15/202111/19/2021

Actions
Precedes Framework - Development #2279: Online test with archived dataAssignedShreya Roy11/29/202112/03/2021

Actions
Precedes Framework - Development #2280: Integration into mCBM data takingAssignedVolker Friese11/29/202112/03/2021

Actions
Actions #1

Updated by Volker Friese 12 months ago

Actions #2

Updated by Volker Friese 12 months ago

Actions #3

Updated by Volker Friese 12 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
Actions #4

Updated by Volker Friese 12 months ago

  • Due date changed from 11/22/2021 to 11/26/2021
Actions #5

Updated by Volker Friese 12 months ago

Actions #6

Updated by Volker Friese 12 months ago

Actions #7

Updated by Volker Friese 10 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?

Actions #8

Updated by Pierre-Alain Loizeau 10 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.

Actions #9

Updated by Pierre-Alain Loizeau 6 days ago

  • Assignee changed from Pierre-Alain Loizeau to Volker Friese

New scheme developed by Volker and Dominik will take care of this and they now gathered some MQ knowledge, so I re-assign to Volker.

Actions

Also available in: Atom PDF