L3Dch progress report Jan 29 1998. ++++++++++++++++++++++++++++++++++ Anders Ryd ++++++++++ Brief list of L3Dch modules and their purpose. ============================================== Modules that does the work: TrgDchHitMatch.cc Matches tsf segments with drift chamber digis. L3DT0.cc Event t0 finding, very preliminary. L3DFinderFitter.cc Does the actual track finding and fitting. Diagnostic modules: L3DAnal.cc Trivial L3 accept, requires 1 track from origin L3DKS.cc Creates K_s from oppositely charged tracks. L3DEff.cc Makes plots of the track finding efficiency. L3DTag.cc Tags the tracks for studies of resolution etc. All work shown below is done using "new" drift chamber hits. In fact I just picked 1 file from the MDC1 production of B->X B->ulnu, these events has slightly lower multiplicity than generic B decays. The work is based on 5.2.2 with the default trgDC that is in this release, Fred says that there are some problems with this version of trgDC in that it does not generate segments in the 0:th cell, but this has not been a problem for me, in fact I have problem with the old simulation which give unexplained pulls in the residuals that are correlated with the momentum. Failing to resolve this using old hits I decided to move to the new hits and here this effect is gone. Configuration control in tcl ============================ Some but not all configuration parameters have moved in to the AbsParm world. The currently available parameters in tcl are: module talk L3DFinderFitter sigma1 set 1.0 sigma2 set 1.0 sigma3 set 1.0 sigma4 set 1.0 sigma5 set 1.0 sigma6 set 1.0 sigma7 set 1.0 sigma8 set 1.0 sigma9 set 1.0 sigma10 set 1.0 residpersegment set 0.0001 phiwindow1 set 120.0 phiwindow2 set 240.0 disp set false fix set 0 exit Things to add: Choice so that the fit can be switched between using fast track derivatives, algebraic or numerical, the current implementation uses numerical which is the slowest possible! Choice of hit-type to use; either the position reported from the tsf finder or the improved position using drift chamber information. All the parameters that are used as cuts for the selection of segments to use on a track. Diagnostics ========== Two different types of diagnostics are available. 1) Event display. Two examples of event displays are in this directory: event.ps and spider_segs.ps. event.ps shows an example of a BBbar event in the full view. The found tracks are plotted in red, and MC tracks are in black. Note that the MC tracks are forced to come from the origin, this will be fixed when I figure out what is wrong with my track parameter transport routine, or if I can find something in the off-line tracking that can do this. Note also that the algorithm were able to separate the two tracks that are in the upper-left quadrant. The spider_segs.ps plot shows a close-up of a track in another events after the displaying of which dch-hits belongs to a given tsf segment. This plot shows that most hits in a super layer made 2 tsf segments. 2) Histograms and N-tuples; several histograms and n-tuples are booked and filled: 100 (N) t0 N-tuple with the drift distance and time from Mc truth. 401 (N) phi pos Compares positions from the tsf with the improved dch segment. 300 (N) Ks K_s mass and momenta. 700 (1) l3dhit The number of hits from the tsf per layer. 701 (1) dchhit The number of the tsf hits matched to a dch digi per layer. 703 (1) ntsfseg Number of tsf segments per event. 702 (1) trgdchhitmatchtime ms Time to do dch matching per event. 101 (1) t0 per segment t0 finding per segment. 102 (1) t0 per event t0 finding per event. 402 (1) time finderfitter ms time to find and fit tracks. 600 (1) d0 distribution d0 distribution, all tracks. 601 (1) z0 distribution z0 distribution, all tracks. 400 (N) hit residuals hit residulas in each layer. 200 (N) taged tracks Tracks tagged to MC, allows studying the resolution. 500 (N) L3Dch tracking efficiency Efficiency as a function of track parameters. Examples of these plots are described below when the performance of the algorithm is discussed. Performance =========== Let's start with the plot d0_z0.ps it shows the impact parameter in r-phi and z respectively in the two plots. Note that these plots contains all tracks found in the event, the average found track multiplicity is 5.3; these plots are based on 1000 events. 999 of these events had at least 1 track with |d0|<0.015 m and |z0|<0.1 m. (I have not yet looked at the event that failed.) Also note that tracks are no longer found in duplicates in any large numbers; previously probably about 50% of the tracks was found more than once. The plot efficiency.ps shows the tracking efficiency as a function of pt. For single track MC the efficiency is much higher. pt_res.ps shows the resolution on pt in 4 bins of pt, again the resolution is now much better than before. dch_tsf.ps compares the phi-position of the tsf segment with the drift chamber improved position, I have not tried to hard to interpret this plot since I'm aware of a flaw in how this plot is made; this is probably partially the explanation for the side-lobes. hitresiduals.ps shows the residual in each layer between the track and the hit. hits_per_layer.ps shows as a solid line the number of dch-cells that are part of the tsf segments for each layer; and the dashed line shows the fraction of these that had a corresponding dch digi matched to it. Note that the efficiency for this is very high in this new production; in the old production data this was not more than about 90% efficient. time.ps show the distributions in CPU ms for two of the modules; the Finder-Fitter module and the track segment matcher module. The average in the first is about 200 ms and the second is 25 ms. (This is CPU time on percheron.) Before we start to panic about this I tried to simply comment out 1 append to a CLHEP list and two histogram accumulation in the TrgDchHittMatch module and the average time went down to 5 ms. I need to look at this more to learn what takes time. t0 finding ========== Currently the drift distance for the drift chamber hits are taken from the smeared MC truth that is available in the DchDigi's. I have started to look at finding the t0 in the matched tsf segments. The idea is the following: a b p c d e f g where a-g and p are the wires in the cell; p is the pivot cell. I look for segments that has hits in, at least, apcf, or bpdf. Then I approximate the time to distance relation with a straight line, and say that the time sum of the times for the 4 wires should equal twice the average distance, perpendicular to the radius, between the wires. This was my very first attempt, I have some ideas how to improve this. The result is shown in t0.ps. The first plots shows the t0 evaluated for each segment, and the second plot shows the average for an whole event. Configuration database ====================== Code exists to write and read the track table from the conditions database. This code has not yet been incorporated with the standard L3Dch code, but I plan to do this by the Feb 3:rd release 6.0.0. This will mean that using the conditions database will be _required_ to run L3Dch. Plans Conclusions ================= I think I made some progress in understanding the algorithm, in particular the geometry problem that I had with old dch hits is now gone, this now means that I think that I can understand the fit in terms of it's resolution on the track parameters in terms of more primitive quantities such as the resolution of the hits; this was not possible before. Also I have to understand how fast I can execute this; currently it looks like there is tremendous bottlenecks in the performance of the histogram booking and/or the CLHEP list class.