LAP Czaring

Overall czaring sequence

• Check the current runs: laptool -listrun -seq_id 8 -state run
  • If everything was recently registered, or has a defined stack association id, it's probably ok.
  • If a run is old, or looks stuck, look at the exposures: laptool -exposures -lap_id LLL
    • Is something stuck because of a fault? Revert it.
    • Is something failing after a revert? It probably has a corrupt file, check the log and fix it.
    • Is something weird? If you can't figure out why exposure X is holding things up, kick it out so we can move on: laptool -updateexp -lap_id LLL -exp_id XXX -set_data_state drop

Examples

After calling laptool -exposures -lap_id 1230 -simple:

 1230 RINGS.V3 skycell.1405 r.00000 run 2011-10-11T01:58:46.000000 0 LAP.ThreePi.20110809 LAP.ThreePi 97873 307033 307034 F T T full full 0 60 283612 full 0 1 267013 full 270040 full 12 71 219206 174035 cleaned 2 59

This is fine. It was generated from an update call, and so that's why the diffRun.state is cleaned, but the other states are full.

 1230 RINGS.V3 skycell.1405 r.00000 run 2011-10-11T01:58:46.000000 0 LAP.ThreePi.20110809 LAP.ThreePi 97902 307036 307035 F T T to_magic update 0 60 283614 full 0 1 267017 full 270044 update 10 72 -1 174036 cleaned 4 60

This is also ok. It's another exposure being updated, but is waiting on the chip stage to finish updating. The lapExp.data_state value of "to_magic" denotes that LAP is waiting for this to destreak the warp stage.

 1230 RINGS.V3 skycell.1405 r.00000 run 2011-10-11T01:58:46.000000 0 LAP.ThreePi.20110809 LAP.ThreePi 98666 319194 319195 F T T full full 0 60 296302 full 0 1 279553 full 281037 full 7 68 225586 178478 full 4 61

This exposure was first processed as part of this lapRun, and has completely finished regular processing. There should be no problems with this exposure.

 1230 RINGS.V3 skycell.1405 r.00000 run 2011-10-11T01:58:46.000000 0 LAP.ThreePi.20110809 LAP.ThreePi 101218 307039 9223372036854775807 T F T to_diff full 0 60 283617 full 0 1 267018 full 270045 full 10 71 0 9223372036854775807  0 0

This exposure does not have a pair, and so the private bit is set to TRUE, and the pairwise bit is set to FALSE. Since we have not made any stacks yet, this exposure is waiting for that. Since it is likely to span multiple projection cells, it may not get a diff as part of this lapRun. In this case, it will have lapExp.data_state set to 'drop' when the lapRun reaches the diff check.

 1241 RINGS.V3 skycell.1586 r.00000 run 2011-10-11T15:26:03.000000 0 LAP.ThreePi.20110809 LAP.ThreePi 97951 319256 319258 F T T to_diff full 0 60 296359 full 0 1 279618 full 281149 full 6 67 0 9223372036854775807  0 0

Regular pairwise diff. It's waiting on other data so the stacks can be made, and once that's done, will do the diff.

 1241 RINGS.V3 skycell.1586 r.00000 run 2011-10-11T15:26:03.000000 0 LAP.ThreePi.20110809 LAP.ThreePi 97976 319461 319462 F T T new new 0 0 9223372036854775807  0 0 9223372036854775807  9223372036854775807  0 0 9223372036854775807 9223372036854775807  0 0

Regular new exposure. No processing has been done yet, but there shouldn't be any problems with it.

 1241 RINGS.V3 skycell.1586 r.00000 run 2011-10-11T15:26:03.000000 0 LAP.ThreePi.20110809 LAP.ThreePi 98678 319235 319233 F T T exists full 0 60 296343 full 0 1 279655 full 281187 full 4 68 0 9223372036854775807  0 0

Similarly, this is an exposure that was already largely processed as part of another lapRun.

 1209 RINGS.V3 skycell.1408 g.00000 run 2011-10-10T13:55:40.000000 0 LAP.ThreePi.20110809 LAP.ThreePi 384906 314005 314002 F T T drop cleaned 0 60 291112 full 1 1 9223372036854775807  9223372036854372036854775807  0 0

This exposure was dropped from further processing because it has a bad quality value at the camera stage (probably a problem with the astrometry).

 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 error_cleaned 0 60 283621 full 0 1 267023 full 270050 update 13 75 -1 174042 cleaned 3 62

The chip processing for this exposure wasn't fully cleaned, and due to a peculiarity with the update code, it wasn't fully updated. This can be fixed by calling chiptool:

chiptool -updateprocessedimfile -set_state cleaned -chip_id 307042 -class_id XY46
chiptool -updaterun -set_state cleaned -chip_id 307042
chiptool -setimfiletoupdate -chip_id 307042 -set_label LAP.ThreePi.20110809

1222 RINGS.V3 skycell.1494 i.00000 run 2011-10-10T17:49:40.000000 0 LAP.ThreePi.20110809 LAP.ThreePi 208760 306559 306557 F T T to_magic update 0 60 282803 full 0 1 266222 full 269249 update 7 71 -1 173576 cleaned 5 64