Status of D + analysis: Vertex reconstruction and event production Francesco Prino INFN Torino People working on D + analysis: Torino: M.Masera, F.Prino, E.Bruna Bari: G.Bruno, D.Elia PWG 3 meeting, Cern 30/05/05
Outline Study of the exclusive decay D + → K - π + π + Physics motivation Simulation strategy Signal and background production Present status of the GRID production Reconstruction of the secondary vertex in the ITS Comparison of different algorithms of vertex finding Future plans
Physics motivation exclusive reconstruction of D ±GOAL: exclusive reconstruction of D ± in the ALICE barrel ITS used in the reconstruction of the secondary vertex Probe the medium created in the collision with heavy quarks Initial state effects (nuclear shadowing) Final state effects (radiative energy loss) Reference for the study of quarkonia production Charm elliptic flow This measurement can: Tell to what degree charm interacts and thermalize Validate quark coalescence models Constrain dynamical scenarios To be studied in semi-central events Need to know: p T and of charmed meson full reconstruction of decay products
Simulation strategy signalGenerate signal events with only D ± decaying in K : Check the kinematics (done) Optimize the vertexing algorithm ( in progress ) backgroundGenerate background events with HIJING Add some charmed mesons in order to reproduce the charm yield predicted by MNR calculations ≈ 170 mesons to be added per event Evaluate the combinatorial background Tune the cuts for analysis: On the tracks used to “feed” the vertexer (p T, impact parameter) On the quality of the secondary vertex (DCA, pointing angle)
Signal production PYTHIA simulation: D + forced to decay in K - + + D + decays: both resonant via K 0 * (892) and non-resonant PYTHIA tuning: NLO from MNR calculations and CTEQ4L PDFs s 1/2 = 5.5 TeV Magnetic Field = 0.5 T 1 st, 2 nd simulation tests on the Torino Farm (Feb. 2005) v4-01-Rev05 AliRoot version: v4-01-Rev05 (the one used in the last Data Challenge) (→ problems with merging for the background production: see following slides) 3 rd simulation test on the Torino Farm (Apr. 2005) v4-02-Rev00 AliRoot version: v4-02-Rev D + → K - + + per event, in the rapidity range |y|<2 leading to a charged multiplicity dN/dy ~ of such signal events produced in Torino’s farm for preliminary studies. Goal: to have 5K signal events with an amount of D → K corresponding to 6X10 7 central Pb-Pb events
Kinematics: p T distributions Plots refer to generated quantities and from D + non-resonant decay HIJING central (normalized) Mean = 0.67 Mean = 0.50 p T (GeV/c) Mean = 0.87 Mean = 0.65 p T (GeV/c) Pions and kaons from D+ decay vs. Pions and Kaons in Hijing central event
Kinematics: Dalitz plots From reconstructed tracks ( : the info given by the generation are taken into account) Non resonant Resonant This is done as an internal cross-check procedure
Background production Old strategy Use central Pb-Pb events from Data Challenge 04 AliRoot v4-01-Rev05 Add to each event 170 charmed mesons HIJING does not reproduce the predicted amount of charm Status of art at the last Alice Week One Hijing event from PDC04 downloaded Technical problems (not solved) with merging Less ESD tracks in the merged event (with additional charm) than in the HIJING event New strategy Use the last AliRoot tagged version (v4-02-Rev00) Generate new background events Switch off charm (and beauty) generation in Hijing COCKTAIL: Hijing cent1 (without charm and beauty)+PYTHIA (230 charmed mesons + 9 beauty mesons) GOAL: produce 20k of such events on the GRID
Tool used for the production GRID production gLite Resource Broker + LCG2 LCG (LFC) file catalogue Running on italian sites (CNAF, Torino, Bari, LNL) Generate 5K signal events and 20K background events Files stored (at CNAF) for each event: galice. root AliESDs. root Kinematics. root TrackRefs. root ITS.RecPoints. root < 2 GB per event Total Disk space ≈ 6TB Steps: 1.Install AliRoot on the sites (done, but…) 2.Test grid submission and data retrieval with short jobs (done) 3.Submit 5K signal events (in progress) STATISTICS: ≈1000 jobs submitted (27/5 morning) Done (success) 661 (=68%) Aborted 72 (=8%) (gLite communication problems) Done with error230 (28%) (143 NFS crash, 55 disk space, 28 Aliroot crash) 4.Submit 20K background events Problem with Hijing central events under Scientific Linux (to be solved)
Search for the secondary vertex AliITSVertexerTracks.h,.cxx Based on the class AliITSVertexerTracks.h,.cxx (primary vertex finding and fitting algorithm in p-p) Main steps: 1. AliESD* event (requirement) 2.An object AliITSVertexerTracks is created 3.The method FindVertexForCurrentEvent is called 4.The object AliESDVertex is ready Ntrks > Min FITTER NUsedTrks < Min PrepareTracks Ntrks < Min FINDER NUsedTrks > Min VERTEX is correctly found All these steps work also for the secondary vertex, passing 3 tracks and the AliESD* event as input
Testing the vertexer AliITSVertexerTracks applied on a Hijing Pb-Pb central event to find the primary vertex Sets of 10 reconstructed tracks are passed to the vertexer Compare the result of the finder (1st step) with the known MC primary vertex Compare the result of the fitter (2nd step) with the known MC primary vertex
Testing the vertexer: results X (Finder) – X (MC) Z (Finder) – Z (MC) Y (Finder) – Y (MC) FINDER X (Finder+Fitter) – X (MC) Z (Finder+Fitter) – Z (MC) Y (Finder+Fitter) – Y (MC) Mean = -0.8 μm RMS = μm Mean = 5.2 μm RMS = 118 μm Mean = 1.4 μm RMS = μm Mean = -5.8 μm RMS = 63.2 μm Mean = 5.5 μm RMS = 64.4 μm Mean = 2.8 μm RMS = 83.1 μm FINDER + FITTER
Testing the vertexer: finder vs. fitter Globally FITTER+FINDER has better resolution than FINDER alone Finder better than fitter X (Finder) – X (MC) Fitter better than finder X (Finder) – X (MC) X (Finder+Fitter) – X (MC) The FITTER is not goodThe FITTER is good … but in ~30% of the cases the FITTER worsens the result of the finder
Additional checks on the fitter The FITTER was “fed” with an external starting guess for the vertex position (instead of using the FINDER) If the input position is within ~100 μm from the MC vertex the RMS of the residual distribution is always ~60 m (80 m for Z), even when the position coincides with the MC vertex Is there room to improve the fitter? If the input position is far from the MC vertex (~500 μm ) the residual distribution broadens In the real algorithm, when the FINDER misses the true vertex position by more than ~ m, the FITTER is also affected Improve the finder (see next slides)
Old vertex finder Based on the Straight Line Approximation (SLA) of a track (helix) Developed to find the primary vertex in p-p Main steps 1.The method receives N tracks as input 2.Each track is aproximated by a straight line in the vicinity of the primary vertex 3.An estimation of the secondary vertex from each pair of tracks is obtained evaluating the crossing point between the 2 straght lines The method AliITSStrLine::Cross is used 4.The coordinates of secondary vertex are determined averaging among all the track pairs:
New vertex finder Based on the Distance of Closest Aprroach (DCA) between helices Does not use a Straight Line Approximation (SLA) as the old one Main steps 1.The method receives N (N=3 in our case) tracks as input 2.For each pair of tracks, the coordinates of the 2 points of closest approach are calculated The method AliITStrackV2::PropagateToDCA() is used 3.An estimation of the secondary vertex from each pair of tracks is obtained averaging the coordinates of the points defining the DCA Two different implemetations: arithmetic vs. wieghted mean The weighted mean is implemented in the same way as for the V0 in AliV0Vertex class 4.The coordinates of secondary vertex are determined averaging among all the track pairs:
Compare different finders (I) FINDER (SLA) - MC FINDER (DCA+w.mean) - MC FINDER (DCA) - MC X coord Y coord Z coord RMS=179 μm RMS=167 μm RMS=165 μm RMS=182 μm RMS=160 μmRMS=170 μm RMS=165 μmRMS=152 μmRMS=169 μm
Compare different finders (II) RMS (x coordinate) vs. max. DCA of the 3 tracks RMS (x coordinate) vs. minimum p T of the 3 tracks Finder (SLA) Finder (DCA) The other coordinates show the same behaviour RMS X (μm) DCA max (μm) Pt min (GeV/c) RMS X (μm)
Compare different finders (III) RMS X (μm) decay l.(μm) RMS X (μm) Finder (SLA) Finder (DCA) RMS (x coordinate) vs. decay length of D meson RMS (x coordinate) vs. p T of D meson The other coordinates show the same behaviour
Pointing angle Pointing angle = angle between the reconstructed p of the D + meson and the segment connecting primary to secondary vertex Cos( point ) should be 1, but suffers from p T and vertex resolution
Is there room to improve the finder? Introduce a weighted mean when averaging between the vertices found from eack pair of tracks 1st guess: weight each pair of tracks by 1/DCA IDEA: the larger the DCA of the 2 considered tracks, the worse the vertex definition RMS=173 μm RMS=174 μm RMS=182 μm RMS are larger than the one obtained without the weights No real improvement obtained introducing a further weight
Comparing the different Finders Main differences between the original Finder (SLA) of AliITSVertexerTracks and the new Finders (DCA) In the SLA algorithm: Track parameters calculated by prolonging the tracks to the primary vertex Straight Line Approximation (SLA) of the tracks on the distance between the primary and the secondary (D→K π π) vertex (c = m ) In the DCA algorithm Cut on the maximum DCA (set at 1.5 mm) of a pair of tracks to be used in the vertex determination.
Straight line approximation Geometrical calculations x y D K X’ y’ C View on the transverse plane P T K(GeV/c) d (μm) Decay dist (μm) d (μm) d is of the order of tens of nm the SLA does not give rise to syst effects d d (μm) is the distance between the secondary vertex and the tangent line
Resolution of the different Finders With the DCA (new) Finders the residual distribution is ≈10 m narrower with respect to the old (SLA) Finder Better performance of the new algorithm The resolution is further improved (especially for the Z coordinate) if the average between 2 tracks is weighted with the Sigma of the track Try to add a weighted mean also in the SLA (old) Finder The introduction of a futher weight when averaging the vertices of the different pairs of tracks does not seem to help The different performance of te Finders does not come from the Straight Line Approximation, but rather from different preselection of track pairs The cut on the maximum DCA for a pair od tracks to be accepted must be studied and tuned As expected, the RMS of the residual distribution: Decreases when the minimum p T of the 3 tracks increases Increases when the maximum of the DCA between track pairs increases
Summary and future plans gLite production The setup of the grid tools has been completed The production of the 5K signal events started (662 good events already obtained) Reconstruction problems with AliRoot v4-02-Rev00 to be fixed before starting the production of the 20K background events Start tuning the D + analysis cuts as soon as production events will be ready Secondary Vertex A new Vertex Finder algorithm has been tested on 200 signal events Small improvement (≈10-15 m) with respect to the standard one Additional tests on the Finder to be done Use AliGenBox to generate pions originating from the surface of a sphere and study the performance of the Finder as a function of the radius of the sphere and the p T of the pions Investigate on the Fitter
Hadronic 3 charged-bodies decays of D + D + K - + + BR = 9.2 % N.B. The sum of these BRs is greater than 9.2% due to quantistic interference phenomena D ± I(J P ) = ½ (0 - ) m = MeV/c 2 c = m (PDG ’04) Non resonantD + →K - + + BR = 8.8 % Resonant D + →K *0 (892) + →K - + + BR = 1.3 % D + →K *0 (1430) + →K - + + BR = 2.3 % D + →K *0( 1680) + →K - + + BR = 3.8 · %