Hi This is a bit surprising; It has certainly worked before - and many tracks must exists in duplicate because there are and have been ghost tracks. I belive the ID were set in the internal table of the ViewCombiner (and knowing what Kris did) the ID is the 'address' of the object. These are then transferred via the base class BrLocalTracking module to the selected best value's. The general ideas of course that the value in the final tracks reflects also the intermediate tracks and one can (if there is a need) match back and forth. This of course could be lost if you re-assingn different ID's in the end. I suggest you talk to Pawel to figure out the root cause of this problem. If this was broken possibly something else might have gone bad. Flemming ------------------------------------------------------ Flemming Videbaek Physics Department Brookhaven National Laboratory tlf: 631-344-4106 fax 631-344-1334 e-mail: videbaek@bnl.gov ----- Original Message ----- From: "Djamel Ouerdane" <ouerdane@nbi.dk> To: <brahms-dev-l@bnl.gov> Sent: Tuesday, April 02, 2002 10:11 AM Subject: DC and BFS tracking > Hi all, > > I discovered recently some odd behaviour while I was trying to improve the > BFS tracking and found out that (at least in the data I was checking, > containing local DC tracks), the local track IDs were not set. > > The reason why we haven't seen some weird e.g. PID is because there's on > average only one track found in each DC. But of course, it happens that > more than one track are recontructed in each DC. In this case, the track > IDs are random, sometimes this random number is the same for all tracks. > When it comes to the matching between say T3 and T4, you can guess what > happens then (this is extremely important when D3 matched tracks are > combined with D4 matched tracks to get BfsTracks!) > > I have fixed the problem in BrDCTrackingModule (well, I hope, since I'm > not the author of this class) and introduced a couple of more changes in > BrBfsTrackingModule: > > * removed everything dealing with the primary vertex in TrackToVertex > when FFS and BFS are aligned. The global track member fTrackVertex in this > case is the intersection of the TOF1 plane. The path length calculation > stops also there. So we need an extra module to combine FFS and BFS (very > easy when T2 - T4 are combined) for specific purpose e.g. TOF2 time > calibration. > > * added options so that: > 1- T3 - T4 are combined if you call > BrBfsTrackingModule::SetFrontMode(BrBfsTrackingModule::kT3, kTRUE); > > 2- T2 - T4 are combined if you call > BrBfsTrackingModule::SetFrontMode(BrBfsTrackingModule::kT2, kTRUE); > > The default of fFrontMode is both. If you call set T2 to true in case the > BFS faces the beamline directly, it is disabled and use T3 instead. > The BrBfsTrack class has already a boolean member to know if T2 was used > or not. > > 3- now, if both T2 - T4 and T3 - T4 were combined, you end up with > matched tracks sharing the same T4 track. It is ok for checking data and > later on for combining T2 - T3 (for e.g. consistency check) but you can > also choose to clean up the duplicates, either the ones made with T3 or > the ones using T2. This is done by calling: > > > BrBfsTrackingModule::SetCleanUp(BrBfsTrackingModule::kCUT2, kTRUE); > > OR > > BrBfsTrackingModule::SetCleanUp(BrBfsTrackingModule::kCUT3, kTRUE); > > > Of course, you cannot clean up both! :) The default is no clean up. > > I checked that the stuff works and give the desirable results. > > * the old method SetCombineMode(bool) has been renamed SetExtendD3Match(bool) > (This method allows you to enable the swim of D3 matched tracks > through D4 - in case there were no D4 matched tracks to be combined with - > and the creation of a virtual D4 matched track, useful when the > efficiency of T5 is low) > > > This is it :) > > Ciao > Djam > > > -- > Djamel Ouerdane ------------------------------------------o > | Niels Bohr Institute | Home: | > | Blegdamsvej 17, DK-2100 Ø | Jagtvej 141 2D, | > | Fax: +45 35 32 50 16 | DK-2200 Copenhagen N | > | Tel: +45 35 32 52 69 | +45 35 86 19 74 | > | http://www.nbi.dk/~ouerdane | > | ouerdane@nbi.dk | > o---------------------------------------------------------o >
This archive was generated by hypermail 2b30 : Tue Apr 02 2002 - 15:41:22 EST