[Rivet] new Rivet plug-in, ALICE

[Andy Buckley]

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