Background-merged events rejected by ZDC tmax cut (269 ns)
- Dominant language
- C++
- Stars
- 13
- Forks
- 42
- Avg merge
- 18h 44m
- Merged PRs (30d)
- 55
Description
# Default ZDC `tmax` rejects valid events from `SignalBackgroundMerger`
## Summary
When reconstructing files produced with the `SignalBackgroundMerger`, the default ZDC cluster time cut
```cpp
// src/detectors/ZDC/ZDC.cc (line 183)
.tmax = 269 * dd4hep::ns,
```
rejects valid signal events, even when **all background contributions are set to zero**.
The `SignalBackgroundMerger` tool spreads events over a time frame to emulate the continuous collision stream, making the default `tmax` possibly incompatible with this workflow. Typically, the time window is of 1000-5000 ns.
Increasing `tmax` appears to restore the expected reconstructions relying on the ZDC.
Possible limitation: the current value (269 ns) could have been chosen for a good reason. Is this documented?
@DraTeots @veprbl @mdiefent @sebouh137
Contributor guide
Research direction
Start in src/detectors/ZDC/ZDC.cc around line 183 and inspect why the default 269 ns tmax is used. Reproduce reconstruction with files from SignalBackgroundMerger, including the zero-background case, and compare results after changing the time window. Done means valid signal events are retained and the reason for the chosen limit is documented or the default is corrected.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp
- Domain
- backend
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 68/100