Changes between Version 10 and Version 11 of PS1_MD04_RefStack

Timestamp:

Jun 22, 2010, 5:17:50 PM (16 years ago)

Author:

Michael Wood-Vasey

Comment:

minor copyedits

PS1_MD04_RefStack

@@ -21 +21 @@
 ==== Selection of the input images ====
 
-To build the reference database, I selected a subset of the exposures which had already been processed and for which magic had been applied,  It turns out that a number of the images (those from before Demo Month) have not been individually magicked -- only the nightly stacks have been distributed to date. In addition, we never created a y-band reference stack, so no y-band images have been processed through diff.  These two restrictions resulted in a total of 295 images available for the reference photometry database in griz.  The sql used to select the images can be found.  I made a separate y-band only database, accepting images which had not been magicked.  
+To build the reference database, I selected a subset of the exposures which had already been processed and for which magic had been applied,  It turns out that a number of the images (those from before Demo Month) have not been individually magicked -- only the nightly stacks have been distributed to date. In addition, we never created a y-band reference stack, so no y-band images have been processed through diff.  These two restrictions resulted in a total of 295 images available for the reference photometry database in griz.  The sql used to select the images can be found below.  I made a separate y-band only database, accepting images which had not been magicked.  
 
 {{{
@@ -46 +46 @@
 }}}
 
-After running addstar on all of the input images, as well as the addstar 'resort' step needed to update the table indexes, I ingested the 2mass data for these regions so that any astrometry analysis performed with this database could constrain images near the edge of the field.  I then ran basic averaging of astrometric and photometric properties (this last step is somewhat redundant with the relphot and relastro analysis below and could be skipped).  The commands for this analysis is given below (note the restriction to the region of interest around MD04).
+After running addstar on all of the input images, as well as the addstar 'resort' step needed to update the table indexes, I ingested the 2mass data for these regions so that any astrometry analysis performed with this database could constrain images near the edge of the field.  I then ran basic averaging of astrometric and photometric properties (this last step is somewhat redundant with the relphot and relastro analysis below and could be skipped).  The commands for this analysis are given below (note the restriction to the region of interest around MD04).
 
 {{{
@@ -103 +103 @@
 }}}
 
-Next, I extract the sdss measurements and the average magnitudes in the equivalent average photcode to determine the zero point offsets between the initial calibration and the SDSS magnitude system.  Here is the mextract command (cycle photcode value: g,r,u,z,y = 1056,7,8,9,60).
+Next, I extract the sdss measurements and the average magnitudes in the equivalent average photcode to determine the zero point offsets between the initial calibration and the SDSS magnitude system.  Here is the mextract command (cycle photcode value: g,r,u,z,y = 1056,1057,1058,1059,1060).
 {{{
 mextract ra, dec, mag, mag:ave where (photcode == 1056)
@@ -112 +112 @@
 === Processing the Images ===
 
-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.  
+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 way 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.  
 
-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.   
+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 images.  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.