[G12] farm local dsks

[Alexander Ostrovidov]

Hi, Johann and Diane,

Here is an attempt to explain what I was talking about at the meeting today.  I'm worried 
that trip files do not contain enough information to label truncated scaler intervals (at the 
beginning/end of split files) as "good" or "bad" (i.e., beam trip) when they are simply 
merged together without re-running sync/tripFixer on these scaler intervals first. 

Sure, there are obvious cases (when beam is clearly down). However, there are much 
less obvious scaler intervals. For example, look at the following entries from 
/work/clas/clasg12/clasg12/gflux/tripfiles/clas_057129.*.trip

1 374 0 26573389 26652473 79085 10000150 130 126 3882289477 374421317 0.815911
9 125 1  7145395  7224809 79415 10000310 130 126 1392236466 125416013 0.813763

The first interval is marked as "good" (flag 0 in the 3rd column) and  will be counted 
by gflux. The second interval is marked "bad" (flag "1") and will be ignored. The big 
question is: how can one understand what is the  difference between these intervals 
just by looking at their corresponding entries in the trip file? Both are 10sec long 
(7th column). Both have about 79k events (6th column). Both have the same live time 
of 81% (last column). Both have identical times per event 130 126 (columns 8&9). 
Other columns are irrelevant (they are sequential interval/event numbers and absolute 
clock readings). Just from trip file entries alone, I don't see what makes them so
different. But sync did mark them differently nevertheless.

Now, let's say we want to merge 2 split intervals from the end of some file 
(flag -2) and the beginning of the next file (flag -1). 

7  7 -2   604724   657855 53132 6353673  120 120   78568395   7008397 0.791181
0  8 -1   657856   685600 27745 3646000  131 119   82214454   8008433 0.801625
------------------------------------------------------------------------------
x  x  ?   604724   685600 80877 9999673  xxx 124   82214454   8008433 0.794989

In the last line, I tried to merge them together. I summed up number of events 
and time and recalculated live time and time per event. So, what should I put 
in the 3rd column instead of "?" - good or bad? And why? How is the last line 
different from either "good" or "bad" intervals above?

If we want to mark the merged interval as good by hands (numbers do look 
good indeed: 80k events in 10sec, 79% live time) then we have to do the same 
with the "bad" interval shown above (it also looks good in the trip file). Or we 
have to let sync/tripFixer to decide how to label newly-merged scaler intervals 
based on their internal logic about beam fluctuations. I just don't want  a situation 
when some intervals are judged by us and other intervals are judged by sync. 

Another reason we want to rerun at least tripFixer is that we want to group
similar runs (60nA, 65nA, 24nA, major trigger changes). Last time we did all runs 
together and, apparently, tripFixer parameters for 24nA runs were overwhelmed 
by statistics from 60nA runs. I suspect, this is why a percentage of bad intervals 
jumps from ~5% in 60nA runs to ~22% in 24nA. I think it would be safer not to mix 
them together this time.

Sasha