PS1 IPP Czar Logs for the week YYYY.MM.DD - YYYY.MM.DD

(Up to PS1 IPP Czar Logs)

Monday : 2015.06.22

• 01:30 MEH: processing rate is terrible ~20/hr.. not sure cause since stdsci looks like it needed to be restarted for sunday night.. doing now and pstamp as it needs it too. then will see if another problem if time before observing...
  • better but not normal, ipp079 seems to being harassed with high cpu wait conditions so try setting repair.. something extra over-running unmonitored?
• 02:30 MEH: summitcopy 10% jobs are faults from 404 files from conductor issue on saturday start of night... -- probably just need to set to drop but no time to deal with

  http://conductor.ifa.hawaii.edu/ds/gpc1/o7194g0009d/o7194g0009d76.fits
  --> then most to all of 0010
  http://conductor.ifa.hawaii.edu/ds/gpc1/o7194g0010d/o7194g0010d01.fits
  

Tuesday : 2015.06.23

• 09:35 Bill: restarted pstamp pantasks
• 11:23 HAF: repeat diff failure, fixed: difftool -dbname gpc1 -updatediffskyfile -set_quality 42 -fault 0 -skycell_id skycell.1326.001 -diff_id 1166562
• 16:08 HAF: restarting pantasks for tonight

Wednesday : 2015-06-24

• 12:15 CZW: set ipp094 and ipp097 off in stdscience. They seem to know how to automount ippb06.2, they have an automounter running, but they do not automount ippb06.2. I suspect this is some transient weirdness, as this would have been noticed before now. They symptom is that they are attempting to do a WS diff, failing to find the primary copy of the stack that is on b06, and failing with fault 2. I've also set WS diffs that were repeatably not completing with fault 5 to a bad quality to clear them out.
• 15:00 CZW: Pushing the phase 1 shuffle (off stsci) somewhat harder to try and make sure that we have free space for the incoming data.
• 20:50 EAM: stopping and restarting ipp pantaskses.

Thursday : 2015.06.25

• 08:37 Bill: started up staticsky as ~ippsky using x0 and x1 hosts

Friday : YYYY.MM.DD

Saturday : YYYY.MM.DD

Sunday : YYYY.MM.DD