MuchDigitizeGem: event-by-event is sensitive to the event rate
If I run run_digi.C event-by-event with event rate = 1, the run_digi.C crashes at the end with such error:
[INFO] Daq: Finish run
[INFO] Buffer status: 31694 data from t = 1.52889e+10 to 1.54355e+10 ns
STS Status DAQ buffer: 30866 data from t = 1.52889e+10 to 1.54355e+10 ns
MUCH Status DAQ buffer: 0 data from t = -1 to -1 ns
TRD Status DAQ buffer: 544 data from t = 1.52889e+10 to 1.54355e+10 ns
TOF Status DAQ buffer: 284 data from t = 1.52889e+10 to 1.54355e+10 ns
[INFO] Daq: Closing Time slice [flexible], data: [381935737.000, 15435481441.000] ns, STS 161743 MUCH 31746 TRD 2858 TOF 1692 , MC events 10
[ERROR] MuchDigitizeGem: CheckBuffer: Found digi at t = 1.66512e+09 ns after digi at t = 3.80471e+09 ns
root.exe: /lustre/cbm/users/anna/APR21/core/base/CbmDaq.cxx:133: void CbmDaq::CloseTimeSlice(): Assertion `CheckOutput()' failed.
Updated by Vikas Singhal over 1 year ago
As you mentioned input Event Rate = 1 means (1 event in one second) and TS Length = -1 (as per my understanding) means all the events after digitization will be placed in one time slice only and time slice length will be flexible. You took 10 events so time slice length should be more than 10 second whihch is seen that digis are spread from 0.381935737 second to 15.435481441 second.
I checked thoroughly in the MUCH digitizer but not found any thing which depend on the event rate. As per the error message it looks that a time slice closed at some time t and in next time slice some digi arrived at time lesser than t. But in one time slice how it may be possible. Volker may suggest some clue.
In between I will request Shreya and Sayak to take similar input and try to regenerate the same. Can you also provide DEBUG info. (Probably output will be huge).
Updated by Volker Friese over 1 year ago
It seems to me that indeed the simulated time (10 s) exceeds the dynamic range of some time representation somewhere. If, for instance, an unsigned int (4 Byte) is used to represent the time in ns, the maximal range is 2^32 ns = 4.3 s. Larger times will lead to wrapping of the respective integer and, consequently, wrong time information.
This will disappear when we always represent the digi time relative to the time slice, but this is not yet there in the simulation. There will be an agreement of the maximal time slice length (some seconds), which the time representation can be adjusted to. Luckily, the event rate 1/s was chosen here by accident and has no real physics use case :-)