100 likes | 212 Views
ADM Meeting , June 29, 2001, Fermilab. First Look at Trigger Rates. Levan Babukhadia. SUNY at Stony Brook. http://www-d0.fnal.gov/~blevan/tm. First look at Monte Carlo trigger rates, some relatively understood issues, some remaining to be resolved …
E N D
ADM Meeting, June 29, 2001, Fermilab First Look at Trigger Rates Levan Babukhadia SUNY at Stony Brook http://www-d0.fnal.gov/~blevan/tm
First look at Monte Carlo trigger rates, some relatively understood issues, some remaining to be resolved … • TrigSim can now take a trigger list. Had 14 triggers in p08. More extended list for p09 in preparation • Trigger rates estimated using large reference sample of QCD dijet Monte Carlo events • Previously, requested 3 sets of the following at three luminosities (0.14, 0.70, & 1.4MB): • PT 2-5 30K • PT 5-10 25K • PT 10-20 20K • PT 20-40 10K • PT 40-80 10K • PT 80+ 5K • What we really get are PT thresholds, NOT bins (we may not want bins anyway). So, how do we combine rates from different PT bins?
It is not clear how to best combine rates from different PT bins without cutting out events from lower into higher bins to avoid double counting. We probably will not get proper weights from MC to do this ‘correctly’ • Need a good quantity to cut on. Hard scattered parton PT’s are not stored (in TrigSim ntuples by MC_Analyze?). So, I suggested to store Q^2 — to my surprise it is not stored right now, even though such quantities are there in MCKine chunk. We should store them! • To do reality checks as well as to check any procedure for combining rates, need a large sample of low PT QCD dijets. Have requested a sample of 200K with 2GeV threshold. Iain told me yesterday that these are already in SAM, need to TrigSim them now. Not sure if we need this for different MB, but it certainly can not hurt to have them... • If we can not combine, could still use the dominant samples but then how large a sample will we need in each PT ‘bin’?
CEM(1,10) checked out Ok against measured and predicted Run I rates — good news! (too good to be true?..) Why is MUON so high?.. • As of yesterday, many of the TrigSim ntuples I have been provided with are not reliable, they need to be recovered, etc. I communicated this, but the new ntuples appear to continue to be the same way (SAM problem?…) requested TrigSimmed Bad • PT 2-5 30K 4 1 • PT 5-10 25K 1 0 • PT 10-20 20K 1 1 • PT 20-40 10K 3 1 • PT 40-80 10K 1 1 • PT 80+ 5K 1 1 This should be fixed! • It would be good to have dedicated disk area for storing these TrigSim ntuples
Other issues: • TrigSim stores CS/Event #. What is this good for? Let’s just store CS!
Other issues: • CS values fluctuate a lot with ~10-15% spread because events are generated in chunks of 250 events (because of RECO memory leaks, etc). So, had to generate large PYTHIA samples to get reliable CS’s.
Other issues: • We all should use the SAME QCD and MB cross section values. Here are the numbers I used • PT 2-5 39528.7b • PT 5-10 8280.15b • PT 10-20 612.552b • PT 20-40 34.5415b • PT 40-80 1.49230b • PT 80+ 0.04470b Minimum Bias (MB) = 46mb
Other issues: • Started to study trigger overlaps or correlations. Here might be where TrigSim could be most helpful, perhaps more than in predicting absolute rates ...
CJT(3,5) CJT(2,5)CJT(1,7) CJT(2,5)CME(20) CEM(1, CEM(1,10) MUO(1,PT4,A,T,T,X) MUO(1,PT4,C,L,L,X) MUO(1,PT3,C,L,L,X) CEM(1,10)CER(1,5,C) CEM(1,10)CER(1,5,C) CEM(1,5)CER(1,5,C)TEL(5,h) TTK(2,5)TTK(1,10)TIS(5)CEM(1,L) CEM(1,5)CJT(2,5)CJR(1,C)TIS(5)P1C_jt MUO(2,PT1,C,L,L,X)MUO(1,PT2,C,T,T,X) CEM(1,5)CEM(2,1.5)CER(1,5,C)P2CCa_shLO