[Rivet] new Rivet plug-in, ALICE

[Sercan Sen]

Hello Andy,

I found the source of this difference. Please have a look at these plots:
http://www.hep.ucl.ac.uk/~ssen/LPCC/DEBUG/aliceDiffraction/plots/

I think you run over inelastic + elastic events (e.g., "softQCD:all = on" in pythia8) and it seems that elastic events are not killed by the cuts in the Rivet routine. if you look at the inel plot, we fill it for each event and when you run over inel+el, of course you end up with a larger cross-section. We should either add a trigger cut to kill elastic events or only run over inelastic events. However, I haven't realized such a trigger cut in the paper or never heard from Martin. Do we need this cut or is it ok to run over inel ??

I checked similar issues 2-3 months ago and have a small list of analyses which do not include such trigger cuts and the resulting distributions are really depend on the steering files of the generators.

For example this analysis does not include a trigger cut and info file suggest to run over NSD events. If you add SD or elastic events, you observe a large normalization issue:
http://www.hep.ucl.ac.uk/~ssen/LPCC/DEBUG/MinBiasParam/CMS_2010_S8656010_el/

By the way, in my previous email I was asking which tune did you run and so on. Because, on my Mac 10.6.8, Safari 5.1.7, your plots didn't correctly show up. please see first attachment. Only the first two distributions (legends) were visible. Later, when I clicked on one of the plot, I realized that you had ctau and 4C distributions as well.. second attachment.

(By the way, should a ctau cut be used
with this analysis? This should be specified in the RunInfo. ATLAS
generator level plots ~always keep Ks and Lambda stable with a "> 10mm =
stable" requirement.)

Yes, ctau cut should be used.

Ok, thanks! That makes a big difference obviously: was the analysis done
with a tracking system or a calorimeter? Since it's particle-level I
have to assume the latter: it's hard/impossible to exactly equate
calorimeter clusters/towers with primary particles due to conversions, etc.

It measures only charged particles at the detector level (Martin can correct if I am wrong), however, I check the distributions with FinalState and/or ChargedFinalState projections just for my curiosity. Using ChargedFinalState Projection is ok both for SD and DD, and also this gives the same/reasonable results with the hadron level MC used in this analysis.

Thanks, Cheers,
Sercan




[cid:C02F5F81-2E1D-407C-8253-41FDD2DCCBEA]




[cid:A587D6B4-D5D3-4D4C-8CE0-F7B4E7764E1E]


On Dec 7, 2012, at 7:35 PM, Andy Buckley wrote:

On 07/12/12 19:13, Sercan Sen wrote:

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.

I was a bit amazed ;) And very pleased to not have to debug where I had
introduced a difference!

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.

I was running Pythia8 with tune 4Cx. I also had a ctau = 10mm cut
enabled, which I thought might have had an effect, but I turned it off
and saw only very small changes. (By the way, should a ctau cut be used
with this analysis? This should be specified in the RunInfo. ATLAS
generator level plots ~always keep Ks and Lambda stable with a "> 10mm =
stable" requirement.)

I also ran with tune 4C, which affects the INEL distributions but not
the diffractive ones -- as would be expected (that's why I wasn't very
bothered about which tune I used).

I've updated my plots to include these extra runs.

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.

Ok, thanks! That makes a big difference obviously: was the analysis done
with a tracking system or a calorimeter? Since it's particle-level I
have to assume the latter: it's hard/impossible to exactly equate
calorimeter clusters/towers with primary particles due to conversions, etc.

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.

Yes, hence no real complaint! But if you do come across missing features
like this (I guess you probably looked for a particlesByRapidity() and
didn't find it) then please ask and we'll try to be helpful. It took me
a couple of minutes to add, since the sorting functor for rapidity (and
|y|) already existed.

You could have done the sorting by hand using std::sort and that
cmpParticleByRapidity function, but I'm not surprised if people don't
find that sort of "semi-internal" functionality that we don't advertise!

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.

Cool :-) That would be great... and if you happen to update it before
the release (the beta is about to go for testing) then we'll happily put
the tidied-up version into 1.8.2.

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

It wasn't a real question... the point is that we would never consider,
say, generating a second random number to deal with the case where
rand/RAND_MAX is exactly 0.5, so why attempt to handle the equally
unlikely case where eta1 == eta2? :)

Have a good weekend,
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<mailto: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
----------------------------------------------



--
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/c7dcf21b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen shot 2012-12-07 at 8.04.26 PM.png
Type: image/png
Size: 77378 bytes
Desc: Screen shot 2012-12-07 at 8.04.26 PM.png
URL: <http://www.hepforge.org/lists-archive/rivet/attachments/20121207/c7dcf21b/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen shot 2012-12-07 at 9.28.25 PM.png
Type: image/png
Size: 46518 bytes
Desc: Screen shot 2012-12-07 at 9.28.25 PM.png
URL: <http://www.hepforge.org/lists-archive/rivet/attachments/20121207/c7dcf21b/attachment-0001.png>