[Rivet] Jet "pair-smearing" and tagging efficiencies

[Chris Pollard]

Hi Andy, all,

I'm very confused ;-)

So the problem is not that we have one function for b-tagging b-jets,
> another for b-tagging light jets, etc., but that we have one sort of
> efficiency function for b-tagging, one for c-tagging, and one for jet
> reco... and all have the same function signature. That means that I need to
> treat each tagging as being something distinct from the rest of the
> smearing/efficiency simulation, because the compiler can't tell if a
> Jet->double function means reco efficiency or some sort of tagging (which
> one?).


Can you explain this perhaps with an example? Why does the compiler need to
know the difference? I would have thought that the analysis would have to
tell the compiler explicitly this kind of thing, but it sounds like you're
aiming for something more automated.

Chris

On Tue, Jul 18, 2017 at 10:16 AM, Andy Buckley <andy.buckley at cern.ch> wrote:

> Hi James!
>
> We handle fakes (i.e. mistags) with the same function that does true-tag
> efficiency. The user-supplied tagging efficiency function can ask questions
> of the truth jet, like bTagged() and cTagged(), so the typical
> implementation is a fall-back of b-tagging rates for true b-jets, then true
> c-jets, then maybe true taus, then light.
>
> You're right that in general these should be mappings on *any* physics
> object, and I have some plans for that... but for now Particle and Jet are
> a bit too distinct.
>
> So the problem is not that we have one function for b-tagging b-jets,
> another for b-tagging light jets, etc., but that we have one sort of
> efficiency function for b-tagging, one for c-tagging, and one for jet
> reco... and all have the same function signature. That means that I need to
> treat each tagging as being something distinct from the rest of the
> smearing/efficiency simulation, because the compiler can't tell if a
> Jet->double function means reco efficiency or some sort of tagging (which
> one?). Thoughts on how to get around this without making the user do
> something horrible?
>
> Andy
>
>
>
> On 18/07/17 08:08, James William Monk wrote:
>
>> Hi Andy,
>>
>> (I know I’m pretty quiet on this list, but I do still lurk!)
>>
>> Do you handle fakes separately?  If not, why does the API need to
>> distinguish between light and b-jets?  It is legitimate to ask it “what is
>> the probability that this light jet is reconstructed as a b-jet.”  In fact,
>> you ought to be able to ask that about any object, not just jets.  From an
>> analysis point of view, all you care about is how many b-jets you
>> reconstruct, so does it make sense to distinguish between fakes and true
>> jets (other than for debugging purposes)?
>>
>> cheers,
>>
>> James
>>
>>
>> On 17 Jul 2017, at 18:03, Andy Buckley <andy.buckley at cern.ch> wrote:
>>>
>>> Hi Riveters,
>>>
>>> A C++ design question for you all... ;-)
>>>
>>> Those who were at the Lunga hackfest last year (yes, we want to do it
>>> again!) might remember that we decided to convert the efficiency function +
>>> smearing function approach to our fast-sim, to instead take an ordered list
>>> of unified transform functions which would operate on, and return,
>>> {object,eff} *pairs*.
>>>
>>> At the time, Karl implemented a bunch of macro trickery on a branch, and
>>> I recently converted it with some C++11 magic to a funkier form that didn't
>>> require users (i.e. analysis authors) to add confusing make_pair calls to
>>> their only-smearing or only-efficiency functions (and lambdas).
>>>
>>> This works beautifully for SmearedParticles -- C++ nerds might want to
>>> look up variadic template functions and geek out -- but with SmearedJets
>>> there's an additional complication: tagging. From function signatures alone
>>> there's nothing to distinguish a Jet->double jet reco efficiency function
>>> (usually ~100% and ignorable) from a Jet->double b-tagging function
>>> (important), or indeed from a Jet->double c-tagging function (haven't used
>>> it yet, but never say never). Or tau tagging, which doesn't exist yet,
>>> but...
>>>
>>> So, any bright ideas of how we can distinguish reco/b-tag/c-tag/tau-tag
>>> efficiency functions? A possibility would be to return not just a double,
>>> but a {pid,eff} = {int,double} pair where the first element is the PID. But
>>> I'm hoping you can suggest something nicer!
>>>
>>> Not a critical thing, but if we're going to polish the interface like
>>> this, we might as well do it properly. This would also have the nice, in
>>> principle, effect of allowing tagging efficiencies to be applied at a
>>> user-defined stage of reconstruction: at the moment the tagging is all
>>> applied based on the post-smearing kinematics.
>>>
>>> Cheers,
>>> Andy
>>>
>>> --
>>> Dr Andy Buckley, Lecturer / Royal Society University Research Fellow
>>> Particle Physics Expt Group, University of Glasgow
>>> _______________________________________________
>>> Rivet mailing list
>>> Rivet at projects.hepforge.org
>>> https://www.hepforge.org/lists/listinfo/rivet
>>>
>>
>>
>
> --
> Dr Andy Buckley, Lecturer / Royal Society University Research Fellow
> Particle Physics Expt Group, University of Glasgow
> _______________________________________________
> Rivet mailing list
> Rivet at projects.hepforge.org
> https://www.hepforge.org/lists/listinfo/rivet
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.hepforge.org/lists-archive/rivet/attachments/20170807/76abc481/attachment.html>