M. Kuhn, P. Hopchev, M. Ferro-Luzzi BGV Vertex Resolution First Analysis Toy Monte Carlo Simulations Fast Vertex Fitting Algorithm M. Kuhn, P. Hopchev, M. Ferro-Luzzi

Motivation Analysis of vertex resolution with simulated beam-gas interactions in model detector Accuracy of measured beam size smeas limited by vertex resolution First estimation of vertex resolution svtx To determine precisely real beam size sbeam To minimize systematic uncertainty: But more important is the precise knowledge of svtx! Vertex resolution needs to be studies as Function of z-position in the vertices Function of number of tracks in the vertex

Introduction Input: original vertex and detector volume Toy Monte Carlo simulation of propagated tracks through detector material Reconstruction of original vertex LHCb fast vertex fitting algorithm Comparison of original and reconstructed vertex BGV vertex resolution As function of number of tracks As function of z-position …

Input Original vertex Detector volume Generated with HIJING (in the LHCb simulation application GAUSS) Neon target Flat distribution of events in z-range [-500;500] mm Each event contains a single beam-gas interaction Detector volume 4 sensitive planes (2 detector modules at z = 1591 mm and z = 2611 mm) x and y spatial resolution = 72 mm (Gaussian smeared) one module = 1.6 % of radiation length exit window thickness is constant with r and corresponds to x/X0 = 1.5 % We used the HIJING generator available in the simulation application (GAUSS) of LHCb. This is what "hi" is for (it could be pythia for example). The "10" in the filename indicates the Z of the target gas, so Neon, which we plan to inject in practice. The last number in the filename is the beam energy. There are different possibilities to specify the longitudinal distribution of the vertices in the simulation. In the ".dat" files above the events have a flat distribution in the range [-500;500] mm. The pressure is not an input parameter, we specify that each "event" contains a single beam-gas interaction (alternatively, we could generate Poisson). The "sensitive planes" represent the detector modules at a specific z. In the geometry description file, the "first" plane is at z = 1591 mm, and the "second" is at z = 2611 mm. The distance between them is the "lever arm" which determines the "extrapolation error". For more details, you can use the "boolDrawDetector" switch in bgv.py and also look at the contents of the detector description file. Spatial resolution = Gaussian smeared

Toy Monte Carlo Simulation Algorithm Track propagation (multiple scattering in traversed material) Smearing of measured points with detector resolution Track and vertex fitting Example: one event with 8 tracks (7 TeV) Simulated 8000 events with a total of 277,383 tracks (more events = more tracks), of which 5581 events are treated for MC simulation Average fraction of accepted and fitted tracks: 0.23 The ToyMC is completely standalone, no LHCb SW involved. The "algorithm" consists of several parts: track propagation, taking into account the multiple scattering in the traversed material, smearing of the measured points with the detector resolution, track fitting, vertex fitting. Expected number of good events: 6891 of 8000 = 0.86 Observed number of good events: 5581 of 8000 = 0.70 This is the average number of generated tracks compared with the average fraction of accepted and fitted tracks (look up in python script) Defined by detector layout

LHCb Fast Vertex Fitting Algorithm Calculate the distance between primary and secondary vertex Assuming a linear interpolation For each track i the equations are xi(z) = x0i + mxi z x0i and y0i are coordinates at z = 0 yi(z) = y0i + myi z mx,y are slopes in x-z and y-z plane Coordinates of the best fitted vertex (vx, vy, vz) are found by minimizing the c2 function (no uncertainties of the track on z-position) sxi and syi are obtained from the track covariance matrix LHCb 2005-013

Vertex Reconstruction Comparison of primary and reconstructed vertex Calculate residuals: primary vertex – reconstructed vertex Fit with Gauss function: s = Vertex Resolution Goal: minimize s and m Primary vertex from MC simulation Resolution should be energy independent At 450 GeV injection energy the distribution of residuals is wider consider not fitting the tails Also less events with high number of tracks for lower energies! not enough statistics for good fit

Vertex Resolution vs. Number of Tracks (I) Procedure: Plot vertex resolution according to #tracks per vertex Fit with 3 parameter Gauss function to obtain the resolution s per #tracks Example:

Vertex Resolution vs. Number of Tracks (II) Spread of m and error increases with more #tracks Resolution improves with more #tracks, but larger errors due to less statistics!

Vertex Resolution vs. Number of Tracks (III) Resolution in all 3 planes improves with large #tracks But fitting is impossible at ~ 20 tracks/vertex!!! Need more statistics (larger number of events) Need to define indication for bad fits to discard them For fitting bin the number of tracks Expected transverse beam sizes in the LHC: sx,y ~ 600 mm at 450 GeV for enorm = 1 mm & b = 170 m Expected transverse beam sizes in the LHC: sx,y ~ 180 mm at 7 TeV for enorm = 1.5 mm & b = 170 m

Vertex Resolution vs. Number of Tracks (IV) Binning of residuals and number of tracks in intervals of [5 ; 8], [9 ; 12], [13 ; 16], [17 ; 20], [ > 20] #tracks Fit with 3 parameter Gauss function to obtain the resolution s per track bin Expected transverse beam sizes in the LHC: sx,y ~ 180 mm at 7 TeV for enorm = 1.5 mm & b = 170 m 5 | 8 | 12 | 16 | 19 |>20 #tracks

Distribution of Vertex z-Position Distribution of original z-position as function of #tracks Distribution of reconstructed z-position as function of #tracks very similar Binning of z-positions in 200 mm intervals bin 0| bin 1| bin 2| bin 3| bin 4

Vertex Resolution vs z-Position (I) Procedure: Bin and plot vertex resolution according to z-position per vertex Fit with 3 parameter Gauss function to obtain the resolution s per interval of z- positions

Vertex Resolution vs. z-Position (II) Transverse planes: vertex resolution varies only slightly Very small dependency on z-position for x and y resolution Longitudinal plane: vertex resolution depends on z-position Best resolution for z > 100 mm -500|-300|-100|100|300|500 z [mm]

Summary Exponential decrease of resolution in all planes Accuracy of measured beam size limited by vertex resolution Therefore vertex resolution needs to be determined very precisely Analysis of vertex resolution via simulated beam-gas interaction Tracking with toy Monte Carlo simulation LHCb Fast Vertex Fitting Algorithm Vertex Resolution of model detector As function of number of tracks: Exponential decrease of resolution in all planes Best resolution for high number of tracks As function of original z-position: Best resolution for z > 100 mm (Interaction point closest to detector modules)

To Do List Vertex resolution for variable window thickness Vertex resolution as function of beam pipe radius To investigate if reduction of aperture is needed Deconvolve the vertex resolution and determine the true beam size Test vertex fitting algorithm in ROOT Improve vertex fitting algorithm (assuming 0.4 GeV/c transverse momentum and knowledge of material distribution to make Kalman filter) On the TO DO (future, medium-term ?): implement a better vtx algorithm that uses assumption of 0.4 GeV/c transverse momentum (which is a mean) and knowledge of material distribution to make a sort of Kalman filter (should improve vtx resolution ? to be studied...). Here we will have to weigh resolution vs timing performance... The Kalman filter, also known as linear quadratic estimation (LQE), is an algorithm that uses a series of measurements observed over time, containing noise (random variations) and other inaccuracies, and produces estimates of unknown variables that tend to be more precise than those based on a single measurement alone. More formally, the Kalman filter operates recursively on streams of noisy input data to produce a statistically optimal estimate of the underlying system state.