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

[Christian Gutschow]

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>




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