<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#ffffff">
    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.<br>
    In your first example it is clear that trip detection failed the
    second interval should have status "0" <br>
    <br>
    As for the second example of merging files in that particular case
    the status should "0" - good interval.<br>
    For the second pass we can use only livetime information and event
    number per interval to reassign the trip status.<br>
    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.<br>
    For other runs taken with different current and/or different trigger
    this number will be different.<br>
    <br>
    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. <br>
    Update a trip status, column 3. For that we need to recalculate live
    time. <br>
    The rest is irrelevant for gflux.<br>
    <br>
    -Eugene<br>
    <br>
    On 04/13/11 17:39, Johann Goetz wrote:<br>
    <span style="white-space: pre;">&gt; Does tripFixer and sync only
      need the tagger and scalar banks (just<br>
      &gt; like gflux) If this is so, then it would be trivial to run
      sync and<br>
      &gt; tripFixer and gflux on the "flux skim" I am making. Does
      anyone know<br>
      &gt; this?<br>
      &gt; <br>
      &gt; On Wed, Apr 13, 2011 at 3:51 PM, Alexander Ostrovidov<br>
      &gt; &lt;<a class="moz-txt-link-abbreviated" href="mailto:ostrov@hadron.physics.fsu.edu">ostrov@hadron.physics.fsu.edu</a><br>
      &gt; <a class="moz-txt-link-rfc2396E" href="mailto:ostrov@hadron.physics.fsu.edu">&lt;mailto:ostrov@hadron.physics.fsu.edu&gt;</a>&gt; wrote:<br>
      &gt; <br>
      &gt; <br>
      &gt; Hi, Johann and Diane,<br>
      &gt; <br>
      &gt; Here is an attempt to explain what I was talking about at the
      meeting<br>
      &gt; today. I'm worried that trip files do not contain enough
      information<br>
      &gt; to label truncated scaler intervals (at the beginning/end of
      split<br>
      &gt; files) as "good" or "bad" (i.e., beam trip) when they are
      simply <br>
      &gt; merged together without re-running sync/tripFixer on these
      scaler<br>
      &gt; intervals first.<br>
      &gt; <br>
      &gt; Sure, there are obvious cases (when beam is clearly down).
      However,<br>
      &gt; there are much less obvious scaler intervals. For example,
      look at<br>
      &gt; the following entries from <br>
      &gt; /work/clas/clasg12/clasg12/gflux/tripfiles/clas_057129.*.trip<br>
      &gt; <br>
      &gt; 1 374 0 26573389 26652473 79085 10000150 130 126 3882289477
      374421317<br>
      &gt; 0.815911 9 125 1 7145395 7224809 79415 10000310 130 126
      1392236466<br>
      &gt; 125416013 0.813763<br>
      &gt; <br>
      &gt; The first interval is marked as "good" (flag 0 in the 3rd
      column) and<br>
      &gt; will be counted by gflux. The second interval is marked "bad"
      (flag<br>
      &gt; "1") and will be ignored. The big question is: how can one
      understand<br>
      &gt; what is the difference between these intervals just by
      looking at<br>
      &gt; their corresponding entries in the trip file? Both are 10sec
      long <br>
      &gt; (7th column). Both have about 79k events (6th column). Both
      have the<br>
      &gt; same live time of 81% (last column). Both have identical
      times per<br>
      &gt; event 130 126 (columns 8&amp;9). Other columns are irrelevant
      (they are<br>
      &gt; sequential interval/event numbers and absolute clock
      readings). Just<br>
      &gt; from trip file entries alone, I don't see what makes them so
      <br>
      &gt; different. But sync did mark them differently nevertheless.<br>
      &gt; <br>
      &gt; Now, let's say we want to merge 2 split intervals from the
      end of<br>
      &gt; some file (flag -2) and the beginning of the next file (flag
      -1).<br>
      &gt; <br>
      &gt; 7 7 -2 604724 657855 53132 6353673 120 120 78568395 7008397<br>
      &gt; 0.791181 0 8 -1 657856 685600 27745 3646000 131 119 82214454<br>
      &gt; 8008433 0.801625 <br>
      &gt;
------------------------------------------------------------------------------<br>
      &gt;<br>
      &gt; </span><br>
    x&nbsp; x&nbsp; ?&nbsp;&nbsp; 604724&nbsp;&nbsp; 685600 80877 9999673&nbsp; xxx 124&nbsp;&nbsp; 82214454&nbsp;&nbsp;
    8008433 0.794989<br>
    <span style="white-space: pre;">&gt; <br>
      &gt; In the last line, I tried to merge them together. I summed up
      number<br>
      &gt; of events and time and recalculated live time and time per
      event. So,<br>
      &gt; what should I put in the 3rd column instead of "?" - good or
      bad? And<br>
      &gt; why? How is the last line different from either "good" or
      "bad"<br>
      &gt; intervals above?<br>
      &gt; <br>
      &gt; If we want to mark the merged interval as good by hands
      (numbers do<br>
      &gt; look good indeed: 80k events in 10sec, 79% live time) then we
      have to<br>
      &gt; do the same with the "bad" interval shown above (it also
      looks good<br>
      &gt; in the trip file). Or we have to let sync/tripFixer to decide
      how to<br>
      &gt; label newly-merged scaler intervals based on their internal
      logic<br>
      &gt; about beam fluctuations. I just don't want a situation when
      some<br>
      &gt; intervals are judged by us and other intervals are judged by
      sync.<br>
      &gt; <br>
      &gt; Another reason we want to rerun at least tripFixer is that we
      want to<br>
      &gt; group similar runs (60nA, 65nA, 24nA, major trigger changes).
      Last<br>
      &gt; time we did all runs together and, apparently, tripFixer
      parameters<br>
      &gt; for 24nA runs were overwhelmed by statistics from 60nA runs.
      I<br>
      &gt; suspect, this is why a percentage of bad intervals jumps from
      ~5% in<br>
      &gt; 60nA runs to ~22% in 24nA. I think it would be safer not to
      mix them<br>
      &gt; together this time.<br>
      &gt; <br>
      &gt; Sasha _______________________________________________ G12
      mailing<br>
      &gt; list <a class="moz-txt-link-abbreviated" href="mailto:G12@jlab.org">G12@jlab.org</a> <a class="moz-txt-link-rfc2396E" href="mailto:G12@jlab.org">&lt;mailto:G12@jlab.org&gt;</a> <br>
      &gt; <a class="moz-txt-link-freetext" href="https://mailman.jlab.org/mailman/listinfo/g12">https://mailman.jlab.org/mailman/listinfo/g12</a><br>
      &gt; <br>
      &gt; <br>
      &gt; <br>
      &gt; <br>
      &gt; -- Johann T. Goetz, PhD. <a class="moz-txt-link-abbreviated" href="mailto:jgoetz@ucla.edu">jgoetz@ucla.edu</a>
      <a class="moz-txt-link-rfc2396E" href="mailto:jgoetz@ucla.edu">&lt;mailto:jgoetz@ucla.edu&gt;</a> <br>
      &gt; Nefkens Group, UCLA Dept. of Physics &amp; Astronomy Hall-B,
      Jefferson<br>
      &gt; Lab, Newport News, VA Office: 757-269-5465 (CEBAF Center
      F-335) <br>
      &gt; Mobile: 757-768-9999<br>
      &gt; <br>
      &gt; <br>
      &gt; <br>
      &gt; _______________________________________________ G12 mailing
      list <br>
      &gt; <a class="moz-txt-link-abbreviated" href="mailto:G12@jlab.org">G12@jlab.org</a> <a class="moz-txt-link-freetext" href="https://mailman.jlab.org/mailman/listinfo/g12">https://mailman.jlab.org/mailman/listinfo/g12</a></span><br>
  </body>
</html>