Project

General

Profile

Kaon LT Meetings » mtg_22nov16.txt

Garth Huber, 11/16/2022 01:08 PM

 
1
                 Nov 16/22 PionLT/KaonLT Analysis Meeting Notes
2
                 ----------------------------------------------
3
                           (Notes by GH and SJDK)
4

    
5
                    Today: KaonLT will be discussed first
6

    
7
Please remember to post your slides at:
8
https://redmine.jlab.org/projects/kltexp/wiki/Kaon_LT_Meetings
9

    
10
Present
11
-------
12
Regina - Garth Huber, Stephen Kay, Ali Usman, Alicia Postuma, Nathan Heinrich,
13
   Love Preet
14
CSULA - Konrad Aniol, Johnathan Conrad
15
CUA - Richard Trotta, Tanja Horn
16
JLab - Dave Gaskell
17

    
18
Stephen Updates
19
---------------
20
- RF time correction updates
21
   - the idea is to implement a path length correction similar to how the
22
     coincidence time is corrected
23
        CT-CT_raw +/- (eCorr-hadCorr)-Offset
24
     where
25
        eCorr/hadCorr are the time corrections for path length
26
        Corr=Length/Beta*c
27
        L_HMS=2200+(0.12*xptar*1000)+(0.17*delta)/100
28
        L_SHMS=1810+(0.11*xptar*1000)+(0.0575*delta)/100
29

    
30
   - first tried the method similar to Shuo's
31
        RF=mod_4.008(RF_raw-FPtime+Corr_cent-Corr_delta+Offset)
32
     Shuo applied the correction outside the modulus, which spreads the data
33
     outside the 4.008ns time range.  Stephen applied the correction inside the
34
     modulus, but also checked it outside the modulus to see if any difference
35
     (none).
36
   - this correction did not improve the RF time dists, if anything they
37
     because broader instead of sharper, K/pi separation degraded
38
   - the correction was only about 0.1ns, which is too small to improve things
39

    
40
   - testing two new methods, results shown for method #1
41
     1) add on TOF for path, use delta and calculated beta
42
     2) determine difference between TOF w/golden track beta and calculated
43
        beta and correct for this
44
   - analyzed Q2=3.0, W=2.32, E=6.19GeV
45
   - Looks like new RF time corrections depending upon particle type actually
46
     helps flatten RFTime vs delta correlation
47
   - RF peaks for each particle type are notably sharper, K/pi separation is
48
     improved
49
   - can apply a secondary correction to remove remaining tilt on K_CTime vs
50
     K_RFtime plot, and further improve K/pi separation
51
   - TO DO: add a separate RF offset for each particle type, so they're all
52
     centered at zero
53

    
54
Richard Updates
55
---------------
56
- Luminosity updates
57
   - Started testing the beam current offset
58
      - Clear rate dependence when offset applied, but applied offset was up to
59
        2.5uA, which is an order of magnitude too large
60
      - Mentioned would like to try adding offset in replay itself, due to some
61
        weird issue with how current cuts are applied in the analysis script
62

    
63
- Discussion of beam on/off cut being done by hcana
64
   - DG: need to *remove* this cut!  it removes all flexibility in the hcana
65
     analysis
66
   - BCM offset should be applied directly to the yields, as a ratio between
67
   - old and new Q
68
     Dave method to apply correction:
69
       cor = (Inom+offset)/Inom
70

    
71
- Bill's LT-separation code
72
   - Getting yields, but they don't make sense, some cut in the script, not in
73
     the cut section
74
      - Missed something small? Will check with Bill?
75
   - Checking HeeP data
76
      - Test runs
77
      - Want same yields as Bill
78

    
79
   - once the yields are fixed, each setting will need a separate script
80
      - Some scripts (t_phi as an example) have hardcoded file names
81
      - Will need to edit this
82
      - GH: yes, some script-dependent scripts will be needed, since the
83
        t-binning will be different for each (Q2,W) setting
84
   - TH - *Prioritise* getting the scripts to work and getting to the cross
85
          sections over the efficiency updates and making the code more elegant
86
        - once you have everything working and have done one LT-sep iteration,
87
          then you will have a better idea of what is important to optimize, or
88
          not
89

    
90
- Raster centroid moving in some runs
91
   - DG - Only reason this would change is if beam trajectory is changing
92
      - Should have fixed beam positions
93
      - GH/TH/RT - We did have intentional beam position changes between some
94
         KaonLT beam energies, had to redo carbon hole etc
95
   - DG: in 6 GeV era, we would put beam offset into SIMC to reproduce beam
96
     position in data
97
   - hcana is "smarter" than the old 6 GeV analysis code, tries to correct
98
     delta, etc. for the beam position
99
   - TH/DG: try to find a way to *turn off* this hcana "improvement", since we
100
     don't know exactly what it does.  Better to use old 6 GeV method, which is
101
     robust, and not try to correct beam spot for actual position change
102
   - DG does not know how to turn this off, consult w/MJ
103

    
104
Ali Updates
105
-----------
106
- Trying to apply Peter B's offsets to the Heep data
107
   - Global offset to HMS momentum
108
   - Improves things marginally
109
   - Makes one beam energy worse (this energy already looked OK)
110

    
111
- Peter also applies a vertical angle offset in the HMS
112
   - Assumed vertical angle is theta
113
   - In hcana, which angle is xptar is a bit mixed up
114
   - Found a bug: they are mislabled in hcana
115
      - Offset in "theta" is actually on yptar
116
      - To apply to xptar, need to apply on phi in hcana
117
   - With offset applied, don't actually see any difference
118
     Plots shown: W, Emiss, Pmiss components
119
   - When applied to the wrong variable, it did actually have an impact
120
   - Going to meet with Peter, when he applies these corrections to our data it
121
     works
122

    
123
- GH - hcana/SIMC variable calculations not exactly the same, should correct
124
  this *first* before diving into this?
125
   - Yes, will discuss with Richard and try to implement
126
   - Other groups (e.g. SIDIS) just calculating variables themselves
127
      - Some (e.g. Bircu) only looked at HeeP singles data
128
   - DG suggests RT to talk to Carlos about the SIMC code modifications
129

    
130
- Lumi discrepancies between Tracked & Untracked Yields
131
   - trying to test different combos of tracking parameters, but ifarm jobs not
132
     done yet
133

    
134
- Error propagation for efficiencies
135
   - Still need to go look at this
136
   - Should use poissonian/binomial statistics?
137
      - DG - Binomial more appropriate than Gaussian
138
      - Effs are more like "flipping a coin" situation
139
      - should be applied on most efficiencies
140

    
141
Alicia Updates
142
--------------
143
- Making progress on helicity analysis
144
   - Checking same data Steve Wood was looking at
145
      - Steve had preliminary results, will compare results with his
146
      - Q2=3.0, W=2.32, high epsilon
147

    
148
- Updating analysis scripts
149
   - Processing replays via the farm
150
   - Should have asymmetry plots for these data fairly soon
151

    
152
Vijay Updates (Presented by Garth)
153
----------------------------------
154
- In previous scaler luminosity plots, saw BCM offset related issue at low
155
  current and a slow trend at higher current
156
   - Vijay was taking a look at the ELT trend to fix the higher current
157
   - Some TLTs over 100%, up to 105%
158
   - Richard had most of these resolved?
159
   - ELT taken as ratio of TLT to CPULT
160
      - Due to TLT issue, see some strange outliers
161

    
162
- When Vijay was applying ELT originally, was using 6 GeV method, which is
163
  based on different gate widths for a scaler
164
   - Numbers weren't crazy, but too low
165
   - GH surprised these numbers existed, though that system no longer exists
166
   - RT - Still in the script, but doesn't actually use them
167
   - DG - Eric Pooser had this setup, but had to physically go and plug in the
168
     relevant cable that you want for the scalers
169
      - doesn't know what scaler was plugged in during KaonLT/PionLT runs,
170
        probably ELREAL
171
      - Values still read out, but probably not be useful
172

    
173
   - RT suggests to use CPULT if TLT doesn't make sense
174
      - for scaler analysis, this would mean applying NO correction
175

    
176
Other Updates
177
-------------
178
- Richard has a picture of how the beam positions are calculated from the BPMs
179
   - Will post photo on Redmine
180

    
181
Next Meeting
182
------------
183
Wed Nov 23 @ 8:15 Eastern/7:15 Regina/5:15 Pacific
184
- PionLT will go first
(128-128/413)