[Rivet] Phone/Skype meeting

[Andy Buckley]

Jonathan Butterworth wrote:
> Hi all,
> 
> I can't make 12th. 13th would ok and I would like to join if possible. 
> Any chance?

Fine by me (and I guess for the rest of the Prof guys held captive in 
Edinburgh!), but it would have to be early afternoon or morning, since 
Holger is giving a seminar at 4pm.

> Frank Siegert wrote:
>> Andy Buckley, Thursday 01 October 2009:
>>> Since Hendrik is moving to Durham at the moment, and some of us
>>> including me will be at an Atlas week next week, I suggest that we have
>>> a DESY phone conf. or Skype (preferences?) meeting on the afternoon of
>>> Monday 12 October.
>> 12 October is fine with me. I'd prefer Skype (poor Durham Uni doesn't have 
>> outgoing phone lines in PhD offices).
>>
>>>   * Properly addressing the cross-section/normalisation issue
>>> (hopefully I'll have fixed the bug in extracting the x-sec from HepMC
>>> by then!). I would really like to remove all the hard-coded cross-secs
>>> from Rivet before we next use it "seriously".

Related feedback: the Atlas report of sudden migration to HepMC 2.05 
which James and I noticed, was a bit misleading: Atlas is *testing* 
HepMC 2.05 but the sudden upgrade was to 2.03.11. So we need to think 
about how we can improve our normalisation model without actually being 
able to guarantee the presence of cross-section info: some sort of 
graceful fallback + post-processing scripts? (see below)

>> I don't know if you saw my comment to #323: This isn't actually a bug, but 
>> simply a missing feature in the HepMC python interface, namely the 
>> inability to access the new (2.05) cross section object. I guess it's 
>> quite trivial to fix for somebody who knows the python interface stuff, so 
>> ... unfortunately (for you) I'm not going^w^w^w you'll have to be 
>> supplying all of it ;)
> 
> On what we are trying to achieve here - what JetWeb used to do was treat 
> normalisation as a free parameter for a given process, but have a single 
> normalisation per process rather than per plot. This makes sense for LO 
> generators where the normalisation is not really reliable anyway.
> 
> I don't think we want to start doing any fitting in rivet, but I do 
> think having the facility to provide a single normalisaton per sample 
> rather than per plot is the first place to start, and then to make this 
> available to professor etc for tuning.

Having thought about a lot (as a background process), I think the best 
route to take is to handle the normalisations as a post-processing step 
in Python, making use of the reference histos and the (possibly merged 
from many runs) MC histos. There is physics encoded in the choice of 
norm strategy, which is generator/user specific, and which we can't 
predict in advance, e.g.

  * each histo normed to data
  * each histo normed to generator cross-sec
  * one {histo, process} normed to data with same scale factor applied 
to others
  * use of only part of a histo e.g. to cut out diffractive parts of 
plots which the generator can't describe
  * etc. ...

I can't imagine trying to build that sort of flexibility into Rivet 
itself --- this is a job for scripts that can if necessary be customised 
by users --- but we can work towards making it as flexible and powerful 
as possible as a post-processing stage. The details of how this 
interacts with and complements the in-analysis finalize step are, I 
think, the main point for discussion.

The main prerequisite for this model is to have a powerful and 
user-friendly histogramming interface that we can use in the 
post-processing scripts for statistical merging, bin/histo 
cut'n'pasting, and variously rescaling the histo collections. I think 
this is important enough that it makes sense for us to dedicate some 
parallel effort to making YODA complete and sufficient for these 
requirements *before* we start in earnest on migrating Rivet to use it.

Andy