Sept 8/22 PionLT/KaonLT Analysis Meeting Notes ---------------------------------------------- (Notes by GH and SJDK) Please remember to post your slides at: https://redmine.jlab.org/projects/kltexp/wiki/Kaon_LT_Meetings Present: Regina - Stephen Kay, Garth Huber, Vijay Kumar, Muhammad Junaid, Alicia Postuma, Jacob Murphy, Ali Usman, Love Preet CUA - Richard Trotta, Tanja Horn Ohio - Jacob Murphy CSULA - Konrad Aniol Richard Updates --------------- - Lumi 10.6GeV Analysis - PID cuts updated - Scaler, Without, and with tracking cuts - Statistical uncertainties now too (but not yet including statistical from efficiencies) - Normalized yield results vs. Current for HMS-Carbon - Blue: total LT, red: CPULT - Scaler vs Event (no tracking) vs Event (tracking) - Large discrepancy between the two, with the CPULT results being MUCH better - SHMS-Carbon analysis shows "reverse boiling" of 14% @ 70uA - SHMS sees a trend even with poor TLT runs removed - Some Lumi runs are not great - <90 seconds of "good" beam on time after current cuts - Bi-modal distribution of current within some runs - GH note afterward: Yes, the 10.6GeV beam current was extremely unstable. The 8,6GeV lumi scans should be much better! - some CPULT as low as 75%, possible due to excessive EDTM rates for some low current settings. EDTM should have smaller effect in high current runs, where PS is set high - Jacob asks about CPULT eqn used. Does it include Carlos' Poisson correction discussed in his thesis? - It sounds like the answer is No, but Richard should double-check - See large inverse boiling trend with scalers in some scans which goes away in untracked and tracked analysis - Bad scaler yields correspond with CPULT drops - This is *very* worrisome, as the scaler analysis should be insensitive to deadtime effects. *Definitely* needs more investigation! - Next up: - Offsets - Lumi analysis, cut iterations - HeeP/Lumi uncertainties - Bill's code - HeeP Singels efficiencies issues - Calorimeter Calibrations - HGC efficiency calculation - Vijay: TLT vs CPULT, which should be used? - Dave G recommended CPULT previously - Generally fairly consistent between the two - Garth: EDTM system between KaonLT/PionLT, major difference between the two experiments. This will be one of the causes of larger systematic error in KaonLT compared to PionLT - EDTM system updates were only ready for 2021 run, low Q2 PionLT (summer 2019) still had the old verion? - As a result, the uncertainty in TLT might be too big to use in some parts of KaonLT, and we would have to use CPULT with a correction to account for Electronic DT - FADC reference timing and CoinTime changes were done during the early parts of KaonLT, as deficiencies in the SHMS+HMS commissioning setup were identified - CoinTIme change was after the 10.6 GeV, but before the 3.9 GeV and 4.8 GeV - CT changes - Leading edge vs falling edge - Inverted signal - DaveG indicates (afterward) that this was error introduced summer 2018, were ALL reference time signals were inverted. The main effect of this was crappy CoinTime resolution, as its more sensitive to jitter in signal timing - Hodoscope timing changes - Mark changed how the different hodoscope planes define the FADC reference time - intial timing had each plane with a different time, with S1X last, leading to multiple peaks - later, after more understanding, the timing was changed so that most events are in a single peak - DaveG thinks this occurred before J/Psi run in early 2019 - All S1X were were synchronized by Simona at some point, to reduce timing jitter between different paddles - this allowed the S1X, S1Y timing windows to be narrowed, which then helped reduce Electronic DeadTime (significant impact in some cases) - DaveG thinks this was done in summer 2018, before KaonLT - Someone should identify exactly when these confiugration changes occured - Ali will check, it would be helpful for Vijay to assist, since neither were present at the beginning of KaonLT data taking - Stephen skimmed the logbooks, some potential entries to look at (to begin with) - https://logbooks.jlab.org/entry/3629548 - https://logbooks.jlab.org/entry/3630734 - https://logbooks.jlab.org/entry/3630346 - https://logbooks.jlab.org/entry/3614446 - https://logbooks.jlab.org/entry/3614481 - https://logbooks.jlab.org/entry/3626160 - https://logbooks.jlab.org/entry/3626194 - Could add issues to wiki once found? - There are status pages for KaonLT, Summer 2019 PionLT - Add information to this Ali Updates ----------- - High Q2 HeePCoin analysis - Ali/Richard looking at 6.2/8.2/10.6 GeV HeePCoin settings - Summarizes the Emiss/Pmiss distribution issues discussed last week - Debug Test #5 - Stephen redid tests 1-4, discovered that files in high Q2 comparison test were different, confirmed that the problem is in hcana, not python script analysis - problem was a wrong gbeam.param file, which was for polarized 3He target data taking, where there is a large solenoidal field at the target - now have much narrower EM/PM peaks, which will allow the offsets to finally be determined from these data - Need consistent set of offsets - Momentum offset changes if the magnets saturate - Magnet settings for each beam energy - 10p6: p_h = -6.590, p_p = +4.484 - 8p2: p_h = -4.672, p_p = +4.371 - 6p2: p_h = -3.571, p_p = +3.486 - 4p9: p_h = -3.124, p_p = +2.583 - 3p8: p_h = -2.026, p_p = +2.583 - What is the correct gbeam.param file? - issue is that there are multiple versions of some variables in Vijay's version of the 2018 file - need to confirm that used file for KaonLT is correct - Dave G seemed to imply (offline) that this is the one should use: - https://github.com/JeffersonLab/hallc_replay_lt/blob/LTSep_Analysis_2022/PARAM/GEN/KaonLT_PARAM/gbeam_fall18.param - Implied we should use a different file altogether for Summer2019 - possibly we need to generate a new one for PionLT 2021-22, from harp scan data - Emiss vs delta(HMS,SHMS) plots have a tilt (8.2 GeV setting) - Happened for all settings except 10.6 GeV - Should also add plot of HMS vs SHMS delta - Tanja mentions we saw the effect of raster offset causing a MM vs delta correlation in Fpi2 - error in raster correction causes an offset in vertical angle at target - strong correlation of angle vs momentum in Heep-Coin makes the effect visible in Heep MM vs delta - the error would be present also in the pi/K data, but the effect would be mostly in worse MM reconstruction resolution, not seen as a clear correlation, as this would be disguised by the 3-body (rather than 2-body) kinematics - How do we apply correct raster offsets? - In gbeam.param, beam on target positions are commented out? - Do these actually adjust anything? Should we set them to our nominal values? - Check and follow up with Dave G - Efficiencies file - Run by run efficiency, propagated error should be statistical uncertainties that are added in quadrature to statistical uncertainty of data Vijay Updates - Working on Lumi studies, no updates Junaid/Nathan Updates - No updates, comprehensive preparation Jacob Updates - No big updates - Lumi scripts + calibrations Stephen - Some discussion on topics to be discussed in October Hall C Analysis Meeting - meeting is planned to be ~2 hours long - 6 to 8 talks in total (GH thinks this might be too many) - Richard Lumi scan and Livetimes - Jacob EDTM and Prescale studies - Ali/Vijay gbeam.param Next Meeting: - Wed Sept 21 at 06:00 Pacific/07:00 SK/09:00 Eastern