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

[James William Monk]

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