Hello,
After spending a very intense 1 1/2 week running DC tracking code in
debug,
we have finally figured out why the DC tracking code got hung up in many
of even the simplest events and why it missed many other simple tracks.
The problem had to do with how hits were combined in adjacent staggered
planes. The idea behind using staggered planes is to have more
information on the left-right ambiguity. What was happening was that
when a track came through at an angle where it would traverse a wire, it
would find the wrong hit candidate and would subsequently not match when
the intermediate hit positions were verified. This caused the track to
be missed. On the other hand, if the combined hit was not found, the
hits from the single planes would be used and this increased the
combinotorics immensely which is where the code would hang and gobble up
a lot of memory which is why the clones arrays got so large and very
frequently had to be cleaned. It is my feeling that this is expaserated
by the planes being relatively far apart (~3cm) relative to the plane
separation of 8mm that was used in the original SONATA and sonata++
where the matching algorithm seemed to work.
What we have done for now and which is probably not the end of the story
is to use only the hit separation as the criterion to determine the
combined hits. This causes us to find all of the correct combined hits
in addition to some incorrect ones. In what we have run so far, it
appears that the incorrect combined hits are rejected when considering
the intermediate views. This causes us to find all of the single pion
tracks when we input perfect position resolution (sigma=0.0) and perfect
efficiency (epsilon=1.0). When we put in realistic values, (eg,
sigma=250um, epsilon=.94) the fraction of single pion tracks found goes
down in a reasonable way.
We have also put in a routine to find combined hits for three planes of
the same view. The above conditions for determining combined hits are
also used, but in addition to using the separation of the hits, we also
look to see if the 3 hits lie on a straight line within some error that
depends on the position resolution. If no candidates are found, the
first two planes are used as a pair with the routine as described
above. Including the third plane increased the efficency of the single
pion tracks very slightly. We also included in the DCPlane the
possibility to have wires staggered at some distance we specify. This
is for our DC's which have planes staggered, but the second plane is not
in the middle of the first one.
In addition to finding single pion tracks, we can now read the real
file. 150 events in sim_325 were read in 147 seconds which comes to
approximately 1 second per event. In the MDC2 summary at
http://www.rhic.bnl.gov/export1/brahms/WWW/private/computing/mdc2/summary.html
it shows that for job 325 that it took 12153.75seconds for 1000 events
which is 12.1 sec per event. We established during MDC2 that it spent
most of the time in the DC tracking. One comment I heard was that it
spend 95% of the time in DC tracking. This performance has increased by
approximately a factor of 12 and that would be somewhat consistent. In
addition, it did not find many of the tracks in MDC2. In looking with
several 10's of events on the event display, we see that with the new
routine we find most of the tracks (though not all) using the reasonable
efficiency of .95 and position resolution of 250um.
We also found two memory leaks yesterday. One was obnoxious and was
located very quickly. The other has not been located yet, but is also
not as serious. It appears that about 35 TObjArrays are being created
in the DC tracking in each event that are not deleted. I did not manage
to locate that yet, but will continue to search.
There are things to study for generating the combined hits. The way it
is done now does not really exploit the staggered planes directly to
help with the left-right ambiguity, but it is used indirectly. It is
clear, however, that when the planes are further apart and the track has
more of a chance to traverse wires that the problem becomes more
interesting. Jerzy is now proceeding into a study of wire distances and
angles and staggering to study the efficiency especially of T3. This
should go very quickly now.
The changes described here to the DC tracking have been checked into the
repository. The code was then downloaded and built from scratch and
appeared to behave correctly, so things should be in order.
More information as it becomes available.
Kris
This archive was generated by hypermail 2b29 : Tue Feb 01 2000 - 20:35:04 EST