[Rivet] VetoedFinalState problem

[Andy Buckley]

Emily Nurse wrote:
> Dear rivet-ers,
> 
> I would make a new rivet ticket but I don't think I can (perhaps  
> connected to the fact that I don't have wiki write access?)

Hopefully this is sorted now: you weren't in Trac's list of Rivet
developers. I've changed the system now so that any authenticated user
is treated as a developer.

> There seems to be a problem in TotalVisibleMomentum and other  
> Projections when used with a VetoedFinalState (ie/ as in  
> CDF_2006_S6653332).
> TotalVisibleMomentum is created in the analysis constructor with a  
> VetoedFinalState as input, but the VetoedFinalState::addVetoPairId()  
> methods are not called until later in the analysis constructor so the  
> vetoed particles are not actually vetoed in the TotalVisibleMomentum  
> calculation.

Yes, that's a bug - I want to make the infrastructure safer against this
sort of problem in the version 2 release.

> In addition, since VetoedFinalState is copied as a  
> FinalState to TotalVisibleMomentum it loses the additional "veto"  
> information anyway.

Yes, this is already known and ticketed:
http://projects.hepforge.org/rivet/trac/ticket/148

James and Piergiulio are looking at this at the moment, I think.

> This can be fixed by keeping a VetoedFinalState (instead of  
> FinalState) as the private data member, _fsproj, in   
> TotalVisibleMomentum and by adding an upDate() function to  
> TotalVisibleMomentum that can update this data member if any  
> particles are vetoed. Alternatively there could be no FinalState& fsp  
> passed into the TotalVisibleMomentum constructor and an init 
> (FinalState& fsp) method could be written that HAS to be called in  
> the analysis constructor (this stops you doing something wrong by  
> accident so may be preferable).
> 
> I can put such a fix in to all the Projections where this is a  
> potential problem unless people would rather a different solution?

I think our preferred solution is to use pointers where these slicing
and initialisation order problems appear. I'm not keen on the update()
method, and the problem with changing the embedded FinalState to a
derived class is that we lose flexibility. It would be great if you
could help to get this fixed via the pointers method: we then have to be
careful to make sure that the referenced objects live at least as long
as their containers.

In the long term, we need to think about how this can be solved more
elegantly, perhaps by centrally storing all projections centrally and
accessing them via a reference mechanism. That sort of re-engineering is
definitely a version 2 issue.

Andy