[Rivet] FastJets caching

[Andy Buckley]

On 18/03/10 12:00, Frank Siegert wrote:
> 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)

This should work, yes (although I've just tidied it a little bit more).
The VisibleFinalState::compare method returns the comparison between its
internal VetoedFinalState (itself built from the JetAlg's FS) and that
of the projection being compared, so provided that those work it should
be ok.

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

Okay, this is a good point. The remaining final state things are built
using the VetoFinalState::addVetoOnThisFinalState method. I have no idea
what goes on inside there, but it seems to me that they can't possibly
know what conditions defined the FS that they are vetoing on... can
they? I could think of a truly hideous way to make this robust, but I
think the safe and simple option might be to add a "includes veto on
another FS" flag to VetoFinalState, which makes the VFS::compare method
always return false. Sound sensible?

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

Hopefully I've done that ;) Incidentally, now that the projections are
now registered in the central ProjectionHandler, I'm quite tempted to
change the way that they are currently "attached" to events to make the
caching work. While that wouldn't change any current behaviour or the
arguments above, it would make the internals a lot more intuitive -- the
current caching design is entirely based on the idea that the project
objects are stored within analysis objects. Doing it the other way
around would allow all of the projection comparisons to take place
during registration, buying us a bit of currently-redundant CPU.

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

Absolutely: thanks for both finding and testing.

Andy

-- 
Dr Andy Buckley
SUPA Advanced Research Fellow
Particle Physics Experiment Group, University of Edinburgh

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.