[Rivet] VetoedFinalState problem

Emily Nurse nurse at fnal.gov
Tue Jan 29 14:24:36 GMT 2008

I'm happy to help with this if James/Piergiulio let me know what the  
status is.


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

More information about the Rivet mailing list