Repository navigation
[PWGLF] Add ML-based track index skim creator for tracks from double omega - #18656
GiorgioAlbertoLucia wants to merge 8 commits into
Conversation
…ame event using derived data
|
O2 linter results: ❌ 0 errors, |
| for (const auto& proton : protons) { | ||
| for (const auto& pion : pions) { | ||
| const auto momentum = RecoDecay::pVec(proton.momentum, pion.momentum); | ||
| const float mass = RecoDecay::m(std::array{proton.momentum, pion.momentum}, std::array{o2::constants::physics::MassProton, o2::constants::physics::MassPionCharged}); |
There was a problem hiding this comment.
Hi @GiorgioAlbertoLucia ! If I understand correctly, you build pair of tracks which were propagated to the primary vertex, and then calculate the invariant mass under the Lambda mass hypothesis (or Omega mass hypothesis below).
However, the invariant mass should be calculated at the production vertex of the daughter tracks (i.e. the decay vertex) in order to have an invariant mass peak.
If you don't propagate the tracks to the decay point, it is unlikely to have an invariant mass peak.
Could you please clarify? Maybe I am missing something.
Thank you very much!
There was a problem hiding this comment.
Ciao @romainschotter,
You are correct in pointing out that the mass variable does not provide a proper evaluation of the Lambda invariant mass. However, in this particular case, an accurate mass reconstruction is not our goal, as this quantity is only used to build candidate pairs that are subsequently refitted.
The purpose of this operation is to reduce the combinatorial background before performing the refit, thereby avoiding the significant computational cost associated with it. The idea is to apply a very loose cut on this approximate invariant mass (e.g. 50 MeV/c²), which is wide enough to retain the signal while still rejecting a substantial fraction of the background.
Regarding your concern about the peak reconstruction, although it is true that the approximation does not reproduce the peak as accurately as the propagator-based calculation, the effect is not as large as one might expect. Here is a comparison of the two distributions, with the fit performed using the propagator (blue) and my approximation (red):
Moreover, given the relatively large mass window, the resulting loss in efficiency is negligible (and will, in any case, be properly accounted for in the analysis). The following plot shows the comparison between the propagator-based calculation (fit) and my approximation (IU):
I hope this clarifies the reasoning behind that line of code!
|
Error while checking build/O2Physics/code-check for 83fa977 at 2026-11-09 12:01: Full log here. |
|
@GiorgioAlbertoLucia Please fix the errors. |
This PR adds a track-level BDT preselection for the double-Omega (ΩΩ → Ω Λ K) search and extends the event mixing of
doubleOmegaTreeCreator.doubleOmegaTrackIndexSkimCreator(o2-analysis-lf-double-omega-track-index-skim-creator, tables inLFDoubleOmegaTrackTables.h)processMC: writes tracks with their MC role toDOmegaTrackTrain, the training sample of a multiclass track BDT. The roles are p, π, K from the Λ and Ω of a ΩΩ decay, other Λ/Ω daughters, and background. Signal is always kept; background and other daughters are downsampled.processCandidates: runs the BDT (ONNX, local or CCDB) on the tracks. It pairs the selected p, π and K into Λ and Ω candidates within loose mass windows and stores their track indices inDOmegaV0sandDOmegaCascades, analogous toaod::V0sandaod::Cascades.computeTrackFeatures) are indoubleOmegaBuilderHelper.hand are computed as in the training.doubleOmegaTreeCreatorprocessFindableTracksWithSkim: likeprocessFindableTracks, but it also checks whether the findable ΩΩ is found in the skim tables. The result goes to a new bin ofMC/generatedAndFindable, "Findable skim cascade + V0", which compares directly with "Findable cascade + V0 + selections" from the standard tables.