Repository navigation
[PWGHF] [WIP] ML skimming for D0 and D* - #18196
Marcellocosti wants to merge 1 commit into
Conversation
Marcellocosti
changed the title
|
O2 linter results: ❌ 0 errors, |
github-actions
Bot
changed the title
fchinu
left a comment
fchinu
left a comment
There was a problem hiding this comment.
Ciao @Marcellocosti!
Thanks a lot for your implementation!
I have just a few suggestions, maybe the most important one would be the D0 duplication, for which I don't have an easy solution in mind at the moment
| Configurable<bool> do2Prongs{"do2Prongs", true, "store 2-prong candidates"}; | ||
| Configurable<bool> doDstar{"doDstar", true, "store D* candidates"}; |
There was a problem hiding this comment.
I would add also a do3Prongs configurable
| registry.add("hVtx2ProngZ", "2-prong candidates;#it{z}_{sec. vtx.} (cm);entries", {HistType::kTH1D, {{1000, -20., 20.}}}); | ||
| registry.add("hNCand2Prong", "2-prong candidates preselected;# of candidates;entries", {HistType::kTH1D, {axisNumCands}}); | ||
| registry.add("hNCand2ProngVsNTracks", "2-prong candidates preselected;# of selected tracks;# of candidates;entries", {HistType::kTH2D, {axisNumTracks, axisNumCands}}); | ||
| registry.add("hMassD0ToPiK", "D^{0} candidates;inv. mass (#pi K #pi) (GeV/#it{c}^{2});entries", {HistType::kTH1D, {{500, 0., 5.}}}); |
There was a problem hiding this comment.
| registry.add("hMassD0ToPiK", "D^{0} candidates;inv. mass (#pi K #pi) (GeV/#it{c}^{2});entries", {HistType::kTH1D, {{500, 0., 5.}}}); | |
| registry.add("hMassD0ToPiK", "D^{0} candidates;inv. mass (#pi K) (GeV/#it{c}^{2});entries", {HistType::kTH1D, {{500, 0., 5.}}}); |
| runCombinatorics(collision, cachePos, cacheNeg); | ||
| runCombinatorics(collision, cacheNeg, cachePos); |
There was a problem hiding this comment.
Did you check that for D0 you don't fill the table twice, once for prong0(+), prong1(-) and once for prong1(-), prong0(+)? I think this may happen if both prongs pass both pion and kaon selections
| Configurable<float> ptMinSoftPi{"ptMinSoftPi", 0.1f, "min. soft pion track pT entering the charm combinatorics"}; | ||
| Configurable<bool> enableTiming{"enableTiming", false, "fill hTiming with the CPU of the feature building and of each model evaluation (adds two clock reads per call)"}; | ||
| // D0 model | ||
| Configurable<bool> applyMlD0{"applyMlD0", true, "evaluate the D0 track model"}; |
There was a problem hiding this comment.
Maybe it would be better to set all the applyMl configurables to false by default, since we would try to fetch the models from the default CCDB paths and tests would fail. Could you do it also for Ds and D+ please?
| int lastFilledD0 = rowTrackIndexProng2.lastIndex(); | ||
| // optional 2-track vertex to skip the pair early | ||
| if (useTwoTrackVertex) { | ||
| if (useTwoTrackVertex || config.do2Prongs || config.doDstar) { |
There was a problem hiding this comment.
Maybe I would separate the two conditions, since for three prongs we would reject "bad" two prong vertices even if the configurable is not set but do2Prongs or doDstar are
| } | ||
|
|
||
| // fill table row | ||
| rowTrackIndexProng2(collision.globalIndex(), prong0.globalIndex, prong1.globalIndex, hfFlagOfSelection(isSelected2ProngCand, false)); |
There was a problem hiding this comment.
TISC fills always with prong0 being the positive daughter and prong1 being the negative one. It seems to me that the selector of D0 exploits this convention, maybe it could be worth using it here as well
2 participants
Extends the ML-based skimming task to D0 and D*. Drafting because the implementation is almost finalized but I am performing more tests locally on CPU usage and candidate efficiency.
Tagging @fchinu, @fgrosa, @zhangbiao-phy, @apalasci