Nov 16/22 PionLT/KaonLT Analysis Meeting Notes ---------------------------------------------- (Notes by GH and SJDK) Today: KaonLT will be discussed first Please remember to post your slides at: https://redmine.jlab.org/projects/kltexp/wiki/Kaon_LT_Meetings Present ------- Regina - Garth Huber, Stephen Kay, Ali Usman, Alicia Postuma, Nathan Heinrich, Love Preet CSULA - Konrad Aniol, Johnathan Conrad CUA - Richard Trotta, Tanja Horn JLab - Dave Gaskell Stephen Updates --------------- - RF time correction updates - the idea is to implement a path length correction similar to how the coincidence time is corrected CT-CT_raw +/- (eCorr-hadCorr)-Offset where eCorr/hadCorr are the time corrections for path length Corr=Length/Beta*c L_HMS=2200+(0.12*xptar*1000)+(0.17*delta)/100 L_SHMS=1810+(0.11*xptar*1000)+(0.0575*delta)/100 - first tried the method similar to Shuo's RF=mod_4.008(RF_raw-FPtime+Corr_cent-Corr_delta+Offset) Shuo applied the correction outside the modulus, which spreads the data outside the 4.008ns time range. Stephen applied the correction inside the modulus, but also checked it outside the modulus to see if any difference (none). - this correction did not improve the RF time dists, if anything they because broader instead of sharper, K/pi separation degraded - the correction was only about 0.1ns, which is too small to improve things - testing two new methods, results shown for method #1 1) add on TOF for path, use delta and calculated beta 2) determine difference between TOF w/golden track beta and calculated beta and correct for this - analyzed Q2=3.0, W=2.32, E=6.19GeV - Looks like new RF time corrections depending upon particle type actually helps flatten RFTime vs delta correlation - RF peaks for each particle type are notably sharper, K/pi separation is improved - can apply a secondary correction to remove remaining tilt on K_CTime vs K_RFtime plot, and further improve K/pi separation - TO DO: add a separate RF offset for each particle type, so they're all centered at zero Richard Updates --------------- - Luminosity updates - Started testing the beam current offset - Clear rate dependence when offset applied, but applied offset was up to 2.5uA, which is an order of magnitude too large - Mentioned would like to try adding offset in replay itself, due to some weird issue with how current cuts are applied in the analysis script - Discussion of beam on/off cut being done by hcana - DG: need to *remove* this cut! it removes all flexibility in the hcana analysis - BCM offset should be applied directly to the yields, as a ratio between - old and new Q Dave method to apply correction: cor = (Inom+offset)/Inom - Bill's LT-separation code - Getting yields, but they don't make sense, some cut in the script, not in the cut section - Missed something small? Will check with Bill? - Checking HeeP data - Test runs - Want same yields as Bill - once the yields are fixed, each setting will need a separate script - Some scripts (t_phi as an example) have hardcoded file names - Will need to edit this - GH: yes, some script-dependent scripts will be needed, since the t-binning will be different for each (Q2,W) setting - TH - *Prioritise* getting the scripts to work and getting to the cross sections over the efficiency updates and making the code more elegant - once you have everything working and have done one LT-sep iteration, then you will have a better idea of what is important to optimize, or not - Raster centroid moving in some runs - DG - Only reason this would change is if beam trajectory is changing - Should have fixed beam positions - GH/TH/RT - We did have intentional beam position changes between some KaonLT beam energies, had to redo carbon hole etc - DG: in 6 GeV era, we would put beam offset into SIMC to reproduce beam position in data - hcana is "smarter" than the old 6 GeV analysis code, tries to correct delta, etc. for the beam position - TH/DG: try to find a way to *turn off* this hcana "improvement", since we don't know exactly what it does. Better to use old 6 GeV method, which is robust, and not try to correct beam spot for actual position change - DG does not know how to turn this off, consult w/MJ Ali Updates ----------- - Trying to apply Peter B's offsets to the Heep data - Global offset to HMS momentum - Improves things marginally - Makes one beam energy worse (this energy already looked OK) - Peter also applies a vertical angle offset in the HMS - Assumed vertical angle is theta - In hcana, which angle is xptar is a bit mixed up - Found a bug: they are mislabled in hcana - Offset in "theta" is actually on yptar - To apply to xptar, need to apply on phi in hcana - With offset applied, don't actually see any difference Plots shown: W, Emiss, Pmiss components - When applied to the wrong variable, it did actually have an impact - Going to meet with Peter, when he applies these corrections to our data it works - GH - hcana/SIMC variable calculations not exactly the same, should correct this *first* before diving into this? - Yes, will discuss with Richard and try to implement - Other groups (e.g. SIDIS) just calculating variables themselves - Some (e.g. Bircu) only looked at HeeP singles data - DG suggests RT to talk to Carlos about the SIMC code modifications - Lumi discrepancies between Tracked & Untracked Yields - trying to test different combos of tracking parameters, but ifarm jobs not done yet - Error propagation for efficiencies - Still need to go look at this - Should use poissonian/binomial statistics? - DG - Binomial more appropriate than Gaussian - Effs are more like "flipping a coin" situation - should be applied on most efficiencies Alicia Updates -------------- - Making progress on helicity analysis - Checking same data Steve Wood was looking at - Steve had preliminary results, will compare results with his - Q2=3.0, W=2.32, high epsilon - Updating analysis scripts - Processing replays via the farm - Should have asymmetry plots for these data fairly soon Vijay Updates (Presented by Garth) ---------------------------------- - In previous scaler luminosity plots, saw BCM offset related issue at low current and a slow trend at higher current - Vijay was taking a look at the ELT trend to fix the higher current - Some TLTs over 100%, up to 105% - Richard had most of these resolved? - ELT taken as ratio of TLT to CPULT - Due to TLT issue, see some strange outliers - When Vijay was applying ELT originally, was using 6 GeV method, which is based on different gate widths for a scaler - Numbers weren't crazy, but too low - GH surprised these numbers existed, though that system no longer exists - RT - Still in the script, but doesn't actually use them - DG - Eric Pooser had this setup, but had to physically go and plug in the relevant cable that you want for the scalers - doesn't know what scaler was plugged in during KaonLT/PionLT runs, probably ELREAL - Values still read out, but probably not be useful - RT suggests to use CPULT if TLT doesn't make sense - for scaler analysis, this would mean applying NO correction Other Updates ------------- - Richard has a picture of how the beam positions are calculated from the BPMs - Will post photo on Redmine Next Meeting ------------ Wed Nov 23 @ 8:15 Eastern/7:15 Regina/5:15 Pacific - PionLT will go first