[Rivet] Common ParticleFinder interface for accessing composite vs. constituent particles? + 2.5.0 release plan

[Andy Buckley]

Thanks Chris, great to have feedback.

These are some of the awkward points I've been juggling internally. I 
pretty much agree with your first 3 paragraphs and think they are what 
I'm saying. I absolutely agree that if running an XFinder, then I expect 
the Particles to be returned by XFinder::particles() to be Xs. Which is 
not the current behaviour.

One nuance: if ZFinder is a ParticleFinder (I think it is...) then the 
bosons would also be accessed through the inherited particles() method. 
Of course we won't want to apply smearing to Z bosons, but it would be 
an obvious consequence of defining that particles/constituents access on 
the base class, and a const ParticleFinder& is what SmearedParticles 
accepts as an input.

Other points:

* consitutents() vs rawConstituents()/etc.: the distinction is 
recursion. Let's say I have a ZFinder, and I ask it for its particles(). 
It returns me a vector of Particles with pid = 23. I then call 
Particle:: constituents() on each of those and what do I get? I'd expect 
the two DressedLeptons*. And if I call constituents() on each of 
_those_, I finally get down to the fundamental bare leptons and photons 
which have corresponding GenParticles.
   So my distinction between Particle::constituents() and 
Particle::rawConstituents() (please, a better name!) is that the latter 
would recurse to find the indivisible consitutents, possibly through 
several layers of composition. Make sense? I guess an indivisible would 
be defined as a Particle with an empty constituents vector (the 
existence of which is essential if Particles are to have finite size!!)

* bosons() vs. boson(): IIRC the ZFinder code says something specific 
about only being able to find one candidate boson per event. But since 
C++ has no NULL/None "invalid value" that can be returned from a boson() 
function (unless using pointers), we started with bosons() and hence 
lots of code that looked like bosons()[0]. boson() is just syntactic 
sugar for that -- I think it throws an exception if there is no boson to 
be returned, but haven't explicitly checked for that.

* Thanks for input on the "release something imperfect, soon". I also 
think it's the way forward. Any objections? "Release early, release 
often", as Linus said.

Cheers,
Andy

* Eek. Here's an awkwardness: a vector<Particle> will have sliced each 
contained DressedParticle down to its Particle base class. To use them 
as DressedLeptons would require a dynamic_cast (or reinterpret_cast?), 
or be impossible. Hopefully adding constituent-awareness to Particle 
will make DressedLepton unnecessary so we can avoid this problem, but 
this is the sort of thing that makes seemingly simple reorganisations 
difficult.


On 01/07/16 14:27, Christian Gutschow wrote:
> Hi Andy,
>
> why do we need a new name and cannot stick to particles and
> constituents, but make them distinct? Is there a technical reason or is
> it just backward compatibility?
>
> Ignoring the status quo, naively I would think that if I call
> particles(), say on the DressedLeptons projection, it should return what
> I asked it to find, i.e. the dressed leptons, whereas if I run
> constituents(), it will give me the raw particles used in the making of
> dressed leptons, all of them. Whereas if I run constituents on an
> individual DressedLepton object, it will only give me the raw particles
> for the individual dressed lepton.
>
> If I apply the same logic to the ZFinder, I would think we need
> something like bosons() which returns the (dressed) dilepton pairs, on
> each of which I can call particles() which will give me the two dressed
> leptons (for said candidate), and on each of those I can call
> constituents(), which will give me the bare electron and the photons, as
> above. If I then ask for the smeared versions, I would get a smeared
> dressed lepton on the particles() level and individually smeared bare
> leptons and photons on the constituent level.
>
> I think this is more or less what you’re suggesting in step a), I’m just
> not sure why we need rawConstituents or simpleConstituents and can’t
> just use constituents for this.
>
> Right now, the ZFinder already has the plural bosons(), but then we also
> have the singular boson() which doesn’t make any sense if there are
> multiple bosons to be found, so why exactly is it there in the first
> place? I’m also unsure about what the ZFinder is going to give me when I
> call constituents() on the projection, especially if there are multiple
> Z candidates. (Is it the bosons? Is it an even number of dressed
> leptons? How are they ordered? …)
>
> Anyway, the distinction between particles and constituents may work
> conceptually for composite particles, but admittedly the same logic
> doesn’t work with jets. At the moment we can call either particles or
> constituents on a Jet object and they will both return the same thing,
> which I think is fine for Jet objects, but it’s not immediately obvious
> that these two are aliases for one another in this case. Perhaps that’s
> not really a problem though?
>
> I’m all in favour of your last suggestion, i.e. pushing out something
> 95% useful asap. For all we know, we may end up receiving some feedback
> which could well influence the ironing out of the remaining details.
>
> Cheers,
> Chris
>
>
>> On 29 Jun 2016, at 14:00, Andy Buckley <andy.buckley at cern.ch
>> <mailto:andy.buckley at cern.ch>> wrote:
>>
>> Hi,
>>
>> Time to grasp a nettle. Remember some weeks back, when putting
>> together a smearing machinery for Rivet, we had some discussion about
>> how to uniformly access composite vs. simple particles from "finder"
>> projections? It seemed awkward, so we stopped.
>>
>> The reason it's important is that at the moment the "finder"
>> projections, more by consensus than explicit design, only return
>> *simple* (i.e. indivisible & directly matched to HepMC objects)
>> constituent particles via the particles() method. There is no
>> equivalent uniform method for accessing composite particles like
>> reconstructed Z bosons or dressed leptons.
>>
>> And that creates a problem, because if I apply an electron smearing or
>> efficiency to an IdentifiedFinalState of simple electrons then what I
>> get out is reasonable, but if I apply the same thing to a
>> DressedLeptons projection then what comes out is a list of simple
>> electrons and photons, which have all had the electron efficiencies
>> applied to them individually. Bad idea.
>>
>> I think to fix this we have to:
>>
>> a) provide *two* methods on the ParticleFinder base class: one for the
>> composite particles that are the semantic output of that projection,
>> i.e. the things we asked it to "find"; and a second for the
>> constituents of those things. I personally feel that changing the
>> meaning of particles() to mean "semantic 'found' particles, maybe
>> composite", and adding a new simpleParticles(), rawParticles() or
>> similar is nicer (but more work) than keeping particles() as-is and
>> adding some even-more-awkwardly named maybeCompositeParticles().
>>
>> b) implement these by adding some access to constituents to the
>> Particle interface, e.g. const vector<Particle>&
>> Particle::constituents(). And maybe a recursively-assembled
>> Particle::rawConstituents() or simpleConstituents(): good, short &
>> intuitive naming ideas welcome! Care needed to avoid object size
>> blow-ups. Use these methods to implement the
>> ParticleFinder::rawParticles() etc.
>>
>> I think this can work --  but it's not clear to me whether the
>> implementation will be smooth or full of pitfalls. Probably we should
>> plan for the latter. Any particular concerns or better ideas?
>>
>> Now we've got 2.5.0beta2 out, and the next step should be a full 2.5.0
>> release. *Ideally* well before the tutorial at CERN on 14th (?) July,
>> so the participants can use that and play with the new machinery. And
>> I'm wondering if we can fix this issue in time for that, or should we
>> put it out now for BSMers to play with and just warn to stick to using
>> projections with "simple" returns for now -- which most will be happy
>> to do, because BSM analyses don't usually bother with details like
>> dressing their leptons. I am drifting toward pushing "full
>> consistency" back to 2.6.0 (since an API change would be involved) and
>> giving them something 95% useful asap. Thoughts?
>>
>> 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 <mailto:Rivet at projects.hepforge.org>
>> https://www.hepforge.org/lists/listinfo/rivet
>
>
>
>
>   —
>
>   Dr. Christian Gütschow
>
>   University College London
>   Department of Physics and Astronomy
>   Gower Street
>   London WC1E 6BT
>
>   > D10 Physics Building
>   > +44 (0)20 7679 3775
>   > chris.g at cern.ch <mailto:chris.g at cern.ch>
>
>
>
>


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