[Rgc_analysis] [EXTERNAL] Question about HWP and TPol when cooking

[Sebastian Kuhn]

Hi Gregory,

I am obviously not an expert on how those banks are filled, but for starters, I WOULD expect EXACTLY 50% +Hel and 50% -Hel no matter the status of HWP. Even if the HWP were somehow included in the helicity signal (which I am quite sure it is NOT), the 2 helicity states should have absolutely the same number of events unless we have a charge asymmetry (more beam for one of the 2 states). The pseudo-random generator is meant to ALWAY create helicity PAIRS with oposite sign.

As for the overall sign of the extracted asymmetry: Yes, the definition of N+ and N- requires to take into account the HELICITY bit information, the HWP status (which reverses the helicity sign but is most likely NOT included in it), and the target polarization (not only the NMR polarization sign, but also the Solenoid field direction which at present is negative and flips the NMR polarization sign). After all, N+ is the number of events where the beam electron spins are ANTI-aligned with the target nucleon spins, and N- where they are aligned. (That’s just a matter of convention). At this point, I wouldn’t worry about the overall sign and just adjust by hand the final Pt sign you get to make it whatever we know it to be (or just always positive for plotting).

You probably should NOT reassign individual N+ and N- counts, especially if it could cause confusion with the FC normalization (charge asymmetry). In other words, you must make sure that you divide each of the N’s with the accumulated charge for the SAME recorded helicity bit (no matter what this corresponds to once HWP etc. have been taken into account). I am saying this mostly because I continue to worry that, at least in some cases, the FC normalization seems to make the extract Pt WORSE (more jumpy and, frankly, unbelievably large at the end of your most recent stretch of results). I am also worried that your last 4 data points show exactly the opposite behavior to what Harut sees.

Meanwhile, thanks for sending your results! - Sebastian

On Feb 20, 2023, at 2:41 PM, Gregory Matousek via Rgc_analysis <rgc_analysis at jlab.org<mailto:rgc_analysis at jlab.org>> wrote:

Hello,

I had a question about how helicity is stored in the HEL::online bank of the sidisdvcs trains ( or any hipo file for that matter ). There are several recent NH3 runs which I am analyzing, and I am getting some counterintuitive results for N+ and N- for each run. I am referring to the 8.5.0 HBT cooks.

For example, Run 17577 has HWP in, and NMR Pt > 0. I find from my DIS channel that 51% of events have helicity = +1 , and the remaining 49% have helicity = -1. I would have initially thought that there would be more helicity = -1 events? I was wondering if the cooking had been accounting for the fact that the HWP was in, and was correctly "flipping" the electron's helicity when storing it in the hipo bank.

Next, we look at Run 17589, with HWP out and NMR Pt>0. Here, I counter-intuitvely find 49% of events have helicity = +1 , and now 51% have helicity = -1. Again, I am just reading the entries in HEL::online. This is odd, because since our asymmetry is positive, this would calculate a negative target polarization in the end (N+ < N-)

For Run 17604, with HWP out and NMR Pt <0. We find 50.88% of events with helicity = +1 and 49.12% with helicity = -1. This is backwards from how I thought the asymmetries would work.

Does anybody familiar with the newest coatjava know how the HEL::online bank is formed? Does it read from the CCDB in anyway to adjust the helicity information based on the HWP or Tpol status? At the moment, the solution is for me to swap N+ <--> N- .


Here, then, are the DIS polarizations I am getting for the NH3 runs. It looks like we were near -80% polarization two days ago.

<image.png><image.png>
_______________________________________________
Rgc_analysis mailing list
Rgc_analysis at jlab.org<mailto:Rgc_analysis at jlab.org>
https://mailman.jlab.org/mailman/listinfo/rgc_analysis

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.jlab.org/pipermail/rgc_analysis/attachments/20230220/da940315/attachment-0001.html>