Helicity Analysis

R. Michaels , last updated September 29, 2008

With thanks to Ole Hansen, Richard Holmes, Vince Sulkosky, and Rob Feuerbach who contributed to the code.

In the G0 era, helicity data are produced by the G0 electronics. This document explains the helicity decoding in the Hall A ROOT/C++ Analyzer ``Podd''.

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:

THaBeam* B = new THaIdealBeam("B","The Beam Class"); // or any other THaBeam 
B->AddDetector( new THaG0Helicity("g0hel.L","Left arm G0 helicity") ); 

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. Users can find details about the database structure in the comments of this file.

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:

B->AddDetector( new THaADCHelicity("adchel.L","Beam helicity L-arm") );

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:

Channel       Description
48          Helicity (copy 1)
49          Helicity (copy 2)
50          MPS Gate

For the BigBite/Polarized 3He experiments running in the Fall and Winter 2008, the helicity signals were moved to ROC 4, Slot 21:

Channel       Description
50          MPS Gate
52          Helicity (copy 1)
53          Helicity (copy 2)

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.

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 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.

Here are some lines in the analysis script to implement the helicity:

  // Helicity "detector" for LEDEX (Summer 2006)
   THaApparatus* a = new THaIdealBeam("Beam", "Ideal beam");
   THaHelicityDet *hleft = new THaHelicityDet("HL","Beam helicity L-arm");
   hleft->SetState (1, 8, -1, 0, 0);  // G0 mode; 8 window delay; sign -1;
                                      // left arm; no redund
   hleft->SetROC (0, 11, 0, 3, 0, 4); // "Left arm" is ROC 11
   THaHelicityDet *hright = new THaHelicityDet("HR","Beam helicity R-arm");
   hright->SetState (1, 8, -1, 1, 0);  // G0 mode; 8 window delay; sign -1;
                                       // right arm; no redund
   hright->SetROC (1, 10, 0, 3, 0, 4); // Right arm is ROC 10
   gHaApps->Add( a );

And here is how to show results and some comments on the meaning:
// helicity on L-arm
// helicity on R-arm

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.

Updated by Ole Hansen 4 months ago · 2 revisions