<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Dustin,<br>
<div class="moz-cite-prefix"><br>
For the study of asymmetry changes due to drift in charge
measurement and <br>
detector efficiency, the transversity experience can only be used
for<br>
detectors, not for charge, since the conditions for charge/current
measurement<br>
are completely different (10 uA vs 100 nA). So we need information
from g2p/GEp<br>
to say anything about charge/current.<br>
<br>
For HRS detector drift during transversity , we measured detector
response <br>
(normalized yield for same condition) over long period and see
little change (<1%). <br>
The measurements were usually limited to about 1% precision. <br>
Not worrying about fluctuations (which does not contribute to
overall drift), this <br>
means that for short time (20 minutes period when we did target
spin flip),<br>
the detector drift should be less than 1%*20minte/3 months and
significantly<br>
less than 10^-3. We just took it as 10^-3 to be conservative.The
total contribution to <br>
our false asymmetry is 10^-3/sqrt(N_pairs) < 10^-4 (since we
have more than 100 pairs).<br>
This is also confirmed from checking false asymmetries.<br>
<br>
To translate to our proposal, if we can keep detector response to
be stable <br>
at 1% in 3 months, then in 12 hours, stability should again be
better than 10^-3,<br>
the total contribution to the systematic should be
10^-3/sqrt(N_pair)=3*10^-4 (for 10 pairs).<br>
(Probably not use conservative number, we can reach 1*10^-4).<br>
<br>
For the charge, if we can measure to 1% in 1s, in a typical run of
1 hour, we<br>
should have more than enough statistics for 10^3. Need to check
stability from<br>
data (g2p/GEP) to see if data stays at that level of stability and
also to check at <br>
12 hours time scale. If it stays at 10^-3, then we have the same <br>
systematic uncertainty of 3*10-4. If it is better, then we can do
better.<br>
<br>
I believe reaching the combined uncertainty (both charge and
detector) of 3*10-4 is <br>
reasonable. But better to have data to support it<br>
<br>
Cheers.<br>
<br>
Jian-ping<br>
<br>
<br>
<br>
On 5/5/2013 3:03 AM, Dustin Keller wrote:<br>
</div>
<blockquote
cite="mid:Pine.LNX.4.64.1305050301340.30622@ifarm1101.jlab.org"
type="cite">here is what i was thinking, let me know if we want to
add something
<br>
like this and we can clean it up a bit and add some details.
<br>
<br>
dustin
<br>
<br>
On Sun, 5 May 2013, Karl Slifer wrote:
<br>
<br>
<blockquote type="cite">Hi Oscar,
<br>
<br>
I modified this eq as you suggested to show the explicit
dependence on Q
<br>
and e.
<br>
<br>
-Karl
<br>
<br>
<br>
[image: Inline image 3]
<br>
<br>
---
<br>
Karl J. Slifer
<br>
Assistant Professor
<br>
University of New Hampshire
<br>
Telephone : 603-722-0695
<br>
<br>
<br>
On Fri, May 3, 2013 at 9:38 PM, Oscar Rondon-Aramayo <
<br>
<a class="moz-txt-link-abbreviated" href="mailto:or@cms.mail.virginia.edu">or@cms.mail.virginia.edu</a>> wrote:
<br>
<br>
<blockquote type="cite">Hi,
<br>
<br>
To further remove any confusion about our method and its
errors, I suggest
<br>
that instead of writing eq. (19) in terms of charge
normalized, efficiency
<br>
corrected counts, we display the charges and efficiencies
explicitly, and
<br>
use raw counts. Although we stated the kind of counts we are
using in that
<br>
eq. just above it, it seems Steve missed it.
<br>
<br>
Per eqs. (32) and (33) in the appendix 2.2.3, this means just
moving Q's
<br>
and
<br>
epsilons to the l.h.sides, since N1 and N are indeed raw
counts there, and
<br>
don't make any approximations, like Q1 ~ Q, etc.
<br>
<br>
Then, the l.h.s. of eq. (34) would be
<br>
<br>
(Q/Q1)*(e/e1)*(N1/N) and
<br>
<br>
eq. (19) becomes
<br>
<br>
Azz = 2/(f*Pzz)*[(Q/Q1)*(e/e1)*(N1/N) - 1]
<br>
<br>
where it's evident that Q's and e's are normalizations or
scale factors,
<br>
just like f and Pzz, and change the text above the equation to
say raw
<br>
counts, not normalized and corrected ones.
<br>
<br>
I don't see any other way to make it any clearer.
<br>
<br>
And, of course, we need to emphasize somewhere that the
statistical error
<br>
is
<br>
always based on the RAW counts.
<br>
<br>
Cheers,
<br>
<br>
Oscar
<br>
<br>
<br>
<br>
On Fri, 3 May 2013 17:43:55 -0400
<br>
Karl Slifer <a class="moz-txt-link-rfc2396E" href="mailto:karl.slifer@unh.edu"><karl.slifer@unh.edu></a> wrote:
<br>
<blockquote type="cite">Hi all,
<br>
<br>
I got a ton of comments, and I think I've implemented them
all. I think
<br>
the most substantial pertain to the following: (equation
numbers refer to
<br>
the attached draft)
<br>
<br>
Eq 17 and 19: Azz expressed as ratio - 1 as suggested by
Oscar
<br>
<br>
Eq 22 : Total time expressed in terms of R_T as noted by
Patricia and
<br>
concurred by Ellie and Oscar.
<br>
<br>
Page 23 Charge determination systematic : modified to
reflect Oscar and
<br>
JP's suggestions
<br>
<br>
There were a lot more, so please double check that your
suggestions have
<br>
been satisfactorily included.
<br>
<br>
The overhead and target sections are still in progress.
Anyone have time
<br>
to help with that?
<br>
<br>
thanks,
<br>
<br>
Karl
<br>
<br>
<br>
---
<br>
Karl J. Slifer
<br>
Assistant Professor
<br>
University of New Hampshire
<br>
Telephone : 603-722-0695
<br>
</blockquote>
<br>
_______________________________________________
<br>
b1_ana mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:b1_ana@jlab.org">b1_ana@jlab.org</a>
<br>
<a class="moz-txt-link-freetext" href="https://mailman.jlab.org/mailman/listinfo/b1_ana">https://mailman.jlab.org/mailman/listinfo/b1_ana</a>
<br>
<br>
</blockquote>
<br>
</blockquote>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
b1_ana mailing list
<a class="moz-txt-link-abbreviated" href="mailto:b1_ana@jlab.org">b1_ana@jlab.org</a>
<a class="moz-txt-link-freetext" href="https://mailman.jlab.org/mailman/listinfo/b1_ana">https://mailman.jlab.org/mailman/listinfo/b1_ana</a></pre>
</blockquote>
<br>
</body>
</html>