[Rivet] Phone/Skype meeting

[Frank Siegert]

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

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 ;)

>   * Getting some manpower on the histogramming upgrade for the
> next-to-next release. I think we need to have a good think about how
> much of the histogramming normalisation, chopping, scaling, etc. should
> be inside Rivet and how much should be in (Python) post-processing
> scripts.

I would definitely be willing to contribute to that and would be very 
happy if we discussed especially the question of how much of the 
normalisation should be done a posteriori. This is in particular relevant 
for me because I want to merge (equivalent!) generator runs to increase 
statistics.
I have also worked on and used the plotting tools quite a bit recently in 
different use cases, so I have a fairly clear perception of what I would 
want it to work like (much of which is already possible, but a little bit 
cumbersome).
What about the actual histogramming package (independent of Rivet), is it 
already in good shape? What is still needed and how efficient/useful would 
you expect it to be if somebody else helped working on it?

> PS. One *very* important issue: I'd like to make our next release
> "1.2.0" rather than "1.1.4". Two reasons: first, there is a major and
> incompatible change to the plugin system; second, our current use of
> the release numbering is so conservative that I fear it makes us look
> like a bunch of lazy "slow patchers", while other HEP tools rocket
> through the version numbers like there's no tomorrow. Just psychology,
> but I think no less important for that ;) Any opposition/comments? (I
> would expect the SHERPAs on the list to have some comments about
> conservative version incrementing!)

Very much in favour of 1.2.0. :)

Frank