Difference between revisions of "Personal Analysis for Ay"

Latest revision as of 12:05, 21 July 2010

Redundant scalar check between L-arm and R-arm

07/21/2010
Since the helicity signal is 0 sometime, which will lead to about 1.2% lost event, so all the scalars should be from the ungated.
For t3 scalar, check the scalar asymmetry of the ungated and the gated,
it is found that left one is stable and should be used for livetime calculation.

01/22/2010
Check the charge scalar-asymmetry for 2-pass runs
(u1 vs u10, u3 vs u10, u1 vs u3, d1 vs d10, d3 vs d10, d1 vs d3, u10 vs d10)
Here are the plots to show charge scalar asymmetries: L-arm runs     R-arm runs
Summary of charge scalar check for 2-pass runs

Further scalar check for 2-pass runs
(u1 vs T3, u3 vs T3, u10 vs T3, d1 vs T3, d3 vs T3, d10 vs T3, unser vs T3)
Plots to show this further check: L-arm runs     R-arm runs

Issues: charge scalar for run 20980 is inconsistent.

01/15/2010
Scalar check for 2-pass runs
Similar to the scalar check for 3-pass runs, T1 scalar asymmetry is checked from ungated scalar:
(1)Scalar asymmetry between L-arm and R-arm for T1 trigger(extracted from ungated)

Other scalar asymmetries are checked from gated scalar: Extract the scalars (target spin + and -) from gated scalar (++, +-, -+, --).
(2)Scalar asymmetry between L-arm and R-arm for each trigger type (extracted from gated)
        ( 3 plots in each page, listed as ungated, + and - target spin state )

After the scalar check, all the inconsistent 2-pass runs are classified   Table for inconsistent 2-pass runs

01/08/2010
Further scalar check for 3-pass runs
(u1 vs T3, u3 vs T3, u10 vs T3, d1 vs T3, d3 vs T3, d10 vs T3, unser vs T3)
Plots to show this further check: L-arm runs     R-arm runs

Comments: There is a problem of charge scalars for some 3-pass runs (1904 ~ 1959 and 20812 ~ 20879).
                    A reliable scalar (unser?) is needed to calculate the charge for these runs.

12/11/2009
Check the charge scalar-asymmetry for 3-pass runs
(u1 vs u10, u3 vs u10, u1 vs u3, d1 vs d10, d3 vs d10, d1 vs d3, u10 vs d10)
Here are the plots to show charge scalar asymmetries: L-arm runs     R-arm runs
Summary of charge scalar check for 3-pass runs

Based on the best plot (u3 vs u10), Table for inconsistent charge scalar 3-pass runs

12/7/2009
Scalar check for 3-pass runs
Extract the scalars (target spin + and -) from ungated scalar.
(1)Scalar asymmetry between L-arm and R-arm for each trigger type (extracted from ungated)
        ( 3 plots in each page, listed as ungated, + and - target spin state )
However, T3 scalar is drifted; fclk scalar is not good, either.

Extract the scalars (target spin + and -) from gated scalar (++, +-, -+, --).
(2)Scalar asymmetry between L-arm and R-arm for each trigger type (extracted from gated)
        ( 3 plots in each page, listed as ungated, + and - target spin state )
However, T1 scalar is drifted.

Solution: Check the scalar asymmetry using gated scalar except for T1; T1 scalar is checked from ungated scalar.
Issues: There are 16 run pairs in which the scalar asymmetry is inconsistent (> 1e-3 level), to be investigated.

After the scalar check, all the inconsistent 3-pass runs are classified   Table for inconsistent 3-pass runs

11/23/2009
Living with the 5 large scalar-asymmetry runs, check the charge scalar-asymmetry in each run
(u1 vs u10, u3 vs u10, u1 vs u3, d1 vs d10, d3 vs d10, d1 vs d3, u10 vs d10)
Here are the plots to show charge scalar asymmetries: L-arm runs     R-arm runs
Summary of charge scalar check for 1-pass runs

11/16/2009
Extract the scalars (target spin + and -) from ungated scalar.
Plots to show scalar asymmetry between L-arm and R-arm for each trigger type
(3 plots in each page, listed as ungated, + and - target spin state)

From the plots, we can see that the scalar asymmetry, especially for t1 and t3, is consistent at 1e-4 level, except for 5 run paris.
(1590, 20461), (1592, 20463), (1608, 20478), (1611, 20481), (1633, 20506)
In these 5 run pairs, the scalar asymmetry is off by more than 5e-4, even 1e-3.

Possible explanation to these 5 run pairs:
I choose run pair (1633 and 20506) to check this offset. I print out the scalar reading for each entry and I find:
  (1) for clock scalar, we have 1847336 in both L and R, equal to 30.067 minutes, exactly same, in the epics reading from end of run.
       while after replaying these 2 runs, I get 1846420 in L-arm and 1847320 in R-arm.

  (2) some time is lost in L-arm run, which led to a smaller scalar reading. If I choose scalar reading 1846420 in R-arm,
       then I get t1 scalar 30068900, vs 30059300 in L-arm, consistent at 1.5e-4. This means that there are 2600 event entries in R-arm run.

  (3) If I choose another scalar class, "left" and "right", not "evleft" and "evright" used in previous check,
         I get t1 scalar with 30075500 vs 30085500, clock scalar with 1847340 vs 1847340 and fast clock scalar with 187243000 vs 187257000.
       They are consistent at 1e-4 level.
I repeat the procedure above for those last 4 run pairs and get the same result.
As for the 1st run pair, short runs, about 8 minutes. It is only inconsistent on (-) spin, which is about 40s running.

Without those 5 large scalar-asymmetry runs, I check the charge scalar-asymmetry in each run
(u1 vs u10, u3 vs u10, u1 vs u3, d1 vs d10, d3 vs d10, d1 vs d3, u10 vs d10)

11/09/2009
From last week's discussion, (++) scalar for each trigger is shifted due to a possible module problem.
So decide to extract target spin state (+ and -) scalar from ungated scalar.

During the cross-check on target spin state, An issue about database

11/03/2009
This is the first try for 1-pass production runs only.
The trig types include: T1, T3, clock, fast clock, u1, u3, u10, d1, d3, d10, unser.
Here are the plots to show the scalar check.
(7 plots in each page for each trig scalar, listed as ungated,++,+-,-+,--, +, - by Target/Helicity)

After the scalar check, all the runs are classified Run table

Comments: (1) There is always an issue about ++ scalar for each trigger, around 1e-3 level. 

           (2) d1 and d3 scalars were not consistent, not useful to calculate the charge. 

  An examples of issues:   ++ fast clock scalar  left run 1653         right run 20539