# Personal Analysis for Ay

## 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 **

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

(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