[PWGCF] Add configurables for MC analysis

[fsii]

No description provided.

[github-actions]

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

[Copilot]

Pull request overview

This PR extends the PartNumFluc analysis task to make key MC-specific event/vertex handling behaviors configurable, aiming to support a wider range of MC analysis strategies without hard-coded assumptions.

Changes:

• Added configurables to control MC collision selection (single collision, best collision) and which z-vertex (reco vs MC) is used for MC-related calculations.
• Updated efficiency lookup and yield histogram filling to optionally use the MC collision z-vertex.
• Added an MC-event rejection based on the number of reconstructed collisions associated to an MC collision, controlled by a new configurable.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 4 comments.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (2)

PWGCF/EbyEFluctuations/Tasks/partNumFluc.cxx:2241

• With cfgFlagBestCollisionMc disabled, the loop over collisions will run for every reconstructed collision associated to the same MC collision, and the MC-truth block (iteration over mcParticles with mcCollisionId() == mcCollision.globalIndex()) will be executed once per reco-collision. That duplicates MC-truth yields/fluctuations for pileup (mcCollision.numRecoCollision()>1) and can distort denominators/efficiencies. Consider ensuring MC-truth is processed only once per MC collision (or guard/forbid the configuration combination that would double-count).

      if (groupEvent.cfgFlagBestCollisionMc.value && collision.globalIndex() != mcCollision.bestCollisionIndex()) {

PWGCF/EbyEFluctuations/Tasks/partNumFluc.cxx:1587

• cfgFlagMcCollisionVz switches Vz to the MC collision for the McTrack yields/efficiency, but the McMcParticle yield filling still always uses holderEvent.vz (reco Vz). When cfgFlagMcCollisionVz=true, this makes MC-truth and reco-derived histograms use different Vz definitions, which can bias efficiency/yield comparisons.

                  if (groupTrack.cfgFlagMcParticleMomentum.value) {
                    hrCalculationYield.fill(C_CS("CalculationYield/hVzCentralityPtMcEtaMc_mc") + C_SV(getName(PidStrategyValue)) + C_SV(getName(ParticleSpeciesValue)) + C_SV(getName(ChargeSpeciesValue)), doprocessMc.value && groupEvent.cfgFlagMcCollisionVz.value ? holderMcEvent.vz : holderEvent.vz, holderEvent.centrality, holderMcParticle.pt, holderMcParticle.eta);
                  } else {
                    hrCalculationYield.fill(C_CS("CalculationYield/hVzCentralityPtEta_mc") + C_SV(getName(PidStrategyValue)) + C_SV(getName(ParticleSpeciesValue)) + C_SV(getName(ChargeSpeciesValue)), doprocessMc.value && groupEvent.cfgFlagMcCollisionVz.value ? holderMcEvent.vz : holderEvent.vz, holderEvent.centrality, holderTrack.pt, holderTrack.eta);

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 1 comment.

Comments suppressed due to low confidence (1)

PWGCF/EbyEFluctuations/Tasks/partNumFluc.cxx:607

• The help strings for these new MC configurables are hard to interpret (and a bit ungrammatical). Since they are user-facing, consider rephrasing them to clearly describe the selection/vertex behavior.

    Configurable<bool> cfgFlagSingleCollisionMc{"cfgFlagSingleCollisionMc", false, "Flag of requiring exactly single collision of MC collision"};
    Configurable<bool> cfgFlagBestCollisionMc{"cfgFlagBestCollisionMc", true, "Flag of requiring best collision of MC collision"};
    Configurable<bool> cfgFlagMcCollisionVz{"cfgFlagMcCollisionVz", false, "Flag of using z-vertex position of MC collision"};

[SwatiSaha-1997]

Dear @fsii, please correct the formatting errors.

[fsii]

Dear @fsii, please correct the formatting errors.

Hi @SwatiSaha-1997 , these errors in formatting seems not from my side.

Error: Refusing to check out fork pull request code from a 'pull_request_target' workflow. This workflow runs with the base repository's GITHUB_TOKEN, secrets, default-branch cache scope, and runner access. Fetching and executing a fork's code in that trusted context commonly leads to "pwn request" vulnerabilities. To opt in, review the risks at https://gh.io/securely-using-pull_request_target and set 'allow-unsafe-pr-checkout: true' on the actions/checkout step.

[SwatiSaha-1997]

Dear @vkucera, could you please have a look at the errors in this PR and how could it be fixed.

[vkucera]

Dear @vkucera, could you please have a look at the errors in this PR and how could it be fixed.

Hi @SwatiSaha-1997 , please update the PR commits to trigger the formatting checks.