[Rgc_analysis] [EXTERNAL] More Target Polarization Info

[Sebastian Kuhn]

Hi Greg,

I finally managed to read your slides and reminded myself again how things work in general.
Here is one specific question: If I interpret the script “ProcessInclusive.C” correctly, you just use the helicity scaler bank information to sum up the life-time gated FC for both individual helicities. You seem to be distinguishing 3 cases: Hel = +1, 0, -1. What is the interpretation for Hel = 0? What do you ultimately do with that information? (It might be useful to see which fraction of HEL::SCALER events contain Hel = 0). Also, what is the relationship between the “true helicity events” and the 300 µs “settle time” events that caused all the issues earlier? Are we 100% sure that this problem is now solved, i.e., all Helicity assignments are really for good 30 ms buckets? Is there a way to double-check that, e.g., using the clock scaler?

As you know, I am concerned that, at least in some cases, normalizing the measured asymmetry to the FC actually makes it MORE ragged, instead of smoothing it out. One other piece of information that might be relevant here is that, for RG-F, one of our students (Madhusudan Pokhrel, cc'd) did a detailed study of the various ways of extracting FC integrated charges from the data. Here is one of his findings:
It shows on the horizontal axis the integrated (gated) charge from the FC from adding up all HEL::scaler events over a file, while on the vertical is the same thing using the value from RUN::scaler (which does the integration for you). Obviously, there is a diagonal line, but there is also a lot of scatter around it, some quite drastically. So I am wondering whether there are additional issues that we need to figure out before we have a reliable measurement of integrated charge! (This goes of course beyond RG-C and even RG-F). And, we should not forget, that we also had some issues with the FC calibration over the course of RG-C, as well.

During RG-F, we had an even worse hiccup where all FC information in BOTH HEL::scaler AND RUN::scaler simply disappeared for a stretch of runs! We tried to circumvent this by using instead the gated clock from the HEL::scaler, multiplying it with the beam current at 2C21 from the RAW::epics bank. (See complete explanation attached - Madhu can comment). Surprisingly, this led to a BETTER agreement with RUN::SCALER than the plot above:
Although there are of course still outliers (probably when the beam dropped off during a time when EPICS::raw scaler wasn’t recording it). I know you already put a lot of effort into these, but since the clock is ALSO labeled by helicity, you could try this, as well, although I’m afraid the EPICS::raw scaler is read too infrequently to get a helicity-dependent beam current out of it…

- Sebastian


On Jan 17, 2023, at 10:34 AM, Gregory Matousek via Rgc_analysis <rgc_analysis at jlab.org<mailto:rgc_analysis at jlab.org>> wrote:

In the event anybody would like to look into how the target polarization are generated, I cleaned up much of my code into a repository containing all I need for the analysis.

https://github.com/Gregtom3/rgcTargetPolarization/tree/main<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_Gregtom3_rgcTargetPolarization_tree_main&d=DwMFAw&c=CJqEzB1piLOyyvZjb8YUQw&r=aSEBncnFTdfouxOejKajYG--Ygz0DFQolIcHUhF20pw&m=hYYnBYUiT4BHE2lUhmdjxTnkArRQCMfZISJy6qYnIU1c0AdJccW3qHsvM0xX-5--&s=s_hZR1cUtGqOTCZ9iy4P2qEnfsvAiyJOCuxffDNtEjQ&e=>

The program for reading the sidisdvcs trains into TTrees with FCup accumulation included isProcessInclusive.C. This includes any bare cuts I make on the event selection, as well as how I pull and save the FCup charges.

The README should be helpful in explaining how the repository is to be used. What is important is that the user needs to use Jupyter Notebook to actually generate the plots.

Please let me know if you have any questions on usage or how it works!

Best,
Gregory
_______________________________________________
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/20230127/c8ae09bb/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-2.tiff
Type: image/tiff
Size: 112160 bytes
Desc: PastedGraphic-2.tiff
URL: <https://mailman.jlab.org/pipermail/rgc_analysis/attachments/20230127/c8ae09bb/attachment-0002.tiff>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-3.tiff
Type: image/tiff
Size: 54150 bytes
Desc: PastedGraphic-3.tiff
URL: <https://mailman.jlab.org/pipermail/rgc_analysis/attachments/20230127/c8ae09bb/attachment-0003.tiff>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Documentation-Beamcharge-calculation.pdf
Type: application/pdf
Size: 1715945 bytes
Desc: Documentation-Beamcharge-calculation.pdf
URL: <https://mailman.jlab.org/pipermail/rgc_analysis/attachments/20230127/c8ae09bb/attachment-0001.pdf>