[Rivet] ParticleFinder/FinalState compound & constituent particle reporting

[Frank Siegert]

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