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

[Lars Sonnenschein]

On Fri, 10 Oct 2008, Andy Buckley wrote:

> Lars Sonnenschein wrote:
> > On Thu, 9 Oct 2008, Andy Buckley wrote:
> >> Lars Sonnenschein wrote:
> 
> [ROOT/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 ...
> 
> Well yes --- after the normalisation the histo pointer is null! This is a
> design feature in Rivet, because AIDA (correctly) uses distinct types for raw &
> normalised histos.
> 
> I don't understand why the order makes a difference... if you've made /d(pT(W))
> and d(pT(Z)*mW/mZ) histos with compatible binnings, then you can extract their
> normalisations and use those to rescale the DPS that comes from the division,
> right?

If you mean that I have to implement into RivetAIDA.hh a function 
integral(), where also the normalization() function has been implemented
then yes I can extract it.
But scaling by an overal factor will not make the distribution flatter.
I produced the ratio plot with Pythia6 by doing the division in my ROOT 
script (as for FHerwig), then I get also a flat distribution.
Unfortunately I cannot connect to Fermilab right now to upload the plot, 
but it looks very similar to the FHerwig flat ratio plot.

Somehow the bins of the Rivet divided histo have to be 
multiplied by the bin widths (x2GeV for the first bins and larger values 
for the later bins.) to get it close to flat, but I'm just guessing.


 
> >> 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.
> 
> Only if the bins actually mismatch after the x-transformation; this analysis is
> okay as far as I can tell.
> 
> > 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)?
> 
> Fortunately I know of no cases where anyone has been foolish enough to bring
> this upon themselves!
> 
> You can probably work out the sort of procedure yourself --- some interpolation
> of the true shape from the bins, then divide the contents of each bin along its
> length using the guessed true slope, then divide where allowed. It's only a way
> to deal with a bad situation, though: much better never to get there!
> 
> >>> 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)
> 
> This looks fine to me: the ratio plots look fairly flat in both cases. Can you
> do Pythia runs with the same stats so we can see what the ratio plot looks like
> there? If it's different from Herwig then there may be a genuine Pythia problem.

I can run 150k events interactively. Beyond a deamon kills my interactive 
jobs. I can prepare jobs for the 1day queue to get better stat.

	Lars