From: Flemming Videbaek (videbaek@sgs1.hirg.bnl.gov)
Date: Tue May 20 2003 - 11:25:32 EDT
Hi Bjoern While waiting for beam during the pp2pp Kris and I went over your plots to try to understand it better. One this that certainly is a bit curious that you use the same acceptance map on the Au.Au data. What data run was it? Were the tpm1-d5-tpm2 moved 50 cm back as in the pp data; this it was for sure in pp since the 35 deg can only be reached in that config. If not, you cannot use the same acceptance map for pp and au-au the +50 cm push back changes the acceptance. If the acceptance in general were so much in MRS Peter or/and Eun-Joo would definitely have found it before so our wondering is more in the direction if the data and sim were carried out the same way. Just a few thoughts Flemming ------------------------------------------------------ Flemming Videbaek Physics Department Brookhaven National Laboratory tlf: 631-344-4106 fax 631-344-1334 e-mail: videbaek@bnl.gov ----- Original Message ----- From: "Bjorn H Samset" <bjornhs@rcf2.rhic.bnl.gov> To: "BRAHMS Software list" <brahms-dev-l@bnl.gov> Sent: Tuesday, May 20, 2003 9:33 AM Subject: Problems with pp acceptance - possible brag problem? | | Hello dev'ils :-) | | For a while now I've been working on acceptances for the 2001 pp run, and | I've run up against a problem that I'd like some feedback on. It's been | discussed both in Oslo and "nordically", but we're still stuck... | | The problem is that when I do the acceptances I get a y-pt distribution | that looks just like the data, but does't quite hit it - it has an offset | of roughly 0.1 unit of y. Plots can be found here: | http://www.fys.uio.no/~bjornhs/brahms/ppAccProblem/ | along with a few words, but I'll do most of the explaining in this email. | (I'll expand the webpage as neceseary.) | | (A note to Claus: I thought this might be related to your recent, similar | problems, but from looking at your plots I don't think so. I see this | problem for much lower fields than where it apears for you. However, | please read this mail and tell me if I'm wrong ;-) | | First a few words on what's been done: | | * To make the acc. I use the software by Peter, Djamel etc. found in | pc_app/brag/acceptance, with some modifications. They are mainly: | * I've added the TMrf counter and require a hit here since it's part of | the trigger. | * I impose a fiducial cut on the midplane of TPM2 (I guess this was also | done for AuAu, but anyway...) | * Since we also had a slat behind the TOFW that was part of the trigger, | I require that the tracks hit the TOFW between slats 25 and 75, based on | the slat distribution of the data. (Cut imposed both in the data and acc. | files, of course.) | * If I only impose the TMrf and TPM2 cuts, I get an acc. distribution that | is much broader than the data, so the real cut is in the TOFW. | * A word on the vertex used: The inelvertex is too broad to be used for | acceptance calulations. Since we mostly have only one track per event, | I've assumed (after discussions with Flemming) that the track origin is | the vertex. This makes the y-pt distr. for the data nice and sharp. | | Now I can run through an acceptance calculation, and the output is what | you can see on the page above. The best example (highest statistics) is | these pictures: | http://www.fys.uio.no/~bjornhs/brahms/ppAccProblem/overlay_40deg_pos_unscaled.gif | http://www.fys.uio.no/~bjornhs/brahms/ppAccProblem/overlay_40deg_neg_unscaled.gif | (see the webpage for explanations). | | It's clear that if we assume (for now) that the acceptance is correct, the | positive particles lie too high in y (or too low in pt...) and the | negatives lie too low in y. | | There are a lot of factors that could shift both positives and negatives | in the same direction (e.g. an offset in the vertex) but only one that | we've found that shift them different ways - the momentum. So I tried | scaling the momentum of the real data to see how big the error had to be, | and I ended up having to scale them by a whopping 35%! (p = p*1.35) | Pictures after scaling are also on the webpage, and now it seems that the | data and acc. overlap very nicely. Luckily (?) 35% is just so much that it | either can't be the data or we'll see it clearly in the data (wrong | temperatures etc.) | | Of course the first thing to check is if the data really are OK. We would | tend to trust the sims, simply because they were used with success for | AuAu and the changes are so small. However, I made a little test to check | the latter first: I imposed the slat cut in the TOFW on a AuAu dst and | overlaid it with my acceptances from pp, and the problem is the same | there. Ergo (to my mind, at least) this is some problem that is common to | AuAu and pp, so I started thinking more about the sims instead. (The | momentum spectra from pp seem reasonable - you'd think we'd notice if they | were scaled by 35%...) | | I have one hypothesis that may fit, and that I'm trying to check now: | | What if the bending in brag through D5 is wrong? For AuAu the TOFW is | symmetric, and large enough that if a particle comes all the way through | the fiducial cuts in the MRS it will hit a slat. Consequently, if the | bending is off by even 35%, we might not see it when we overlay it with | AuAu data. (Remember that brag takes a momentum and finds a bending, while | we measure a bending and find a momentum.) Such a problem would only | become apparent when we make an asymmetric cut somewhere in the MRS, and | would look like what I see. | | Maybe this is not very likely, but at least it's a consistent theory (I | think). I'm checking this now, but I hope that someone else can give this | some thought and tell me if there's anything we've missed or should be | looking at. | | Well - that's a brief (yar ;-) description of problem, status and | progress. Please ask if anything is unclear - this is beginning to bug me | somewhat ;-) | | See you in Krakow. | | -- | Bjorn H. Samset Phone: 22856465/92051998 | PhD student, heavy ion physics Adr: Schouterrassen 6 | Inst. of Physics, University of Oslo 0573 Oslo | \|/ | ----------------------------> -*- <----------------------------- | /|\ |
This archive was generated by hypermail 2.1.5 : Tue May 20 2003 - 11:21:01 EDT
