[Rgc_analysis] [EXTERNAL] More Target Polarization Info

Tue Jan 31 14:07:38 EST 2023

Hi Sebastian,

I apologize too for not making the meeting. I have a preliminary exam coming up with Duke and I have, for lack of a better phrasing, been tunnel-visioning on it. I also apologize for not getting back to your more recent email. I’ll try to address both here.

Currently, my analysis does not look at the helicity=0 events. From what I remember, they did not make up a significant portion of the helicity readings at all. I know how to read from RAW Scaler from my work a few months ago. What I recall is that the 33ms and 500us windows would occasionally “swap”. This means that while HEL::Scaler is getting constructed in post-processing, the fcupgated for the run is misread, as it will accumulate during the wrong window. From what I remember, newer versions past 8.3.0 were supposed to resolve this issue. I don’t exactly know how that was done, but how I did it was by simply checking the magnitude of the charge for each window, and always taking the larger one (which should always correspond to the 33ms).  What I can do is see if this is still the case, i.e., if the summing in RAW::Scaler for the 33ms window is the same as HEL::Scaler reports.

I’m trying to piece together the plots you show. Each data point must then be a different bank entry for a single run? I find it noteworthy that RUN Scaler is the one which is having trouble, since the spread in HEL Scaler rarely goes out of the typical range. Could you provide more details on how the plot is made? Since RUN::Scaler integrates for you, do you set the bottom bound to be the integration value at the start of the file?

As for Raffaella’s comment about which method is better, I haven’t tried repeating my polarization extractions by using RUN Scaler, so it would be interesting to see what immediate difference that may have on, say, the carbon data. Is RUN::Scaler generated from RAW::Scaler in post? Or is it saved directly to disk during the run?

I will work on producing the Pt plots for the Carbon data set, and get those to you by next week. As a quick question for clarification, what theoretical asymmetry for the carbon target would I use (with the depolarization factor included). I don’t seem to represent a table of them like we had for NH3 and ND3.

Best,
Greg

Sent from Mail<https://urldefense.proofpoint.com/v2/url?u=https-3A__go.microsoft.com_fwlink_-3FLinkId-3D550986&d=DwIF-g&c=CJqEzB1piLOyyvZjb8YUQw&r=aSEBncnFTdfouxOejKajYG--Ygz0DFQolIcHUhF20pw&m=Uw3-GCEhmFsXQaQsTdRjB1ACUPMKRaK36f0teZiWhe3SvN7EUrd0XtL5DLaxSgij&s=phXIfbjtipjX6dRaZSR6HXPQdEYS_fd0GTEipfbfn6o&e= > for Windows

From: Sebastian Kuhn<mailto:kuhn at jlab.org>
Sent: Tuesday, January 31, 2023 1:41 PM
To: Gregory Matousek<mailto:gregory.matousek at duke.edu>
Cc: rgc_analysis at jlab.org<mailto:rgc_analysis at jlab.org>; Anselm Vossen, Ph.D.<mailto:anselm.vossen at duke.edu>; Madhusudhan Pokhrel<mailto:mpokh001 at odu.edu>
Subject: Re: [Rgc_analysis] [EXTERNAL] More Target Polarization Info

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://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_Gregtom3_rgcTargetPolarization_tree_main&d=DwIF-g&c=CJqEzB1piLOyyvZjb8YUQw&r=aSEBncnFTdfouxOejKajYG--Ygz0DFQolIcHUhF20pw&m=Uw3-GCEhmFsXQaQsTdRjB1ACUPMKRaK36f0teZiWhe3SvN7EUrd0XtL5DLaxSgij&s=Ty_NPJRnnOGcvry5TIck6ajRaCCMk6zS9caYqGtltbs&e= <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<https://urldefense.com/v3/__https:/mailman.jlab.org/mailman/listinfo/rgc_analysis__;!!OToaGQ!qwIGeXrvmh4RRwcLAUY8_79OBVNUoAQ_uyKxd_NkDLE6ZYTfNZaz75pQjATt5yt5LFE8yFyH5HRbfAP4LSE$>

<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/54f04d88/attachment-0001.html>