[Rivet] normalisation to cross-sections

[Hendrik Hoeth]

Hi Frank,

Thus spake Frank Siegert (frank.siegert at durham.ac.uk):

> Thanks for the implicit compliment :-P

You're welcome.  :-P

> > But let's do it for a moment. Things like a 1-Thrust certainly don't
> > need to be normalised to anything other than 1. [...]
> 
> I agree, and that's why they are being normalised to 1 in the *.plot file. 
> I thought the reasoning behind this was laid out in the other long thread 
> that you didn't bother to read ;-)

Uhm, I disagree here. In the very first mail of that thread you start
with saying

>>> (Note that all of the following only refers to distributions which are
>>> proportional to the cross section, i.e. not profile histograms like
>>> N_charged vs. pT(leading jet), where normalisation is not an issue.)

and by definition an event shape is not proportional to the
cross-section. So while I agree with most of what's being said in the
long thread, that thread doesn't touch the issue I mentioned yesterday
evening.

Normalising the histograms to 1 in the plot file is not a viable
solution here. From a users' point of view _I_ would expect that I can
compare whatever histograms come out of Rivet directly to the reference
data, without any post-processing. That goes in a similar direction as
Andy's comment in the long thread in the context of K-factors:

>>> This also makes sense for users like Herwig++, who are accessing
>>> Rivet as a library and presumably want whatever histograms are
>>> written out to be meaningful *before* post-processing scripts are
>>> applied (with any post-processing of their own presumably done via
>>> YODA's C++ interface.) 

The one and only case where I could imagine something like normalising
an event shape to cross-section would be for generator studies like
"what's the contribution of 1-jet, 2-jets, 3-jets, 4+-jets to this
plot", and there you'd have to manually mess with the plots anyhow, e.g.
to include "Stack=<list>" in the PLOT section of the .dat file, etc.
But for the typical Rivet user I think this breaks the expected
functionality.

> > Again, I don't know the other analyses in that list, and I didn't look
> > them up, but please let us go through whatever analyses we want to
> > change _thoughtfully_. And add the "setNeedsCrossSection(True)" only if
> > needed.
> 
> My understanding of (and I think Andy's comment in?) the discussion was 
> that we assume every generator to be able to provide cross section 
> information.

Our last week's patch for Pythia 8 for instance will only be included
from the next release onwards. Anybody using an older version doesn't
get the cross-section.

> So the setNeedsCrossSection() is going to go away and be 
> assumed true anyway.

And until then we should put it explicitly in all analyses where we use
crosssection(), so that Rivet stops before running those 5 million
events and doesn't crash in finalize() only after burning hours of CPU
time.

Cheers,

   Hendrik

-- 
"You have to take the most direct road to go instead of your
 meeting, you have to, this one ended, leave at once the CERN
 domain."         (imprint on the CERN visitor ID cards)