| | 28 | * 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. |
| | 29 | * 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. |
| | 30 | * Implemented a hack to fault a chip when the *measured* fwhm is larger than 35 pixels. This avoids the memory explosion. |
| | 31 | * Debugged and fixed a problem with psastro where unreasonably large negative magnitudes in the reference catalog caused some code to run forever. |
| | 32 | * 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.) |
| | 33 | * 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) |
| | 34 | * Tracked down and fixed the cause of unmasked infinite pixels in psphot. |
| | 35 | * 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. |
