[Rivet] new Rivet plug-in, ALICE

[Andy Buckley]

On 07/12/12 21:59, Sercan Sen wrote:
> 
> 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/

That list sounds useful. I think it would be a good idea to add trigger
cuts to "min bias" analyses so they are not incredibly sensitive to
whether or not elastic events are included... could you post the list?

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

If it's a track analysis then I think ChargedFinalState is more
appropriate... it depends on what the experimental analysis corrected
for, but I hope correcting from charged particles back to all particles
wasn't part of it! It won't make much difference, but the principle is
that the MC analysis should be as close as possible to the data one.

Martin, can you clarify this (and whether the data has been "corrected"
by MC-specific definition of "single-diffractive", etc., or if the
observables this analysis makes from final-state info are directly
equivalent to what was measured in the data?)

Thanks again,
Andy


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


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