[Rivet] CMS analyses

[Andy Buckley]

On 06/02/12 14:55, Albert Knutsson wrote:
> Dear Rivet developers,
>
> please find attached a tar ball with four CMS analyses.
>
> - CMS_2011_S8941262, Open beauty production cross sections with muons
> - CMS_2011_S8973270, B Bbar angular correlations
> - CMS_2011_S9215166, Forward energy flow at sqrt(s)= 0.9 and 7 TeV)
> - CMS_QCD_10_024, Eta of charged particles sqrt(s)=0.9 and 7 TeV)

Thanks Albert,

I've added tidied-up versions of these to Rivet now, in time for version 
1.8.0. It took a few hours to go through them to my satisfaction, so 
here are a few comments. The last one is significant in terms of the 
physics content of the analysis.

* Just a reminder of the Rivet coding conventions: these are documented 
at http://projects.hepforge.org/rivet/trac/wiki/CodingStyleGuide
It's not a great use of our time to go through analyses modifying them 
to meet the already-advertised coding style.

* When there are equivalent histos at multiple energies, you only need 
to make one of each histo object and choose which histo code it's used 
for in the init(). This then saves *loads* of code duplication later, so 
we're very keen to have code written this way. I've modified the 
offenders :)

* Rivet's normalize() function now includes contributions from histo 
overflows, so you can use it in place of the old counters+scale() method 
in most cases. This again saves on lots of code.

* Avoid making member variables for things which only live in the event 
loop -- you then have to explicitly re-init them in every event for no 
reason!

* Remember that the event counters are sums of weights, so they have to 
be doubles rather than ints.

* jetsByPt returns the jets ordered by decreasing pT, so no need to e.g. 
work out the list indices of the hardest and second-hardest pT jets: 
they'll automatically be 0 and 1.

* Remember the built-in deltaPhi, deltaR, etc. functions (in 
Math/MathUtils.hh, which is automatically visible to all analyses). So 
you don't have to (and shouldn't) explicitly do all that "if (dphi > 
2*PI) dphi -= PI" stuff.

* In CMS_2011_S9215166 the delta(phi) between the leading jets is 
calculated explicitly to be in the range [0, pi], and then there's a 
(deltaPhi-pi < 1.0) "back to back" cut. Did I read this wrongly? It 
looks to me like this cut can't work because deltaPhi-pi is always < 0.

Cheers,
Andy

-- 
Dr Andy Buckley
SUPA Advanced Research Fellow
Particle Physics Experiment Group, University of Edinburgh

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.