Bandwith of D0 -> KS KS trigger lines
Following up from #840, the bandwidth of the following lines
Hlt2Charm_DstpToD0Pip_D0ToKsKs_DDDDDecision
Hlt2Charm_DstpToD0Pip_D0ToKsKs_DDLDDecision
Hlt2Charm_DstpToD0Pip_D0ToKsKs_DDLD_TightDecision
Hlt2Charm_DstpToD0Pip_D0ToKsKs_DDDD_TightDecisionis unreasonably high (> 60 MB/s for the first two, > 20 MB for the last two, see https://rjhunter-bandwidth.web.cern.ch/HighMuData/hlt2__production__rates_for_all_lines_split_by_stream.html#turbo_label for detailed results). This needs to be promptly fixed or we will have to disable them for the rest of data taking, also because no signal was found so far using them as far as I know (for sure not in Run 2). @lpica could you look at whether signal can be reconstructed, at least in simulation, and with which efficiency?
Also probably these cuts can be tightened (but I am not sure about how much bandwidth you can gain with that: https://gitlab.cern.ch/lhcb/Moore/-/blob/2024-patches/Hlt/Hlt2Conf/python/Hlt2Conf/lines/charm/d0_to_ksks.py?ref_type=heads#L118 (assuming that UT uncertainties are well tuned now) https://gitlab.cern.ch/lhcb/Moore/-/blob/2024-patches/Hlt/Hlt2Conf/python/Hlt2Conf/lines/charm/d0_to_ksks.py?ref_type=heads#L47 (pT cut)