Skip to content
Snippets Groups Projects

Draft : Upsilon -> ll

Closed Raja Nandakumar requested to merge nraja_rd_upsilon2ll into master

patch generated by https://gitlab.cern.ch/lhcb/Moore/-/jobs/18533986

This is the first version of a work in progress to enable the analysis of upsilon -> ll (ee, mumu, tautau, mutau, etau) in run3. Of course the hope is that a code review will highlight both the code issues and any issues with the current default cuts applied.

Note that upsilon -> emu is already a part of the qqbar->emu lines.

The bits of code that have been added :

  1. New file rd/upsilon_to_ll.py - contains the trigger lines for the above mentioned lines.
  2. Update of rd/builders/qqbar_builder.py to contain the relevant make_... functions make_prompt_mumu make_prompt_ee make_prompt_tautau make_prompt_etau make_prompt_mutau

Thanks and Cheers, Raja (and Fergus).

Merge request reports

Merge request pipeline #3564344 failed

Merge request pipeline failed for 78ca26f6

Closed by Raja NandakumarRaja Nandakumar 2 years ago (Mar 6, 2022 10:01am UTC)

Merge details

  • The changes were not merged into .

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
243
244 # filter based on the rd_detached_mue / make_detached_mue_with_brem with zero cuts on IP and added combination cuts
245 @configurable
246 def make_prompt_mumu(
247 name="prompt_mumu_builder",
248 min_dilepton_mass=0.0 * MeV,
249 max_dilepton_mass=6000.0 * MeV,
250 min_dilepton_pt=1.0 * GeV,
251 max_ipchi2_mumu=50,
252 parent_id="J/psi(1S)",
253 min_probnn_mu=0.0,
254 IsMuon=True,
255 min_pt_mu=0.5 * GeV,
256 minipchi2=0, # must be 0 for a prompt builder
257 min_bpvvdchi2=0.0, # must be 0 for a prompt builder
258 max_trghostprob=0.2,
    • Hello @nraja, thanks for this contribution. For sure you are aware of !1220 (merged) as you are using part of its code, I am thinking we could have just one qqbar_to_ll module which would contain all combinations. What do you think?

    • Author Developer

      Hi @msaur, thanks! I am happy for the code to be added into a generic qqbar_to_ll. I suppose that will involve some major changes - maybe it will be simpler to discuss this in a meeting? Among the topics I suppose will be :

      1. Mass cut range
      2. Naming of the lines
      3. What will be the rate of such lines.

      If we have a large mass range, we do not need separate lines for each meson.

    • Hello @nraja, I need to find a time, but hopefully later today or tomorrow I could push updated qqbar -> emu code.

      For mass range, we have to be aware of final rates, so what we could have is jpsi + psi(2S) and then Y(1S) + Y(2S) + Y(3S) together, but hardly having a full range from jpsi to Y.

      Some chat would be a good idea, ping me via mail or on mattermost.

    • Please register or sign in to reply
  • 61 )
    62
    63
    64 @register_line_builder(all_lines)
    65 @configurable
    66 def Hlt2RD_UpsilonToMuMu_Line(
    67 name="Hlt2RD_UpsilonToMuMu_Line", prescale=1, persistreco=False
    68 ):
    69
    70 mumu = make_prompt_mumu(
    71 name="Hlt2RD_UpsilonToMuMu_Builder",
    72 parent_id="Upsilon(1S)",
    73 min_dilepton_mass=7000.0 * MeV,
    74 max_dilepton_mass=13000.0 * MeV,
    75 min_dilepton_pt=1.0 * GeV,
    76 min_pt_mu=1.0 * GeV,
    • Comment on lines +75 to +76

      just guessing: the pT's could possibly be a bit tighter without signal loss, right? You might be able to loosen a bit other requirements. If so, would apply to all of the selections. The muons are probably fine, but I wonder about the background rate of the electron and tau lines

    • Please register or sign in to reply
  • 74 max_dilepton_mass=13000.0 * MeV,
    75 min_dilepton_pt=1.0 * GeV,
    76 min_pt_mu=1.0 * GeV,
    77 )
    78 return Hlt2Line(
    79 name=name,
    80 algs=upfront_reconstruction() + [mumu],
    81 prescale=prescale,
    82 persistreco=persistreco,
    83 )
    84
    85
    86 @register_line_builder(all_lines)
    87 @configurable
    88 def Hlt2RD_UpsilonToTauTau_Line(
    89 name="Hlt2RD_UpsilonToTauTau_Line", prescale=1, persistreco=False
    • Comment on lines +88 to +89

      Please specify the decay of the taus. Possibly any of tau->3pi, tau->mu and tau->e (yes, that's an option as well if we have efficient HLT1 triggers, the resolution is as good as the muons) could yield some potential.

    • Please register or sign in to reply
  • 100 min_pt_e=0.5 * GeV,
    101 min_pt_tau=0.3 * GeV,
    102 minipchi2=0, # must be 0 for a prompt builder
    103 min_bpvvdchi2=0.0, # must be 0 for a prompt builder
    104 max_vchi2ndof=10.0,
    105 ):
    106 """
    107 Make the detached electron-tau pair, opposite-sign for now.
    108 """
    109 pvs = make_pvs()
    110 descriptor = "[{} -> e+ tau-]cc".format(parent_id)
    111 taus = make_rd_tauons_hadronic_decay(
    112 best_pi_ipchi2_min=minipchi2
    113 ) # Make them prompt(?)
    114 electrons = make_long_electrons_with_brem()
    115 daughters_code = {
    • you are apparently using LoKi for combining the particles and then some ThOr filters on top. This is unnecessarily complicated and slows down the process. Have a look at rdbuilder_thor to see how to use ThOr combiners with a selection instead.

    • Please register or sign in to reply
  • 98 min_PIDe=2.0,
    99 max_adocachi2=30.0,
    100 min_pt_e=0.5 * GeV,
    101 min_pt_tau=0.3 * GeV,
    102 minipchi2=0, # must be 0 for a prompt builder
    103 min_bpvvdchi2=0.0, # must be 0 for a prompt builder
    104 max_vchi2ndof=10.0,
    105 ):
    106 """
    107 Make the detached electron-tau pair, opposite-sign for now.
    108 """
    109 pvs = make_pvs()
    110 descriptor = "[{} -> e+ tau-]cc".format(parent_id)
    111 taus = make_rd_tauons_hadronic_decay(
    112 best_pi_ipchi2_min=minipchi2
    113 ) # Make them prompt(?)
    • Comment on lines +112 to +113

      prompt pions will probably dominate the rate. As the tau's have a small but significant lifetime, any requirement on the pi minipchi2 might be crucial to achieve manageable rates

    • Please register or sign in to reply
  • Some more general comments:

    1. could you put the rate (measured on the standard minbias MC as suggested in the documentation) and possibly signal efficiencies that you measured in the description of the MR? That would help judging what will need tuning
    2. I see you are using tau->3pi decays for the lines involving taus. If you get a sensible rate with that, that's fine. But I doubt it. Carlos and friends had some trouble getting low background for proposed ditau resonance searches (actually above the Upsilon masses) and in the end opted for leptonically decaying taus (https://arxiv.org/abs/2106.12615).
  • Author Developer

    Thanks everyone.

    1. Happy to - but should we wait a more detailed discussion about the fate of this MR (!1323 (comment 5268439))?
    2. Thanks. Will think about it.
    • Author Developer

      Hi,

      As an update giving the information on the rates from my test as requested by Titus above :

        LAZY_AND: Hlt2RD_UpsilonToEE_LineDecisionWithOutput                                                          #=3393    Sum=0           Eff=|( 0.000000 +- 0.00000 )%|
        LAZY_AND: Hlt2RD_UpsilonToMuE_LineDecisionWithOutput                                                         #=3393    Sum=0           Eff=|( 0.000000 +- 0.00000 )%|
        LAZY_AND: Hlt2RD_UpsilonToMuE_SS_LineDecisionWithOutput                                                      #=3393    Sum=1           Eff=|(0.02947244 +- 0.0294681)%|
        LAZY_AND: Hlt2RD_UpsilonToMuMu_LineDecisionWithOutput                                                        #=3393    Sum=2           Eff=|(0.05894489 +- 0.0416680)%|
        LAZY_AND: Hlt2RD_UpsilonToTauTau_LineDecisionWithOutput                                                      #=3393    Sum=1           Eff=|(0.02947244 +- 0.0294681)%|
        LAZY_AND: Hlt2RD_UpsilonToeTau_LineDecisionWithOutput                                                        #=3393    Sum=1           Eff=|(0.02947244 +- 0.0294681)%|
        LAZY_AND: Hlt2RD_UpsilonTomuTau_LineDecisionWithOutput                                                       #=3393    Sum=1           Eff=|(0.02947244 +- 0.0294681)%|

      Cheers, Raja.

    • Hello @nraja , thanks for rates, what exact MC have you used? Please put rates to the description of this MR and translate them into kHz for simpler check.

    • Please register or sign in to reply
  • Author Developer

    Hi @msaur,

    Thanks. With this, the results are :

    LAZY_AND: Hlt2RD_UpsilonToEE_LineDecisionWithOutput #=14983 Sum=3 Eff=|(0.02002269 +- 0.0115589)%| LAZY_AND: Hlt2RD_UpsilonToMuMu_LineDecisionWithOutput #=14983 Sum=9 Eff=|(0.06006808 +- 0.0200167)%| LAZY_AND: Hlt2RD_UpsilonToTauTau_LineDecisionWithOutput #=14983 Sum=0 Eff=|( 0.000000 +- 0.00000 )%| LAZY_AND: Hlt2RD_UpsilonToeTau_LineDecisionWithOutput #=14983 Sum=0 Eff=|( 0.000000 +- 0.00000 )%| LAZY_AND: Hlt2RD_UpsilonTomuTau_LineDecisionWithOutput #=14983 Sum=0 Eff=|( 0.000000 +- 0.00000 )%|

    In total there are 12 events out of 14983 events which pass the lines, giving a rate of about 0.1%.

    Assuming a 1MHz rate, if my understanding is correct, these 5 lines together give a 1KHz rate of data. I do not have a feel for whether these numbers are reasonable!

    Cheers, Raja.

  • Miroslav Saur changed target branch from master to msaur_rd_qqbar2emu

    changed target branch from master to msaur_rd_qqbar2emu

  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Please register or sign in to reply
    Loading