[PWGHF] Fix vertexing for charm baryons to cascade + bachelors

[fgrosa]

This PR fixes the vertexing for Xic and OmegaC baryons, by removing the call to propagateTracksToVertex. As observed also for the HF triggers (see 3ea6038) propagateTracksToVertex fails silently for a large fraction of the cases, leading to huge efficiency losses. It is instead better to set propagateToPCA to true in the DCAFitter configuration.
Tagging @zhangbiao-phy @stefanopolitano @xinyepeng @gluparel for info (might be useful to reproduce derived datasets, especially if produced recently).

[github-actions]

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

[alibuild]

Auto-approving on behalf of @fgrosa.

[vkucera]

@fgrosa Does this affect also the V0 + bachelor tracking in HfTrackIndexSkimCreatorCascades?

[vkucera]

Tagging @JaeYoonCHO

[fgrosa]

Hi @vkucera I did not notice that it was used also there. Anyway if no cut is applied after that call, it might be ok, but I did not test it (the most problematic case was the Xic+, that I extensively tested before pushing the fix, since we were not understanding why we were recovering only ~1/10 of the triggered Xic+). If a pt cut is applied afterwards (

O2Physics/PWGHF/TableProducer/trackIndexSkimCreator.cxx

Lines 3273 to 3277 in 3498466

	// cascade candidate pT cut
	const auto ptCascCand = RecoDecay::pt(pVecBach, pVecV0);
	if (ptCascCand < config.ptCascCandMin) {
	continue;
	}

) it might also have an impact (what I noticed is that after the propagateTracksToVertex the momenta of the tracks are completely screwed), but I think that usually we don't apply a min pT cut for the pK0S. I will anyway open a new PR to remove it there as well.

[vkucera]

Hi @vkucera I did not notice that it was used also there. Anyway if no cut is applied after that call, it might be ok, but I did not test it (the most problematic case was the Xic+, that I extensively tested before pushing the fix, since we were not understanding why we were recovering only ~1/10 of the triggered Xic+). If a pt cut is applied afterwards (

O2Physics/PWGHF/TableProducer/trackIndexSkimCreator.cxx

Lines 3273 to 3277 in 3498466

	// cascade candidate pT cut
	const auto ptCascCand = RecoDecay::pt(pVecBach, pVecV0);
	if (ptCascCand < config.ptCascCandMin) {
	continue;
	}

) it might also have an impact (what I noticed is that after the propagateTracksToVertex the momenta of the tracks are completely screwed), but I think that usually we don't apply a min pT cut for the pK0S. I will anyway open a new PR to remove it there as well.

OK, thanks!

[mfaggin]

Ciao @fgrosa , I see that the solution in this PR consists in:

1. put propagateToPCA to true for the DCAFitter object
2. remove the call of propagateTracksToVertex

In other PWGHF tasks I see that this propagateTracksToVertex function is still used, for example (but there are many others):

• PWGHF/TableProducer/candidateCreatorB0.cxx

  O2Physics/PWGHF/TableProducer/candidateCreatorB0.cxx

  Line 349 in 3498466

  df2.propagateTracksToVertex();

  : in this case, I notice that on top of using propagateTracksToVertex there is also propagateToPCA == true by default

• PWGHF/TableProducer/candidateCreatorXic0Omegac0.cxx

  O2Physics/PWGHF/TableProducer/candidateCreatorXic0Omegac0.cxx

  Line 548 in 3498466

  df.propagateTracksToVertex();

  : I this case instead I see that propagateToPCA == false by default

According to your understanding, are the two cases equivalent? Or does one have to switch everywhere to the solution "propagateToPCA == true + remove propagateTracksToVertex calls" ? In the mentioned cases the daughter momenta are always used to calculate invariant mass values on which some selections are applied later.

Thanks in advance, it's just for my understanding, and to understand if analysers have to be pinged.

[vkucera]

Good point @mfaggin !
Would be good to include any further propagation of this change as part of #14541.

[fgrosa]

Good point @mfaggin ! Would be good to include any further propagation of this change as part of #14541.

Indeed, I can remove them from everywhere. It is not superclear to me whether it has a big impact in all cases (with real tracks only, tracks+pseudotracks, etc), but since it is not necessary I would avoid it and rely on propagateToPCA=true instead. It might even be that the issue was not setting propagateToPCA=true and then calling propagateTracksToVertex, while if both are true it might be that the effect is not there, simply because it is not repeated if done already.

[mfaggin]

Good point @mfaggin ! Would be good to include any further propagation of this change as part of #14541.

Indeed, I can remove them from everywhere. It is not superclear to me whether it has a big impact in all cases (with real tracks only, tracks+pseudotracks, etc), but since it is not necessary I would avoid it and rely on propagateToPCA=true instead. It might even be that the issue was not setting propagateToPCA=true and then calling propagateTracksToVertex, while if both are true it might be that the effect is not there, simply because it is not repeated if done already.

thanks a lot @fgrosa , I will point this during the PWGHF discussion on Omegac later. In the meantime, I tag already @fcatalan92 @mtorresc15

[fgrosa]

Good point @mfaggin ! Would be good to include any further propagation of this change as part of #14541.

Indeed, I can remove them from everywhere. It is not superclear to me whether it has a big impact in all cases (with real tracks only, tracks+pseudotracks, etc), but since it is not necessary I would avoid it and rely on propagateToPCA=true instead. It might even be that the issue was not setting propagateToPCA=true and then calling propagateTracksToVertex, while if both are true it might be that the effect is not there, simply because it is not repeated if done already.

thanks a lot @fgrosa , I will point this during the PWGHF discussion on Omegac later. In the meantime, I tag already @fcatalan92 @mtorresc15

Indeed I checked and in all our code, except for the trackIndexSkimCreatorLfCascade we had by default propagateToPCA=true, which should make it safe. The question is about derived data for Xic and OmegaC. Since we apply no cut to Xic0 and OmegaC0 candidates after the vertices, it might even be that they are OK. For Xic+ everything that was produced before adding the vertexing was also good for sure, but I would consider to reproduce the derived data for recent derived data productions with Xic+.

[fcatalan92]

Hi @fgrosa, @mfaggin, I had a quick look at the code to understand the status for the OmegaC, I see that invariant-mass and pT cuts are applied after the vertexing https://github.com/AliceO2Group/O2Physics/blob/master/PWGHF/TableProducer/trackIndexSkimCreator.cxx#L3757-L3764 . The ranges in the index-skim-creator task used to produce the derived data (https://alimonitor.cern.ch/hyperloop/view-wagon/6159/configuration?timestamp=1763568095379) are 2.2 to 3 GeV/c2 for the mass and pT > 0, so a loose selection on the invariant-mass is there. Not sure how big the impact is on the current derived data.

I have a doubt on setting propagateToPCA=true as default, what this parameter does in the DCAFitter is to call propagateTracksToVertex https://github.com/AliceO2Group/AliceO2/blob/ed8276cbddc8b3928c59fd6ee2b68dd60bb6afe1/Common/DCAFitter/include/DCAFitter/DCAFitterN.h#L470 , so having propagateToPCA=true and removing propagateTracksToVertex looks equivalent to set propagateToPCA=false and having propagateTracksToVertex. What's the difference?

I will check the effect of these changes on an AO2D and let you know what happens.

[vkucera]

Has the point raised by @fcatalan92 been resolved?

[fcatalan92]

Has the point raised by @fcatalan92 been resolved?

Hi @vkucera, I managed to complete the checks and will present them at the D2H meeting of tomorrow, you can already find the slides here https://indico.cern.ch/event/1627072/#3-updates-on-charm-baryons-ver .

In summary, with the changes of this PR and #14541 in the skimming:

• for Xic0 and OmegaC0, the number of candidates skimmed decreases by a few percent
• for XiC+, there is a ~70% increase and the same can be obtained by setting propagateToPCA=true in the old code
• for the Lc->pK0s, no changes
• now running with propagateToPCA=false make the task crash at runtime
• the same effect on the skimming could have been obtained by setting propagateToPCA=true in the task configuration, without any code change