HLT1 Lumi counters in PbPb with GEC
!1237 (merged) sets the default HLT1 ion sequence for 2023 without a GEC. Even if that seems to work with average centrality simulation, and with 2022 data, we think it is still a good idea to have a sort of "sanity" GEC in the sequence. This can be looser than 25k, it should be seen more as a safety net to make sure we don't crash or reach a throughput bottleneck with very high occupancy events. While running on 2022 data we didn't observe such a case, the significantly lower effective collision rate of last year is not representative of the conditions we will have in 2023.
The main issue/concern for implementing this loose GEC is how we treat luminosity counters. In principle, we would like to have some way of still getting luminosity information for events above the GEC. For some counters (for instance hit-related counters) this should not be a problem, since we would only need to run decoding algorithms in order to calculate them. But for more high-level counters, such as ones based on tracking information, we would like to avoid running the full reconstruction for these very busy events but still have a way of extracting some luminosity information ( an option would be to have it in the form of an overflow value in the counter, which was the approach adopted in Run 2).
This issue is to discuss and understand:
- what is the best approach for handling lumi counters for very busy events that might fail a loose GEC in HLT1?
- is the current implementation of the lumi counters adapted to handle the chosen approach? And if not, what are the steps & time needed to adapt it?
@baudurie @samarian @rmatev @cmarinbe @decianm @dcraik @sxian @elniel