[Rgc_analysis] [EXTERNAL] Re: Cut for FC asymmetry measurement

tforest at jlab.org tforest at jlab.org
Fri Aug 4 03:34:24 EDT 2023


Timothy:

    You now have some evidence that shifts in the target polarization
measurement aren't a FC normalization problem that is coming from
"mislabeling" the RAW::scaler channel number.  The problem of
"mislabeling" was observed in the RAW::scaler bank some time ago.  As
shown in my wiki entry, the channel label changes in the middle of a
data file effectively mislabeling the 500 us and 33 ms time window
measurements of the FC charge.   It appears that a software fix was
implemented so the HEL::scaler bank reports the correct time window. 
There are, however, a series of events over which the scaler is
transitioning between the channel "mislabeling" state (event 2542300 
to 2542530  in my example).  It is unclear, during these events, which
time window is being reported in the HEL::scaler bank.  You may want
to consider keeping the CLK>30000 cut to remove such events in your
physics analysis.

     I observed little impact (typically < 1%) on the FC asymmetry when
applying the cut to remove HEL::scaler events that occur when the
scaler transitions to the channel "mislabeled" state.  Even with such
little impact, I would argue that we should apply the cut to remove
events during times when the scaler is in an unknown state.  We now
rely upon the UNgated clock values of 33330 and 500 to determine the
channel number.  I compared the asymmetry from the "mislabeled"
channel states to those with the expected label.  I found the
asymmetry to be the same suggesting that we could still use those
events when the channel label is "software" corrected.



> Dear Tony,
>
> Thank you for looking into this. I must admit that I’m not entirely sure
> I follow the full line of reasoning (and unfortunately I had to leave
> early on Tuesday). I tried redoing my epX fits with the accumulated
> charges that come straight out of HEL_SCALER and with imposing your
> suggested getFloat("clock",0) > 30000 and, as you allude to, it thankfully
> makes a very very negligible difference. For example, for the PT beam-spin
> asymmetry: a + b sin(phi) for the a values I get (the first value is <PT>,
> the second value is a and the third value is the uncertainty on a):
>
> {{0.123649, 0.000562477, 0.00130613}, {0.275275, -0.000327254,
> 0.000762493}, {0.444372, 0.00003, 0.0007719}, {0.616924, -0.00067699,
> 0.00108001}, {0.833187, -0.00337556, 0.00161188}}
>
> vs
>
> {{0.123649, 0.000563902, 0.00130613}, {0.275275, -0.000325848,
> 0.000762493}, {0.444372, 0.000032, 0.0007719}, {0.616924, -0.000675556,
> 0.00108001}, {0.833187, -0.00337414, 0.00161188}}
>
>
>
>
> A similar story for the target-spin asymmetry:
>
>
> I observed a similar negligible effect on the extraction of dilution
> factors.
>
> Best regards,
> Timothy
>
>
> On Aug 1, 2023, at 9:43 AM, tforest--- via Rgc_analysis
> <rgc_analysis at jlab.org<mailto:rgc_analysis at jlab.org>> wrote:
>
> *Message sent from a system outside of UConn.*
>
>
> Fellow collaborators:
>
> Base on today's discussion, I would suggest changing the line in
> FCcup_reading.cc<https://urldefense.proofpoint.com/v2/url?u=http-3A__fccup-5Freading.cc_&d=DwIGaQ&c=CJqEzB1piLOyyvZjb8YUQw&r=L5A-yGwJ9K-baCY_qQQ2GF5HgMof8bDLK5HeSeLyAlM&m=F3z7de5v4Qvx8t-W5byODzJHv87xBdWzgm1jeOZoIY-pg2Zlb_Lff-l7XotpRMj7&s=zbLvhnHJ3B9rbnR_3e_Ld-lQiYR9U1MLUqNSzfXcg-c&e=
> > from
>
> if(HEL_SCALER.getRows()>0)
>
> to be
>
> if(HEL_SCALER.getRows()>0 && HEL_SCALER.getFloat("clock",0) > 30000)
>
> It should help ensure reliable results.  Only one run, 16535, had a
> relative changed of more than 1% with the suggested cut above.
>
> Tony
>
> _______________________________________________
> Rgc_analysis mailing list
> Rgc_analysis at jlab.org<mailto:Rgc_analysis at jlab.org>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__nam10.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fmailman.jlab.org-252Fmailman-252Flistinfo-252Frgc-5Fanalysis-26data-3D05-257C01-257Ctimothy.hayward-2540uconn.edu-257C5f3e0a48c8304b97656908db9295450c-257C17f1a87e2a254eaab9df9d439034b080-257C0-257C0-257C638264942035825953-257CUnknown-257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0-253D-257C3000-257C-257C-257C-26sdata-3DhB4ahYyGZpnwT8GLEpoG7-252ByyteCH8cBwWih556r2bMs-253D-26reserved-3D0&d=DwIGaQ&c=CJqEzB1piLOyyvZjb8YUQw&r=L5A-yGwJ9K-baCY_qQQ2GF5HgMof8bDLK5HeSeLyAlM&m=F3z7de5v4Qvx8t-W5byODzJHv87xBdWzgm1jeOZoIY-pg2Zlb_Lff-l7XotpRMj7&s=WTzqgIBeJ8D74uL022hnuURo73_UZsdtcR5QyS85QH8&e=
>
>




More information about the Rgc_analysis mailing list