User name riordan
Log entry time 13:32:34 on April 16, 2006
Entry number 170932
This entry is a followup to: 170835
Followups:
keyword=Elastic Detection without Drift Chambers (continued)So it turns out I wasn't applying the shower energy cuts as effectively
as I could have been. Figure 1 shows the shower vs preshower amplitude
spectrum as the contour and the elastics are in as the dots. By
selecting on this region around them shower+preshower sum = 3500 I was
able to improve things a bit from yesterday.
I did two different selection methods. The first is a loose cut trying
to be reasonably inclusive around ToF, x-x, y-y, and shower sum. Figure
2 is the tracks per event and figure 3 is the momentum spectrum for those
events. For this we found 620 tracks without tracking and about 490
tracks with giving a tracking efficiency of 80%. From analysis of run
3365 and fitting peaks using neutron arm cuts, we found about 324 elastic
events in the peak, so these cuts seem to be fairly inclusive of the
elastic tracking events.
Doing tighter cuts I begin to work on a subset of elastics, but reject
out more events that were not. Figure 4 is the tracks per event. Our
non-tracking selection reduced to 306 events, but our tracking selection
was 280 events (representing about 80% of the total found elastic events
with tracking and neutron arm cuts) giving a tracking efficiency of about
90%. As you can see from the momentum spectrum in figure 5, the events
are more contained within the elastic peak.
I'm pretty well convinced at this point that these events are not
manifesting themselves in the data as we expect if indeed they are even
in the data. If I remove the time of flight cut, but leave everything
else we get 960 events and 67% of them have tracks (figure 6). We expect
to have about twice this number of elastics, so I'm thinking that the
timing from the trigger getting screwed up is probably not the issue.
The only thing I can think of at this is if these events are in the data,
we need to implement a multiple clustering algorithm in the shower. If
we have more than one cluster and for some terrible reason we are
selecting the wrong one 2/3s of the time we will have problems as we've
made the tracking dependent on having that correct.
Looking at the software amplitude sum for the shower less the shower
energy cluster (figure 7), they seem to completely agree with each other
at least 65% of the time, so it may not even be worthwhile to consider
multiple clusters to solve this problem.
Anyone have any suggestions where to look from here?
A copy of this log entry has been emailed to: gf0b@andrew.cmu.edu, bogdanw@jlab.org, nl8n@virginia.edu, feuerbac@jlab.org
Figure 1
Figure 2
Figure 3
Figure 4
Figure 5
Figure 6
Figure 7
