[Rivet] Rivet bug in LEP Jet Resolutions Y12 ?

[Peter Skands]

Hi Frank,

Thanks for the quick reply. The quote from the paper is from section 2, on their 
experimental procedure, so I'm afraid everything in that analysis may be 
affected here.

An exception may be the charged-particle measurements. Of course, anything 
involving *only* charged particles should be ok, but for some of the 
charged-particle distributions, they need to define a thrust or sphericity 
direction, for instance for pTin and pTout. There they say that "The thrust and 
sphericity axes used for the rapidities and the event plane used for pTin and 
pTout are determined using both charged and neutral particles". Now, do 
"neutral" include neutrinos there too? Maybe not. The section 3 which deals with 
the charged particles has its own little paragraph on corrections, which says: 
"The data are corrected for initial and final state photon radiation, detector 
effects and background." Which appears to contradict the earlier statement that 
it was corrected for neutrinos too. On the other hand, it would be pretty weird 
to define a sphericity measurement that includes neutrinos, and then use a 
sphericity axis that doesn't to define pTout and pTin. It really depends on how 
separately these analyses were performed I guess. OK, so I guess we just don't 
know. The only recourse may be to inflate the errors. Does this have an impact 
on the pTin and pTout distributions themselves, which have always appeared 
problematic?

So I guess for certain, the
  - Jet Resolutions
  - Jet Rates
  - Event shapes
are affected, and the
  - Charged Particles with a charged+neutral reference direction
may be affected, and the
  - Charged-particle-only distributions
are not affected

They show some plots of pTin and pTout, etc, so if there is a visible 
difference, maybe from those plots together with the generator versions they say 
they used, one could still deduce what their definition was.

Peter


On 2/4/11 3:22 PM, Frank Siegert wrote:
> 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