[Rivet] normalisation to cross-sections

[Frank Siegert]

Hendrik Hoeth, Friday 23 October 2009:
> > > 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.

Now I see where the misunderstandings come from. What I meant here is to 
make a distinction between histograms and profile histograms because 
obviously for the latter all of this normalisation stuff doesn't apply.
So if you read this to refer only to histograms where the _data_ is 
proportional to the cross section, how would my proposal make any 
difference to what we have done so far? For them we already do finalize 
with crossSection()/sumOfWeights() and nothing will have to be done a 
posteriori to change that.

> 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: [snip]

I understand that in the ideal world the histogram numbers coming out of 
Rivet would be directly the same as in the experiment. But please also 
consider that we have a desperate need to run higher statistics through 
Rivet by merging runs. That is mainly relevant for validation rather than 
tuning though.
So I thought my suggestion was a fair (and temporary) compromise. Do you 
have any better suggestion?

> But for the typical Rivet user I think this breaks the expected
> functionality.

The next release is not backwards compatible anyway, so I don't see a big 
problem in that. Does Hw++ plot directly from within C++, or do they use 
our plotting tools? In the first case, we might want to provide 
programmatic access to the Norm which is right now only available in the 
*.plot file.

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

As I said, that's nothing that I would mind changing.

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

Which is exactly what I did in my recent commit unless I have missed one, 
in which case I would appreciate if you pointed it out.

Frank