[Rivet] Validation & tuning phone meeting, Monday 29th Sept, 4pm (UK)

[Andy Buckley]

Lars Sonnenschein wrote:
> On Thu, 9 Oct 2008, Andy Buckley wrote:
>> Lars Sonnenschein wrote:
>>
>>> I checked with the very first bin value in the histo's to be divided that 
>>> ROOT is doing the right thing. The ratio histo from Rivet is about a 
>>> factor of two lower than the Rivet answer.
>>
>> What do you mean here: which of these "Rivet"s should have been "ROOT"? ;)

???

>> We need to be really careful with these divisions: by default ROOT's
>> histograms don't take any account of bin width, i.e. the BinContent(i)
>> function returns the sum of weights in bin i, rather than
>> sumW(i)/binWidth(i), which is the proper bin-measure invariant shape of
>> the histogram. This should drop out in taking the ratio, but don't the
>> bins end up not have matching edges in the W and scaled-Z histos
>> [because of the mW/mZ factor in d(sigma)/d(pT(Z)*mW/mZ)]? If this is the
>> case, then I have no idea how ROOT's division function attempts to match
>> up the bins and handle the width-factors. Yuck.
> 
> I don't understand how I can in general divide histograms with different 
> binnings. Wouldn't you divide apples by oranges?
> The bin edge of one histogram could fall into the middle of the
> other histogram. Which bin would I then be divided by which bin?

That's exactly the point: you can do it, but it requires some
interpolation scheme to infer the binning that "should have been". I
don't advise it!

The conversion d(sigma)/d(pT(Z)) -> d(sigma)/d(pT(Z)*mW/mZ) is changing
the binning by a factor of mW/mZ (i.e. compressing it) with the
corresponding Jacobian factor mZ/mW applying to the y-axis, such that
the normalisation remains unchanged (this is automatically handled by
Rivet'sretation of the AIDA definition of bin height, but not ROOT's).
This is the distinction between d(sigma)/d(pT(Z)*mW/mZ) and
d(sigma)/d(pT(Z))*mW/mZ.

For the ratio binnings to work in this scheme, they would need to be
different in d(sigma)/d(pT(W)) and d(sigma)/d(pT(Z)) by a factor mZ/mW.
I can't tell from the plots of this is the case.

> What I do (as you can see in the head version) is to fill into the scaled 
> ZpT histogram the variable: pmom.pT()*_mwmz instead of simply the pT.
> The binning is identical to the other histograms.

Right, so the effect is to compress the Z pT fall-off into a smaller
x-range, so the effect should be to flatten off that ratio plot.

> The difference between dividing by the scaled or unscaled ZpT 
> histogram does only make a small difference and seems not to alter the 
> shape.

Well yes, the shape is only changed in the sense that there's a
horizontal compression factor of 91.2/80.4 = 1.13 (or the inverse as you
prefer). So it wouldn't be easy to see by eye, but the ratio plot should
definitely change. To be honest, from your current ratio plot I just
can't tell what's going on because the errors are so huge --- looks like
you need to put *lots* more stats into your generator runs. How many
events are in these plots?

>> I just tried running the AGILe HEAD with HerwigJimmy and LHC mode MPI
>> and found the same problem. I tracked it to the checking of the Herwig
>> error flag at the end of the event loop, which meant that the event was
>> never accepted. It's fixed in the AGILe head now. This might mandate an
>> AGILe patch release soon; silly error :(
> 
> OK, thanks.
> I just try to re-compile and get (after autoreconf and configure):
> Making all in pyext
[...]
> AGILe_wrap.cc AGILe.i
> AGILe.i:11: Unable to find 'std_set.i'
> 
> Do I need to configure differently or does something else need to be 
> checked in or is it again a cern installation problem?

Take a look at the error message... it's in the Python interface (which
isn't important yet, but will be), so you can disable the Python build
with --disable--pyext for now.

Actually, mapping support for std::set wasn't needed anyway by the
interface so I've removed it in the head. I'm not particularly worried
about the SLC4 SWIG compatibility for the moment, since that interface
to AGILe/Rivet will never be relevant for experiment interfaces to
Rivet, and by the time that users want to use it, I hope that SL5 will
be more widespread. Or alternatively everyone will have spontaneously
come to their senses and ditched the whole SL line as a bad joke... hmm,
in my dreams!

Andy

-- 
Dr Andy Buckley
Institute for Particle Physics Phenomenology
Durham University
0191 3343798 | 0191 3732613 | www.insectnation.org