Changes between Version 3 and Version 4 of Processing_Log

Timestamp:

Jun 9, 2010, 1:38:14 PM (16 years ago)

Author:

bills

Comment:

--

Processing_Log

@@ -4 +4 @@
 2010-06-09 Bill
  * Bad weather last night never opened. 
- * chip processing was generating lots of errors due to missing detrends. It turns out that some engineering exposures got made with obs_mode = '3PI'. Set chipRuns to drop.
+ * chip processing was generating lots of errors due to missing detrends. It turns out that some engineering exposures got made with obs_mode = '3PI'. Set these chipRuns to drop.
  * camRun 85769 repeatedly failed. exp_name o5354g0523o. jpeg images for exposures around this time have lots of missing chips. Observing log says 'g0490o - g0523o  Most of these exposures were taken in twilight and need to be redone' Set camRun to drop with note to this effect
  * 4 warpSkyfiles were repeatedly failing. This was because one of the input images chip_id 100112 class_id XY17 was corrupted. Re-ran chip_imfile.pl by hand, reverted warp, and it completed. The command line was
@@ -11 +11 @@
 
 }}}
- * What!? camRun 85769 got set changed from drop to new! Looks like camtool -revertprocessedexp is obsolete. Paul will investigate.
+ * What!? camRun 85769 got set changed from drop to new! Looks like camtool -revertprocessedexp is obsolete. Paul investigated and fixed in trunk.
+ * 4 of the twilight exposures from MJD 55354 failed at warp stage. Set the corresponding runs' state to 'drop'.
+ * Eric Morganson reports that some postage stamp requests he submitted last night (HST) didn't complete. Turns out each one referenced some warpRuns in unexpected state:  state = 'full' magicked = -1 Fixed by setting the corresponding magicDSRuns to state new. This shouldn't have happened. Magicked gets set to -1 when cleaned and
+at update time, since the chips are magicked the warps are magicked.  These were the only runs in this state (at any stage) so I let this go for now.