Layer processing v2

[osschar]

Changes in ModuleInfo / Hit / LayerOfHits

1. Add half_length member to ModuleInfo, fill it in MkFitGeometryESProducer.cc
2. Extend HitInfo with half-strip-length, add qbar (the other of r/z variables). Store fast-access arrays as std::vector.

Initially, the idea was that strip half-length from ModuleInfo would be filled into the fast-access structure HitInfo. Then I realized that for strips the same thing can be obtained as sqrt(12 * (exx + eyy)/2 (for endcaps) and `sqrt(12 * ezz)/2 (for barrel). This is now used while filling up the hits.

We still need to think which is better and what this means for pixel detectors (and, if the calculation of clusters "long" direction should be different there).

Changes in MkFinder::selectHitIndicies()

1. When local bool NEW_SELECTION is set, propagate parameters (not errors) of the candidate to the hit position and re-calculate dphi and dq values at the hit position. Select int NEW_MAX_HIT (tried 4 and 6) hits with best dphi for further processing.

2. Add additional ROOT-text-tree ntuples dumps (like used for the hit-window tuning):

   • per considered hit information;
   • per candidate in a layer information.

3. This is to provide us with data for understanding of possible performance and tuning of the above algorithm.

Further explorations to be done

1. Try simpler propagate-to-hit schemas (linear, quadratic/cubic Taylor).

2. Study how to replace current windows. As a fist approximation, propagate to the beginning and the end of the current layer and use these points (+ some simple delta) to calculate phi and q variable ranges for iteration over bins in LayerOfHits.
   These beg/end points / momentum vectors could also be used as a basis for simpler propagation above.

3. Study dq and dphi windows to apply to individual hits. For now the original (old) windows are still used. Especially relevant for q as we are going to limit the number of hits that pass the phi cuts anyway.
   Make N_max_hits iteration dependent (or use a number calculated from N_max_cands).

4. Investigate stereo layers and usage of ModuleInfo position, direction vectors for calculating the track-to-hit distance (this could even replace phi). We might need additional fan-out angle parameter for endcap modules.

Plans for later / follow-up

1. Multi-step layer (+ optionally the matching stereo layer) processing to properly pick-up overlap hits and to properly score candidates. Name 'thin-layers' was used for this.
   Requires some intermediate (simplified?) Candidate storage (as we might have to go beyon N-max-cands not to penalize tracks that only pick up hits at the back of the layer) and a local scoring function.

Side issues

1. In initialStep low-pt cands (< 0.5 GeV) seem to be picking up way more bad hits, especially in the barrel -- i.e. true hit dphi does not have rank 1. or 2. as is the case almost everywhere else.
   There is some indication that pT of seeds is lower than pT of sim tracks. Slava warns that this might just be due to the energy loss in the 4 seed layers.
   Find the source, can it be offset somehow? Consider separate low-pT processing / finding parameters?

[leonardogiannini]

Comparison for default configuration (4+1 mkFit iterations)
http://uaf-10.t2.ucsd.edu/~legianni/plots_PR129

to add low pT and pixelLess iterations comparisons

[slava77]

Comparison for default configuration (4+1 mkFit iterations)
http://uaf-10.t2.ucsd.edu/~legianni/plots_PR129

detached quad and triplet have some inefficiency at low pt

[leonardogiannini]

I'm adding the plots where I compare pure CKF (blue) to mkFit for one iteration (red) to mkFIt + PR129 for one iteration

PixelLess-PR129-plots/
LowPtT-PR129-plots/
LowPtQ-PR129-plots/

I updated the links. there is still some discrepancy in the post selection tracks (due to cross cleaning?),
but now the seeds are identical up to the iteration of interest.

[slava77]

I'm adding the plots where I compare pure CKF (blue) to mkFit for one iteration (red) to mkFIt + PR129 for one iteration

PixelLess-PR129-plots/ LowPtT-PR129-plots/ LowPtQ-PR129-plots/

I updated the links. there is still some discrepancy in the post selection tracks (due to cross cleaning?), but now the seeds are identical up to the iteration of interest.

pixelLess is improving (left) while lowPtQuad (right) gets slightly worse

The improvement for the pixelLess is expected. From debugging in the past maxhit of 16 was inefficient and this update narrows down to hit selection more appropriately.

The number of strip hits in lowPtQuad is up, perhaps the efficiency loss is actually a classification migration (the track is there but we pick up wrong hits).

[leonardogiannini]

I'm adding here the MTV plots with the latest commit (red is the former version as of Sept 21 and black is the most recent), comparing the to the standard mkFit (blue) for the usual 4+1 iterations

http://uaf-10.t2.ucsd.edu/~legianni/plots_compare_layerProcv2_octoberVersion/

[leonardogiannini]

this is the MTV comparison after switching off the new layer processing. (code-format commit not included)
http://uaf-10.t2.ucsd.edu/~legianni/plots_compare_layerProcv2_PRVersion/

it looks like the PR is good for CMSSW

[srlantz]

If I'm not mistaken, the commits in this PR's layer-processing-v2 branch were squashed and rebased in a new branch, layer-processing-v2-rb1, which became the source for a PR to cmssw itself, cms-sw#43145 ...yes, this is confirmed by @osschar

[srlantz]

Pretty sure there's a typo here? Seems like it should be return t.sqr(a);

[osschar]

Thank you Steve, I added this change into prop-to-plane PR, cms-sw#43146, commit ab89b2f

[osschar]

The CMSSW PR cms-sw#43145 has been merged and should be picked up by master resync ... this one is out of sync -- closing.