|
[Rivet] VetoedFinalState problemEmily Nurse nurse at fnal.govMon Jan 28 22:56:23 GMT 2008
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?) 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. In addition, since VetoedFinalState is copied as a FinalState to TotalVisibleMomentum it loses the additional "veto" information anyway. 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? Emily.
More information about the Rivet mailing list |