Draft: B2OC: Reduce rate of Xib2Dph lines

Reduce rate of Xib2Dph lines:

• XibmToDmPK_DmToHHH
• XibmToDmPPi_DmToHHH
• XibmToDsmPK_DsmToHHH
• XibmToDsmPPi_DsmToHHH
• XibmToDstmPK_DstmToD0Pi_D0ToHH
• XibmToDstmPPi_DstmToD0Pi_D0ToHH

Stop using all HH or HHH decays and use only CF decays, i.e.

$D^+ \to K^- \pi^+ \pi^+$

,

$D_s^+ \to K^+ K^- \pi^+$

,

$D^0 \to K^- \pi^+$

.

Tighten the PID on all tracks, including adding a (PIDK - PIDp) cut to protons.

cc: @mwhitehe

added B2OC label

requested review from @abertoli and @shunan

added 2 commits

• 1152f548 - Add (PIDK - PIDp) cut to protons
• 85cf9795 - Further tightening of PID cuts to ensure mutual exclusivity between the lines

Compare with previous version

requested review from @bshi

@tlatham cc @mwhitehe:

• the lines you are acting on here are also listed in the B2OC section of this document, am I right ? all of them ?
• can you attach the .log file you got running the code locally ?

The top 4 lines in the description are in the document you listed, yes

Hi @abertoli, yes 4 of the lines are listed there (line numbers 45, 48, 67 and 96). The other two (the Dstar lines) are Hlt2 lines and don't feature there but also have been reported to have rather high rates (although much lower bandwidth).

I am currently running local tests, including only these 6 lines (both in this branch and in b2oc-2025-dev for comparison). Will post logs when I have them.

point taken @tlatham, I am about to send an e-mail where I will ask line proponents to act on the spruce lines of the table they are responsible for

I will mention you are already doing it

Here are the LAZY_AND lines from the logs. I'm running the b2oc_hlt2_example.py modified to only load the 6 lines under consideration here and to run over 100k events.

Firstly, the results running in the b2oc-2025-dev branch:

LAZY_AND: moore                                                                 #=100000  Sum=115         Eff=|(0.1150000 +- 0.0107176)%|
   LAZY_AND: Hlt2B2OC_XibmToDmPK_DmToHHHDecisionWithOutput                      #=100000  Sum=41          Eff=|(0.04100000 +- 0.00640181)%|
    LAZY_AND: Hlt2B2OC_XibmToDmPK_DmToHHH                                       #=100000  Sum=41          Eff=|(0.04100000 +- 0.00640181)%|
   LAZY_AND: Hlt2B2OC_XibmToDmPPi_DmToHHHDecisionWithOutput                     #=100000  Sum=42          Eff=|(0.04200000 +- 0.00647938)%|
    LAZY_AND: Hlt2B2OC_XibmToDmPPi_DmToHHH                                      #=100000  Sum=42          Eff=|(0.04200000 +- 0.00647938)%|
   LAZY_AND: Hlt2B2OC_XibmToDsmPK_DsmToHHHDecisionWithOutput                    #=100000  Sum=38          Eff=|(0.03800000 +- 0.00616324)%|
    LAZY_AND: Hlt2B2OC_XibmToDsmPK_DsmToHHH                                     #=100000  Sum=38          Eff=|(0.03800000 +- 0.00616324)%|
   LAZY_AND: Hlt2B2OC_XibmToDsmPPi_DsmToHHHDecisionWithOutput                   #=100000  Sum=40          Eff=|(0.04000000 +- 0.00632329)%|
    LAZY_AND: Hlt2B2OC_XibmToDsmPPi_DsmToHHH                                    #=100000  Sum=40          Eff=|(0.04000000 +- 0.00632329)%|
   LAZY_AND: Hlt2B2OC_XibmToDstmPK_DstmToD0Pi_D0ToHHDecisionWithOutput          #=100000  Sum=21          Eff=|(0.02100000 +- 0.00458209)%|
    LAZY_AND: Hlt2B2OC_XibmToDstmPK_DstmToD0Pi_D0ToHH                           #=100000  Sum=21          Eff=|(0.02100000 +- 0.00458209)%|
   LAZY_AND: Hlt2B2OC_XibmToDstmPPi_DstmToD0Pi_D0ToHHDecisionWithOutput         #=100000  Sum=27          Eff=|(0.02700000 +- 0.00519545)%|
    LAZY_AND: Hlt2B2OC_XibmToDstmPPi_DstmToD0Pi_D0ToHH                          #=100000  Sum=27          Eff=|(0.02700000 +- 0.00519545)%|
  LAZY_AND: monitor_decisions                                                   #=100000  Sum=0           Eff=|( 0.000000 +- 0.00000 )%|
  LAZY_AND: b2oc_writer                                                         #=115     Sum=115         Eff=|( 100.0000 +- 0.00000 )%|

Then the results after applying the changes in this MR:

LAZY_AND: moore                                                                 #=100000  Sum=10          Eff=|(0.01000000 +- 0.00316212)%|
   LAZY_AND: Hlt2B2OC_XibmToDmPK_DmToHHHDecisionWithOutput                      #=100000  Sum=1           Eff=|(0.001000000 +- 0.000999995)%|
    LAZY_AND: Hlt2B2OC_XibmToDmPK_DmToHHH                                       #=100000  Sum=1           Eff=|(0.001000000 +- 0.000999995)%|
   LAZY_AND: Hlt2B2OC_XibmToDmPPi_DmToHHHDecisionWithOutput                     #=100000  Sum=1           Eff=|(0.001000000 +- 0.000999995)%|
    LAZY_AND: Hlt2B2OC_XibmToDmPPi_DmToHHH                                      #=100000  Sum=1           Eff=|(0.001000000 +- 0.000999995)%|
   LAZY_AND: Hlt2B2OC_XibmToDsmPK_DsmToHHHDecisionWithOutput                    #=100000  Sum=3           Eff=|(0.003000000 +- 0.00173202)%|
    LAZY_AND: Hlt2B2OC_XibmToDsmPK_DsmToHHH                                     #=100000  Sum=3           Eff=|(0.003000000 +- 0.00173202)%|
   LAZY_AND: Hlt2B2OC_XibmToDsmPPi_DsmToHHHDecisionWithOutput                   #=100000  Sum=0           Eff=|( 0.000000 +- 0.00000 )%|
    LAZY_AND: Hlt2B2OC_XibmToDsmPPi_DsmToHHH                                    #=100000  Sum=0           Eff=|( 0.000000 +- 0.00000 )%|
   LAZY_AND: Hlt2B2OC_XibmToDstmPK_DstmToD0Pi_D0ToHHDecisionWithOutput          #=100000  Sum=3           Eff=|(0.003000000 +- 0.00173202)%|
    LAZY_AND: Hlt2B2OC_XibmToDstmPK_DstmToD0Pi_D0ToHH                           #=100000  Sum=3           Eff=|(0.003000000 +- 0.00173202)%|
   LAZY_AND: Hlt2B2OC_XibmToDstmPPi_DstmToD0Pi_D0ToHHDecisionWithOutput         #=100000  Sum=4           Eff=|(0.004000000 +- 0.00199996)%|
    LAZY_AND: Hlt2B2OC_XibmToDstmPPi_DstmToD0Pi_D0ToHH                          #=100000  Sum=4           Eff=|(0.004000000 +- 0.00199996)%|
  LAZY_AND: monitor_decisions                                                   #=100000  Sum=0           Eff=|( 0.000000 +- 0.00000 )%|
  LAZY_AND: b2oc_writer                                                         #=10      Sum=10          Eff=|( 100.0000 +- 0.00000 )%|

As you can see, it results in a substantial reduction in rate. Given the nature of the changes in the PID cuts, I believe this will also result in a considerable reduction in the number of candidates, further reducing the bandwidth.

What's the best way to actually measure the bandwidth these days? Do we run this through a CI test?

@tlatham cc @mwhitehe @bshi sorry but I am missing if here you are taking care or planning to take care also of some of the spruce lines I reported in the following b2oc issue #938

or here you prefer to address only hlt2 lines ?

once I know that I will tell you about the CI test

Yes, four of the lines here are the spruce lines that you mention. The other two are Hlt2 lines. I just ran all of them through the b2oc_hlt2_example script to get an idea of the rate reduction, which is why they appear to be HLT2 lines in the snippet of the log posted above.

so @tlatham cc @bshi @shunan can we say we are ready here ? in that case we will give a look to the code and then merge it

Yes I think so - many thanks

mentioned in issue #938

hello @bshi, this is for Monday morning when you will be in your office

here I see changes in basic_buildres.py and bbaryon_to_lightbaryon_dh.py

the changes in bbaryon_to_lightbaryon_dh.py can not impact other lines and I do not see anything problematic with them if the retention goes down

the changes in basic_buildres.py could potentially affect other lines using protons but as the default value of the newly added agrument is p_pidkmp_max=None this can not happy, the proponent is just changing his lines not affecting other lines

if we agree on the last point and if you do not have other issues with this code please merge it !

approved this merge request

@bshi I am keeping Draft: just to avoid potential issues with the shifter, just remove it yourself please

@tlatham cc @abertoli @bshi Personally I would prefer also changing the line names for clarification, e.g. XibmToDmPK_DmToHHH -> XibmToDmPK_DmToKpPimPim, but I do understand that using consistent line names throughout Run 3 is much more convenient for analysts and operation. I leave the decision to the proponent.

@shunan, indeed I wondered about this but decided that consistency of naming throughout Run 3 seemed more important. So would prefer to keep it like this unless anyone objects strongly.