Repository navigation
[PWGCF,PWGHF] Split kaon DCA secondary templates into HF and LF - #18481
Merged
Merged
Conversation
Follow RecoDecay::getParticleOrigin with its default arguments and classify nonzero origins as HF, as suggested by Fabrizio. Remove the custom PDG and ancestry helpers without changing the remaining origin routing. Co-authored-by: Fabrizio Grosa <[email protected]>
FDUEnrich
requested review from
NicoleBastid,
alibuild,
deepathoms,
fcatalan92,
fcolamar,
fgrosa,
hahassan7,
jpxrk,
mfaggin,
mmazzilli and
vkucera
as code owners
October 27, 2026 18:23
FDUEnrich
requested review from
apalasciano,
ariedel-cern,
dimihayl,
dsarkaralice,
gluparel,
lauraser,
singhra1994,
stefanopolitano,
victor-gonzalez,
xinyepeng and
zhangbiao-phy
as code owners
October 27, 2026 18:23
|
O2 linter results: ❌ 0 errors, |
xinyepeng
previously approved these changes
Oct 28, 2026
xinyepeng
enabled auto-merge (squash)
October 28, 2026 00:46
lauraser
reviewed
Oct 30, 2026
|
|
||
| /// Classify true kaons from the correct collision for the DCA templates. | ||
| template <typename T> | ||
| inline int getKaonOrigin(T const& particles, typename T::iterator const& particle) |
Collaborator
There was a problem hiding this comment.
This function is used only y HF. Would it be possible to move this template to the HF charm producer instead of implementing it here?
Collaborator
There was a problem hiding this comment.
Hi @lauraser it is fine to move it to the HF producer, but you should consider to use it also for other analyses, as the fraction of kaons from HF decays is about 5% so not totally negligible, and in other femto analyses they were always considered primaries, but they are not (as they are produced micrometers away from the interaction point)
Contributor
Author
There was a problem hiding this comment.
Hi, Laura. I've modified according to your request. Could you please have a look?
Collaborator
There was a problem hiding this comment.
Hi, thanks a lot for the explanation @fgrosa ! I would like to ask @FDUEnrich to present this in more detail in femto PAG when possible, and then we could discuss the implications for other analyses as well. Thanks a lot!
lauraser
requested changes
Oct 30, 2026
auto-merge was automatically disabled
November 2, 2026 10:57
Head branch was pushed to by a user without write access
lauraser
enabled auto-merge (squash)
November 2, 2026 12:53
lauraser
approved these changes
Nov 2, 2026
fgrosa
approved these changes
Nov 2, 2026
fgrosa
disabled auto-merge
November 2, 2026 15:04
Alascraker
pushed a commit
to Alascraker/O2Physics
that referenced
this pull request
Nov 2, 2026
- reuse RecoDecay::getParticleOrigin (as done in AliceO2Group#18481) instead of an ad-hoc first-digit PDG scan, so the V0 origin is filled with kPrimary, kMaterial, kSecondaryFromHF and kSecondaryFromLF - the phi chain (phi -> K0/K0bar -> K0s) is light-flavour feed-down and is filled as kSecondaryFromLF - add RecoDecay::isDiquark and skip diquark states in RecoDecay::getParticleOrigin: their PDG codes (4101, 4201, 5101, ...) satisfy pdg / 1000 == 4 or 5 and would otherwise be taken as charm/beauty baryons - use o2::constants::physics::Pdg::kPhi and kK0 instead of literal PDG codes
Alascraker
pushed a commit
to Alascraker/O2Physics
that referenced
this pull request
Nov 2, 2026
- reuse RecoDecay::getParticleOrigin (as done in AliceO2Group#18481) instead of an ad-hoc first-digit PDG scan, so the V0 origin is filled with kPrimary, kMaterial, kSecondaryFromHF and kSecondaryFromLF - add kSecondaryFromPhi: the phi chain (phi -> K0/K0bar -> K0s) is light-flavour feed-down, but it is kept as a separate class because the relatively long phi lifetime makes it a distinct source that should not be mixed with other light-flavour feed-down - add RecoDecay::isDiquark and skip diquark states in RecoDecay::getParticleOrigin: their PDG codes (4101, 4201, 5101, ...) satisfy pdg / 1000 == 4 or 5 and would otherwise be taken as charm/beauty baryons - use o2::constants::physics::Pdg::kPhi and kK0 instead of literal PDG codes
Alascraker
pushed a commit
to Alascraker/O2Physics
that referenced
this pull request
Nov 2, 2026
- reuse RecoDecay::getParticleOrigin (as done in AliceO2Group#18481) instead of an ad-hoc first-digit PDG scan, so the V0 origin is filled with kPrimary, kMaterial, kSecondaryFromHF and kSecondaryFromLF - add kSecondaryFromPhi: the phi chain (phi -> K0/K0bar -> K0s) is light-flavour feed-down, but it is kept as a separate class because the relatively long phi lifetime makes it a distinct source that should not be mixed with other light-flavour feed-down - add RecoDecay::isDiquark and skip diquark states in RecoDecay::getParticleOrigin: their PDG codes (4101, 4201, 5101, ...) satisfy pdg / 1000 == 4 or 5 and would otherwise be taken as charm/beauty baryons - use o2::constants::physics::Pdg::kPhi and kK0 instead of literal PDG codes
Alascraker
pushed a commit
to Alascraker/O2Physics
that referenced
this pull request
Nov 3, 2026
- reuse RecoDecay::getParticleOrigin (as done in AliceO2Group#18481) instead of an ad-hoc first-digit PDG scan, so the V0 origin is filled with kPrimary, kMaterial, kSecondaryFromHF, kSecondaryFromLF and kSecondaryFromPhi - add kSecondaryFromPhi: the phi chain (phi -> K0/K0bar -> K0s) is light-flavour feed-down, but it is kept as a separate class because the relatively long phi lifetime makes it a distinct source - RecoDecay::getParticleOrigin now stops the mother walk (break) as soon as a parton or a diquark is reached: no heavy-flavour hadron can be found above the partonic level, and diquark PDG codes (4101, 4201, 5101, ...) satisfy pdg / 1000 == 4 or 5 and were otherwise misidentified as charm/beauty baryons (RecoDecay::isDiquark is added for that); the parton stop follows the !searchUpToQuark idiom of getMother() so that the search-up-to-quark mode still reaches the charm and beauty quarks - use o2::constants::physics::Pdg::kPhi and kK0 instead of literal PDG codes
Alascraker
pushed a commit
to Alascraker/O2Physics
that referenced
this pull request
Nov 3, 2026
- reuse RecoDecay::getParticleOrigin (as done in AliceO2Group#18481) instead of an ad-hoc first-digit PDG scan, so the V0 origin is filled with kPrimary, kMaterial, kSecondaryFromHF, kSecondaryFromLF and kSecondaryFromPhi - add kSecondaryFromPhi: the phi chain (phi -> K0/K0bar -> K0s) is light-flavour feed-down, but it is kept as a separate class because the relatively long phi lifetime makes it a distinct source - RecoDecay::getParticleOrigin now stops the mother walk (break) as soon as a parton or a diquark is reached: no heavy-flavour hadron can be found above the partonic level, and diquark PDG codes (4101, 4201, 5101, ...) satisfy pdg / 1000 == 4 or 5 and were otherwise misidentified as charm/beauty baryons; the parton stop follows the !searchUpToQuark idiom of getMother() so that the search-up-to-quark mode still reaches the charm and beauty quarks - add RecoDecay::isDiquark() and PdgDiquarkSpin0Code/PdgDiquarkSpin1Code, built from the existing PDG constants and divisors (no literal PDG codes) - use o2::constants::physics::Pdg::kPhi and kK0 instead of literal PDG codes
Alascraker
pushed a commit
to Alascraker/O2Physics
that referenced
this pull request
Nov 3, 2026
- reuse RecoDecay::getParticleOrigin (as done in AliceO2Group#18481) instead of an ad-hoc first-digit PDG scan, so the V0 origin is filled with kPrimary, kMaterial, kSecondaryFromHF, kSecondaryFromLF and kSecondaryFromPhi - add kSecondaryFromPhi: the phi chain (phi -> K0/K0bar -> K0s) is light-flavour feed-down, but it is kept as a separate class because the relatively long phi lifetime makes it a distinct source - RecoDecay::getParticleOrigin now stops the mother walk (break) in the hadron-level mode as soon as a parton or a diquark is reached: no heavy-flavour hadron can be found above the partonic level, and diquark PDG codes (4101, 4201, 5101, ...) satisfy pdg / 1000 == 4 or 5 and were otherwise misidentified as charm/beauty baryons; in the parton-level mode (searchUpToQuark) the walk still goes through diquarks, since a charm or beauty quark can be found above them - add RecoDecay::isDiquark() and PdgDiquarkSpin0Code/PdgDiquarkSpin1Code, built from the existing PDG constants and divisors (no literal PDG codes) - use o2::constants::physics::Pdg::kPhi and kK0 instead of literal PDG codes
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Separate kaon MC DCAxy templates into HF and LF using
RecoDecay::getParticleOrigin. Include Omega contributions in LF; leave other particle classifications unchanged.