|
[Rivet] CMS_2015_I1397174Andy Buckley andy.buckley at cern.chSun Sep 18 17:07:45 BST 2016
Hi Markus, Great! I've fixed & tidied the algorithm (attached) and plot labels, and made validation plots with 300k LO Pythia inclusive ttbar events: https://users.hepforge.org/~buckley/rivet-cmspartontop/CMS_2015_I1397174/index.html The xsec is a bit low as expected from LO, but it all looks very consistent to me. I'll add it to the Rivet core. Thanks, Andy On 17/09/16 15:30, Markus Seidel wrote: > Hi Andy, > > thanks, this is good news! > > It is only the event counters that divide by abs(weight), also in the > new CMS_2016_I1473674. I cannot think of a good reason for that anymore. > > You are also correct about the second point: the gap fractions should be > implemented as Profile1D, filling 0 or 1 for each bin and event. > > I can do the changes next week (unless you already did them). > > Cheers, > Markus > > On 16.09.2016 23:20, Andy Buckley wrote: >> Hi again Markus, >> >> There will be a PartonicTops projection in the upcoming Rivet 2.5.2 >> release, and today I went through your analysis code to convert it... it >> looks pretty good, so hopefully we can finally get it into that >> approaching release. >> >> The one thing that looks *really* weird is that the analysis doesn't >> fill the histograms with the event weights, but with their *signs*. That >> will do very strange things in event sets with e.g. weighted kinematic >> enhancement. Is there a reason for it? >> >> I also noticed that your "gap" histograms are filled with >> weight*binwidth, so that the resulting histograms are like bar plots >> (where the width is not physically meaningful) rather than dN/dx >> differential histograms. I've not checked exactly what is being filled, >> but could you quickly verify that this is correct? Is it perhaps a way >> to get the central value (but not error) behaviour of a profile >> histogram via a standard one? >> >> Cheers, >> Andy >> >> >> >> On 19/07/16 15:38, Markus Seidel wrote: >>> Hi Andy, >>> >>> I hope that future analyses just look for two high-pt leptons and are >>> easier to implement then... >>> The problem is that many of the 8 TeV analyses explicitly veto W>tau >>> decays. In dilepton it should be possible to search for exactly 2 >>> lepton+neutrino pairs that have a mass close to 80.4 GeV but in >>> lepton+jets we would need to be able to identify hadronic tau decays to >>> veto lepton+tau(had)+jets on particle level. >>> >>> In fact, I forgot about the piece of code that deals with additional b >>> jets. This is indeed heavily reliant on the HepMC record. We might >>> consider splitting it in two analyses... >>> >>> The b-tag is indeed without cut on the hadron pt. Is there a compelling >>> reason for a cut? I think we discussed it once in the LHCTopWG but >>> without outcome. >>> >>> Cheers, >>> Markus >>> >>> >>> Am 19.07.2016 um 16:19 schrieb Andy Buckley: >>>> Requiring exactly 2 prompt (i.e. not-from-hadron-decay) charged leptons >>>> with substantial pT should do 99% of what's required, I think! This is >>>> pretty easy to do. >>>> >>>> But I saw some code in there which also categorises b-jets according to >>>> whether they come from top decay or not... so maybe the connection is >>>> deeper? Complex "HepMC digging" analyses like this can take a while for >>>> us to integrate, because we really need to go through them in detail >>>> and >>>> make sure everything makes sense & uses appropriate machinery. >>>> >>>> Andy >>>> >>>> PS. By the way, is there really no pT cut on the b-hadrons that you >>>> consider as tagging a jet? You can use e.g. jet.bTagged(Cuts::pT > >>>> 1*GeV), for example, or a similar argument to Jet::bTags() >>>> >>>> >>>> On 19/07/16 15:13, Markus Seidel wrote: >>>>> Hi Andy, >>>>> >>>>> thanks for the feedback! >>>>> >>>>> Actually, the parton level stuff is needed here only for selecting the >>>>> ttbar decay channel (dilepton ee/emu/mumu). Is there a better way >>>>> to do >>>>> that? >>>>> >>>>> Cheers, >>>>> Markus >>>>> >>>>> Am 19.07.2016 um 15:57 schrieb Andy Buckley: >>>>>> On 19/07/16 14:47, Markus Seidel wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> for some reason this analysis did not make it to the mailing list >>>>>>> after >>>>>>> uploading (in April): >>>>>>> https://www.hepforge.org/archive/rivet/contrib/NEW/CMS_2015_I1397174.tgz >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> It contains jet multiplicity, pt, eta, etc... measured in ttbar >>>>>>> events >>>>>>> at 8 TeV. >>>>>> >>>>>> Hi Markus, >>>>>> >>>>>> We've not yet incorporated this one because (as the code >>>>>> acknowledges) >>>>>> it uses a non-portable partonic top quark definition and introduces a >>>>>> lot of custom machinery that we need to merge carefully into the >>>>>> Rivet >>>>>> system. >>>>>> >>>>>> We've decided to allow partonic top definitions in "official" Rivet >>>>>> analyses, but have not provided the central machinery for that yet. >>>>>> When >>>>>> it is ready, this analysis will still require significant effort to >>>>>> include in the distribution... but in the meantime the code is still >>>>>> publicly available in the contrib directory for anyone who wants to >>>>>> use it. >>>>>> >>>>>> Cheers, >>>>>> Andy >>>>>> >>>> >>>> >> >> -- Dr Andy Buckley, Lecturer / Royal Society University Research Fellow Particle Physics Expt Group, University of Glasgow -------------- next part -------------- A non-text attachment was scrubbed... Name: CMS_2015_I1397174.cc Type: text/x-c++src Size: 17315 bytes Desc: not available URL: <https://www.hepforge.org/lists-archive/rivet/attachments/20160918/da2b1325/attachment.cc>
More information about the Rivet mailing list |