80 likes | 150 Views
Charged Kaons group Report. P. de Simone 25 September 2001. Outline: tools development to improve charged kaons reconstruction. Kaon candidates, ECLO bank. Selection last point of kaon track - first/last point of secondary particles : D R xy < 30 cm, D Z < 25 cm P < 40 MeV/c.
E N D
Charged Kaons group Report P. de Simone 25 September 2001 Outline: tools development to improve charged kaons reconstruction
Kaon candidates, ECLO bank Selection last point of kaon track - first/last point of secondary particles : DRxy < 30 cm, DZ < 25 cm P < 40 MeV/c If vertex - check ortogonality 80< = | - | 1 - 2|| < 1720 and |p1 - p2| > 40 MeV Create new DPRS, update DHRE, and perform new track fit Look for other pieces of tracks to merge Tracks merging procedure
Tracks merging procedure Old event Merged event Kaon track Kaon track Kaon track Kaon track
Vertex efficiency Without new merging procedure With new merging procedure Efficiency as a function of Rxy
Vertex efficiency Without new merging procedure With new merging procedure Efficiency as a function of Z
Why there are so many split tracks ? The following items are under study: 1) Multiple Scattering performances and optimization for charged kaons events. 2) Charged kaons timing. For well reconstructed simple topology (eg. K-> mn , K -> p0p+) use T0 step 1. Else use the distribution of the Drift Chamber hits. 3) Background effects on track reconstruction. First simulated background events added in DTCE banks.
Bhabha MC tprimi mean of the first 4 DCH times in the 30 ns window RMS = 6 ns window mean of DCH times in the 30 ns window =4.6 ns • work in progress on DATA: • calibration using K -> , 0 • comparison with bhabha, Ks-> +- T0 using Drift Chamber hits • least mean squared fit of the cumulative distribution of DCH time ordered hits gives the firstT0 guess • at least 100 DCH hits • define a 30 ns window around T0 guess
Machine background simulation • noisy hits in the Drift Chamber have been selected looking at gg events • SELGG module identifies those events and stores them on ascii files • different ascii files will take care of different data taking/machine background conditions • noisy hits are then superimposed to MonteCarlo physical events