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

[Andy Buckley]

On 01/07/16 16:18, Christian Gutschow wrote:
> Thanks for clarifying, Andy! I see the problem about the recursion now.
> Will have to think about your points more carefully, but just to comment
> on this one:
>
>> * 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!!)
>
> What the ZFinder::particles() would actually return is the 4-momentum
> combination of the (dressed) leptons for a given pair, no? Are we
> currently assigning a pid to the ZFinder::bosons()? The pid = 23 makes
> it look like it's the actual Z boson from the event record which (i)
> doesn’t exist depending on the generator and (ii) I could imagine people
> will use to cook up all sorts of Born-level nonsense not explicit enough
> about this.

The interface promises to return a Particle object (or rather a vector 
of them), so it can't just be a bare momentum object... and cf. all this 
discussion it needs to know about its contents, etc. I guess we could 
set the Particle::pid() to 0, but for now we set it to 23.

And yes, caveat emptor re. Born Z's etc.! Not sure the solution to that 
is technical, unless we wanted to call it a "PseudoZFinder" cf. pseudo-tops.

> How about components() for "constituent, maybe composite" and
> constituents() for indivisible constituents then?

Actually, I rather like that. Only issue is that the words are quite 
similar, but I think it's neat. Other people's thoughts and suggestions?

Cheers,
Andy


>> On 1 Jul 2016, at 14:54, Andy Buckley <a.g.buckley at gmail.com
>> <mailto:a.g.buckley at gmail.com>> wrote:
>>
>> 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>
>>>> <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><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><mailto:chris.g at cern.ch>
>>>
>>>
>>>
>>>
>>
>>
>> --
>> Dr Andy Buckley, Lecturer / Royal Society University Research Fellow
>> Particle Physics Expt Group, University of Glasgow
>
>
>
>
>   —
>
>   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