Considerations for (an alternative) RICH Mirrors' alignment HLT1 line

(Key trigger line design requests in bold)

The RICH mirrors' alignment relies on RICH photodetectors collecting "enough" Cherenkov photons from high momentum tracks traversing the RICH. It is very easy to collect enough photons from tracks in the "inner" regions of the RICH detector, but it is very hard to do so in "outer" regions, because lower eta (pseudorapidity) tracks are rarer.

The basic idea then is to pre-select useful tracks for the mirrors' alignment using an HLT1 line. We trigger on tracks in the "most outer" regions, until we have enough tracks in those regions to perform the alignment. In doing so, we collect the minimum number of tracks in the outer regions, and far more than enough tracks in the inner regions.

In Run 2, we performed the mirror alignment once per fill. Our concept was implemented, and within the first couple hours of a fill, we triggered on 3M events with our one-track (a high momentum track in specific eta/phi region) trigger line. There were two trigger decisions in the line, one to populate RICH1 and the other for RICH2. The triggered raw events were stored on local disks of the HLT "Alignment" Farm, and then using the Farm we processed every track from those events that was over a high momentum threshold (40 GeV Rich2, 20GeV Rich 1), to create the photon histograms we needed to assess and align (in software) the RICH mirrors. O(5) tracks per event were reconstructed per event under these conditions. Because the raw selected events were distributed across 1500 nodes, and processed in parallel, there was no possibility to reconstruct fewer inner tracks, as we had no way to count how many inner tracks were already reconstructed. Fortunately the processing time was more than fast enough for our needs in Run 2.

In Run 3, as in Run 2 we expect to perform the alignment once per fill. In the first instance, we would like to recreate the Run 2 line. Run 3 events will of course have more tracks per event. We would certainly collect usable tracks much faster (which could be reduced by a prescale if needed). It would also be a benefit if we were able to raise our momentum requirement for the tracks we reconstruct. Note that we think we can reduce the total number of events we need to collect somewhat by granulating our (eta/phi) cuts, but it would likely be by a small fraction rather than an order of magnitude. In any case we, will want to have this line prepared and ready for commissioning.

In principle however, we could perform the alignment with far fewer selected and/or reconstructed tracks. Fewer selected tracks can be achieved by using a predetermined map of eta/phi regions corresponding to tracks whose photons unambiguously bounce off each populated combination of mirrors in the RICH. We presume it would be impossible to count tracks that fill those regions in real time. What could be done instead, is that a weighting is applied to each region within the HLT line, such that if the trigger track would put photons into an "outer" region the track (or event) would always be accepted, but if the trigger track was more central it would fail the trigger a large fraction of the time rather than be selected. If only the trigger track is kept, and the map is accurate, then in principle we only need O(100k) total reconstructed tracks to perform the mirror alignment. If the whole event has to be kept then we could choose to still reconstruct only those O(100k) tracks if it is possible to flag them.

We recognize that while this new version of of trigger line is a very nice idea to reduce our trigger rate or reconstruction time, there may be several hurdles to making it work, which is why we are trying to determine if this idea is even feasible first. We also recognize that given the awesome crunching power of the farm and the increased number of tracks per event, that our idea may not be strictly necessary --- however, we think it is at least worthwhile to suggest the idea if it can potentially save CPU cycles and/or trigger bandwidth. It also may allow us to perform automated checks of the detector geometry during our alignments.

@pnaik, @asolomin, @rilane (https://its.cern.ch/jira/projects/RICH/issues/RICH-16)

P.S. For reference, the Run 2 RICH mirrors' alignment Line code is here: https://gitlab.cern.ch/lhcb/Hlt/-/blob/2018-patches/Hlt/Hlt1Lines/python/Hlt1Lines/Hlt1CalibRICHMirrorLines.py and last used settings are here: https://gitlab.cern.ch/lhcb/Hlt/-/blob/2018-patches/Hlt/HltSettings/python/HltSettings/Physics_pp_2017.py#L355