[FCC] Tracking: Prepare for TrackMerger - #193
Conversation
|
Relies on a solution of key4hep/k4RecTracker#90 |
746e4f2 to
07241b2
Compare
This is no longer true, I think. |
07241b2 to
dc6c509
Compare
3693c3a to
e708419
Compare
e708419 to
2c768e0
Compare
ed42ee8 to
256226c
Compare
6c1be0a to
dec74d0
Compare
| # TrackMerger considers two tracks a match if the differences of their track | ||
| # parameters at the adjoining hit are within the configured tolerances. Each | ||
| # of the 5 track parameters (D0, Z0, phi, omega, tanLambda) has its own | ||
| # tolerance property; a negative value disables that parameter, i.e. it is | ||
| # not considered for matching. The properties are: | ||
| # D0Tolerance, Z0Tolerance, PhiTolerance, OmegaTolerance, TanLambdaTolerance | ||
| # | ||
| # The defaults set in TrackMerger.cpp reproduce the original criterion | ||
| # (D0Tolerance=0.5, Z0Tolerance=2.5, everything else negative/disabled), so | ||
| # this dict only needs entries for parameters you want to override, e.g. | ||
| # {"PhiTolerance": 0.05} to also require phi compatibility, or | ||
| # {"D0Tolerance": -1} to turn the D0 check off. |
There was a problem hiding this comment.
meta question to this, resp. the track merger: What happens to the forward SiTracks that do not have a Clupatra counter part, simply because the underlying particle doesn't go through the TPC?
There was a problem hiding this comment.
They will not appear in the output collection of the TrackMerger. I guess we wanna have another processor after the TrackMerger that finds those tracks and combines them with the merged ones
There was a problem hiding this comment.
I am not quite sure whether it needs to be another algorithm (or whether it can actually be without re-doing quite a bit of work). In the end the TrackMerger knows from each track whether it is merged or not and could just add the un-merged ones as well, right?
Probably a discussion to be had after some first performance plots are in.
There was a problem hiding this comment.
Fair point, but I am not sure whether just blindly adding all the un-merged tracks is what we wanna do. The first step might be adding all un-merged silicon tracks which are outside of the TPC's acceptance. If deciding which tracks to add becomes more involved, it might be out of place in a general track merging processor which should not be tailored specifically towards ILD@FCC.
I agree that this discussion, although very interesting, is better to have with some more detailed performance plots at hand.
2 participants
BEGINRELEASENOTES
TrackMerging_FCCee.pycliargtrackMergeto activate theTrackMergersHighLevelRecofor ILD@FCC-ee to truth link theClupatraandTrackMergertracks at the same timeClupatratracks are always refitted also when thetrackMergeflag is not providedtype edm4hep::ParticleIDCollectioncolls before writing output filesENDRELEASENOTES