|
[Rivet] [Rivet-svn] r3383 - in trunk: include/Rivet/Projections src/Analyses src/ProjectionsFrank Siegert frank.siegert at cern.chFri Sep 30 10:00:29 BST 2011
On 30/09/11 09:28, Frank Siegert wrote: > > I now realise what the problem is: I was looking at parton shower level > and NLO ME runs, and gluons are rejected by the modified VisibleFS > filter. Since we do want to support parton/shower level analyses, they > should definitely be treated as visible. > On that finding, I'm not sure that such a white-list filter is really > better than a blacklist... could there be any similar cases which we > forget to think about right now? Actually, this is one problem, but not the most severe one. The real problem was that the compare method for the VisibleFinalState projection was broken. The fix is basically reverting it to what it looked like before: int VisibleFinalState::compare(const Projection& p) const { - return FinalState::compare(p); + return mkNamedPCmp(p, "FS"); } (We do not want to compare VisibleFinalState::_ptmin etc., since they aren't used anyway. Only the "FS" is important) This together with the gluon issue fixes my plots for good now. But the question whether to prefer a black or a white list is still open. Cheers, Frank > > On 29/09/11 20:34, David Grellscheid wrote: >> Hi Frank, >> >> Sorry! I tested with Herwig's LEP tune plots, and they looked OK. >> Strange. I'll take another look tomorrow. But revert it if it's urgent. >> >> The logic seems OK to me. I'll have to test the filter branches >> individually, I guess. >> >> David >> _______________________________________________ >> Rivet mailing list >> Rivet at projects.hepforge.org >> http://www.hepforge.org/lists/listinfo/rivet
More information about the Rivet mailing list |