|
[Rivet] Normalization issue in a Rivet STAR analysis?Peter Skands peter.skands at monash.eduWed Oct 7 23:12:56 BST 2015
Hi Andy Thanks for following up! Good point that I could actually start working with students on making/fixing RIVET analyses, like this one. I’ve had a few 3rd year students approach me about possible projects, so I could see if it could be proposed to any of them. Anton has a number of analyses and other updates that we would like to get onto MCPLOTS on his table, so I think he is quite busy for the time being? By the way, do you still have plans to allow to call finalize() (or something equivalent) several times during the run, eg to permit run-time display of non-trivial histograms? At the moment, I also don’t think we are able to merge histograms from different subruns if they have non-trivial finalize() methods - is that right Anton? For all the linearly scaling ones, the MCPLOTS volunteers generate huge statistics, but when it comes to more complex analyses we are limited to single-run ones. Is that still true in the most recent RIVET versions? 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 On 7 October 2015 at 6:05:45 pm, Andy Buckley (andy.buckley at cern.ch) wrote: Hi Peter (& Anton), Just so you know, we haven't forgotten about this... but as none of the Rivet developer "usual suspects" are using this analysis it keeps slipping down the to-do list compared to other projects and pressures. Do you have anyone in Monash (or elsewhere) working with you on interpretation of these data? We'd love to get them fixed, but it is probably best done by someone with an incentive to have them working, as well as a close interest in the physics. We are about to release a new Rivet version (2.4.0), but our plan is to now work to a regular 3 monthly analysis-update release cycle, so there will be another one around the new year. Hence now would be an excellent time to start work on fixing this issue. Cheers, Andy On 07/04/15 00:18, Peter Skands wrote: > 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> > <http://arxiv.org/pdf/0808.2041v2.pdf>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 <tel://(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 > <mailto: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 -- 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/20151007/a8d40f94/attachment.html>
More information about the Rivet mailing list |