IPP Software Navigation Tools IPP Links Communication Pan-STARRS Links

Changes between Version 13 and Version 14 of IPP_for_PS2


Ignore:
Timestamp:
Apr 12, 2018, 3:27:03 PM (8 years ago)
Author:
watersc1
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • IPP_for_PS2

    v13 v14  
    4848  * 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.
    4949   * I have added stackInputSkyfile entries for all i-band stacks that point at warp_id 60.  For all of them.  This lie should allow WS diffs to complete, as the camera will match.
     50   * Due to issues with ppSub and the way files are read, I have had to make a very hacky edit to ppSubCamera.c to allow these diffs to be generated.  After loading the warp images (from GPC2), ppSub throws an error when it attempts to read the stack (from GPC1) because the camera in the pmConfig object does not match the camera determined from the stack header.  This appears to be a fundamental limitation of the pmFPAfileDefine codebase, and I could not find an easy solution.  Instead, upon failing to read the stack, I have the code (near ppSubCamera.c:215) substitute the string GPC1 for GPC2 in the config->cameraName string.  This allows a second attempt to read the stack (and all subsequent stack products) to succeed, as the header matches the config expectation.  Once all stack products have been loaded, the config->cameraName string is set back to the original GPC2 value, and the difference processing continues as normal.  This generates images that appear reasonable, but this edit is not a good long-term solution.  The substitution is hardcoded, and ignores the fundamental issue that skycell products should be treated equally by the code, regardless of camera.