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