[Rivet] Rivet analysis OPAL_2004_S613224, and some further questions

[Christoph Pahl]

Hello Andy, Peter and all rivet developpers,

I'm happy to see that the problems in the rivet implementation of our OPAL 
analysis are resolved and it can be used now.

I struggled quite a bit with some technical rivet problems and would need 
some help please: I'd like to write some OPAL jet analysis similar to 
JADE_OPAL_2000_S4300807, for:


A) ee-SISCone, in my data analysis program:

   fastjet::SISConeSphericalPlugin * plugin =new fastjet::SISConeSphericalPlugin(Rparam, f, npass, Emin);
   fastjet::JetDefinition jet_def(plugin);

Contrary to SISCone, SISConeSpherical isn't included in the "Wrapper enum 
for selected Fastjet jet algorithms", therefore I tried in my rivet 
analysis

   fastjet::SISConeSphericalPlugin * plugin = new fastjet::SISConeSphericalPlugin(R, f, npass, Emin);
   addProjection(fs, plugin);

which gives a compile error

   error: no matching function for call to ‘Rivet::MyAnalysis::addProjection(const Rivet::FinalState&, fastjet::SISConeSphericalPlugin*&)’

I do not understand these plugin-types well, what do I have to change?


B) ee-antikt, in the data analysis:

   fastjet::JetDefinition ee_antikt(fastjet::ee_genkt_algorithm, R, -1, fastjet::E_scheme);

Again this isn't included in the enum, and rivet doesn't provide a

   FastJets(const FinalState& fsp, fastjet::JetAlgorithm type, fastjet::RecombinationScheme recom, double rparameter, int exponent);

with suitable parameters.

How can I proceed? Write a plugin as in B) ?


Thanks a lot for any hint,
Christoph Pahl



On Sat, 1 Feb 2014, Peter Skands wrote:

> 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
>