[Rivet] CMS_2015_I1397174

[Markus Seidel]

Hi Andy,

great, thanks a lot!
I hope we move to Rivet 2.5.2 in CMS soon, so that we can use the 
PartonicTops projection also for other (old) analyses.

Cheers,
Markus

Am 18.09.2016 um 18:07 schrieb Andy Buckley:
> 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
>>>>>>>
>>>>>
>>>>>
>>>
>>>
>
>