Skip to content

AOD producer: improve MC collision labels for embedded events#15299

Open
sawenzel wants to merge 1 commit intoAliceO2Group:devfrom
sawenzel:swenzel/O2-6840
Open

AOD producer: improve MC collision labels for embedded events#15299
sawenzel wants to merge 1 commit intoAliceO2Group:devfrom
sawenzel:swenzel/O2-6840

Conversation

@sawenzel
Copy link
Copy Markdown
Collaborator

In embedding scenarios where a single background event is reused across multiple collisions, e.g.:

Collision 0: Background 0 + Signal 0
Collision 1: Background 0 + Signal 1
Collision 2: Background 0 + Signal 2
Collision 3: Background 0 + Signal 3
Collision 4: Background 0 + Signal 4

the primary vertexer may return MC labels all pointing to "Background 0". This caused an ambiguous lookup in the AOD producer, resulting in all reconstructed collisions being incorrectly associated to the same MCCollision entry.

This is addressed by collecting all MCCollision candidates matching a given (sourceID, eventID) label and disambiguating via bunch-crossing time, picking the MCCollision whose BC is closest to the reconstructed vertex time.

Note: a more robust long-term solution would be to extend the primary vertexer to return the full set of contributing MC labels per found vertex, enabling simpler and more reliable disambiguation strategies.

This relates to https://its.cern.ch/jira/browse/O2-6840.

In embedding scenarios where a single background event is reused across
multiple collisions, e.g.:

  Collision 0: Background 0 + Signal 0
  Collision 1: Background 0 + Signal 1
  Collision 2: Background 0 + Signal 2
  Collision 3: Background 0 + Signal 3
  Collision 4: Background 0 + Signal 4

the primary vertexer may return MC labels all pointing to "Background 0".
This caused an ambiguous lookup in the AOD producer, resulting in all
reconstructed collisions being incorrectly associated to the same
MCCollision entry.

This is addressed by collecting all MCCollision candidates matching a
given (sourceID, eventID) label and disambiguating via bunch-crossing
time, picking the MCCollision whose BC is closest to the reconstructed
vertex time.

Note: a more robust long-term solution would be to extend the primary
vertexer to return the full set of contributing MC labels per found
vertex, enabling simpler and more reliable disambiguation strategies.

This relates to https://its.cern.ch/jira/browse/O2-6840.
@sawenzel sawenzel requested a review from a team as a code owner April 21, 2026 13:24
@shahor02
Copy link
Copy Markdown
Collaborator

@sawenzel currently the PVertex MCEventLabel follows the same schema as for other reconstructed objects: it corresponds to the label of the majority of contributors (additionally storing also the fraction of this majority).
In principle, independently of this MCEventLabel, which I would not touch, I could store a vector MC events contributing to the given PV. But as far as I understand, propagating this vector to the AOD would require adding a new (small) labels tree.
Still, I am not sure how this would resolve the ambiguity: a reconstructed vertex often contains a few wrongly attached tracks from different event. What will you do for the vertex with the MC event labels {BackgroundA, BackgroundB, SignalC, SignalD}?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

2 participants