[Rivet] DressedLeptons and photons from tau decays

[Andy Buckley]

Of course, I forgot there was that option. Indeed, that's the neatest 
way: good to be reminded that we occasionally got the design right ;-)

Cheers,
Andy


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


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