| | 7 | |
| | 8 | One of my current goals is to generate a clean demonstration deep stack of MD04, both for its own sake, and as an example for the rest of the deep stacks. The prerequisite for this is a photometry and astrometry reference database for the field. I a good part of the week working on this, and running into various blocks. I eventually discovered that there were a couple of bugs introduced in the dvo code that corrupted the NAN values, and which in turn resulted in nonsensical magnitudes for some sources. I have addressed this particular issue, and am continuing to double check the relphot analysis on the MD04 field to ensure no other subtle bugs are present in the code. |
| | 9 | |
| | 10 | The telescope finally obtained a set of STS images appropriate for the reference stack, so while I was processing czar on Thursday and Friday, I attempted to build these stacks. The processing proceeded well to the warp stage, but the stacking process bogged down very badly. Our nightly stacks (8-deep) normally only take about 10-15 minutes of processing time. The STS stacks had more inputs (30-60), so I expected them to be a few to nearly 10 times as long. Instead, they took 10-15 hours, much longer than expected, and many failed completely. I looked into this, and consulted with Paul on the possible slow-downs. We discovered three choices in ppStack which are not optimal, and which are exaggerated when the stellar density is high, all related to the fake reference image generated for the PSF matching: 1) there is no limit to the number of stars used to make the fake image; 2) the stellar profiles are placed in the image to a flux significance of 0.01 sigma, which can be extremely large; 3) a separate reference is generated for each input image, even though they cover the same area. Although some care is needed, we can probably make some important speed gains by addressing these issues. I have postponed the STS stacks until at least some of this can be fixed. |
| | 11 | |
| | 12 | Finally, I spent part of the week on a relastro mode to detect possible high-speed proper motion candidates. Niall Deacon has been working on this problem using DVO shell user-level queries, and it has been extremely slow. The relastro version is now working and generates a useful set of output parameters, but is not yet easily configurable (options need to be changed in the C-code). But, where the DVO shell version was taking multiple weeks to run on the 3pi data set, the relastro version can be run in roughly a couple hours for the full sky. It clearly shows that while the DVO shell may be convenient for simple queries, it is far from optimal for queries which are equivalent to a 2point correlation function. PSPS will (hopefully!) be much better in this respect. |
