Kaon_LT Experiment

                 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