Hi Peter and others, First: Congratulations with very good work on the clusterfinder ++! On Mon, 2 Oct 2000, Peter H. L. Christiansen wrote: > A few comments : > 1) I don't understand what you say on page 1. You substitute the geant hit > with ... The Geant hits of the pion tracks are digitized and reconstructed from BrTPCSequences to BrDetectorHits "the standard way", and added to the table of detector hits from the raw background event with their 3D positions as determined by the clusterfinder. In this first approach to an efficiency estimate, only the position uncertainties for each hit, BrDetectorHit::fDPos[2], are replaced with numbers taken from randomly chosen hits from a different raw data file. (The combined hit table is then used as input to the trackfinder.) > 2) What is the efficiency vs the number of initial tracks ? This is not investigated explicitly yet (but will soon be.) Figures 2 and 5 at least show that the TFF has a significant chance to miss the track in events with no reconstructed background tracks, while the TSF almost always finds it in such cases. However, we don't expect a very dramatic efficiency dependence on the number of initial tracks at this stage, since the dependence on the centrality as measured by Tiles is very small (except for TFF at 40 degrees, see question 5).) > 3) Do you check to see if you find the track alone with the tracking code. > The reason for not reconstructing some of the geant tracks is that some of > them are quite curved. Print out the chi**2 and compare to when you find > the track. > In general the Chi**2 output from at least the BrTrackFollowFinder looks > bad( I included this as a new histo in BrClusterFinderBase) and is of > course quite interesting for the quality of tracks we > find. Does it look consistently bad for the StringFinder ? > This is of course related to what we assume the white noise to be ( > currently 2 adc channels ). All Geant tracks used for insertion in raw events have already been reconstructed by the TFF as one-track events, so they should be nice and linear. > 4) Are the 2 trackers allowed to miss the same number of planes, ghost > hits share the same number of hits etc.? Yes, they both use the default values (3 missing rows allowed, 4 overlapping hits to define two tracks as identical.) > What trigger do you use - I > would start with trigger 6 where we know that there are much less banana > tracks. Cuts on vertex ? So far, we have used _all_ events, with no trigger cuts (so a lot of the background events may be _very_ messy!) A question: How do you know that trigger 6 has fewer banana structures, from visual inspection event by event, or have you generated some kind of statistical documentation on this? > 5) I think the problem with anti-ghost hits is related to the break down > of the tracking code at least for -2 and down. Now I propogate the status > to the Entry function and store it in a histo ( 0 = ok, 1 = failed ), but > maybe you want to make the status an accessible parameter. At least I > think the crashes should be seperated for both trackers, so we only get > the relative tracking efficiency and then seperately the crash > efficiency;) It's very likely that both the anti-ghost problem and the low apparent TFF efficiency is related to the tendency for this module to give up due to too many track candidates. As you suggest, it would be a good idea to make the outcome (reconstruction completed or not) an accessible parameter, so the two efficiencies could be separated. Maybe the optimization of the TFF overall efficiency will require some compromise between tracking / crashing efficiency (adjustment of hit search widths?) The stubborn TSF doesn't really crash, just chews up CPU time forever - . We look forward to see how the new and improved clusterfinder will influence the results! > 6) I don't understand why the distribution in figure 1 has such a long > tail for the TrackStringFinder. We don't know for sure either. However, the TSF is known to create groups of near-identical tracks at high cluster density, and most of the "ghosts" are removed by TSF's own "extra ghostbuster", RemoveDuplications() prior to the base class ghostbusting. Since the position uncertainties of the inserted hits are somewhat random (see question 1)) the track with the best chisquare is not necessarily the one corresponding most closely to the original Geant track. > 7) I think that instead of using to much time on going down to the > TPCSequence level it would be interesting to focus on why we don't find > the tracks. This is of course a damn hard task, but maybe there is a > simple subset of events that could be viewed on a monitor that would shead > some light on this. We think both approaches are important. The clusterfinder efficiency is an inseparable part of the overall track reconstruction efficiency, and event-by-event inspection of simulated events have shown that the cluster resolution is a major limiting factor at high track density. On the other hand, by using "ready-made hits" one can isolate and study the shortcomings of the trackfinder algorithms. > One could also carefully keep track of the tracks > before and after and compare them, compare tracks from the 2 methods and > compare tracks in a single ouput to see how the general overlap > distribution looks. A comparison of the sets of tracks "before" and "after" Geant track insertion (with overlap calculations) would be important to estimate the "ghost" probability / tracking stability. We plan to look at this in the near future. Cheers, Trine and Bjørn
This archive was generated by hypermail 2b29 : Tue Oct 03 2000 - 12:12:23 EDT