IPP Progress Report for the week 2011.02.21 - 2011.02.25

(Up to IPP Progress Reports)

Eugene Magnier

I spent the week working on stack photometry issues. I have generated a set of MD04 stacks from raw data using my current development branch with 8 exposures per filter. I am trying to run psphotStack on the resulting stacks, but have been getting side-tracked by issues in the stacks and the in the photometry analysis of stack images. (The full psphotStack program is heavy enough to run that I would like to address issues in the single-stack psphot analysis before braving the full psphotStack analysis.)

I found that the PSF model for the stacks is not very well represented by the standard single-image PSF (PS1_V1, with a power-law slope of r3.33). For the 8-way stacks, at least, much better fit can be had with the 'QGAUSS' model, with a power-law slope of 2.25. For the generic stack, it may be necessary to use the 'RGAUSS' model, in which the model slope is a free parameter. Tests showed that this model worked nearly as well for the 8-way stacks as QGAUSS, but it should have the flexibility to handle the much deeper stacks as well. The impact of the model is the reduce the amplitude of the aperture-psf correction, and improve the scatter somewhat.

I also explored the question of weighted vs unweighted fits. As suspected, the unweighted fits do not show the substantial trend of the aperture-psf correction with magnitude (bias in the psf fits). We will use unweighted fits for the full-scale stack photometry analysis as well.

I identified the source of the error that is caused by having CELL.SATURATION set incorrectly. This value is used to mark objects as saturated if their fitted peak is higher than the saturation level. This information is then used in the aperture-correction analysis to exclude saturated stars. For deep stacks, this results in nearly all stars being excluded, and only a small number of poorly measured stars were actually used. The errors from those poorly measured stars were carried into the 2D aperture correction, with the result that all PSF magnitudes were then tainted. Fixing the value of CELL.SATURATION help, but this investigation also showed that the aperture correction analysis needed to be made more robust against catastrophic failures.

I addressed some cases in ppSub where the Kron analysis of the stamps failed to converge: the measurement is used to determine the stamp sizes, but if the image has insufficient clean stars, it will not converge. This situation is now detected as a bad-data case.

I also ran a number of tests to see if we can improve the rejection of bright objects in the background model. I added code to psphot to mask pixels significantly above the background model, and to re-measure the model. Even pushing the rejection to 2 sigma above background, I did not find a significant improvement in the background model: very bright stars and galaxies continue to bias the background model. I believe this is because nearly all of the pixels in the corresponding supercell have contributions from these objects near the sky level. The bias is not due to the extreme outliers, but rather to the plentiful insignificant outliers. My only possible suggestion to reduce this rejection would be to use larger superpixels (say 512 instead of 128).

Serge Chastel

  • MOPS czar
  • IPP czar on Friday
  • pstamp replication
  • mops tracking html pages
  • Finally found that the bottleneck in nebulous is apache. Trying to find the "right" configuration of MinSpareServers/MaxSpareServers? and possibly other parameters.

Heather Flewelling

  • selected a set of 3Pi exposures between early 2009 and the end of 2010 for testing of the new ippconfig changes. They processed through warp, diff, magic, with a few issues:
    • data > 2010-07-23 did not get processed using the new mask because that mask is "MASKTEST". I need to redo this set of data with a different config.
    • data < 2009-12-09 needs pattern correction on for all of the cells.
    • the rest of the data looks good - it respects the different configurations.
    • I need to reprocess with the 2 changes above, to test.
  • JT's MD reprocessing
    • finished MD06 (except for a few days that I need to investigate)
    • finished MD07 (except for one skycell)
  • addstar -resort investigations
    • unable to trigger the problem where addstar does not resort. Tried this with different ipp-builds (in case it was build dependent). The key points:
      • ThreePi?.298 was selected as my test case. dvoverify and bill's script say it is unsorted, gpc1 db has a resort time for it (so it claims it was sorted)
      • ThreePi?.298 was copied a couple of times, and had addstar -resort run on it with ipp-20101215 and ipp-20110218. Both builds report that addstar resorts without problems.
  • working on poster for Telescopes from Afar conference.
  • I am now the "survey czar"
  • wrote the scripts for queueing ThreePi?.136 diffs- these just 'copy' the diffs that had been done previously, with the same gaps and misqueues.

Roy Henderson

out sick

Bill Sweeney

  • Modified IPP to not automatically clean up data that has not yet been destreaked. This should help us insure that 3pi pairs taken on different nights get finished.
  • Debugged and repaired some bugs with postage stamp dependency checking that affects the diff stage
  • Marked camRuns whose data has been lost on ipp020 in the database.
  • Populated the detection efficiency measurements in chipProcessedImfile. (I collected this data last fall but never finished the task)
  • Update MPIA's ipp installation with a build from the current production branch.
  • Investigated the reason that getstar was not returning stars in the polar region. Fixed the problem.
  • Used the updated database to start processing data from the CNP survey. Debugged problem in psastro that causes about half of the exposures to fail astrometry.
  • Wrote script to set up chipRuns for reprocessing last month's ThreePi? data with the current IPP. Label is ThreePi?.136
  • Two days as processing czar + some time on the weekened monitoring ThreePi?.136.

Chris Waters

  • Investigated diffraction spike mask quality, and discovered some rotation between the applied masks and the actual spike positions. Implemented variable width masks that should help catch the full width of the brightest spikes. There is still some unexplained angle variations for some images that need more study.
  • Diskspace issues:
  • Ran some photometry comparison tests on GPC1/SDSS/Subaru data.