WIP: Add detached dimuon lines for Jpsi and psi(2S), plan to persist tracks associated with dimuon

Purpose

We would like to study the performance of the detached Jpsi/psi(2S) to dimuon lines for the run3 B&Q analyses. This study should include a Jpsi/psi(2S) selection and a persist reco for the nearby tracks.

Current status

Write the structure of the Jpsi/psi(2S) selections, test the efficiency using some benchmark b->Jpsi X decays.

Now I'm trying to study the performance of the persist Reco. In the template of D02HH and Bs2JpsiPhi I did not find a suggested way of doing the persist Reco using the current framework. My plan is: add some exclusive b->JpsiX lines, where X stands for an additional track or tracks; cut the vertex quality between Jpsi + any track; check the efficiency. It would be appreciated if anyone could point out if there's any other recommended method to perform a "persist Reco" reconstruction in the current Moore framework.

Structure of the line

The configuration of the new lines are defined in Moore/Hlt/Hlt2Conf/python/Hlt2Conf/lines/psi2MuMu_detached.py. This file is written based on the structure of D02HH lines:

Muon selection

Defined in make_selected_muons. Cut the track quality, IPCHI2, pT, p and PID of the muon.

Dimuon selection

Defined in make_dimuon_detached. Cut a mass window which covers both Jpsi and psi(2S), cut pT for muons and dimuon system, vertex quality. The dimuon vertex is required to have a significant distance from PV. The DIRA cut in D02HH line is removed as we do not require Jpsi/psi(2S) from PV.

Jpsi and psi(2S) selection

Defined in make_Jpsi_detached and make_psi2S_detached. Cut only the invariant mass. For both Jpsi and psi(2S), the mass window is from PDG mass - 120MeV to PDG mass + 100 MeV.

HLT2 lines

Defined in Jpsi2MuMudetached_line and psi2S2MuMudetached_line.

Persist Reco

Working in progress.

How to determine selections

It's arbitrary at this moment. Further studies are required.

Validation of efficiencies

Several benchmark b->JpsiX decays are used for checking the efficiencies. For each decay mode, 100000 signal events are used as input. All the input events are after the HLT1 filtering, namely the ones located in /MC/Upgrade/Beam7000GeV-Upgrade-MagDown-Nu7.6-25ns-Pythia8/Sim09c-Up02/Reco-Up01/Trig0x52000000/EVENTTYPE/LDST. Efficiency is defined as "(Number of events where one Jpsi is reconstructed)/(Number of events processed)". The result is:

11144008: B0->Jpsi rho, Jpsi->dimuon, rho->pipi; efficiency = (25.50300 +- 0.137837)%
12143001: B+ -> Jpsi K+, Jpsi->dimuon; efficiency = (26.16200 +- 0.138987)%
12245021: B -> Jpsi K pi pi, Jpsi->dimuon; efficiency = (26.01100 +- 0.138727)%
15144001: Lb -> Jpsi p K, Jpsi->dimuon; efficiency = (23.35200 +- 0.133787)%

The efficiencies are at 20% level for , which is consistent with the previous studies (although the selections are not carefully tuned to be the same...)

Estimation of bandwidth cost ?

I did not see an output file which can be used directly for a bandwidth cost estimation. We could use the "efficiency" of the mini bias events after HLT1 filtering, namely the ones in /MC/Upgrade/Beam7000GeV-Upgrade-MagDown-Nu7.6-25ns-Pythia8/Sim09c-Up02/Reco-Up01/Trig0x52000000/30000000/LDST, to show the level of background rate. The result is:

30000000: mini bias; efficiency = (0.01300000 +- 0.00360532)%

Option files:

python files locates in the B&Q eos area: /eos/lhcb/wg/BandQ/trigger/Upgrade/detached_Jpsi_scripts/options

log files: /eos/lhcb/wg/BandQ/trigger/Upgrade/detached_Jpsi_scripts/logs

To run a test, the corresponding shell script is: /eos/lhcb/wg/BandQ/trigger/Upgrade/detached_Jpsi_scripts/shell/runme.sh