[Rivet] C++11 plan for Rivet

[Andy Buckley]

Yes, I agree. This should be an opportunity to clean up and make our API 
more expressive, not to introduce more fallbacks and complexity.

Andy


On 24/03/16 10:27, David Grellscheid wrote:
> Hi Andy,
>
> I'm all for the transition to C++11. But if we do it, I vote for a hard
> switchover. No backwards compat flags, #ifdefs falling back to Boost,
> etc. Once a function is converted, it stays that way. We should assume a
> fully-compliant C++11 compiler and not have to worry about use of
> individual features, and when they started being supported by which
> version of gcc.
>
> See you,
>
>    David
>
>
>
> On 23/03/2016 22:19, Andy Buckley wrote:
>> 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