[PWGCF] add 2 and 4 particle correlation and fix errors

[pykuan]

No description provided.

[github-actions]

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

[alibuild]

Error while checking build/O2Physics/o2 for a7a4270 at 2026-06-11 12:50:

## sw/BUILD/O2Physics-latest/log
/sw/SOURCES/O2Physics/slc9_x86-64-slc9_x86-64/0/PWGCF/MultiparticleCorrelations/Tasks/multiparticleCumulants.cxx:556:16: error: 'Q' was not declared in this scope
/sw/SOURCES/O2Physics/slc9_x86-64-slc9_x86-64/0/PWGCF/MultiparticleCorrelations/Tasks/multiparticleCumulants.cxx:1054:62: error: 'Cos' is not a member of 'o2::constants::math'
/sw/SOURCES/O2Physics/slc9_x86-64-slc9_x86-64/0/PWGCF/MultiparticleCorrelations/Tasks/multiparticleCumulants.cxx:1055:62: error: 'Sin' is not a member of 'o2::constants::math'
/sw/SOURCES/O2Physics/slc9_x86-64-slc9_x86-64/0/PWGCF/MultiparticleCorrelations/Tasks/multiparticleCumulants.cxx:814:11: error: unused variable 'histAcceptanceWeight' [-Werror=unused-variable]
/sw/SOURCES/O2Physics/slc9_x86-64-slc9_x86-64/0/PWGCF/MultiparticleCorrelations/Tasks/multiparticleCumulants.cxx:814:11: error: unused variable 'histAcceptanceWeight' [-Werror=unused-variable]
ninja: build stopped: subcommand failed.

Full log here.

[alibuild]

Error while checking build/O2Physics/staging for a7a4270 at 2026-06-11 12:53:

## sw/BUILD/O2Physics-latest/log
/sw/SOURCES/O2Physics/slc9_x86-64-slc9_x86-64/0/PWGCF/MultiparticleCorrelations/Tasks/multiparticleCumulants.cxx:556:16: error: 'Q' was not declared in this scope
/sw/SOURCES/O2Physics/slc9_x86-64-slc9_x86-64/0/PWGCF/MultiparticleCorrelations/Tasks/multiparticleCumulants.cxx:1054:62: error: 'Cos' is not a member of 'o2::constants::math'
/sw/SOURCES/O2Physics/slc9_x86-64-slc9_x86-64/0/PWGCF/MultiparticleCorrelations/Tasks/multiparticleCumulants.cxx:1055:62: error: 'Sin' is not a member of 'o2::constants::math'
/sw/SOURCES/O2Physics/slc9_x86-64-slc9_x86-64/0/PWGCF/MultiparticleCorrelations/Tasks/multiparticleCumulants.cxx:814:11: error: unused variable 'histAcceptanceWeight' [-Werror=unused-variable]
/sw/SOURCES/O2Physics/slc9_x86-64-slc9_x86-64/0/PWGCF/MultiparticleCorrelations/Tasks/multiparticleCumulants.cxx:814:11: error: unused variable 'histAcceptanceWeight' [-Werror=unused-variable]
ninja: build stopped: subcommand failed.

Full log here.

[vkucera]

@pykuan You are supposed to test your changes before you make a PR. Please follow the contribution guidelines.

[pykuan]

@pykuan You are supposed to test your changes before you make a PR. Please follow the contribution guidelines.

Sorry, the clang-format in local didn't work properly. It caused even more errors than I expected... I'll try to fix O2 linter error and the code itself first.

[vkucera]

@pykuan You are supposed to test your changes before you make a PR. Please follow the contribution guidelines.

Sorry, the clang-format in local didn't work properly. It caused even more errors than I expected... I'll try to fix O2 linter error and the code itself first.

clang-format cannot cause errors if you use it as explained in the documentation and it has definitely nothing to do with your broken compilation.

[vkucera]

How exactly are you using clang-format?

[pykuan]

How exactly are you using clang-format?

I used "clang-format -i someFile" but it somehow breaks lines that are supposed to be in a single line, and causes errors. I saw there are many configurables in clang-format but didn't know which to switch off to satisfy the automatic checks.
In the last modification I tried to change them manually according to the error message.

[vkucera]

How exactly are you using clang-format?

I used "clang-format -i someFile" but it somehow breaks lines that are supposed to be in a single line, and causes errors. I saw there are many configurables in clang-format but didn't know which to switch off to satisfy the automatic checks. In the last modification I tried to change them manually according to the error message.

There is no such instruction in the documentation to use clang-format -i. Where did you get it from?

[abilandz]

How exactly are you using clang-format?

I used "clang-format -i someFile" but it somehow breaks lines that are supposed to be in a single line, and causes errors. I saw there are many configurables in clang-format but didn't know which to switch off to satisfy the automatic checks. In the last modification I tried to change them manually according to the error message.

There is no such instruction in the documentation to use clang-format -i. Where did you get it from?

From me. I was using that regularly for local formatting before committing code to the O2physics repository, starting in 2023. I also used it a few months ago when making my last commit, and there were no problems or complaints.

I do not remember from where I got it any longer in 2023, but for more than 2 years (at least), there were no problems with that. Can you please clarify to us why we cannot use suddenly clang-format -i any longer locally for formatting? Thanks!

[vkucera]

Hi @abilandz

Can you please clarify to us why we cannot use suddenly clang-format -i any longer locally for formatting? Thanks!

You can use whatever you want but:

• a) it's obvious that whatever you are doing now simply does not work and
• b) there are already documented automated tools that do the formatting for you, so there is no reason to do it by hand.

[abilandz]

Hi @abilandz

Can you please clarify to us why we cannot use suddenly clang-format -i any longer locally for formatting? Thanks!

You can use whatever you want but:

If my memory does not betray me, when I was getting first formatting errors on my very first commits in O2Physics, I was getting automatically generated commits from aliBuild with the title "Please consider the following formatting changes", or something like that. I think that after inspecting the online log, I realized they were generated with clang-format. I tried to use myself clang-format locally in the same way, before making any new commit, and it worked - from that point onward I never had problems with the formatting of my commits.

And I completely eliminated from my workflow in O2Physics these unnecessary automatically generated commits from aliBuild related to the formatting.

Btw, the flag "-i" is irrelevant for this discussion - it merely updates the files in-place after the formatting (in the same fashion as sed -i does it, etc).

• a) it's obvious that whatever you are doing now simply does not work and

This is not a fair summary. We have used `clang-format' successfully for more than two years, basically in all my commits in the past 2+ years. @pykuan also used it successfully in her commits in the past few weeks. So something very recently has changed in the workflow related to the formatting.

Could you please clarify what has changed? Do we use some other tool now instead of clang-format, or do we still use it, but with some new non-default options, etc?

• b) there are already documented automated tools that do the formatting for you, so there is no reason to do it by hand.

I do not consider executing clang-format -i someFile before making a commit to be that difficult... It's trivial in fact.

Are you suggesting now that we should not attempt to format ourselves the code locally, and just rely on these automated tools you are mentioning?

But if I can format in the very same way my code locally, that should only ease the burden on those automated tools... Therefore, I do not fully understand your point here.

[abilandz]

I see most of the formatting problems are fixed, therefore I approve this one. Please address the remaining 1 error from O2linter in the next PR.

[vkucera]

@abilandz

... I was getting automatically generated commits from aliBuild with the title "Please consider the following formatting changes..."

It is still the case. See above.

• a) it's obvious that whatever you are doing now simply does not work and

This is not a fair summary.

I don't know what you find "not fair" but the facts are simple. If your local formatting worked, there would be no formatting PR created. It was created, therefore your local formatting does not work.

So something very recently has changed in the workflow related to the formatting.

No, nothing has changed very recently. The last change of the clang-format version was in March.

Do we use some other tool now instead of clang-format, or do we still use it, but with some new non-default options, etc?

No. The options have not changed as far as I can remember.

I do not consider executing clang-format -i someFile before making a commit to be that difficult... It's trivial in fact.

It's trivial and wrong because you are missing the --style option which applies the project configuration. That's why we provide and encourage automated solutions.

Are you suggesting now that we should not attempt to format ourselves the code locally, and just rely on these automated tools you are mentioning?

Yes. It's written in the documentation.

But if I can format in the very same way my code locally, that should only ease the burden on those automated tools...

If you prefer extra work and want to do it locally by hand, do it at least properly and do not confuse students with wrong instructions. Otherwise, there is a configured and documented pre-commit hook for this.

[vkucera]

@abilandz

... I was getting automatically generated commits from aliBuild with the title "Please consider the following formatting changes..."

It is still the case. See above.

• a) it's obvious that whatever you are doing now simply does not work and

This is not a fair summary.

I don't know what you find "not fair" but if your local formatting worked, there would be no formatting PR created. It was created, therefore your local formatting does not work.

So something very recently has changed in the workflow related to the formatting.

No, nothing has changed very recently. The last change of the clang-format version was in March.

Do we use some other tool now instead of clang-format, or do we still use it, but with some new non-default options, etc?

No. The options have not changed as far as I can remember.

I do not consider executing clang-format -i someFile before making a commit to be that difficult... It's trivial in fact.

It's trivial and also wrong because you are missing the --style option which applies the project configuration. That's why we provide and encourage automated solutions.

Are you suggesting now that we should not attempt to format ourselves the code locally, and just rely on these automated tools you are mentioning?

Yes. It's written in the documentation.

But if I can format in the very same way my code locally, that should only ease the burden on those automated tools...

If you prefer extra work and want to do it locally by hand, do it at least properly and do not confuse students with wrong instructions. Otherwise, there is a configured and documented pre-commit hook for this.