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

[Christian Gutschow]

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.

Ok, that’s what I thought. Pid = 0 makes more sense to me than pid = 23, but I guess that’s debatable. PseudoZFinder is probably (hopefully?) not necessary…

Cheers,
Chris


On 1 Jul 2016, at 16:28, Andy Buckley <a.g.buckley at gmail.com<mailto:a.g.buckley at gmail.com>> wrote:

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>
<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>
<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><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><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> <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>




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.hepforge.org/lists-archive/rivet/attachments/20160701/666b578a/attachment.html>