Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TPC Tracking: Workaround for 0-cluster tracks #5097

Merged
merged 1 commit into from Dec 25, 2020

Conversation

davidrohr
Copy link
Collaborator

@shahor02 @sawenzel : This should fix (work around) the problem with the 0-cluster tracks you reported.
I could not verify on @sawenzel 's data, since it is no longer present in the tmp folder on lxplus, but this is certainly a but that can cause such behavior.
The background is: By default we drop all secondary legs of looping tracks. If during the refit all hits of the primary leg are rejected, but not of the secondary, it is still a healthy track. When the track is stored discarding all secondary legs, it becomes a 0-cluster track. This is suppressed with this PR.
I think for the future this should be done better, by refitting the track using only the primary leg in such case, in order not to loose the track.

@davidrohr
Copy link
Collaborator Author

Could reproduce the issue mentioned in https://alice.its.cern.ch/jira/browse/O2-1908 by running the full script locally, and this PR fixes it. Merging.

@davidrohr davidrohr merged commit f28e5f0 into AliceO2Group:dev Dec 25, 2020
@shahor02
Copy link
Collaborator

@davidrohr thanks, this indeed fixes Ncl=0 problem.

ncl_befaft

I think one should suppress also the tracks with less than 4 (at least) hits, as kinematically they are not constrained and lack any redundancy.

Should not one redefine the primary leg if after the refit all clusters of the assumed primary leg were suppressed.

@davidrohr
Copy link
Collaborator Author

Tracks with few clusters come from the same problem, i.e. only 1 hit survived in the primary leg. Note that were during the TPC fit correctly constrained from the other hits.

Not 100% sure what to do best. I'll look at some examples to get an idea what actually goes wrong. But I don't see much sense in redefining the primary leg. If the fit problem is only in the primary leg, one should probably undo the merging, but I am not so sure how many tracks are effected in this way, probably it is negligible.

If something goes wrong already beforehand, and this in consequence leads to loosing the hits of the primary leg (which is fitted last), I think it is best to just refit the primary leg only in this case. One could of course still consider to unmerge the track in that case, but then what do I do, just assume the leg next to the originally primary leg as primary? But then it might again suffer from the fit failure. And actually also here I'd check beforehand if there are sufficiently many cases to justify a special treatment.

@shahor02
Copy link
Collaborator

Indeed, unmerging and redefining the primary leg would make sense only if suspect that these low-ncluster "primary legs" are dominantly fake. This seems not to be the case: contamination has max. of ~50% at 8 clusters and drops on for higher and lower nclus
fakefrac
BTW, in case of merging, is the MClabel describing surviving leg or the whole looper?
At the same time, dumping a few 10 such tracks and comparing with their MC particles, I see that the pT resolution is much worse than the declared error (<15% in average from cov. matrix, but off by factor ~2 in most cases).

If we consider only pT>50MeV, then the contamination by tracks of <9 clusters is ~0.5% and drops to 0 above 150 MeV.
frac9
Given their small fraction, I would consider suppressing these tracks: these pTs make sense only for secondary vertices search in the TPC, which implies refit (which requires clusters...).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants