Skip to content

Conversation

@torkjellsdatter
Copy link
Contributor

Purpose

Implement MC-truth / generated secondary vertex quantities for the triplet observables used in the B → J/ψ K analysis.

Changes

PWGDQ/Core/VarManager.h

  • New function VarManager::FillTrackCollisionMC.
  • Takes a daughter track, the mother track, and the generated collision as arguments
    Computes MC-truth decay length as the difference between collision.mcPosX() and track.vx() (daughter’s generated vertex = secondary vertex).
  • Secondary-vertex quantities are computed using this secondary vertex, and the mother momentum and mass.
  • Note: Mother mass currently implemented only for B⁺ and B⁰.
  • Includes Run 2 projected definitions and expected decay length for cross-checks.

PWGDQ/Tasks/dqEfficiency_withAssoc.cxx

In AnalysisDileptonTrack::runDileptonHadron:

  • Changes applied only for TCandidateType == VarManager::kBtoJpsiEEK.
  • If mcDecision = true, fill MC-truth B-mother quantities and compute MC secondary-vertex quantities using VarManager::FillTrackCollisionMC.
  • Additional MC-truth secondary-vertex variables and reconstructed-vertex errors added to the B-meson table.

PWGDQ/Core/VarManager.cxx

Units defined for the corresponding new values.

PWGDQ/Core/HistogramsLibrary.cxx

Added MC-truth histogram class in the dilepton-trackf subgroup for plotting the new quantities.

@github-actions
Copy link

github-actions bot commented Nov 19, 2025

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

@github-actions github-actions bot changed the title dqEfficiency_withAssoc/VarManager: Add MC-truth secondary vertex for B→J/ψK triplet quantities [PWGDQ] dqEfficiency_withAssoc/VarManager: Add MC-truth secondary vertex for B→J/ψK triplet quantities Nov 19, 2025
[PWGDQ] Please consider the following formatting changes to AliceO2Group#13890
Comment on lines +2851 to +2852
values[kMCVertexingTauz] = (collision.mcPosZ() - track.vz()) * m / (TMath::Abs(MotherTrack.pz()) * o2::constants::physics::LightSpeedCm2NS);
values[kMCVertexingTauxy] = values[kMCVertexingLxy] * m / (MotherTrack.pt() * o2::constants::physics::LightSpeedCm2NS);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe you need to add also the version for Tauxyz ?

values[kMCLxyExpected] = (MotherTrack.pt() / m) * (pdgLifetime * o2::constants::physics::LightSpeedCm2S);
values[kMCLxyzExpected] = (MotherTrack.p() / m) * (pdgLifetime * o2::constants::physics::LightSpeedCm2S);

values[kMCVertexingLzProjected] = ((track.vz() - collision.mcPosZ()) * MotherTrack.pz()) / TMath::Sqrt(MotherTrack.pz() * MotherTrack.pz());
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

in all this expression, what you need is just the sign of the pz component. So instead of pz / (sqrt(pz*pz)) should be just sign(pz()) or TMath::Sign(pz()). However, it seems that there is no straightforward sign function, so at least you could do just this: pz() / abs(pz())


values[kMCVertexingLzProjected] = ((track.vz() - collision.mcPosZ()) * MotherTrack.pz()) / TMath::Sqrt(MotherTrack.pz() * MotherTrack.pz());
values[kMCVertexingLxyProjected] = ((track.vx() - collision.mcPosX()) * MotherTrack.px()) + ((track.vy() - collision.mcPosY()) * MotherTrack.py());
values[kMCVertexingLxyProjected] = values[kVertexingLxyProjected] / TMath::Sqrt((MotherTrack.px() * MotherTrack.px()) + (MotherTrack.py() * MotherTrack.py()));
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This part, TMath::Sqrt((MotherTrack.px() * MotherTrack.px()) + (MotherTrack.py() * MotherTrack.py()), should be just MotherTrack.pt()

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you sure its not
values[kMCVertexingLxyProjected] = values[kVertexingLxyProjected] / TMath::Abs(MotherTrack.pt());

values[kMCVertexingLzProjected] = ((track.vz() - collision.mcPosZ()) * MotherTrack.pz()) / TMath::Sqrt(MotherTrack.pz() * MotherTrack.pz());
values[kMCVertexingLxyProjected] = ((track.vx() - collision.mcPosX()) * MotherTrack.px()) + ((track.vy() - collision.mcPosY()) * MotherTrack.py());
values[kMCVertexingLxyProjected] = values[kVertexingLxyProjected] / TMath::Sqrt((MotherTrack.px() * MotherTrack.px()) + (MotherTrack.py() * MotherTrack.py()));
values[kMCVertexingLxyzProjected] = ((track.vx() - collision.mcPosX()) * MotherTrack.px()) + ((track.vy() - collision.mcPosY()) * MotherTrack.py()) + ((track.vz() - collision.mcPosZ()) * MotherTrack.pz());
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here you compute this as the sum of kMCVertexingLxyProjected and the vz part of the scalar product

values[kMCVertexingLxyProjected] = ((track.vx() - collision.mcPosX()) * MotherTrack.px()) + ((track.vy() - collision.mcPosY()) * MotherTrack.py());
values[kMCVertexingLxyProjected] = values[kVertexingLxyProjected] / TMath::Sqrt((MotherTrack.px() * MotherTrack.px()) + (MotherTrack.py() * MotherTrack.py()));
values[kMCVertexingLxyzProjected] = ((track.vx() - collision.mcPosX()) * MotherTrack.px()) + ((track.vy() - collision.mcPosY()) * MotherTrack.py()) + ((track.vz() - collision.mcPosZ()) * MotherTrack.pz());
values[kMCVertexingLxyzProjected] = values[kMCVertexingLxyzProjected] / TMath::Sqrt((MotherTrack.px() * MotherTrack.px()) + (MotherTrack.py() * MotherTrack.py()) + (MotherTrack.pz() * MotherTrack.pz()));
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here, TMath::Sqrt((MotherTrack.px() * MotherTrack.px()) + (MotherTrack.py() * MotherTrack.py()) + (MotherTrack.pz() * MotherTrack.pz())) , should be just MotherTrack.p()

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Abs(MotherTrack.p())?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

p is just the mom vector magnitude, it can only be positive, no abs is not needed

values[kMCVertexingLxyzProjected] = ((track.vx() - collision.mcPosX()) * MotherTrack.px()) + ((track.vy() - collision.mcPosY()) * MotherTrack.py()) + ((track.vz() - collision.mcPosZ()) * MotherTrack.pz());
values[kMCVertexingLxyzProjected] = values[kMCVertexingLxyzProjected] / TMath::Sqrt((MotherTrack.px() * MotherTrack.px()) + (MotherTrack.py() * MotherTrack.py()) + (MotherTrack.pz() * MotherTrack.pz()));
values[kMCVertexingTauxyProjected] = values[kMCVertexingLxyProjected] * m / (MotherTrack.pt());
values[kMCVertexingTauxyProjectedNs] = values[kMCVertexingTauxyProjected] / o2::constants::physics::LightSpeedCm2NS;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you added this quantity in nano-sec just for the xy projection. Maybe you need it for the others too? Also, for the not projected Tau variables, you have them in nano-seconds, but this is not reflected in the name of the variable. Also, there you have them just in nanoseconds, and not the version which is in spatial units. I suggest to be consistent and have all of these variables.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The default or O2Physics is ns, so It seems unnessecary to specify this in the variable name of all tau variables in all tasks? The reason why I added it here is that "_Projected" are the same definitions in Run2, and at some point, in order to check consistenstsy between Run2 and Run3 I added the "_ProjectedNs" definition. So I havent really used these variables for anything else than Run2/Run3 comparisons.

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

Labels

Development

Successfully merging this pull request may close these issues.

3 participants