Repository navigation
[PWGLF] Add ML-based track index skim creator for tracks from double omega - #18656
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!
There was a problem hiding this comment.
Ciao @GiorgioAlbertoLucia !
I understand now that the mass selection is rather loose. However, propagating the tracks to the decay vertex before calculating the invariant mass would allow you to apply a tighter selection, thereby further reducing the combinatorial background and the computational cost.
Nevertheless, if the motivation for this approach is to reduce computational cost, an even more significant improvement could be achieved by not rebuilding the V0s and cascades, but instead using those already produced by the strangeness builder.
Of course, there may well be a valid reason for not using the strangeness builder. However, if that is the case, I think it should be clearly explained and demonstrated. This point was already raised three months ago and still needs to be explicitly addressed.
I am happy to approve the PR once the remaining errors are fixed. However, I want to stress that the question regarding the use of the strangeness builder needs to be addressed.
Thank you very much!
There was a problem hiding this comment.
Ciao @romainschotter, indeed there is a motivation for not going with the strangeness-builder. The analysis we are carrying out is statistics hungry, and one of the main challenges is improving the reconstruction efficiency. In an efficiency study that Francesco made, we discovered that an important part of the efficiency loss comes directly from using the SVertexer outputs, which is the starting point for the strangeness builder, as far as I understand.
The ML TISC that we propose here bypasses this, by pairing together all the tracks and applying ML cuts to reduce the statistics without affecting the efficiency. In order to reduce the combinatorics further, the mass cut is applied, with the caveat that the loose cut should be sufficient and that reconstructing the vertex each time would increase too much the cpu cost.
I think at this point I can just schedule a pag presentation and show you a couple of these plots. If you will have a better solution, I will be happy to implement that in a future version!
There was a problem hiding this comment.
Ciao @GiorgioAlbertoLucia !
Indeed, this would be very helpful to show a few plots highlighting the loss of cascades with respect to the SVertexer. Again, it is possible that we loose candidates in the SVertexer but, if so, we need to identify at which step the candidates are lost, such that it is fixed for everyone.
In any case, once the PR passes the formatting requirements, I will approve and merge it.
Thank you very much!
Please consider the following formatting changes to AliceO2Group#18656
|
Error while checking build/O2Physics/o2 for 5812f37 at 2026-11-10 09:48: Full log here. |
|
Error while checking build/O2Physics/staging for 5812f37 at 2026-11-10 09:50: Full log here. |
|
Error while checking build/O2Physics/code-check for 5812f37 at 2026-11-10 14:09: Full log here. |
|
Error while checking build/O2Physics/staging for 9f52d58 at 2026-11-10 11:41: Full log here. |
|
Error while checking build/O2Physics/o2 for 018ae47 at 2026-11-10 12:02: Full log here. |
|
Error while checking build/O2Physics/code-check for 018ae47 at 2026-11-10 13:47: Full log here. |
Please consider the following formatting changes to AliceO2Group#18656
Please consider the following formatting changes to AliceO2Group#18656
|
Error while checking build/O2Physics/staging for 018ae47 at 2026-11-10 15:16: Full log here. |
|
Error while checking build/O2Physics/o2 for 979ee6a at 2026-11-10 18:29: Full log here. |
|
Error while checking build/O2Physics/staging for 979ee6a at 2026-11-10 20:19: Full log here. |
|
Error while checking build/O2Physics/code-check for 979ee6a at 2026-11-10 21:12: Full log here. |
Co-Authored-By: Claude Opus 5.5 <[email protected]>
|
Hello @GiorgioAlbertoLucia, sorry to jump in, but why is this in the strangeness folder? The analysis is under NUSPEX ... |
Ciao @mpuccio, the task started as OmegaOmega correlations, it is a good point to move it to nuspex. I will update this PR |
|
hi @GiorgioAlbertoLucia, thanks! I guess you can move it in the next PR as this was merged by @romainschotter |
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.