SVACInstrument Analysis Meeting, September 23, 2005 Anders W. Borgland 1 GEM Discarded Events Anders W. Borgland Science Verification, Analysis and Calibrations

SVACInstrument Analysis Meeting, September 23, 2005 Anders W. Borgland 2 Outline What are the GEM discarded events Number of discarded events Time distribution of the discarded events STR 33 results STR 35 anticipation Summary

SVACInstrument Analysis Meeting, September 23, 2005 Anders W. Borgland 3 Why You Should Be Looking At The Data! This all started with Mutsumi coming into my office with a distribution that looked strange. A lot of people have been involved in what followed: –Warren, Jim, Mike, Eric, Eric, Eric..... Here I will try to summarize what we know about this effect. SVAC ntuple variables! Run B2 8 tower

SVACInstrument Analysis Meeting, September 23, 2005 Anders W. Borgland 4 GEM Discarded Events GEM discarded events: –A counter that keeps track of how many times the trigger window turned, but the LAT was busy. –Called 'GemDiscarded' in the SVAC ntuple. We may have discarded events under normal data taking: –Two physics events coming close to each other, and the LAT is busy reading out the first one –Periodic trigger fires while we read out an event But the rate should be very low! GEM Discarded counter for first 10 events of run Value of GemDiscarded We have We have We have 20 discarded events for the first 10 events that were read out! There is also a pattern here.....

SVACInstrument Analysis Meeting, September 23, 2005 Anders W. Borgland 5 Plots: Part I I will plot how much the GEM discarded counter increases from one read out event to the next read out event: –Delta GemDiscarded Will show you plots for: –Different number of towers in the grid: –1, 2, 4, 6 and 8 towers –Different run types: –B2 and 1-1: Flight configuration –B10: CAL 4-range readout –B13: CAL 4-range readout and no zero-suppression Deadtime is different for the different run types (see Warren's talk from August 5): –B2 : 529 ticks –B10: 1309 ticks –B13: ticks Remember: –It's only a discarded event if it occurs inside the dead time!

SVACInstrument Analysis Meeting, September 23, 2005 Anders W. Borgland 6 One Tower Data: End2End 1-1 Delta GemDiscarded peaks at % of the read out events have discarded events

SVACInstrument Analysis Meeting, September 23, 2005 Anders W. Borgland 7 Two Tower Data: End2End B2 Delta GemDiscarded still peaks at 0. 1% of the read out events have discarded events.

SVACInstrument Analysis Meeting, September 23, 2005 Anders W. Borgland 8 Two Tower Data: B13 More discarded events here than for B2, but remember the deadtime is larger.

SVACInstrument Analysis Meeting, September 23, 2005 Anders W. Borgland 9 Four Tower Data: B2 We nearly always have one discarded event per read out event!

SVACInstrument Analysis Meeting, September 23, 2005 Anders W. Borgland 10 Four Tower Data: B10 Delta GemDiscarded peaks at 0!

SVACInstrument Analysis Meeting, September 23, 2005 Anders W. Borgland 11 Six Tower Data: B2 And B10 B2: Nearly always 2 discarded events per read out event! And we always have discarded events! B10: Nearly no discarded events at all!

SVACInstrument Analysis Meeting, September 23, 2005 Anders W. Borgland 12 Eight Tower Data: B2 And B10 B2 B10 We now have discarded events all the time for both run types!

SVACInstrument Analysis Meeting, September 23, 2005 Anders W. Borgland 13 Time Structure Of The Discarded Events Will plot: –GemDeltaEventTime - GemDeltaWindowOpenTime This gives us the time between the previous read out event and the LAST discarded event: –See cartoon on the next page. –NB! As the number of discarded events increases this time quantity will increase since we always look at the time of the last discarded event. –This quantity will be 0 if there are no discarded events We don't know anything about the other discarded events except how many there are (from GemDiscarded). This time quantity is only useful for events where GemDeltaEventTime is not saturated (3.3 ms).

SVACInstrument Analysis Meeting, September 23, 2005 Anders W. Borgland 14 Time Structure Of The Discarded Events Previously read out event GEM Delta Event Time GEM Delta Window Open Time between current event and the last retriggered event Trigger window width (12 ticks) N retriggered events: Only info available is GEM discarded counter Current read out event: Time of event is time of window closing

SVACInstrument Analysis Meeting, September 23, 2005 Anders W. Borgland 15 One Tower Data: 1-1 Remember: Not many discarded events for 1 tower data, but there is a peak around 140 ticks : Deadtime for 1-1 runs

SVACInstrument Analysis Meeting, September 23, 2005 Anders W. Borgland 16 Two Tower Data: B2 Definitively a peak around 140 ticks.

SVACInstrument Analysis Meeting, September 23, 2005 Anders W. Borgland 17 Four Tower Data: B2 And B10 B2 B10 New peak around 350 ticks. Peak at 140 is still there.

SVACInstrument Analysis Meeting, September 23, 2005 Anders W. Borgland 18 Six Tower Data: B2 B2 Remember: Now we always have discarded events.

SVACInstrument Analysis Meeting, September 23, 2005 Anders W. Borgland 19 Eight Tower Data: B2 And B10 Two peaks: 350 and 365 ticks B2 B10 Another new peak....

SVACInstrument Analysis Meeting, September 23, 2005 Anders W. Borgland 20 STR 33 We don't know what causes these discarded events. Suspect the CAL: –“Known” that when you read out the CAL you 'retrigger'. Special Test Request: STR 33 –Take muon data in a B2 configuration –Turn off CAL LO –Turn off CAL HI –Turn of both CAL LO and CAL HI 'Turn off': –We don't allow it to open the trigger window

SVACInstrument Analysis Meeting, September 23, 2005 Anders W. Borgland 21 STR 33: Baseline B2 Run B2 STR Baseline B2 run Old 8 tower B2 run For the same configuration, the number of discarded events changed!

SVACInstrument Analysis Meeting, September 23, 2005 Anders W. Borgland 22 STR 33: Baseline Run B2 Time distribution did not change!

SVACInstrument Analysis Meeting, September 23, 2005 Anders W. Borgland 23 STR 33: Turn Off CAL LO A small decrease in the number of discarded events

SVACInstrument Analysis Meeting, September 23, 2005 Anders W. Borgland 24 STR 33: Turn Off CAL LO - Time We see only the '350' peak.

SVACInstrument Analysis Meeting, September 23, 2005 Anders W. Borgland 25 STR 33: Turn Off CAL HI A lot less discarded events!

SVACInstrument Analysis Meeting, September 23, 2005 Anders W. Borgland 26 STR 33: Turn Off CAL HI - Time We see our old friend at 140 again..... (consequence of having less discarded events). And we still have the 365 peak.

SVACInstrument Analysis Meeting, September 23, 2005 Anders W. Borgland 27 STR 33: Turn Off CAL LO And CAL HI Very few discarded events left!

SVACInstrument Analysis Meeting, September 23, 2005 Anders W. Borgland 28 Summary We now always have discarded events when we take data. The are coming from the CAL triggers: –Mainly CAL HI The discarded events occur at very specific times. The effect seems to be worse with increasing number of towers in the grid: –Current hypothesis is that some CAL modules are more sensitive than others and we happened put one of them in when we went to 4, 6 and 8 towers. STR 35: –We will redo STR 33 but with only one tower powered up at a time. –Will tell us if some modules are more sensitive than others –Hope to do it next week.

SVACInstrument Analysis Meeting, September 23, 2005 Anders W. Borgland 29 Summary cont' Source of the problem: –Seem to come from the range selector in the Mux (see Fig. 1 in LAT-SS-01972). –According to the experts these events should never leak outside the dead time and become real retriggers. It looks like we have to live with this effect. Makes some GEM variables useless: –Gem Discarded –Gem Delta Window Open Time And we discovered this because somebody plotted an SVAC ntuple variable and thought it looked strange Looking at the Data is doubleplusgood!