Skip to content
Snippets Groups Projects

B2OC: Tbc & Xibc decays with similar final states

Merged B2OC: Tbc & Xibc decays with similar final states
Xibc-Tbc-decays into b2oc_upgrade
Merged Ivan Polyakov requested to merge Xibc-Tbc-decays into b2oc_upgrade

adding Tbc (bcu~d~ tetraquark) and Xibc decay lines to HLT2 aiming to make them similar between each other and to already existing Xibc lines. While reducing rates to bring down to <200Hz had adjusted selection for existing Xibc and Ombc lines using created make_xibc2cx, make_xibc2ccx, make_tbc2cx, make_tbc2ccx with tighter cuts

  • PT(Xibc/Tbc) > 6 GeV [was 5 GeV]
  • PIDk(K) > -2, PIDp(p) > -2 [was -5]
  • vtx(Charm)_Z - vtx(Xibc/Tbc)_Z > -0.5mm
  • in Xibc/Tbc -> Charm + hadrons: PT(p/k/pi) > 500 MeV [was mainly 250 MeV]
  • in Xibc/Tbc -> Charm1 + Charm2 + hadrons: PT(p/k) > 500 MeV, PT(pi) > 350 MeV
  • in Xibc/Tbc -> Charm + hh: sumPT(hh) > 2.25 GeV
  • in Xibc/Tbc -> Charm1 + CHarm2 + hh: sumPT(hh) > 1.25 GeV

Plus created dedicated tighter versions of D0, D+, Lc, Xic selectors named _for_xibc with

  • PIDk(K) > -2, PIDp(p) > -2 [was -5]
  • PIDk(pi) < 2 [was 5]
  • vchi2pdof < 7, [was 10]
  • tighter mass windows:
    • +-50MeV for D0->Kpi
    • +-40MeV for D+->Kpipi, D0->K3pi, Lc->pKpi, Xic+->pKpi, Xic0->ppKpi
  • and for D0->K3pi increased FD_chi2>49 [while keep 36 for all others]. Logic is that more tracks give better FD resolution, plus more pions in final state means larger background from PV.

All lines with D0 are in two variants - D0ToKPi and D0ToKPiPiPi. Merged versions D0ToKPiOrKPiPiPi are also prepared and can be included in hlt2 or sprucing at any moment.

Edited by Ivan Polyakov

Merge request reports

Loading
Loading

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
  • Ivan Polyakov added B2OC label

    added B2OC label

  • Ivan Polyakov assigned to @abertoli, @sblusk, @ipolyako, and @shunan

    assigned to @abertoli, @sblusk, @ipolyako, and @shunan

  • Ivan Polyakov changed title from Draft: [B2OC] T{--}bc {-(bcud tetraquark) -}& Xi{--}bc decays with similar final states to Draft: [B2OC] Tbc & Xibc decays with similar final states

    changed title from Draft: [B2OC] T{--}bc {-(bcud tetraquark) -}& Xi{--}bc decays with similar final states to Draft: [B2OC] Tbc & Xibc decays with similar final states

  • Ivan Polyakov changed the description

    changed the description

  • Software for LHCb added RTA label

    added RTA label

  • Ivan Polyakov added 34 commits

    added 34 commits

    Compare with previous version

    Toggle commit list
  • Ivan Polyakov added 1 commit

    added 1 commit

    Compare with previous version

  • Ivan Polyakov added 1 commit

    added 1 commit

    Compare with previous version

  • Shunan Zhang
    Shunan Zhang @shunan ·
    Developer

    @ipolyako Is this MR ready for review?

  • Shunan Zhang changed target branch from master to b2oc_upgrade

    changed target branch from master to b2oc_upgrade

  • Ivan Polyakov changed the description

    changed the description

  • Ivan Polyakov added 2 commits

    added 2 commits

    • 59d7ef21 - debugging
    • 0f9b36ff - fix Lambda lines, adjust selections and add Tbc & tight_dzero_kpipipi builders

    Compare with previous version

  • Ivan Polyakov added 1 commit

    added 1 commit

    Compare with previous version

  • Ivan Polyakov marked this merge request as ready

    marked this merge request as ready

  • Ivan Polyakov changed the description

    changed the description

  • Alessandro Bertolin marked this merge request as draft

    marked this merge request as draft

  • Alessandro Bertolin changed title from [B2OC] Tbc & Xibc decays with similar final states to Draft: B2OC: Tbc & Xibc decays with similar final states (shifters PLEASE ignore)

    changed title from [B2OC] Tbc & Xibc decays with similar final states to Draft: B2OC: Tbc & Xibc decays with similar final states (shifters PLEASE ignore)

  • Alessandro Bertolin requested review from @abertoli

    requested review from @abertoli

  • Alessandro Bertolin requested review from @shunan

    requested review from @shunan

  • Ivan Polyakov added 1 commit

    added 1 commit

    • 65a73321 - tighten protons in Xibc^Ccharm+h(h)

    Compare with previous version

    • Alessandro Bertolin
      Alessandro Bertolin @abertoli ·
      Developer
      Resolved by Alessandro Bertolin

      @ipolyako concerning this: My first idea on how to reduce them is to change hadron selection to make_tightpid_tight_XXX. The question is should I do the same for other Xibc->Dh(h), Xibc->DDh(h) lines even if their rate is below 1kHz and they're not mine?

      I am not sure I understand what you mean but the golden rule is that author A can NOT applay cuts to line a that will change the retention of line b authored by B

      should you have any issue with this rule myself and @shunan will advise you on the code

      if you mean something different please try again to tell me your point

    • Alessandro Bertolin
      Alessandro Bertolin @abertoli ·
      Developer
      Resolved by Alessandro Bertolin

      @ipolyako concerning retentions let me add this example

      for a line I care the expected signal rate is easy to compute because all BR and fragmentation fractions are know, 9.8 Hz

      with the tuning in the present Moore master I get (1e+6 * 8./150000.) = 53.33 Hz i.e. running on 150k I retain 8

      so clearly 50 Hz > 10 Hz ... but I am not multiple orders of magnitude away ...

      so in a first attempt starting from 1 kHz you could try to reach 100 Hz and then we start to argue from there

      concerning the expected signal rate I may have omitted to tell you that we use 100 % trigger efficiency for it so it is just a product of the b cross section, the fragmentation function and the relevant BR

      but in your specific case it can well be that most of these factors are unknown ... so if you put < 10 Hz or any other guestimate you have it's fine

      Edited by Alessandro Bertolin
  • Ivan Polyakov added 4 commits

    added 4 commits

    Compare with previous version

    Toggle commit list
  • Ivan Polyakov added 1 commit

    added 1 commit

    • d6798d19 - fix missing bc2vtx_sep and formatting

    Compare with previous version

  • Ivan Polyakov added 1 commit

    added 1 commit

    Compare with previous version

  • Alessandro Bertolin
    Alessandro Bertolin @abertoli ·
    Developer

    @ipolyako @sblusk (cc @shunan) let me try to catch up a few point above:

    • A natural way to do that would be modify make_tight_dzero_... selection, but that's likely to influence many people. Maybe it's a good thing for everybody, or should we instead create a new selector, let's say make_tightmass_tight_dzero_XXX?

    golden rule: that author A can NOT applay cuts to line a that will change the retention of line b authored by B

    please let's stick to the golden rule, may be proponent B need a wider mass window on the D0 to estimate some background, it should not be an issue to introduce a new selector

    • During this year, the BW won't be an issue, right? So maybe it's OK that we're a bit over the BW budget?

    can we quantify with numbers the meaning of a bit over the budget ? at the top of this page there were lines running > 1 kHz while your expected signal rate is O(1) Hz

    if you click here: https://lhcbpr-hlt.web.cern.ch/UpgradeRateTest/RateTest_lhcb-master.1907_Moore_hlt2_rate_and_size_x86_64_v3-centos7-gcc11-opt+g_2023-01-24_02:33:28_+0100/all_rates.html you will see a table with the rates of all B2OC lines in master, in decreasing rate order, the top one is at 280 Hz

    I can only hope you can stay below that number

    if I have forgotten something relevant point me to it please

  • S
    Steven R. Blusk @sblusk ·
    Developer

    Hi, Can you tell me what is the rate limit for Sprucing lines?

    For the HLT2 rate-limited lines: I think the main idea, in my mind, is to come up with cuts that are as generous as possible with respect to lifetime and pT of individual particle, since we don't know the lifetime of these states, and for multibody decays, pT spectra of the lowest momentum particle can be low.

    For the D0 -> K3pi modes you could make a new "tighter" module, with a) a narrower mass window for your D0: Mass resolution for D0->K3pi is going to be ~5 MeV. So, 60 MeV --> 40 MeV mass window is going to save you up to 50% in rate. b) tighter vertex chisq / dof cut, reduce from 10 -> 6. This will only cost a few percent loss in efficiency (assuming VELO is aligned). and is not lifetime biasing, or dependent on pT (in principle). With unaligned VELO, of course you will lose more, but we're not going to be finding Tbc in 2023! c) You could tweak up the "ASUMPT' from 1800 MeV to 2000 MeV, or maybe a bit higher to see how much it gains you. Good thing here of course, is that it is just 1 cut, and can be satisfied in many ways among the four daughters.

    One could also try and consider an ASUMPT cut on the bachelor hadrons? This is what I had done in 1 Run 1/2 stripping lines. For Tbc -> Charm + hh, the 2 bachelors should have sizeable SumpT. I don't know if there is an easy way to include that kind of cut in the current framework though.

    Another possibility is to increase the minimum decay time from 0.1 ps to 0.15 ps. I know this goes against what I said above, but in reality, with a decay time resolution ~40 fs (say, optimistically), 100 fs is only 2.5 sigma. One is likely to be swamped in background here, and these events may be, for all practical purposes, useless.

    Just some thoughts from my side...

    Cheers, Steve

  • Alessandro Bertolin
    Alessandro Bertolin @abertoli ·
    Developer

    @sblusk Hi, Can you tell me what is the rate limit for Sprucing lines?

    if you look here: https://lhcbpr-hlt.web.cern.ch/UpgradeRateTest/RateTest_lhcb-master.1928_Moore_spruce_rate_and_size_x86_64_v3-centos7-gcc11+detdesc-opt+g_2023-02-12_09:52:46_+0100/plots_per_wg.html you will find the plot I attach below for convenience: snap whatever line is above 1 kHz has a, let's say, red warning attached to it (there are a few not visible in this plot, the red warning is visible in a different page)

    this 1 kHz is likely a (very) generous limit

    looking at the plot you should try to target < 400 Hz, < 200 Hz would be better

  • Alessandro Bertolin
    Alessandro Bertolin @abertoli ·
    Developer

    @sblusk For Tbc -> Charm + hh, the 2 bachelors should have sizeable SumpT. I don't know if there is an easy way to include that kind of cut in the current framework though.

    from: https://gitlab.cern.ch/lhcb/DaVinci/-/blob/master/DaVinciExamples/python/DaVinciExamples/tupling/AllFunctors.py I guess what you need is:

    F.CHILD(2, F.PT)+F.CHILD(3, F.PT)

    in the last 6 to 12 months an extensive functor writing campain occurred so now we have a significantly better coverage that when we did the conversion to ThOr of the B2OC code, F.CHILD(,) is an example

    and we had to do that conversion because we needed multi-thread compliance

  • Ivan Polyakov
    Ivan Polyakov @ipolyako ·
    Author Developer

    Hi @sblusk, @abertoli, thanks for your suggestions on reducing the rates. Concerning for SumPT for bachelor tracks in Xibc -> Charm + hh, can you suggest particular number?

  • S
    Steven R. Blusk @sblusk ·
    Developer

    Hi @ipolyako , @abertoli , Great. I could pull a number out of the air, say 1.5 GeV, but it's probably better to run a quick simulation (preferably EvtGenOnly, but maybe RapidSim is OK too), make the p, pT cuts on the D meson, it's daughters, and on the bachelors, then see what the SUMPT spectrum of the 2 bachelors looks like. Decide how much signal efficiency loss you'd be willing to tolerate (10%-ish?), and give that cut a try. What do you think? Cheers, Steve

  • Ivan Polyakov
    Ivan Polyakov @ipolyako ·
    Author Developer

    thanks Steve, I have ran RapidSim for

    • Xibc0 -> Lc+ D0 pi+ pi-
    • Xibc+ -> D0 D0 p+ pi-
    • Tbc0 -> D0 D0 pi+ pi-

    taking m(Xibc)=6.91 GeV according to Karliner&Rosner and m(Tbc)=7.14 GeV (5MeV below BD threshold).

    After applying cuts on p,PT & sumPT of Lc and D0 daughters according to make_tight_xxx lines and PT>0.25GeV for bachelor hadrons I get following histograms for sumPT of all Xibc/Tbc daughters and two bachelor tracks: Applying cut sumPT(Xibc)>5.5GeV has efficiency of 88-96% (depending on channel) and consecutive cut PT(h1)+PT(h2)>1.25GeV has efficiency of 86-93%, i.e. combined efficiency is 82-85%, which I consider is reasonable enough.

    then done similar exersize for modes with one charm:

    • Xibc+ -> Lc+ K- pi+
    • Xibc0 -> D0 p+ K-
    • Tbc0 -> D0 K- pi+

    Applying cut sumPT(Xibc)>5.5GeV has efficiency of 94-97% and consecutive cut PT(h1)+PT(h2)>2.25GeV has efficiency of 90-95%, i.e. combined efficiency is 88-92%.

    I'll estimate resulting rates today/tomorrow so can make final decision on cuts. I attach here plots for future reference.

  • S
    Steven R. Blusk @sblusk ·
    Developer

    @ipolyako : Nice.. That all seems reasonable to me as well. I'm hoping that most of the background is from prompt tracks, and so peaks at low SUMPT, and this buys roughly a factor of 2 lower MB rate. Cheers, Steve

  • Ivan Polyakov
    Ivan Polyakov @ipolyako ·
    Author Developer

    I have estimated HLT2 rates (with 86k events) after tightening selections for PT of bachelor hadrons and tightening mass windows and PID requirements for D0/D+/Lc/Xic.

    Now most of lines have HLT2 rates within 100Hz, there are only few above 200Hz:

    • TbcToD0KmPip_D0ToKPiOrKPiPiPi: 310Hz (while if separated TbcToD0KmPip_D0ToKPi: 240Hz, TbcToD0KmPip_D0ToKPiPiPi: 130Hz)
    • Xibc0ToPD0K_D0ToKPiOrKPiPiPi: 330Hz (while if separated Xibc0ToPD0K_D0ToKPi: 270Hz, Xibc0ToPD0K_D0ToKPiPiPi: 120Hz)
    • XibcpToXicpPiPi_XicpToPKPi: 200Hz
    • XibcpToLcpPiPi_LcpToPKPi: 230Hz

    the last three lines were introduced by @sblusk and their rates been reduced by factor 1.5-3x. full list can be found here.

    @sblusk, please let me know if you're OK with changes.

    @shunan, @abertoli, please let me know if you want me to put all lines in HLT2, or some of them to Sprucing.

  • Ivan Polyakov added 79 commits

    added 79 commits

    Compare with previous version

    Toggle commit list
  • Ivan Polyakov added 1 commit

    added 1 commit

    Compare with previous version

  • Ivan Polyakov added 1 commit

    added 1 commit

    Compare with previous version

    • Alessandro Bertolin
      Alessandro Bertolin @abertoli ·
      Developer
      Resolved by Alessandro Bertolin

      @ipolyako concerning "please let me know if you want me to put all lines in HLT2, or some of them to Sprucing." I understand that there are just 4 lines above 200 Hz, with the highest rate being 330 Hz

      so I would suggest Hlt2

      I would have a preference for splitting the D0 modes but I let you the final decision

      now let's assume you have the ok of @sblusk then you have to give me and @shunan some time to look at the diff of your code with the b2oc_upgrade branch, during this time you have to keep your code frozen of course, usually myself and Shunan are quite efficient in running the review, then we will merge into b2oc_upgrade

      but PLEASE when you think we have to start drop here a clear message

  • Ivan Polyakov added 1 commit

    added 1 commit

    Compare with previous version

  • Ivan Polyakov added 1 commit

    added 1 commit

    Compare with previous version

  • Ivan Polyakov added 1 commit

    added 1 commit

    Compare with previous version

  • Ivan Polyakov changed the description

    changed the description

  • Ivan Polyakov added 1 commit

    added 1 commit

    Compare with previous version

  • Ivan Polyakov changed the description

    changed the description

    • S
      Steven R. Blusk @sblusk ·
      Developer
      Resolved by Alessandro Bertolin

      @abertoli , @ipolyako @shunan : Hi,

      If I understand, the main changes to reduce the rate have been the sum(pT) on the bachelors (1.25 GeV for cchh, and 2.25 GeV for c h h), and 40 MeV mass windows on the charm baryons. If those are the only changes, they are fine with me. If we have to reduce more, it is probably better to look at other variables, like vertex chi2 / dof, where a cut at 10 is quite generous for a well-aligned detector. (A cut at 6 would likely cut 20-30% more background with few percent signal loss in signal efficiency. Cheers, Steve

  • Ivan Polyakov changed the description

    changed the description

  • S
    Steven R. Blusk @sblusk ·
    Developer

    @ipolyako : It's fine to leave, if rates are acceptable. I have some old B-->DD MC samples (2012), and the vertex chisq is strongly peaked at 0. Of course, this is with a fully aligned detector, which can be expected in the long term. So, eventually, if we need to reduce rate further, rather than cut into pT spectra, I'd recommend tighter cuts on vertex chisq. cheers, Steve

  • Alessandro Bertolin resolved all threads

    resolved all threads

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