[PWGHF,PWGCF] fix the issue of int configurable caste to int8_t and add QA plot of charm mass vs pt in MC rec #13240
Conversation
github-actions
bot
changed the title
|
O2 linter results: ❌ 44 errors, |
zhangbiao-phy
changed the title
zhangbiao-phy
changed the title
zhangbiao-phy
changed the title
zhangbiao-phy
requested review from
NicoleBastid,
alibuild,
apalasciano,
deepathoms,
fcatalan92,
fcolamar,
fgrosa,
gluparel,
hahassan7,
jgrosseo,
jpxrk,
lgraczykCern,
mfaggin,
mmazzilli,
stefanopolitano,
victor-gonzalez,
vkucera and
zchochul
as code owners
zhangbiao-phy
requested review from
ariedel-cern,
glromane,
lauraser,
otonvd,
prchakra and
shouqiye
as code owners
| DECLARE_SOA_COLUMN(Prong1Phi, prong1Phi, float); //! Track phi of charm hadron prong1 | ||
| DECLARE_SOA_COLUMN(Prong2Phi, prong2Phi, float); //! Track phi of charm hadron prong2 | ||
| DECLARE_SOA_COLUMN(CandidateSelFlag, candidateSelFlag, int8_t); //! Selection of mass hypothesis for charm hadron (1 for Lc -> pkpi, 2 for Lc -> pikp, 4 for D+ -> pikpi) | ||
| DECLARE_SOA_COLUMN(CandidateSelFlag, candidateSelFlag, int); //! Selection of mass hypothesis for charm hadron (1 for Lc -> pkpi, 2 for Lc -> pikp, 4 for D+ -> pikpi) |
There was a problem hiding this comment.
I believe that int8_t is the only integral type affected by this issue. Why not use int16_t?
There was a problem hiding this comment.
Thank you for the suggestion! Using int16_t would indeed be more memory-efficient, but I kept it as int for consistency with other columns and to avoid additional casting in the task code.
There was a problem hiding this comment.
Sorry, but I couldn't find a line where additional casting would be needed. Can you refer them?
There was a problem hiding this comment.
here:
I will get the error if I didn't caste it to
int16_t: Reason: Failed to create filter: ExpressionValidationError: Function bool greater_than_or_equal_to(int16, int32) not supported yet.
There was a problem hiding this comment.
I don't see why charmHadMcSel has to be int.
There was a problem hiding this comment.
Your solution is to promote all concerned variables to
int. I am proposing to make them the smallest working integral type, which AFAIK isint16_t.
I agree with your point and I also want to improve it with this point. However as I mentioned above, I already tried int16_t. It doesn't work (seems not support). So could you please approve it with current version?
There was a problem hiding this comment.
If you are referring to the error
Function bool greater_than_or_equal_to(int16, int32) not supported yet.
I believe that one is irrelevant to my proposal.
I assume that in that case flagMc was int16 and charmHadMcSel was int.
What I am proposing is to have both of them int16 which should be supported.
There was a problem hiding this comment.
I already tried both case (flagMc was int16 and charmHadMcSel was int16). it is not the case.
There was a problem hiding this comment.
What do you mean? What is not the case? What is the error then?
There was a problem hiding this comment.
I will try to investigate locally. Go ahead.
alibuild
left a comment
alibuild
left a comment
There was a problem hiding this comment.
Auto-approving on behalf of @zhangbiao-phy.
|
@zhangbiao-phy @shouqiye @ariedel-cern @lauraser Are we sure this does not break backward compatibility with already produced derived data? |
Hi @victor-gonzalez, sorry for confused you again! I think the changes only related to the HF part, we don't produce derived data for common used, since there are only two analysis (pLc and pDplus) used such tables for the moment. |
|
@victor-gonzalez thanks a lot for tagging me, I can confirm the statement by Biao, that these are tables used by HF exclusively and affect only their derived data. So everything should be fine for LF analyses. |
…dd QA plot of charm mass vs pt in MC rec (AliceO2Group#13240)
…dd QA plot of charm mass vs pt in MC rec (AliceO2Group#13240)
…dd QA plot of charm mass vs pt in MC rec (AliceO2Group#13240)
…dd QA plot of charm mass vs pt in MC rec (AliceO2Group#13240)
…dd QA plot of charm mass vs pt in MC rec (AliceO2Group#13240)
6 participants
The issue is It will always use the default value when the int configurable caste to int8_t in Filter or Partition