IPP Progress Report for the week 2011.01.17 - 2011.01.21

(Up to IPP Progress Reports)

Eugene Magnier

I have continued to worry about the magic masking coming from the PSF-matching code. I have adjusted the code to make a choice for the single 1, single 2, or dual convolution based on the improvements to the chisq of the fit (it must improve enough to justify more terms). This modification helps, but does not solve all issues. Looking further, I discovered 2 additional interesting issues. First, the PSF-matching code scales sizes of the set of Gaussians based on the FWHM of the input images. This input FWHM is measured on the warp images from sources at the locations determined by detection on the chip images. I discovered that sometimes these reported FWHM is significantly different from the actual FWHM -- the rate of bad PSF model fits seems to be higher in the warp output than in the chip analysis. I modified the code to use the moments-based analysis of the FWHM in the ppSub process to determine the Gaussian sizes, rather than trusting the warp values. Second, I discovered an error in the code which truncates the convolution kernel : this function is called before propagating the covariance matrix through the convolution kernel. The effect of the error is ignore the convolution kernel when propagating the covariance, resulting in the wrong covariance values. The error in the code has been in place since early 2010, but is only triggered in cases when the convolution kernel is large compared with the kernel window, so the effect was only rarely triggered. The modifications in 8-2010 included reduction of that window to speed the processing, resulting much greater frequency of the error being triggered. Applying these fixes has improved the masking rate relative to the 8/23 installation, but does not reach the levels from before that code change, so I am still investigating this issue.

I also addressed the relphot / dvo error that Heather and Roy were hitting. I extended 'dvoverify' to test the values of the internal and external indexes, and found that the last entry in a dvo average table can claim the wrong number of measurements -- an off-by-one counting error. this is now fixed in my branch and is addressed by re-running 'addstar -resort'.

I also spent some time on the magic and burntool processing throughputs: when we have a large data backlog, the magic queries can result in under-filled processing queues, slowing the magic processing rate. This can be addressed by requesting more jobs per query; making this change pushed the magic throughput to ~50-70 exposures per hour. For burntool, the relevant pantasks was being slowed by other stdscience processing taking place on the same machine. Reducing the number of processing connections to that pantasks host made the burntool (and the rest of registration) zip along much faster.

Serge Chastel

  • MOPS czar
  • IPP czar on Friday
  • MySql? (Ingesting 64M entries in a nebulous db using neb-touch on ippc01).

Heather Flewelling

  • czar Wed and Thurs. No data (bad weather), however there were problems registering images. Also tried to kick registration/burntool on Monday, unsuccessfully.
  • relphot investigations -- Why can't we relphot ThreePi?.283? I tried building different minidvodbs from those cam_ids, and I have not found any useful clues.
    • binary sort (keep chopping the number of cam_ids in half until you find which cam_id is corrupted) - this didn't work. On the chop from 81->40, I created 2 dvodbs that can have relphot run on them successfully.
    • taking one of those, and adding in the missing cam_ids one at a time, and running relphot on it in between, didn't work - I added in all the cam_ids and it was fine.
    • running relphot on 284- it ran fine.
    • roy also tried to investigate, also unsuccessfully.
  • fringe investigations
    • there was no signal on my good and bad examples (!),so it was fitting things pretty randomly. I found a fringe with a good amount of signal, and I can see that it still has a number of bad points in it. I think the bad points are messing up the fit, I'm investigating further.
  • found what is taking up diskspace on ipp004 and started cleaning it up - nearly 2TB of nebulous! There are other offenders too, but that one is by far the largest and easiest to take care of.

Roy Henderson

  • PSPS
    • detection loading continued: now 10,000 MergeWorthy. Stopped so we can merge.
    • PSVO
      • added right-click menus to table for specific columns:
        • get detections for 'this' frame
        • get columns for 'this' table
      • fixed some small bugs reported by Jim: table resizing and 'long' data type not exporting to TOPCAT
      • added ability to pass ecliptic and galactic plane coords to TOPCAT for plotting
      • added to documentation, both wiki and code comments
      • finally checked-in to PSPS repository
  • IPP
    • looked into relphot bug with Heather:
      • found crash in relphot: array-out-of-bounds in 'setMave()' function
      • wrote script to make mini-mini DVOS for each smf, to ascertain whether it was due to corrupt input file (or two). sadly relphot doesn't work on these...
    • some minor fixes to ipp metrics code

Bill Sweeney

  • Finished implementation and testing of muggle postage stamps that I started last week. Integrated the code and deployed to the production system.
  • Kept watch on the STS data processing, keeping it flowing.
  • Wrote a program to facilitate queuing data to be reprocessed to make a reference stack. Used it to queue for MD05.

Chris Waters

  • Fixed bugs in queuing code for nightly science. Added code to properly excluded exposures that are faulty at the summit that were preventing burntool from completing.
  • Ran bin-by-4 ppImage runs for laser data.
  • Ran more ROC correction runs to fix bad ROC files.
  • Finished correcting log(flux) compression method, although I have not finished writing recipes that automatically use these methods.