[Rivet] Rivet 2.4.1, 2.5, 2.6 and 3.0 dev / release plans

[Andy Buckley]

Hi all,

Just to keep you in the loop, in the last couple of weeks I've merged in 
the remaining contributed analyses to the 2.4.x Rivet branch, and since 
Chris' validation tests just passed with flying colours I think we're 
ready for a 2.4.1 release (and a corresponding YODA 1.5.8) tomorrow. 
This version also contains some plotting code improvements to smooth the 
path to multiweighted histo output in v3.0.

More interesting is the plan for the next major versions, 2.5, 2.6, and 
3.0; the first of these should come pretty soon, in fact. It currently 
contains a few advances over 2.4.x including the ability to give 
analyses alias names for the loader to use, to smooth the migration of 
older analyses from SPIRES-based to Inspire-based names. I will do some 
more of the grunt work toward that migration (i.e. making the Inspire 
names the canonical ones, while still supporting the SPIRES names as -a 
arguments), and remove the automated event rotation that was annoying 
Tanguy. After that, the only thing on my 2.5 to-do list is to make 
make-plots gracefully handle NaN values when plotting, since YODA 1.6.0 
will return NaN for uncomputables, e.g. profile bin means in bins with 
no fills, or uncertainties in bins with < 2 fills.

v2.6 should also happen in the next few months. The distinctive thing 
here will be addition of *very limited* smearing machinery for BSM 
search analysis implementation. Chris and I have been following the Les 
Houches discussions over data analysis encoding, and it seems obvious 
that there is a real need here and that our SM methodology is now 
sufficiently established that we don't need to worry about there being a 
"slippery slope": the experiments get that unfolding is the gold 
standard, and anyway the accuracy of crude smearing is not going to be 
sufficient for SM measurement needs... while for BSM purposes it should 
be sufficient. Input on this is extremely welcome, and maybe we can make 
it the focus of a long-overdue Rivet hackfest in the next few months?

The smearing function design I have in mind would benefit from 
availability of C++11 features (particularly lambda functions), and so I 
think 2.6 would be a good place to make the switch to C++11... rather 
than placing all our eggs in the v3.0 basket and thus making that 
release unbelievably difficult. This is also part of my thinking in 
starting the SPIRES -> Inspire migration now rather than also adding 
that to the huge list of v3.0 to-dos. It's particularly relevant since 
CMS have recently started submitting analysis codes using C++11 
features, and we don't want to put unnecessary barriers in the way; for 
users outside the experiment software setups, it is relatively easy to 
set up a C++11 compiler from CVMFS, and we should provide instructions 
on how to do that. We also need to grasp the nettle of how to allow 
analyses to just FastJet contrib features... should we make fjcontrib 
(or specific bits of it?) a Rivet dependency?

And you all know about v3.0: it's the 
NLO/multiweight/continuous-finalizing/etc. release that will blow 
everyone's socks off. Let's get it out this year ;-)

That's more than enough from me. Thanks for reading. And let's have a 
Rivet hacking & planning meet-up sometime soon.

FYI, here's the big Rivet to-do list in the sky, if you're looking for 
something to do:
https://trello.com/b/D8eBEuRM/rivet

Andy

-- 
Dr Andy Buckley, Lecturer / Royal Society University Research Fellow
Particle Physics Expt Group, University of Glasgow