[Rivet] new Rivet plug-in, ALICE

[Andy Buckley]

Hi Sercan and Martin,

I actually ended up rewriting the analysis this morning because it
needed a lot of cleaning up (and it shrank by almost a factor of two in
the process!). I've checked both analysis versions with Pythia8.170 and
get exactly the same answers, so I think it's fine. However, the answers
that I got with Pythia8 were *very* different from the ones you showed:

http://users.hepforge.org/~buckley/plots-ALICE_2012_I1181770/ALICE_2012_I1181770/index.html

I'm also wondering (Martin is probably best placed to answer) how
model-independent this data is. The names given to the different
selections are phenomenological/theoretical, i.e. individual events are
identified as "single diffractive", "double diffractive", etc. Of course
in reality this clean separation isn't possible, since the distributions
of event types overlap. The abstract says something about the
measurement having been done with "a simulation of diffraction adjusted
to data" -- so are the data actually directly as measured in those phase
spaces or have they been "corrected" by this unnamed simulation? Is
there a systematic error associated with the simulation? I really
thought we had moved beyond this...

I'm also wondering how there can be no experimental pT or eta cuts at
all! There must have been some eta beyond which ALICE has no acceptance,
and the most forward and backward gaps identified in this analysis are
probably outside that acceptance. How does this work? I hope it's not
been filled in with an MC model, because in that case we have an
analysis that tests the difference between two MCs, not between MC and
data :)



Ok, that's all on the physics content: I'd be very interested to know
the answers (since these questions are related to exactly the sort of
model-dependence issue that Rivet has been quite invested in addressing
at the LHC). Mainly for Sercan's interest, my rewritten version of the
code is here:

https://rivet.hepforge.org/trac/browser/branches/2012-06-aidarivet/src/Analyses/ALICE_2012_I1181770.cc

Note that this won't actually work with the current Rivet release, as I
added a FinalState::particlesByRapidity() method which this analysis
highlighted as a missing bit of functionality. Using this and
calculating the eta-ordered gap sizes into a vector eliminated a lot of
fiddly code. I have also marked the analysis as VALIDATED in the .info
file: please do this when you consider the analysis to have been checked
and to have reproduced the analysis procedure and the MC lines in the
paper, where available.

Stylistically, please also try to avoid C/Fortran en masse variable
declarations like this at the top of the routine:

      double Eslowest(0.0), pslowest(0.0), yslowest(999.);
      double Efastest(0.0), pfastest(0.0), yfastest(-999.);
      int pidslowest(0), pidfastest(0);

By storing the "fastest"/"slowest" (weird names...) Particle objects, I
eliminated all of this, and in general variables should be declared as
close as possible to where they are set and used. Please also note that
this sort of code can and should be avoided in Rivet analyses:

if (fuzzyEquals(sqrtS()/GeV, 900, 1E-3)) {
  _h_xsec_dd->fill( 900/GeV, weight);
} else if (fuzzyEquals(sqrtS()/GeV, 2760, 1E-3)) {
  _h_xsec_dd->fill( 2760/GeV, weight);
} else if (fuzzyEquals(sqrtS()/GeV, 7000, 1E-3)) {
  _h_xsec_dd->fill( 7000/GeV, weight);
}

There were several of these and if you look closely you'll note a) the
900/GeV is definitely wrong b) this can be entirely replaced with

_h_xsec_dd->fill(sqrtS()/GeV, weight);

since you've explicitly checked that sqrtS()/GeV *is* 900, 2760, etc. in
the if statements! There is another haphazard use of the GeV unit in the
next line:

double Mx = sqrt((sqrtS()/GeV-Elead-plead)*(sqrtS()/GeV-Elead+plead));

I checked, and sqrtS(), Elead, and plead are all equally "unitful"
quantities: so they should either all be divided by GeV, or none of
them. I prefer to do it to none of them, so that the units conversions
only appear in application of cuts or when filling histograms.

Finally, I have removed the use of a random number to handle the case
when two floats are exactly equal. This has a negligible occurrence if
there are no special values that the float will tend to appear at, and
as Hendrik pointed out to me "if that's a problem, what do you do when
the random number is exactly 0.5?" ;-)

Cheers,
Andy


On 06/12/12 18:22, Andy Buckley wrote:
> Thanks Sercan,
> 
> We were just about to release a new tarball for testing, but will get
> this in first! (I'll do the build integration for this one, Hendrik).
> 
> Andy
> 
> 
> On 06/12/12 17:22, Sercan Sen wrote:
>>
>> Dear all, 
>>
>> Attached is the Rivet plug-in for diffractive and total inelastic cross
>> section measurements paper from ALICE, http://arxiv.org/pdf/1208.4968.pdf. 
>>
>> We check the plug-in & results with M. Poghosyan (in cc) who is the
>> analysis contact of this paper in ALICE. 
>>
>> plots:
>> http://www.hep.ucl.ac.uk/~ssen/LPCC/Rivet/ALICE_2012_I1181770/plots/
>>
>> Thanks for including it for the next release. 
>>
>> Cheers,
>> Sercan 
>>
>> -- 
>> Sercan Sen http://cern.ch/ssen
>> ----------------------------------------------
>>
>>
>>
>> _______________________________________________
>> Rivet mailing list
>> Rivet at projects.hepforge.org
>> http://www.hepforge.org/lists/listinfo/rivet
>>
> 
> 


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

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