PWGHF: first checked implementation of Xic->pKpi filtering#5436
PWGHF: first checked implementation of Xic->pKpi filtering#5436jgrosseo merged 14 commits intoAliceO2Group:devfrom
Conversation
|
Linked PR in validation framework: AliceO2Group/Run3AnalysisValidation#158 |
6e806a2 to
7b95b03
Compare
7b95b03 to
652a5b5
Compare
|
@ginnocen @vkucera @DelloStritto few required fixes implemented |
|
@ginnocen switched to "ready for review" status |
|
@mfaggin @DelloStritto @ginnocen If I understand correctly, the only difference between the Lc and Xic selector should eventually be the configuration (including the mass cut) and the output flag column. |
IMHO, this should be avoided at this stage. My implementation of the Xic is indeed based on the Lc task, since we are talking about particles that are reconstructed in the same decay channel. However, being two different particles with different kinematics, I would not force them to be equal or strongly correlated for the moment, because for real analysis things may differentiate. I agre with you for methods like the one on the pKpi invariant mass calculations, but not for all methods. |
|
@mfaggin Is there any topological cut that could ever be applied only for Lc and not for Xic? |
|
@vkucera at this stage I do not see indeed, but I do not have such a long-time view to confirm it at 100%. I can try to have a look if such an operation would be too constraining or not, but I do not have too much time to dedicate on this business in a short time-scale. Do you think it's crucial for this PR to be approved? I may think to address this topic after this PR merging, so that something is already in place for Xic. |
|
Hi @vkucera , I see conflicts in Analysis/Tasks/PWGHF/CMakeLists.txt that probably depend on the fact that in the meanwhile something changed in the dev branch (also for the validation framework). I think it's better if you fix it as you prefer, according to the new conventions, in both cases. Do you agree? |
Hi @mfaggin , those should be just conflicts due to the addition of the MC validation task. You should just rebase, resolve the conflicts and push again. |
Hi @vkucera , I manually resolved the conflicts directly from the git interface, please check if my implementations are ok. |
vkucera
left a comment
There was a problem hiding this comment.
As discussed, the selector should use functions from the Lc selector, but that can be done in the next steps.
- (HFCandidateCreator3Prong.cxx) remove refuse std::move, forgot in the middle of the for loop - (HFCandidateCreator3Prong.cxx) fix if statement condition for isMatchedMCGen - (taskXic.cxx) fix MC histogram titles
1b521b4 to
d79b31b
Compare
…isMatchedMCGen for Xic->pKpi
|
The code looks fine now. |
Hi @vkucera , which variables are you referring to? If I am not wrong, the variable names in the |
I meant the configurables and histograms, but it's fine, we can rename them later, together with everything else. |
387c213 to
0776b93
Compare
|
@vkucera I followed your instructions and the |
149f368 to
e20d36b
Compare
9d97ed8 to
afb4535
Compare
b82e082 to
c6c4228
Compare
7b66c68 to
a01c377
Compare
|
Mac CI pending since 2 days. Merging. |
…oup#5436) * PWGHF: first checked code of Xic->pKpi filtering * Update HFSecondaryVertex.h * Update HFXicCandidateSelector.cxx * Fix code with camelCase syntax conventions * Fix code syntax conventions for Xic methods * PWGHF: further fixes for Xic to pKpi filtering and analysis - (HFCandidateCreator3Prong.cxx) remove refuse std::move, forgot in the middle of the for loop - (HFCandidateCreator3Prong.cxx) fix if statement condition for isMatchedMCGen - (taskXic.cxx) fix MC histogram titles * PWGHF: avoid storing return values of RecoDecay::getMatchedMCRec and isMatchedMCGen for Xic->pKpi * PWGHF: pair Xic code with adaptAnalysisTask and charge() changes * PWGHF: remove check for charge to be different from 0 * PWGHF: change label_as into mcParticle_as in taskXic * PWGHF: fix particle label for ct distribution in taskXic * PWGHF: remove selection flag for Xicbar (obsolete) from taskXic Co-authored-by: Mattia Faggin <mfaggin@cern.ch>
No description provided.