Change this sub-batch from segment based to pixel based. Currently we warn users not to enter sub-batch and tune this parameter to try to cover all segments of a batch in one sub-batch. The reason is that the signals on the signals won't be summed up which would cause inaccurate ADC simulation. In theory, you could even get two hits on the same pixel at the same time. If we were keeping the segment sub-batch, at least we should take the readout simulation part out of the sub-batch loop, but it would still be memory heavy, so it defeats the purpose of the sub-batch.
I think it's a good idea to change this sub-batch to be pixel-based (We can do something similar for the light simulation.) We do still need to provide a size of how many segments, but we can then set it to be inclusive trivially (I think...). It should also ease the memory crisis.
I'm interested in this work but cannot commit at the moment. Tag others who might be interested to share the workload @jaafar-chakrani @mjkramer .
Paraphrasing Kazu's suggestion here:
Change this sub-batch from segment based to pixel based. Currently we warn users not to enter sub-batch and tune this parameter to try to cover all segments of a batch in one sub-batch. The reason is that the signals on the signals won't be summed up which would cause inaccurate ADC simulation. In theory, you could even get two hits on the same pixel at the same time. If we were keeping the segment sub-batch, at least we should take the readout simulation part out of the sub-batch loop, but it would still be memory heavy, so it defeats the purpose of the sub-batch.
I think it's a good idea to change this sub-batch to be pixel-based (We can do something similar for the light simulation.) We do still need to provide a size of how many segments, but we can then set it to be inclusive trivially (I think...). It should also ease the memory crisis.
I'm interested in this work but cannot commit at the moment. Tag others who might be interested to share the workload @jaafar-chakrani @mjkramer .