IPP Progress Report for the week 2012-08-06 - 2012-08-12

(Up to IPP Progress Reports)

Eugene Magnier

Serge Chastel

• Czaring
• Partial implementation of the ota check.
• ipp027 / ipp022 backup

Heather Flewelling

• q2 is finally built - minus the 2 broken minidvos, and handed off to Gene
• SAS8 is loaded onto the datastore (with new schema)
  • some queries on PSPS sandbox to check sanity:
    • when nx = 0, xMeanPSFMag/Err look okay (they are -999), but xMeanKronMag/Err are completely random numbers
    • x20pct/x80pct default to 32.767 instead of -999
    • xStackKronMag is goofy, the actual kron mag = xStackKronMag + 2*8.9
    • there are objects with -999s for everything (these are present in the dvo as well)
    • xflags, sgsep, infoFlags are not yet populated
    • skycell_id, projection_id are not properly in psps (this is known, I just found it again)
  • i was cheating and doing the following to grab stuff: where ng > 0 and nr > 0 and ni > 0 and nz > 0 and ny > 0.
• not enough work on my talk for durham
• travel days to london/durham (thursday/friday)

Mark Huber

Bill Sweeney

• Debugged a ppImage process that was consuming large amounts of memory. It turned out that psphot was erroneously measuring very large fwhm for the psf in a chip with a very bright gint (from Mira) on the edge of the field of view. Further analysis found that the pattern row correction is causing problems near such sources.
• Implemented a recipe change to reduce the maximum sigma value used in the moments window measurement for gpc1. This did not "fix" the problem above but is a reasonable thing to do given that the current code was producing unreasonably large values.
• Implemented a hack to fault a chip when the *measured* fwhm is larger than 35 pixels. This avoids the memory explosion.
• Debugged and fixed a problem with psastro where unreasonably large negative magnitudes in the reference catalog caused some code to run forever.
• Set up distribution of the ecliptic.rp data. Investigated why some exposures were not republished. (They failed astrometry in the lap run even though they worked on the night they were taken.)
• Did a detailed analysis of where the memory is being used by psphotStack. Report to be written. Summary: There are no apparent magic bullets. 100,000 sources x 5 filters x 2 copies is just a whole lot of memory (40G). We either need to reorganize how psphotStack does its analysis or limit it to run only on machines with a lot of RAM (at least for fields in the galactic plane)
• Tracked down and fixed the cause of unmasked infinite pixels in psphot.
• Several weekend hours acting as processing czar. Summit copy and/or registration seemed to be having more problems than usual causing things to get hung up at night. Later in the week the situation seemed to improve.

Chris Waters