[Rivet] VetoedFinalState problem

[Emily Nurse]

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