[Rivet] normalisation to cross-sections

[Andy Buckley]

Frank Siegert wrote:
> I've just discussed this with Hendrik over lunch, and I think that cleared 
> all misunderstandings. So here a short summary in case anybody else is 
> still following this thread.
> 
> There are two separate points of criticism.
> 
> 1. Analyses should not unnecessarily require the generator cross section 
> if all of their distributions are normalised.
> I agree and will change the scale(crossSection()/sumOfWeights()) to 
> scale(1.0/sumOfWeights()).
> 
> 
> 2. Rivet's AIDA output should be the same as the data without needing 
> extra information from the *.plot files.
> Here it seems like my motivation wasn't really clear, so let me try to 
> state it again:
> 
> If I run 10 x 1 million events to get high statistics in short time, then 
> I want to be able to combine the resulting 10 histograms into one. The 
> perfect solution to this is going to come with YODA where we store the raw 
> weights. Until then, I still want to be able to average the 10 values in 
> each bin to get a correct combined value. If I normalise histograms to 1 
> and I have filled _weighted_ events into these histograms, this doesn't 
> work, because there might be runaway bins which create a bias towards low 
> values for all other bins. On the other hand, if I scale the histograms by 
> whatever/sumOfWeights() this is not a problem.
> 
> Hendrik agreed on the second issue and said he could live with that.

So if I understand correctly, when coded this way these analyses will 
not be directly comparable with the reference data on coming out of 
Rivet (and being averaged), but will require the scaling information 
from the .plot files to be applied first?

I can't say I'm a fan of this approach: it still seems (to me) to break 
Rivet's expected behaviour (including how Professor uses the output) and 
it requires first pushing information into the .plot files and then 
hauling it back into the C++ again "once YODA arrives". I don't want to 
get in the way of Rivet being useful for studies requiring high stats 
(and this can be used to speed up detector-smeared MC samples, so I 
definitely want to see it happen), but I would much rather that we keep 
Rivet's behaviour such that what comes out of the C++ is directly 
comparable to the reference data with the discrepancy factor purely 
being of the K-factor type. I don't want to have to hack some temporary 
reading of .plot files into Professor for this version of Rivet only.

The time spent on writing custom scripts to average data grabbed from 
AIDA XML, attempt to approximately reverse-engineer the merged errors, 
etc. can instead be devoted directly into getting YODA ready for use. I 
don't think very much work is needed here, but it needs to happen in 
YODA rather than in stopgap solutions... otherwise YODA never will 
"arrive". And I think with a concerted effort this can happen very fast 
after the 1.2.0 release... so let's get 1.2.0 out asap, with the same 
histo behaviour as we intend all versions to have, and get working on 
this histo upgrade immediately after. Checking out YODA and testing the 
statistics of the histo combination, getting the I/O to work, etc. would 
be a BIG step in the right direction.

Andy

-- 
Dr Andy Buckley
Particle Physics Experiment Group, University of Edinburgh