Changes between Version 10 and Version 11 of LAP_Czar

Timestamp:

Nov 1, 2011, 6:02:07 PM (15 years ago)

Author:

watersc1

Comment:

--

LAP_Czar

@@ -178 +178 @@
 
 This exposure looks fine (it's waiting for update to finish), but as update faults aren't shown in czartool, there may be problems.  chiptool sorts the jobs by chip_id, so update jobs (which have smaller, older chip_id values) always run before new jobs.  If you see a lapExp line like this, but are processing new jobs, then there's probably a hidden fault that needs to be tracked down and fixed.
+
+{{{
+1230 RINGS.V3 skycell.1405 r.00000 run 2011-10-11T01:58:46.000000 0 LAP.ThreePi.20110809 LAP.ThreePi 209356 307042 307045 F T T to_magic cleaned 0 60 283621 full 0 1 267023 full 270050 cleaned 13 75 -1 174042 cleaned 3 62
+}}}
+
+A line similar to this showed up today (2011-11-01).  It seems that this exposure did not get updated when the lapRun was queued, and continued to not get updated when the three other lapRuns that contained it were queued.  I don't have a good explanation for this at the moment, but this was easily resolved by running the update commands for the chip, warp, and destreak runs (I grabbed that bit of code out of lap_science.pl, and put it in /home/panstarrs/watersc1/bin/run_update_for_chip_id.pl. This might be useful if this problem crops up again, as I currently don't see any obvious reason why the update wouldn't happen.  The script takes the chip_id to be updated, and runs the commands as needed).