[Rivet] DressedLeptons and photons from tau decays

[Markus Seidel]

Hi Andy,

yes, I was referring to the call of fromTau, indeed.

I would be happy with any solution that we can backport to 2.4.2 with a 
custom photon projection. (We made an effort to call Rivet projections 
directly in the CMS software, where the release for 2016 data analysis 
is bound to Rivet 2.4.2, and it is not trivial to update.)

I think your proposed solution should work and deliver physics as 
intended :)

Just calling !fromHadron instead of !fromDecay would also solve the 
issue for many use cases I think.
(Only photons directly from the hadronic tau (not its hadron daughters) 
might get clustered with a electron/muon going into the same direction)

Cheers,
Markus

Am 24/02/2017 um 20:20 schrieb Andy Buckley:
> Hi Markus,
>
> Sorry it's taken a while to get back to you on this -- I had a very busy
> period. Taking advantage of a train journey to reply!
>
> It took a little digging to work out what code you were referring to:
> that's a couple of steps away, in Particle::fromTau, right? Which is
> called via Particle::fromDecay, if DressedLeptons is called with the
> fromDecay=true option. I think you're right about the unintended
> consequence, though.
>
> I agree this stuff is a bit messy: when I wrote it, I didn't want to
> proliferate a multitude of options about vetoing photons
> directly/indirectly from hadrons and/or all/hadronic taus -- you get the
> idea from all the slashes, hopefully! But in retrospect I think I should
> have probably provided a isHadronicTau Particle classifier function*,
> and used the logic fromHadronicDecay = fromHadron || fromHadronicTau.
> "fromDecay" is too vague.
>
> Would that meet your approval: if !fromDecay, don't use any photons for
> clustering which either have an unstable hadron or a prompt,
> hadronically decaying tau in their history?
>
> Thanks,
> Andy
>
> * Or just a generic hasHadronic/LeptonicDecay? That's the problem with
> this stuff -- so many possible combinations, but which are the most
> natural/flexible/convenient?! I'm open to suggestions!
>
>
>
> On 08/02/17 08:06, Markus Seidel wrote:
>> Hi Andy, hi Frank,
>>
>> I was not so much concerned about the photons directly from the tau but
>> about those from the tau daughter leptons.
>>
>> If we look at these lines:
>>>     return _hasRelativeWith(HepMC::ancestors, [](const Particle& p){
>>>         return p.genParticle()->status() == 2 && isTau(p);
>>>       });
>>
>> It checks if there was a tau in the photon ancestors.
>> So if we have a chain tau->electron->photon, the photon is not used for
>> the dressed electron because there is a tau upwards?
>>
>> Is my interpretation correct, or do I just misunderstand the meaning of
>> HepMC::ancestors?
>>
>> Cheers,
>> Markus
>>
>> Am 07.02.2017 um 21:49 schrieb Andy Buckley:
>>> On 06/02/17 15:07, Markus Seidel wrote:
>>>> Dear all,
>>>>
>>>> what is the reason for excluding photons from tau decays from the
>>>> DressedLeptons?
>>>>
>>>> Doesn't this prevent to cluster photons from electrons from taus?
>>>
>>> Hi Markus,
>>>
>>> I think the projection was probably written considering (as is usually
>>> the case, in my experience) leptonic taus to only be observed via their
>>> muon or electron child -- and it is the child rather than the parent
>>> whose momentum vector is used as the centre of the dressing cone.
>>>
>>> DressedLeptons isn't designed for hadronic taus, and I suspect this rule
>>> is in there to avoid "contamination" from hadronic tau decay photons
>>> into prompt electron or muon dressing.
>>>
>>> You're probably right that there's an issue in how it's implemented,
>>> though: it does seem reasonable, or at least would be a reasonable
>>> option, to include photons directly from a prompt leptonic tau when
>>> dressing that tau's electron/muon child. The neutrinos are still
>>> "missing", so it may not help much, but is physically well-defined. I
>>> *could* add an option flag of that sort, to restrict the veto to
>>> *hadronic* taus only: is that what you had in mind?
>>>
>>> Frank Siegert may know more: he originally implemented DressedLeptons
>>> (then called ClusteredLeptons), and I can'd remember if he or I added
>>> the tau photon veto! Frank??
>>>
>>> Andy
>>>
>
>