QIE digi time offset isn't accounted for in simulation

[bryngemark]

Currently, the QIE digi code assigns a time stamp to hits which is based on allowing time t=0 at the start of the first sample out of five, effectively adding an offset sampleNumber*1/sampling_frequency to the time. In addition, there's an arbitrary time shift to make sure the rising pulse is well within the sample interval.

This means that the timing of TS digis is currently offset by this number compared to the rest of the hits in our simulation, which sets t=0 when the beam electrons hit the target (on average). It is currently mainly a concern when it comes to making cuts on time later in the TS reconstruction chain, where the digi time offset has to be known.

Proposed solution The QIE digi + rechit chain could subtract the offset introduced by the QIE digi code. These are all configurable, passable parameters and it could be done with appropriate defaults in the configuration of these processors.

Alternative solution considered We could also adjust the baseline time used for timing cuts in e.g. clustering. In light of upcoming out-of-time studies, I think this solution is suboptimal, since it doesn't align the TS hits in time with e.g. Ecal hits.

[bryngemark]

@EBerzin just to couble check you're not running into some version of this...

[EBerzin]

I did run into this. I ended up just adjusting the baseline time (using the pad_time variable) for each of the TS pads to match the output of the QIE digi code.