[Rivet] DressedLeptons and photons from tau decays

[Markus Seidel]

Hi Andy,

for the "backporting" my idea was to just include a custom projection 
"PhotonsThatWeWantToUse" and feed that into the DressedLeptons projection.
The PhotonsThatWeWantToUse would be based on what you decide to 
implement for the upcoming Rivet code.

But indeed, if I see correctly the PromptFinalState(fs, true, true) 
would be equivalent to my other suggestion, i.e., give us all photons 
that are not from hadron.
(I find it very elegant to use the DressedLeptons projection, so I'm a 
bit reluctant to do it by hand ;))

Cheers,
Markus

Am 27.02.2017 um 17:50 schrieb 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
>>>>>
>>>
>>>
>
>