[Rivet] Normalization issue in a Rivet STAR analysis?

[Peter Skands]

Hi Andy

Yes, we included some unvalidated ones especially in the beginning when there were not validated ones for all aspects. The aim was also to crowdsource their validation, ie people would tell us if something looked odd. But you’re right it would probably be constructive put an unvalidated disclaimer on plots that come from such analyses, just to alert people to the fact that they should double check what they are seeing. Anton, would you be able to add a Jira about that?

Concerning the STAR Nch(raw) measurements, I’ve found the efficiency tables in a mail from five years ago. They correspond to Fig.11a and Fig.13a of one of the published STAR analyses we use from RIVET (“global" tracks are what we want), so the numbers are all “blessed” in that sense (Phys. Rev. C 79, 034909 (2009)):
http://arxiv.org/pdf/0808.2041v2.pdf

The tabulated data points for the plots are archived on this page:
https://drupal.star.bnl.gov/STAR/files/starpublications/124/data.html 

To translate from an MC analysis to a STAR Nch(raw) number, I worked out the following procedure with Mark Heinz who was on STAR at the time. 

1. Apply BBC min-bias trigger. 
Require a hit in both forward and backward BBCs. The BBC coverage is 3.5 < |eta| < 5.0 (PRC 75 (2007) 064901 section II).

2. Apply central track finding efficiencies (assumed independent of eta, since the coverage is anyway tiny):
For tracks with pT between 0 and 600 MeV, use the following interpolation table (in 50-MeV steps from 0 - 600):
float trkeff[10] ={0,0,0.38,0.72,0.78,0.81,0.82,0.84,0.85,0.86,0.87,0.88}; 
Tracks with pT > 600 MeV have 0.88 probability to be found.

(In principle, the paper gives separate efficiencies for pions, kaons, and protons, so I’m not 100% sure whether those should be applied, or just the table above.)

3. Apply vertex finding efficiency (else throw even away). Use the numbers in this table here:
https://drupal.star.bnl.gov/STAR/files/starpublications/124/Fig11a_vtx_eff_vs_global_pp.txt 

Note that their vertex finding efficiency is non-zero already for events with 1 track. That’s because they apply a constraint with whether that track intersects the beam spot, which is constrained down to a few mm.

Would this be all the info needed to “fix” the analyses? In particular STAR_2008_S7869363/d01-x01-y01:
http://mcplots.cern.ch/?query=plots,ppppbar,uemb-soft,nch#pp200 

Note that I’m still not sure I understand the identified-particle spectra, in particular the proton and antiproton MC curves contradict those from another STAR analysis (which looks fine):
http://mcplots.cern.ch/?query=plots,ppppbar,uemb-soft,p_pt#pp200 

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

On 1 April 2015 at 6:52:12 am, Andy Buckley (andy.buckley at cern.ch) wrote:

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