[Rivet] Phone/Skype meeting

[Andy Buckley]

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

Boo hoo. I'm also getting to like Skype, possibly just because it makes 
our community EVO system look so appalling.

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

;) Yes, I saw that. I think while we still have to support earlier HepMC 
versions (or do we?... discuss), the detection needs to be done in the 
C++ code rather than having to --- somehow --- build slightly different 
Python interfaces for different HepMCs. (Unfortunately the HepMC code is 
such an overcomplicated mess that SWIG can't parse its headers directly 
and needs to be told what to ignore, what to rename, and what to 
enhance.) But it's on my collection of TODO post-it notes!

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

Excellent. I realise that few people get excited about infrastructure 
that doesn't itself produce physics, but this is an important discussion 
which I think is key to us exploiting Rivet results more flexibly. And 
there's a lot of physics in *that*.

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

Great... I know that make-plots starts creaking a bit when you put as 
many range bands etc. into the plots as you've been doing! The art is 
going to be addressing the problems without killing our productivity.

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

It's in semi-good shape. I have had YODA issues sitting untouched on my 
TODO for a long time, because there's little point in working on it 
until there's demand. And there won't be demand until... you get the 
picture ;) What's needed now is a bit of work on the I/O and a lot of 
correctness and usability testing.

We need to think about whether we can release Rivet 1.2.0 before 
committing to a histogramming port: using better histo classes will 
really open up what we can do, but it will be a rather major porting 
exercise, involving changes to scripts which currently expect AIDA as 
well as updating analyses which expect to use AIDA or LWH objects.

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

At least that's one important issue dealt with!

Andy

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.