search

DUNE-DAQ / trigger

Trigger infrastructure of the DUNE DAQ
0 stars 6 forks source link

Missing TriggerCandidate Fragments #357

Open eflumerf opened 1 day ago

eflumerf commented 1 day ago

https://github.com/DUNE-DAQ/trigger/blob/f8835d4eee21f50d77331910b0fcfe16bae9f96e/src/TCProcessor.cpp#L303

When a TriggerCandidate is created with a time_candidate - time_start difference larger than the TCReadoutMap's time_before, the TriggerCandidate Fragment will not be found, as they are indexed in the buffer by their start time. There are two potential solutions:

Index the TCWrappers in the latency buffer by time_candidate (the trigger timestamp), so it should always be in the relevant readout window

OR

When creating the TriggerDecision in TCProcessor, make sure that SourceIDs with subsystem kTrigger have the original window so they are always recovered during later retrieval.

ArturSztuc commented 1 day ago

This has been an issue since long time before, even in v4 -- we only discovered it recently though. It seems like we never really tried to ask MLT for a shorter readout window than the one specified by the Random (or in v5, Timing) TCMaker.

Indexing the TCWrappers in the latency buffer by time_candidate would be one workaround, but time_candidate is not specified by many triggering algorithms.

I would say for now we should use more reasonable configuration (i.e. readout window equal to or longer than the one specified by RandomTCMaker), and long-term, re-work how readout windows are specified/enforced by the MLT. MLT has a lot of logic that overrides the readout windows, and many "caveats" like the one above. I think this requires a bit more careful thinking and re-writing/thinking of the MLT.

I was going to present on this issue (MLT/TD readout windows vs TC readout windows) at one of the incoming DS/PP meetings and start working on this soon (hopefully before v5.3 release).

bieryAtFnal commented 20 hours ago

This issue was previously reported in Issue 270.