[Rivet] Rivet bug in LEP Jet Resolutions Y12 ?

Frank Siegert frank.siegert at cern.ch
Fri Feb 4 14:22:05 GMT 2011


Hi Peter,

Well spotted!

I have always been wondering why this distribution looks roughly correct 
at the shower level, but not after hadronisation!

So this will be easy to fix for the jet resolutions, since we have

     void useInvisibles(bool useinvis=true) {
       _useInvisibles = useinvis;
     }

which we can call for the FastJets projection. What about the other 
observables in that analysis, are they also affected by the same issue?

Cheers,
Frank


On 04/02/11 15:15, Peter Skands wrote:
> Hi all,
>
> I believe there is a bug in the code that generates the following
> analysis in Rivet, ALEPH_2004_S5765862, see the plot here
> http://mcplots.cern.ch/?query=plots,ee,zhad,Y2-ch,Main
>
> As you can see, all the generators seem to have a very wide tail whereas
> the data hits a shoulder and falls off more steeply. There is a residual
> effect of opposite sign also in Y23.
>
> This has nothing to do with ISR on/off or anything like that. It's
> worse. There is one particular thing which causes exactly this effect:
> whether neutrinos are, or are not, included in the final state. I
> believe Rivet is trying to do the "right" thing by throwing away the
> neutrinos. However, one obtains precisely that shoulder which the data
> exhibits if one *does not* throw away the neutrinos.
>
> In the paper, they state (p.461 of the EPJC journal article):
> "The data are corrected for acceptance, detector resolution, undetected
> particles such as neutrinos, particle masses, final state photon
> radiation and the residual effects of ISR by means of multiplicative
> factors."
>
> This would seem consistent with the supposition that they are actually
> putting the neutrinos *back*. Otherwise there would be no need to
> "correct" for them - they would simply not be there, neither in the
> numerator nor in the denominator of y_ij. I think, therefore, this
> analysis has to include the neutrinos in the jet clustering, although I
> completely agree that this is a horrid idea and the responsibles ought
> to be publicly flogged. One should certainly add a remark about it to
> the manual entry, to ensure that people don't start flogging *us* for it.
>
> Peter
> _______________________________________________
> Rivet mailing list
> Rivet at projects.hepforge.org
> http://www.hepforge.org/lists/listinfo/rivet


More information about the Rivet mailing list