<html><head><style>body{font-family:Helvetica,Arial;font-size:13px}</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">Hi Andy</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">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?</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">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)):</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><a href="http://arxiv.org/pdf/0808.2041v2.pdf"></a><div id="bloop_customfont" style="margin: 0px;"><a href="http://arxiv.org/pdf/0808.2041v2.pdf"></a><a href="http://arxiv.org/pdf/0808.2041v2.pdf">http://arxiv.org/pdf/0808.2041v2.pdf</a></div><div><br></div></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">The tabulated data points for the plots are archived on this page:</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><a href="https://drupal.star.bnl.gov/STAR/files/starpublications/124/data.html">https://drupal.star.bnl.gov/STAR/files/starpublications/124/data.html</a> </div> <div><br></div><div>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. </div><div><br></div><div>1. Apply BBC min-bias trigger. </div><div>Require a hit in both forward and backward BBCs. <span style="font-family: 'helvetica Neue', helvetica; line-height: 19px;">The BBC coverage is 3.5 < |eta| < 5.0 (PRC</span><span style="font-family: 'helvetica Neue', helvetica; line-height: 19px;"> 75 </span><a href="tel://(2007) 064901" style="font-family: 'helvetica Neue', helvetica; line-height: 19px;">(2007) 064901</a><span style="font-family: 'helvetica Neue', helvetica; line-height: 19px;"> section II).</span></div><div><br></div><div>2. Apply central track finding efficiencies (assumed independent of eta, since the coverage is anyway tiny):</div><div>For tracks with pT between 0 and 600 MeV, use the following interpolation table (in 50-MeV steps from 0 - 600):</div><div><span style="font-family: 'helvetica Neue', helvetica; line-height: 19px;">float trkeff[10] ={0,0,0.38,0.72,0.78,0.81,0.82,</span><span style="font-family: 'helvetica Neue', helvetica; line-height: 19px;">0.84,0.85,0.86,0.87,0.88}; </span></div><div><div>Tracks with pT > 600 MeV have 0.88 probability to be found.</div></div><div><br></div><div>(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.)</div><div><br></div><div><span style="font-family: 'helvetica Neue', helvetica; line-height: 19px;">3. Apply vertex finding efficiency (else throw even away). Use the numbers in this table here:</span></div><div><a href="https://drupal.star.bnl.gov/STAR/files/starpublications/124/Fig11a_vtx_eff_vs_global_pp.txt">https://drupal.star.bnl.gov/STAR/files/starpublications/124/Fig11a_vtx_eff_vs_global_pp.txt</a> </div><div><br></div><div><font face="helvetica Neue, helvetica"><span style="line-height: 19px;">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.</span></font></div><div><font face="helvetica Neue, helvetica"><span style="line-height: 19px;"><br></span></font></div><div><font face="helvetica Neue, helvetica"><span style="line-height: 19px;">Would this be all the info needed to “fix” the analyses? In particular </span></font><span style="white-space: pre-wrap;">STAR_2008_S7869363/d01-x01-y01</span><span style="line-height: 19px; font-family: 'helvetica Neue', helvetica;">:</span></div><div><a href="http://mcplots.cern.ch/?query=plots,ppppbar,uemb-soft,nch#pp200">http://mcplots.cern.ch/?query=plots,ppppbar,uemb-soft,nch#pp200</a> </div><div><font face="helvetica Neue, helvetica"><span style="line-height: 19px;"><br></span></font></div><div><font face="helvetica Neue, helvetica"><span style="line-height: 19px;">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):</span></font></div><div><a href="http://mcplots.cern.ch/?query=plots,ppppbar,uemb-soft,p_pt#pp200">http://mcplots.cern.ch/?query=plots,ppppbar,uemb-soft,p_pt#pp200</a> </div><div><font face="helvetica Neue, helvetica"><span style="line-height: 19px;"><br></span></font></div><div><font face="helvetica Neue, helvetica"><span style="line-height: 19px;">Peter</span></font></div><div><span style="font-family: 'helvetica Neue', helvetica; line-height: 19px;"><br></span></div> <div id="bloop_sign_1428360045318642176" class="bloop_sign">—<div>Peter Skands</div><div>Associate Professor, ARC Future Fellow</div><div><div id="bloop_sign_1424726530974701824" class="bloop_sign" style="font-family: Helvetica, Arial;"><div style="font-family: helvetica, arial;">School of Physics and Astronomy</div><div style="font-family: helvetica, arial;">Monash University, Melbourne</div><div style="font-family: helvetica, arial;">WWW: <a href="http://skands.physics.monash.edu">http://skands.physics.monash.edu</a></div></div><div style="font-family:helvetica,arial;font-size:13px">-- <br>Sent with Airmail</div></div></div> <br><p class="airmail_on" style="color:#000;">On 1 April 2015 at 6:52:12 am, Andy Buckley (<a href="mailto:andy.buckley@cern.ch">andy.buckley@cern.ch</a>) wrote:</p> <blockquote type="cite" class="clean_bq"><span><div><div></div><div>Hi Peter, <br> <br>The unvalidated analysis is on the public website?! The clue is in the <br>name ;-) <br> <br>Anyway, thanks for highlighting this: we have too many analyses <br>languishing in the unvalidated queue, and hopefully we can sort this one <br>out for the next release (which will be 2.2.2). <br> <br>Looking in the analysis info file, I see the following notes: <br> <br>ToDo: <br> - Understand first bin in multiplicity distribution <br> - Normalise to generator values (just scale by 1/nPassedCuts?) rather <br>than data areas <br> <br>So I think the second of those probably explains the normalization <br>issue. The multiplicity distribution remains problematic and is very <br>likely due to what you suggest -- I wish STAR & co would realise the <br>importance of unfolding and fiducial measurements. It'd be great if you <br>can supply the smearing/efficiency function that's needed. <br> <br>The NSD analyses are also an issue for reproducibility (and <br>physicality). I think a special NSD run card will be needed for them, if <br>you really want to base comparisons on them. Not all generators have <br>such a concept that can be switched on/off, e.g. EPOS & friends, which <br>would be interesting for such observables. <br> <br>Cheers,, <br>Andy <br> <br> <br>On 30/03/15 14:06, Peter Skands wrote: <br>> Dear Riveteers (cc Anton) <br>> <br>> Going over some distributions on mcplots recently, I noticed that we <br>> have two RIVET analyses of proton spectra from STAR, appearing to show <br>> contradictory results: <br>> http://mcplots.cern.ch/?query=plots,ppppbar,uemb-soft,p_pt#pp200 <br>> <br>> I have not managed to fully understand the reason yet, so apologies if I <br>> am just sharing my confusion, but here goes. While the experimental data <br>> points appear roughly consistent between the two, the normalization of <br>> the MC curves is different by roughly a factor 2 between the two <br>> analyses, despite the y axis having the same label. From the way the <br>> discrepancies look, my first guess is that there is a normalization <br>> problem with the analysis STAR_2008_S7869363 (added by Holger Shulz and <br>> still listed as unvalidated, whereas the other one is listed as <br>> validated by Hendrik Hoeth), with the MC’s having a factor 2 too small <br>> normalization there. Guessing further, the issue could be either a <br>> problem with the normalization to the phase-space region (eg Delta-Y <br>> range), or eg that only protons (or the average of protons and <br>> antiprotons) are plotted in the MC while perhaps the sum of protons + <br>> antiprotons are plotted in the data. That’s hard to believe though, <br>> since STAR_2008_S7869363 includes a separate proton and antiproton <br>> spectrum, so I am not fully convinced I understand what is going on. <br>> <br>> The multiplicity distribution from that analysis (STAR_2008_S7869363) <br>> also looks rather worrying: <br>> http://mcplots.cern.ch/?query=plots,ppppbar,uemb-soft,nch#pp200 <br>> <br>> One notices that the x axis says “Nch(raw)” which suggests that what is <br>> being counted is not equivalent to the number of MC-generated tracks <br>> which I suspect is what is being plotted for the MCs. Measurements by <br>> UA1 at the same energy (scroll down) appear to contradict the STAR ones, <br>> so my guess is that there should be a correction applied to the MC to <br>> translate from Nch(gen) to Nch(raw), but that this correction is missing <br>> in the implementation of the analysis? I think I have some old <br>> parametrised STAR track-finding efficiencies (a simple accept/reject <br>> based on pT and eta which was claimed to do a faithful job at <br>> translating to raw - we faced the problem then that quite many of the <br>> STAR results had Nch(raw) on the axes) in a mail from people there at <br>> the time, that might do the job, so let me know if you want to see if <br>> the analysis could be recovered by including them. <br>> <br>> The STAR data are of course interesting because they extend our lever <br>> arm for extrapolations downwards in ECM, so even though we are not often <br>> highly concerned about the STAR measurements, they do have some <br>> relevance and would be good to validate if possible. <br>> <br>> Finally, I note that there is a normalization issue for the UA5 NSD Nch <br>> distribution also at 200 GeV: <br>> http://mcplots.cern.ch/?query=plots,ppppbar,uemb-soft,nch#ppbar200 <br>> <br>> I guess that is because we run non-diffractive, and the analysis is <br>> designed for NSD. We had similar issues with some CMS analyses, not sure <br>> if they were ever resolved satisfactorily. Anyway, for this and any <br>> other NSD-specific analyses, it might be necessary to implement a <br>> special NSD run card in mcplots. Alternatively, we would simply have to <br>> kick out any NSD analyses that are not accompanied by an NSD trigger <br>> definition implemented on the Rivet side? Unfortunately that would <br>> include some of the CMS identified particle measurements, like this K0S one: <br>> http://mcplots.cern.ch/?query=plots,ppppbar,uemb-soft,K0S_eta#pp7000 <br>> <br>> At the very least, we would have to replace those by ALICE, ATLAS, or <br>> updated CMS ones with physical trigger definitions. <br>> <br>> Cheers, <br>> Peter <br>> <br>> <br>> — <br>> Peter Skands <br>> Associate Professor, ARC Future Fellow <br>> School of Physics and Astronomy <br>> Monash University, Melbourne <br>> WWW: http://skands.physics.monash.edu <br>> -- <br>> Sent with Airmail <br>> <br>> <br>> _______________________________________________ <br>> Rivet mailing list <br>> Rivet@projects.hepforge.org <br>> https://www.hepforge.org/lists/listinfo/rivet <br>> <br> <br> <br>-- <br>Dr Andy Buckley, Lecturer / Royal Society University Research Fellow <br>Particle Physics Expt Group, University of Glasgow <br></div></div></span></blockquote></body></html>