Creation of the MD04 Reference Stacks -- 2010.06.10

This page documents the process of creating the first set of deep MD04 reference stacks.

I generated a set of reference stacks for MD04 from the data taken in late 2009 / early 2010. For this analysis, I first generated a reference photometry and astrometry database, and then used that database to reprocess the images that went into the stack. The expectation is that the improved astrometry should result in better registration of the images and thus a better stack, while the improved photometry should allow for a deep stack which is correctly calibrated relative to the rest of the PS1 system.

Data Available for MD04

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 1125 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.

Generation of the reference database

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.

select exp_name, dateobs, exp_id, max(cam_id), filter, camProcessedExp.path_base
from camRun 
join camProcessedExp using (cam_id)
join chipRun using (chip_id) 
join rawExp using (exp_id) 
where comment like 'MD04%'
and camRun.magicked > 0 
group by exp_id
order by dateobs

The selected images were ingested into 2 dvo databases (one for griz and a second for y-band). Below, I give the addstar commands used for the ingest. In this case, the 'NOMINAL' zero point was applied; this means that the on-the-fly calibrations were ignored and the expected zero points were used.

foreach file (`cat smffiles.list`)
  set realname = `neb-locate -p $file`
  addstar -D PHOTCODE_FILE dvo.photcode.grizyJHK -D ZERO_POINT_OPTION NOMINAL -D SKY_DEPTH 4 -D CAMERA gpc1 -D CATDIR $catdir -update $realname -use-name $file
end

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).

set region = "-region 147.0 152.0 0.0 4.2"
addstar -D CATDIR $catdir -resort $region
load2mass -v -D CATDIR $catdir -existing-regions $region
relphot -v -D GRID_TOOFEW 10 -D MOSAICNAME GPC1 -D CATDIR $catdir -averages -update -reset -statmode WT_MEAN $region
relastro -v -D GRID_TOOFEW 10 -D MOSAICNAME GPC1 -D CATDIR $catdir -update-objects -update $region

After the databases were created, I ran the full-scale relative astrometry and photometry analysis on them. The relative photometry analysis currently runs separately for each target average photcode (grizy). The analysis determines the average magnitudes of the stars in the images, based on the available measurements, then uses these averages to determine the relative offsets of the image zero points. It stabilizes the system of equations by re-setting the photometric clusters of images to 0.0. The program performs a requested number of iterations on the photometry. As the analysis proceeds, the code attempts to identify outlier detections for individual stars, then outlier stars (variable stars) from the sample, and finally outlier images -- those with excessively large scatter (ie, poor photometric conditions). As these outlier / poor entries are discovered, they are excluded from the constraints on the average magnitudes. I ran 20 iterations of relative photometry, using the commands listed below. Note that only the high signal-to-noise measurements were used to determine the relative photometry (SIGMA_LIM), and that the zero points were calculated for the full GPC1 exposures, with the individual chips held fixed relative to one another (-imfreeze -mosaic). The -statmode option specifies how the averaging is performed; in this case, the analysis performs a weighted mean of the inner 50% of the available measurements.

foreach filter (g r i z y)
  relphot $region -v -D GRID_TOOFEW 10 -D MOSAICNAME GPC1 -D SIGMA_LIM 0.025 -D CATDIR $catdir -update -statmode INNER_WTMEAN -nloop 20 -imfreeze -mosaic $filter
end

The relative astrometry analysis currently performs only one stage of the analysis at a time. Either the average positions of objects in the database are calculated based on the current image calibration parameters, or the image calibrations are re-measured based on the average positions of the objects in the database. Like the relative photometry analysis, this process requires a series of iterations to converge on a good solution. In this example, I ran 4 iterations. Currently, relastro does not perform a very robust outlier rejection. The commands used are listed below (repeated 4 times in the actual analysis):

relastro $region -v -D GRID_TOOFEW 10 -D MOSAICNAME GPC1 -D CATDIR $catdir -update-objects -update
relastro $region -v -D GRID_TOOFEW 10 -D MOSAICNAME GPC1 -D CATDIR $catdir -update-chips -update