[Rivet] CMS_2015_I1397174

Andy Buckley andy.buckley at cern.ch
Sun 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