# Presentation: 025531

## CSC Segment finding - update on ST

** **
**EMU meeting, UCLA, Feb. 07**
**CSC Segment finding - update on ST**

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

-  Motivation/Aim - recap
-  Comparison of ST / DF / TC on MTCC data
-  Comparison and studies on MC
-  Conclusions

## Motivation

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

-  Evidence for biases and moderate efficiency in the standard SK and TC
- 	algorithms were presented recently.
-  Current algorithms involve multiple fits - likely to be too slow for HLT usage
-  Decided to attempt a different segment finding approach which should:
- 	- remove the observed bias
- 	- have high efficiency and maintain purity
- 	- be faster than TC/SK
- 	- be prepared to deal with showers 		and backgrounds (e.g. neutrons)
- 	- be as simple and modular as possible

## Our approach

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

**Pre-cluster in xy**

**Find segments/patterns in xz**

**Optionally **
**Prune bad hits**

- See last week DPG meeting:
**Remark on pruning**: last week did not mention “brute forceƒ pruning:
- 						Refit all segments removing one hit after another.
- 						Some comparisons of pruning methods shown today.

**Fit best candidates only**

- http://indico.cern.ch/conferenceDisplay.py?confId=11836

## Strategy for this update:

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

- Last week at DPG introduced ST and compared mainly with TC.
- Were asked questions which made us start to address the following
- list during the last week:
- 	* Purity:
- 		- do we really find the correct segments
- 	  	- do we really prune away the correct hits
- 	* Understanding the code:
- 		- what happens with background
- 		- what goes on at very low P(chi2, ndf)
- 		- why the observed difference in direction TC / ST
- 	* Performance:
- 		- absolute gain in time
- 		- how does ST compare to DF

## Why TC / ST position difference in rare cases?

- Several different reasons found in “goodƒ events with hits on all layers:
- - TC misses one or more hits (chi2 cut)
- - ST misses one hit because very loose 	cut in y does not consider errors
- - ST can pick a curved segment in	some events with delta rays, 		TC the right one (optimize weight)
- - possible bug in ST when layer 1 and 2 	are empty and there are >2 rechits in layer 3
- => a possible ST bug found - will be fixed.
- => Further improvements based on understanding of these rare events

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

## ST / DF / TC Efficiency (data)

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

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

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

- before pruning

## ST / DF / TC #segments and #hits on segments (data)

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

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

- No pruning applied:
- 	ST and DF produce essentially the same number of 6-hit segments
- 	DF and TC produce more segments per chamber than ST
- 	DF and TC have more segments with lower number of hits

## ST / DF / TC Timing (data)

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

- Both ST and DF are faster than TC and SK (SK not shown).
- Surprise - though based on SK which is slower than ST, the DF algorithm is
- currently the fastest and does not show tails. Needs to be understood.
- We believe that ST still has a lot of potential to be sped up e.g. by code
- optimization. (Same might be true for DF :) )

- DF peak: 	1.5 ms
- ST peak:  	2.0 ms

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

## Comparison: ST / DF / TC

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

- Overall P(chi2, ndf) looks
- similar for the 3 algorithms.
- Difference in smallest bin:
- 	TC least low P entries
- 	ST somewhat more than TC
- 	DF has most entries at low P

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

## Comparison with MC truth

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

- Behaviour in core similar, tails differ.
-       Core dx RMS           Tail contribution
- TC     0.099                   ~ 4.5%
- ST      TC*1.02             ~ 4.6%
- DF      TC*1.10             ~ 8.4%

- Use single muon gun MC (E = 25 GeV)
- Plot distances between **reconstructed segments** and **muon simHit** on
- each layer:

**e simhits**

****** ****simhits**

## Comparison with MC truth

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

- Do we find the muon track stub? Compare TC / DF and ST:

- Local delta x/y between
- reco-segment and simulated
- muon hit (on each layer)

- Study on single  gun MC

- Behaviour in core similar, tails differ.
-       Core dx RMS           Tail contribution
- TC     0.099                   ~ 4.5%
- ST      TC*1.02             ~ 4.6%
- DF      TC*1.10             ~ 8.4%

- Core (0.75cm in x) RMS of x
- distribution  most narrow for TC.
- About 2% wider for ST and
-           10% wider for DF.

## Comparison with MC truth - x

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

- Local delta x/y between
- 	reco-segment and
- 	simulated muon hit:

- Main influence on the tails:
- Electron hit is on the segment,
- or segment is based on electron
- hits only.
- Sample contains many delta electrons, ~0.55 electron simhits per muon simhit

- Behaviour in core similar, tails differ.
-       Core dx RMS           Tail contribution
- TC     0.099                   ~ 4.5%
- ST      TC*1.02             ~ 4.6%
- DF      TC*1.10             ~ 8.4%

- Tail contribution:
- TC ~ 4.5%
- ST ~ 4.6%
- DF ~ 8.4%

- All algorithms show tails.
- TC/ST ~ 5%,
- DF       ~ 8%

- Comparison with MC truth - x

- Caveat: all segments entered
- 	- DF has more segments
- 	   per chamber

## Comparison with MC truth - x vs P(chi2, ndf)

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

- Forgot to plot - deltax vs chi2 - show that largest tails at low chi2!
- Show this here.
- Next slide: Tell about different low chi2 events, the 10 cases

- P(chi2, ndf)

- local x segment - x simhit (cm)

- However: Most large offsets at low
- P(chi2, ndf)
-  **Correlation between bad chi2 **
**	****and large tails!**

- Some events with larger offsets for proper P(chi2).
- Properly reconstructed
- delta rays.

- Comparison with MC truth - x vs P(chi2, ndf)

- local x segment - x simhit (cm)

- Need core to tail ratio for >0.1 and
- <0.005 - plot that

- local x segment - x simhit (cm)

- Tails:
- P(chi2) < 0.005:	28%
- P(chi2) > 0.1:     	2%

- Partially due to presence of e hits  (>10 e per layer, >20 rechits per chamber, some just line up)
- or just proper delta-ray fits.

## Low P(chi2, ndf) events - scan

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

- Forgot to plot - deltax vs chi2 - show that largest tails at low chi2!
- Show this here.
- Next slide: Tell about different low chi2 events, the 10 cases

- Some reasons for low P(chi2, ndf) (9 ST events):
- 	- tracked e+/e-, but also found a proper  segment (3/9)
- 	- e and  simhits are merged into one rechit, which makes
- 	  	the chi2 bad (3/9)
- 	- Finder combined e and  hits, but did not find “pureƒ 
- 		segment (2/9)
- 	- Finder tracked e but don't find  (event with very many
- 		sim and rechits, case to fix) (1/9)
- All events with bad chi2 involved e hits on the segment.
**Training ground for pruning method - will study further.**

- show “eventdisplays/comicsƒ
- rather than writing text!!!

- Illustrations:

- Re-find the evenjt with the 2 largest residuals being the muons not the e

- To find the hit with the largest residual would not always have
- “repairedƒ the segment.

## Comparison with MC truth

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

- Does pruning improve reco-true correlation / are we removing the right hits?
- ST before and after pruning:

**Pruning improves agreement**.
- - Std. prune reduces core RMS by 2%
- - Brute pruning (refit all hits and
-   drop worst) reduces core RMS by 6%

- Core gets slimmer, tails reduced:
-       Core dx RMS           Tail contribution
- ST          0.1                     ~ 4.5%
- ST stpr   *0.98                 ~ 4.2%
- ST brpr  *0.94                 ~ 3.6%

- Tail contribution:
- brute pruning 	~ 3.6%
- std. pruning 	~ 4.2%
- no pruning  	~ 4.5%

**Pruning** still needs to be optimized, but it is **changing the segments in the**
**right direction**.

- Local delta x/y between
- 	reco-segment and
- 	simulated muon hit

- Mark core, mark std pruning, brute pr, reexpain brute

- reduces tails by          7 or 20%

## Segment finding - Conclusion

-  Both DF and ST are
- 	- faster 	- less biased	 - more efficient	- more modular
-   than existing standard finders
-  Scrutinized individual events (data&MC) 	- to understand TC/ST differences	- begin to understand effects of additional hits from electrons
-  DF produces somewhat more segments 	- additional segment cleaning step needed?
-  Good to have two different finders for cross checks
-  future development:	- further speed improvements	- improvement of pruning	- improve MC comparison / further scrutinizing	- clean up code and make it available

## Backup slides follow!

**Backup slides follow!**

## Backup Plots

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

- with pruning

- with pruning

## Backup Plots

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

## Backup Plots

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

- hits TC - hits ST

## New Approach to CSC Segment Finding  

- Ingo Bloch & Eric James (Fermilab),
- Michael Schmitt & Stoyan Stoynev (Northwestern U.)
- February 1st, 2007
- CSC-DPG Meeting

## Motivation

- It’s important to settle on an approach for CSC segment finding as soon as possible.
- Several people have presented evidence that the current algorithm introduces potential biases (see following slides).
- In addition, the current algorithm which relies on numerous fit iterations most likely is not fast enough to be used in the HLT.

## Current Biases

**using maximum ********2**** = 60/d.o.f. cut**

******2****= 729/4 d.o.f.**

- Chi-Squared cut as implemented
- does not work properly

- Stan Durkin : CSC-DPG (1/25/07)

******2****= 16/5 d.o.f.**

**using no maximum ********2**** cut**

## Current Biases

- Stepping Bias versus Layer

- Stoyan Stoynev : CSC-DPG (1/25/07)

## Requirements

- Decided to consider a new approach
- Must remove bias in segment reconstruction
- Must have high efficiency for reconstructing segments with maximal number of hits
- Must produce accurate segments
- Must be faster for utilization in HLT
- Must be able to deal with showers and backgrounds (e.g. neutrons)
- Should be as simple as possible

## Our Approach

- Pre-cluster groups of hits within a chamber to reduce total number of hit combinations.
- Perform pure pattern recognition looking at all potential hit combinations.
- Fit only the best segments determined from the pattern recognition.
- Optionally, allow for trimming away bad hits (e.g. those originating from delta rays).
- Use a specialized approach for messy events.

## Current Status

- A first version of our algorithms has been coded within CMSSW.
- The algorithms are designed to be modular (e.g. the new pre-clustering algorithm can also be run in front of the current TC & SK).
- The preliminary results look promising (see talks from Stoyan and Ingo).
- We believe that the observed reduction in processing times can still be significantly improved with further code optimization.

## Next Steps

- Current studies indicate that our new approach has promise.
- Code not quite ready for release
- Hope for help from experts with testing
- Some features still to be added
- Need to polish and streamline algorithms
- Looking forward to receiving feedback and having more discussion at UCLA.

##           New segment finding ST algorithm        

- Ingo Bloch1
- Eric James1
- Michael Schmitt2
- Stoyan Stoynev2
*1**Fermilab *
*2**Northwestern University*

- 1 Feb 2007

- CSC-DPG meeting

## Outline 

-  Introduction
-  Conventions
-  The ST algorithm
-  Basic selection for the data
-   Efficiency of the ST and comparisons with TC
-  Other comparison plots
-  Timing of ST and comparisons with TC
-  Conclusions

## Introduction  

-  Current segment finding algorithms are based on “swimming” pattern recognition              routines (fitting at every step)
- we believe “swimming” introduces bias
- better look for methods which don't involve “swimming” and which walk through the complete set of layers
-  Possible approach is using the Minimum (Weight) Spanning Tree (MST) idea
- in general this is a graph that connects all the vertices and there is a weight             assigned  to each connection between two vertices (an edge)
- the weight of the graph (spanning tree) is assigned to that tree by summing all the    weights of the edges
- MST is the spanning tree with weight less than (or equal to) the weight of any     other spanning tree
-  The Spanning Tree (ST) algorithm described later is based on the MST idea
-  We expect and demand that the new ST algorithm should be fast and unbiased
- avoid CPU-expensive calculations such as 2, exp, sqrt, etc.

## Conventions

-  For hits in the six layers we denote:                 xi, zi; i=1,..,6 - co-ordinates                            ij – angle between hits i and j
-            (i=j-1; see plot)
-        ij ≡ xj- xi                             zij ≡ zj- zi
-                      tg(ij) = ij/zij

-  For six dots lying on a line we observe:
-  A ≡ (23-12) + (34-23) + (45-34) + (56-45) = 0
-                             and also
-  S ≡ sub123+ sub234+ sub345+ sub456=0 , where
-      subijk ≡ tg(jk) - tg(ij)
-  Then we could use this to find if 6 (rec)hits are           close to that condition. As zij is the same for any      two adjacent layers in a chamber we simplify             and construct the quantity:
-         W =  w123+ w234+ w345+ w456  , where
-         wijk = |jk -ij|

-  We call  wijk wights  and there are          various candidates for a weight              definition. We chose a simple and          effective one.
-  Smaller the W better the segment          candidate.

## The ST algorithm 

-  For all the possible combinations of rechits the weight W is constructed
- demand that there are no rechits in W from one and the same layer
- accept cases in which there is a missing hit in a layer
- all the weights in W (wijk) should be < 25 (cm) (it is a parameter)
- no more that 2 missing hits (it is a parameter) in the segment candidate
-  Compare weights W's for the segment candidates, choose a candidate(s)
- segments that do not have common hits are not compared (they are “preferred”)
- it is acceptable for segments to have 1 common hit (it is a parameter)
- segment with bigger number of hits is preferred to a segment with smaller number of hits (for segments with common hits)
- segment with smaller weight W is preferred (for segments with common hits and if equal number of hits in the candidates)
- preferred candidates are chosen for real segments
-  At the end at least one of the existing segment candidates is chosen and it always           includes the “best” one
-  By spending (a bit) more time the ST algorithm could choose all the candidates              fulfilling the conditions above (i.e. finding all the segments)

## Basic selection 

-  Selection for alignment  and efficiency studies used
- a (TC) segment in ME+2 with 6 hits required
- a specific requirement for the studies presented here that there are no more than 20 rechits in a chamber is made (ALL THE PLOTS EXCEPT TIMING AND EFFICIENCY ARE MADE AFTER THESE CONDITIONS; segment to segment comparisons require also exactly 1 segment in a chamber)
- a segment in  ME+2 is required to have 2/DOF<3
- a segment in  ME+3/2 is searched for
- segment efficiency is estimated (probability to include a rechit from a layer in a segment); please find details in my talk on 25.01.07/CSC-DPG meeting
-  Efficiency is estimated per layer in a segment (for ME+3/2/XX)
-   Timing is estimated/taken from the TimeModule in CMSSW and is for the                         CSCSegmentProducer (called once per event)
-  All the other plots are either per event or per chamber or per segment
-  Except for efficiency the other plots are based on 10000 events (from run 3792)
- in average there are ~3 stations (chambers) per event fired
- in average there is ~1 segment per chamber

## Efficiency of ST and TC 

-  It was shown that the        current segment finding     algorithms are biased*

- TC

- ST

-  Scales are different!

-   *SK results very similar to TC

## Segments and constructing hits of ST and TC 

-  Filled bars represent ST
-  Red lines represent TC

- Mean (ST): 1.011
- Mean(TC): 1.017

- Mean (ST): 5.909
- Mean(TC): 5.817

## Differences in segment co-ordinates 

## Differences in segment directions 

## Timing and comparisons with TC

## Time difference vs. multiplicity 

-  ST is faster

-  TC is faster

## Conclusions

-  The ST algorithm is less biased that the existing ones
-  It reproduces the main segment characteristics of the current segment finding      algorithms (still there are long tails)
-  ST timing is better (in >85-90%) than TC
-  Statement: ST could be easily optimized more!
-  ST fails (for now) for chambers with high multiplicity of rechits (follow up – pre-   clustering in Ingo's talk)

## 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 - 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.