[Rivet] CMS_2015_I1370682.tgz

[Andy Buckley]

One other thing that I forgot to mention: this analysis and particularly 
the PseudoTop class were written using C++11 features. We love C++11, 
but since we sit between the experiments and theorists we also have to 
make life straightforward for those without the up-to-date experiment 
compiler suites, etc.

The SL6 default compilers don't do C++11 at a sufficient level, so for 
several years we have had to avoid C++11 features in official Rivet code 
(it can be used in plugin analyses, but not ones that get integrated 
into the main release.)

I've converted the code back to standard C++98 for now, but that's 
something we'd prefer not to do regularly since it's the sort of 
transformation that's perfect for introducing bugs. (A bit less use of 
"auto" would aid code readability even in C++11-land!) So can you ensure 
that *for now*, the analysis codes coming from CMS are in C++98? We will 
move to using C++11 as standard in Rivet v3.0.0, if not in an earlier v2 
major release.

Best wishes,
Andy


On 23/02/16 22:11, Andy Buckley wrote:
> Hi Xavier,
>
> I finally got free from various other commitments and have integrated
> this analysis into Rivet for the upcoming 2.4.1 release.
>
> The approach that we decided to take is to embed the PseudoJet class
> "inline" in the analysis .cc file: see
> https://rivet.hepforge.org/hg/rivet/file/tip/src/Analyses/CMS_2015_I1370682.cc
>
>
> I've used an unnamed namespace for this embedding, which I think should
> ensure that the exact same PseudoJet code -- or a slightly different &
> evolved version, which is why we did it this way -- can be embedded into
> other analyses without symbol clashes and similar fun.
>
> Obviously this isn't great for code reuse, but our experience with quite
> analysis-specific quantities like photon/lepton/jet isolation algorithms
> has been that it's better to define them locally to the analysis at
> least until it seems certain that the definitions are globally suitable.
> Some features of this one, such as the hard-coded target top and W
> masses, probably wouldn't be suitable for all pseudo-top analyses.
>
> Just a reminder that we also still haven't integrated CMS_2014_I1305624
> into Rivet because of the dodgy "EventShape_rivet" class that it came
> with. Most of the functionality of this class is implemented already,
> and more nicely, in Rivet's own vector classes and event shape
> projections, and this doesn't look like something that will be easy for
> us to maintain in future. But if you do want to keep it more-or-less as
> it currently is, then please use the same unnamed namespace trick and
> resubmit the single .cc file to us. Thanks!
>
> Best wishes,
> Andy
>
>
> On 27/11/15 20:42, Janssen Xavier wrote:
>> Hi,
>>
>> I am submitting the first TOP plugin from CMS but we need to discuss
>> as the people responsible for it wrote a ‘PseudoTop’ class that they
>> intend to re-use across different analysis in the future.
>> I am not sure however how this works for you and maybe it needs ad
>> minima renaming to CMS_PseudoTop
>>
>> Let me known,
>>
>> Xavier,
>> _______________________________________________
>> Rivet mailing list
>> Rivet at projects.hepforge.org
>> https://www.hepforge.org/lists/listinfo/rivet
>>
>
>


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