[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+.