[Rivet] new Rivet plug-in, ALICE

[Sercan Sen]

Hi Andy,

some comments inline -

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.


Thanks for checking this routine so quickly and for the clean up. It's good to hear that you get the same results after all these modifications.


However, the answers
that I got with Pythia8 were *very* different from the ones you showed:


I think you run Pythia8.170 with the default tune ? What I sent before was Pythia8.165 with tune4C (default). Let me run the jobs again also with Pythia8.170 to see what is going on.

Also, my suspicious is that we had two versions of the routine with a minor difference about using FinalState or ChargedFinalState projection. I am going to check it if this is the case.


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

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.


Since there is no particlesByRapidity() method in the current release, we order the particles by rapidity and find the most forward / backward particles etc. in the routine.  I am sure the style is not good, no doubt : ) but gives the same results.


Using this and
calculating the eta-ordered gap sizes into a vector eliminated a lot of
fiddly code.


I really like this part of the code. I can also update ATLAS inelastic rivet routine later by doing something similar to this.


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?" ;-)

we generate a double precision number between 0 and 1 and I would not worry about the possibility of having a number exactly equals to 0.500000... But I agree one should add a "=" to the following line "(double)rand() / (double)RAND_MAX >= 0.5". I personally don't expect any difference on the results by using the fastest or slowest particle information when the generated number is exactly 0.5...

Cheers,
Sercan







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<mailto: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.


--
Sercan Sen http://cern.ch/ssen
----------------------------------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.hepforge.org/lists-archive/rivet/attachments/20121207/301149f8/attachment.html>