• Main INDEX
  • Monthly INDEX
  • PREV
  • NEXT
    Make New Entry, Make Followup Entry

    User name R. Michaels

    Log entry time 07:29:51 on December17,2010

    Entry number 344788

    Followups:

    keyword=missing halog end-run problem

    Some runs like 9724 and 9727 do not have end-of-run info in halog,
    while others like 9722 and 9725 do. Then there are CODA crash
    runs like 9723 which obviously don't, but that's understandable.

    I investigated the problem. In ~a-onl/epics/runfiles you will see
    normally 5 files (ls *9725*), but for the miss-end runs only 4 files,
    the missing one being halog_end_*.epics. This file is produced at
    the end of the script epicsRunEnd

    cat $comfile > $halogfile
    cat $epicsfile >> $halogfile

    where $comfile is halog_com_*.epics, $epicsfile is End_of_Run_*.epics
    and $halogfile is the one that gets missed, namely halog_end_*.epics.

    If we look at $epicsfile it's clear what fails:
    Consider the lines that retrieve info about DVCS calorimeter, e.g.

    log "Anode current of block 200 (c,r:12,8) :" `$CAGET -t -f3 haVMI3128_4_AI9`

    You can see that if this reaches the end (block 207) everything
    is fine (5 files produced and $halogfile goes to halog.

    But if it stops somewhere short (run 9724 stops at block 176
    and run 9727 stops at block 190) so the lines that create
    $halogfile never happen. Hence no end-run entry in halog.

    I'm a little too tired to fix it now, but my speculation is
    that the 200+ lines of caget that were added for DVCS calo
    take a long time, and if the next run is started quickly
    it will "clean up" (via a script designed to kill hanging
    processes) the previous instances of the script. The culprit
    may be the line "killproc caget emacs" in end_clean. So either
    don't do that, or delay that, or improve the logic some other way.

    The data are still available but it's not so convenient to miss
    the end-run halog entries.