Helicity » History » Version 2
Ole Hansen, 01/24/2023 09:17 PM
1 | 1 | Ole Hansen | h1. Helicity Analysis |
---|---|---|---|
2 | |||
3 | R. Michaels rom@jlab.org, last updated September 29, 2008 |
||
4 | |||
5 | With thanks to Ole Hansen, Richard Holmes, Vince Sulkosky, and Rob Feuerbach who contributed to the code. |
||
6 | |||
7 | ---- |
||
8 | |||
9 | 2 | Ole Hansen | In the G0 era, helicity data are produced by the "G0 electronics":http://www.jlab.org/%7Erom/g0helicity.html. This document explains the helicity decoding in the Hall A ROOT/C++ Analyzer ``Podd''. |
10 | 1 | Ole Hansen | |
11 | Starting with Podd version 1.5.0, the helicity code is no longer implemented via the software development kit as in previous releases. However a wrapper class is still used to add the helicity into a beam apparatus via THaBeam: |
||
12 | |||
13 | <pre><code class="cpp"> |
||
14 | THaBeam* B = new THaIdealBeam("B","The Beam Class"); // or any other THaBeam |
||
15 | B->AddDetector( new THaG0Helicity("g0hel.L","Left arm G0 helicity") ); |
||
16 | </code></pre> |
||
17 | |||
18 | The detector will read database keys starting with "@g0hel.L.@", "@g0hel.@", and "" in that order from the database file @db_hel.dat@. For experiments E04-007 and E08-007, here is the helicity database used during Spring 2008 "@db_hel.dat@":http://www.jlab.org/%7Evasulk/helicity/db_hel.dat. Users can find details about the database structure in the comments of this file. |
||
19 | |||
20 | For redundancy, copies of the helicity and MPS signals are sent to a Fastbus ADC on both spectrometers. The ADC signal turns into a logical signal when it's either pedestal or saturated. Hence, a threshold value needs to be set in the database such as "@adchel.threshold = 4000.0@" to distinguish between the two helicity states. The helicity decoding from the ADC is implemented as follows: |
||
21 | |||
22 | <pre><code class="cpp"> |
||
23 | B->AddDetector( new THaADCHelicity("adchel.L","Beam helicity L-arm") ); |
||
24 | </code></pre> |
||
25 | |||
26 | In the Spring of 2008, the helicity and MPS signals were in the following ADC channels of ROC 3, Slot 23 for the Left HRS: |
||
27 | |||
28 | <pre> |
||
29 | Channel Description |
||
30 | ----------------------------- |
||
31 | 48 Helicity (copy 1) |
||
32 | 49 Helicity (copy 2) |
||
33 | 50 MPS Gate |
||
34 | </pre> |
||
35 | |||
36 | For the BigBite/Polarized 3He experiments running in the Fall and Winter 2008, the helicity signals were moved to ROC 4, Slot 21: |
||
37 | |||
38 | <pre> |
||
39 | Channel Description |
||
40 | ----------------------------- |
||
41 | 50 MPS Gate |
||
42 | 52 Helicity (copy 1) |
||
43 | 53 Helicity (copy 2) |
||
44 | </pre> |
||
45 | |||
46 | The final helicity of all @THaHelicityDet@ classes is always in the global variable "helicity" (prefixed by the detector name), such as "@g0hel.L.helicity@" and "@adchel.L.helicity@" for the above examples. |
||
47 | |||
48 | ---- |
||
49 | |||
50 | Prior to Podd version 1.5.0, the code uses Ole's [[SDK]] (software development kit) to provide a modularized plug-in. Specifically, we use a wrapper class which is a ''detector'' that plugs into an apparatus ''beam''. This allows seperate development. The code is standalone in this sense and compiles to a shared-object library @libHaHelicity.so@. This library contains the wrapper class as well as the main class, which at the moment is called @HaHelicity@ (in Spring 2006 it was @GenHelicity@, they are slightly different). If you need the plug-in, you should ask me for an official version. |
||
51 | |||
52 | Here are some lines in the analysis script to implement the helicity: |
||
53 | <pre><code class="cpp"> |
||
54 | // Helicity "detector" for LEDEX (Summer 2006) |
||
55 | gSystem->Load("libHaHelicity.so"); |
||
56 | THaApparatus* a = new THaIdealBeam("Beam", "Ideal beam"); |
||
57 | THaHelicityDet *hleft = new THaHelicityDet("HL","Beam helicity L-arm"); |
||
58 | hleft->SetState (1, 8, -1, 0, 0); // G0 mode; 8 window delay; sign -1; |
||
59 | // left arm; no redund |
||
60 | hleft->SetROC (0, 11, 0, 3, 0, 4); // "Left arm" is ROC 11 |
||
61 | a->AddDetector(hleft); |
||
62 | THaHelicityDet *hright = new THaHelicityDet("HR","Beam helicity R-arm"); |
||
63 | hright->SetState (1, 8, -1, 1, 0); // G0 mode; 8 window delay; sign -1; |
||
64 | // right arm; no redund |
||
65 | hright->SetROC (1, 10, 0, 3, 0, 4); // Right arm is ROC 10 |
||
66 | a->AddDetector(hright); |
||
67 | gHaApps->Add( a ); |
||
68 | </code></pre> |
||
69 | And here is how to show results and some comments on the meaning: |
||
70 | <pre><code class="cpp"> |
||
71 | // helicity on L-arm |
||
72 | T->Draw("Beam.HL.helicity:fEvtHdr.fEvtNum","fEvtHdr.fEvtNum<15000") |
||
73 | // helicity on R-arm |
||
74 | T->Draw("Beam.HR.helicity:fEvtHdr.fEvtNum","fEvtHdr.fEvtNum<15000") |
||
75 | </code></pre> |
||
76 | Note, if triggers are random in time, we expect 1.5% of events to have helicity==0 because the helicity is ``blanked off'' for 500 microsec out of 33 msec. This is normal. Also note, if trigger T9 exists (it is the MPS signal which intiates each helicity sequence) then since all T9 come at the time when gate==0 they will all have helicity==0. Don't panic, this is normal. |