[Rivet] CMS_2015_I1397174

[Andy Buckley]

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.

The PromptFinalState can be told to veto leptonic tau decays, so 
hopefully this can be handled. Certainly this could be done in a 
fiducial pseudotop analysis that explicitly reconstructs (loose) W's. 
And of course in MC-land we have the freedom to specify that the 
analysis should be run with leptonic ttbar events, so the real-world's 
background cuts aren't always needed!

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

Ok, well keep us in the loop and maybe we can help next time! I'll let 
you know how we get on with integrating this one and the rest of our 
"standard" partonic top machinery -- I'll try to make it largely 
compatible with yours.

And it has wider application: partonic top data analyses are probably 
going to keep coming, and obviously they contain valuable information... 
so while they're awkward in some ways we do want to be able to encode 
them in Rivet. Just without doing anything really dangerous or wrong, 
hence being a bit timid about adding it!

Thanks for providing a concrete example for us to worry about ;-)

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

Just wondering since it seemed a strange fiducial definition to me. I 
guess there is a small amount of extrapolation there, but it should be 
pretty rare for the b to be below thresholds when the jet is energetic, 
especially for those from top decay.

Andy


> 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