Hi Flemming and others,
Happy New Year!
On Wed, 3 Jan 2001, Flemming Videbaek wrote:
> To checkput the dN/dEta analysis I wanted to run at least a single run
> replacing BrTrackStringFollow Finder for the default TrackFollow all
> embedded in BrTrackFollowFinderModule, the setup was easy, but the code
> crashed rigth away.
> The first problem was simple moving Init() and the default parameters to
> the correct place.
You're right, we in Oslo also had to edit the BrTrackStringFinder to make
it work after the December (?) update of Brat, but forgot to check this in.
> The second problem is
> a bit worse. I had added in the BrTrackFinderBase module some histogramming
> of the track parameters rel. to hits
> (deviation plots) as an overall check. This does not work with the
> TrackStringFinder since it clears the hitarray for each track. I commented
> this out, but it should be re-coded such it has a hit list for the final
> localtracks.
This is very strange. As far as I can see, the DetectorTracks produced
by the TSF have pointers to LocalTracks with lists of DetectorHits, just
as it should be. What is cleared is just the module's private scratch
hitlist. (I put in a debug statement in BrTrackFinderBase, just
after the incrementing of histograms, and had no problems retrieving
the hits.) Exactly how does the problem manifest?
> Another question is about parameters for the module. For TPM1 the default
> module finds more tracks (about 10%) than the trackFollowFinder- for tpm2
> though it finds fewer and fewer matched tracks. This indicates to me that
> the params are not optimal for the large angle tracks in tpm2. Is this
> possible a correct interpretation?
> Please comment.
The default parameters might not be optimal for TPM2. To start with,
the default tracking method should be 2 (picks one hit only from each
padrow, while method 1 just counts all hits within a cylinder, which
might produce a little bit more ghost tracks.)
This can be done in application code by:
BrTrackStringFinder* trackfinder;
....
trackfinder->SetFindTracksMethod(2);
More important, one could increase the maximum allowed distance
between line and hit a little from default 0.40 (default in TFF is 0.40
both in X and Y direction):
trackfinder->SetDistance(0.50); (up to 0.60 or something?)
A problem is that the TSF is very slow for more central events in TPM1.
If you want to find primary tracks in TPM1, it is possible to speed
it up a bit by considering only track candidates pointing (approximately)
back to the nominal beamline. Without this requirement, the
primary / secondary ratio is very similar for TSF and TFF (see Bjørn's
efficiency note.)
trackfinder->SetRequireBeamlineOrigin(kTRUE);
trackfinder->SetAllowedBeamlineMiss(4.0); (a few cm, corresponding to your
y vertex cut)
Best wishes,
Trine
This archive was generated by hypermail 2b29 : Thu Jan 04 2001 - 11:18:34 EST