Changes between Version 12 and Version 13 of PS1_IPP_Czarlog_20190211

Timestamp:

Feb 15, 2019, 3:50:15 PM (7 years ago)

Author:

fairlamb

Comment:

--

PS1_IPP_Czarlog_20190211

@@ -880 +880 @@
 * 09:30 EAM : I discovered the ipp051 nebulous directory rsynced to ipp080.  I'm running the neb reinsert script to let nebulous know where these instances now live (they get moved from the /data/ipp080.0/retire_rsyncX/ipp051.0 subdirectory to the regular ipp080 nebulous directory).
 
+JRF: '''More pstamp shenanigans:'''
+
+Yesterday, the job I sent got interrupted because of the daily reset. This resulted in a fault being reported for it. To clear this away you can follow the steps on the PSNSC_MOPS page:
+{{{
+pstamptool -dbname ippRequestServer -dbserver ipp113 -updatereq  -set_state stop -req_id XXXXX
+}}}
+You can also clean it away, but it will get cleaned up in 14 days anyway.
+
+Sent another much shorter request that contains a few of the problem exposures. There is a log file that can be viewed by following the links on the psstamp website. It contains a relatively limited amount of information. The reqfinish log in the pstamp directory contains more information.
+
+There were still from fault [25] errors reported. To see what the issue issue is look at the log file by following the 'outputbase' in the reqlog. In this new log there is the actual error reported, along with the nebulous paths for the files used, specifically the skycell fits file. The fits files used can be loaded into DS9 and the co-ordinates double checked. In this particular case all of the errors were because the 'Region of Interest' was outside of the actual skycell. It's not really that the stamp is unavailable, just that the location requested isn't in the relevant skycell. It can occur when looking at overlapping skycells. The error reported is misleading, it should really be changed to report differently. So they're not actually missing.
+
 === Saturday : YYYY.MM.DD ===