There was an issue discovered in the light event timestamps during validation and trying to match charge and light timestamps.
Except for the first file of a production run all the timestamps do not start a 0 as expected and have a non proper rollover behaviour.
There was an issue discovered in the light event timestamps during validation and trying to match charge and light timestamps. Except for the first file of a production run all the timestamps do not start a 0 as expected and have a non proper rollover behaviour.
The "not starting at 0" issue could be routed down to the following line https://github.com/DUNE/larnd-sim/blob/e699f84400ad30291bd4282874c927a0e62eaecc/cli/simulate_pixels.py#L490 where the event times get looked up with global
light_event_id
as index but theevent_times
array is only defined for a single input file using file-by-file event ids.Also the use of the
event_times
array for charge readout timestamps at https://github.com/DUNE/larnd-sim/blob/e699f84400ad30291bd4282874c927a0e62eaecc/cli/simulate_pixels.py#L457 is not getting the correct timestamps as it conflicts with the definition of theevent_times
array at https://github.com/DUNE/larnd-sim/blob/e699f84400ad30291bd4282874c927a0e62eaecc/cli/simulate_pixels.py#L366We try to address this issue by defining
event_times
in a way that global event ids can be used as index, e.g. making it a dictionary.The wrong rollover behaviour in the light timestamps might be due to the double implementation of the rollover at https://github.com/DUNE/larnd-sim/blob/e699f84400ad30291bd4282874c927a0e62eaecc/larndsim/light_sim.py#L609 and https://github.com/DUNE/larnd-sim/blob/e699f84400ad30291bd4282874c927a0e62eaecc/larndsim/light_sim.py#L615