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

  • Czar Monday: ipp027 looking into leaking disk sapce, ippc17 datastore locked out of mysql and other trouble so restart ippc17, tracked down missing exposures for MOPS, ippc29,ippc61 seem to stalled stdscience by filling book with CRASH entries so restarted and removed c29,c61 from processing.
  • PS1SC Durham: poster scramble (3 of 4 printed in time).
    • Full field MD images of all MD fields, .wt. images for posters and talk at Durham.
    • Re-run MD10 skycal to correct reduction type so most succeed. Collect all staticsky and skycal CMFs to local disk for making plots and take to meeting.
    • MD04,09.deeptest.20120727 staticsky and skycal CMFs for plots in talk at Durham and take to meeting.
  • MD.GR0 -
    • both md08,09 have the wt arc problem.. so lower priority to fix now.. but re-made a MD10.refstack.20120804 that looks good.
    • collect summary information for talk at Durham.
  • MD01 refstack priority since data being taken on field.
    • Few skycells, mostly in z, had troubles and re-ran with previous looser input cuts. Similar problem before with convolution mis-chosen, and re-visited ppStack patch w/o solution.
    • Test diffim sample and turned on for full nightly processing. Queued up recent delayed nights, but also continued to redo from past season and need to disable in future.
    • Out to distribution and uploaded to Odyssey.
  • STS warp-stack diffims for MOPS: ran test and queued up full nightly test sample STS.20120807 for MOPS to evaluate (to IPP-MOPS-TEST-2). MOPS found will not work, will need to re-evaluate refstack being used.

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