[G12] farm local dsks

[Johann Goetz]

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> 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
> https://mailman.jlab.org/mailman/listinfo/g12
>



-- 
Johann T. Goetz, PhD.
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://mailman.jlab.org/pipermail/g12/attachments/20110413/b80e72fc/attachment.html