FairDevice class comprising the functionality of CbmRecoTs (unpacker + trigger + event builder). Including the infrastructure to run it (shell scripts).
#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.