TWiki> Main Web>TWikiUsers>BrianFrancis>BFrancisNotes (revision 1)EditAttachPDF

SUS-15-009: Search for natural GMSB in events with top quark pairs and photons (8 TeV)





Analysis Summary

The analysis searches for an excess of high MET events in the lepton (e/mu), jets, and photon final state. The search targets the direct production of light stops in a GMSB scenario with a very bino-like neutralino NLSP.

The dominant background is Standard Model top-antitop pair production with associated photons or additional jets that may be mis-identified as photons. Additional backgrounds include typical backgrounds to ttbar searches: W/Z + gamma, diboson, W/Z + jets, and single top production. All backgrounds are simulated in Monte Carlo and several scale factors are determined to best fit the data in several control regions. An additional control region using poorly isolated photons ("fakes") is examined to characterize the MET shape of the MC.

The results of the search are interpreted as a shape comparison between data and expected backgrounds. To eliminate dependance on the SM ttbar+gamma+gamma cross section and the jet-->photon fake rate, the total background normalization is allowed to float freely to be an entirely shape-based comparison. Upper limits are calculated against a private MC sample of very bino-like NLSP GMSB models with the stop being much lighter than all other squarks or gluinos.

Signal MC

The search uses a privately generated FastSim set of samples. For information about these, see:

ARC review:

Manfred Paulini on AN v3:

  • Sec. 2.2: What checks were performed to gain some confidence that the privately produced GMSB signal samples can be trusted as if they were centrally produced?
    These samples were created similarly to those for the di-photon inclusive searches (SUS-12-001 and SUS-12-018), in which the production was not stops but first/second generation squarks and gluinos (scalar udsg). Thus the checks performed for the "stop-bino" samples were mainly against these well-known older samples, which were also private FastSim.
    We found that for stops and binos in our sample, the kinematics agreed favorably to that of squarks and binos with the same masses produced in these older samples. For an executive summary see Dave Mason's xPAG presentation and the twiki for the scan.
    If he'd like, perhaps Dave Mason could comment on this since he oversaw their creation firsthand.

  • Sec. 2.5: why was the tt= sample re-weighted by the weights squared and not by a variation of no re-weight and 2x the weight (instead of weight squared)?
    Weighting by the weight squared is the TOP PAG recommendation for estimating the upwards systematic fluctuation of this effect: see their twiki on the matter.

  • Sec. 3.3 & 3.4: what bothesr me a bit is the fact that the eta regions for e (2.5) and mu (2.1) are different for tight but for loose you use 2.5 for mu, too. Can this difference in choice cause any effect on the CR estimates?
    The requirement |eta|<2.1 for tight muons is due to the SingleMuon trigger requiring it, and is not necessary for other/additional muons in the event. The loose lepton veto is kept constant between signal and control regions, so this should not affect control regions. Where it could affect the analysis is if the object kinematics or MET differed greatly between ttbar-->(e+e, e+mu, mu+mu), in which case the different efficiencies for each combination would be important; however this is not the case.
    The |eta|<2.1 cut in the trigger does make the tight muon requirement tighter than for the tight electron, which is one cause of the difference between electron and muon event counts. Beyond all this, these vetoes are what is recommended by the TOP PAG for semi-leptonic selections.

  • Tab. 8: why is there a lower cut of 0.001 on sigma_IetaIeta? Is this standard photon ID? I don't recall ...
    This cut, and the one on sigma_IphiIphi, are for ECAL spike removal and general anomaly protection. They are not required by EGamma but are fairly common; for example the 8 TeV inclusive search used these as well. Concerning its effect, zero otherwise selected photons in the TTGamma MC sample fail these cuts.

  • Fig. 9: the fits seem okay around the Z region but are less from optimal away from the Z. Is this anything to worry about? Was is treated in a systematic uncertainty?
    While not considered important for the signal regions, what you are seeing is the lack of Drell Yan for 20 GeV < M(lep lep) < 50 GeV, which in Figure 9 is exaggerated compared to signal regions due to the di-lepton selection here. You can see in Figure 9 that when requiring b-jets (the top two plots) this is not an issue.
    What can be done to study the effect of this is to re-do the template fit excluding this low-mass region, and see that the scale factor doesn't change much (it should be dominated by on-mass Z-->dilepton). Furthermore, since these events are more accurately Z/gamma* Drell Yan, the fit range can be extended to higher masses to observe how much the scale factors change. Keep in mind here that the non-btagged muon channel (bottom right of Fig. 9) is not used in the analysis: the non-btagged electron sample is only useful as an input to the electron mis-id rate measurement. When varying the fit range of Figure 9, the scale factors for this are:
Z(gamma) SF in channel Normal (0 - 180) 50 - 180 50 - 600
ele_jjj 1.24 1.26 1.25
ele_bjj 1.38 1.39 1.39
muon_bjj 1.60 1.62 1.62
These are within the fit uncertainties summarized in Table 14 of the AN. So in short this is not seen as a cause for concern, and was not given its own systematic. Plots of the results for this are shown below:
Normal (0 - 180) 50 - 180 50 - 600
z_mass_ele_jjj_0_180.png x y

  • Sec. 4.4.1, bottom of p. 21: how is the overall scale adjustment taken into account in the analysis? From Fig. 15 is seems to be a good 10% effect.
    In lines 357-360 and 376-378 explain, this scale adjustment is not actually applied to the final result. The goal of this section is to ask: if we were to adjust the photon purity with this scale factor, would the distribution of MET change noticeably? In isolating only the shape of MET in the final evaluation, the extra 100% systematic on background normalization would wash away this overall 10% effect, but would not wash away a change in the shape. You can also see this is a 10% effect from the scale factors in Table 16.

  • Tab. 15: the discrepancy between Fit and MC seems to be bigger in sigma_IetaIeta? Why not just using chHadIso? Or at least having a systematics that using only one or the other? Back to the previous answer, neither is actually used in the final results so a systematic reflecting the difference isn't warranted. As for the discrepancy in sigma_IetaIeta here, the tt+gamma cross section measurement also encountered this and treated it in the same way. As you say, the way both analysis handled this was to just use chHadIso. The low sigma_IetaIeta is seen to be from some error in the shower evolution of photons in GEANT4, however I haven't found a more informative explanation of this yet.
    If you look in the PAS in lines 147-151 indirectly touch on this question, because the 5% variation is from a very maximal case where you completely replace the MET from ttjets with tt+gamma's shape, or vice versa -- ie, if you were to perform a template fit like chHadIso or sigma_IetaIeta and find a maximal disagreement, the effect on MET would just be 5% bin-by-bin variations.

Manfred Paulini on PAS v0:

Anthony Barker on AN v3:

Anthony Barker on PAS v0:

-- BrianFrancis - 2015-12-10

Edit | Attach | Watch | Print version | History: r9 | r4 < r3 < r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r1 - 2015-12-10 - BrianFrancis
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    Main All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback