[Rivet] VetoedFinalState problem

[James Monk]

We have the same problem with wanting to exclude some leptons from the  
FastJets projection, which also holds a FinalState and not a  
VetoedFinalState.  I got caught up in HepMC issues with adding the  
functionality to VetoedFinalState to remove the Z decay products, so  
haven't yet got around to sorting out the FinalState Vs.  
VetoedFinalState member.

I wonder if we actually need a distinction between a FinalState and a  
VetoedFinalState?  A VetoedFinalState without any vetoes applied is  
the same as a FinalState, so could we not just ditch FinalState and  
use VetoedFinalState everywhere (with an appropriate compare method so  
it gets cached when there are no vetoes applied).

James

On 29 Jan 2008, at 14:24, Emily Nurse wrote:

> I'm happy to help with this if James/Piergiulio let me know what the
> status is.
>
> Cheers,
> Emily.
>
> On 29 Jan 2008, at 05:07, Andy Buckley wrote:
>
>> 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
>> _______________________________________________
>> Rivet mailing list
>> Rivet at projects.hepforge.org
>> http://www.hepforge.org/lists/listinfo/rivet
>
> _______________________________________________
> Rivet mailing list
> Rivet at projects.hepforge.org
> http://www.hepforge.org/lists/listinfo/rivet