[Rivet] Work plan

[Frank Siegert]

Andy Buckley, Thursday 12 March 2009:
> Frank Siegert wrote:
> > I've got one more: We have so many pp -> Z (+ jets) analyses and all
> > do something very similar for finding the Z candidate, which doesn't
> > look exactly pretty. Maybe we can factor this out into a common
> > projection? I'd work on this, if you agree that would be useful.
>
> I think it would, particularly as a central place to keep any
> enhancements like the photon clustering. Your list of flexible features
> is what I would think of. But please keep the interface relatively
> clean, i.e. don't require 10 constructor arguments! ;)

Ok.

> > The projection should be able to return the Z candidates as
> > vector<pair<Particle, Particle> > and the particles not contained in
> > the Z candidate (such that one can run e.g. a jet algorithm on them).
>
> I think we have a final state projection at the moment which will veto
> particles in a supplied list. It might be a good idea to not replicate
> this behaviour, or at least to use that vetoing FS projection
> internally.

Yes, that is a good idea. 
I agree that it should not be a monolithic Projection, but be constructed 
in the analyses out of the following projections (and their arguments):

IdentifiedFinalState: pTmin, etamin, etamax, PdgIds
InvMassFinalState: IdentifiedFinalState, m2_min, m2_max
                   (veto if size()!=2)
PhotonClustering: FinalState, InvMassFinalState, dRmax
                  this should store all FinalState photons found with 
                  dR<dRmax around the particles in InvMassFinalState

So the photon clustering would be a new projection.
To calculate Z quantities, one then adds all momenta from the 
InvMassFinalState and the PhotonClustering. 
To calculate jet quantities, one would use a vetoed final state like:
VetoedFinalState(VetoedFinalState(FinalState).addVetoOnThisFinalState(InvMassFinalState)).addVetoOnThisFinalState(PhotonClustering)

Does that sound reasonable?

One addition that might be necessary for some analyses: Allow multiple eta 
ranges in the (Identified)FinalState projection. Do you think we can 
introduce that? This might be useful in completely different contexts as 
well.

Cheers,
Frank