[G12] farm local dsks

Wed Apr 13 17:59:03 EDT 2011

We know that trip utility sometimes marks good intervals as bad. 
Particularly when files are short. The original algorithm does not work 
properly. However, information contained in the trip files are 
sufficient to fix them. By fixing I mean not only merging them but also 
fix wrong assignment in the middle of the file.
In your first example it is clear that trip detection failed the second 
interval should have status "0"

As for the second example of merging files in that particular case the 
status should "0" - good interval.
For the second pass we can use only livetime information and event 
number per interval to reassign the trip status.
Diane already has live time distributions for every run. We know where 
to set the cut off on the live time for good intervals. For normal 
production runs it is 0.9. If LT is larger than 0.9 it should be marked 
as trip.
For other runs taken with different current and/or different trigger 
this number will be different.

In the merged trip file we need to to update the first and the last 
physics, event number, interval number in the 1st column as well. If we 
merge entire run, then column 1 always should be the same as column 2.
Update a trip status, column 3. For that we need to recalculate live time.
The rest is irrelevant for gflux.

-Eugene

On 04/13/11 17:39, Johann Goetz wrote:
>  Does tripFixer and sync only need the tagger and scalar banks (just
>  like gflux) If this is so, then it would be trivial to run sync and
>  tripFixer and gflux on the "flux skim" I am making. Does anyone know
>  this?
>
>  On Wed, Apr 13, 2011 at 3:51 PM, Alexander Ostrovidov
>  <ostrov at hadron.physics.fsu.edu
>  <mailto:ostrov at hadron.physics.fsu.edu>> wrote:
>
>
>  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 _______________________________________________ G12 mailing
>  list G12 at jlab.org <mailto:G12 at jlab.org>
>  https://mailman.jlab.org/mailman/listinfo/g12
>
>
>
>
>  -- Johann T. Goetz, PhD. jgoetz at ucla.edu <mailto:jgoetz at ucla.edu>
>  Nefkens Group, UCLA Dept. of Physics & Astronomy Hall-B, Jefferson
>  Lab, Newport News, VA Office: 757-269-5465 (CEBAF Center F-335)
>  Mobile: 757-768-9999
>
>
>
>  _______________________________________________ G12 mailing list
>  G12 at jlab.org https://mailman.jlab.org/mailman/listinfo/g12
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://mailman.jlab.org/pipermail/g12/attachments/20110413/5408c449/attachment-0001.html 