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

[Andy Buckley]

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