[Rivet] Rivet analysis OPAL_2004_S613224

[Peter Skands]

Hi

I just re-checked mcplots for the opal analysis and am happy to report that I no longer see any discrepancies for the OPAL thrust analysis there. In fact the OPAL energy scaling analysis *is* now included a among the publicly available results on the site. I don't recall exactly when the bug was fixed but at least it appears to be ok in the version of rivet we currently use: 1.8.3.

Note that it was not an issue between the ALEPH and OPAL *measurements*, which were consistent, but with the rivet analyses giving factor 3 different MC results between the two. That seems to have been fixed now however. 

All the best, 
Peter

Sent from my iPhone - please excuse my brevity

> On 31/01/2014, at 18.29, "Andy Buckley" <a.g.buckley at gmail.com> wrote:
> 
>> On 15/11/13 15:11, Christoph Pahl wrote:
>> Hello Andy, Peter and all rivet developpers,
>> 
>> we would be happy if the OPAL 2004 Rivet analysis could in fact be used.
>> We are still using the analysis code (working with Nadine Fischer led me
>> back to this problem) and we have all data and MC samples.
>> 
>> The exclusion resulted from Peter Skands stating
>> http://www.hepforge.org/lists-archive/rivet/2011-May/002220.html
>> large deviations ~ factor 3 between data and rivet PYTHIA results in
>> (for example) the lowest 1-thrust bin for OPAL at 91 GeV, but not for
>> ALEPH.
>> 
>> The linked plots are hard to read as they are very dense, and the ratios
>> go only up to 1.5 . From the numbers on the cited web page I calculate
>> the deviation more precisely as 2.5; and from the ALEPH plot I see a
>> HERWIG deviation in this bin of ~ 2, shouldn't you then exclude
>> ALEPH as well?
>> The lowest bin has experimental and theoretical difficulties and we
>> never include it in any fitrange. So excluding an analysis because of a
>> problem
>> there is pretty sad. But as soon as I understand the problem better I
>> can of course compare our code with the rivet analysis.
> 
> Hi again Christoph,
> 
> Apologies for the long delay -- we've again been working on Rivet 2
> developments whenever there has been free time, but with the Rivet 2.1.0
> release approaching I wanted to return to this issue.
> 
> I don't think we declare any particular analysis validity strictly based
> on problems with MC. In these specific cases any information that you
> have which could help us make the implementation better would be
> *really* valued (and credited, of course).
> 
> Going back to your original email, I'm usually in the 3-D corridor
> section of B40 at CERN if you want to talk in person about this and any
> improvements that we could put into Rivet's implementations to help you
> (and others).
> 
>> On Mon, 21 Oct 2013, Andy Buckley wrote
>>> In particular, as part of the histogramming migration to Rivet 2.0, we
>>> did discover some issues with the definition of _integrated_ jet rates
>>> in the JADE_OPAL analysis. Depending on whether the integral is taken up
>>> to the midpoint of the bin, the low edge, or the upper edge you can get
>>> quite different answers. I am not sure which is correct for that
>>> analysis -- are you? -- but the differential rates should be correct.
>>> Please let us know if you've got any ideas or questions about this.
>> 
>> Stefan Kluth told me that OPAL always employed the bin midpoint to
>> represent the point where the jet rate had been evaluated.
> 
> That's great to know: I have updated the analysis for version 2.1.0 and
> credited you and Stefan for that information in the .info file and
> ChangeLog. Thanks!
> 
> Best wishes,
> Andy
> 
> -- 
> Dr Andy Buckley, Royal Society University Research Fellow
> Particle Physics Expt Group, University of Glasgow / PH Dept, CERN