[G12] farm local dsks

[Eugene Pasyuk]

Yes, it is that simple. Just use livetime in combination with number of 
physics events per interval.

sync/trip does not work reliably with short files. Tripfixer either. The 
reason is that they assume no a priory knowledge about contents of the 
file and do some guess work based on some sampling from the beginning of 
the file. When the files were long enough, say several dozens of scaler 
intervals it can guess correctly, but if files has trip at the beginning 
of the file it fails miserably.
It worked ok for g1c, g2a, g3 runs where event rate was low.
for g10 and g11 we already had some problems. People created various 
"tripfixers" which could fix the problem in certain cases but not 
always. g12 had even higher event rate which amplified the problem.

In other words the original hope was that the the program will "teach" 
itself what is god and what is bad. Well, as we see sometimes it does, 
sometimes it does not.

However, even with those broken routines once we have in hands the 
complete pass through the entire data set, information about every 
single file. And that information allows us to forget about the guess 
work and use this information to set the criteria for good and bad 
intervals ourselves.
Sometimes it is not possible to automate everything that would work for 
any data sample. Sometimes we have to use our judgment rather than rely 
on a guess made by the software.

For the PrimEx experiment we used exactly the same procedure. We did not 
use sync/trip first of all because data format was completely different. 
We ran through the entire data set and tracked livetime fro entire data 
set.based on that we determined good/bad intervals.

  -Eugene

Alexander Ostrovidov wrote, On 04/13/11 21:22:
> On Wednesday, April 13, 2011, Eugene Pasyuk wrote:
>> In your first example it is clear that trip detection failed the second
>> interval should have status "0"
>>
>
> Eugene,
>
> I'm getting an impression that if trip detection by sync followed by
> tripFixer can so easily fail on such good looking interval then
> it's even more likely to fail in many other places as well.
>
> Live time peak for this run 57129 is 0.8019 with a sigma of 0.0209
> (Gaussian fit). The interval  I gave has LT of 0.813. It's well within
> LT peak and should survive any  LT cut. Same story for the number
> of events. Yet it was still marked as bad by sync/tripFixer.
>
> This is not an insignificant problem. Run 57129 which I looked carefully at
> contains 768 scaler intervals. Not a small run - about 2 hours of running.
> 251 intervals are marked with status "1". By my eyeball  estimate, about
> 150 of them look perfectly normal in terms of the number of events and
> average live time. If "trip detection failed" in 1/5 of all scaler intervals then
> this should be of some concern, right?
>
> As I understood you, your suggested solution is to ignore interval's beam trip
> status after sync. Don't use tripFixer at all - what the point? Just determine
> LT threshold on per run basis, and use LT cut to correct interval status
> in the trip files for all intervals (not just the ones merged together from
> previously split files). Is this that simple?
>
> Sasha
>
>
>
>
>
> _______________________________________________
> G12 mailing list
> G12 at jlab.org
> https://mailman.jlab.org/mailman/listinfo/g12