[Rivet] Normalization issue in a Rivet STAR analysis?

[Andy Buckley]

Hi Peter,

The unvalidated analysis is on the public website?! The clue is in the
name ;-)

Anyway, thanks for highlighting this: we have too many analyses
languishing in the unvalidated queue, and hopefully we can sort this one
out for the next release (which will be 2.2.2).

Looking in the analysis info file, I see the following notes:

ToDo:
 - Understand first bin in multiplicity distribution
 - Normalise to generator values (just scale by 1/nPassedCuts?) rather
than data areas

So I think the second of those probably explains the normalization
issue. The multiplicity distribution remains problematic and is very
likely due to what you suggest -- I wish STAR & co would realise the
importance of unfolding and fiducial measurements. It'd be great if you
can supply the smearing/efficiency function that's needed.

The NSD analyses are also an issue for reproducibility (and
physicality). I think a special NSD run card will be needed for them, if
you really want to base comparisons on them. Not all generators have
such a concept that can be switched on/off, e.g. EPOS & friends, which
would be interesting for such observables.

Cheers,,
Andy


On 30/03/15 14:06, Peter Skands wrote:
> Dear Riveteers (cc Anton)
> 
> Going over some distributions on mcplots recently, I noticed that we
> have two RIVET analyses of proton spectra from STAR, appearing to show
> contradictory results:
> http://mcplots.cern.ch/?query=plots,ppppbar,uemb-soft,p_pt#pp200
> 
> I have not managed to fully understand the reason yet, so apologies if I
> am just sharing my confusion, but here goes. While the experimental data
> points appear roughly consistent between the two, the normalization of
> the MC curves is different by roughly a factor 2 between the two
> analyses, despite the y axis having the same label. From the way the
> discrepancies look, my first guess is that there is a normalization
> problem with the analysis STAR_2008_S7869363 (added by Holger Shulz and
> still listed as unvalidated, whereas the other one is listed as
> validated by Hendrik Hoeth), with the MC’s having a factor 2 too small
> normalization there. Guessing further, the issue could be either a
> problem with the normalization to the phase-space region (eg Delta-Y
> range), or eg that only protons (or the average of protons and
> antiprotons) are plotted in the MC while perhaps the sum of protons +
> antiprotons are plotted in the data. That’s hard to believe though,
> since STAR_2008_S7869363 includes a separate proton and antiproton
> spectrum, so I am not fully convinced I understand what is going on.
> 
> The multiplicity distribution from that analysis (STAR_2008_S7869363)
> also looks rather worrying:
> http://mcplots.cern.ch/?query=plots,ppppbar,uemb-soft,nch#pp200
> 
> One notices that the x axis says “Nch(raw)” which suggests that what is
> being counted is not equivalent to the number of MC-generated tracks
> which I suspect is what is being plotted for the MCs. Measurements by
> UA1 at the same energy (scroll down) appear to contradict the STAR ones,
> so my guess is that there should be a correction applied to the MC to
> translate from Nch(gen) to Nch(raw), but that this correction is missing
> in the implementation of the analysis? I think I have some old
> parametrised STAR track-finding efficiencies (a simple accept/reject
> based on pT and eta which was claimed to do a faithful job at
> translating to raw - we faced the problem then that quite many of the
> STAR results had Nch(raw) on the axes) in a mail from people there at
> the time, that might do the job, so let me know if you want to see if
> the analysis could be recovered by including them. 
> 
> The STAR data are of course interesting because they extend our lever
> arm for extrapolations downwards in ECM, so even though we are not often
> highly concerned about the STAR measurements, they do have some
> relevance and would be good to validate if possible.
> 
> Finally, I note that there is a normalization issue for the UA5 NSD Nch
> distribution also at 200 GeV:
> http://mcplots.cern.ch/?query=plots,ppppbar,uemb-soft,nch#ppbar200
> 
> I guess that is because we run non-diffractive, and the analysis is
> designed for NSD. We had similar issues with some CMS analyses, not sure
> if they were ever resolved satisfactorily. Anyway, for this and any
> other NSD-specific analyses, it might be necessary to implement a
> special NSD run card in mcplots. Alternatively, we would simply have to
> kick out any NSD analyses that are not accompanied by an NSD trigger
> definition implemented on the Rivet side? Unfortunately that would
> include some of the CMS identified particle measurements, like this K0S one:
> http://mcplots.cern.ch/?query=plots,ppppbar,uemb-soft,K0S_eta#pp7000 
> 
> At the very least, we would have to replace those by ALICE, ATLAS, or
> updated CMS ones with physical trigger definitions. 
> 
> Cheers,
> Peter
> 
> 
> —
> Peter Skands
> Associate Professor, ARC Future Fellow
> School of Physics and Astronomy
> Monash University, Melbourne
> WWW: http://skands.physics.monash.edu
> -- 
> Sent with Airmail
> 
> 
> _______________________________________________
> Rivet mailing list
> Rivet at projects.hepforge.org
> https://www.hepforge.org/lists/listinfo/rivet
> 


-- 
Dr Andy Buckley, Lecturer / Royal Society University Research Fellow
Particle Physics Expt Group, University of Glasgow