[Rivet] YODA development

[Andy Buckley]

Hi guys,

Sorry about the slowness in responding to YODA guidance... it's been 
another busy week! I've asked the IPPP admins to add James, Frank, Eike 
and Holger to the YODA project so you can commit code: hopefully that 
will be done today. Eike, I think you already have some changes, e.g. 
moving test scripts out of pyext, right? Please commit those when you 
get access.

Roughly, the things to try immediately are:

  * Check out the code and see if you can build and install it. There 
are no dependencies. It worked for Eike, but you never know!

  * Try running some of the test scripts and programs in the tests 
directory. Have a look at the code and comment on whether you think the 
API sucks or can be improved in small ways.

  * Add some test scripts for the weighted run combination correctness: 
this should already be done for both positive and negative weights on 
standard histograms, but I don't think there are yet unit tests for the 
Profile1D.

  * If you're feeling adventurous, try to fill in some of the missing 
bits of code and functionality. Here are my top few tasks:

   - Get I/O working: this means a functional implementation of 
http://projects.hepforge.org/yoda/trac/ticket/7 (register and discuss 
the implementation on the tracker please... I never got any feedback, 
but David and I decided after some playing with flex/yacc that it was 
better to use a clean base like YAML than to try to crowbar a general 
parser around the make-plots format. libyaml-cpp is included in YODA, as 
for Rivet.

   - Also on the I/O, I'm not happy about the current design for the I/O 
type detection: the current design handles the passing of a base 
AnalysisObject into the Writer, which then produces an output stream, 
but how can we safely work out the type of object which is being read 
in, if all that's returned is a base reference? The basic C++ way is a 
dynamic_cast: can that be made neater?

   - The Scatter<N> class, and especially the very complicated errors 
associated with it, is a horrible abomination of a design, and getting 
the templation to work ate more of my time than I want to think about. 
It should probably be thrown away and replaced with simpler Scatter1D 
and Scatter2D classes with usable errors. It's worth

   - Conversion of Histo1D and Profile1D to Scatter2D. Obvious 
requirement, needs Scatter2D to exist first. Arguably more important for 
Rivet usability is the ~opposite: booking the bins of Histo1D and 
Profile1D from a Scatter (remember, in YODA bin edges don't have to be 
contiguous, i.e. gaps are allowed)

   - Annotations: how we're going to specify target norms, scale factors 
etc. in the persistent format. These particular annotations should be 
treated specially by e.g. merging code, but arbitrary annotations such 
as "KFactor" should also be possible.

Please ask if there are any questions, and use the tracker and the YODA 
mailing list (join it!) to coordinate who's doing what. Hopefully I can 
answer any questions about the existing code...

Thanks,
Andy

-- 
Dr Andy Buckley
SUPA Advanced Research Fellow
Particle Physics Experiment Group, University of Edinburgh