[Rivet] DressedLeptons and photons from tau decays

[Andy Buckley]

Thanks for the clarification. I will modify DressedLeptons in this 
fashion for future releases.

But when you say "backport to 2.4.2", do you mean a modification to the 
analysis or to the projection? I was proposing to make a change in 
DressedLeptons, but that would require patching the Rivet core. In the 
analysis you could manually do the same as the projection does:

declare(PromptFinalState(Cuts::pid == PID::PHOTON, true), 
"PromptPhotons"); //< can't remember if Cuts::pid is in 242...

...

const Particles promptphotons = apply<FinalState>(event, 
"PromptPhotons").particles();

Particles dressedleptons;
for (const Particle& l : leptons) {
   FourMomentum mom = l.mom();
   sum(filter_select(promptphotons, deltaRLess(l, 0.2)), mom);
   dressedleptons.push_back(Particle(l.pid(), mom, l.origin());
}

Or maybe a bit more complicated if there's any danger of 
double-counting. I may have made use of some post-2.4.2 features there, 
but sum, filter_select, and deltaRLess can be easily replicated in a few 
lines of normal for-loop.

I'll have a bit more of a think about what to do re. hadronic taus -- as 
you say, the "from hadron" already captures most, if not everything, 
that was intended... but I suppose it is consistent and more complete to 
also veto photons from a prompt tau which decays hadronically.

Andy


On 27/02/17 14:46, Markus Seidel wrote:
> 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
>>>>
>>
>>


-- 
Dr Andy Buckley, Lecturer / Royal Society University Research Fellow
Particle Physics Expt Group, University of Glasgow