# Presentation: 009402

## CSC Segment finding - part III

** **
**CSC DPG meeting Feb. 1****st**** 07**
**CSC Segment finding - part III**

- S. Stoynev1, M. Schmitt1,
- E. James2, _I. Bloch_2
- 1 - Northwestern University
- 2 - Fermilab

-  Finding pre-clusters
-  Optional segment pruning
-  Compare ST with TC
-  Conclusions

## Pre-clustering in the chamber plane (xy)

**Aim:**
**Avoid considering clearly separated hits** when building segments
- Build (rough & fast) local xy-groups of separated
- 	hits and calculate xy-mean and xy-size of groups.
- Do **segment finding on** these **smaller groups**
- or optionally special treatment when group is too large 	(use e.g. only use group mean x and y then)
- 	**Requirements:**
- 		**fast**:
- 			avoid CPU intensive calculations e.g. sqrt
- 			stop loops as early as possible
- 		**robust**:
- 			independent of sorting of hits
- 			rather group up too many hits than split hits off a segment
- 	xy coordinates should be fine, as one is clustering roughly only.

## Pre-clustering - Method

- 1

- 6

- 4

- 3

- 2

- 5

- Implemented as loop over hits:
- 	if 2 hits/boxes closer than x < 4cm & y < 8cm (current cuts - can be optimized)
- 	=> add&replace, 	calc. running mean 	and
- 		open new box defined by hits min/max X and min/max Y:

-  Accumulate hits that are close in x and y
-  Define a larger box based on the merged hits
-  Again merge new box with close hits or boxes.

## Pre-clustering - Method

- 1

- 6

**4**

- 3

- 2

- 5

- Accumulate hits into boxes - measure distance between boxes in x and y, add close
- boxes:

## Pre-clustering - Method

- 6

- 3

- 2

**5**

- 1

**4**

- Accumulate hits into boxes - measure distance between boxes in x and y, add close
- boxes:

## Pre-clustering - Method

**6**

- 3

- 1

**4**

- 2

**5**

- Accumulate hits into boxes - measure distance between boxes in x and y, add close
- boxes:

## Pre-clustering - Method

**6**

- 3

- 1

- 4

- 2

**5**

- Accumulate hits into boxes - measure distance between boxes in x and y, add close
- boxes:

## Pre-clustering - Constructed event:

- As “training groundƒ overlaid 10 difficult MTCC events:

## Pre-clustering - Constructed event:

- This is what is clustered up.
- 		Two overlapping segments stubs get merged:

- The cluster step merges up close hits as desired.

- Should we add also
- a demonstration, how
- the segment finder
- finds the original
- segments back??
- Fun thing...
- if we have the time...

## Pre-clustering - Performance

- Timing? w / w/o clustering? For ST from Stoyan - I could provide TC
- comparison

- as proof that no splitting occurs, show Stoyan's efficency! - mention here, show later?

-  **Clustering does not lead to fake**
**	****splitting:**

- Efficiency to place a hit present on the given layer onto the segment:

- Benefits of pre-clustering step:
- fast, as explicit distance calculation between all hits are avoided
- could be used to throw exceptions on messy events (more than N
- 		hits in small box)
- may be useful for trigger as rough estimate of x and y of a segment?
- improves speed of standard segment finders by ~10%
- reduces time for large multiplicity events in ST

## Pre-clustering - Performance

- Timing? w / w/o clustering? For ST from Stoyan - I could provide TC
- comparison

- Clustering speeds up other
- finders too:
- 	TC (MC) with clustering:
- 	~10% faster
-          up to 3x faster in tails

- as proof that no splitting occurs, show Stoyan's efficency! - mention here, show later?

- Benefits of pre-clustering step:
- fast, as explicit distance calculation between all hits are avoided
- could be used to throw exceptions on messy events (more than X
- 		hits in small box)
- may be useful for trigger as rough estimate of x and y of a segment?
**improves speed of standard segment finders by ~10%**
- reduces time for large multiplicity events in ST:

- with clus.
- faster

- with clus.
- slower

## Pre-clustering - Performance

- Timing? w / w/o clustering? For ST from Stoyan - I could provide TC
- comparison

- Benefits of pre-clustering step:
- fast, as explicit distance calculation between all hits are avoided
- could be used to throw exceptions on messy events (more than X
- 		hits in small box)
- may be useful for trigger as rough estimate of x and y of a segment?
- improves speed of standard segment finders by ~10%
**reduces time for large multiplicity events in ST**:

- as proof that no splitting occurs, show Stoyan's efficency! - mention here, show later?

- Time difference: TC - ST
- before clustering:
- 	  ST slows down at larger
- 		multiplicities

-        TC faster

- ST faster

## Pre-clustering - Performance

- Timing? w / w/o clustering? For ST from Stoyan - I could provide TC
- comparison

- as proof that no splitting occurs, show Stoyan's efficency! - mention here, show later?

- Time difference TC - ST
- after clustering:
- 	  ST slow-down is reduced
- 		(further improvements
- 		foreseen inside ST)

- Benefits of pre-clustering step:
- fast, as explicit distance calculation between all hits are avoided
- could be used to throw exceptions on messy events (more than X
- 		hits in small box)
- may be useful for trigger as rough estimate of x and y of a segment?
- improves speed of standard segment finders by ~10%
**reduces time for large multiplicity events in ST**:

-        TC faster

- ST faster

## Segment pruning

**In pattern recognition step**: find largest number of hits “on a lineƒ.
- 	Find the pattern, don't try to eliminate outlier hits.
**Separate step**** - Pruning:**** try to remove spurious hit:**
- Current strategy (needs to be fast!, want to avoid biasing):
- Only for “bad segmentsƒ   currently P(2,ndf) < 10-4
- Determine one (just one) “worst hitƒ (modular):
- hit with largest normalized “x - residualƒ if 1.5 times larger than the 2nd worst	(minimum implicit significance >7 sigma)
- Redo fit and replace orig. n-hit segment with (n-1)-hit segment if resulting			P(n-1) > 1000*P(n)		and 	P(n-1) > 10-10
- Should be expanded to also include e.g. charge, y(?), ...

- show effi before and after (overlaid)
- show chi2 before and after

- OUT!!! Alternative cross check method: refit all n-1 combinations and select subsegment with highest P(chi2, ndf) (just as a cross check!)

- Just pattern, not trying to remove outlier hits!

- Prefer large number of hits over perfect line - not trying to remove “worst hitƒ

## Segment pruning - ST segment efficiency (data)

- show effi before and after (overlaid)
- show chi2 before and after

- OUT!!! Alternative cross check method: refit all n-1 combinations and select subsegment with highest P(chi2, ndf) (just as a cross check!)

- ST after pruning:
- Removal of spurious hits
- keeps segment efficiency
- at ~ 99%

- ST before pruning

- Efficiency to place a hit
- present on the given layer
- onto the segment.

## P(Chi2, ndf ) here

- show effi before and after (overlaid)
- show chi2 before and after

- OUT!!! Alternative cross check method: refit all n-1 combinations and select subsegment with highest P(chi2, ndf) (just as a cross check!)

- Removal of spurious hits reduces
- segments with very low probability.
- Still too many entries at low probability
- - same picture for other finders
- 	 need to investigate

**P(Chi2, ndf ) here**

**P(Chi2, ndf ) here**

- blue solid: ST before pruning
- red dashed: ST after pruning

- ST before pruning

## Segment chi2 probability: TC and ST on data/MC

- show effi before and after (overlaid)
- show chi2 before and after

- OUT!!! Alternative cross check method: refit all n-1 combinations and select subsegment with highest P(chi2, ndf) (just as a cross check!)

- Both data and MC show enhancement at low P(2,ndf). Peak at 1 missing in MC.

- ST and TC:
- Similar P(2, ndf)
- distributions.

## Segment finding - Efficiency TC / ST (data)

** ****ST algorithm**
** ****TC algorithm**

- Efficiency to place
- a hit present on the
- given layer onto the
- segment.
- Both with clustering
- and pruning.

- The behaviour for both ST and TC is similarly flat.
- ST yields globally higher efficiency than TC.

## Segment finding - Conclusion

-  New package:
- 	- faster 	- less biased	 - more efficient	- more modular
- than existing finders.
-  Segment finding is done as pattern recognition
- 	- avoiding biases by swimming
-   Clustering and pruning step can also be used for other finders
- 	- just plug in your favourite finder.
-  Actual code not yet releasable
- 	- want some people to help testing it
- 	- we still foresee some improvements in the code
-  Plan to have it finished in about 1-2 months
-  We look forward to discussing this further, at UCLA