Time: 12:30-1:30 Toll-Free Number (U.S.& Canada): 888-240-2560 PARTICIPANT CODE: #543 006 042 Room IRL: <none> https://bluejeans.com/543006042
Please post slides in haplog or docdb, before the meeting
- Devi: HAMC vs prex-2 data comparison HAPLOG:4255
Notes by Bob M. 14:00 Friday Sept 25, 2020. Hopefully everyone will post there slides. A picture is worth a thousand words !
Showed tg_th vs tg_ph for data, which was over-fitting near the edge of the acceptance, creating tails. He corrected this by removing some parameters and lowering the order of the tensor. This made the 2D plot look better but it slightly increased the chisquare for some sieve holes on the border. Discussion with Nilanga on things to try next. It's looking a lot better already, though.
Has been using hamc to check g4hrs. The hamc acceptance is too broad when we use the PREX-2 collimator, but this is likely because of a wrong Z location. We're working on finding the correct Z location and checking versus various sources of information. Meanwhile, Devi tried an "empirical angle" collimator, which uses a polygon in "angle space" of tg_th vs tg_ph and demands that hamc tracks are inside that polygon. This essentially forces hamc to look like data. Doing this he gets a reasonable agreement to data (momentum, angles, etc) and a reasonable agreement between the hamc vs g4hrs acceptance function. What "reasonable" means is that the shift in the cross-section-weight asymmetry across the acceptance, when comparing the 2 MC results, is about 1.6%, which is sort of ok at this stage but not good enough yet. It's a work in progress.
Wants to see how sensitive the acceptance function will be to location of the cut defining "in the detector" and seeing how the average asymmetry changes. He has developed some software and is close to providing some results.
Continues to make comparisons of g4hrs distributions in the focal plane versus data for X, Y, tan(theta), and tan(phi). Some of the variables look great, some others are not matching in width and/or shifted. This might be because we don't know either the origin or the Z location of the plane to which she extrapolates, or both. We worry about this because the (X,Y) cut of the detector location will need to be used in g4hrs to define what it means to be "in the detector". She is working on finding out coordinate origin and distances to the detector plane. These should be known, somewhere. I'm thinking we may end up living with small arbitrary shifts, and correcting for those, but the wrong magnification may be due to evolving the track bundle to a slightly wrong Z.