[Rivet] CMS_2015_I1397174

[Markus Seidel]

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
>>>>>
>>>
>>>
>
>