[Rivet] FastJets caching (was: [Rivet-svn] r2339)

[Frank Siegert]

I have a follow-up question to this commit.
When we initialise FastJets projections on given final states, does the 
caching system ensure that these FinalStates are being compared properly?
I am unsure for two reasons:

Within the JetAlg the given FS is wrapped inside a VisibleFinalState, so 
does the comparison work properly recursively? (probably yes)

Looking at the complicated case where I pass a 
ZFinder::remainingFinalState into FastJets, how does FastJets know how 
these remainingFinalStates compare between different analyses? Does all 
the information needed actually get propagated down to the comparison 
within FastJets?

I've so far been relatively ignorant about how the projection caching 
works, so if somebody more familiar with it could put my mind to rest, I'd 
be grateful.

Cheers,
Frank

PS: About my commit r2339... I am currently running validation runs for 
all Z+jets and pure QCD analyses at Tevatron (which are the ones most 
affected I think). I'll let you know in case I notice any significant 
differences, in which case we might want to think about 1.2.1.

blackhole at projects.hepforge.org, Thursday 18 March 2010:
> Author: fsiegert
> Date: Thu Mar 18 11:19:14 2010
> New Revision: 2339
> 
> Log:
> Slightly horrifying bugfix with respect to the pTmin argument of the
> FastJets projection constructor:
> pTmin was only used in the D0ILCone case where it specifies some kind
> of internal(!) parameter of the jet algorithm. It is nothing like a
> pTmin cut on the final jets which is what some analyses assumed
> though. This commit removes the pTmin argument from the FastJets
> constructor and adapts all analyses to properly require
> jetsBy*(pTmin).
> Also I tried to unify jetfinders where allowed such that they can be
> cached.