[G12] farm local dsks

[Alexander Ostrovidov]

On Thursday, April 14, 2011, you wrote:
> Sasha, privet!
> 
> I have a simple question: do we need to use trip detection at all?
> Can you provide normalized to the flux yield (pp-+pi-, or any other
> combination)
> for selected with trip detector events and just for all events. I mean take
> all events with
> flux from the trip,  bad or good.
> Based on these numbers we can judge, do we need it or not. What do you
> think?
> g12 is not PRIMEX, we don't need very good absolute normalization.
> 
> Valery
> 

Valery,

Yes, we can do that. However, I think, we will overestimate beam flux then.
It's hard to say by how much. The problem is that we are not actually counting
all beam photons. We are only sampling them in a small (like 100ns or 
something - don't remember) out-of-time tagger TDC window. Then we are 
making a crucial assumption that we are allowed to scale this 100ns into, say,
8 seconds of live-time during interval (in case of 80% LT). This should work
well if beam was indeed stable during scaler interval. We collect 80k events,
determine probability to have a hit in each tagger counter in the small TDC 
window over those events, and then scale this sampling window to all live time. 
What happens if beam trips after 5 seconds? We would still collect 40k events 
and determine the same probability of a tagger hit in the same TDC window. 
But LT is 9 sec in this case (4sec from the first half, and the full 5 seconds
from the second half of the interval). After rescaling, we'll actually count
9/8 of the flux of a good interval instead of the expected 1/2 of it.

The right way to do this is still the same: count flux only in good intervals AND
filter events with a call to TRIP() function. However, nobody seems to be doing 
the later step even when they are calculating yields. Everybody wants to keep
all collected events. In this case, beam flux is underestimated and cross section 
is overestimated. May be, it is useful indeed as you suggest to run gflux again
in "overestimation" mode to have the floor and the ceiling of flux range for yields
calculations.

Anyway, I still don't see gflux as a culprit in factor of 5 difference in pipi yields
between 24nA and 60nA runs. Initially, I was afraid that, somehow, 80% of
scaler intervals were incorrectly marked as bad in 24nA run, resulting in factor 
of 5 underestimation of flux and overestimation of cross section. As it turned out, 
the problem is present indeed but at about 20% level. Taking into account
that it is also present at 60nA at about 5% scale, this can only explain about
15% difference between 60nA and 24nA yields but not a factor of 5.

Sasha