Hello,
I have spent the last several days pulling my hair out with the tracking
routine. I think Alv has also at some level. The problem started as I
indicated in a previous message that I could not find single tracks in
T1 and T2 from the single pion track file that Flemming generated for
me. One problem was the windows on psig and tsig which was the subject
of the last message a few days ago. But still no tracks! So I traced
further and discovered that I was losing them in the place where
TPCPadFindHit where a hit from a given row is taken with the current
guess of the track vector and projected back to see if the next point in
space falls within some limits. In printing out the lists of positions
of the BrCombinedHits, I discovered that they were all over the place
and not on a straight line that I would have expected for a track going
through a TPC that is not sitting in a magnetic field. So I began to
look further back to see why those where all over the place. I then
discovered that we were cutting the ADC spectrum in a bad way and that
the distributions were skewed toward higher ADC values, but not in even
ways. So to solve that problem, I lowered the threshold for a hit to be
accepted in BrDigitizeTPC. It is the statement toward the end where it
says,
if(qbin > .05) {
add the hit
}
I changed that to read
if(qbin > .001) {
add the hit
}
That cleaned things up alot and made the BrCombinedHit positions lie
much closer on a line. But it still was not perfect. In order to get
things to be accepted, I had to open up the limits of what was
acceptable in y. I changed in BrLocalTrackTPC::Event the definition of
dy from .6 to 1.2. With anything below 1.2, many tracks are lost.
Then I had a surprise. I began to find tracks in T1, but T2 still acted
up with the single pion file. I still have not solved that problem. I
decided to take a look at a more realistic file and see if things run.
So I digitized sim_130.cdat at the RCF using the BrEventIO object and
transferred the file here and have been analyzing it. It seems to at
least run without crashing. I also find tracks in T1 and T2 and they
appear to bear some resemblence to the ones found in T3, T4 and T5. The
BrCombineTrack in some iterations of this (although not the last one!!!)
was matching tracks between T3, T4 and T5. The T2Match was still
failing because the track matching did not fulfill the criteria to match
T2 with T3T4T5. This investigation is in its infancy, but I plan to
turn my full attention to that with the goal of getting a reasonable
T2Match which would lead to the new definition of BrTrack as soon as
possible.
I also spent a bunch of time today getting a fresh copy down here from
the repository. In putting in my modifications to BrLocalTrackTPC, I
managed to wipe out the ones Alv made. With a fair amount of time and a
manual and enough bad words about unix, I think I finally managed to
merge mine and Alv's modifications and not leave too much of either one
out. Alv might want to take a look at the version in the repository now
and make sure I did'nt wipe out something important. I might also add
that once I got the latest version going down here that the DC and TPC
tracking routine run much more smoothly than I remember. I think Alv
did a good job of optomizing things.
Please comment on the above modifications I made in order to get tracks
out of T1 and T2. I find the limit on qbin reasonable because in the
old tracking we had the whole TPC as an active volume and that led to
certain dedx. When the padrows were split up, as far as I could tell,
the dedx scaled by the factor of the number of padrows. (12 for T1 and
16 for T2). I lowered by a factor of 20 so I think that hangs
together. More bothersome is opening the limits in dy for accepting
tracks together. That would cause problems when we get into high
multiplicity events.
Let me know what you think.
Regards
Kris
P. S. In the true spirit of UNIX, I discovered that if you compile
things correctly (smart remark) when things are not exactly in the right
order that you can call BrDigitizeDC::ListEventStatistics() when the
program in fact says object->EventStatisticsEnd(). I can even play that
trick in VMS on a bad day, but VMS says all kinds of nasty things to me
about how I am fooling my self by doing such things. UNIX is so polite
that he suffers in silence and doesn't say anything and lets you do all
kinds of nasty things to yourself and he just watches you. So needless
to say, I wasted a bunch of time trying to figure out what was going on
there.
This archive was generated by hypermail 2b29 : Tue Feb 01 2000 - 20:35:04 EST