[Rivet] C++11 plan for Rivet

[Andy Buckley]

On 17/03/16 10:27, Holger Schulz wrote:
>
>
> On 17/03/16 09:19, Andy Buckley wrote:
>> Hi all,
>>
>> I'm currently hacking together a prototype physics object smearing
>> system for Rivet 2.5 or 2.6, to be beta-tested with the BSM
>> experimental groups and re-casters. No capitulation: we will continue
>> to require unfolded "proper" measurements, but there is BSM demand for
>> Rivet and they will not bite unless we can provide at least some
>> simple machinery for efficiency curves.
>
> I completely agree now that the ATOM guys have essentially decoupled
> their efforts from Rivet.
> I did something like that in my ATLAS analysis for random removal of
> tracks based on track
> reco efficiency and I know that there is demand to have that in rivet, too.

Somehow I was interested enough in this to spend a bit of time hacking a 
start together. Here it is:

https://rivet.hepforge.org/hg/rivet/file/tip/include/Rivet/Projections/SmearedParticles.hh
https://rivet.hepforge.org/hg/rivet/file/tip/include/Rivet/Projections/SmearedJets.hh

(Connoisseurs of borderline-evil code may like to note how the function 
hash for projection comparison is being done ;-) But no worse than what 
you need to do to use POSIX dlsym... aka the evil_cast in AGILe's module 
loader.)

And here's how the SmearedJets looks in action in an analysis:

FastJets fj(FinalState(Cuts::abseta < 5), FastJets::ANTIKT, 0.4);
SmearedJets sj(fj, JET_EFF_ONE, JET_SMEAR_IDENTITY);

Ok, those are do-nothing standard perfect efficiency and smearing 
functions, but the principle works. I'm populating a file with a few 
real efficiency and smearing functions... but they will strongly benefit 
from going to mandatory C++11 so we can use the new random generator 
machinery. And here's another C++11 killer feature for this use-case -- 
inline lambda functions:

SmearedJets sj(fj,
                [](const Jet& j) { return 1 - exp(-j.pT()/(10*GeV)); },
                [](const Jet& j) { return j; });

I think this stuff makes a pretty good case for going to C++11 with the 
addition of this feature... and then gradually converting lots of our 
internal Boost and hackery to use the much nicer new language features 
instead.

>> The way I'm designing it can all be done with Boost features, but once
>> again it's stuff that is part of the core language in C++11 and using
>> the less-standard Boost implementations feels like going in the wrong
>> direction. Also, we are starting to see submitted analyses which use
>> C++11 features, and it both feels unnecessarily restrictive on our
>> "clients" and is extra work for us to have to revert that code to C++98.
>>
>> So I would like us to make the switch to mandatory C++11 building of
>> Rivet in the next couple of 2.x releases. This would also help us to
>> reduce the currently huge number of "paradigm shifts" scheduled (for
>> lack of imagination) on v3.0.
>>
>> There is one major sticking point, in the form of FastJet. While C++11
>> compatible, it makes use of auto_ptr and exposes that in its public
>> headers, meaning that anyone compiling a Rivet analysis in C++11 mode
>> gets a terminal output dominated by FJ auto_ptr deprecation warnings.
>> There seems to be no way in GCC to disable these warnings -- or does
>> someone know of one? So I think we need to put a bit of pressure on
>> FastJet to make a non-complaining release; I already did this ~6
>> months ago and was told that they are working on a major new
>> development, but it has not appeared and the issue is more urgent now
>> (I don't know what the experiments are doing re. this). So I'll prod
>> them again and hopefully we'll be able to make this switch in Rivet
>> 2.5 or 2.6.
>
> We can just ask again, maybe point them to this forum:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59325

Did that: thanks for the link :-) And the timing was good: FastJet 3.2.0 
is out now and at the last minute they removed auto_ptr from fjcore and 
added a configure-time option to disable the auto_ptrs in the main FJ 
interface.

And it looks like LCG can be persuaded to build their FJ 3.2.0 
installations using that flag, so once there is such a bundle to play 
with, we can make a mandatory C++11 release. Which I would like to use 
for beta-testing the new smearing features with interested parties.

Cheers,
Andy

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