Investigation on the alignment of the silicon tracking system Alain Bonissent Dominique Fouchez Andre Tilquin Atlas Alignment Metting 17/12/2002

Goal and Plan Converge to a feasability + methodology for this alignment chalenge within a year (our comittment on ATLAS) How : adapt the aleph experience/method to the atlas pixel detector alignment The context : Steven Haywood+Pawel Bruckman already implemented a prototype following aleph/slc method : join the group and share/use code and methods

Benefit from Aleph alignment method History : –LEP I :  2 computed with all tracks (overlaps + dimuons) and minimized a la « Minuit » (numerical derivatives) : slow and tricky convergence :1 million of events + 6 month of work.. And resultnot completly accurate ! –LEP II : A new method has been set up : the minimization is done quasi- analytically by computing first and second derivatives of  2. Few events + 3 days enough to get a correct result ! Monte Carlo including misalignment errors from the minimization agree well with the data.

Aleph Method Use gradient method and analytic solution for first and second derivatives of  2. Introduction of mechanical constraints. Result = A precision of alignment below intrinsic resolution of detector (see plot).

Intrinsic errors Alignment errors

New challenge with Atlas - Number of modules for the pixels = X 10 and number of tracks big  increase in memory size and cpu time Atlas method compare to Aleph one : investigation to find benefit from each method

Our approach : how to contribute to converge toward align working Study current atlas soft. Study matrix challenge. Study/compare atlas/aleph methods : find the best from both.

Study of current Atlas software Study of time consumming : the code is organized in three main parts –Loading the event from the ntuple + derivative computation –Building the big matrix including track, vertex refit –Solving the alignment parameter : inversion of the big matrix Checks with detailled profiler (on going work) for the two first part: – first result (excluding last big matrix inversion) : time spent mainly in elementary matrix operations : M(i,j) = x ( operations for 100 events) or V = M*N … Beginning of optimizing code : there is a scale protection, which my not be necessary : remove it : –improvement : execution time reduced by a factor 22.

Matrix inversion challenge Size –(8700x8700) pixel barrel, (10400x10400) pixel or (30000x30000) pixel+SCT Evaluation of different packages and different machines –Packages DSINV (cernlib). DPTORF,DPTORI and X04CAF (naglib). SPMINV (Millepede). A recursive home made routine based on Strassen study. –Machines 200 Mhz DEC alpha, 400 Mb memory 1.4 Ghz PIII, 2 Gb memory Quadri-pro DEC alpha 667 Mhz, 4.5 Gb memory Sun 200 Mhz 600 Mb memory

Matrix inversion challenge Results –Fastest (2x) = recursive method, but less accurate ( maximum precision in double precision = 10 7 / for other methods, the price to go to quadruple precision is too big for current machines). –Best (most powerful and robust) = SPMINV running on PIII. 8700x8700 is inverted in 5 hours with max uncertainty of x10400 is inverted in 9 hours with same uncertainty –Results after extrapolation : pixel = 8 hours, SCT = 2.6 days, pixels+SCT = 10 days in the future those number may be reduce by a factor 2 to 4. Conclusion : –It will be difficult to invert a whole atlas ID matrix. One solution may come from the use of specialized hardware (ex systems based on FPGA)

Atlas/Aleph comparison Both view at once are considered in Atlas –It was the case on aleph only for vertex constraint. It is certainly necessary for atlas due to pixel or stereo strips. Mutiple scattering: –It was the case on aleph only for vertex constraint. Not necessary for single tracks in Aleph due to small number of scattering planes and high momentum of selected tracks.

Atlas/Aleph comparison Multiple scattering : to fit or not to fit ? –Atlas : explicit computation of scattering angles, rather than non diagonal terms: track parameters dimension (and associated matrix) : 5  5+Nscat Effective residuals : N  2N-1 –Number of operation : With non diagonal matrices : Nmult = 84 N  3 With diagonal matrices : Nmult = 192 N  3  The non diagonal matrices lead to less operations

Atlas/Aleph comparison Linearization : elegant and universal solution opted by ATLAS. Is it safe and justified ? –For track parameters : safe because eq. Of helix is linear wrt track parameters. Probably still ok with non uniform B field. –For alignment parameters: non linearities come from rotations, but angle are supposed to be small. (100 microns  10-2 rad or a quadratic term of 1 micron). On aleph a solution was to iterate, but it is costly. It is necessary to compute derivative at current align point and maybe use higher order –For vertices : equations are not linear: the solution is to iterate and perform first order developement around vertex position. Useful to check with numerical derivative at this stage

Solving linear equations Analytical solution was adopted in Aleph for track paremeter or vertices –. It was computed for any number of hits on the track. We check that this method is not faster than the matrix approche used in Atlas method. The Atlas method is simpler. It should be possible to compute analytical solution for each given number of hits on a track and then gain w.r.t. Atlas current method.

Mechanical constraint Use in ALEPH method –It can help for memory size and cpu time reduction. Reduction of Number of degree of fredoom. –Achieved by defining a set of linear relationship between alignment parameters, satisfied by construction (i.d. distance between edges of two adjacent modules inside one stave) By projecting alignment eq. into orthogonal subspace and solve. Result projected back into full space Investigation with marseille meca experts : –Measurement between wafers of O(1micron) : allow reduction of N of DoF of 30% –with a stability of O(1micron) on 5 points: if measured by previous alignment can reduce NDoF by 5 for fast alignment

Conclusions First contact with the Atlas alignment software –Request : a full documentation of the code to share the developement : inside the code (1 comment per line or so..) and a write up. We can use a documentation tool like Doxigen. First investigation on cpu time: profiling and big matrix inversion –Still slow after few improvement : need more Aleph experience –Ideas around to improve existing Atlas method and implementation. –The code may be difficult to debug, even if it seems to converge to minimum  It should be useful to have an option with numerical derivatives