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

[Lars Sonnenschein]

Hello Andy


On Thu, 9 Oct 2008, Andy Buckley wrote:

> Lars Sonnenschein wrote:
> > Just a short heads up:
> > 
> > I have put two new plots at:
> > 
> > http://www-d0.fnal.gov/~sonne/D0_2001_S4674421/
> 
> > Concerning the plots: The Pythia simulation is scaled to the data.
> > The ratio is obtained by the scaled histo's, using ROOT's 
> > histogram division function. Without scaling to data the ratio
> > is by about 20% lower.
> 
> > 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.
> 
> Hi Lars,
> 
> 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?

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.

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




> > The other thing is that when I run HerwigJimmy from the cern afs 
> > cluster it's trying events but I never see the Rivet 100 events control 
> > message, then after about 20 minutes my interactive job gets killed from 
> > a daemon. So there are no accepted events.
> 
> 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
make[1]: Entering directory 
`/afs/cern.ch/user/l/lsonnens/scratch0/cedar/AGILeCommit/pyext'
/usr/bin/swig -c++ -python -I../include -I../include  
-I/afs/cern.ch/sw/lcg/external/Boost/1.34.1/slc4_ia32_gcc34/include/boost-1_34_1  
-I/afs/cern.ch/sw/lcg/external/HepMC/2.04.00/slc4_ia32_gcc34/include  -o 
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?

	Lars

 
________________________________
Lars Sonnenschein    
________________________________
Home Institution:
PH/TH 53/1-052 
CERN
CH-1211 Geneve 23
Switzerland
Tel.:+41(22)767-2801
--------------------------------
________________________________
FNAL:
D0, PK151
Mailstop #352
Fermilab, P.O.Box 500
Batavia, IL 60510-500
USA
Tel.: +1(630)840-8740
________________________________