Identify the MC required for Ghost

yipengsun commented 2 years ago

In the end, we'll use 12875420 as our run 2 ghost sample.

DecFiles

Run 1

27163070: https://gitlab.cern.ch/lhcb-datapkg/Gen/DecFiles/-/blob/tags/v27r80/dkfiles/Dst_D0pi,Kpi=TightCut,FromB.dec

Run 2

11774004: https://gitlab.cern.ch/lhcb-datapkg/Gen/DecFiles/-/blob/v31r9/dkfiles/Bd_DstX,cocktail,D0pi,Kpi=TightCut.dec
12365401: https://gitlab.cern.ch/lhcb-datapkg/Gen/DecFiles/-/blob/v31r9/dkfiles/Bu_DstX,cocktail,D0pi,Kpi=TightCut.dec
The 27163070 is the other secondary. It doesn't exist on DIRAC.

From Greg:

11876063 (Bd_D0Xmunu,D0=cocktail,LHCbAcceptance)
12875420 (Bu_D0Xmunu,D0=cocktail,LHCbAcceptance)

yipengsun commented 2 years ago

Zishuo used inclusive J/psi MC sample for ghost. We should use something similar, like inclusive D/D*.

yipengsun commented 2 years ago

We can use this link: http://lhcbdoc.web.cern.ch/lhcbdoc/decfiles/releases/v31r9/table_evttype.php

And search for incl_D.

yipengsun commented 2 years ago

We should use the same misID data control sample reconstruction.

Currently it contains loose PID cuts. It's probably a good idea to remove them.

yipengsun commented 2 years ago

We need a D*+ inclusive MC, and the only available one seems to be this: https://gitlab.cern.ch/lhcb-datapkg/Gen/DecFiles/-/blob/v31r9/dkfiles/incl_Dstplus_D0ToAllExceptK3pi.dec

The MC ID is: 27260200

yipengsun commented 2 years ago

Well, can't find it on DIRAC. That's a bummer.

yipengsun commented 2 years ago

There's 27163970 and 27163971, both are D* 3pi decays (and the MCs are sim09e-ReDecay), so I don't think we can use either of these.

I looked into RD+'s ANA, chapter 6. They only mentioned that a simulation sample is used, without a concrete MC ID.

yipengsun commented 2 years ago

For RDX run 1, it was 27163070 (Dst_D0pi,Kpi=TightCut,FromB), which has been superseded by 12365401. The newer one is filtered on the prompt D2Kpi trigger so might not represent kinematic consistently w/ our decay mode.

Still, it might be the best available. There's a equivalent version for B0:

We might need to pick one of them.

yipengsun commented 2 years ago

We should produce ntuples for all 3 of them (1 for run 1, 2 for run 2), and do the following test:

hecking P/Pt (or P/eta) coverage in the lab and then comparing B-frame momentum distributions of ghosts for the Run1 and Run2 samples

I think here we should require ghost to have a TRUE PID of 0.

yipengsun commented 2 years ago

When trying to download sample .DST files for 2012 ghost sample, I got the following error:

Got 3 LFNs
Downloading 3 files to .
Failed :
    /lhcb/MC/2012/PROMPTD2KPI.STRIPTRIG.DST/00045827/0000/00045827_00000005_1.promptd2kpi.striptrig.dst : Connection timed out ( 110 : Could not copy srm://storm-fe-lhcb.cr.cnaf.infn.it:8444/srm/managerv2?SFN=/tape/lhcb/archive/lhcb/MC/2012/PROMPTD2KPI.STRIPTRIG.DST/00045827/0000/00045827_00000005_1.promptd2kpi.striptrig.dst to file:///eos/home-s/suny/raw_data/Dst_D0Pi_FromB-2012-md-py8-sim08h/00045827_00000005_1.promptd2kpi.striptrig.dst, [110] SOURCE SRM_GET_TURL srm-ifce err: Connection timed out, err: [SE][StatusOfGetRequest][ETIMEDOUT] httpg://storm-fe-lhcb.cr.cnaf.infn.it:8444/srm/managerv2: User timeout over
                                                                                                          )
    /lhcb/MC/2012/PROMPTD2KPI.STRIPTRIG.DST/00045827/0000/00045827_00000006_1.promptd2kpi.striptrig.dst : Connection timed out ( 110 : Could not copy srm://tape-sdrm.t1.grid.kiae.ru:8443/srm/managerv2?SFN=/t1.grid.kiae.ru/data/lhcb/lhcbtape/lhcb/MC/2012/PROMPTD2KPI.STRIPTRIG.DST/00045827/0000/00045827_00000006_1.promptd2kpi.striptrig.dst to file:///eos/home-s/suny/raw_data/Dst_D0Pi_FromB-2012-md-py8-sim08h/00045827_00000006_1.promptd2kpi.striptrig.dst, [110] SOURCE SRM_GET_TURL srm-ifce err: Connection timed out, err: [SE][StatusOfGetRequest][ETIMEDOUT] httpg://tape-sdrm.t1.grid.kiae.ru:8443/srm/managerv2: User timeout over
                                                                                                          )
    /lhcb/MC/2012/PROMPTD2KPI.STRIPTRIG.DST/00045827/0000/00045827_00000007_1.promptd2kpi.striptrig.dst : No accessible replicas found

yipengsun commented 2 years ago

I tried to download all files for run 1 ghost MC. 1/18 is available. Everything else is either unavailable or has a file size of 512 Byte (broken?).

yipengsun commented 2 years ago

For run 2, the ghost candidate MCs are MicroDST. Learning on how to use them.

Here's a ref: https://indico.cern.ch/event/159520/contributions/1410656/subcontributions/128357/attachments/181571/255244/20120427_MicroDST.pdf

yipengsun commented 2 years ago

I was able to reco events from both MC samples recommended by Greg.

Note that neither is filtered so we can't use stripping line. Currently I'm reco'ing them just like any MC (no stripping, no PID cut).

Questions:

Is the normal reconstruction sufficient for ghost sample (I think so, but I'd like to confirm that w/ Greg)
The 11876060 sample is marked as "LHCb Acceptance buggy". Should we use the 12875420 sample only?

yipengsun commented 2 years ago

Job submitted. The GRID progress will be tracked in #95.

yipengsun commented 2 years ago

We need to have a better understanding on why certain MC is better than the others.

yipengsun commented 2 years ago

In the Muon reconstruction, there's a Ghost probability cut:

algo_Bminus.DaughtersCuts = {
    'mu-': '(MIPCHI2DV(PRIMARY) > 16.0) & (TRGHOSTPROB < 0.5) &'
           '(P > 3.0*GeV)'  # NOTE: Mu PID is added later
}

So, I think all old MC samples are not suitable for Ghost study, simply because we've removed most of Ghosts explicitly.

To confirm my claim, I looked at 11574021 FS MC:

tree->GetEntries("mu_TRUEID == 0")

And there's 0 entry.

EDIT: There's also a MC truth requirement, so for normal MC, there will be NO ghost. The ghost condition is added by me after the GRID production.

if DaVinci().Simulation and not has_flag('GHOST'):
    algo_Bminus.Preambulo += algo_mc_match_preambulo
    algo_Bminus.DaughtersCuts['mu-'] = \
        "(mcMatch('[^mu+]CC')) &" + algo_Bminus.DaughtersCuts['mu-']

yipengsun commented 2 years ago

Previous post indicates that there's NO true ghost for existing MC ntuples.

Revisiting Greg's suggested MC 12875420, with GhostProb cut and Muon truth matching removed:

old: 142, true ghost: 0
new (tree->GetEntries("mu_TRUEID == 0): 344, true ghost: 28
new (tree->GetEntries("mu_TRUEID == 0 && mu_TRACK_GhostProb < 0.5")): 344, true ghost: 28

Total number of input events: 7515

The generated ntuple has a size of 1.5 MB. So, if we have 1M events, the output size is expected to be 200 MB, and we'll have ~3700 true ghost, which is probably not enough.

FYI @Svende @manuelfs

manuelfs commented 2 years ago

The probability of tagging a ghost as a given species could depend on the GhostProb, right? If so, we'd need the cut.

Does Zishuo apply that cut? What are his stats (initial events, and events after reco)?

yipengsun commented 2 years ago

The probability of tagging a ghost as a given species could depend on the GhostProb, right? If so, we'd need the cut.

Does Zishuo apply that cut? What are his stats (initial events, and events after reco)?

You are right. But we can always apply that cut offline. In that case we'll have even less events for sure.

I haven't asked Zishuo about this. I checked his true ghost histograms, and the number of entries is 2,279,991. I don't know number of events in the input DST files.

yipengsun commented 2 years ago

EDIT: There's also a MC truth requirement, so for normal MC, there will be NO ghost. The ghost condition is added by me after the GRID production.
if DaVinci().Simulation and not has_flag('GHOST'):
    algo_Bminus.Preambulo += algo_mc_match_preambulo
    algo_Bminus.DaughtersCuts['mu-'] = \
        "(mcMatch('[^mu+]CC')) &" + algo_Bminus.DaughtersCuts['mu-']

Updated the post to show that there's also a MC truth requirement so all OLD MC ntuples will NOT containing ghost.

The not has_flag('GHOST') condition was added this past weekend, so the GRID production of the MC ghost candidate (~170MB) doesn't contain ghost either.

I can do a reproduction, but for me it looks that we'll not be having enough stat to do the efficiency study on this sample.

Maybe I should reproduce the FullSim normalization sample, w/o either DaVinci-level GhostProb cut nor MC truth matching, and see if the efficiencies are compatible between this and Zishuo's (when applying the same tagging cuts).

yipengsun commented 2 years ago

Updated the yield numbers. Turns out the GhostProb < 0.5 is not very useful. The previous ntuples don't have any ghost mainly because of the truth-matching requirement.

Svende commented 2 years ago

I looked more into those dec files listed above (https://github.com/umd-lhcb/lhcb-ntuples-gen/issues/111#issue-1165573626) and I will add more info to it:

In the end, we'll use 12875420 as our run 2 ghost sample.

DecFiles

Run 1

27163070: https://gitlab.cern.ch/lhcb-datapkg/Gen/DecFiles/-/blob/tags/v27r80/dkfiles/Dst_D0pi,Kpi=TightCut,FromB.dec

This dec file is an inclusive $D^{+}\to D^0(\to K^-\pi^+) \pi^+$ cocktail where the D0 is coming from an B. The kaon and pion have to fullfil the cuts: `( GPT > 220 MeV ) & ( GP > 3.0 GeV )and the D0:( GPT > 0.9 GeV )`, those cuts are in agreement with our generator level or trigger cuts. No events are produced in Run2 for this dec file.

Run 2

11774004: https://gitlab.cern.ch/lhcb-datapkg/Gen/DecFiles/-/blob/v31r9/dkfiles/Bd_DstX,cocktail,D0pi,Kpi=TightCut.dec

This is a $B^0 \to D^{*+}X$ with $D^{+}\to D^0(\to K^-\pi^+) \pi^+$ cocktail, including not only semileptonic but also multi-hadron final states. The following cuts are applied: `goodSlowPion = ( GPT > 190 MeV ) & ( GP > 0.97 GeV ) & inAcc Kaon, pion = ( GPT > 775 MeV ) & ( GP > 4.85 GeV ) goodD0 = inAcc & ( GPT > 1.94 GeV ) ` We don't apply any cuts on the slow pion (did we ever look into this?) and also the $p_T$ cuts on the kaon & pion are tighter wrt. our loose trigger (stripping) cuts of 200(300) MeV. But from Alex Run2 optimization study summarized here: https://github.com/umd-lhcb/group-talks/blob/42437231ccfb59f1ce21bc968739c6bb920105b3/rdx/22-04-27_alex_run2_cut_opt.pdf it doesn't look like we gain much anyways from loosing those cuts. Also there was a new dec file written here: https://gitlab.cern.ch/lhcb-datapkg/Gen/DecFiles/-/blob/v30r73/dkfiles/Bd_DstX,cocktail,D0pi,Kpi=DecProdCut.dec which is the same as above without the tight generator level cuts. We should check if there are any events produced for this one.

12365401: https://gitlab.cern.ch/lhcb-datapkg/Gen/DecFiles/-/blob/v31r9/dkfiles/Bu_DstX,cocktail,D0pi,Kpi=TightCut.dec

Same as the previous dec file only with $B+$ now. Only MDST available and filtered on the prompt D2HH trigger. IF the slow pion cuts and tighter kaon & pion cuts are fine for us, those two would be the most similar as what was done in Run1 and we could request. unfiltered DST samples for those.

From Greg:

11876063 (Bd_D0Xmunu,D0=cocktail,LHCbAcceptance)

The previous event type 11876060 (Bd_D0Xmunu,D0=cocktail,LHCbAcceptance_buggy can be found here: 11876060 (Bd_D0Xmunu,D0=cocktail,LHCbAcceptance_buggy. It is marked as buggy due to wrong particle in the non-resonant decay and the corrected event type should be 11876063. Although this shouldn't matter much for us we should check if events were produced with the latter. Also this event type only contains $B^0\to D*$ or higher excited D** semileptonic decays and NOT other multi-hadron final states as used in Run 1.

12875420 (Bu_D0Xmunu,D0=cocktail,LHCbAcceptance)

Same as above, but no wrong non-resonant decay in this file. ~1M per event type available in Run2, probably much too small for our needs (IIRC Zishuo has 10M of incJpsi which doesn't even require the Jpsi coming from a B-decay(https://gitlab.cern.ch/lhcb-datapkg/Gen/DecFiles/-/blob/v30r73/dkfiles/incl_Jpsi,mm=DecProdCut.dec))

yipengsun commented 2 years ago

Looking at 11574021: For a single polarity, we have 1269016 reconstructed events in the ntuple. Now, for a locally produced samples with 65088 events, we have 5203 true ghosts.

Therefore, for the 11574021 mode:

$$ 1269016 \times 2 \times \frac{5203}{65088} \approx 202885 $$

true ghosts. It's a fraction of 0.1 compared to Zishuo's, but I think it is enough to give us meaningful stats.

yipengsun commented 2 years ago

Submitted 11574021 to the GRID with ghost production mode.

yipengsun commented 2 years ago

I generated true ghost to tagged species efficiencies from both our D0Mu MC and Zishuo's incl. J/psi MC.

Note that the efficiencies don't include UBDT, as ZIshuo's MC lacks required branches to add UBDT.

I then compared the bin-by-bin efficiencies between two histograms, with the following considerations:

If the absolute difference is > 5%, the bin is considered bad
A $\chi^2$ is computed, based on the formula: $\frac{(eff{us} - eff{Zishuo})^2}{\sigma^2{us} + \sigma^2{Zishuo}}$.

  chi2 = 212.7663413917214, ndof = 24, chi2ndof = 8.865264224655059
  These are the worst 0 bins: (bin idx, abs. diff, RDX. val, RJpsi val)
Comparing gTrueToKTag...
  chi2 = 261.81824160876295, ndof = 24, chi2ndof = 10.909093400365123
  These are the worst 0 bins: (bin idx, abs. diff, RDX. val, RJpsi val)
Comparing gTrueToPTag...
  chi2 = 187.63664601815066, ndof = 24, chi2ndof = 7.81819358408961
  These are the worst 0 bins: (bin idx, abs. diff, RDX. val, RJpsi val)
Comparing gTrueToETag...
  chi2 = 261.16429055614077, ndof = 24, chi2ndof = 10.881845439839198
  These are the worst 0 bins: (bin idx, abs. diff, RDX. val, RJpsi val)
Comparing gTrueToGTag...
  chi2 = 16621.759039622902, ndof = 24, chi2ndof = 692.5732933176209
  These are the worst 24 bins: (bin idx, abs. diff, RDX. val, RJpsi val)
    (4, 1, 1)   0.25775886721245317 0.5991902834008097  0.34143141618835654
    (5, 1, 1)   0.24973079873936893 0.6293103448275862  0.37957954608821726
    (1, 1, 1)   0.23144457138668806 0.6271908722248952  0.39574630083820717
    (2, 1, 1)   0.22894078205501317 0.6196392785571142  0.39069849650210103
    (3, 1, 1)   0.2271891019899298  0.5610162432319866  0.3338271412420568
    (1, 2, 1)   0.2071267022547597  0.6431094092717201  0.4359827070169604
    (2, 2, 1)   0.1903052666468929  0.6153695417877788  0.4250642751408859
    (6, 1, 1)   0.19022566924299006 0.6412213740458015  0.4509957048028114
    (3, 2, 1)   0.1850622405213888  0.5607666966157532  0.37570445609436437
    (6, 1, 2)   0.17162207789628398 0.6410256410256411  0.4694035631293571
    (6, 2, 1)   0.16988107797850055 0.5310274669379451  0.36114638895944456
    (4, 1, 2)   0.15702420858916383 0.5560109289617486  0.3989867203725848
    (5, 2, 1)   0.1487020795354395  0.506336405529954   0.35763432599451445
    (4, 2, 1)   0.14798791372593756 0.5122246918569408  0.3642367781310032
    (1, 1, 2)   0.1441949888387276  0.576784482097677   0.43258949325894935
    (5, 1, 2)   0.14268709223729747 0.5652173913043478  0.4225302990670503
    (3, 1, 2)   0.1381174368553561  0.5371428571428571  0.39902542028750104
    (1, 2, 2)   0.13628020374600863 0.5942747836918081  0.45799457994579945
    (2, 1, 2)   0.13019313687977224 0.5632157046038794  0.43302256772410713
    (6, 2, 2)   0.1269314916164429  0.5314009661835749  0.404469474567132
    (2, 2, 2)   0.11391676031481385 0.5673931524847361  0.45347639216992225
    (3, 2, 2)   0.11178662136642054 0.523952309559506   0.41216568819308547
    (5, 2, 2)   0.09395928767357736 0.48919288645690834 0.395233598783331
    (4, 2, 2)   0.08913458665655732 0.48997829694880635 0.400843710292249

Naively, the true ghost -> tagged NON ghost efficiencies are more or less compatible, whereas the true ghost -> tagged ghost disagrees on every single bin.

yipengsun commented 2 years ago

There's a bug in my computation of efficiencies. w/ that fixed:

Comparing gTrueToPiTag...
  chi2 = 1237.59799936526, ndof = 24, chi2ndof = 51.56658330688583
  These bins are requested: (bin idx, abs. diff, RDX. val, RJpsi val)
    (4, 1, 1)   0.04282056767721204 0.11914893617021277 0.1619695038474248
  These are the worst 4 bins: (bin idx, abs. diff, RDX. val, RJpsi val)
    (1, 1, 1)   0.06897226919157756 0.113022585295531   0.18199485448710856
    (2, 1, 1)   0.05795595959402475 0.1291759465478842  0.18713190614190894
    (3, 1, 1)   0.056859631850197795    0.13662456946039037 0.19348420131058816
    (1, 2, 1)   0.052911064667435864    0.03862369101047192 0.09153475567790778
Comparing gTrueToKTag...
  chi2 = 511.24290431324124, ndof = 24, chi2ndof = 21.301787679718384
  These bins are requested: (bin idx, abs. diff, RDX. val, RJpsi val)
    (4, 1, 1)   0.04499633889479822 0.02553191489361702 0.07052825378841523
  These are the worst 0 bins: (bin idx, abs. diff, RDX. val, RJpsi val)
Comparing gTrueToPTag...
  chi2 = 339.9631108593128, ndof = 24, chi2ndof = 14.165129619138034
  These bins are requested: (bin idx, abs. diff, RDX. val, RJpsi val)
    (4, 1, 1)   0.009991000410807138    0.05638297872340425 0.06637397913421139
  These are the worst 0 bins: (bin idx, abs. diff, RDX. val, RJpsi val)
Comparing gTrueToETag...
  chi2 = 290.41278541448247, ndof = 24, chi2ndof = 12.100532725603436
  These bins are requested: (bin idx, abs. diff, RDX. val, RJpsi val)
    (4, 1, 1)   0.0014216036343876713   0.011702127659574468    0.013123731293962139
  These are the worst 0 bins: (bin idx, abs. diff, RDX. val, RJpsi val)
Comparing gTrueToGTag...
  chi2 = 1662.2994879813753, ndof = 24, chi2ndof = 69.26247866589064
  These bins are requested: (bin idx, abs. diff, RDX. val, RJpsi val)
    (4, 1, 1)   0.09922951061720509 0.7872340425531915  0.6880045319359864
  These are the worst 7 bins: (bin idx, abs. diff, RDX. val, RJpsi val)
    (4, 1, 1)   0.09922951061720509 0.7872340425531915  0.6880045319359864
    (5, 1, 1)   0.09610246572523906 0.8410138248847926  0.7449113591595535
    (3, 1, 1)   0.0917167589032708  0.7732491389207807  0.6815323800175099
    (3, 2, 1)   0.07328576415228405 0.8444885441096879  0.7712027799574038
    (1, 1, 1)   0.064579044253809   0.8769822200864968  0.8124031758326878
    (3, 1, 2)   0.0628514408549653  0.8631772268135904  0.8003257859586251
    (2, 1, 1)   0.06005157139784634 0.8608017817371938  0.8007502103393475

Checking that total efficiencies add up to 1:

>>> 0.11914893617021277 + 0.02553191489361702 + 0.05638297872340425 + 0.011702127659574468 + 0.7872340425531915
1.0

yipengsun commented 2 years ago

Perhaps a better comparison is to check if the two efficiencies agree within their uncertainties:

Comparing gTrueToPiTag...
  chi2 = 1.24e+03, ndof = 24, chi2ndof = 51.6
  These bins are requested: (bin idx, abs. diff, RDX. val, RJpsi val)
    (4, 1, 1)   0.043   0.119±0.011 0.162±0.003
  These are the worst 17 bins: (bin idx, abs. diff, RDX. val, RJpsi val)
    (1, 1, 1)   0.069   0.113±0.003 0.182±0.001
    (2, 1, 1)   0.058   0.129±0.006 0.187±0.001
    (3, 1, 1)   0.057   0.137±0.009 0.193±0.002
    (1, 2, 1)   0.053   0.039±0.001 0.092±0.008
    (1, 1, 2)   0.047   0.080±0.003 0.127±0.001
    (4, 1, 1)   0.043   0.119±0.011 0.162±0.003
    (3, 1, 2)   0.038   0.084±0.009 0.121±0.002
    (5, 1, 1)   0.037   0.083±0.015 0.120±0.003
    (2, 2, 1)   0.034   0.069±0.002 0.103±0.001
    (1, 2, 2)   0.030   0.034±0.001 0.064±0.008
    (3, 2, 1)   0.024   0.110±0.003 0.134±0.001
    (2, 1, 2)   0.023   0.095±0.006 0.119±0.001
    (4, 1, 2)   0.018   0.088±0.015 0.106±0.002
    (2, 2, 2)   0.015   0.059±0.002 0.073±0.001
    (3, 2, 2)   0.013   0.097±0.003 0.109±0.001
    (5, 2, 1)   0.008   0.129±0.006 0.138±0.001
    (4, 2, 1)   0.008   0.134±0.004 0.142±0.001
Comparing gTrueToKTag...
  chi2 = 511, ndof = 24, chi2ndof = 21.3
  These bins are requested: (bin idx, abs. diff, RDX. val, RJpsi val)
    (4, 1, 1)   0.045   0.026±0.006 0.071±0.002
  These are the worst 10 bins: (bin idx, abs. diff, RDX. val, RJpsi val)
    (4, 1, 1)   0.045   0.026±0.006 0.071±0.002
    (5, 1, 1)   0.033   0.039±0.012 0.072±0.003
    (6, 2, 2)   0.032   0.020±0.010 0.052±0.003
    (3, 1, 1)   0.023   0.033±0.005 0.056±0.001
    (3, 1, 2)   0.021   0.014±0.004 0.035±0.001
    (3, 2, 1)   0.016   0.018±0.001 0.034±0.001
    (6, 2, 1)   0.014   0.058±0.010 0.071±0.002
    (3, 2, 2)   0.014   0.011±0.001 0.025±0.001
    (2, 2, 1)   0.005   0.001±0.000 0.006±0.000
    (2, 2, 2)   0.003   0.001±0.000 0.004±0.000
Comparing gTrueToPTag...
  chi2 = 340, ndof = 24, chi2ndof = 14.2
  These bins are requested: (bin idx, abs. diff, RDX. val, RJpsi val)
    (4, 1, 1)   0.010   0.056±0.009 0.066±0.002
  These are the worst 10 bins: (bin idx, abs. diff, RDX. val, RJpsi val)
    (5, 1, 1)   0.024   0.032±0.011 0.056±0.002
    (5, 1, 2)   0.022   0.019±0.015 0.041±0.003
    (4, 1, 2)   0.018   0.031±0.010 0.049±0.002
    (3, 2, 1)   0.015   0.010±0.001 0.026±0.001
    (3, 1, 1)   0.011   0.042±0.005 0.053±0.001
    (3, 2, 2)   0.010   0.008±0.001 0.018±0.000
    (5, 2, 1)   0.007   0.057±0.004 0.064±0.001
    (2, 2, 1)   0.002   0.000±0.000 0.002±0.000
    (2, 1, 1)   0.001   0.000±0.001 0.002±0.000
    (2, 2, 2)   0.001   0.000±0.000 0.001±0.000
Comparing gTrueToETag...
  chi2 = 290, ndof = 24, chi2ndof = 12.1
  These bins are requested: (bin idx, abs. diff, RDX. val, RJpsi val)
    (4, 1, 1)   0.001   0.012±0.005 0.013±0.001
  These are the worst 11 bins: (bin idx, abs. diff, RDX. val, RJpsi val)
    (3, 2, 1)   0.018   0.017±0.001 0.035±0.001
    (1, 2, 1)   0.014   0.020±0.001 0.006±0.003
    (3, 2, 2)   0.011   0.012±0.001 0.022±0.001
    (1, 2, 2)   0.008   0.012±0.001 0.003±0.002
    (4, 1, 2)   0.006   0.002±0.005 0.008±0.001
    (6, 2, 1)   0.005   0.000±0.003 0.005±0.001
    (4, 2, 1)   0.005   0.030±0.002 0.035±0.001
    (1, 1, 1)   0.004   0.010±0.001 0.006±0.000
    (2, 2, 1)   0.004   0.020±0.001 0.016±0.001
    (5, 2, 1)   0.003   0.014±0.002 0.017±0.000
    (1, 1, 2)   0.003   0.007±0.001 0.004±0.000
Comparing gTrueToGTag...
  chi2 = 1.66e+03, ndof = 24, chi2ndof = 69.3
  These bins are requested: (bin idx, abs. diff, RDX. val, RJpsi val)
    (4, 1, 1)   0.099   0.787±0.014 0.688±0.003
  These are the worst 19 bins: (bin idx, abs. diff, RDX. val, RJpsi val)
    (4, 1, 1)   0.099   0.787±0.014 0.688±0.003
    (5, 1, 1)   0.096   0.841±0.019 0.745±0.005
    (3, 1, 1)   0.092   0.773±0.010 0.682±0.002
    (3, 2, 1)   0.073   0.844±0.003 0.771±0.001
    (1, 1, 1)   0.065   0.877±0.003 0.812±0.001
    (3, 1, 2)   0.063   0.863±0.011 0.800±0.002
    (2, 1, 1)   0.060   0.861±0.006 0.801±0.001
    (3, 2, 2)   0.047   0.872±0.004 0.825±0.001
    (5, 1, 2)   0.047   0.879±0.027 0.832±0.005
    (1, 1, 2)   0.045   0.914±0.003 0.869±0.001
    (1, 2, 1)   0.039   0.941±0.001 0.902±0.008
    (6, 2, 1)   0.038   0.771±0.017 0.733±0.004
    (4, 1, 2)   0.037   0.837±0.018 0.800±0.003
    (2, 2, 1)   0.036   0.909±0.002 0.873±0.001
    (2, 1, 2)   0.026   0.899±0.006 0.873±0.001
    (1, 2, 2)   0.021   0.954±0.001 0.933±0.008
    (5, 2, 1)   0.020   0.751±0.007 0.731±0.002
    (2, 2, 2)   0.019   0.929±0.002 0.910±0.001
    (4, 2, 1)   0.012   0.762±0.005 0.750±0.001

yipengsun commented 2 years ago

I think at this point we really need to request some D* inclusive MC.

For now though let's use J/psi inclusive.

yipengsun commented 1 year ago

@manuelfs @hadjichris @afernez Just a reminder - the ghost MC sample should also be request.

afernez commented 1 year ago

I'll mention #125 so it shows up in the thread there and we don't forget!

hadjichris commented 1 year ago

@yipengsun can you confirm that we will eventually use 12875420 as our RUN2 ghost sample? Do we have an estimate of the statistics?

yipengsun commented 1 year ago

Looking at the .dec file:

# EventType: 12875420
#
# Descriptor: [[B-] ==> mu- anti-nu_mu (D*0 -> (D0 -> K- pi+ pi+ pi-) pi0)]cc
#
# NickName: Bu_D0Xmunu,D0=cocktail,LHCbAcceptance
#
# Cuts: LHCbAcceptance
#
# Documentation: Sum of B+ -> D0Xmunu modes with (D0 -> K- pi+) and (D0 -> K- pi+ pi+ pi-) final states, including D** and non resonant modes. D*pipi mode contained in D_10 channel.

I think this looks like the correct one (poor man's inclusive D0 MC with minimum cut).

yipengsun commented 1 year ago

I re-read the old discussions in this post. I think a $B \rightarrow D^{(*)} X$ cocktail would be better.

Maybe Svende's old post is useful? https://github.com/umd-lhcb/lhcb-ntuples-gen/issues/111#issuecomment-1135176293, where she mentioned that there's a new cocktail written for run 2: https://gitlab.cern.ch/lhcb-datapkg/Gen/DecFiles/-/blob/v30r73/dkfiles/Bd_DstX,cocktail,D0pi,Kpi=DecProdCut.dec

You probably should check if that cocktail has been produced.

In terms of stats, I was only doing naive estimation based on a normalization mode MC, and the numbers are listed in this post: https://github.com/umd-lhcb/lhcb-ntuples-gen/issues/111#issuecomment-1136415772

umd-lhcb / lhcb-ntuples-gen