|
[Rivet] Phone/Skype meetingJonathan Butterworth jmb at hep.ucl.ac.ukFri Oct 2 09:17:02 BST 2009
Hi all, I can't make 12th. 13th would ok and I would like to join if possible. Any chance? 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". > > 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. >> * 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. :) me 2 > > Frank > > _______________________________________________ > Rivet mailing list > Rivet at projects.hepforge.org > http://www.hepforge.org/lists/listinfo/rivet -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Prof. Jonathan Butterworth, http://www.hep.ucl.ac.uk/~jmb/ Physics and Astronomy Department Tel: +44 20 7679 3444 ATLAS, CERN Tel: +41 22 76 72340 University College London Gower St, London WC1E 6BT, UK ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
More information about the Rivet mailing list |