[PWGDQ] Fix event mixing bug in MixingHandler and tableReader by JinjooSeo · Pull Request #17880 · AliceO2Group/O2Physics

JinjooSeo · 2026-09-11T13:36:12Z

Problems

Mixing-only variables were never filled by VarManager::FillEvent()
FindEventCategory() mixed up two variable orders, so different (vtxZ, centrality) bins could hash to the same category
Out-of-range events in mixing categories all got hash -1 and were mixed
In *direct workflow, the hash was published after event selection, shifting the hash of all following events
UpdatePool() ages each stored event with its own mask instead of the arriving event's, so cfgMixingDepth counts arrivals rather than mixed partners: a selective track cut gets far fewer partners than a loose one
Pools crossed run boundaries

Changes

AddMixingVariable() marks the variable as used
Category hashing uses one consistent variable order
Out-of-range events get a distinct negative hash
Hash is published before any event selection, one row per event
Add UpdatePool(event, poolDepth, agingMask): the across-TF path passes the mask of the arriving event, so an event is aged for a cut only when a mixed pair was produced for it
Pools are cleared at a run change

github-actions · 2026-09-11T13:36:31Z

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

vkucera

@JinjooSeo Please add the location in the PR title. (See the contribution guidelines.)

JinjooSeo · 2026-09-11T15:40:42Z

@JinjooSeo Please add the location in the PR title. (See the contribution guidelines.)

@vkucera PWGDQ is already attached do I need to add another location?

vkucera · 2026-09-11T15:47:51Z

@JinjooSeo Please add the location in the PR title. (See the contribution guidelines.)

@vkucera PWGDQ is already attached do I need to add another location?

Yes. PWGDQ is just a tag. Did you read the guidelines?

vkucera

Thanks for fixing the title.

mguilbau

Hi @JinjooSeo,
Could you please fix the o2 linter error here? You have duplicated some existing one so I would kindly ask you to fix these

JinjooSeo · 2026-09-12T15:09:18Z

Hi @JinjooSeo, Could you please fix the o2 linter error here? You have duplicated some existing one so I would kindly ask you to fix these

Hi @mguilbau Thanks! I've made a fix, but I'm not sure if it's what you meant. could you take a look and let me know if there iss anything else?

iarsene · 2026-09-16T09:39:14Z

+    // globalIndex is unique only within a dataframe, so the dataframe sequence is part of the track identity
+    uint64_t dataFrameSequence = 0;
+    uint64_t trackGlobalIndex = 0;
+    // electric charge of the track; 0 means "not set" and disables the charge dependent pair variables
+    int8_t sign = 0;
+    bool IsSamePhysicalTrack(const MixingTrack& other) const
+    {
+      return dataFrameSequence == other.dataFrameSequence && trackGlobalIndex == other.trackGlobalIndex;
+    }


I don't think that this is needed. The tracks and events added to the mixing pools are different and don't need the DF or track index, neither the charge. For example, to distinguish the tracks when doing like-sign, one only needs to compare the iterators. Also, regarding the sign, the events are organized already such that they have two different track lists. In this particular case they are separated based on charge, but in other cases these can be particle species, or whatever (trigger and assoc particle, etc.). So this is a specialization that is not needed here, but it is implemented at the place where the mixing handler is actually used. So, since we need to add additional variables in this struct that are going to be needed for other purposes (such as mixing for flow, polarization, correlations), I strongly suggest to not add these new members. I agree they might be nice to have, but this is a part of code that is intensively used in our workflows and we should keep it at a minimum required.

Thanks Ionut! I fully agree with you and I reverted them.

Just for the record, it was catching a track associated with two collisions of the same DF getting paired with itself in LS. Both copies have identical kinematics, so it will always be at 1 MeV LS only. Negligible for our analysis, but worth keeping in mind for possible analysis (maybe correlation..?)

iarsene · 2026-09-16T09:40:03Z

+  // dataframe counter, part of the track identity in the mixing pools
+  uint64_t fMixingDataFrameSequence = 0;


As commented above, this is not needed.

iarsene · 2026-09-16T09:40:58Z

+    uint64_t currentMixingDataFrameSequence = 0;
+    if (fConfigRunMixingAcrossTFs) {
+      currentMixingDataFrameSequence = ++fMixingDataFrameSequence;
+    }


As commented above

iarsene · 2026-09-16T09:41:36Z

            }
            auto t1 = assoc.template reducedtrack_as<TTracks>();
-            MixingHandler::MixingTrack mixingTrack(t1.pt(), t1.eta(), t1.phi(), trackFilterForMixing);
+            MixingHandler::MixingTrack mixingTrack(t1.pt(), t1.eta(), t1.phi(), trackFilterForMixing, currentMixingDataFrameSequence, static_cast<uint64_t>(assoc.reducedtrackId()), static_cast<int8_t>(t1.sign()));


As commented above, we should not need these additional members.

iarsene · 2026-09-16T09:42:12Z

+              // check the two-track filter for the mixed pair and skip the same track associated to both collisions
              uint32_t mixedTwoTrackFilter = t1.filteringFlags & t2.filteringFlags;
-              if (!mixedTwoTrackFilter) {
+              if (!mixedTwoTrackFilter || t1.IsSamePhysicalTrack(t2)) {


the check should be removed, you can just make a comparison of the iterators instead

iarsene · 2026-09-16T09:43:22Z

+              // check the two-track filter for the mixed pair and skip the same track associated to both collisions
              uint32_t mixedTwoTrackFilter = t1.filteringFlags & t2.filteringFlags;
-              if (!mixedTwoTrackFilter) {
+              if (!mixedTwoTrackFilter || t1.IsSamePhysicalTrack(t2)) {


the check should be replaced with a comparison of the iterators

JinjooSeo requested review from XiaozhiBai, alibuild, iarsene, mcoquet642 and mguilbau as code owners September 11, 2026 13:36

github-actions Bot added the pwgdq label Sep 11, 2026

github-actions Bot changed the title ~~Fix event mixing bug~~ [PWGDQ] Fix event mixing bug Sep 11, 2026

vkucera requested changes Sep 11, 2026

View reviewed changes

JinjooSeo changed the title ~~[PWGDQ] Fix event mixing bug~~ [PWGDQ] Fix event mixing bug in MixingHandler and tableReader Sep 11, 2026

JinjooSeo requested a review from vkucera September 11, 2026 16:30

vkucera previously approved these changes Sep 11, 2026

View reviewed changes

mguilbau reviewed Sep 12, 2026

View reviewed changes

JinjooSeo dismissed vkucera’s stale review via 3d4aefe September 12, 2026 14:47

JinjooSeo force-pushed the pwgdq-mixing-min branch from fc7adcd to 3d4aefe Compare September 12, 2026 14:47

JinjooSeo force-pushed the pwgdq-mixing-min branch 2 times, most recently from 5b56f1e to 3804722 Compare September 15, 2026 11:41

mguilbau previously approved these changes Sep 15, 2026

View reviewed changes

iarsene reviewed Sep 16, 2026

View reviewed changes

mcoquet642 requested a review from mguilbau September 16, 2026 09:52

JinjooSeo added 5 commits September 16, 2026 12:56

Fix event mixing bug

84e7fc5

o2 linter

60f0039

back to rolling mixing

dcda5ca

fix

de52d33

address comments

54969bf

JinjooSeo dismissed mguilbau’s stale review via 54969bf September 16, 2026 10:59

JinjooSeo force-pushed the pwgdq-mixing-min branch from 3804722 to 54969bf Compare September 16, 2026 10:59

		// dataframe counter, part of the track identity in the mixing pools
		uint64_t fMixingDataFrameSequence = 0;

Uh oh!

Conversation

JinjooSeo commented Sep 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions Bot commented Sep 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

vkucera left a comment

Choose a reason for hiding this comment

Uh oh!

JinjooSeo commented Sep 11, 2026

Uh oh!

vkucera commented Sep 11, 2026

Uh oh!

vkucera left a comment

Choose a reason for hiding this comment

Uh oh!

mguilbau left a comment

Choose a reason for hiding this comment

Uh oh!

JinjooSeo commented Sep 12, 2026

Uh oh!

iarsene Sep 16, 2026

Choose a reason for hiding this comment

Uh oh!

JinjooSeo Sep 16, 2026

Choose a reason for hiding this comment

Uh oh!

iarsene Sep 16, 2026

Choose a reason for hiding this comment

Uh oh!

iarsene Sep 16, 2026

Choose a reason for hiding this comment

Uh oh!

iarsene Sep 16, 2026

Choose a reason for hiding this comment

Uh oh!

iarsene Sep 16, 2026

Choose a reason for hiding this comment

Uh oh!

iarsene Sep 16, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

4 participants

JinjooSeo commented Sep 11, 2026 •

edited

Loading

github-actions Bot commented Sep 11, 2026 •

edited

Loading