kmcdermo
commented
7 years ago Closing this issue: from f2f, we decided that this is not really worth it. The only thing that happens if a simtrack gets to the max nHit indices to store, it will simply drop the hits at the end of the track.
For loopers, who cares.
For long tracks, we really only care about the start of the track anyway. The only downside to truncating the list of hits for such a track is that when going to match with a reco track, the reco track will have a slightly lower criterion to be matched (we place a very loose requirement on the reco track to have nHits >= minUniqueLayers on the simtrack).
Namely, the simtrack will have a slightly lower minUniqueLayers. So the reco track can be matched "easier", but as Slava said, this is a subpercent effect.
One issue I raised in #69 on L158 of Event.cc in that PR was about having more than one hit per layer when simulating a track when approaching an overlap region from a polygonal geometry with extended edges like CMS. Namely, one could have a sim track pass through an overlap region in the barrel (or endcap), like in CMSSW, in which the sim track will register a hit in the same layer index more than once, as seen here:
.
This really is only a problem for how we save the extra hit inside the hit index array inside the sim track. This hit will automatically be added to the global ev.layerHits, as will the simHitsInfo (as it is uniquely identified by the mcHitID index and ithLayerHit).
In reality, it isn't "really" a problem, since the second hit will be added like normal to the hit index array, and the respective counters get incremented. The problem is really making the hit index array large enough to account for overlaps.
Or we could consider creating an inherited Track class called SimTrack, which has a hit index array size much larger than the standard Track class, so as to not blow up the size of the reco tracks. It would be useful to signify "inner" and "outer" hits on the same layer (i.e. closer or further from the origin), through a bool inside simHitInfo or something. Or simply just replace the hit index array with a vector (as we had before).
A related problem is also simtrack seeds... if we simply just expanded the hit index array, it is quite possible that a sim track hits the same pixel layer twice and another one once, and since we use pixel triplets (at the moment), the sim track seed will just be two layers, instead of three. Algorithmically, this really isn't so much of a problem, even though we do proceed by loops over layers, as the track state will just be propagated to the first building layer. However, it might be best to "split" the seeds: i.e. have a seed for each overlap.
During reconstruction, this is also not really a problem, as all the hits explored by a track are considered, adding one hit per layer per candidate. This is also what is done in CMSSW -- when considering a propagated state near an overlap of a single layer, still only hit is added per layer. During the fitting/smoothing step, there are options to remove spurious hits and also add more hits, in which case it is possible to add a second hit from the same layer if you are at an overlap region.
And finally, for validation, this is not a problem, as again, the definition of efficiency is tied to the number of hits inside the reconstructed track that are matched to exactly one sim track.
Although we will never track loopers, it is a similar problem... how to add these hits to sim tracks in a sensical manner.
N.B. This excludes the transition, where a track could pass between a barrel layer and endcap disk very close by, which is distinct from this problem where the same layer index is used to identify two hits from the same sim track. This should be its own discussion.