[Rivet] Plans for Rivet 1.8.0 release

[Frank Siegert]

Hi Andy,

On 17/01/12 12:15, Andy Buckley wrote:
> and Frank S wanted to
> improve the W/ZFinder interfaces a bit more (what's the status of that,
> Frank?)

That was about the ability to specify an input final state for them, and 
has been implemented on trunk for a bit now. So no (known) blocker from 
that side.

> * I would like to split the MC_GENERIC analysis into several distinct
> analyses, since the current collection is rather a mish-mash, grown
> according to validation/sanity checking needs. In particular I'd like to
> separate the identified hadron rates into a separate MC_HADRONS, since
> it takes make-plots a *very* long time to plot the ~3000 bins of the PID
> histograms (it's not clever enough to merge all the consecutive empty
> bins into a single Postscript line). I might also add a specific
> charged+neutral min bias MC analysis that I wrote for ATLAS pile-up
> studies.

* I would like to do something similar in MC_{W,Z,H,WW,ZZ,PHOTON,}JETS, 
namely split each into at least three different parts:
  - Properties of the hard object (let's call it e.g. MC_W)
  - Properties of anti-kt (0.4?) jets to have a more reasonable 
validation analysis for LHC purposes (e.g. MC_W_JETS)
  - Differential kt jet resolutions since they are so useful for MC 
development (e.g. MC_W_JETRESOLUTIONS)

> After this release, we really do need to merge the YODA branch into the
> trunk, and make new 1.8.x releases (and 1.9.x if _forced_) from a
> maintenance branch. The YODA merge will break things, but I think we're
> nearly at the point where that will be tolerable, and will certainly be
> fixed much faster by having several people working on it than just
> Hendrik, David, and myself once every other month! Histogram
> inflexibility has got to be the #1 Rivet FAQ at the moment, so making
> this upgrade is long overdue.
>
> Any comments, objections, etc.?

One comment: I'd very much like to get our manual (arXiv:1003.0694) 
published in e.g. CPC as soon as possible. Initially we were planning to 
wait for a final stable API, but I think we have given up the plans to 
have everything completely stable and final at least for 2.0, so there 
is no real reason to wait for that, is there? The publication of the 
manual would of course not mean that we won't update the arXiv version 
anymore.
If there is support for it, I'd volunteer to take the lead on this and 
do the boilerplate and organisational work, and then delegate to you all 
for specific parts of it.

What do you think?

Cheers,
Frank