[Rgc_analysis] [EXTERNAL] More Target Polarization Info

[Sebastian Kuhn]

Hi Gregory,

sorry you couldn’t join today’s RG-C analysis meeting. I presented some of the same stuff (yours and Madhu’s) which started a more lengthy discussion on Faraday cup normalization. One statement that was made by Raffaella said that adding up all the individual FC counts from HEL::scaler may not be the most precise thing to do, since occasionally a HEL::scaler readout can be mistimed. So she recommends to use the RUN::scalar (automatic sum) DAQ-gated FC for normalization (I wasn’t sure whether that is what you are doing).

Meanwhile, she also suggested a test to see if normalizing to FC as we (you) do for your Pt analysis actually improves things or makes the false asymmetry worse (which, by eye, it sometimes seems to do - at least asymmetries seem to jump around more WITH normalization than without). The way to do this is to pick a (or a few) recently cooked 12C run(s) (from October 2022, e.g.) that we KNOW can’t have any REAL asymmetry. Then repeat your analysis as IF it was an ND3 target (you can use the same dilution factor, or set it to 1). Compare the Count-rate asymmetry-based extracted Pt with what you would get if you were to first normalize the counts for either helicity by
1) RUN::scalar gated FC
2) RUN::scalar gated clock
3) HEL::scalar summed-up gated FC
(4 IF you have the stamina: HEL::scalar gated clock multiplied with EPICS::scalar current in 2C21)
5) Simply normalize by the number of FC TRIGGERS (trigger bit 39) for each helicity, as we do for the online, real-time asymmetry measurement.

Hopefully not too much of an “ask”. Let me know if you have any questions.
Greetings - Sebastian

On Jan 27, 2023, at 11:31 AM, Sebastian Kuhn <kuhn at jlab.org<mailto:kuhn at jlab.org>> wrote:

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

<PastedGraphic-2.tiff><PastedGraphic-3.tiff><Documentation-Beamcharge-calculation.pdf>

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