[Rivet] Normalization issue in a Rivet STAR analysis?

[Peter Skands]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.hepforge.org/lists-archive/rivet/attachments/20150331/51e6ae39/attachment.html>