|
[Rivet] ParticleFinder/FinalState compound & constituent particle reportingAndy Buckley andy.buckley at cern.chTue Apr 19 12:33:00 BST 2016
Gah, you went straight to the thing I had hoped would be a semi-ignorable detail ;-) My immediate reaction is that only the two extremes are predictable: a projection like WFinder finds Ws, so those are the "particles" -- the "most compound" object. And the raw particles of the WFinder are the union of the raw particles of any contained projections. For WFinder guess this would just be the DressedLepton's raw particles, since we now use "reconstructed" MET rather than identifying a final-state neutrino with an associated GenParticle*. This can then be chained further, so e.g. a hypothetical TopFinder's particles() are tops, and its raw particles are the union of its jets' raw particles and its W's raw particles, which in turn uses the dressed lepton's raw particles. But this has been a useful exercise, since in this case we're not interested in the raw particles of every dressed lepton in the event, but only the ones associated to the lepton pulled into the W, and only the Ws used in the top construction. So we maybe also need a rawParticles() method on Particle itself? Or something of that kind... I'll leave that unstructured thought there, and let someone else take the next step. It feels like the sort of loose thread that threatens to unravel the beautifully knitted jumper ;-) Get pulling... Andy On 19/04/16 12:19, Frank Siegert wrote: > Hi Andy, > > sounds like a neat idea. But what if a projection would return > different types of compound particles, e.g. the ZFinder could be asked > for its constituents() (which are the dressed leptons) and also for > the bosons(). Which one would you return through compoundParticles()? > > Cheers, > Frank > > > On 19 April 2016 at 13:14, Andy Buckley <andy.buckley at cern.ch> wrote: >> Hi all, >> >> I realised while putting finishing touches on the Rivet 2.5 smearing >> mechanisms that we need a standardised interface for distinctly returning >> "compound particles" created by a projection, and for returning the raw >> constituent particles from which they are created. >> >> In many cases these are the same thing. For example, a FinalState's >> particles() method returns all raw particles matching the cuts, and there >> are no compound particles. But WFinder, ZFinder, DressedLeptons, and >> arguably things like TauFinder are able to return both compound particles -- >> the Ws, Zs, and dressed leptons -- and the raw particles from which they are >> built. >> >> At the moment, the particles() method always returns the raw ones, and there >> are special methods like WFinder::bosons() and >> DressedLeptons::dressedLeptons() to get the compounds. But for smearing we >> are really interested in the "most compound" objects returned by a >> projection, so I can use a SmearedParticles projection to wrap either an >> IdentifiedFinalState of raw electrons, or a DressedLeptons wrapper of the >> same. At the moment if I make a >> SmearedParticles(DressedLeptons(IdentifiedFinalState)), then the electron >> smearing will be applied equally to raw electrons and raw photons, and all >> those smeared raw particles will be returned -- oops. >> >> I don't think this is something in need of fixing for the 2.5.0beta1 >> (hopefully to go out today?), but it should be done for 2.5.0 proper. I >> suggest adding rawParticles() and compoundParticles() methods to >> ParticleFinder and making sure that each derived class returns the >> appropriate collection. Or, since I find it rather odd that >> WFinder::particles(), DressedLeptons::particles(), etc. do *not* currently >> return Ws, dressed leptons, etc., we could change those methods to do so, >> and just add rawParticles() as the standard hook for retrieving objects that >> come direct from HepMC -- and adapt the veto-on-FS / remainingFinalState >> mechanisms to use rawParticles() rather than particles(). I very much doubt >> anyone is using that behaviour directly in user code. I prefer the latter >> for several reasons, but this is the sort of thing that should be discussed. >> Feedback, please!! >> >> 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
More information about the Rivet mailing list |