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

[Lars Sonnenschein]

Hello Andy (et al.)

On Thu, 9 Oct 2008, Andy Buckley wrote:

> 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"? ;)
> 
> ???
The second Rivet should be ROOT.
I have added a plot:
D0_2001_WptZpt_Pythia6413TuneA_datnormed__RivetRatio_partons.eps
which shows the histogram as computed by Rivet.
I think I understand now the difference:
The division in Rivet should be done after the normalisation and not 
before. But If I try to divide the histo's after normalisation I get a 
segmentation violation ...

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

That sounds interesting. I would suspect that some weired inter-bin 
smearing/smoothing effects could slip in.
Could you point me to an analysis note (data or phenomenological) which 
makes use of such a technique and describes it (at least a little bit)?

 
> 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 have also added two more FHerwig plots with more stat:

D0_2001_WptZpt_Herwig6510EmilysWZTune_datnormed_partons.eps      
and
D0_2001_WptZpt_Herwig6510EmilysWZTune_partons.eps    
(of course with ROOT ratio since I need two separated Herwig runs for W 
and Z boson production)
 

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

Thanks again.
I will produce now some HerwigJimmy plots

	  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
________________________________