CLCT “Readout Inefficiency”

1. CLCT “Readout Inefficiency” • Recall CRAFT result: CLCT Readout efficiency ~ 60% for high momentum muons normal to chamber… • Andrey gave a talk nicely explaining the problem… (see backup slides) Essentially: • Sequential events sometimes occur with closely spaced L1A’s, but still within the CMS “trigger rules”… (such as cosmic rays passing from one endcap to another). For these events: • ALCT and SP data repeated in each event (with different “BX” value) • TMB data in first event, no data in second event • CFEB data split across both events • What do we do about it? Currently the subject of a huge number of long emails… G. Rakness (UCLA)

2. TMB software, status at CERN G. Rakness (UCLA)

3. Bit received at ALCT  sent back to TMB  Received at TMB 0 1------------------------------------------------------- Pass 1 -1------------------------------------------------------ Pass 2 --1----------------------------------------------------- Pass 3 ---1---------------------------------------------------- Pass 4 ----1--------------------------------------------------- Pass 5 -----1-------------------------------------------------- Pass 6 ------1------------------------------------------------- Pass 7 -------1------------------------------------------------ Pass 8 --------1----------------------------------------------- Pass 9 ---------1---------------------------------------------- Pass 10 ----------1--------------------------------------------- Pass 11 -----------1-------------------------------------------- Pass 12 ------------1------------------------------------------- Pass 13 -------------1------------------------------------------ Pass 14 --------------1----------------------------------------- Pass 15 ---------------1---------------------------------------- Pass 16 ----------------1--------------------------------------- Pass 17 -----------------1-------------------------------------- Pass 18 ------------------1------------------------------------- Pass 19 -------------------1------------------------------------ Pass 20 --------------------1----------------------------------- Pass 21 ---------------------1---------------------------------- Pass 22 ----------------------1--------------------------------- Pass 23 -----------------------1-------------------------------- Pass 24 ------------------------1------------------------------- Pass 25 -------------------------1------------------------------ Pass 26 --------------------------1----------------------------- Pass 27 ---------------------------1---------------------------- Pass 28 ----------------------------1--------------------------- Pass 29 -----------------------------1-------------------------- Pass 30 ------------------------------1------------------------- Pass 31 -------------------------------1------------------------ Pass 32 --------------------------------1----------------------- Pass 33 ---------------------------------1---------------------- Pass 33 ----------------------------------1--------------------- Pass 34 -----------------------------------1-------------------- Pass … Total number of bad bits = 0 • Test at 904: • Send 1 bit from TMB • Receive bit at ALCT • Send it from ALCT • Receive it at TMB • Loop 1000 times per bit Bit sent from TMB • Checked cables on 3 CSC’s with known issues at point 5 •  All have all bits OK… G. Rakness (UCLA)

4. Result (tx vs. rx) tx ----> 00 01 02 03 04 05 06 07 08 09 10 11 12 ==== ==== ==== ==== ==== ==== ==== ==== ==== ==== ==== ==== ==== rx = 0 0 0 0 2c0 0 0 0 0 3d8 0 0 0 0 rx = 1 0 0 0 3 0 0 0 0 0 0 0 0 0 rx = 2 0 0 0 0 0 0 0 0 0 0 0 0 0 rx = 3 0 0 0 0 0 0 0 0 0 0 0 0 0 rx = 4 0 0 0 3d8 0 0 0 0 0 0 0 0 0 rx = 5 0 0 0 3d9 3d8 3d8 0 0 0 0 0 0 0 rx = 6 0 0 0 3d8 3d8 3d8 0 0 0 0 0 0 0 rx = 7 0 0 0 3d8 3d8 3d8 3d8 0 0 0 0 0 0 rx = 8 0 0 0 3d8 3d8 3d8 3d8 3d8 0 0 0 0 0 rx = 9 0 0 0 0 3d8 3d8 3d8 3d8 3d8 0 0 0 0 rx =10 0 0 0 0 0 3d8 3d8 3d8 3d8 0 0 0 0 rx =11 0 0 0 625 0 0 3d8 3d8 3d8 0 0 0 0 rx =12 0 0 0 0 0 0 0 3d8 3d8 0 0 0 0 Result (tx vs. rx) tx ----> 00 01 02 03 04 05 06 07 08 09 10 11 12 ==== ==== ==== ==== ==== ==== ==== ==== ==== ==== ==== ==== ==== rx = 0 0 0 0 0 0 0 0 0 0 0 0 0 0 rx = 1 0 0 0 0 0 0 0 0 0 0 0 0 0 rx = 2 0 0 0 0 0 0 0 0 0 0 0 0 0 rx = 3 0 0 0 0 11 0 0 0 0 0 0 0 0 rx = 4 0 0 0 0 11 11 0 0 0 0 0 0 0 rx = 5 0 0 0 0 11 11 11 0 0 0 0 0 0 rx = 6 0 0 0 0 0 11 11 11 0 0 0 0 0 rx = 7 0 0 0 0 0 11 11 11 0 0 0 0 0 rx = 8 0 0 0 0 0 0 0 0 0 0 0 0 0 rx = 9 0 0 0 0 0 0 0 0 0 0 0 0 0 rx =10 0 0 0 0 0 0 0 0 0 0 0 0 0 rx =11 0 0 0 0 0 0 0 0 0 0 0 0 0 rx =12 0 0 0 0 0 0 0 0 0 0 0 0 0 ALCT – TMB communication scan Old scan: send empty data, count the number of ALCT words Best value in center of diamond “Diamond of good communication” shrinks significantly Shifted by ¼ bx? Difficult to say since “old” scan is ~½ bx wide… New scan using random loopback: G. Rakness (UCLA)

5. Questions for discussion Q: Have we learned all we can with the test ALCT module at CERN? • Given that the old “good window” is so wide, I don’t know if we learn more by iterating on latching phases? • Perhaps ECC maybe best checked out with real data? G. Rakness (UCLA)

6. TMB software at CERN • Software changes: • Added alct_ecc_enable bit to TMB configuration data block • Need to iterate with Angela and Jinghua about adding this to configuration database… • Updated counters • Made “Getter” functions to counter indices in TMB class so that any functions which rely on counters (such as timing scans or XMAS) do not need to change… • Last night: downloaded the firmware to ME+ station 2, trigger sector 5. • Two data runs taken with alct_ecc_enable = 0 (Runs 79653 and 79652)  All OK from DQM and emulator points of view… G. Rakness (UCLA)

7. Proposal to stage TMB/ALCT firmware • Load TMB to one trigger sector (including ME1/1) • Make sure I have correctly loaded the ME1/1 chambers (recall ME1/1 loading mistake by GR) • Set alct_ecc_enable = 0, make sure all is OK • Load TMB to all chambers • Set alct_ecc_enable = 0, make sure all is OK • Load ALCT to one trigger sector • Re-measure TMB – ALCT phase parameters • Take data to make sure ECC is implemented correctly in working ALCT • Load ALCT to all chambers • Re-measure all TMB – ALCT phase parameters • Make sure all is OK… Comments? G. Rakness (UCLA)

8. G. Rakness (UCLA)

9. Ring +1/2 CLCT pretrigger Time (bx) Recall: Position of RPC data in TMB FIFO CRAFT 2008 Position of RPC data in TMB FIFO = 6.8bx Note: This is ~8bx late G. Rakness (UCLA)

10. 2009: Position of RPC data in TMB FIFO 4 – 5 March 2009 MWGR Ring +1/2 Position of RPC data in TMB FIFO = 4.7bx CLCT pretrigger Time (bx) Is narrower, with longer tails than CRAFT 2008… Need to sort by chamber to see if specific chambers are late? Suggestions? G. Rakness (UCLA)

11. Other stuff • From 25 – 26 March Mid-Week Global Run… • Firmware update of DCC examiner to comply with CMS DAQ requirement that unused bits = 0… This change was not communicated well to offline folks…  DCC “Examiner” removing all CSC events from Global data • CSC TF still needs extra “Resync” in global runs… • To be tracked down tomorrow… • Next MWGR = 8 – 9 April • CSC Local Runs with no HV  20 events/hour trigger rate… • Report on events at tomorrow’s DPG meeting… Longer run to be taken tomorrow evening… • Tiziano Camporesi is going to come see how we “operate the detector” from a shift point-of-view • He wants to understand what it entails… He is leaning towards centralization of shifts… • I am going to give a plenary talk at the Division of Particles and Fields of the APS 26 – 31 July • Title: “The CMS Detector” G. Rakness (UCLA)

12. To do • Today I was trying to get the “CLCT key-wiregroup” finding program from Andy Kubik to derive how I should load TMB firmware to ME1/1 chambers • Still working on it… G. Rakness (UCLA)

13. Backup slides G. Rakness (UCLA)

14. CRAFT data: plot on right Data: CLCT readout efficiency Monte Carlo: RecHit efficiency NB: Empty boxes—either low stat or there are no such chambers Andrey Korytov March 26, 2009 14

15. Event Display Why CLCT is missing? Andrey Korytov March 26, 2009 15

16. Explanation (1) • We have a large detector: ~75 ns TOF (corner to corner) • CRAFT Trigger: any chamber • Trigger rule: no more than 1 L1A within 3 BXs • Cosmic rays: we are bound to have some L1A’s coming from the very same muon (with 3 BX time difference) note the rate of double triggers for DTs alone: ~1% of all events (L. Guiducci, Torino CRAFT workshop) Andrey Korytov March 26, 2009 16

17. Explanation (2) • Current readout rules • ALCT: • ALCT0 opens 7-BX window (configurable) • if L1A falls inside window, ALCT data are sent to DAQ • if second L1A comes and falls in the 7-BX window, an event is sent to DAQ again • TMB: • (CLCT0xALCT0) opens 7-BX window (configurable) • if L1A falls inside window, TMB data are sent to DAQ • if second L1A comes and falls in the 7-BX window, it is ignored • CFEB: • pre-CLCT opens 3-BX window (fixed in firmware) • if L1A falls inside window, data are sent to DAQ • second L1A in the same winow is not allowed by trigger rules • if second L1A comes in 3 BXs, there is not a match (window is closed) Andrey Korytov March 26, 2009 17

18. Explanation (3) • So what happens is as follows • Muon crosses two endcaps (or DTs and CSCs) • two L1A spaced by 3 BX can be generated, • e.g. first by top chambers in the “–” endcap and then by bottom chambers in the “+” endcap • Now, we have two “events” in data corresponding to one physical event (will certainly help discover Higgs!) • ALCT data are repeated with 3 BX time offset in both “events” • CLCT data are present in the first “event”, but absent in the subsequent • CFEB data are actually split between the two “events”: • the – endcap data will be present in the 1st event • the + endcap data will end up in the 2nd event • This would explain: • good efficiency of ALCT • bad efficiency of CLCT • not too good efficiency for RecHit Andrey Korytov March 26, 2009 18

19. Explanation (4) Event structure of doublets (example) Run 69912 L1A=5492521 ME+1/3/07 ALCT TMB CFEB ME-1/2/18 ALCT TMB - ME-3/2/20 ALCT TMB - ME-2/2/19 ALCT TMB - L1A=5492522 ME+1/3/07 ALCT - - ME-1/2/18 ALCT - CFEB ME-3/2/20 ALCT - CFEB ME-2/2/19 ALCT - CFEB CFEB CFEB dBXN between two L1A’s is 3 BXs ENTRY EXIT ENTRY EXIT Andrey Korytov March 26, 2009 19

20. Implications • CRAFT data analyses: • watch out for duplicate events; they must be merged • one cannot discard both of them (there too many of them to “induce an apparent 40% inefficiency”) • one cannot discard just one (CSC information is actually split between the two) • reconstruction is not ready for such merging • note that some parts of CSC events can be stolen by calorimeter triggers (different dataset) • Future running: should we change anything? • ideally, for cosmics/halo, and low lumi: • keep large N-BX windows (including CFEBs, which are now “firm”-coded for 3-BX) • change trigger rule: no more than 1 L1A in a N-BX window • will have no duplicates • inefficiency is driven by (window)x(rate); predictable • squeeze window size as we go from N to 7, 6, 5, … BXs • alternatively, start out with all coincidence windows set to 3 BXs • duplicates will persist in cosmic/halo runs • parts of many events will inevitably be split (a la CFEB now), never shared (a la ALCT now), and never stolen (a la CLCT now) • precise synchronization is requires • inefficiency may become driven by sync errors; less predictable Andrey Korytov March 26, 2009 20