[PWGHF] Fix unbound index issue in XiC0 tree creator

[Tao-Fang]

No description provided.

[vkucera]

Hi @Tao-Fang , please stop creating and closing PRs on the same subject. Keep one PR opened and update it if needed.

[Tao-Fang]

Hi @Tao-Fang , please stop creating and closing PRs on the same subject. Keep one PR opened and update it if needed.
Hello Vit
Sorry for creating so many pull requests, now I want to delete the closed ones and couldn't find the 'Delete pull request' button below the comment box.

[fcatalan92]

Hi @Tao-Fang,
You cannot delete a PR after it has been opened, the only thing you can do is to close it.

Concerning the content, I see you are trying to workaround the unbound index issue (which prevents from running on the GRID if I remember correctly) by replicating the indexing with a different approach. I'm not sure this will work, since the indexing will be the same for multiple jobs on the GRID, so if your plan is to merge the output the index will not be unique.
Can you explain the idea behind your proposed changes?

[Tao-Fang]

Hi @Tao-Fang, You cannot delete a PR after it has been opened, the only thing you can do is to close it.

Concerning the content, I see you are trying to workaround the unbound index issue (which prevents from running on the GRID if I remember correctly) by replicating the indexing with a different approach. I'm not sure this will work, since the indexing will be the same for multiple jobs on the GRID, so if your plan is to merge the output the index will not be unique. Can you explain the idea behind your proposed changes?

Hello Fabio

Thanks for you reply, you are right the indexing will be the same for multiple jobs, and when I do the merge the index will overlap then It can't continue conect event table to collision table. Now I have change the define of HfToXiPiEvBase to INDEX_COLUMN_CUSTOM just like Lc died in DerivedTables.h L166-173, but somehow It will stell overlap when I local test

Cheers
Tao

[fcatalan92]

Hi @Tao-Fang, AFAIK using INDEX_COLUMN_CUSTOM is just another way to define an index column so you get exactly the same unbound index issue as before. The easiest solution is to store the event information that you need in the candidate table, so duplicating it for each candidate. It is not optimal in terms of space but it should work.

I think the approach behind the Lc derived tables is different and they are not meant to be merged. @vkucera can tell you more on this.

[Tao-Fang]

Hi @Tao-Fang, AFAIK using INDEX_COLUMN_CUSTOM is just another way to define an index column so you get exactly the same unbound index issue as before. The easiest solution is to store the event information that you need in the candidate table, so duplicating it for each candidate. It is not optimal in terms of space but it should work.

I think the approach behind the Lc derived tables is different and they are not meant to be merged. @vkucera can tell you more on this.

Thank you for your reply. The easiest solution is indeed to store the needed information, and I have tested it locally—it works.
I was confused about the strategy. For example:

Lc adds multiplicity information in DerivedTables.h.
Ds+ adds it in treeCreatorDsToKKPi.cxx.
D+ was recently updated to include it in DerivedTables.h.

Should I add Xic to DerivedTables.h as well? I am not sure because Lc and D+ are three-prong decays.

[fcatalan92]

@Tao-Fang What is done in DerivedTables.h is an alternative approach to the tree creators, with the idea of storing more information and performing a more complex analysis chain locally (here I'm not an expert). My suggestion is that you stick to use the tree creator.

[Tao-Fang]

Thank you for your patient answer, I just think to add cenrtl directly at the candidate level is easier, now I have update the new code. They tested well locally.

[alibuild]

Error while checking build/O2Physics/o2 for 86be21a at 2025-04-03 13:15:

## sw/BUILD/O2Physics-latest/log
/sw/SOURCES/O2Physics/10710-slc9_x86-64/0/PWGHF/TableProducer/treeCreatorToXiPi.cxx:369:41: error: 'getCentralityPercentile' is not a member of 'o2::hf_centrality'; did you mean 'getCentralityGenColl'?
ninja: build stopped: subcommand failed.

Full log here.

[fcatalan92]

Hi @Tao-Fang, please do not change 'HfToXiPiEvs' and all the tree creator code. You should just add the information you need to HfToXiPiFulls (for consistency) and HfToXiPiLites.

[fcatalan92]

If you just want a specific centrality estimator, please specify this info in the name of the column.

[Tao-Fang]

If you just want a specific centrality estimator, please specify this info in the name of the column.

For different centrality change different processes to achieve, and a common centrality variable is needed, otherwise, some tables that require centrality are not declared, Like I processes the FT0M the FT0A column will not declared at the table I used

[vkucera]

Hi @Tao-Fang , I don't see how these extensive changes address the unbound index issue mentioned in the PR title. Can you please clarify your intentions?

[Tao-Fang]

My initial idea was to adopt an approach similar to the Lc vs multiplicity analysis, where I added FT0M, Ntrack, and other information into the collision table. Then, I try to use the SliceBy method to linke the collision-level and candidate-leve by rowEv.lastIndex(). However, I encount an issue where merging results caused rowEv.lastIndex() to overlap along the y-axis for different parent datasets (since rowEv.lastIndex() is not unique across parent data). This broken link between the collision and candidate layers. I try to repid what seen in utilsDerivedData.h (line 196) and DerivedTables.h (line 177), which define this connection for the Lc vs multiplicity study (treeCreatorLcToPKPi.cxx), but the core linkage issue remains unresolved. (On January 23, I submitted code that introduced FT0M and Ntracks into the collision table which why these variables are now present there)

Faced with this challenge, I just change the way, similar to the Ds analysis (treeCreatorDsToKKPi.cxx), where centrality-related information is added directly at the candidate level. If implemented this way, the previous structure such as storing FT0M in the collision table and relying on sliceBy would become useless. Therefore, I go to remove the collision-level FT0M/Ntracks and related sliceBy wich the January code I submissed.

[vkucera]

Hi @Tao-Fang , thanks for the clarification.
If I understood correctly, the problem you are trying to solve is to link the collision multiplicity/centrality information to the candidate.

• The simplest solution I see is to add that column in the candidate table produced by the tree creator, which is the approach in treeCreatorDsToKKPi, as you pointed out.
• Another solution would be to implement a derived-data creator using the derived-data model in DerivedTables.h, as @fcatalan92 mentioned.

If just adding the multiplicity/centrality column is fine for you, I would suggest to go with the first solution.
In any case, please do not remove any existing functionality.

[Tao-Fang]

Thank you for your understanding. I am currently using the first solution. Regarding the output functions, on one hand, I added them previously, and I believe that deleting this part will not affect others. On the other hand, I need to clean up this part of the results because if I don’t remove the SOA_COLUMN declarations at the collision level, running a specific centrality process will break due to undefined variables. Moreover, the parts I am deleting were intended for the second structure you mentioned, making them clear.

[vkucera]

Why were all these columns removed from the table?!

[Tao-Fang]

This is the part of the structure that I added earlier and wanted to bund central to the collision lever. Of course, it's nice to keep central's information at the collision level. But the problem is that when I choose to run the program in a specific central and want get central info at candidate level (e.g. FT0M it won't find the like FT0A's FT0C Table at collision level), so I just deleted this part