[Rivet] [Rivet-svn] r3383 - in trunk: include/Rivet/Projections src/Analyses src/Projections

Frank Siegert frank.siegert at cern.ch
Fri 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