Changes between Version 11 and Version 12 of IPP_for_PS2

Timestamp:

Apr 10, 2018, 4:29:06 PM (8 years ago)

Author:

watersc1

Comment:

--

IPP_for_PS2

@@ -44 +44 @@
  * There is no cleanup pantasks, so nightly science exposures go to label="goto_cleaned" and state="goto_cleaned".  For the one night of science data, I moved them back using {{{STAGEtool -dbname tgpc2 -updaterun -label goto_cleaned -set_label czw.up -set_state full}}}.
  * The current MASK is a DARKMASK+FLATMASK that does not exclude static bad pixels/columns that are not caught by those processes.
- * The i-band GPC1 stacks with label="LAP.PV3.20140730.final" are being ingested into the tgpc2 database to allow for warp (GPC2) - stack (GPC1) difference image processing.  The stackRun.filter column will need to be modified, as difftool blocks diffs that do not have the same filter.  The ingest process uses the stack_id value from the gpc1 database, so the tgpc2.stackRun and tgpc2.stackSumSkyfile tables will have a much higher auto-increment value.  The stackInputSkyfile entries are lost, as they reference warpSkyfile entries that do not exist.
  * Occasionally the OBJECT field is not cleared before engineering data is taken.  This has not resulted in non-science exposures being processed, but it is a possibility.
  * The i-band GPC1 stacks with label="LAP.PV3.20140730.final" are being ingested into the tgpc2 database to allow for warp (GPC2) - stack (GPC1) difference image processing.  The stackRun.filter column will need to be modified, as difftool blocks diffs that do not have the same filter.  The ingest process uses the stack_id value from the gpc1 database, so the tgpc2.stackRun and tgpc2.stackSumSkyfile tables will have a much higher auto-increment value.  The stackInputSkyfile entries are lost, as they reference warpSkyfile entries that do not exist.
+  * Warp (GPC2) - stack (GPC1) difference images do not currently work, because there is a database JOIN from the stackInputSkyfile table to the warpRun table, I assume to prevent a stack from being subtracted from an input warp.  However, as the stack entries are fakes from the GPC1 database, this JOIN fails, and no stacks are found when the diff is attempted.  This is not a queuing issue, as the diffInputSkyfile entries were constructed with appropriate warp1/stack2 values.  It is only when processing the diff does the issue come up.  I think the solution is to create a sacrificial warp that will be the "input" to all ingested stacks.