StretchOR Efficiency Results

These results are based on the STR8 Stretch/Oneshot tests performed on  May/6/05. The main strategy was to enable only 3 XY layer pairs in tower 4 (tower B) to form exactly one 3-in-a-row combination as the 'test region'. While tower 0 (tower A) was in normal operations to provide triggers and tracks, in particular the inclined tracks. Muon telescope was placed vertically over tower 4. EXT, CAL_LE and TKR triggers were enabled for data taking.  

Event Selection:

The analysis is based on the v4r60302p23 processing root files using RootTreeAnalysis. Event selection cuts:

• Require EXT | CAL_LE | TKR(tower 0)      (i.e. independent of tower 4 TKR trigger)
• event time >1ms from last event                   (to reduce retriggering and remnant effects)
• Exactly 1 recon track in event     (in part for clean extrapolation, in part to avoid a problem in running RootTreeAnalysis in CINT which has memory overwrite crashes for events with >1 track)
• CAL has >5 layers with Xtal energy over 5 MeV    (penerating muons)
• Track c²/dof <5    (these calculated for electrons, but still helps to wipe out very bad fits)
• Examine the track segments above and below the test region layers separately, to pick the longer side with more hits and require at least 8 hits on that side excluding the test region  (to make sure the existence of the track has minimal dependence on the hits in the test region).
• Locate the last hit immediately outside the test region on the long segment and extrapolate the track into the test region (based on ideal LAT geometry). Require the extrapolated position in all 6 test layers to be well within the tower 4 fiducial ( >1.8cm from the edge).

These selection criteria obtained an (to first order) unbiased tracks which should trigger the TKR in tower 4 test region. As the main purpose is to compare two different stretchOr settings, any remaining small bias should not matter. We then simply measure the 3-in-a-row efficiency from the GEM TKR vector bit for tower 4 to see if it is set. The event selection statistics for one of the runs (L0,1,2 combination) is displayed below:

There were fair amount of CAL retriggring so that only half the events were real triggers. As a trade off  to ensure we have a clean sample, the exactly one track and CAL energy cuts are losing fair amount of statistics which we may be able to revisit with a revised analysis later. The distributions of some of the event selection variables are shown below:

It can be seen that tower 0 has helped to get tracks at inclined angles (f=90,270), but the 8 tracks hits cut may have restricted the low cosq reach somewhat. To verify that the track extrapolation is reasonable, we can examine the extrapolated positions where there wasn't a track hits in the test layers, e.g. in the X planes, which correctly shows ladder gaps and and wafer breaks:

StretchOR Results:

We first run the analysis on the quick OR stretch  scan runs 135002068-73, where we were running on tower 4 alone with the Treq script (GEM win=31), but the tracks hits are mostly still present. These are the only runs we have a fair number of steps in the Stretch OR to map out the stretch behavior in a coarse scan with 1000 events/point:

The StretchOr = 0 point is with stretchOR off to use the natural pulse width of the TKR signals. The plateau appears to occur at Stretch=9-10 (the point at 12 is probably statistically fluctuated down). The higher statistics results from the dedicated StretchOR runs for 3 different layer combinations at 3 fixed StretchOR settings:

There are not statistically significant difference between the Stretch=0 natural width result and the stretch=12 result. We can further examine the results as a function of cosq:

(This plot was made earlier and didn't include the L8,9,10 result, as that was added later on when data from one L8,9,10 run was missing and thanks to Anders and Jim  to getting it back).  There are no noticeable effects distinguishing between no stretch and stretchOR=12.

In conclusion, stretchOR=12 has the same performance as the natural width no-stretch mode. To get some safety margin, we therefore recommended StretchOR=14 as the standard setting for all data taking runs.