Changes between Version 5 and Version 6 of PS1_MD04_RefStack
- Timestamp:
- Jun 20, 2010, 12:13:39 PM (16 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
PS1_MD04_RefStack
v5 v6 7 7 === Data Available for MD04 === 8 8 9 PS1 has obtained 1204 exposures of MD04. Of these exposures, 70 were from 2008, and were ignored for this analysis. I also excluded the 3pi exposures taken in the vicinity of the field. This left a total of 1125exposures which could potentially be used, all taken between 2009.11.26 and 2010.05.05. For the basic reference stacks, as discussed below, I only included images taken in photometric conditions with seeing better than some nominal limit.9 PS1 has obtained 1204 exposures of MD04. Of these exposures, 70 were from 2008, and were ignored for this analysis. This left a total of 1134 exposures which could potentially be used, all taken between 2009.11.26 and 2010.05.05. For the basic reference stacks, as discussed below, I only included images taken in photometric conditions with seeing better than some nominal limit. 10 10 11 11 === Generation of the reference database === … … 106 106 Once the MD04 reference dvo database was available, it was now possible to use it for the data processing. I copied the database to the Maui cluster (actually a copy on several of machines to reduce the loading), and created an alternate reduction class in which I defined a psastro recipe with the new reference database as the calibration source. The was this is currently defined in the recipe system is a bit cumbersome; we need to consider ways of making this more flexible. One particular inconvenience comes from the definition of the average photcodes. The psastro recipe needs to associate the filter being processed with a specific average photcode from the reference database. The synthetic grizy database uses average names of the form g_SYNTH, and these are listed in the default recipe for gpc1 as a MULTI block. With our current metadata parsing, it is not possible to have a recipe which overrides the values in the MULTI block; new values simply supplement the set of existing values, leading to confusion. To make the system work for now, I changed the new reference db average photcodes to have the same form as the synthetic db. 107 107 108 I queued all of the 1134 relevant exposures of MD04 for re-processing using the new database. Some of these images, those from 3 nights in November and December 2009, have not had the current version of burntool run on the images. For now, I have simply deferred these imaegs. The rest were processed to the warp stage. To generate the stack, I selected the images with good photometry and acceptable seeing. I used limits of grizy = (6.0, 5.5, 5.0, 5.0, 5.0) pixels for the maximum accepted FWHM (major axis, PSF model version) and grizy = (24.55, 24.70, 24.55, 24.20, 23.25) as the minimum allowed zero point for the images. (Need a plot of the on the fly zero points). The on-the-fly astrometry was quite good, typically at the 15mas level. The above choice of limits resulted in roughly 100 exposures per filter available for the stack. 109 110 111
