[PWGCF] Update on femtoDream Framework：Event Plane & Qn

[mutecho]

Update in DataModel:
1、New column EventPlane, containing event plane angle psi (in degrees) for each event. Stored in new table FDExtEPCollisions independently.

Update in functional part:
1、3D femto calculation
2、pair phi-psi binning in femto calculation
3、mixing policy with event plane psi angle

Minor change:
1、added .clangd in gitignore in case someone might want to use

[github-actions]

O2 linter results: ❌ 233 errors, ⚠️ 300 warnings, 🔕 0 disabled

[lauraser]

I had a look and did not notice any clashes with the main framework. As the PR is big, it would be good if also @victor-gonzalez has a look if you have time.

[victor-gonzalez]

I had a look and did not notice any clashes with the main framework. As the PR is big, it would be good if also @victor-gonzalez has a look if you have time.

I will do it along today

But first I would suggest rebasing the changes to the latest tag
30 commits from two months ago doesn't look appropriate

[wenyaCern]

I had a look and did not notice any clashes with the main framework. As the PR is big, it would be good if also @victor-gonzalez has a look if you have time.

I will do it along today

But first I would suggest rebasing the changes to the latest tag 30 commits from two months ago doesn't look appropriate

Dear Victor,
Thank you very much for your attention and review. The branch has been updated and rebased to the latest tag. These commits only show the history of changes made to this branch. There are no conflicts with the latest O2Physics tag. We would like to ask is your opinion to creat a new branch and submit the pull request with clear commits ?

[victor-gonzalez]

I would recommend the same as the linter, use always the std:: prefix

[mutecho]

All abs are now std::abs. But it seemed to me that linter didn’t suggest me to do so ( since I’m not quite familiar with GitHub), could you please tell me where to see this?

[victor-gonzalez]

Check the linter log following the link of the failed O2linter check
At the end of the log you get indications on how to run the test locally

[victor-gonzalez]

This is a change done at the top level of the O2Physics hierarchy
We at PWGCF don't have approval rights for it
Is it really needed?
(It seems no one has asked for it before)

[mutecho]

This is for anyone who wants fine tune on how their clangd would behave, but if it’s beyond PWG work let’s forget about it. The standard settings do a good job as well.

[victor-gonzalez]

I would suggest an intensive use of the methods in O2Physics/Common/Core/RecoDecay.h instead of the ROOT four vectors arithmetic and adhering to the linter recommendations, specially in the new source code

[victor-gonzalez]

I had a look and did not notice any clashes with the main framework. As the PR is big, it would be good if also @victor-gonzalez has a look if you have time.

I will do it along today
But first I would suggest rebasing the changes to the latest tag 30 commits from two months ago doesn't look appropriate

Dear Victor, Thank you very much for your attention and review. The branch has been updated and rebased to the latest tag. These commits only show the history of changes made to this branch. There are no conflicts with the latest O2Physics tag. We would like to ask is your opinion to creat a new branch and submit the pull request with clear commits ?

To me it looks like the latest tag have been merged several times (as can be seen in the last two months commits history) but that is something completely different than rebasing the changes to the latest tag. In my opinion those merges should then disappear, independently of in which branch it is done

[victor-gonzalez]

Why keeping merging and not rebasing?

[mutecho]

Why keeping merging and not rebasing?

I'm going to reset and force push an all-in-one commit to avoid solving conflicts for all these versions.... So first I would like to confirm is there still any further modifications needed (so that there would be only one commit in final history), if not, I'll starting handling this. Thank you @victor-gonzalez

[victor-gonzalez]

Why keeping merging and not rebasing?

I'm going to reset and force push an all-in-one commit to avoid solving conflicts for all these versions.... So first I would like to confirm is there still any further modifications needed (so that there would be only one commit in final history), if not, I'll starting handling this. Thank you @victor-gonzalez

Why not just rebase (https://git-scm.com/book/en/v2/Git-Branching-Rebasing) and force push?

[mutecho]

Why keeping merging and not rebasing?

I'm going to reset and force push an all-in-one commit to avoid solving conflicts for all these versions.... So first I would like to confirm is there still any further modifications needed (so that there would be only one commit in final history), if not, I'll starting handling this. Thank you @victor-gonzalez

Why not just rebase (https://git-scm.com/book/en/v2/Git-Branching-Rebasing) and force push?

Well, like I said, when doing rebase I need to solve the conflicts in all 30+ commits(Because the whole git works on all previous commits, simply dropping is not possible), which would be unnecessary time consumption and it very easily leads to mistakes introduced by human. So basically I have three options:
1 reset - merge - commit - force push, in this case conflicts only appear once
2 new branch - cherry picking - new PR
3 squash these commits by you, if you're willing to
and I think solution 1 would be easiest for all of us

[victor-gonzalez]

Why keeping merging and not rebasing?

I'm going to reset and force push an all-in-one commit to avoid solving conflicts for all these versions.... So first I would like to confirm is there still any further modifications needed (so that there would be only one commit in final history), if not, I'll starting handling this. Thank you @victor-gonzalez

Why not just rebase (https://git-scm.com/book/en/v2/Git-Branching-Rebasing) and force push?

Well, like I said, when doing rebase I need to solve the conflicts in all 30+ commits(Because the whole git works on all previous commits, simply dropping is not possible), which would be unnecessary time consumption and it very easily leads to mistakes introduced by human. So basically I have three options: 1 reset - merge - commit - force push, in this case conflicts only appear once 2 new branch - cherry picking - new PR 3 squash these commits by you, if you're willing to and I think solution 1 would be easiest for all of us

This situation did not happen because the way git works, git works as the users ask it to work
This happened because instead of rebasing the intermediate changes, they were merged with the master and this creates a cumulative situation which actually pollutes the branch tree not allowing its clean rebase

Now, as you said, the option one is the only viable
In the future, never merge your branches with your changes, rebase them to keep the branch tree clean

Regarding further changes, in the logic I haven't see any issue
I suggested following linter recommendations in the new code

[mutecho]

Why keeping merging and not rebasing?

I'm going to reset and force push an all-in-one commit to avoid solving conflicts for all these versions.... So first I would like to confirm is there still any further modifications needed (so that there would be only one commit in final history), if not, I'll starting handling this. Thank you @victor-gonzalez

Why not just rebase (https://git-scm.com/book/en/v2/Git-Branching-Rebasing) and force push?

Well, like I said, when doing rebase I need to solve the conflicts in all 30+ commits(Because the whole git works on all previous commits, simply dropping is not possible), which would be unnecessary time consumption and it very easily leads to mistakes introduced by human. So basically I have three options: 1 reset - merge - commit - force push, in this case conflicts only appear once 2 new branch - cherry picking - new PR 3 squash these commits by you, if you're willing to and I think solution 1 would be easiest for all of us

This situation did not happen because the way git works, git works as the users ask it to work This happened because instead of rebasing the intermediate changes, they were merged with the master and this creates a cumulative situation which actually pollutes the branch tree not allowing its clean rebase

Now, as you said, the option one is the only viable In the future, never merge your branches with your changes, rebase them to keep the branch tree clean

Regarding further changes, in the logic I haven't see any issue I suggested following linter recommendations in the new code

Thank you for the advise, I'll try not to mess this in the future. wenya had force pushed a version yesterday, and the branch should be clean for PR now

[alibuild]

Error while checking build/O2Physics/o2 for ebc2a71 at 2025-11-18 20:46:

## sw/BUILD/O2Physics-latest/log
/sw/SOURCES/O2Physics/13801-slc9_x86-64/0/PWGCF/FemtoDream/Tasks/femtoDreamPairTaskTrackTrack.cxx:764:43: error: 'myqnBin' may be used uninitialized [-Werror=maybe-uninitialized]
/sw/SOURCES/O2Physics/13801-slc9_x86-64/0/PWGCF/FemtoDream/TableProducer/femtoDreamProducerTask.cxx:1118:109: error: unused parameter 'multNtr' [-Werror=unused-parameter]
ninja: build stopped: subcommand failed.

Full log here.

[wenyaCern]

Dear @victor-gonzalez, Dear @shouqiye ,
It seems the CI workflow didn't been actived via the approve (for the updated commit with debuging for two warnings which were treated by alibuild as Errors.) Could you please approve again and active the pCI check "build/O2Physics/o2"? Thanks a lot for your help!